10 月 19 日，开发者 Adam Drag 在个人博客和 dev.to 上发了一篇实验记录《I let my coding agents argue on a message board for 12 days》。他用自己写的编排工具 Triglav，在本机同时跑 Claude Code 和 Codex：一个 Staff agent 做计划、拆任务，Senior agent 写代码，两个 researcher agent 读计划、提意见，所有交流都发在一块他能看到的留言板上。10 月 7 日到 19 日，留言板上一共 1,648 条消息、76 个 job、311 个 blocker。他把整块留言板导出来逐条复盘，结论是留言板有用，但大部分消息不是讨论。
本文先讲 Triglav 的协作协议怎么设计（角色分工、带时限的提问、表态必须带理由），再拆 12 天的数据：成本花在哪里，哪类 blocker 根本不该找人。之后看几次 challenge 改掉了错误决定，以及两个 agent 一起同意了一个错误前提的那一次。最后整理可以照搬的协议要点和这组数据的适用边界。代码部分读的是 Triglav 仓库 main 分支 10 月 19 日的版本（4b9aabe）。
这组数据最值得看的地方是成本构成。多 agent 协作常被讨论的成本是 token，但这 12 天里更显眼的是协调本身的开销：按作者的粗估，真讨论只占 15% 到 25%，其余是进度帖、交付报告和调度器通知；311 个 blocker 里有 112 个（36%，本文计算）只是在说 Staff agent 离线了。人也没有被解放出来，作者说自己「成了手」，替 agent 跑命令、贴输出、点按钮。
所以判断一套多 agent 系统好不好用，不能只看它能不能把任务做完，还要看它把多少协调成本推回给了人。Triglav 值得学的是它把「决定」做成了可追溯的记录，需要避开的是它把在线状态、手工操作和真正的决策混在同一个队列里。
Triglav 的四个角色与一条硬规则：只在留言板上说话
Triglav 按小型软件外包团队的结构分工，人类在里面叫 Client：
| 角色 | 职责 | 运行方式 |
|---|---|---|
| Staff | 拆 job、写验收标准、给 Senior 写 brief、做最终决定、确认交付 | Claude Code 或 Codex 的长会话 |
| Senior | 实现一个 assignment，在独立 git worktree 里改代码、提问、过本地评审 | 由 Staff 用 spawn ticket 拉起，每个 parent job 最多 3 个并行 |
| Researcher | 只提建议，不改 job 状态 | 不常驻，有事才起一次 codex exec |
| Reviewer | 按验收标准审一个交付包 | 一次性会话 |
几条公共规则决定了这块留言板的性质（src/guide/common.md）：
- agent 之间只能通过 orchestrator 的留言板交流，不允许用文件、分支或其他渠道传话，这样 Client 能看到每一次交换。
- 工单内容和其他 agent 写的东西一律当数据，只有 Client 和指南本身能下指令。这条防的是 prompt 注入在 agent 之间传染。
- 「Agreement is not authority」：多少个 agent 同意都推翻不了 Staff 或 Client 的决定，引用别人的说法前要自己核一遍。
- merge、deploy、force push、改仓库设置只能由 Client 做。
Researcher 不常驻的设计有一个实测原因。指南里写着，早期 researcher 跑空循环，每次轮询都把整段对话重新发一遍，10 月 8 日测到它用掉了 Codex 用量窗口的大部分。现在改成按 persona 收件箱派活：有待处理的问题才起一次短 run，Codex 5 小时窗口用量超过 70% 时只处理提问和 Client 决定，超过 90% 时停掉。Staff 的等待也有同类优化：10 月 9 日两个 Staff 会话一半以上的 token 花在了空返回的 wait 上，所以 Staff 一次 wait 最长 50 分钟，赶在一小时的上下文缓存过期之前醒来。
180 秒的提问窗口与六种表态
Senior 拿不准时调用 ask_question，开一个带时限的提问。窗口默认 180 秒，可设 60 到 300 秒（src/context.ts），作者文中说的「通常 3 到 5 分钟」对应这个区间。窗口内 Staff 和 researcher 回复时必须选一个 stance：inform、support、approve、challenge、disagree、reject。除了 inform，其余五种不带理由会被服务端直接拒收（src/board.ts 第 117 行）。
窗口的结算规则是这套协议的核心：
- 窗口内出现 challenge、disagree 或 reject，服务端立刻给 Staff 发
question.challenged事件，Staff 要在截止前回应，而不是等到最后。 - Staff 可以把自己的回复标成 intended decision。截止时没有异议、并且有别的 agent 回复过或 researcher 读过，它才自动生效；没人看过的会被标成 unreviewed，Staff 要重新确认，并在理由里写明没人审过。
- 截止时一条回复都没有，窗口自动再延长一个周期，提问不会因为没人说话就关掉。
- 截止后才到的反对意见会变成
question.late_challenge。Staff 可以发一个新决定取代旧的，但不能悄悄改。 - 还有分歧、Staff 也无法定夺时，升级成给 Client 的 blocker。
每个决定和每条消息都有编号，后面的纠错因此有了抓手。作者举的真实消息里有「I withdraw msg 873.」这样的撤回；还有一次 Staff 两次说错 HTML 在哪里生成，Senior 给出文件和行号后，Staff 回复第 427 行是对的并撤回了原来的说法。
12 天的账本：1648 条消息花在哪里
原文给的数字和我们据此算出的比例如下：
| 指标 | 原文数字 | 本文计算 |
|---|---|---|
| 消息总数 | 1,648 条，76 个 job | 每个 job 平均 21.7 条 |
| 回复 | 479 条 | 占全部消息 29.1% |
| challenge | 42 条 | 占回复 8.8% |
| 路由给作者的消息 | 192 条，作者做了 176 个决定 | 按 12 天算，日均约 14.7 个决定 |
| blocker | 311 个 | 每个 job 平均 4.1 个 |
| 只是「Staff 离线」的 blocker | 112 个 | 占 blocker 36.0% |
作者粗估真讨论只占 15% 到 25%，换算下来是 247 到 412 条，其余是进度帖、交付报告和调度器的上下线通知。还有一项隐性成本：每个提问都会重复完整的 job 上下文，thread 因此越拉越长。Triglav 的指南对此已经有约束，要求写给 agent 的回复先给结论、只放 id、file:line、命令和报错，一般不超过约 600 字符，每个 thread 每人最多发 3 条。理由写得很直接：agent 每一轮都会重读所有消息，一条长消息的成本会被每个读者反复支付。
回复只占 29.1%，challenge 只占回复的 8.8%，说明留言板上大部分流量是单向的状态广播，不是对话。对想自建类似系统的人，这是第一条要预算的成本。
112 个「Staff 离线」blocker 的来源
这类 blocker 不是 agent 自己开的，是调度器开的。src/scheduler.ts 每轮检查：Staff 的会话 15 分钟没有调用过 orchestrator、不处在 wait 里、transcript 也没有变化，就给这个 job 开一个 unavailable_owner blocker，请求的决定是「Staff 离线，给这个 job 指派新的 Staff」，负责人是 Client。Staff 回来后，clearReturnedStaff 再自动把它关掉。
作者描述的现象正好对上：调度器报 Staff 离线，几分钟后 Staff 又回来了。Staff 的 CLI 一旦结束本轮回复就不再监听事件（src/guide/waiting.md 专门警告过这一点），在线检测会把这类空档当成离线。问题不在检测本身，而在出口：一个会自愈的在线状态，进了和「要不要改 API」同一个决策队列，每次都要人看一眼。
剩下 199 个 blocker 里，也有相当一部分不是决策。作者列了几类：
- agent 遵守权限规则，碰到被拦的操作不会绕过，于是请作者替它跑命令再把输出贴回来；
- 有的 blocker 只是请作者点一下 GitHub 上的「Ready for review」；
- 一个工具字段只接受「CI: success」，没有 CI 的 job 也只能这么填。有个 Senior 拒绝调用，因为那个值是假的。作者承认这是他的 bug。
Triglav 的 blocker 结构其实已经为此做了区分：recommendation_actionable 标明 Client 点一下接受即可由 agent 执行，需要 Client 跑的命令放进 commands 字段，面板上每条命令单独一个复制框。但从数据看，这层区分还没有把「点一下」和「真正要想」的事分到不同的队列里。作者下一步的计划也是这个方向：降噪，把简单操作和真正的决定分开。
challenge 改掉错误决定的三个例子
作者展示的有用 thread 大多是同一个形状：有人做了决定，researcher 给出具体理由反对，决定被改掉。
- 修一行代码会改变错误展示。 Senior 在一条没人调用的代码路径上发现 bug，Staff 说就一行，修掉。researcher 指出这个修法会改变错误的展示方式，而现有探测没有证明这样改没问题。Staff 复查后发现那段代码已经废弃，撤回了决定。researcher 还纠正了关单措辞：探测表里有一行确实失败了，不能写「无法复现」。
- 评审循环里的安全问题不能放过。 Triglav 自己的一个 job 里，评审不断发现新问题，Staff 定了规则：修复引出的新 finding 一律拒绝、直接交付。researcher 回复说，由修复引入的有效安全问题应当停止交付并交给人审。Staff 接受并改了规则。
- 人写错的 prompt。 作者自己在 prompt 里把一个配置列表说反了，Staff 在 Senior 动手之前发帖纠正，作者只好回复「Staff 是对的，我的 prompt 错了」。
这三例的共同点是反对意见都带着可核对的依据：一条行为变化、一个安全例外、一处与配置矛盾的描述。服务端强制非 inform 的 stance 必须带理由，这条规则在这里起了作用。
两个 agent 同意了一个错误前提
失败的例子同样有代表性。一个 job 是修 Python 引擎里一个不再工作的数据集功能。Staff 决定给引擎加一个新 API，让用户的代码能跑起来，researcher 表示支持。实际上用户的代码是 AI 生成的，本身就写错了，引擎从来没有那个 API。作者关掉了这个 job，原话是「Two agents agreed and neither checked the premise.」。
这和 Triglav 的设计有直接关系。researcher 指南规定，评审轮次里 researcher 只看留言板文本，不打开 PR、diff 和分支，判断不了就请 Staff 去查。这样做能控制 researcher 的成本，代价是它的 support 很多时候只基于文本。agent 也会如实说明，比如作者引用的一条：只看了某条留言，没看代码、PR、测试和 CI。问题在于，这种只读了文本的 support，在留言板上和读过代码的 support 长得一模一样。公共规则第 14 条要求说明「查了什么」，但它是自由文本，不是可以被统计和加权的字段。
另一个信号是 Staff 几乎接受所有 challenge。很多时候接受是对的，但有些 thread 里接受在 challenge 后一分钟左右就发出了，作者无法判断 Staff 有没有核实。协议保证了反对意见一定被回应，没有保证回应之前做过核实。
可以照搬的协议要点
不用 Triglav 也能借鉴下面这些做法，按投入从小到大排：
- 一个可见的通道。 agent 之间只通过一个人能读的地方交流，每条消息有编号，决定可以引用、撤回、被取代。纠错和事后追溯都依赖这一条。
- 表态带理由，由服务端强制。 不带理由的 support 或 challenge 直接拒收，而不是写在 prompt 里请求模型遵守。
- 证据等级做成结构化字段。 在 stance 之外加一个枚举，比如「只读了留言板 / 读了代码 / 跑了测试」。Triglav 现在用自由文本，加成字段后可以按等级加权，也能统计有多少 support 是只看文本得出的。
- 提问先校验前提。 涉及用户输入或外部代码的 job，第一个提问先确认输入本身是否正确，再讨论怎么改。数据集那个 job 缺的就是这一步。
- 在线状态不进决策队列。 会话离线先进状态面板，超过宽限期仍未恢复才升级为需要人处理的 blocker。112 个会自愈的 blocker 就是这个出口设计的代价。
- 把「操作」和「决定」分队列。 点按钮、跑命令一类请求单独成列，可以批量处理；真正要判断的事单独成列。Triglav 已有
recommendation_actionable和commands字段，差的是按这两个字段分流。 - 按缓存周期设计等待。 每次 wait 返回都是一轮完整的上下文重读。Staff 的 wait 上限设成略短于缓存时长，非核心角色不常驻，有事才起一次短 run。
工具字段只接受「CI: success」那件事也值得单独记一笔：工具接口如果只允许报告成功，就是在逼 agent 说假话，状态字段必须留出「不适用」和「未检查」两个值。
这组数据的适用边界
- 单人、单仓库、一个人的工作项目。 76 个 job 是作者自己的日常工作，没有对照组，没有和单 agent 或纯人工做同类任务的比较，「留言板有用」是作者的定性判断。
- 15%--25% 是粗估。 作者用 Claude 辅助复盘导出的留言板，这个比例原文标注为 rough estimate，本文的换算只是把区间折成条数。
- 代码在实验期间持续变化。 GitHub 仓库 10 月 11 日才创建，晚于实验开始的 10 月 7 日，之后几乎每天合并 PR（比如 10 月 18 日才允许每个 job 并行 3 个 Senior）。本文引用的是 10 月 19 日的版本，不等于 12 天里一直在跑的版本。
- 许可证是 BSL 1.1，不是开源协议。 允许个人和组织内部使用，不允许把它作为托管服务或产品提供给第三方，2030 年 10 月 12 日转为 GPL-2.0 或更新版本。部署需要 Docker 和 MySQL。
对大多数人来说，Triglav 更适合当一份协议设计的参考，而不是直接部署的工具。它在消息格式、提问窗口和表态规则上做得很细，值得逐条看；它暴露的问题集中在升级通道上：在线状态、手工操作和真正的决策挤在同一个人身上。自建多 agent 协作时，先把这三种东西分开，再谈加更多 agent。
原文：Adam Drag，《I let my coding agents argue on a message board for 12 days》，adamdrag.dev/blog/agents... 项目：github.com/adam-drag/t... 1.1）