如何控制对话轮次
轮次从哪来
每段对话自带一个计数器：第一封信 turn="1"，回信 2，再回 3——双方都不用记，引用里自动 +1，status --conversations 的 turn 列读的就是它。它是对话的里程表：一眼看出这段对话走了多远，也看出两个 agent 是不是在对弹。
给对话设预算
预算三层来源，优先级从高到低：
| 层 | 形态 | 生效范围 |
|---|---|---|
| 单条消息 | crosschat send --max-turn 40 … | 这一条信封 |
| 环境变量 | CROSSCHAT_MAX_TURN=40 | 这台机器的每次 send |
| 会话级（启动器） | crosschat claude --max-turn 40 | 这个会话后续所有 send（写进子进程环境变量） |
启动器形态最常用：起会话时就定好这场的预算，之后会话里每次发消息都自动带上，不用每条手写。非法值（非正整数）的行为有意不对称——send 侧静默降级到下一层（不打断 agent 的自纠循环），启动器侧当场报错（人在终端前，立刻改）。
turn=“13/40” 怎么读
设了预算，信封里的轮次就带分母（真实信封头，--max-turn 5 发出）：
<cross-session-message from-name="单机通信专家" turn="1/5">
13/40 读作：第 13 轮，预算 40 轮。收发双方都看得见——这是协议层的共同仪表盘，不是私设的提醒。
预算是软提醒
超过预算不硬拦：turn="41/40" 照发照显，任务没完可以继续。设计意图是给收发双方一个“该总结收尾了“的共同信号，而不是替你掐断对话——什么时候停是判断题，协议只保证双方看到同一个数字。实操口径：接近分母时主动总结结论、说清剩余事项，需要继续就明说“预算续到多少“。
轮次、限流与上下文
三个容易混的东西，各管各的：
| 机制 | 管什么 | 数字 |
|---|---|---|
| 轮次计数 | 这段对话走了多远（里程） | 无上限，只计数 |
| 轮次预算 | 提醒收尾（软） | 你定（--max-turn） |
| 防乒乓限流 | 两个 AI 别无限对弹（速率） | 30 条 / 60 秒 / 每对会话，超了报 RATE_LIMITED 等待即可 |
⚠️ 概念红线：这些机制（连同 16KiB 大小上限）都是传输与状态治理，不是上下文保护——crosschat 不管理任何 agent 的上下文窗口，也管不了。对话内容的真正治理是轮次预算：它是协议给“上下文快满了“这件事的唯一答案（机制全貌见第1课 1.5 上限与限流）。