背景与动机
多 Agent 协作的价值不是“同时开很多窗口”，而是把不同类型的工作隔离开：一个负责实现，一个负责审查，一个负责调研，一个负责验证。
如果所有任务都堆在同一个上下文里，长会话会变得混乱；如果拆得太碎，又会出现重复探索和结论不一致。关键是按职责拆分。
适合拆给多个 Agent 的场景
适合：
- 大型改动前的代码调研。
- 实现完成后的独立代码审查。
- 多个互不依赖的内容整理任务。
- 一个 Agent 写方案，另一个 Agent 验证风险。
不适合：
- 强依赖同一段未完成代码的并发修改。
- 需要连续产品判断的任务。
- 高风险命令或外部写入操作。
常见分工模型
1. 调研 Agent
只读代码和文档，不修改文件，输出：
- 相关文件。
- 现有模式。
- 可能风险。
- 推荐最小修改点。
2. 实现 Agent
根据已确认方案修改代码，输出：
- 修改文件。
- 实现说明。
- 验证命令。
- 未覆盖风险。
3. 审查 Agent
从代码审查角度看改动，优先找：
- 逻辑 bug。
- 回归风险。
- 缺失测试。
- 越界修改。
上下文交接要结构化
不要把整段聊天记录直接扔给下一个 Agent。更好的交接格式：
目标：已确认决定：不要做的事：涉及文件：当前状态：验证方式：剩余风险：这能减少后续 Agent 重新自由推断。
长任务中的一致性
长任务容易遇到上下文压缩。为了保持一致，需要维护一份“当前仍有效决定”：
- 当前目标。
- 已确认边界。
- 用户纠正过的误区。
- 本轮只做什么。
- 哪些文件不能碰。
每次继续执行前，先用这份清单校准，而不是重新解释需求。
常见陷阱
- 多个 Agent 同时改同一批文件，产生冲突。
- 审查 Agent 被实现过程说服，没有独立检查。
- 交接只说“继续做”，没有保留边界。
- 把并发当成加速手段，却增加了协调成本。
多 Agent 协作模板
调研 Agent：只读代码，输出涉及文件、现有模式和风险。
实现 Agent：只根据确认方案修改文件，运行验证。
审查 Agent：不改代码，只找 bug、越界修改和缺失测试。
汇总 Agent：整理最终变更、测试结果和剩余风险。一句话总结
多 Agent 协作的重点是职责隔离和结构化交接，而不是简单地并发执行更多任务。