多智能体（Multi-Agent）架构选型：四种模式，一张图看懂
多智能体（Multi-Agent）架构选型：四种模式，一张图看懂
摘要（先看结论）
多智能体不是“更高级”，而是用更高的系统复杂度换取：上下文隔离、并行化、分工协作、长流程可控。
- 仍然能用“单 Agent + 好工具”解决：不要上多智能体
- 需要强控制权 + 上下文隔离：选 Subagents（主-子集中编排）
- 需要单 Agent 多专业化且保持交互简单：选 Skills（按需加载）
- 需要多阶段顺序流程（每阶段职责清晰）：选 Handoffs（状态驱动交接）
- 需要多领域并行查询 + 合成答案：选 Router（路由分发 + 汇总）
一句话口诀：并行找 Router，顺序走 Handoffs，强控用 Subagents，轻量用 Skills。
先把三个词说清楚：Context / State / Tools
- Context：模型每次调用能“看到”的输入（system prompt + history + reference），天然会变长、会漂移、会浪费 Token
- State：系统保存的结构化进度（通常是 JSON/DB），描述“任务进行到哪了、已确认什么、下一步做什么”
- Tools：确定性动作（查库/下单/发邮件/运行脚本），应该具备幂等、超时、错误码与可观测
多智能体的工程价值，本质是把：
- “靠模型自己从上下文里悟出来该做什么”
- 变成
- “靠状态与契约决定下一步、靠工具做确定性动作”
什么时候需要从单 Agent 升级
- Prompt 越写越长：塞了太多领域知识，Token 浪费 + 注意力被稀释
- 任务跨度变大：一次请求要跨多个系统/团队/领域协作
- 对吞吐/延迟有要求：希望并行查多个源或并行跑多个子任务
- 长流程要可控：必须支持分阶段、可回滚、可恢复、可审计
把它更“工程化”地说：不是因为 Prompt 变长就一定要多智能体，而是出现了这些不可绕过的系统约束：
单 Agent 常见痛点（症状） 触发的系统约束（原因） ────────────────────── ───────────────────── Prompt 越写越长/越难控 ───────────▶ 需要上下文隔离（Context Isolation） 一次请求跨多个系统/团队 ───────────▶ 需要分工协作（Distributed Ownership） 要同时查多个源/跑多个子任务 ─────────▶ 需要并行化（Parallel Fan-out） 流程分阶段且要可恢复/可审计 ─────────▶ 需要状态机（State Machine） 升维前先问 4 个 Yes/No（只要命中 1 个“硬约束”，再考虑多智能体）：
- 你是否必须把某些领域知识与对话历史隔离开，否则质量会明显下降？
- 你是否必须把能力拆给不同团队独立维护、独立发布？
- 你是否必须把 2+ 个子任务并行执行，才能满足延迟/吞吐？
- 你是否必须把流程做成可恢复的状态机（阶段、回滚、审计）？
四种模式（每种都用同一套模板理解）
方案一：Subagents（集中式编排）
- 工作机制：主智能体（Supervisor/Main Agent）维护对话 Context 与编排；子智能体作为“工具”被调用，通常无状态、专注单一领域
- 最佳场景：多领域协作，需要集中式工作流控制 + 强上下文隔离，子智能体无需直接与用户对话
- 核心权衡：每次子调用都要“出去一趟再回来” → 延迟/Token 上升，但换来严格控制权与清晰边界
- 你要补的工程能力：主编排层（任务拆解/并发/汇总）、子智能体输入输出契约、子调用可观测与限流
User Request ──▶ Main Agent (Supervisor, owns Context) │ ┌───────────┼───────────┐ │ │ │ ▼ ▼ ▼ Subagent A Subagent B Subagent C (Calendar) (Mail) (CRM) │ │ │ └─────── results merged ────────┘ ▼ Final Response 方案二：Skills（渐进式揭示 / 按需加载）
- 工作机制：同一个 Agent 按需加载“技能包”（短规则 + reference + scripts），临时切到某个专业流程
- 最佳场景：单 Agent 多专业化，但仍要保持“用户直连”的交互体验（编码/写作/排障）
- 核心权衡：简单、迭代快；但技能用多了，history 累积 → Token 膨胀、模型漂移
- 你要补的工程能力：按需加载与裁剪（reference 分层、历史压缩）、技能的触发条件与禁止事项、输出格式强约束
User │ ▼ Agent ├─ load(skill: code-review) ──▶ follow fixed output ├─ load(skill: db-debug) ──▶ read reference/* if needed └─ load(skill: release) ──▶ run scripts/* if needed (conversation history grows if不裁剪) 方案三：Handoffs（状态驱动交接）
- 工作机制：系统维护显式 state（phase、facts、artifacts、nextActions…）；当前活跃 Agent 完成本阶段后，把控制权交给下一阶段 Agent
- 最佳场景：多阶段顺序工作流（客服/审批/排障/交付），每个阶段职责边界清晰
- 核心权衡：流程可控、衔接自然；但 state 设计与一致性要求高，交接必须保证信息不丢失
- 你要补的工程能力：state schema（字段/版本/持久化）、幂等与重试、阶段级观测与恢复策略
先用一句话理解：不是“谁更聪明就继续聊”，而是“state.phase 变了就换人做下一步”。
┌───────────────┐ handoff ┌───────────────┐ handoff ┌───────────────┐ │ Agent A │───────────▶│ Agent B │───────────▶│ Agent C │ │ (Collect Info) │ │ (Execute) │ │ (Verify/Close) │ └───────┬────────┘ └───────┬────────┘ └───────┬────────┘ │ update state │ update state │ update state ▼ ▼ ▼ state.phase=collect state.phase=execute state.phase=verify state 通常长这样（示意）：
{"ticketId":"T-123","phase":"execute","facts":{"user":"u_001","device":"iOS","errorCode":"AUTH_403"},"artifacts":{"diagnosis":"token expired","toolResults":["reset_token:ok"]},"nextActions":["ask_user_relogin","verify_login_success"],"retry":{"count":1,"max":3}}方案四：Router（路由分发 + 汇总合成）
- 工作机制：Router 先分类/意图识别，再并行分发给多个专业 Agent；最后由汇总器合成最终结果
- 最佳场景：企业级知识库、多垂直领域检索、多源比对（要并行“查”和“算”）
- 核心权衡：无状态、一致性好、天然并行；但需要额外路由与合成层，路由误判会放大到最终答案
- 你要补的工程能力：路由置信度与回退策略、并发控制与缓存、合成器（证据对齐/冲突消解）
┌──────────────┐ User ──────▶│ Router │ └──────┬────────┘ │ fan-out (parallel) ┌─────────┼──────────┐ │ │ │ ▼ ▼ ▼ Agent DomainA AgentB AgentC │ │ │ └─────────┴──────────┘ ▼ ┌──────────────┐ │ Aggregator │ └──────────────┘ ▼ Final Answer 一张表对比（选型时只看这张也够）
| 模式 | 分布式开发 | 并行 | 多跳顺序 | 直接用户交互 | 主要成本 | 主要风险 |
|---|---|---|---|---|---|---|
| Subagents | 强 | 强 | 中 | 弱（一般不直连） | 往返调用次数↑ | 延迟、编排复杂度 |
| Skills | 中 | 弱 | 中 | 强 | history 变长 Token↑ | 技能污染上下文、漂移 |
| Handoffs | 中 | 弱 | 强 | 中/强 | 状态管理成本↑ | 交接丢信息、状态不一致 |
| Router | 强 | 强 | 弱 | 弱/中 | 路由+合成开销 | 路由误判、合成偏差 |
怎么选（决策树）
先问一句：单 Agent + 工具 + 约束化输出 是否已足够？ └─ 是 → 先不升维 └─ 否 → 你的核心矛盾是什么？ ├─ 要强控制 + 上下文隔离 + 多领域协作 → Subagents ├─ 要保持直连交互 + 按需专业化 → Skills ├─ 要分阶段顺序推进 + 进度可恢复可审计 → Handoffs └─ 要并行查多源 + 汇总合成 → Router 三个典型场景（模式怎么落到业务）
| 场景 | 更优模式 | 为什么 | 你要提前付的成本 |
|---|---|---|---|
| 一次性请求（单工具） | Skills / 单 Agent | 需求简单，别为架构加延迟 | 控制 history 增长 |
| 多阶段客服/审批 | Handoffs | 阶段边界清晰，进度可追踪 | state schema + 恢复策略 |
| 企业知识检索与比对 | Router | 天然并行，多源合成 | 路由准确率 + 合成策略 |
客户端落地要点（端侧视角）
- 体验预算：并行/多轮会拉长等待；必须有阶段进度、可取消、可恢复
- 弱网与失败：超时/重试/幂等/降级要统一；错误码对齐到 UI 文案与引导
- 可观测性：按 phase 记录耗时/失败/重试/取消；能追踪到子智能体/路由分支
- 成本控制：对 fan-out 做限流；对 skills 做按需读取与历史裁剪；对 router 做缓存
- 发布与回滚：所有分支要可灰度；关键开关尽量收敛到主编排层
最小实践清单（你要交付什么）
- 写清楚“为何升到多智能体”：约束来自哪里（隔离/并行/状态/协作）
- 为每个分支定义契约：输入/输出/错误码/证据包（日志、埋点、截图）
- 设计 state（若选 Handoffs）：phase、facts、artifacts、nextActions、retry、audit
- 做可观测：阶段耗时、失败恢复率、取消率、路由命中率、合成一致性
- 做回归与兜底：子调用失败如何降级；合成失败如何最小可用输出
参考
- https://mp.weixin.qq.com/s/tuG5sqLhFpbsxN1Mo8juig
