多智能体（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