多 Agent 架构：什么时候需要，以及如何避免过度设计
开篇：多 Agent 看起来很先进，为什么项目反而更难交付
很多团队在做 Agent 应用时，都会很快走到这个节点：
- 单 Agent 版本已经能跑
- 但复杂任务完成率不稳定
- 于是想通过“多 Agent 分工”提升质量
结果往往是：
- 架构图变漂亮了，问题没变少
- Debug 难度暴涨
- Token 成本与时延双双上涨
- 出错后很难定位到底谁错了
这说明一个现实：
多 Agent 不是能力加法，首先是复杂度乘法。
所以正确姿势不是“能拆就拆”，而是先回答：
- 业务问题是否真的需要多角色协作
- 复杂度上升是否有明确收益
- 你是否具备治理这套系统的能力
一、先做决策：什么时候用单 Agent，什么时候上多 Agent
1.1 优先单 Agent 的场景
满足以下条件时，建议坚持单 Agent：
- 任务链条短（2~4 步）
- 主要依赖固定工具集
- 路由逻辑可规则化
- 失败可通过简单重试与兜底处理
一句话：
如果流程能写成稳定 Workflow，就别急着引入多 Agent。
1.2 适合多 Agent 的场景
当你出现这些特征，才值得考虑多 Agent：
- 任务天然多角色（如分析、执行、审校）
- 子任务知识域差异明显（法务、财务、技术）
- 单 Agent 提示过长导致性能和稳定性下降
- 需要并行处理多个独立子问题
二、三种主流多 Agent 模式（从易到难）
2.1 模式 A：单 Agent + 工具集（最推荐起点）
本质：还是单 Agent，只是通过工具扩展能力边界。
优点：简单、稳定、可控。
缺点：当任务复杂到需要多角色审校时会吃力。
2.2 模式 B：Supervisor + Specialists（实战主流）
一个总控 Agent 负责拆解任务，多个专家 Agent 负责子任务。
优点：
- 分工明确，提示词长度可控
- 便于替换某个子 Agent 能力
缺点：
- 协调成本高
- 状态一致性要求更高
2.3 模式 C：去中心化协作（谨慎使用）
多个 Agent 彼此调用、协商、迭代。
理论上更灵活，实际上极难控制。
不建议初期采用，常见后果是：
- 执行路径不可预测
- 无限循环风险
- 成本失控
三、多 Agent 的核心不是“数量”，而是“协作协议”
你可以把多 Agent 看成“多服务协同系统”。
没有协议，协作必乱。
3.1 必须定义的协作契约
每个 Agent 至少要有：
- 输入契约（需要哪些上下文字段）
- 输出契约（结构化 JSON）
- 责任边界（做什么，不做什么）
- 失败契约（错误码、是否可重试）
示例（简化）：
{"agent":"review_agent","input_schema":{"draft_answer":"string","citations":"array"},"output_schema":{"pass":"boolean","risk_level":"low|medium|high","feedback":"string"}}3.2 不要让 Agent 之间传“自然语言段子”
如果 A Agent 给 B Agent 的输入是大段自由文本，
你很难做自动校验与错误定位。
建议传“结构化工单”：
- 任务 ID
- 子任务类型
- 必填字段
- 上游证据引用
四、状态管理：多 Agent 失败最多的地方
多 Agent 一旦涉及共享状态，就会面临一致性问题。
4.1 三类状态要区分
- 会话状态：当前用户会话上下文（短期）
- 任务状态：工作流执行进度（中期）
- 业务状态：订单、审批、工单等真实业务数据（长期）
原则：
- 会话状态可缓存，必须有 TTL
- 任务状态要可恢复（checkpoint）
- 业务状态必须以源系统为准，不能依赖模型“记忆”
4.2 推荐状态机设计
这套状态机会让你在故障场景下仍可追踪与恢复。
五、上下文共享策略：共享太少不协同，共享太多会污染
多 Agent 不是每个都拿全量上下文。
应按职责最小化共享。
5.1 推荐“分层上下文”
- 全局层：用户身份、权限、目标任务
- 任务层：当前子任务必要资料
- 私有层：Agent 自身推理中间态（默认不外泄）
5.2 避免“上下文污染”
常见问题：
- 一个 Agent 的错误中间结论被全链路复用
- 过期信息覆盖最新业务状态
治理策略：
- 中间结果必须带时间戳和来源
- 高风险结论必须二次校验
- 过期上下文自动失效
六、并行与串行：不是越并行越快
并行能降时延，但会提高协调成本与冲突概率。
6.1 适合并行的任务
- 子任务独立，互不依赖
- 最终只需聚合结果
6.2 必须串行的任务
- 下游依赖上游输出
- 涉及写操作或状态变更
工程建议：
对可变更状态的任务默认串行，
对纯分析任务优先并行。
七、代码示例：Supervisor 模式最小可用实现（Python）
fromtypingimportDict,Any,ListclassSupervisor:def__init__(self,agents):self.agents=agentsdefrun(self,task:Dict[str,Any])->Dict[str,Any]:# 1) 拆解任务plan=self._plan(task)results:List[Dict[str,Any]]=[]# 2) 调度执行（示例为串行，可扩展并行）forstepinplan["steps"]:agent_name=step["agent"]payload=step["payload"]res=self.agents[agent_name].execute(payload)ifnotres.get("ok"):# 失败策略：重试/降级/中止fallback=self._handle_failure(step,res)ifnotfallback.get("ok"):return{"ok":False,"error":fallback}res=fallback results.append({"step":step["id"],"result":res})# 3) 聚合与审校final=self._merge_and_review(results)return{"ok":True,"data":final}def_plan(self,task):return{"steps":[{"id":"s1","agent":"research_agent","payload":task},{"id":"s2","agent":"execution_agent","payload":task},{"id":"s3","agent":"review_agent","payload":task},]}def_handle_failure(self,step,res):return{"ok":False,"code":"STEP_FAILED","step":step["id"],"detail":res}def_merge_and_review(self,results):return{"summary":"done","details":results}这段代码重点不是功能多，而是体现了 4 个多 Agent 基础能力：
- 可计划（plan）
- 可调度（dispatch）
- 可恢复（failure handling）
- 可审校（merge/review）
八、可靠性设计：多 Agent 必须有“刹车系统”
8.1 防无限循环
- 设置最大迭代步数
- 设置全局 Token/时长预算
- 同一错误重复出现时强制中止
8.2 防雪崩
- 子 Agent 限流
- 下游工具熔断
- 全链路超时上限
8.3 防静默失败
- 每步都有成功/失败事件日志
- 未上报结果视为失败而非等待
- 超时自动触发补偿或回滚
九、成本治理：多 Agent 的隐藏账本
多 Agent 常见成本陷阱：
- 重复读同一上下文
- 重复检索同一问题
- Review Agent 过度调用大模型
优化建议：
- 共享检索结果缓存（按任务 ID）
- 低风险步骤使用小模型
- Review 只审关键字段，不重做整段推理
- 设定任务级 Token 预算和硬阈值
十、评估方法：不要只看最终答案
多 Agent 需要过程级评估，而不只是结果评分。
推荐指标：
- 任务完成率
- 步骤失败率（按 Agent 维度）
- 平均步骤数（是否冗长）
- 人工接管率
- 单任务成本（token/API 调用）
- 端到端时延（P50/P95）
十一、常见反模式（看到就要警惕）
- 为了“高级感”硬拆多 Agent
- 每个 Agent 都读全量上下文
- 没有统一协议，只靠自然语言协作
- 失败处理靠“再问一遍模型”
- 没有步骤级观测，只看最终结果
- 把多 Agent 当作性能优化手段（多数情况下会更慢）
十二、上线 Checklist（多 Agent 专项）
架构与协议
- 每个 Agent 输入/输出 schema 已定义
- 角色职责边界清晰，无重复职责
- Supervisor 调度策略可配置
状态与可靠性
- 任务状态机可追踪、可恢复
- 迭代步数与预算上限已配置
- 失败重试与降级策略已验证
成本与评估
- 步骤级成本可统计
- 子 Agent 质量指标可观测
- 灰度策略与回滚策略可执行
结语
多 Agent 不是目标，只是一种手段。
当它能明确提高任务完成率、可维护性、可扩展性时才值得引入。
先把单 Agent 做稳，再把多 Agent 做精。
复杂度必须有收益对价，否则就是技术自嗨。
下一篇预告
下一篇进入很多团队最容易忽略但影响长期效果的模块：
《Agent 的记忆系统设计：短期记忆、长期记忆与记忆污染治理》
重点会讲：
- 记忆写入与召回策略
- 用户画像和任务记忆如何分层
- 如何防止“记错、记脏、记过期”
