多智能体（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 变长就一定要多智能体，而是出现了这些不可绕过的系统约束：
single agent common pain points (symptoms) -> system constraints (causes)
Prompt gets longer/harder to control -> Need context isolation
Request spans multiple systems/teams -> Need distributed ownership
Need to query multiple sources/run subtasks in parallel -> Need parallel fan-out
Process needs phases with rollback/audit -> Need state machine
升维前先问 4 个 Yes/No（只要命中 1 个'硬约束'，再考虑多智能体）：
- 你是否必须把某些领域知识与对话历史隔离开，否则质量会明显下降？
- 你是否必须把能力拆给不同团队独立维护、独立发布？
- 你是否必须把 2+ 个子任务并行执行，才能满足延迟/吞吐？
- 你是否必须把流程做成可恢复的状态机（阶段、回滚、审计）？
