系列导航上一篇AI Agent 工程实践47什么时候应该从 Agent 改回 Workflow下一篇AI Agent 工程实践49一次真实优化——从 Agent v1 到 v2发布时间2026-08-15标签AI Agent工程实践Multi-Agent架构决策上一篇我把 PR review 从 Agent 退回了 Workflow因为它太确定。这一篇问题反过来了bug 定位这个任务我做得越来越重重到开始出问题。一个 Agent 里既要做规划下一步查什么、又要做调研读哪些文件、还要做审查结论对不对三种职责挤在一起开始互相打架。有人建议我拆成 Multi-Agent 吧一个管规划一个管调研一个管审查。我差点就信了。直到我算了一笔账。问题背景这是第五阶段的第十三篇。上一篇聊该往回收Agent→Workflow这一篇聊该不该往上走单 Agent→Multi-Agent。先澄清概念Multi-Agent 不是多个 LLM 调用而是多个有独立职责、独立上下文的 Agent 协作。这是很多教程爱讲、很多项目爱上的东西——因为它听起来先进。但我要讲的不是Multi-Agent 怎么搭第 08、12 篇讲过理论而是一个更实际的决策在你这个具体的项目里到底该不该拆以及怎么算这笔账。错误尝试职责冲突就想拆Repo Doctor 的 bug 定位任务最近越来越重我观察到一个现象三种职责在一个 Agent 里打架。具体症状它在读文件找线索的时候会突然忘了自己原本的调查计划开始乱读一气调研干扰规划。它在下结论的时候又带着调研者的身份舍不得否定自己刚找到的线索即使线索有问题调研干扰审查。用第 40 篇的分类树来说这已经是 State Error 和 Reasoning Error 的高发区了。于是我脑子里冒出一个很自然的念头把这三个职责拆成三个 Agent 呗。Planner 一个、Researcher 一个、Reviewer 一个各自独立各干各的。这个念头几乎就是过度工程的标准起手式。关键观察拆之前先算四本账在动手拆之前我逼自己算了一笔账——拆成 Multi-Agent到底要付出什么、能赚到什么成本账拆的代价 1. Token三个 Agent 各自维护完整上下文Token 直接翻倍甚至三倍 2. LatencyAgent 之间要串行/协调编排延迟上升 3. Complexity从一个 loop变成三个 Agent 的消息协议复杂度暴涨 4. Failure Surface失败面从 1 变成 3任何一个 Agent 出错都会拖垮整体 收益账拆的好处 1. 职责清晰每个 Agent 只干一件事Prompt 更短更专 2. 单点好调某个职责出错只调对应 Agent不污染其他 3. 可并行Researcher 可以并行读多个文件核心洞察Multi-Agent 不是为了看起来先进是单 Agent 的职责冲突到了拆开的收益超过编排成本的那一刻。而 Repo Doctor 现在还没到那一刻。最终方案不拆 Multi-Agent只抽一个 Reviewer 节点算完账我的结论很明确现在不拆。但我也没有无视职责冲突这个问题——我找到了一个更轻的解法把审查这一项抽成一个独立的 Reviewer 节点。注意区别节点 ≠ Agent。节点同一个执行流程里的一个步骤共享上下文成本极低。Agent独立的智能体有自己的上下文和工具成本高、要编排。我抽的是节点不是Agent。它只是把审查结论证据链这一步从原来的顺手做变成了独立做加了一道关卡这样既解决了调研者舍不得否定自己的冲突审查独立了又没付出 Multi-Agent 的成本还是同一个流程、共享上下文。代码或配置示例抽 Reviewer 节点的实现关键在职责隔离——它在流程上独立但成本上仍是节点# repo_doctor/nodes/reviewer.py —— 独立 Reviewer 节点不是独立 Agent def reviewer_node(state: State) - Verdict: 独立审查结论的每条证据都必须能回溯到文件行。 这是节点不是 Agent——共享 state不另起上下文。 conclusion state.conclusion for claim in conclusion.claims: if claim not in state.evidence_map: # 证据链断裂打回 Planner 重新调查 return Verdict(rejectTrue, reasonf无证据支撑: {claim}) return Verdict(acceptTrue)对比拆成独立 Agent和抽成节点维度拆成独立 Reviewer Agent抽成 Reviewer 节点Token 成本1 份完整上下文0共享 state编排复杂度要消息协议流程里加一步失败面1不变职责隔离效果强足够对当前规模来说节点的职责隔离效果足够了成本却低一个数量级。设计权衡候选方案优点缺点为什么不选维持原状不处理冲突零成本职责打架State/Reasoning 错误高发冲突真实存在不能无视拆成 Multi-Agent职责最清晰Token 翻倍、延迟升、失败面×3规模不够收益撑不起成本抽独立 Reviewer 节点隔离审查职责、成本极低隔离不如真 Agent 彻底当前规模的最优解关键结论该不该拆 Multi-Agent的答案从来不是一个固定值而是收益 vs 成本的动态比较。今天不拆不代表永远不拆——如果哪天 Repo Doctor 要同时诊断十几个仓库、要并行几十个调研任务那笔账可能就翻过来了。总结✅ 单 Agent 的职责冲突是真实问题但拆 Multi-Agent不是唯一解。✅ 拆之前先算四本账Token / Latency / Complexity / Failure Surface。✅ 当前规模下收益撑不起成本所以不拆。✅ 折中解把审查抽成独立 Reviewer节点非 Agent隔离职责、成本极低。✅ 铁律Multi-Agent 是拆开收益超过编排成本那一刻才做的决定不是看起来先进的理由。参考资料Anthropic《Building Effective Agents》的 multi-agent 成本分析 → 为什么引用为收益 vs 成本的决策框架提供了依据。第 08、12 篇本系列关于 Multi-Agent 的理论 → 为什么引用本文是它们在真实项目里的落地决策形成呼应。系列导航上一篇AI Agent 工程实践47什么时候应该从 Agent 改回 Workflow下一篇AI Agent 工程实践49一次真实优化——从 Agent v1 到 v2本文是 [AI Agent 工程实践] 系列的第 48 篇。