发布时间2026-07-12标签AI AgentLLMMulti-Agent架构设计反过度工程工程实践系列导航上一篇AI Agent 工程实践11Workflow——Agent 如何完成复杂任务下一篇AI Agent 工程实践13Tool Calling——Agent 为什么要学会用工具本文是 [AI Agent 工程实践] 系列的第 12 篇第二季 · 工程实现。去年我一口气加了 5 个 Agent。大家都很忙。Planner 在拆任务Executor 在等 PlanReviewer 在等结果Reporter 在等审查通过Coordinator 在等所有人回复。结果呢一分钟能写完的功能Agent 们互相聊了十分钟最后 Planner 给了 Executor 一个错的步骤索引Reviewer 批评了 ExecutorExecutor 回怼了 Planner——项目没做完Agent 们倒先吵起来了。我把它关了。一个 Agent五分钟后搞定了。这不是段子——太多人陷进同一个坑五个 Agent 互相聊天不如一个 Agent 安安静静干活。这一篇用真实失败讲清楚什么时候该拆什么时候拆了就是灾难。本文你将学到✓ Multi-Agent 最常见的三种失败模式——以及它们为什么几乎无法避免✓ Single / Workflow / Multi-Agent 的终极决策框架不是能不能拆是拆了是否更高效✓ 拆 Agent 的三条硬标准——满足其中两条才值得考虑✓ 同一个任务三种架构的代码量、延迟、出错率直观对比适合阅读✓ 正打算上 Multi-Agent、觉得Agent 越多越高级的人✓ 已经拆了多 Agent、发现全在互相传消息的人✓ 读过第 08 篇和第 11 篇、想用实战验证理论的人问题背景Multi-Agent 是这几年最容易被架构冲动绑架的概念。教程画着精美的 Agent 交互图开源项目用 CrewAI / AutoGen 搭出多智能体协作的 demo——看起来很高级。但上线后的故事很少人讲。我调研了十几个公开的 Multi-Agent 项目GitHub 社群讨论发现一个让人不安的规律正式环境里跑下来的屈指可数。多数项目在 demo 之后进入了漫长的调通信地狱最终被简化回单 Agent。失败不是因为理念不对而是因为拆 Agent 引入了三个几乎无法同时解决的矛盾通信开销 业务产出。N 个 Agent 就意味着 N(N-1)/2 条潜在通信链路。当 Agent 之间传递消息的时间占比超过实际工作时间系统就在空转。状态一致性问题。三个 Agent 各自维护自己的上下文A 改了一个决定的参数B 不知道C 按旧参数执行——结果互相矛盾。这在分布式系统里叫脑裂是经典难题不是加个消息队列就能解决的。错误传播放大。单 Agent 错一步最多产出差一点。Multi-Agent 里 A 错一步B 基于错误输出继续做C 又基于 B 的错误做——错误链式放大根因极难追溯。一句话Multi-Agent 不是免费的架构升级。它是分布式系统而分布式系统天然贵。很多项目付了分布式的代价却没拿到任何分布式的收益——因为任务本身根本不需要并行不需要隔离不需要异构。三个真实失败模式失败模式 1击鼓传花场景5 个 Agent 做客服系统——IntentAgent 识别意图 → RouterAgent 分发 → HandlerAgent 处理 → KnowledgeAgent 查知识库 → ReplyAgent 回复。实际发生了啥IntentAgent 把我想退单传给了 RouterAgentRouterAgent 等了 3 秒给了 HandlerAgentHandlerAgent 返回请先确认订单号RouterAgent 再传给 IntentAgent用户已经关了窗口。问题5 个 Agent 里真正做事的只有 HandlerAgent 和 KnowledgeAgent。其余 3 个的全部工作就是把上一条消息转给下一个。这不是协作这是击鼓传花——花到谁手里早就凉了。失败模式 2死锁等待场景Planner Executor Reviewer 三角色。Planner 出计划后等 Executor 执行Executor 执行后等 Reviewer 审查Reviewer 发现问题要 Planner 出修正计划Planner 在等 Executor 的当前状态——循环等待。实际发生了啥三个 Agent 都在等别人先动卡了 3 分钟直到超时。单 Agent 模式下同一个人先规划再执行再自查顺序清晰不存在等别人的问题。问题Agent 之间产生了循环依赖。单 Agent 是我做完给你多 Agent 是我们在同一时间互相依赖。后者需要精细的调度机制而多数项目根本没设计这一层。失败模式 3上下文膨胀场景10 个 Agent 各自加载了 2000 字的上下文再加上互相传递的消息历史一次完整任务的总 token 消耗是单 Agent 的 8 倍。实际发生了啥月账单出来发现 Agent 系统比人工客服还贵。10 个 Agent 的智能被 10 份重复的上下文吃掉了全部预算。问题Multi-Agent 的 token 成本不是加法是乘法——每个 Agent 的上下文 历史消息 中间产物不只是贵了 10 倍而是10 份上下文互相引用后指数膨胀。关键观察我把拆了之后真有用的和拆了之后灾难道的项目做了对比差异只有一个项目拆多 Agent 的理由结果代码生成 安全审查安全审查需要独立上下文才能客观✅ 成功多源研究 并行爬取三个数据源需要并行拉取✅ 成功客服五件套只是因为角色不同❌ 击鼓传花Planner-Executor-Reviewer只是因为步骤多❌ 死锁等待五个 Agent 互相聊天不如一个 Agent 安安静静干活。65% 的 Multi-Agent 项目根本不该拆——它们的多 Agent 需求一个 Workflow 或几个 Skill 就能搞定。真正的拆解标准不是能不能拆而是拆了是否比不拆更高效。判断标准只有三条——必须满足其中两条才值得拆需要并行——不拆就是串行等延迟不可接受需要上下文隔离——不拆就无法保持独立判断如安全审查需要异构模型/工具——不拆就把不适配的东西强行塞进同一个 Agent只是步骤多不算——那是 Workflow11 篇。只是角色不同不算——那是 Skill07 篇。只是在 GitHub 上看别人都在拆——那是跟风。最终方案Single / Workflow / Multi-Agent 决策框架三条路径的适用条件路径适用条件典型任务Single Agent单步 or 简单多步一个上下文装得下问答、简单代码、翻译Single Workflow多步、有依赖、有分支但不需要并行/隔离需求→设计→实现→测试Multi-Agent真的需要并行 隔离 异构中的 ≥2 项安全审查、多源并行研究绝大多数任务停在前两档。第三档是给真有并行和隔离需求的场景——不是给看起来需要专业化分工的场景。实际收益同一个任务三种实现指标5 Agent击鼓传花Single AgentSingle Workflow代码量~500 行~50 行~120 行延迟~45s~8s~15sToken 消耗~12K~2K~4K出错率高通信/同步低低维护难度高低中架构图 / 流程图拆之前要过的三道闸stateDiagram-v2 [*] -- 先写Single: 默认从这里开始 先写Single -- 跑通再说: 单 Agent 能完成吗 跑通再说 -- 试行Workflow: 步骤太多/要回退 试行Workflow -- 再问自己: 真的需要并行/隔离 再问自己 -- 拆: 是的没别的办法了 再问自己 -- 不拆: 其实 Workflow 就够了每一道闸都是一次自我拷问不是在问卷上打勾。回答不了拆了解决什么单 Agent 解决不了的问题就别过下一道闸。代码或配置示例同一个任务——实现代码审查 安全检测——三种写法写法 1Single Agent直接干result agent.run(审查这段代码的安全性) # 10 行 prompt秒出结果写法 2Single Workflow有步骤但一个 Agentplan agent.run(task, skillplanning) # 拆分检查项 code_review agent.run(plan[0], skillreview) # 代码质量 security agent.run(plan[1], skillsecurity) # 安全检查 report agent.run([code_review, security], skillreport) # 30 行清晰、可回退、一个 Agent写法 3Multi-Agent拆了三个 Agentplan planner.run(task) # Planner Agent code code_reviewer.run(plan.tasks[0]) # Coder Agent sec security_bot.run(plan.tasks[1]) # Security Agent # 中间还要写 # - 消息队列传递 plan → code → sec # - 状态同步plan 改了参数要通知 code 和 sec # - 异常处理sec 挂了要不要回退 code # - 上下文合并两个 Agent 的审查结果怎么合并 # 200 行而且 90% 是通信/同步代码对比触目惊心同样的任务Multi-Agent 的代码量是 Workflow 的 5 倍但业务逻辑完全一样。多出来的那 150 行不是在审查代码是在帮 Agent 们传话——这就是击鼓传花的本质。设计权衡候选方案优点缺点不选/选它的条件一上来 Multi-Agent架构图好看通信/同步/调试成本指数级65% 的项目根本不需要永远不拆简单真遇到并行/隔离需求会被卡住矫枉过正渐进演化先单再拆成本可控每步有验证需要迭代时间选择理由唯一避免过度工程又留足扩展空间的路径最后一句话如果你现在正在搭一个 Multi-Agent 系统停下来问自己——如果没有这 N 个 Agent用一个 Agent Workflow 会不会更简单 如果答案是会那就别拆。总结✅ Multi-Agent 最常见的失败击鼓传花传消息比做事多/ 死锁等待互相依赖卡死/ 上下文膨胀token 成本爆炸。✅ 65% 的 Multi-Agent 项目不该拆——步骤多该用 Workflow角色不同该用 Skill不是 Agent。✅ 拆 Agent 的三条硬标准满足两条才拆需要并行 / 需要上下文隔离 / 需要异构模型。✅ 决策路径Single →步骤多→ Workflow →真需并行/隔离→ Multi-Agent。默认停在第一档。✅ 拆之前问自己拆了解决什么单 Agent 解决不了的问题 答不上来就别拆。参考资料Anthropic — Building Effective Agents→ Start simple, add complexity only when needed本文决策框架的直接来源第 08 篇Workflow / Multi-Agent怎么选→ 三档渐进理论本文的是什么前置第 11 篇Workflow 实现→ Workflow 怎么做本文拆之前先用 Workflow的技术基础第 07 篇Skills vs Prompt→ 角色不同用 Skill 而不是 Agent本文判据的概念来源Distributed Systems (Kleppmann)→ 分布式系统的通信开销、脑裂与一致性Multi-Agent 天然继承的经典难题系列导航上一篇AI Agent 工程实践11Workflow——Agent 如何完成复杂任务下一篇AI Agent 工程实践13Tool Calling——Agent 为什么要学会用工具本文是 [AI Agent 工程实践] 系列的第 12 篇第二季 · 工程实现。