Agent 架构与协作模式

真正决定一个 Agent 系统质量的，并不是里面有几个模型，而是三个问题：谁决定下一步、状态如何流动、结果由谁负责。

这篇文章尝试从工程视角梳理清楚：

单 Agent 常见的运行架构；
多 Agent 到底有哪些协作模式；
Workflow 与 Agent 应该如何组合；
什么时候值得上多 Agent，什么时候反而应该保持简单。

一、先把 Agent 说清楚

普通 LLM 应用通常是一次输入、一次输出：

用户问题 → 模型 → 答案

Agent 则多了一个面向环境的执行闭环：

flowchart LR
    U[用户目标] --> A[Agent Controller]
    A --> M[模型推理与决策]
    M --> T[调用工具]
    T --> E[外部环境]
    E --> O[Observation]
    O --> A
    A --> R[完成结果]

模型不只是生成文本，还要根据工具返回、环境状态和任务进度决定下一步行动。这也是 ReAct 的核心思想：把 Reasoning、Action 和 Observation 交错起来，让模型能够依据外部反馈修正行为，而不是只靠内部知识一路“想到底”。

因此，一个能稳定工作的 Agent，通常至少包含以下部分：

组件	主要职责
Model	理解目标、推理并选择动作
Instructions	定义角色、边界、规则和输出要求
Tools / Skills	搜索、读写文件、数据库、API、代码执行等能力
Context	当前任务需要的上下文
Memory	跨步骤或跨会话保存信息
State	任务计划、步骤状态、产物、错误和重试记录
Guardrail	输入、工具调用和输出安全检查
Runtime	超时、重试、并发、Checkpoint、恢复和观测

这里有一个很重要的判断：RAG、Memory、MCP 和 Tool Calling 都不是完整的 Agent 架构，它们是 Agent 的能力组件。

二、比“单 Agent / 多 Agent”更重要的分界线

在讨论 Agent 数量之前，应该先问：流程是由代码决定，还是由模型决定？

flowchart TB
    S[Agentic System]
    S --> W[Workflow：代码控制流程]
    S --> G[Agent：模型动态决定下一步]

    W --> W1[固定顺序]
    W --> W2[DAG 依赖]
    W --> W3[条件分支]
    W --> W4[固定评审循环]

    G --> G1[自主选择工具]
    G --> G2[动态拆解任务]
    G --> G3[根据反馈改计划]
    G --> G4[决定是否委派]

Workflow 的优势是可预测、可测试、容易恢复；Agent 的优势是灵活，能够处理事先无法穷举的情况。

例如，“先拉取财务数据，再计算指标，最后生成固定格式报告”天然适合 Workflow；“调查这家公司最近出现了什么风险，并自行决定从哪里开始查”更适合动态 Agent。

两者并不冲突。生产系统经常用 Workflow 固定主干，让 Agent 只在需要判断的节点内发挥自主性。

三、单 Agent 的五种常见架构

1. Tool Calling Agent：最小可用形态

模型根据用户意图选择工具，拿到结果后生成回答。

sequenceDiagram
    participant U as 用户
    participant A as Agent
    participant T as Tool
    U->>A: 查询订单为什么还没发货
    A->>T: get_order_status(orderId)
    T-->>A: 已付款，仓库缺货
    A-->>U: 解释状态并给出处理建议

它适合客服查询、知识问答和简单业务操作。系统短、成本低，也容易定位问题。

但随着工具数量增加，模型可能选错工具、填错参数，或者在相似工具之间反复尝试。因此工具描述、参数 Schema、权限和错误返回格式往往比提示词更重要。

2. ReAct：边思考、边行动、边修正

ReAct Agent 不一定提前知道完整路径，而是在循环中逐步推进：

分析当前状态 → 选择动作 → 调用工具 → 观察结果 → 调整下一步

它适合搜索研究、网页操作、故障诊断等环境反馈较多的任务。

ReAct 的主要问题是容易走远：搜索越搜越多、失败后不断尝试、上下文不断膨胀。工程上需要最大步骤数、工具预算、总超时和清晰的终止条件。

3. Plan-and-Execute：把计划与执行拆开

flowchart LR
    U[用户目标] --> P[Planner]
    P --> L[任务清单]
    L --> X[Executor]
    X --> C{完成了吗？}
    C -- 否，局部调整 --> P
    C -- 是 --> R[最终结果]

它更适合长任务。计划显式化之后，系统能够显示进度，也更容易暂停和恢复。

但 Planner 不能在每次遇到小问题时都推翻原计划。否则系统会在“规划—失败—重新规划”之间来回震荡。比较稳妥的做法是保留已完成节点，只修改真正失效的部分。

4. Reflection：执行之后再检查

初次执行 → 结果检查 → 生成反馈 → 有针对性地重试

Reflection 适合代码修复、文案优化、方案打磨，因为这些任务通常存在可理解的反馈。

但“让模型再想一遍”并不是可靠验证。只有当反馈来自测试结果、业务规则、引用证据或明确评分标准时，反思才真正有价值。

5. 单 Agent + 确定性状态机

这是经常被忽视、却非常实用的方案：系统只有一个 Agent 身份，但运行时限制了它可以进入哪些状态。

待理解 → 待确认 → 执行中 → 待验证 → 已完成 / 已阻塞

它保留了单 Agent 的上下文连续性，又获得 Workflow 的可控性。对中等复杂度的业务系统，往往比直接搭建一个 Agent 团队更合适。

四、多 Agent 有哪些协作模式？

多 Agent 不是一个固定架构，而是一组不同的通信拓扑和责任分配方式。

1. Router：先判断该找谁

flowchart LR
    U[用户请求] --> R[Router]
    R -->|退款问题| F[财务 Agent]
    R -->|系统故障| T[技术 Agent]
    R -->|产品咨询| P[产品 Agent]

Router 解决的是“应该由谁处理”。通常只有一个下游 Agent 真正执行任务，所以它更像智能分流，而不是多个 Agent 共同工作。

它适合客服、领域问答和模型分级：简单问题交给低成本模型，复杂任务交给能力更强的 Agent。

2. Supervisor-Worker：主管分工，专家执行

flowchart TB
    U[用户目标] --> S[Supervisor]
    S --> W1[搜索 Agent]
    S --> W2[数据分析 Agent]
    S --> W3[行业研究 Agent]
    W1 --> S
    W2 --> S
    W3 --> S
    S --> R[汇总、校验与回答]

Supervisor 负责理解目标、拆解任务、选择 Worker、汇总产物和判断是否结束；Worker 只负责边界清楚的子任务。

这也是当前复杂研究和编码任务中最常见的模式之一。OpenAI Agents SDK 将其归入“Agents as tools”：主管 Agent 保留会话控制权，把专家 Agent 当作能力调用。Anthropic 的 Research 系统也使用 Lead Agent 协调多个并行 Subagents，再由专门的 Citation Agent 处理引用。

它的弱点同样明显：Supervisor 既可能成为性能瓶颈，也可能错误拆解任务。Worker 做得再好，如果主管遗漏了一个关键方向，最终答案仍然不完整。

3. Pipeline / DAG：像流水线一样协作

flowchart LR
    D[数据 Agent] --> A[分析 Agent]
    A --> W[写作 Agent]
    W --> V[审核 Agent]
    V --> O[交付物]

如果任务步骤和依赖关系在运行前就能确定，应优先考虑 Pipeline 或 DAG，而不是让 Agent 在群聊里自己商量。

它适合报告生成、数据加工、合同审核、审批等流程。每个节点都应该产生可持久化的中间产物，失败后从对应节点恢复，而不是从头重跑。

4. Parallel / Fan-out–Fan-in：并行后汇总

flowchart LR
    I[输入] --> F[任务分发]
    F --> A1[基本面分析]
    F --> A2[技术面分析]
    F --> A3[新闻舆情分析]
    A1 --> M[Aggregator]
    A2 --> M
    A3 --> M
    M --> O[综合结论]

并行有两种典型目的：

将不同子问题分给不同 Agent，提升覆盖度和速度；
让多个 Agent 独立处理同一问题，再投票或交给 Judge，提升答案多样性。

它只适合相对独立的任务。多个 Agent 如果同时修改同一份文件、同一条数据库记录或同一个外部对象，就必须额外处理锁、事务、幂等和冲突合并。

5. Handoff：把控制权交给更合适的人

flowchart LR
    T[Triage Agent] -->|需要技术诊断| A[技术 Agent]
    A -->|涉及退款| B[财务 Agent]
    B -->|需要人工裁决| H[人工客服]

Handoff 和 Supervisor 的区别在于：交接之后，接收方成为新的主 Agent，原 Agent 不再负责汇总。

它适合需求在对话过程中逐渐清晰的客服或跨领域任务。工程上必须限制最大交接次数，并记录当前责任人、交接原因和上下文摘要，否则很容易出现 Agent 之间“踢皮球”。

6. Group Chat / Blackboard：让多个角色共同讨论

Group Chat 中，多个 Agent 共享一段对话，由 Chat Manager 决定下一位发言者和终止条件。

flowchart TB
    M[Chat Manager]
    C[(共享上下文 / Blackboard)]
    A[架构 Agent] <--> C
    B[安全 Agent] <--> C
    D[业务 Agent] <--> C
    M --> A
    M --> B
    M --> D

它适合头脑风暴、方案评审和多方权衡。但自由讨论很昂贵：每个 Agent 都需要反复读取不断增长的聊天记录，而且“大家达成一致”并不等于结论正确。

在工程系统中，Blackboard 往往比纯群聊更稳。Agent 不必持续互发自然语言消息，只需要从共享任务板读取结构化状态，并提交证据、决策和产物。

7. Maker-Checker：一个产出，一个把关

flowchart LR
    M[Maker] --> D[候选结果]
    D --> C[Checker]
    C -->|不通过：结构化反馈| M
    C -->|通过| O[交付]

它也叫 Evaluator-Optimizer、Generator-Verifier 或 Critic Loop。

Maker-Checker 不是完整的任务拓扑，而是一种可以叠加在其他架构上的质量机制。要让 Checker 真正有效，它必须拥有明确标准，例如：

测试是否通过；
数字能否由原始数据复算；
引用是否支持对应结论；
输出是否满足 Schema；
是否触发合规规则。

如果 Checker 只能凭感觉评价文本，它很容易和 Maker 一起产生同样的幻觉。

8. Debate / Ensemble：用分歧换取更全面的判断

多个 Agent 独立给出观点，再彼此质疑，最后投票或由 Judge 决策。

它适合高不确定性分析和方案比较，但不要把“多数票”当成事实校验。多个 Agent 可能使用同一个基础模型、同一批上下文，因此会共享偏差。外部证据、真实执行结果和人工判断仍然不可替代。

9. Hierarchical / Hybrid：大型系统的最终形态

flowchart TB
    G[总协调 Agent]
    G --> R[研究 Supervisor]
    G --> E[工程 Supervisor]
    R --> R1[搜索 Agent]
    R --> R2[数据 Agent]
    E --> E1[开发 Agent]
    E --> E2[测试 Agent]

大型 Agent 系统通常不会只使用一种模式，而是：顶层集中管理、局部并行执行、节点间通过产物交接，关键步骤增加 Checker 和人工审批。

这种架构能力强，但管理开销也会快速增长。如果职责、权限和中间产物没有定义清楚，它只是把一个难以调试的 Agent 变成了一群难以调试的 Agent。

五、一个更现实的投研 Agent 组合

以“生成一份有证据支撑的公司研究报告”为例，比较合理的架构不是让几个 Agent 在群里自由讨论，而是固定主流程，只在可以并行的地方展开。

flowchart TB
    U[用户研究目标] --> R{Router}
    R -->|简单问答| Q[单 Agent ReAct]
    R -->|正式报告| P[锁定研究口径与计划]

    P --> D1[财务数据 Agent]
    P --> D2[行业数据 Agent]
    P --> D3[新闻事件 Agent]

    D1 --> E[(Evidence Store)]
    D2 --> E
    D3 --> E

    E --> A1[基本面研究 Agent]
    E --> A2[行业研究 Agent]
    E --> A3[风险研究 Agent]

    A1 --> S[综合分析 Agent]
    A2 --> S
    A3 --> S

    S --> V{事实与数字复核}
    V -->|不通过| E
    V -->|通过| W[写作 Agent]
    W --> H{人工审批}
    H --> O[报告交付]

这里的关键不是角色名字，而是数据契约。数据 Agent 提交的证据至少要包含：

{
  "metric": "营业收入",
  "value": 128.4,
  "unit": "亿元",
  "definition": "公司合并口径营业收入",
  "source_url": "https://example.com/report",
  "data_as_of": "2026-06-30",
  "fetched_at": "2026-09-27T10:00:00+08:00"
}

研究 Agent 只能基于证据层做分析；写作 Agent 不能凭记忆补数字；Reviewer 必须能重新计算和追踪来源。这样，多 Agent 带来的才是责任分离和可验证性，而不仅仅是更多文本。

六、多 Agent 为什么不一定更好

多 Agent 会引入一笔经常被低估的“协作税”：

每次委派都要重新描述目标和上下文；
不同 Agent 之间会重复搜索和重复推理；
上游错误可能被下游当成事实继续放大；
聚合器需要处理冲突、遗漏和格式不一致；
调用次数、Token、延迟和失败点都会增加；
责任边界不清时，很难判断最终错误来自哪里。

Google Research 在 2026 年的一项受控实验中比较了单 Agent、独立并行、集中式、去中心化和混合式架构。实验显示：在可并行的金融分析任务上，集中式多 Agent 相对单 Agent 提升约 80.9%；但在严格顺序的规划任务上，所有多 Agent 方案都下降了 39%—70%。

这些数字不能直接外推到所有业务，但它说明了一个很朴素的原则：

多 Agent 的收益来自任务可分解、可并行和能力互补，而不是 Agent 数量本身。

七、怎样选择架构

flowchart TD
    A[拿到一个 Agent 需求] --> B{一次模型调用或少量工具能完成吗？}
    B -- 是 --> C[普通 LLM / 单 Agent Tool Calling]
    B -- 否 --> D{流程是否稳定且依赖明确？}
    D -- 是 --> E[Workflow / Pipeline / DAG]
    D -- 否 --> F{子任务能否独立并行？}
    F -- 是 --> G[Supervisor + Parallel Workers]
    F -- 否 --> H{是否需要动态切换专家？}
    H -- 是 --> I[Router / Handoff]
    H -- 否 --> J[单 Agent Plan-and-Execute]
    E --> K{是否需要独立质量检查？}
    G --> K
    I --> K
    J --> K
    K -- 是 --> L[增加 Maker-Checker / 人工审批]
    K -- 否 --> M[保持当前最小架构]

可以进一步总结为：

任务特征	优先考虑
简单问答、工具较少	单 Agent Tool Calling
动态搜索、网页交互	单 Agent ReAct
长任务但推理高度连续	Plan-and-Execute
流程固定、强调恢复和审计	Workflow / DAG
多个独立研究方向	Supervisor + Parallel Workers
处理者需随上下文动态变化	Router / Handoff
需要多角度方案评审	Parallel + Judge / Group Chat
存在明确验收标准	Maker-Checker
高风险外部写操作	确定性 Workflow + Guardrail + 人工审批

八、生产级多 Agent 的最低配置

真正落地时，每个 Agent 至少应定义清楚以下内容：

1. 责任

它负责什么；
不负责什么；
谁对最终结果负责；
什么情况下必须升级给人。

2. 能力与权限

允许使用哪些工具；
哪些工具只读；
哪些操作需要审批；
是否可以继续委派其他 Agent。

3. 输入输出契约

输入 Schema；
输出 Schema；
必须包含的证据和元数据；
无数据、超时和失败如何表达。

4. 状态与恢复

每个节点的执行状态；
Checkpoint；
重试次数；
幂等键；
外部写入结果未知时如何核验。

5. 终止条件

最大步骤数；
最大 Token 或成本；
总时长和无事件超时；
Handoff 和评审循环上限；
“完成”需要满足的验收条件。

6. 可观测与评估

每次模型调用和工具调用的 Trace；
任务成功率；
事实错误率；
证据完整度；
人工介入率；
平均延迟和成本；
重试、重复工作与错误传播情况。

没有这些能力，多 Agent 更像一场无法复盘的线上会议；具备这些能力之后，它才开始接近一个可以交付业务结果的协作系统。

结语

Agent 架构设计的目标，不是把系统做得像一家公司，也不是给每项工作都安排一个“智能员工”。

真正值得追求的是：该确定的地方足够确定，该灵活的地方保留灵活；让每个决策有依据，每次行动可追踪，每个产物可验证，每次失败能够恢复。

如果一个单 Agent 加三个工具已经能稳定完成任务，就没有必要搭一个 Agent 团队。如果任务确实跨越多个上下文、专业领域和权限边界，那么多 Agent 才开始具有工程价值。

最后可以用一句话概括：

从最简单的架构开始，只有当任务结构证明需要协作时，才增加 Agent；增加的不是角色数量，而是清晰的责任、契约和验证机制。