多智能体协作：从一个大脑到一支团队

系列：ToyAgent 智能体知识库 12/26

一句话核心：规划者拆任务，研究员找素材，写手出内容，审查员把关——多智能体协作没有魔法，每个角色都是同一个模型换了份系统提示词，区别只在消息流的结构。

为什么需要

什么时候该把一个 Agent 拆成一支团队？三个信号：

上下文装不下：一个 Agent 要同时装下所有领域的提示词、工具与中间产物，上下文窗口被无关信息挤爆。
职责混杂：既当研究员又当审查员，自己查自己审，容易"放水"——产出自查的独立性天然不足。
并行需求：多个子任务互不依赖，可以同时执行，单 Agent 串行白白浪费时间。

核心机制：一条流水线

最经典的结构是四角色流水线：

规划者 Planner → 研究员 Researcher → 写手 Writer → 审查员 Reviewer → 汇总交付

// 每个角色 = 同一个 ChatModel + 不同的系统提示词
String plan = model.chat(List.of(Message.system("""
        你是规划者（Planner）。把任务拆解为三个角色的执行计划：
        {"plan": [{"role": "研究员", "task": "..."},
                  {"role": "写手",   "task": "..."},
                  {"role": "审查员", "task": "..."}]}
        """), Message.user(input)));

// 上游产出作为下游输入 —— 消息在角色间流动
String notes = model.chat(List.of(
        Message.system("你是研究员，输出 3 条以内研究要点。"),
        Message.user(input)));

String draft = model.chat(List.of(
        Message.system("你是写手。基于研究笔记写短文。\n笔记: " + notes),
        Message.user(input)));

// 审查员可以打回 → 触发修改循环，直到通过或达到轮次上限

理解这段骨架的关键不是代码，而是一个观念转变：设计多 Agent 系统 = 设计"谁在什么时刻看见什么信息"。研究员只看原始任务，写手只看研究笔记（不看用户的原话 clutter），审查员只看成稿——上下文的裁剪与传递才是协作的全部秘密。

举例

模拟对话轨迹——任务："写一篇 500 字的向量数据库选型短文"：

[规划者] 输出结构化计划：
  {"plan": [
    {"role": "研究员", "task": "对比 Milvus/ES/pgvector 的定位与适用场景"},
    {"role": "写手",   "task": "基于研究笔记写 500 字选型短文"},
    {"role": "审查员", "task": "核查结论是否有依据、篇幅是否达标"}]}

[研究员] 只收到自己的 task（看不到写手的存在）：
  "① Milvus：独立分布式向量库，超大规模首选；② pgvector：
   已有 PostgreSQL 团队零新增组件；③ ES：兼顾关键词检索……"

[写手] 只收到笔记 + 篇幅要求：
  产出 480 字短文，三个选型结论各带一句适用条件

[审查员] 收到成稿：
  "结论均有笔记支撑；篇幅 480 字达标 → 通过 ✓"

[汇总] 终稿交付用户

注意每一步的角色只看见自己该看的——写手没被原始对话噪音干扰，审查员没被"这是我自己团队写的"心态影响。如果打回，写手收到的是具体的修改意见而不是全文重来。

四角色流水线与审查打回循环：

graph LR
    U["用户任务"] --> P["规划者 Planner"]
    P -->|执行计划| RS["研究员 Researcher"]
    RS -->|研究笔记| W["写手 Writer"]
    W -->|成稿| RV["审查员 Reviewer"]
    RV -->|打回修改意见| W
    RV -->|通过| D["汇总交付用户"]

图示：上游产出作为下游输入单向流动，审查员是唯一带回流边的角色——打回触发修改循环，通过则汇总交付。

三种经典协作模式：

模式	结构	适用
流水线	顺序传递，单向	内容生产、报告生成
主管-工人	主管动态分派、汇总	任务边界不确定的调研
辩论/评审	多 Agent 互审博弈	高可靠性要求的结论

LangChain4j/Spring 视角：生产实现里每个角色是一个独立的 AiService 或 Agent 实例（不同 system prompt、不同工具集、不同模型档位——研究员用便宜快模型，写手用强模型），编排层是一个普通的状态机/方法调用链，审查打回就是一次 goto 之前的 while 循环。

面试考点

多智能体的本质是什么？ 同一个模型 + 不同的系统提示词 + 结构化的消息流。协作智能不是模型突然变强，而是上下文裁剪与职责隔离带来的行为差异。
流水线、主管-工人、辩论各适用什么？ 流水线适合边界清晰的顺序任务；主管-工人适合任务需要动态拆分的调研；辩论/评审用对抗换可靠性。
什么时候不该上多智能体？ 能用单 Agent + 好提示词解决的，不要上多 Agent——每加一个角色，延迟与 Token 成本线性上涨，还引入新的失败面（某角色输出格式错，下游全崩）。

生产化路径

角色即配置：角色定义（system prompt、工具白名单、模型档位）做成可配置数据而非硬编码，新角色上线不改编排代码。
消息契约结构化：角色间传递用 JSON Schema 约束（如 planner 必须输出合法 plan 数组），下游入口做校验 + 重试，防止格式漂移打断流水线。
审查打回要有上限：修改循环设最大轮次（如 2 次），超限降级为"带审查意见交付"，避免两个 Agent 互相打回无限空转烧 token。
跨系统协作上 A2A：当角色分布在不同系统/厂商时，需要 Agent 间协议（能力卡片 + 任务协商），MCP 管工具，A2A 管 Agent。
并行化：无依赖的研究子任务并行派发（线程池或子代理），流水线总耗时从"各步之和"降到"最长一步"。