管理多个 AI Coding Agent 最稳妥的方式，是协调交付物，而不是协调聊天窗口。给每个 Agent 一个边界清楚的结果，隔离可能重叠的写入，要求它留下证据，并让项目层保留唯一的决策与下一步事实。

如果你每天的主要工作变成“记住哪个终端正在做什么”，系统只是把协调负担从 Agent 转回了你。

从可以命名的工作开始

每个活动任务都需要：

  • 具体结果；
  • 明确负责人；
  • 授权范围；
  • 依赖和阻塞；
  • 完成证据；
  • 稳定身份。

“右边终端里的第三个 Agent”不是稳定身份；“修复 Issue 184 的上手验证”才是。

OpenAI 也描述过相似的上限：工程师手工管理多个交互式 Agent 时，超过大约三到五个会话，注意力切换就开始变得痛苦。其编排实践因此从会话和 PR 转向交付物及依赖关系：Symphony。

只并行真正独立的工作

适合并行的任务拥有不同输出：

  • 一个 Agent 调研最新 API 合同；
  • 一个 Agent 只读审计无障碍问题；
  • 一个 Agent 实现隔离组件；
  • 一个 Agent 验证已经完成的 diff。

不适合并行的是：让多个 Agent 同时修改相同文件，或替你决定同一个产品边界。只要人类需要重新调和相互冲突的假设，并行速度就会消失。

多个 Agent 并发写入时，应使用 worktree 或隔离环境。例如 Codex app 使用独立线程和 worktree，让不同任务不共享一份可变工作副本：Introducing the Codex app。

把交付与复核分开

第一套实用的多 Agent 模式是顺序协作：

Builder 实施 → Reviewer 独立查证 → Builder 修正

Reviewer 应读取用户原始目标、真实 diff 和验证结果，而不只是 Builder 的总结。除非已经明确文件冲突和最终责任，否则 Reviewer 保持只读。

以下任务特别值得独立复核：

  • 公共合同；
  • 登录与权限；
  • 生成后的脚本；
  • 面向用户的文案和界面；
  • 迁移与发布。

项目只保留一份事实

每种 Coding Agent 都可以保留自己的聊天历史，但项目仍然需要一份共享记录：

  • 当前路线图结果；
  • 已接受决策；
  • 活动任务；
  • 精确版本或提交；
  • 验证证据；
  • 剩余缺口。

把这些事实以所有 Agent 都能读取的形式保存在项目旁边。不要让某个供应商的私有会话记忆成为跨工具权威。

给注意力设预算

并非每项任务都值得调用多个 Agent。只有漏掉错误的成本高于协调成本时，才增加 Reviewer。

一个 Agent 足够处理：

  • 小型文档修正；
  • 低风险聚焦重构；
  • 证据清晰的只读问题。

Builder 加 Reviewer 适合：

  • 普通代码与 UI 改动；
  • 即将发布的内容；
  • 共享配置。

Planner、Builder、Verifier 适合：

  • 跨模块改动；
  • 生产数据；
  • 权限；
  • 发布；
  • 不可逆动作。

简洁的控制面

每个活动结果只需展示：

  • 正在做：本轮尝试什么。
  • 状态：排队、执行、验证、阻塞或完成。
  • 证据：diff、测试、页面或运行结果。
  • 下一步：下一个安全动作。
  • 需要你：只有系统无法替你做的决策或授权。

用户不应该管理内部路由、工具调用、角色矩阵或重试状态。

危险信号

  • 两个 Agent 可以同时修改同一份权威。
  • Reviewer 只读另一个 Agent 的结论。
  • “完成”没有最终消费者证据。
  • 每次失败都新开会话，而不是续接同一个任务。
  • 用户必须手工翻译不同 Agent 的历史。
  • Agent 数量增加，但发布结果没有增加。

核心原则

多 Agent 协作成立的前提，是项目掌握计划、证据和交接。Agent 是围绕耐久结果工作的可替换执行者，而不是一组需要用户手工同步的独立项目。