1. 多 Agent 协作到底在解决什么问题1.1 从单 Agent 的能力天花板说起单个 Agent 的能力上限其实在真实业务里暴露得非常快。我最早做智能客服工单分类的时候一个 Agent 挂上提示词、接上知识库、再配几个工具看起来什么都能干。但一旦任务链条拉长比如“识别用户意图 → 查询订单状态 → 判断是否符合退款条件 → 生成回复 → 记录工单”单 Agent 就开始出现典型的“上下文污染”前面查订单的中间结果会干扰后面判断退款条件的推理工具调用的返回值太长把系统提示词挤到了窗口边缘更麻烦的是你没法单独优化其中某一步因为所有逻辑都揉在一个提示词里。这就是多 Agent 协作要解决的第一性问题把一个大而全的智能体拆成多个职责单一、边界清晰的小智能体让每个小智能体只关心自己那一亩三分地。听起来像微服务架构的思路实际上本质就是如此。单 Agent 像一个全栈工程师什么都能干但什么都不精多 Agent 像一个分工明确的团队每个角色只做自己最擅长的事。但这里有个关键认知多 Agent 不是“多个 Agent 简单堆在一起”。我见过太多项目把三个 Agent 串成一条链就宣称自己是多 Agent 系统。结果跑起来发现Agent A 的输出格式 Agent B 解析不了Agent B 的中间状态 Agent C 拿不到最后整个流程比单 Agent 还脆弱。问题出在哪出在边界没有定义清楚。1.2 边界才是多 Agent 协作的真正核心“边界”这个词听起来抽象落到工程上其实非常具体。一个多 Agent 系统里至少存在四层边界职责边界哪个 Agent 负责什么任务不负责什么任务。比如“检索 Agent”只负责从知识库拉取相关文档不做总结“总结 Agent”只负责把文档压缩成要点不做事实判断。数据边界Agent 之间传递什么数据、用什么格式、字段有哪些、哪些字段是必填、哪些可以为空。这层边界不定义清楚就会出现“A 给了 B 一个字符串B 以为是个 JSON”的经典事故。状态边界哪些状态是全局共享的哪些是 Agent 私有的。全局状态放哪里、怎么读写、并发时怎么保证一致性这些不解决多 Agent 跑起来就是一团乱麻。控制边界谁来决定下一个执行哪个 Agent是固定流程还是动态路由失败重试由谁负责超时怎么处理。我个人的经验是多 Agent 项目失败八成不是模型不够强而是边界没画好。模型能力可以靠换更强的模型解决但边界问题只能靠工程手段解决。这也是为什么我把标题定为“一场关于边界的工程学”——多 Agent 协作的本质不是 AI 问题是软件工程问题。1.3 哪些场景真的需要多 Agent不是所有任务都值得上多 Agent。我总结了一个简单的判断标准场景特征适合单 Agent适合多 Agent任务步骤1-3 步4 步以上上下文长度短单次可容纳长需要分段处理职责差异同质化明显异质化可并行性无有独立子任务调试需求低需要单独调试某一步工具数量少于 5 个多于 5 个且分类明显举个具体例子。简历筛选工作流就是一个典型的多 Agent 场景解析简历 Agent 负责把 PDF/Word 转成结构化数据匹配度评估 Agent 负责对照 JD 打分风险审查 Agent 负责检查履历中的疑点最后汇总 Agent 生成面试建议。这四个 Agent 职责完全不同用的工具也不同拆开之后每个都能单独调优。如果你硬塞进一个 Agent提示词会长到难以维护而且解析简历的噪声会干扰匹配度评估的准确性。反过来像“把一段中文翻译成英文”这种任务单 Agent 就够了拆成多 Agent 纯属过度设计。我见过有人把翻译拆成“分词 Agent → 翻译 Agent → 润色 Agent”结果延迟翻了三倍效果还不如直接调一次翻译 API。2. 多 Agent 协作的四种主流编排模式2.1 顺序链式最简单也最容易踩坑顺序链式就是 Agent A 输出给 Agent BB 输出给 C像流水线一样。这种模式最容易理解也最容易实现但坑也最多。最大的坑是错误累积。假设每个 Agent 的准确率是 90%三个 Agent 串起来端到端准确率就变成 0.9 × 0.9 × 0.9 72.9%。四个 Agent 就掉到 65.6%。这就是为什么链式编排里每个环节的可靠性必须做得非常高或者要在关键节点加校验。第二个坑是格式漂移。A 输出的是 Markdown 列表B 期望的是 JSON 数组中间没有转换层直接报错。我的做法是在每个 Agent 的输出端强制加一个“格式化校验”步骤用代码而不是模型来保证格式。比如要求 Agent 输出 JSON就用 JSON Schema 校验不通过就重试重试三次还不行就降级到规则解析。第三个坑是上下文膨胀。链式传递时如果把所有历史输出都往下传到第四个 Agent 时上下文已经爆了。正确做法是每个 Agent 只接收自己需要的最小上下文而不是全量透传。这一点后面讲状态管理时会展开。2.2 路由分发让合适的 Agent 做合适的事路由模式的核心是有一个“调度 Agent”或“路由器”根据输入决定交给哪个下游 Agent 处理。这比链式灵活得多适合任务类型不确定的场景。比如一个客服系统用户输入可能是咨询、投诉、退款、技术支持中的任意一种。用一个路由 Agent 先分类再分发给对应的专业 Agent每个专业 Agent 的提示词和工具都可以针对性优化。这比一个 Agent 硬扛所有类型效果好得多。路由模式的关键设计点是路由决策的可靠性。路由错了后面全错。我的经验是路由 Agent 不要用开放式生成而是用分类任务输出限定在几个枚举值里。如果分类置信度低于阈值就走“兜底 Agent”或者转人工。另外路由决策最好记录日志方便事后分析哪些输入容易被误分类。2.3 并行聚合用并发换时间有些任务可以拆成互不依赖的子任务同时执行再汇总。比如分析一份财报可以同时让“财务指标 Agent”算比率、“风险 Agent”查异常项、“舆情 Agent”拉外部评价最后“汇总 Agent”合并三份结果。并行聚合的工程难点在结果合并。三个 Agent 的输出格式不同、粒度不同合并时容易出现信息冲突。比如财务 Agent 说“营收增长 20%”舆情 Agent 说“市场预期增长 25%”汇总 Agent 要能识别这种冲突并给出合理表述而不是简单拼接。我的做法是给并行 Agent 定义统一的输出契约比如都输出{结论, 置信度, 证据, 数据来源}四元组汇总 Agent 按契约解析冲突时按置信度加权或标注分歧。这样合并逻辑就是确定性的代码而不是靠模型即兴发挥。2.4 层级编排复杂任务的终极形态当任务复杂到一定程度就需要层级编排顶层有一个“主管 Agent”负责规划和分解中层有若干“领域 Agent”负责执行子任务底层有“工具 Agent”负责具体操作。这其实就是把组织架构搬到了 AI 系统里。层级编排最考验的是任务分解的质量和状态回传的完整性。主管 Agent 把任务拆给下属后要能跟踪每个子任务的进度、收集结果、处理失败。这已经非常接近一个工作流引擎的职责了。实际落地时我建议不要一上来就搞三层先从两层开始跑通了再往下加。3. 状态管理多 Agent 协作的隐形战场3.1 为什么状态管理最容易出问题多 Agent 系统里状态管理是最不显眼但最致命的部分。单 Agent 时状态就是对话历史简单明了。多 Agent 时状态变成了一个分布式问题每个 Agent 有自己的局部状态Agent 之间有共享状态还有全局的流程状态。我踩过最惨的一次坑是两个 Agent 并发写同一个共享状态字段结果后写的覆盖了先写的导致流程判断出错。排查了半天才发现是并发问题。从那以后我在设计多 Agent 系统时第一件事就是画状态图哪些状态是只读的哪些是可写的谁写谁读并发时怎么加锁。3.2 三种状态管理方案对比方案实现方式优点缺点适用场景消息传递Agent 之间直接传消息简单、解耦状态分散、难追踪简单链式共享内存全局字典/对象读写方便并发风险、难持久化单机短流程外部状态存储Redis/数据库可持久化、可追踪增加依赖、有延迟生产级系统我现在的默认选择是外部状态存储 消息传递混合Agent 之间的即时通信走消息传递关键状态落外部存储。这样既保证了灵活性又保证了可恢复性。比如流程跑到一半服务重启从外部存储恢复状态就能继续跑而不是从头再来。3.3 状态设计的三条实操原则第一条原则状态字段宁少勿多。每加一个字段就多一个需要维护、需要同步、可能出错的地方。我见过一个项目共享状态里有 40 多个字段结果没人说得清哪些字段在什么时候被谁改了。后来重构砍到 12 个字段问题少了一大半。第二条原则状态变更必须可追溯。每次状态修改都记录 who、when、what、why。这在调试时价值巨大。我通常会在状态存储里加一个change_log列表记录每次变更的快照和原因。出问题时回放日志很快就能定位到是哪一步改坏的。第三条原则状态要有版本号。并发写入时用乐观锁读的时候拿版本号写的时候检查版本号有没有变变了就重试。这比悲观锁性能好实现也不复杂。4. 编排引擎选型从手写代码到专业框架4.1 手写编排的适用边界刚开始做多 Agent 时很多人选择手写编排逻辑一个 Python 函数里 if-else 判断下一步调哪个 Agent。这在 Agent 数量少于 3 个、流程固定时完全够用而且调试直观。但手写编排有几个明显的天花板流程一变就要改代码没有可视化失败重试要自己实现并发控制要自己处理。我一般建议原型阶段手写生产阶段上框架。手写用来验证想法框架用来支撑规模。4.2 主流编排框架的取舍市面上编排框架很多我按自己的使用体验做个对比框架类型代表优势适合谁代码优先LangGraph、AutoGen灵活、可版本控制有工程能力的团队可视化Dify、Coze、n8n上手快、易演示快速验证、非技术用户工作流引擎Temporal、Airflow可靠、可观测生产级长流程自研基于状态机完全可控有特殊需求的团队我的实际选择是用 LangGraph 做 Agent 编排用 Temporal 做流程持久化。LangGraph 负责 Agent 之间的图结构编排Temporal 负责整个流程的可靠执行和重试。两者结合既有灵活性又有可靠性。如果你是非技术背景想快速搭一个多 Agent 工作流Dify 和 Coze 是很好的起点。它们的可视化编排能让你在半小时内跑通一个多 Agent 流程。但要注意可视化工具在复杂状态管理和自定义逻辑上会有局限规模上去后可能需要迁移到代码方案。4.3 编排引擎的核心能力清单不管选哪个框架我都会检查它是否具备这几个核心能力条件分支能根据 Agent 输出动态决定下一步循环与重试支持失败重试、最大次数限制、退避策略并行执行支持 fan-out/fan-in状态持久化流程中断后能恢复可观测性能看到每个 Agent 的输入输出、耗时、token 消耗人工介入支持在关键节点暂停等待人工确认缺了任何一项在生产环境都会变成痛点。特别是可观测性我强烈建议在项目初期就接上追踪系统否则出了问题只能靠猜。5. 实操搭一个简历筛选多 Agent 工作流5.1 整体架构设计我用简历筛选这个场景完整走一遍多 Agent 工作流的搭建过程。这个场景足够典型任务链条长、职责异质化明显、有并行空间、需要状态管理。整体架构分四层接入层接收简历文件PDF/Word和 JD 文本解析层简历解析 Agent把文件转成结构化 JSON评估层匹配度 Agent、风险审查 Agent、亮点提取 Agent三个并行汇总层汇总 Agent合并三份评估结果生成面试建议状态设计上我用一个ScreeningState字典贯穿全程包含resume_raw、resume_parsed、jd_text、match_score、risk_flags、highlights、final_report等字段。每个 Agent 只读写自己负责的字段避免越界。5.2 关键步骤与参数配置第一步是简历解析。这里我不用模型直接解析 PDF而是先用pdfplumber或python-docx提取纯文本再让模型做结构化。原因是模型直接读 PDF 容易漏内容而且 token 消耗大。提取文本后再结构化准确率和成本都更优。解析 Agent 的输出契约我定义为{ name: string, years_of_experience: number, skills: [string], work_history: [{company: string, role: string, duration: string}], education: {degree: string, school: string}, parse_confidence: number }parse_confidence是解析置信度低于 0.7 时触发人工复核。这个字段很关键它让系统知道自己什么时候不确定。第二步是并行评估。三个 Agent 同时跑每个接收resume_parsed和jd_text输出各自的评估结果。匹配度 Agent 输出 0-100 的分数和理由风险审查 Agent 输出风险项列表亮点提取 Agent 输出亮点列表。并行执行用asyncio.gather实现三个 Agent 的调用并发发出。实测下来并行比串行快 2.5 倍左右因为三个 Agent 的耗时差不多并行几乎省掉了两次等待。第三步是汇总。汇总 Agent 接收三份结果生成最终报告。这里有个技巧汇总 Agent 的提示词里要明确要求它标注分歧。比如匹配度 Agent 给了 85 分但风险审查 Agent 发现了履历时间线矛盾汇总时要明确指出这个矛盾而不是简单给个平均分。5.3 状态流转与异常处理整个流程的状态流转是这样的init → parsing → evaluating → aggregating → done。每个状态转换都记录到状态存储里附带时间戳和 Agent 输出摘要。异常处理我设了三层Agent 级重试单个 Agent 调用失败重试 3 次指数退避流程级降级某个评估 Agent 连续失败跳过它继续最终报告标注“该项评估缺失”全局兜底整个流程超时我设的是 120 秒返回已完成的中间结果并标注未完成项这套异常处理跑下来系统在部分 Agent 故障时仍能产出可用结果而不是整个流程崩掉。6. 常见问题与排查技巧实录6.1 Agent 之间格式不兼容怎么办这是最高频的问题。A 输出 MarkdownB 期望 JSON直接报错。我的解决方案是在 Agent 输出端加格式化层Agent 生成后用一个轻量的解析函数尝试提取结构化数据提取失败就触发重试重试时在提示词里强调“只输出 JSON不要任何其他文字”。更彻底的做法是用 Function Calling 或 Structured Output 能力让模型直接输出符合 Schema 的结构化数据。OpenAI 和国内主流模型都支持这个能力能大幅降低格式问题。如果模型不支持就退回到“生成 解析 重试”的方案。6.2 上下文超长怎么处理多 Agent 链式传递时上下文很容易爆。我的处理策略是分层压缩原始输入只在第一个 Agent 完整可见中间 Agent 只接收上游的摘要不接收全文关键数据用结构化字段传递不用自然语言每个 Agent 的输出限制长度超长就截断并标注另外如果用的是 Dify 这类工具注意它的上下文窗口配置。我遇到过 Dify 工作流因为上下文超长导致后续节点拿不到数据的情况排查后发现是中间节点的输出没有正确传递。解决办法是在每个节点显式声明输入输出变量不要依赖隐式传递。6.3 排查速查表现象可能原因排查方向流程卡住不动Agent 调用超时未处理检查超时配置和重试逻辑输出格式错乱提示词约束不够加格式化层或换 Structured Output结果前后矛盾状态被并发覆盖检查共享状态读写锁某个 Agent 总失败输入不符合预期打印该 Agent 的实际输入整体延迟高串行执行可并行任务改并行检查依赖关系成本超预算上下文过长或重试过多压缩上下文限制重试次数6.4 几条踩坑换来的经验第一条先跑通再优化。我见过太多人一上来就追求完美架构结果两周还没跑通一个流程。正确做法是先用手写编排跑通最小闭环再逐步替换成框架、加状态管理、加异常处理。第二条每个 Agent 都要能单独测试。设计时就让每个 Agent 的输入输出可独立构造和验证这样出问题时能快速定位是哪个 Agent 的问题而不是整个流程一起调。第三条日志要记全。每个 Agent 的输入、输出、耗时、token 消耗、重试次数全部记录。这些数据在优化时价值巨大。我通常会把日志接到一个简单的看板上随时能看到流程的健康状况。第四条不要迷信 Agent 数量。多 Agent 不是越多越好每多一个 Agent 就多一份协调成本。我的一般原则是能用 3 个 Agent 解决就不用 5 个能合并的职责就合并。边界的清晰度比 Agent 的数量重要得多。第五条人工介入点要提前设计。生产系统里纯自动化的多 Agent 流程很少能 100% 可靠。在关键决策点留人工确认入口比如简历筛选的最终录用建议、财务审批的最终放款这些地方人工介入不是退步是负责任的设计。7. 边界工程学的几条底层原则7.1 职责单一接口明确每个 Agent 只做一件事做好一件事。Agent 之间的接口用 Schema 定义不靠自然语言约定。这跟微服务的设计原则一模一样高内聚、低耦合。我见过一个反例一个 Agent 既做意图识别又做实体抽取还做回复生成结果三个任务的提示词互相干扰哪个都做不好。拆成三个 Agent 后每个的准确率都上去了。7.2 状态最小化变更可追溯共享状态能少则少每个字段都要有明确的 owner。状态变更记录日志支持回放。这条原则的价值在调试时体现得最明显当流程出错时你能精确知道是哪个 Agent 在哪一步改了哪个字段而不是面对一团黑盒。7.3 失败是常态降级是能力多 Agent 系统里单个 Agent 失败是必然事件。设计时就要假设“这个 Agent 可能会挂”准备好降级方案。能跳过的跳过能兜底的兜底能转人工的转人工。一个健壮的多 Agent 系统不是永不失败的系统而是失败后仍能产出可用结果的系统。7.4 可观测性优先于功能在加新功能之前先把可观测性做好。每个 Agent 的调用链路、耗时、token 消耗、成功率都要能看到。没有可观测性优化就是盲人摸象。我现在的习惯是新项目第一周不写业务逻辑先把日志、追踪、看板搭好后面开发效率反而更高。这套边界工程学的方法论我在几个项目里反复验证过。从简历筛选到客服工单从内容审核到数据分析核心思路是一致的把复杂问题拆成边界清晰的子问题用工程手段保证子问题之间的协作可靠。模型能力会不断进化但边界设计的工程原则不会过时。这也是我认为多 Agent 协作最值得投入学习的地方——它考验的不是提示词技巧而是系统设计能力。