企业官网建设流程全解析

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

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

怎么选（决策树）

先问一句：单 Agent + 工具 + 约束化输出 是否已足够？ └─ 是 → 先不升维 └─ 否 → 你的核心矛盾是什么？ ├─ 要强控制 + 上下文隔离 + 多领域协作 → Subagents ├─ 要保持直连交互 + 按需专业化 → Skills ├─ 要分阶段顺序推进 + 进度可恢复可审计 → Handoffs └─ 要并行查多源 + 汇总合成 → Router

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

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

• 体验预算：并行/多轮会拉长等待；必须有阶段进度、可取消、可恢复
• 弱网与失败：超时/重试/幂等/降级要统一；错误码对齐到 UI 文案与引导
• 可观测性：按 phase 记录耗时/失败/重试/取消；能追踪到子智能体/路由分支
• 成本控制：对 fan-out 做限流；对 skills 做按需读取与历史裁剪；对 router 做缓存
• 发布与回滚：所有分支要可灰度；关键开关尽量收敛到主编排层

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

• 写清楚“为何升到多智能体”：约束来自哪里（隔离/并行/状态/协作）
• 为每个分支定义契约：输入/输出/错误码/证据包（日志、埋点、截图）
• 设计 state（若选 Handoffs）：phase、facts、artifacts、nextActions、retry、audit
• 做可观测：阶段耗时、失败恢复率、取消率、路由命中率、合成一致性
• 做回归与兜底：子调用失败如何降级；合成失败如何最小可用输出

参考

• https://mp.weixin.qq.com/s/tuG5sqLhFpbsxN1Mo8juig