发布时间2026-07-11标签AI AgentLLMMulti-AgentWorkflow架构设计工程实践系列导航上一篇AI Agent 工程实践07AI Agent 为什么需要 Skills而不是 Prompt下一篇AI Agent 工程实践09AI Engineering OS v2——系统如何持续演化本文是 [AI Agent 工程实践] 系列的第 08 篇。去年我做第一个正经 Agent 项目一上来就画了 5 个 AgentPlanner、Researcher、Coder、Reviewer、Reporter。架构图很漂亮我发朋友圈都有人点赞。然后我花了两周调它们之间的通信、状态同步、错误传播——最后发现这些活儿一个 Agent 加个 Workflow 半天就能干完。那 5 个 Agent 里有 4 个的全部工作就是把消息传给下一个。我踩的这个坑太多人正在踩一上来就上 Multi-Agent以为 Agent 越多越强。其实 80% 的项目单 Agent 就够了。本文你将学到✓ 为什么一上来就 Multi-Agent是最常见的过度工程✓ Single Agent → Workflow → Multi-Agent 的演进阈值在哪✓ Planner / Executor / Reviewer 什么时候值得真正拆开✓ 拆 Multi-Agent 的隐藏成本通信、状态、调试适合阅读✓ 打算做多 Agent 系统、但不确定要不要拆的人✓ 用 LangGraph / AutoGen / CrewAI 搭多智能体的开发者✓ 想避开为架构而架构这个坑的人目录[TOC]问题背景Multi-Agent 是这两年最被高估的概念。教程、demo、开源项目张口就是多智能体协作好像单 Agent 是上个时代的东西。于是新人包括去年的我形成一个错觉Agent 越多 系统越强。真做起来才发现拆多 Agent 引入了一堆单 Agent 根本没有的问题通信开销。Agent 之间要传消息、对齐格式光设计谁跟谁说话就够喝一壶。状态同步。每个 Agent 有自己的上下文一个改了状态其它怎么知道很容易各说各话。调试地狱。出错时是 Planner 规划错了Executor 执行错了还是消息在传递中丢了责任链一长根因难定位。成本翻倍。5 个 Agent 5 份上下文、5 次 LLM 调用token 和延迟成倍涨。一句话Multi-Agent 不是免费的架构升级它是有沉重代价的分布式系统。大多数时候你付了分布式的代价却没享受到分布式的收益。错误尝试第一次一上来就 5 个 Agent第一个项目我照着最佳实践画了 Planner/Researcher/Coder/Reviewer/Reporter 五件套。结果两周耗在 Agent 间通信和状态同步上真正的业务逻辑没写多少。最后复盘发现4 个 Agent 的实际工作就是把上一个的输出转给下一个——这不是协作这是击鼓传花。第二次全塞进一个 Agent 的巨型 Prompt矫枉过正我把 5 个 Agent 的活儿全塞进一个 Agent 的超长 prompt你要先规划再研究再写代码再审查……结果又回到第 02 篇和第 07 篇的老问题——prompt 爆炸、步骤互相干扰、模型在长流程里丢步骤。把多步流程压进一个 prompt不是单 Agent是没有编排的混乱。两次尝试指向同一个教训单 Agent 和多 Agent 之间缺了中间那一档——Workflow。大多数需要多 Agent的场景其实只需要单 Agent Workflow。关键观察我把做过的十几个 Agent 项目按实际需要的架构归了类项目复杂度实际需要占比单一任务问答、生成、审查Single Agent~50%多步但线性规划→执行→检查Single Agent Workflow~30%多步且需并行/异构专精才真正需要 Multi-Agent~20%pie title 项目实际需要的架构分布 Single Agent 就够 : 50 Single Workflow : 30 真需要 Multi-Agent : 2080% 的项目不需要 Multi-Agent。一上来拆多 Agent不是把系统做强了是把复杂度提前透支了。定位真正原因问题不在该不该用 Multi-Agent而在没有一个清晰的升级阈值——大家凭感觉高级来选架构而不是凭任务是否真的需要。正确思路是把架构选择变成一条渐进升级链每一档都有明确的触发条件Single Agent →步骤变多→ Workflow →需要并行/异构专精→ Multi-Agent默认从最简单的开始只有当前档位真扛不住了才升级到下一档。这和第 02 篇不要在不需要分层的地方强行分层、第 07 篇一次性任务就别抽 Skill是同一条原则先满足需求再谈架构升级。最终方案三档演进 拆分阈值第一档Single Agent默认起点什么时候用任务是单一的或多步但简单到一个上下文能装下。问答、代码生成、单文件审查——绝大多数任务属于这档。别被单字骗了配好 Rule 和 Skill 的单 Agent能力远超想象。这是默认档没有明确理由不要离开它。第二档Single Agent Workflow多步但线性升级信号任务有明确的多步骤且步骤之间有依赖先规划才能执行先执行才能检查。这时候不用拆 Agent——同一个 Agent按 Workflow 编排多步就行。Workflow 负责步骤顺序和状态传递Agent 负责每步执行。# workflow/code-task.yaml — 单 Agent 跑多步 agent: claude-code steps: - name: plan skill: task-planning - name: execute skill: code-generation - name: review skill: code-review # 同一个 Agent换 skill 跑不同步骤这一档能覆盖大多数看起来需要多 Agent的场景。90% 想拆 Agent 的冲动停在这里就够了。第三档Multi-Agent真正需要才拆升级信号满足其一才考虑需要并行——多个子任务能同时跑如同时研究 3 个技术方案单 Agent 串行太慢异构专精——不同步骤需要完全不同的模型/工具/上下文如一个用代码模型、一个用检索模型塞一个 Agent 里互相干扰独立上下文——步骤之间上下文必须隔离如审查者不该看到规划者的思路以保持独立判断这三条才是拆 Multi-Agent 的真正理由。只是步骤多不算——那是 Workflow 的活。Planner / Executor / Reviewer什么时候值得拆这是最经典的三角色。但它们不是必须三个 Agent多数时候是一个 Agent 的三个阶段Workflow。真正值得拆成独立 Agent 的判据角色值得拆成独立 Agent 的条件否则Planner规划需要独立探索、试错、长上下文会污染执行当作 Workflow 的第一步Executor需要专门的工具/模型或要并行多个当作执行步骤Reviewer必须独立上下文——不看执行者思路才能客观当作检查步骤其中Reviewer 是最有理由独立的——因为独立判断本身要求上下文隔离这正好命中第三条拆分信号。而 Planner 和 Executor多数时候留在同一个 Agent 里更省心。实际收益指标一上来 5 Agent按阈值渐进开发周期长耗在通信/同步短先跑通再升级调试难度高责任链长低单点定位Token/延迟成本高N 份上下文低按需拆架构合理性常过度匹配真实需求为主观估算非严格 A/B Test但反映了渐进升级对避免过度工程的作用。架构图 / 流程图三档架构的升级路径关键点每一档都是上一档扛不住了才升级。默认停在 Single Agent遇到多步升 Workflow只有命中并行/异构/隔离才拆 Multi-Agent。Planner-Executor-Reviewer 的两种形态图片多样性用了 Mermaid 的 pie / flowchart含 subgraph两种发文时可再补一张 ProcessOn/draw.io 版的决策树提升 CSDN 图片多样性得分。代码或配置示例同一个任务三档写法对比第一档 Single Agent——直接干result agent.run(task) # 就这么简单第二档 Single Workflow——多步但一个 Agentdef run_workflow(task, agent): plan agent.run(task, skillplanning) # 步骤 1 code agent.run(plan, skillcoding) # 步骤 2 review agent.run(code, skillreview) # 步骤 3 return review # 线性传递无跨 Agent 通信第三档 Multi-Agent——仅当需要隔离/并行def run_multi_agent(task): plan planner.run(task) # 独立 Agent # 并行执行多个子任务这才是拆的理由 results parallel([executor.run(sub) for sub in plan.subtasks]) # Reviewer 独立上下文不看 executor 的中间思路 return reviewer.run(results, contextisolated)对比很明显从第一档到第三档代码复杂度是跳级上升的。没有并行/隔离的真实需求第三档的复杂度就是纯亏。架构选择判定伪代码def choose_architecture(task) - str: 按真实需求选架构不凭感觉高级 if task.is_single_step or task.fits_one_context: return single_agent # 默认档 if task.is_linear_multi_step: return single_agent_workflow # 多步但线性 if task.needs_parallel or task.needs_isolation or task.needs_heterogeneous: return multi_agent # 才真正拆 return single_agent_workflow # 拿不准 → 保守选中间档最后一行是关键拿不准时选保守档。和第 05 篇 Fallback没把握就加载最少一个哲学——宁可欠配不可过度。设计权衡候选方案优点缺点为什么不选作为默认一上来 Multi-Agent架构高级、可并行通信/状态/调试成本高多数是过度工程80% 项目用不上代价白付全塞一个巨型 Prompt无需编排prompt 爆炸、丢步骤不是单 Agent是无编排的混乱三档渐进默认单 Agent匹配真实需求、成本可控需判断升级时机选择理由唯一避免过度工程又留足扩展空间的路径Multi-Agent 不是错的过早用才是错的。当你真的遇到并行、异构、上下文隔离的需求该拆就拆——那时它是解药。判断标准就一句不是能不能拆而是拆了到底解决什么单 Agent 解决不了的问题。答不上来就别拆。总结✅ 80% 的项目不需要 Multi-Agent——一上来就拆是最常见的过度工程。✅ 架构是三档渐进Single Agent默认→ Workflow多步线性→ Multi-Agent并行/异构/隔离每档扛不住才升级。✅ 大多数想拆多 Agent的冲动用单 Agent Workflow就能满足。✅ Planner/Executor/Reviewer 多数是一个 Agent 的三个阶段只有 Reviewer 因需独立上下文最有理由拆成独立 Agent。✅ 拆的唯一理由是解决单 Agent 解决不了的问题并行/异构/隔离答不上来就别拆。参考资料Anthropic — Building Effective Agents→ 从简单开始、按需增加复杂度本文渐进升级思想的直接来源LangGraph 官方文档 — Multi-Agent Patterns→ Multi-Agent 编排的工程实现与适用场景参考AutoGen / CrewAI 文档→ 多智能体协作框架理解拆分成本的实践对照第 02 篇为什么 Rules 要分层→ 不要在不需要的地方强行分层与本文反过度工程同源第 07 篇Skills vs Prompt→ Workflow 编排 Skill 的定义本文第二档的概念基础系列导航上一篇AI Agent 工程实践07AI Agent 为什么需要 Skills而不是 Prompt下一篇AI Agent 工程实践09AI Engineering OS v2——系统如何持续演化本文是 [AI Agent 工程实践] 系列的第 08 篇。