一、引言：一个常见的架构误区

在AI应用开发中，存在一个普遍现象：部分团队在项目启动阶段即采用多Agent架构，将系统拆分为规划Agent、检索Agent、执行Agent、审稿Agent、路由Agent等多个节点。架构图设计完整，但系统上线后频繁出现Token消耗超出预期、端到端延迟显著增加等问题

最初的设计如下：

笔者的早期实践也验证了这一现象。在搭建Agent集群初期，曾将本可由单Agent处理的简单任务拆分为路由、执行、审查等多个Agent节点。运行结果表明，Token消耗大幅增加，端到端延迟严重恶化。最终通过将多余节点合并，性能恢复正常。这正是后来反复提及的“从9个Agent砍到5个”的技术背景（agent数量精简这次踩坑经历，笔者也会尽快分享出来，敬请期待）

目前的架构如下：

这一经历引出一个核心问题：多Agent是否必然是单Agent的升级方案？

查阅过去一年主流厂商的官方建议，结论高度一致。Anthropic强调从简单方案起步，优先验证单Agent的能力边界。OpenAI建议先将单Agent能力充分利用，再考虑拆分。Microsoft明确指出，能用确定性函数解决的问题，不应使用AI Agent。Google ADK将Sequential、Parallel等workflow结构与multi-agent并列为同级选项，而非默认更高级的方案

上述建议指向同一个结论：默认从单Agent起步，只有在观测到明确的“拆分信号”时才演进，是工程上性价比最高的策略

二、工程经济学视角：多Agent的隐性成本

多Agent架构引入的隐性成本，对资源有限的团队构成实质性负债。主要体现在以下层面：

【协调开销】 Agent之间的通信、状态同步与错误传播，每一层交互都增加系统复杂度。当Agent数量上升时，交互边界的数量非线性增长，系统行为的可预测性随之下降

【延迟叠加】 单Agent单次推理可完成的任务，拆分为多Agent串行或并行调用后，端到端延迟成倍增长。即使采用并行设计，协调节点与聚合节点的等待时间仍是额外延迟源

【Token成本膨胀】 多Agent系统的Token消耗可能是单Agent的数倍，具体倍数取决于协调复杂度。在日均万级请求的场景下，这一差异体现为从每日数百元到数千元的成本差距。笔者在早期集群中实测验证了拆分后Token消耗大幅增加的现象

【调试复杂度】 单Agent出现问题，只需分析一个推理链。多Agent出现问题，需要在多个Agent之间排查调用边界、通信格式与状态一致性，故障定位时间可能显著延长

三、五个拆分决策信号

拆分决策不应基于“业务听起来复杂”的主观判断，而应基于可观测的生产指标。以下是五个最关键的触发信号：

信号1：【提示词与工具超载】

当系统提示词超过800词时，指令之间开始竞争模型的注意力资源，关键约束被忽略的概率显著上升；

当可用工具超过8至10个时，工具选择准确率显著下降，频繁出现工具调用错误。当单次推理需要跨越3个以上业务域时，不同域的治理规则在同一上下文中产生冲突

在搭建枢衡系统早期，笔者曾遇到典型的工具超载问题。一个Agent绑定了过多插件，在供应链推演任务中频繁选错调用工具，准确率出现断崖式下降。精简工具集后，性能回升

CallSphere提出的评估函数提供了一个可操作的量化参考：工具数大于8、提示词大于800词、领域数大于3、错误率大于15%，四项中满足两项，即应进入拆分评估

信号2：【领域冲突】

当Agent在不同业务域中对同一实体需要应用相互矛盾的规则时，单Agent架构面临结构性困境。典型案例是：Agent同时负责销售与定价策略。销售逻辑为促进成交倾向于给予折扣，定价策略逻辑则禁止突破底价。两类规则置于同一段提示词中，模型无法确定优先级

这一问题的本质不是提示词设计不当，而是两个业务域的治理逻辑天然对立。Nimblebrain将其定义为“domain conflict”，认为这是从单Agent向多Agent演进的最强信号。当同一实体在不同业务域中需要接受不同规则约束时，拆分是架构上的必然选择

信号3：【治理与审计隔离】

在金融、医疗、供应链等受监管领域，或需要向客户与投资人证明决策可追溯性的场景中，单Agent的推理链难以提供清晰的责任边界

多Agent的核心治理优势在于：每个Agent具有明确的输入、输出与责任范围，审计trail结构化且可查询。以贷款审批为例：数据提取Agent负责从多源系统获取客户信息，风险评估Agent负责计算违约概率，合规审查Agent负责核对监管要求，最终决策Agent负责输出审批结论。每个环节均有独立日志，故障可追溯至具体Agent与具体环节。此类责任边界，单Agent架构难以提供

信号4：【并行化瓶颈】

当任务可分解为多个独立子任务且彼此无强依赖时，单Agent的顺序执行构成延迟瓶颈。跨服务重构、多维度代码审查、广度优先的研究检索等场景，子任务之间天然可并行，多Agent并行处理能带来显著的吞吐量提升

关键前提是：子任务之间存在真实独立分支，而非伪并行。将可顺序完成的逻辑拆分为多个Agent并行调用，不仅不会提速，协调开销反而导致整体延迟增加

信号5：【错误率持续高于15%且呈现领域聚集】

当单Agent整体错误率超过15%，且错误集中于某个特定环节，例如总是出现合规检查错误，而其他环节表现正常，说明该环节需要独立的领域上下文与工具集，是拆分的最佳切入点

错误率的领域聚集性，本质上表明该环节的逻辑已超出当前Agent的承载能力，需要专属的处理空间

四、最小可行演进路线

多Agent拆分中常见的过度设计是：一次性引入规划Agent、检索Agent、执行Agent、审稿Agent、路由Agent等全部节点，导致系统复杂度超出实际需求。笔者早期的“从9个Agent砍到5个”，本质上是对过度拆分的纠错

推荐的策略是“Triage + 渐进抽离”，分四个阶段演进

阶段1：【单Agent攻坚】单一Agent配合优质工具与RAG，目标是覆盖80%的场景，建立基线指标：延迟、成本、准确率。此阶段聚焦于将单Agent能力发挥至极限，不启动任何拆分

阶段2：【先抽Reviewer】当输出质量出现不稳定时，首个拆分的节点应为审查者而非执行者。增加Reviewer Agent对最终输出进行质量校验、策略校验与合规校验。Reviewer是风险最低、收益最明确的拆分方式：不改变原有执行逻辑，仅在输出端增加一道关卡。即使Reviewer出现问题，也不影响主流程执行

阶段3：【再抽Planner】当任务类型多样化且不同任务需要不同执行路径时，引入轻量级Planner或Router负责意图识别与任务分发。此时系统架构为：Planner理解用户意图并选择执行路径，Specialist Executor负责具体执行，Reviewer负责最终校验

阶段4：【领域特化】当某个Specialist Executor自身出现工具超载或领域冲突时，进一步细分。例如，将“供应链执行Agent”拆分为“采购Agent”与“库存Agent”。

每次拆分前需回答一个核心问题：新Agent是否具有不同的schema、不同的工具集、不同的治理规则？若仅因提示词差异而拆分、其他完全一致，则应合并回去

提示词差异不等于架构差异

五、六维评测框架

拆分后须用数据验证多Agent系统是否优于单Agent，而非仅呈现更复杂的架构图。建议从以下六个维度进行对比评测：

【端到端延迟】 单Agent基线通常为2至5秒（同步场景）。多Agent的目标为：并行任务总延迟显著低于单Agent顺序执行；串行任务延迟恶化不超过20%。评测方法为对同一请求各执行100次，对比P95延迟值

【Token成本】 单Agent基线为单次推理总消耗。多Agent系统的总Token消耗不应超过单Agent的2至3倍，具体容忍度取决于业务场景。需精确统计每个Agent的input与output tokens，加总后与单Agent对比

【任务准确率】 单Agent基线为整体准确率。多Agent的目标为分领域错误率显著下降，整体错误率降至10%以下。需构建100个以上case的评估集，覆盖各业务场景

【调试效率】 单Agent故障定位平均时间较长，因所有逻辑混合于同一推理链中。多Agent因责任边界清晰，定位时间应缩短50%以上。评测方法为记录生产环境中故障排查的平均时长

【治理清晰度】 单Agent提供完整但结构松散的推理trace。多Agent应提供结构化、可查询的Agent级审计日志。可模拟监管审计场景，测试能否在5分钟内提取特定决策的完整链路

【可扩展性】 单Agent升级需全量重新部署。多Agent应支持独立升级或回滚单个Agent。评测方法为执行一次Agent级A/B测试，验证能否仅升级其中一个Agent而不影响整体系统

需特别注意的研究结论来自Google Research：多Agent变体在顺序推理任务上存在39%至70%的性能下降风险。若任务本质为“步骤A严格先于步骤B”，拆分为多Agent将增加协调开销，不带来收益

实用盲评机制：对同一批复杂请求，分别由单Agent和多Agent处理，隐去架构信息后由业务专家评分。若专家无法稳定区分或认为多Agent明显更优，说明拆分未带来实质价值。

六、常见陷阱

陷阱1：【为拆分而拆分】拆分的唯一正当理由是可观测指标的恶化，而非追求架构图复杂度。笔者从9个Agent精简至5个的过程，本质上是从架构虚荣回归工程现实

陷阱2：【将workflow混淆为multi-agent】Google ADK将Sequential、Parallel workflow与multi-agent并列为同级选项。workflow是确定性的步骤编排，multi-agent是自治实体之间的动态协作。混淆二者会导致在不适用场景过度投入，在真正需要时准备不足

陷阱3：【忽视回退能力】即使采用多Agent架构，也需确保单个Agent可独立运行与测试。生产环境出现问题时，需具备快速回退至单Agent模式的能力，或隔离故障Agent使其余节点继续工作。无回退能力的多Agent架构属于高风险架构

七、结语

多Agent不是智能的升级，是协调的代价。能用一个Agent解决的问题，不应使用两个；能用确定性代码解决的问题，不应使用Agent

单Agent是默认答案，多Agent是特定约束下的衍生方案。架构决策的核心不是“如何拆得更精细”，而是“观测到什么信号时，拆分的收益大于其引入的成本”

若已确认拆分需求，关于路由、委托、辩论、群体四种协作范式的选择，参见《一文讲清Agent集群的四种设计模式》

【看山 Agent 架构】

工信部 AI 技术应用（高级）认证

30次集群崩溃复盘 | 20+智能体实战

深耕 Agent 集群架构，用商科思维重构复杂系统效率

注：本文内容由 AI 辅助创作，作者对内容结果负责