第 18 章：Multi-Agent System

本章导读

核心问题：什么时候需要 Multi-Agent，以及如何设计角色协作。

关键词：Coordinator、Subagent、Reviewer、Synthesizer、Finding、Budget

学习产出：把复杂 CI 失败分析拆成日志、代码、测试和评审多个 Agent。

1. 本章要解决什么问题

前面章节一直以单 Agent 为主。

但有些任务天然适合多个 Agent 协作。

例如：

深度技术调研；
多系统故障排查；
大型代码评审；
安全审计；
架构方案评估；
企业知识库研究；
复杂应用开发。

这些任务有几个共同特点：

路径开放
信息来源多
可以并行探索
需要多角度分析
单个上下文窗口难以容纳全部细节

这就是 Multi-Agent 的适用场景。

但 Multi-Agent 不是“多开几个模型”这么简单。

它需要：

任务分解；
角色设计；
上下文隔离；
消息协议；
结果汇总；
冲突处理；
成本控制；
可靠性工程。

本章核心观点是：

Multi-Agent 的价值在于并行探索、角色分工和上下文隔离，而不是简单堆叠多个模型。

2. 对应 Anthropic 文章

本章主要对应：

How we built our multi-agent research system

Anthropic 在文章中说明，Research 类任务很难预先写死固定路径。

研究过程往往是动态的：

发现线索
  ↓
调整方向
  ↓
深入某个来源
  ↓
发现新问题
  ↓
继续探索

这类任务适合 Agent。

而 Multi-Agent 的优势在于：

多个 subagent 拥有独立上下文窗口；
可以并行探索不同方向；
每个 subagent 只返回压缩结论；
lead agent 负责计划和综合；
形成更强的信息压缩能力。

Anthropic 提到：搜索的本质是压缩，从大量语料中提炼洞察。Subagent 正是通过并行探索和结果压缩来提升系统能力。

3. 什么时候需要 Multi-Agent

3.1 适合 Multi-Agent 的任务

适合场景：

子任务可以并行；
不同子任务需要不同工具或视角；
信息来源非常多；
单个上下文窗口难以容纳全部探索；
需要互相评审；
需要覆盖多个风险维度。

例子：

评估公司是否采用某个新框架：
- Agent A 研究技术成熟度
- Agent B 研究生态和社区
- Agent C 研究安全风险
- Agent D 研究迁移成本
- Reviewer 汇总和质疑

3.2 不适合 Multi-Agent 的任务

不适合场景：

简单问答；
固定流程；
强顺序依赖；
子任务无法独立；
成本敏感；
需要严格确定性；
单 Agent 足够完成。

如果任务本来可以用 Workflow 或单 Agent 解决，引入 Multi-Agent 只会增加复杂度。

4. Multi-Agent 的典型角色

4.1 Coordinator / Lead Agent

负责：

理解用户目标；
拆分任务；
分配子任务；
控制预算；
汇总结果；
决定是否继续探索；
输出最终答案。

Coordinator 不应该陷入所有细节。

它应关注计划和综合。

4.2 Planner Agent

负责任务分解。

输出：

子任务列表
每个子任务目标
需要的工具
预期输出格式
预算
停止条件

4.3 Research / Worker Agent

负责具体探索。

每个 Worker 有独立上下文。

它应输出：

finding
evidence
confidence
references
open_questions

4.4 Reviewer / Critic Agent

负责质疑和评审。

它不重复做研究，而是检查：

证据是否充分；
结论是否过度；
是否遗漏重要角度；
是否存在冲突；
是否需要继续探索。

4.5 Synthesizer Agent

负责综合多个 Worker 结果。

它需要处理：

去重；
冲突；
权重；
结构化输出；
引用来源。

5. Multi-Agent 的关键设计

5.1 上下文隔离

每个 Agent 应有自己的上下文窗口。

不要让所有 Agent 共享完整历史。

共享的应该是：

任务目标
子任务说明
必要输入
压缩结果
证据引用

5.2 输出格式标准化

Subagent 输出必须结构化。

例如：

{
  "finding": "...",
  "evidence": ["..."],
  "confidence": 0.82,
  "references": ["..."],
  "openQuestions": ["..."]
}

否则 Synthesizer 难以汇总。

5.3 成本控制

Multi-Agent 成本高。

必须控制：

subagent 数量；
每个 subagent 最大轮数；
每个 subagent 可用工具；
总 token 预算；
是否允许继续扩展；
何时停止。

5.4 可靠性与恢复

Anthropic 在 multi-agent 文章中强调，Agent 是 stateful 的，错误会累积。

所以 Multi-Agent 系统需要：

定期 checkpoint；
工具错误处理；
可恢复执行；
子任务失败降级；
调试 trace。

5.5 可观测性

需要记录：

Coordinator 为什么拆成这些任务；
每个 subagent 做了什么；
用了哪些工具；
发现了什么证据；
哪些结论被采纳；
哪些结论被拒绝；
最终答案如何合成。

6. 架构图 / 流程图

图 18-1 Multi-Agent Research 架构 这张图展示 Coordinator、Specialist Agents、Synthesizer 和 Reviewer 的协作关系。 Mermaid 源文件

6.1 Multi-Agent Research 架构

图 18-2 Multi-Agent Research 架构 Mermaid 源文件

6.2 多 Agent 代码评审

图 18-3 多 Agent 代码评审 Mermaid 源文件

6.3 成本控制

图 18-4 成本控制 Mermaid 源文件

7. Java / Spring Boot 落地方案

7.1 AgentRole

public enum AgentRole {
    COORDINATOR,
    PLANNER,
    RESEARCHER,
    CODER,
    REVIEWER,
    SYNTHESIZER,
    TESTER
}

7.2 AgentDefinition

public record AgentDefinition(
    String agentId,
    AgentRole role,
    String systemInstruction,
    Set<String> allowedTools,
    ContextScope contextScope,
    AgentBudget budget
) {}

7.3 MultiAgentTask

public record MultiAgentTask(
    String taskId,
    String objective,
    List<SubTask> subTasks,
    MultiAgentPolicy policy
) {}

7.4 SubTask

public record SubTask(
    String subTaskId,
    String objective,
    AgentRole assignedRole,
    List<ContextChunk> inputContext,
    OutputSchema expectedOutput
) {}

7.5 CoordinatorAgent

public interface CoordinatorAgent {
    MultiAgentTask plan(AgentTask task);
    FinalAnswer synthesize(List<SubTaskResult> results);
}

7.6 AgentMessageBus

public interface AgentMessageBus {
    void publish(AgentMessage message);
    List<AgentMessage> poll(String agentId);
}

8. 企业案例：技术选型研究

任务：

评估是否采用 LangGraph 构建企业 Agent Runtime。

分工：

Agent	子任务
Planner	拆分研究维度
Researcher A	研究功能能力
Researcher B	研究生产案例
Researcher C	研究与 Java/Spring 集成成本
Security Reviewer	检查安全和合规风险
Synthesizer	汇总建议

最终输出应包含：

推荐结论；
证据；
风险；
替代方案；
适用条件；
不确定性。

9. 常见误区

9.1 为了高级而 Multi-Agent

Multi-Agent 成本高，只有任务确实需要并行探索和角色分工时才值得。

9.2 所有 Agent 共享上下文

这会破坏独立性并导致上下文污染。

9.3 没有 Coordinator

没有协调者，多个 Agent 的结果很难形成一致输出。

9.4 没有 Reviewer

多 Agent 不自动保证正确，需要评审和质疑。

9.5 没有预算控制

Multi-Agent 很容易成本失控。

10. 贯穿案例：CI 失败分析 Agent

复杂 CI 失败可以扩展为 Multi-Agent 分析。

例如：

CoordinatorAgent：拆分任务并汇总结果
LogAnalysisAgent：分析 CI 日志和失败类型
CodeAnalysisAgent：分析 Git Diff 和相关代码
TestAnalysisAgent：分析失败测试和测试约定
ReviewerAgent：检查结论是否有证据

对于 build #4312，LogAnalysisAgent 可能输出：

失败类型：test failure
失败测试：OrderServiceTest.shouldApprovePendingReviewOrder
异常：transition PENDING_REVIEW -> APPROVED is not allowed

CodeAnalysisAgent 可能输出：

PR #882 新增 OrderStatus.PENDING_REVIEW，但 OrderStateMachine.allowedTransitions 未更新。

ReviewerAgent 则检查两者是否有共同证据，并确认最终报告不能过度推断。

这个案例说明 Multi-Agent 的价值在于并行探索和角色分工，而不是简单多调用几次模型。

11. 本章小结

本章讨论 Multi-Agent System。

核心结论：

Multi-Agent 适合开放、复杂、可并行探索的任务。
Subagent 的价值在于独立上下文和并行压缩。
Coordinator 负责计划、预算和综合。
Reviewer / Critic 能提高结论质量。
Multi-Agent 必须有上下文隔离、结构化输出、成本控制和可观测性。

一句话总结：

Multi-Agent 不是更多模型，而是把复杂任务组织成可并行、可隔离、可综合的协作系统。

12. 实践任务

任务 1：设计四角色研究系统

为一个技术调研任务设计 Planner、Researcher、Reviewer、Synthesizer。

任务 2：定义 Subagent 输出 JSON

包含 finding、evidence、confidence、references、openQuestions。

任务 3：预算控制

为每个 subagent 设置最大工具调用次数和最大 token。

任务 4：多 Agent 代码评审

为 PR Review 设计 SecurityAgent、TestAgent、PerformanceAgent 和 Synthesizer。