本文面向正在落地 LLM 应用的工程师系统梳理多 Agent 工作流的核心概念、编排模式、工程实践与常见陷阱。不堆砌概念只讲能用起来的东西。一、为什么需要多 Agent单个 LLM Agent 能做的事情是有限的。当你开始用它做真正复杂的任务时很快会遇到几个天花板上下文爆炸一个任务既需要读大量资料、又需要分析、还需要产出所有东西塞进一个上下文里token 越用越贵模型也开始「忘事」。职责混杂一个 Prompt 既要管调研、又要管写作、还要管审校指令之间互相干扰输出质量不稳定。能力边界有些任务天然需要「反思」「对比」「多角度审视」单个模型自问自答的效果远不如多个独立视角互相质询。可维护性差巨型 Prompt 改一处牵动全身难以测试和迭代。多 Agent 的核心思想很朴素像组织一个团队一样组织你的模型调用。把大任务拆成小角色让每个 Agent 专注一件事通过约定的方式通信、协作、交接。二、核心概念在开始写代码之前先明确几个反复出现的术语概念说明Agent一个有明确角色、目标、可用工具或技能和系统提示词的独立单元Orchestrator编排者决定「谁在什么时候做什么」可以是代码逻辑也可以是一个 Agent共享状态 / 黑板Agent 之间交换信息的公共存储内存、文件、数据库工具 / 技能Agent 可调用的外部能力如搜索、读写文件、执行代码、调用 API上下文传递上一个 Agent 的产出如何变成下一个 Agent 的输入终止条件什么时候停止协作避免无限循环这些概念本身不复杂真正决定成败的是如何组合。三、五种常见编排模式1. 顺序流水线Sequential Pipeline最简单的模式Agent A 的原始输出直接变成 Agent B 的输入像流水线一样。[ 撰写 ] → [ 审校 ] → [ 排版 ]适用场景任务可清晰分阶段后一步强依赖前一步。优点易实现、易调试、成本可控。缺点无法并行错误会一路向下传递。2. 并行分发Parallel Fan-out把一个任务拆成多个互不依赖的子任务同时分发最后汇总。┌─→ [调研 A] [ 调度 ] ──┼─→ [调研 B] └─→ [调研 C] ─→ [汇总]适用场景信息收集、多角度分析、独立模块的并行生成。优点速度快天然适合多视角。缺点需要一个靠谱的「汇总者」各分支质量参差不齐时需处理。3. 层级监督Hierarchical / Manager-Worker一个「管理者」Agent 负责任务分解、分配给「执行者」Agent并审核结果。不满足要求就打回重做。[管理者] / | \ [执行者1][执行者2][执行者3] \ | / [结果汇总]适用场景任务复杂、需要质量把关、子任务较多。优点质量可控有天然的「质检」环节。缺点层级越深延迟和 token 成本越高。4. 协作辩论Collaborative Debate / Reflection多个 Agent 分别从不同立场表达观点互相质询最终由「仲裁者」给出结论。[正方] ⇄ [反方] ↓ 汇总观点 ↓ [仲裁者 / 综合者]适用场景方案选型、风险评估、需要对抗性思维的决策场景。优点能显著减少「一言堂」的盲区。缺点成本高容易陷入无意义的来回拉扯必须有明确终止条件。5. 迭代循环Iterative Loop执行 → 检查 → 反馈 → 再执行直到满足退出条件。[生成] → [评分] → 达标? ──否──→ [反馈/修订] → [生成] └──是──→ [输出]适用场景代码生成、文案优化、任何「先出草稿再打磨」的任务。优点质量收敛效果好。缺点循环次数必须设上限否则烧钱又不见得更好。实际项目中很少只用一种模式通常是混合编排外层是顺序流水线某个环节内部用并行分发生成环节再叠加迭代循环。四、一个端到端实践案例以一个「技术博客写作」任务为例说明如何组合上述模式。任务目标根据给定主题产出一篇结构完整、事实准确、可直接发布的博客文章。编排设计┌─→ [信息调研 Agent] [主题 大纲] → [调度] ─┼─→ [竞品/资料 Agent] ─→ [汇总 Agent] └─→ [案例搜集 Agent] │ ↓ [撰写 Agent] ← [大纲 素材] ↓ [审校/事实核对 Agent] ↓ (不达标则回退) [排版 Agent] ↓ [最终输出]关键实现要点角色分离调研 Agent只负责「找信息和提炼」提示词里禁止它写正文。撰写 Agent只负责「基于给定素材写作」不负责扩搜索。审校 Agent只负责「挑毛病」输出结构化的问题清单而不是改好的文章。结构化交接不要让 Agent 之间传「一大段自然语言」。用结构化数据交接{outline:[一、背景,二、方案,三、总结],facts:[{claim:Python 3.12 发布,source:https://...,confidence:0.9}],requirements:面向工程师篇幅 2500 字中文}带「评分」的迭代终止条件审校 Agent 不只输出意见还要给一个score0–10和blocking_issues列表。仅当score 8或迭代次数到达 3 次时才停止避免无限返工。事实核对的「证据约束」要求审校 Agent 标出每个关键事实是否有来源支撑未标注来源的断言默认降级为「作者观点」防止模型一本正经地胡说。成本与质量的平衡实测经验同样的写作任务多 Agent 协作比单 Agent 一次生成token 成本约高出 1.5–3 倍但「事实错误率」和「结构散乱率」显著下降。多 Agent 不是免费的午餐它买的是质量和可控性。五、常见陷阱与对策1. 上下文爆炸现象层层传递时把历史对话全文转发越往后 token 越贵。对策传递「提炼后的结构化结果」而非「原始对话」长文档用摘要或索引需要细节时再针对性检索。2. 职责越权现象撰写 Agent 偷偷把审校的活也干了或审校 Agent 把文章重写一通。对策在系统提示词里明确「你只能做什么、禁止做什么」并约定输出格式必要时用代码层校验输出结构。3. 错误级联现象上游一个错误事实下游全部基于它发挥越错越离谱。对策关键事实要求附带source下游 Agent 对上游输入做「可信度标注」而非全盘接受。4. 无限循环 / 来回拉扯现象两个 Agent 意见不合陷入无限辩论。对策显式设置最大轮次引入「仲裁者」一票终止约定辩论新增信息量太低就强制结束。5. 可观测性不足现象出了问题不知道是哪个 Agent、哪一步错的。对策为每个 Agent 的输入/输出打日志记录 token 消耗、耗时、迭代次数给每一步一个唯一 ID。六、工具与框架选型工具/框架特点适合LangGraph图结构编排状态管理清晰支持循环与分支需要精细控制流程的工程团队AutoGen多 Agent 对话天然内置开箱即用快速验证多 Agent 对话场景CrewAI角色化抽象Agent/Task/Crew易上手中小项目、快速原型自研编排完全可控无框架束缚对流程与成本有极致要求的团队选型的核心判断不是「哪个框架最火」而是你需要的是「对话式协作」还是「流程式编排」。前者适合 AutoGen 类后者适合 LangGraph 或自研。七、总结多 Agent 工作流的价值不在于「堆更多的模型」而在于把复杂任务拆解成可管理、可测试的小单元用明确的角色和协议取代含糊的巨型 Prompt用结构化的交接和显式的终止条件换取工程上的可控性。落地时记住几个原则先从最简单的流水线开始验证有效后再加并行和迭代让交接结构化给每个 Agent 划清边界永远设置终止条件。多 Agent 不是银弹但当你把「团队协作的思维方式」用在模型编排上时很多原本做不动的复杂任务会突然变得可拆、可做、可交付。