Agent 架构盘点与选型分析

单 Agent 的常见架构

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、权限和错误返回格式往往比提示词更重要。

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

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

flowchart LR
    A[用户请求] --> B[Reason<br/>推理]
    B --> C[Act<br/>工具调用]
    C --> D[Observation<br/>结果观察]
    D --> B
    B -->|任务完成| E[Final Answer]

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

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

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

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

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

架构缺点：初始计划可能有误；重规划容易造成重复工作。比较稳妥的做法是保留已完成节点，只修改真正失效的部分。

Reflection：执行之后再检查

Reflection 模式是在 Agent 执行循环中加入“结果评估和失败复盘”，让 Agent 能够根据测试、规则或环境反馈不断修正自己的行为。

flowchart LR
    A["生成结果"] --> B["执行与验证"]
    B --> C{"是否通过？"}
    C -->|通过| D["最终输出"]
    C -->|未通过| E["分析失败原因"]
    E --> F["生成改进策略"]
    F --> A

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

架构缺点：没有可靠反馈时容易“空想式修改”。只有当反馈来自测试结果、业务规则、引用证据或明确评分标准时，反思才真正有价值。

确定性状态机

系统只有一个 Agent 身份，但运行时限制了它可以进入哪些状态。

sequenceDiagram
    participant U as 用户
    participant S as 状态机
    participant A as 同一个 Agent
    U->>S: 生成报告
    S->>A: 当前状态：收集资料
    A-->>S: 返回资料和来源
    S->>S: 检查资料是否齐全
    S->>A: 当前状态：撰写报告
    A-->>S: 返回报告草稿
    S->>S: 切换到验证状态
    S->>A: 当前状态：验证报告
    A-->>S: 返回验证结果
    S-->>U: 验证通过，交付报告

适用场景：它保留了单 Agent 的上下文连续性，又获得 Workflow 的可控性。适合报告、审批等步骤稳定、需要审计和恢复的流程

架构缺点：状态机的步骤由开发者预先写在代码里，流程变化需要改状态与转移规则，不如Plan-and-Execute每次动态生成灵活

多 Agent 协作模式

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

Router：先判断该找谁

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

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

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

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 做得再好，如果主管遗漏了一个关键方向，最终答案仍然不完整。

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

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

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

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

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 如果同时修改同一份文件、同一条数据库记录或同一个外部对象，就必须额外处理锁、事务、幂等和冲突合并。

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

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

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

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

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 不必持续互发自然语言消息，只需要从共享任务板读取结构化状态，并提交证据、决策和产物。

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 一起产生同样的幻觉。

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 会引入一笔经常被低估的“协作税”：

每次委派都要重新描述目标和上下文；
不同 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 + 人工审批