多 Agent 系统

多 Agent 不是让多个模型角色互相聊天。它是一种并发与模块化架构：把可独立验证的子任务交给隔离工作单元，再由明确协议合并结果。若任务本身不可拆，增加 Agent 只会增加上下文复制、意见冲突和成本。

1. 什么时候值得拆分

适合多 Agent：

• 多个子任务真正独立，可并行执行；
• 每个子任务需要不同工具、权限或上下文；
• 单个上下文过大，按领域隔离能显著减少噪声；
• 结果能用测试、Schema 或证据独立验收。

不适合：每一步强依赖上一步、任务很小、共享状态频繁变化、结果主要依靠主观共识、没有可靠验收器。

先估算理论收益。三个各需 5 分钟的独立研究可以接近并行收益；三个持续互相等待的代码修改，协调成本可能大于节省的时间。

2. 常见拓扑

2.1 管理者—工作者

管理者拆任务、分配、验收和合并，工作者只看自己的最小上下文。适合研究、批量迁移和多模块审查。

2.2 流水线

一个 Agent 的结构化输出成为下一阶段输入，例如“研究 → 方案 → 实现 → 审查”。它便于职责隔离，但前序错误会向后传播，每个边界都要校验。

2.3 评审者或辩论

多个 Agent 独立给候选，再由评分器或人工选择。只在错误代价足以覆盖多倍成本时使用。让所有角色看见彼此答案后再“独立判断”，会产生锚定而非真正多样性。

3. 委派协议决定质量

工作单不能只有一句“研究数据库方案”。至少包含：

{
  "task_id": "db-options",
  "objective": "比较三种存储方案并给出推荐",
  "inputs": ["requirements:v4"],
  "constraints": ["monthly_budget<500", "region=cn"],
  "deliverable_schema": "decision-comparison:v2",
  "acceptance": ["covers_cost", "covers_recovery", "sources_attached"],
  "allowed_tools": ["read_requirements", "search_docs"],
  "deadline": "2026-09-08T12:00:00Z"
}

工作者输出结论、证据、假设、未解决问题和产物引用。明确“不做什么”能防止多个工作者同时修改共享文件。

4. 隔离写入，集中合并

多个 Agent 直接写同一工作区会发生覆盖和基于旧版本修改。推荐：

• 每个工作者使用独立分支、工作树、事务或草稿对象；
• 工作者只拥有自己子任务需要的路径和工具；
• 合并者检查基线版本、冲突和验收；
• 合并后运行端到端验证，而不是只相信各自测试。

共享黑板更适合写追加式事实与状态，不适合无锁修改同一个自由文本。记录需要版本号或 compare-and-swap，避免丢失更新。

5. 上下文隔离与传递

不要把完整主会话复制给所有工作者。每个工作者只收到目标、约束、必要输入和输出协议，这既降低成本，也减少错误假设传播。

跨 Agent 传递的是结构化产物和证据引用，而不是一句“我已经搞定了”。接收方必须能检查产物版本和验收结果。

6. 并行调度与依赖图

把任务表示为有向无环图：

需求冻结
├─ API 设计 ─┐
├─ 数据迁移 ─┼→ 集成实现 → 端到端测试
└─ 风险审查 ─┘

只有入度为零的节点进入就绪队列。每个节点设置并发上限、租约、超时和重试策略。工作者超时后，调度器先检查是否留下部分产物，再决定重派；写操作必须幂等。

7. 处理分歧

分歧不能靠“再多聊几轮”自动消失。先分类：事实分歧用来源和实验解决；约束理解分歧回到需求；价值取舍由明确决策者选择；实现分歧用基准测试或小型原型比较。

仲裁输入应隐藏作者身份，使用统一量表，并允许结论为“证据不足”。如果仲裁者与候选共享同一模型和上下文，错误可能高度相关，关键决策仍需外部验证。

8. 多 Agent 的预算与停止机制

全局预算必须覆盖子任务总和。管理者不能在每个工作者达到局部预算后无限创建新工作者。设置：最大并发、最大委派深度、最大工作单数量、全局费用、截止时间和重复任务检测。

工作者结束状态应是 completed、needs_input、failed_retryable 或 failed_terminal，而不是都返回自然语言“完成”。管理者只对通过验收的产物计为完成。

9. 评测多 Agent 系统

除最终成功率外，还要测：关键路径时长、并行效率、上下文复制成本、委派返工率、合并冲突率、重复劳动率、工作者结果采纳率和全局预算耗尽率。

做消融实验：同一任务分别用单 Agent、固定流水线和多 Agent 运行多次。只有当多 Agent 在成功率、时长或上下文隔离上带来稳定净收益，才保留这层复杂度。

10. 实施顺序

1. 先让单 Agent 在固定评测集上稳定完成任务；
2. 找到明确瓶颈：上下文、延迟、权限或专业能力；
3. 只拆出一个边界清楚、可独立验收的工作者；
4. 加入版本化产物、合并检查和全局预算；
5. 用消融评测证明收益后再增加角色。

多 Agent 的成熟标志不是角色数量，而是每次委派都有清晰契约，每个产物都可验证，每项并发都能解释其收益。