多智能体（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 变长就一定要多智能体，而是出现了这些不可绕过的系统约束：​

​

代码块​

Python

单 Agent 常见痛点（症状） 触发的系统约束（原因）​

────────────────────── ─────────────────────​

Prompt 越写越长/越难控 ───────────▶ 需要上下文隔离（Context Isolation）​

一次请求跨多个系统/团队 ───────────▶ 需要分工协作（Distributed Ownership）​

要同时查多个源/跑多个子任务 ─────────▶ 需要并行化（Parallel Fan-out）​

流程分阶段且要可恢复/可审计 ─────────▶ 需要状态机（State Machine）​

​

升维前先问 4 个 Yes/No（只要命中 1 个“硬约束”，再考虑多智能体）：​

•

你是否必须把某些领域知识与对话历史隔离开，否则质量会明显下降？​

•

你是否必须把能力拆给不同团队独立维护、独立发布？​

•

你是否必须把 2+ 个子任务并行执行，才能满足延迟/吞吐？​

•

你是否必须把流程做成可恢复的状态机（阶段、回滚、审计）？​

​

​

四种模式（每种都用同一套模板理解）​

方案一：Subagents（集中式编排）​

•

工作机制：主智能体（Supervisor/Main Agent）维护对话 Context 与编排；子智能体作为“工具”被调用，通常无状态、专注单一领域​

•

最佳场景：多领域协作，需要集中式工作流控制 + 强上下文隔离，子智能体无需直接与用户对话​

•

核心权衡：每次子调用都要“出去一趟再回来” → 延迟/Token 上升，但换来严格控制权与清晰边界​

•

你要补的工程能力：主编排层（任务拆解/并发/汇总）、子智能体输入输出契约、子调用可观测与限流​

​

代码块​

Python

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 分层、历史压缩）、技能的触发条件与禁止事项、输出格式强约束​

​

代码块​

Python

User​

│​

▼​

Agent​

​

​

​

方案三：Handoffs（状态驱动交接）​

•

工作机制：系统维护显示state（phase、facts、artifacts、nextActions…）；当前活跃 Agent 完成本阶段后，把控制权交给下一阶段 Agent​

•

最佳场景：多阶段顺序工作流（客服/审批/排障/交付），每个阶段职责边界清晰​

•

核心权衡：流程可控、衔接自然；但 state 设计与一致性要求高，交接必须保证信息不丢失​

•

你要补的工程能力：state schema（字段/版本/持久化）、幂等与重试、阶段级观测与恢复策略​

先用一句话理解：不是“谁更聪明就继续聊”，而是“state.phase 变了就换人做下一步”。​

​

代码块​

SQL

┌───────────────┐ 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 通常长这样（示意）：​

​

代码块​

JSON

{​

"ticketId": "T-123",​

"phase": "execute",​

"facts": {​

"user": "u_001",​

"device": "iOS",​

"errorCode": "AUTH_403"​

},​

"artifacts": {​

"diagnosis": "token expired",​

"toolResults": ["reset_token:ok"]​

​

方案四：Router（路由分发 + 汇总合成）​

•

工作机制：Router 先分类/意图识别，再并行分发给多个专业 Agent；最后由汇总器合成最终结果​

•

最佳场景：企业级知识库、多垂直领域检索、多源比对（要并行“查”和“算”）​

•

核心权衡：无状态、一致性好、天然并行；但需要额外路由与合成层，路由误判会放大到最终答案​

•

你要补的工程能力：路由置信度与回退策略、并发控制与缓存、合成器（证据对齐/冲突消解）​

​

​

​

代码块​

Python

┌──────────────┐​

User ──────▶│ Router │​

└──────┬────────┘​

│ fan-out (parallel)​

┌─────────┼──────────┐​

​

​

​

​

一张表对比（选型时只看这张也够）​

​

#foJRrKNraKmz text{white-space:pre}.fb0{stroke:var(--N900-FG, 0.15)}.fx0{stroke-miterlimit:10}.fa1{fill:#bbbfc4}.fx1{font:normal 400 12px MonospacedNumber,LarkHackSafariFont,LarkEmojiFont,LarkChineseQuote,-apple-system,BlinkMacSystemFont,Helvetica Neue,Tahoma,PingFang SC,Microsoft Yahei,Arial,Hiragino Sans GB,sans-serif,Apple Color Emoji,Segoe UI Emoji,Segoe UI Symbol,Noto Color Emoji}.fx2{text-anchor:middle}.fx3{dominant-baseline:central}.fx4{stroke:none}.fc0{fill:var(--text-caption)}.fa2{fill:var(--text-link-disabled)}.fa3{fill:#1f2329}.fx5{font:normal 400 16px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"}.fx6{dominant-baseline:alphabetic}.fc1{fill:#ffffff}.fc2{fill:rgb(0, 0, 0)}.fb1{fill:var(--N900-FG, 0.15)}.fa4{fill:var(--bg-body)}ABCDEF12345模式SubagentsSkillsHandoffsRouter分布式开发强中中强并行强弱弱强多跳顺序中中强弱直接用户交互弱（一般不直连）强中/强弱/中主要成本往返调用次数↑history 变长 Token↑状态管理成本↑路由+合成开销

​

​

​

怎么选（决策树）​

​

代码块​

Python

先问一句：单 Agent + 工具 + 约束化输出 是否已足够？​

└─ 是 → 先不升维​

​

​

​

​

​

​

三个典型场景（模式怎么落到业务）​

​

表格加载中...

​

​

​

客户端落地要点（端侧视角）​

•

体验预算：并行/多轮会拉长等待；必须有阶段进度、可取消、可恢复​

•

弱网与失败：超时/重试/幂等/降级要统一；错误码对齐到 UI 文案与引导​

•

可观测性：按 phase 记录耗时/失败/重试/取消；能追踪到子智能体/路由分支​

•

成本控制：对 fan-out 做限流；对 skills 做按需读取与历史裁剪；对 router 做缓存​

•

发布与回滚：所有分支要可灰度；关键开关尽量收敛到主编排层​

​

​

最小实践清单（你要交付什么）​

•

写清楚“为何升到多智能体”：约束来自哪里（隔离/并行/状态/协作）​

•

为每个分支定义契约：输入/输出/错误码/证据包（日志、埋点、截图）​

•

设计 state（若选 Handoffs）：phase、facts、artifacts、nextActions、retry、audit​

•

做可观测：阶段耗时、失败恢复率、取消率、路由命中率、合成一致性​

•

做回归与兜底：子调用失败如何降级；合成失败如何最小可用输出​