专栏第 12 篇
目标：回答一个最容易走偏的问题——“什么时候该拆多 Agent，以及怎么拆才不翻车”。
一、问题背景：为什么“多 Agent 冲动”常常导致工程倒退？
当单 Agent 跑出初步效果后，团队很容易进入一个阶段：
- 想拆“规划 Agent / 执行 Agent / 审核 Agent / 记忆 Agent”；
- 觉得角色越多，系统越“高级”；
- 期望通过拆分自然提升质量与效率。
但实际经常出现：
- 协作链路变长，故障点成倍增加；
- Agent 间协议不统一，调试成本飙升；
- 延迟和调用成本显著上升；
- 一旦异常，无法快速回退到稳定版本。
核心结论：多 Agent 不是目标，而是在单 Agent 达到瓶颈后的“工程手段”。
二、先给结论：是否拆分看“瓶颈证据”，不看“架构偏好”
建议用“证据驱动”判断，而不是“感觉驱动”。
2.1 适合继续单 Agent 的信号
- 问题主要来自 Prompt、工具质量或数据质量；
- 通过状态机/容错/检索优化仍能持续提升；
- 当前延迟与成本在可接受范围内；
- 团队规模和运维能力不足以支撑复杂编排。
2.2 进入多 Agent 评估的强信号（满足 2~3 条）
- 职责冲突稳定出现：规划逻辑与执行逻辑互相污染；
- 性能瓶颈长期存在：关键任务 p95 延迟持续高位；
- 质量平台期明显：单 Agent 优化 2~3 个迭代周期后收益趋近于零；
- 组织协作需要边界：不同子域由不同小组维护，冲突频繁；
- 已具备基础工程能力：统一协议、可观测、灰度与回滚机制完善。
三、多 Agent 拆分原则：先“职责解耦”，再“进程解耦”
很多团队一上来就做“服务级拆分”，这是高风险做法。正确顺序应是：
- 逻辑内拆（同进程）
- 服务化拆分（小流量）
- 编排层引入（可观测齐全）
- 全量演进（保留单 Agent 回退）
原则：每一步都可验证、可灰度、可回滚。
四、推荐演进路径（四阶段）
Phase 1：单体内逻辑拆分（不拆部署）
目标：在不改变线上拓扑的前提下，先把边界理清。
建议拆为模块：
- Planner（规划）
- Executor（执行）
- Reviewer（审查）
- Memory Manager（记忆管理）
输出要求：
- 模块输入输出统一 schema；
- request_id / trace_id 全链路贯通；
- 保持当前单 Agent 交付路径不变。
Phase 2：优先拆“最稳定、最独立”的模块
目标：降低首次服务化风险。
优先候选：
- 检索服务（RAG）
- 工具执行服务（Tool Gateway）
- 评测服务（离线）
灰度建议：
- 5% 流量小流量验证；
- 指标达标后再扩到 20%、50%。
Phase 3：引入编排层（Orchestrator）
目标：显式管理 Agent 间协作流程。
编排层职责：
- 任务路由（谁来做）
- 状态协调（当前到哪一步）
- 异常处理（超时、重试、降级、熔断）
- 观测汇总（跨 Agent trace）
关键要求：
- 协议强一致；
- 错误码统一；
- 调用预算可控。
Phase 4：全量迁移与持续优化
目标：在稳定性不下降的前提下释放多 Agent 价值。
关注指标：
- 质量：任务成功率、事实一致性
- 性能：p95/p99
- 成本：单请求成本、总成本
- 稳定性：失败率、降级率
五、拆分时的关键架构决策（必须提前定）
5.1 通信模式：同步优先，异步补充
- 实时交互路径：优先同步 RPC（可控、易观测）
- 长耗时任务：异步队列 + 回调
5.2 协议标准化
统一：
- 请求头（request_id、trace_id、tenant_id）
- 响应结构（ok/data/error/meta）
- 错误码（可重试/不可重试）
5.3 状态归属
明确“谁是状态真源”：
- 编排层持有全局状态；
- 子 Agent 只维护本地执行状态；
- 状态变更必须事件化记录。
六、成本与时延评估：拆分后必须“算账”
多 Agent 通常会带来：
- 跨服务通信开销；
- 更多模型调用；
- 更复杂的重试链路。
建议建立“拆分前后对照表”：
| 指标 | 拆分前 | 拆分后目标 | 备注 |
|---|---|---|---|
| 任务成功率 | baseline | +3%~8% | 视任务复杂度 |
| p95 时延 | baseline | 不高于 +20% | 超过需优化 |
| 单请求成本 | baseline | 不高于 +25% | 必须有收益说明 |
| 事故定位时间 | baseline | -30% 以上 | 可观测带来的收益 |
如果质量提升不足以覆盖时延和成本上涨，拆分就是失败的。
七、风险护栏：确保“可进可退”
7.1 双轨运行（推荐）
- 保留单 Agent 作为 stable path；
- 多 Agent 走 canary path；
- 按用户分桶或请求分桶灰度。
7.2 一键回退机制
触发条件示例：
- success_rate 下降 > 3%
- p95 增长 > 25%
- degrade_rate 持续上升 > 30%
触发后：
- 立即切回单 Agent 主路径；
- 冻结多 Agent 扩量；
- 自动生成复盘报告。
7.3 故障演练
在正式切换前至少做：
- 下游依赖不可用演练
- 编排器异常演练
- 回退流程演练
八、伪代码：渐进式路由与回退
defroute_request(req,cfg,metrics):# 1) 多Agent是否可用ifnotcfg.multi_agent_enabled:returnrun_single_agent(req)# 2) 是否命中灰度桶ifnotin_canary_bucket(req.user_id,cfg.canary_ratio):returnrun_single_agent(req)# 3) 健康门禁（实时）ifmetrics.multi_agent_error_rate>cfg.max_error_rate:returnrun_single_agent(req)# 4) 尝试多Agenttry:returnrun_multi_agent(req)exceptException:# 5) 快速回退returnrun_single_agent(req)九、常见误区与修正建议
误区 1：一次性全量切换
- 问题：风险不可控
- 修正：灰度放量 + 指标门禁
误区 2：先拆服务再统一协议
- 问题：跨服务对接混乱
- 修正：先协议标准化，再服务化
误区 3：只看质量提升，不看成本/时延
- 问题：上线后不可持续
- 修正：三指标联评（质量、时延、成本）
误区 4：没有回退通道
- 问题：故障时无法止损
- 修正：始终保留单 Agent stable path
十、系列总结：从 0 到 1，不是“复杂化”，而是“工程化”
回顾整套专栏，你会发现一个核心主线：
- 先把单 Agent 做稳（架构、状态机、容错、观测）；
- 再把能力做强（Prompt、记忆、RAG、上线治理）；
- 最后按证据演进（多 Agent 拆分与回退）。
最终结论：先进架构的前提，是稳定工程；持续迭代的前提，是可验证与可回退。
