多Agent协同实战：WorkBuddy工作流编排、上下文隔离与稳定性指南

上个月我接了个全栈小需求让单个 Agent 从头跑到尾结果前两步很顺利到第三步它开始和上下文里的旧方案较劲改了这个忘了那个最后交上来的接口文档和实现完全对不上。这个问题的根源不是模型能力不够而是单 Agent 的工作方式天然不适合多阶段任务。《WorkBuddy 实战蓝皮书》系列前几篇我们解决了安装、Skill 封装、工作台搭建这些基础操作这一篇专门聊多 Agent当任务复杂到一定程度怎么让多个 Agent 各司其职地协同而不是让它们在一段共享上下文里互相打架。这篇文章适合已经跑通 WorkBuddy 基础流程、正在尝试把它用在真实项目中的朋友读完你会对 Agent 的拆分方式、编排模式、通信和记忆机制有完整认知也能直接照着搭出第一个多 Agent 流水线。1. 为什么单 Agent 会把简单任务做成车祸现场1.1 单 Agent 真正的问题不是笨是上下文被挤爆很多人以为多 Agent 是为了让多个模型“一起商量”其实大部分场景要解决的只是上下文管理问题。单个 Agent 在执行多阶段任务时所有历史信息——原始需求、中间产物、错误日志、临时的猜测——全都会被塞进同一段上下文里。上下文窗口是有限的越往后真正重要的信息在注意力中的占比就越低。我用一个生活化的类比解释你请了一个全能助理让他同时当产品经理、开发、测试。他刚写完需求文档马上又要写代码转头还要自己验收自己的成果。人的短期记忆一乱就会开始自己反驳自己前面说要按 A 方案做后面写着写着觉得 B 方案更好于是代码改了需求文档却没同步最后交付的东西和约定完全不一致。单 Agent 遇到的正是这个问题而且上下文窗口越长这种“自我打架”出现的概率越高。还有一个容易被忽略的坑工具操作也在同一个上下文里累积。Agent 在步骤一里读了一整个大型代码仓库这些文件内容会留在上下文里步骤二它去修改其中一个文件但步骤三要做决策时它看到的还是旧的文件内容快照。这个“过期信息污染”问题单 Agent 在长链路任务里几乎无解。1.2 一场对照组实测同一需求单 Agent 六小时四 Agent 三小时我不想空谈原理上个月我用同一个需求跑了一组对照实验。需求是给内部工具加一个“答题统计”模块包含数据采集、按维度聚合、前端图表展示三块内容。我先用单 Agent 全权负责再拆成四个 Agent 流水线跑了一遍结果如下指标单 Agent四 Agent 流水线首次可用产出4 小时后2 小时后返工次数4 次2 次需求理解偏差出现 2 次出现 0 次最终交付耗时约 6 小时约 3 小时单 Agent 返工集中发生在“前端图表展示”阶段它为了适配图表库悄悄把后端返回的数据结构改了但没有通知任何人——因为“其他人”就是它自己。四 Agent 流水线里后端 Agent 和前端 Agent 的接口协议是提前约定好的后端只输出 JSON前端只消费 JSON想改结构必须回到“接口设计”节点重新审批这个流程墙直接消灭了这类问题。我并不是说多 Agent 一定快一倍但这组数据说明当任务存在明显的阶段边界和交付物交接时把工作拆开让每个 Agent 只看自己需要的输入效率会高很多。1.3 什么时候老老实实用单 Agent 就够了多 Agent 不是银弹它引入的编排复杂度是实打实的成本。根据我的经验下面这些情况请继续用单 Agent任务能在五轮对话内结束输出一次性定型比如写一篇文章、解释一段代码、翻译一份文档任务只涉及单文件或单领域不需要跨模块交接任务失败成本很低大不了重跑一遍。判断标准可以再简化一点如果这个任务你一句话就能说清楚期望产出就用单 Agent如果一句话说不清楚需要拆成“先做什么、再做什么、谁来验收”那就值得上多 Agent。2. 多 Agent 的四种编排模式以及 WorkBuddy 里 Agent 到底是个什么2.1 四种编排模式的适用场景对比真正开始设计多 Agent 系统时先别急着堆角色先选编排模式。我常用的是四种串联流水线、扇出聚合、监督委托、辩论协作。串联流水线是最直观的Agent A 的输出作为 Agent B 的输入B 的输出再给 C像工厂流水线。它适合阶段边界清晰、每个阶段有明确交付物的任务比如“需求分析 → 方案设计 → 编码 → 测试”。扇出聚合适合一类任务拆成多个独立子任务并行做一个调度 Agent 先把任务切成几块派给多个执行 Agent 同时干最后汇聚到聚合 Agent 手里合并。比如写一份技术调研报告让几个 Agent 分别查不同方向的资料再合并成文。监督委托模拟的是“主管 员工”结构主管 Agent 拆任务、派活、检查结果不满意就打回重做。最适合需要反复多轮打磨的任务比如写商业计划书、做产品方案。辩论协作是让多个 Agent 扮演不同立场对同一个问题给出观点最后有一个裁决者拍板。适用范围比较窄适合决策类场景比如技术选型、定价策略。四种模式并不是互斥的实际项目经常是嵌套的。比如外层用监督委托里层的执行阶段用扇出聚合。WorkBuddy 工作台的好处是这些结构都能通过节点连线搭出来模式切换的成本就是拖动节点的成本。2.2 在 WorkBuddy 里分清 Agent、Tool、Skill否则后面一定会乱多 Agent 设计早期最容易犯的一个错误是分不清 Agent、Tool、Skill 三者的边界结果要么把每个 Tool 都包成一个 Agent要么把整个流程塞进一个 Skill最后编排成了一团乱麻。我的理解是Agent 是拥有目标、记忆和决策能力的执行单元它会自己判断该调用哪些工具、按什么顺序执行、遇到意外怎么处理Tool 是最小的原子操作比如读文件、执行命令、调用外部 API本身没有决策能力Skill 则是把若干 Tool 和一个标准流程封装成可复用的“技能包”相当于给 Agent 预装了一套作业手册。举例来说“调用翻译 API 翻译一段文字”是一个 Tool“把文档翻译成中文保留格式专业术语参考项目术语表”是一个 Skill“负责把用户反馈翻译成结构化工单并分类”才是一个 Agent。很多人在 WorkBuddy 里把“翻译”直接做成了一个 Agent这是不合适的。Agent 越多通信成本越高一个只管翻译的“Agent”其实只需要是一个 Skill挂在某个更大的 Agent 身上就够了。我的经验法则是如果一个单元的输入输出非常固定、几乎没有决策空间那它就是 Tool 或 Skill不是 Agent只有当你希望它在面对不同输入时采取不同策略、甚至主动发现问题时才配当 Agent。3. 在 WorkBuddy 里跑通一个三 Agent 工作流从角色定义到连线发布3.1 先给角色画边界每个 Agent 的“不做清单”比“要做清单”更重要搭建第一步不是写 System Prompt是画角色边界。我见过很多人把每个 Agent 的 Prompt 写得很长又是“你是专家”又是“你要负责”结果角色之间职责重叠两个 Agent 反复牵扯同一个问题流水线在中间环节来回震荡。我习惯先给每个 Agent 列两张清单一张“要做”一张“不做”。“不做清单”尤其重要。比如需求解析 Agent它的“不做清单”包括不要编写业务代码、不要检查代码实现细节、不要自行决定技术方案。“不做清单”能阻止 Agent 越权而越权正是多 Agent 系统里最常见的故障源。角色边界确定后再给每个 Agent 规定输出协议也就是它交接到下一个节点时的交付物格式。这一步决定了流水线能不能真正转起来。3.2 角色定义与输出协议配置示例下面是一个三 Agent 流水线的角色配置示例结构和字段名以你当前版本的 WorkBuddy 界面为准但设计思路是通用的。{ agents: [ { id: requirement-parser, name: 需求解析 Agent, goal: 把用户原始描述改写成可执行的结构化任务卡, do: [提炼目标, 拆分验收标准, 识别约束条件], do_not: [编写代码, 指定技术栈, 修改需求范围], output_protocol: { format: json, schema: { task_id: string, requirements: [string], acceptance_criteria: [string], constraints: [string], priority: string } } }, { id: executor, name: 执行 Agent, goal: 基于任务卡完成实际交付, do: [按任务卡执行, 调用已挂载的 Skill, 记录变更日志], do_not: [修改需求描述, 跳过验收标准], input_protocol: { source: requirement-parser, required_fields: [task_id, requirements, acceptance_criteria] }, output_protocol: { format: json, schema: { task_id: string, deliverable: string, change_log: [string], status: string } } }, { id: reviewer, name: 质检 Agent, goal: 对照任务卡验收执行结果, do: [逐条核对验收标准, 给出修改建议], do_not: [再次修改交付物, 引入新需求], output_protocol: { format: json, schema: { task_id: string, passed: boolean, issues: [ { severity: high|medium|low, description: string, suggestion: string } ] } } } ], connections: [ { from: requirement-parser, to: executor, via: output_protocol }, { from: executor, to: reviewer, via: output_protocol } ] }看到这里你可能会问这个 JSON 是在哪里写的实际上你完全可以在 WorkBuddy 工作台的可视化界面里逐个添加 Agent然后在每个 Agent 的配置页里填“要做 / 不做 / 输出格式”。我之所以用 JSON 展示是为了强调一个习惯先把协议写出来再去界面里点。协议先行的好处是你能在动手配置之前就发现角色边界是否清晰、交接字段是否齐全。如果两个 Agent 之间没有可交接的结构化字段那它们在实际上根本无法可靠协作。3.3 连线、汇聚与人工闸门角色和协议都定义好了接下来是在工作台里连线。WorkBuddy 里的连线思路和数据处理平台类似每个 Agent 是一个节点节点之间有边边的含义是“上一个节点的结构化输出作为下一个节点的输入”。实际操作中我建议在两条线上额外加东西。一是汇聚节点当多个 Agent 并行产出、需要合并时汇聚节点的作用是“等待全部到达然后按规则合并”。默认并行行为容易出问题比如某个分支执行失败汇聚节点等不到结果整个流程挂起所以这里要配置超时和分支失败策略。二是人工审批闸门在关键节点——比如执行 Agent 交付到质检 Agent 之前、质检通过之后——插入一个人工确认步骤。这个闸门看起来拖慢流程但实际能减少下游连锁返工。特别是交付给客户、发布到生产环境的节点人工闸门一定要有。连线完成后先不要上真实需求用一个玩具用例跑通全链路观察中间节点的输出是否符合协议。我第一次搭流水线时就是跳过了这个验证步骤直接上真实任务结果第三个节点因为前一个节点输出的字段名不一致直接报错。4. Agent 之间的通信、上下文隔离与记忆同步最容易翻车的三个地方4.1 翻车点一把 Agent 的完整输出直接丢给下一个 Agent这大概是多 Agent 新手最容易踩的坑。直觉上“传递完整的中间产物”似乎是最稳妥的毕竟信息多一点总比少一点好。但在多 Agent 系统里信息越多噪音越大下一个 Agent 越容易抓不住重点。正确的做法是只传递协议约定好的结构化字段。我在 3.2 里给每个 Agent 定义了输出协议就是这个用途。比如需求解析 Agent 可能会在分析过程中产生一大堆备注和草稿但传给执行 Agent 的只有 requirements、acceptance_criteria、constraints 这些核心字段。执行 Agent 不需要知道需求解析 Agent 是怎么推导出这些结论的它只需要按结论干活。这也是我强调“不要让 Agent 之间自由对话”的原因。Agent 之间自然语言互聊看起来智能实际上会引入大量无法预测的噪音。把通信限制为“结构化的 JSON 交付物”等于给每个 Agent 加了明确的工作交接单整个链条的可控性会显著提升。4.2 翻车点二所有 Agent 共享同一个完整上下文第二个翻车点是图省事给所有 Agent 挂在同一个上下文或同一个工作区里让每个 Agent 都“看到所有内容”。这种做法造成的后果是上下文互相串味执行 Agent 会发现上下文中同时存在多个需求版本质检 Agent 会被大量与验收无关的信息干扰判断。我建议按角色做上下文隔离。具体在 WorkBuddy 里的做法是每个 Agent 只挂载它职责范围内需要的知识库、项目和 Skill。比如需求解析 Agent 只挂需求相关的文档执行 Agent 挂代码库和技术文档质检 Agent 挂验收标准和检查清单。隔离之后各个 Agent 的决策质量会明显提升因为它们被迫聚焦不会被无关信息带偏。这里有个常见误解上下文隔离不等于工作区隔离。你可以让多个 Agent 在同一个物理项目下工作但对每个 Agent 设置不同的“视野范围”。就像同一个公司里产品经理和开发工程师使用同一套代码仓库但产品经理不需要被代码变更日志淹没问题开发工程师不需要被一堆用户访谈录音干扰是什么角色就看什么数据。4.3 翻车点三记忆不同步以及换账号后怎么找回“原来账号的记忆”记忆问题是多 Agent 进阶路上的硬骨头。我把它拆成两个实际场景。第一个场景同一个工作流里Agent A 在步骤一中获知了某个业务背景步骤四中 Agent B 又需要这个背景。如果 B 的上下文里没有这个信息它就只能猜测猜错的概率很高。解决方式有两个一是把背景信息显式写进交接协议让 A 在交付物里带上摘要而不是让 B 去“翻历史”二是把业务背景放进共享知识库或项目文档让所有 Agent 都能按需读取。显式传递比隐式共享更可靠但信息量不大时共享知识库更省事具体场景需要自己权衡。第二个场景是很多人在社区问的问题换账号后原来账号的记忆怎么带过去我特意踩过这个坑。WorkBuddy 的记忆通常和账号绑在一起换账号以后工作流定义、Skill、项目知识库不会自动同步。解决路径是在新账号里重建工作流之前先把原账号里的角色 Prompt、Skill 文档、任务卡模板、知识库文件导出保存为本地 Markdown 或 JSON 文件再导入到新账号对应位置。这套流程相当于给账号做“知识搬家”比试图去翻缓存目录找回记忆要可靠得多。直接去改缓存目录是个高危操作缓存目录主要放的是临时文件和模型缓存根本不适合当作记忆持久化介质很可能你把目录改乱了旧记忆没找回来新工作流反而起不来。5. 实战复盘一条需求从进来到上线四 Agent 流水线怎么扛住5.1 四个角色与任务卡协议理论说再多不如看一次完整实战。我选了一个典型的轻量级任务作为示例给一个在线学习小程序增加“番茄钟”功能包含开始/暂停/重置、按学习科目统计时长、以及一页统计报表。我设计了四个 Agent需求解析 Agent把一句话变成结构化任务卡、方案设计 Agent基于任务卡产出技术方案和接口协议、编码 Agent按方案写代码、质检 Agent对照验收标准测试并给出报告。这四个角色分别工作彼此之间通过任务卡和方案文档交接。任务卡协议是整条流水线的锚点。需求解析 Agent 输出如下字段{ task_id: TK-2025-001, requirements: [ 支持开始/暂停/重置计时, 按科目记录学习时长, 统计报表按日/周聚合 ], acceptance_criteria: [ 开始计时后界面倒计时正常推进, 暂停后再次开始累计时长不丢失, 报表可按科目和日期维度筛选, 数据在页面刷新后仍保留 ], constraints: [ 使用现有前端组件库, 后端仅提供数据接口不迁移现有数据库 ], priority: P1 }方案设计 Agent 拿到这份任务卡后输出技术方案、页面结构、API 定义再传给编码 Agent。编码 Agent 只认方案文档不直接看原始需求这样原始需求里“想做个番茄钟”这种模糊表述就不会在编码阶段产生歧义。5.2 中途加需求如何让流水线不散架这次实战里我故意加了一个中途变更刚跑完方案设计阶段产品突然说“能不能顺便加一个白噪音功能”。这种情况在真实项目里太常见了也正是多 Agent 流水线最容易翻车的地方。如果让编码 Agent 顺手把白噪音也做了它就会同时携带“番茄钟”和“白噪音”两个需求在上下文里旧方案文档和新需求产生冲突节奏就会被带乱。我的处理方式是把变更也当作一次正式需求变更流程让需求解析 Agent 重新输出一份更新后的任务卡再让方案设计 Agent 评估影响更新技术方案之后重新向下游传递。注意这里的关键不是“效率”——直接让编码 Agent 加功能当然是更快的路径但会为后续验收埋雷。流水线存在的意义就是强制每个角色只接收协议规定的输入所有变更必须从源头重新走一遍。表面多花了一点时间但避免了“编码 Agent 干了产品经理的活质检 Agent 却不知道需求变了”这种混乱。5.3 质检 Agent 卡死与“假验收”的处理实战中我最常遇到的异常是质检 Agent 卡死它一直返回“未通过”但返回的 issues 里写的全是“整体不够完善”“感觉缺少一些细节”这种无法落地的评价。这叫“假验收”——不是真的发现了 bug而是它根本不知道用什么标准来验收。解决办法是给质检 Agent 换上强制模板不允许输出模糊结论每个 issue 必须包含严重级别、可复现步骤或证据、具体修改建议。如果 Task 的验收标准有五条它必须逐条明确标注通过/不通过并附含理由。模板一带上质检 Agent 的质量马上上来了因为它无法再逃避到模糊语言里。另一个要提前防范的问题是质检 Agent 的“返工循环”质检不通过执行 Agent 改一次再测还是不过又回去改如此循环几次业务流程就卡死了。我给流水线设置了一个最大返工次数比如 3 次。超过 3 次仍未通过工作流自动转人工由人来判断是需求描述不清、执行能力不足还是验收标准本身有问题。这个兜底机制救过我很多次否则流水线会陷入无意义的死循环。6. 稳定性三板斧并发限流、缓存目录、AI 味检测6.1 并发限流与重试策略多 Agent 跑起来之后最先遇到的问题往往不是模型能力而是外部依赖的稳定性。多个 Agent 同时执行立刻会出现三类情况并发调用量激增触发 API 限流、单次执行超时导致流程卡住、某个下游服务临时不可用导致连锁失败。建议在 WorkBuddy 工作流的入口处加一个并发队列把同时执行的 Agent 数控制在一个合理的上限以内。比如我的经验是对模型 API 的单工作流并发数不要超过 8 个除非你已经确认有更高的配额。给外部 HTTP 调用设置超时时间默认 30 秒超过就按失败处理不要无限等待。重试策略要避开一个坑不要所有失败都无条件重试。网络抖动这类瞬时错误可以立即重试模型返回格式错误重试一两次也可能恢复正常但如果是下游业务接口报“参数校验失败”重试一百次也没用应该把错误抛回上层转人工或终止流程。我常用的是指数退避重试第一次 2 秒、第二次 4 秒、第三次 8 秒最多三次。再多说明不是瞬时问题了。6.2 给 WorkBuddy 换一个干净的缓存目录跑多 Agent 流水线之后中间产物、日志、模型缓存占磁盘非常快。默认缓存目录往往在系统盘跑上几周就会看到磁盘空间告警。想改缓存目录的路径不需要动工作流配置在 WorkBuddy 的设置或启动环境变量里找到缓存路径相关配置把它指向一个空间大的数据盘然后重启 WorkBuddy确认日志和临时文件开始写入新目录即可。这里有一条经验改完缓存目录后一定要重新确认旧目录的内容可以清理。很多中间产物是一次性的留着只会占空间。我会定期把新的缓存目录下超过 7 天的临时文件自动清理掉。注意只清理临时产物不要动项目文件和知识库目录生产环境里一个“顺手清理”就可以把所有的工作流定义清光。6.3 用“人味规则”和人工闸门兜底多 Agent 产出的内容质量上去了但会留下明显的“AI 味”措辞工整得过了头、每段结构完全对称、形容词密度偏高、缺少具体的个人经验。这个现象在文章写作、客户沟通、方案文档场景里特别致命因为客户一眼就能看出来这是模型生成的。我的办法是在质检 Agent 的验收清单里加入“人味规则”。比如不允许出现排比式的开头至少包含一个具体的、带数字或日期的案例不能用“总之”“综上所述”这类空泛总结每个结论都要有证据支撑。这些规则听起来很虚但写进模板之后Agent 的输出气质会明显变化因为它默认执行者也会按这些规则生成内容。人味规则只是兜底的一部分我更建议在面向外部用户的关键节点保留人工审批闸门。多 Agent 流水线适合处理 80% 的常规交付但剩下的 20% 关键时刻人工确认是必要的。自动化和质量之间从来不是非此即彼你可以在“质检通过”和“最终交付”之间加一个轻量的人工确认步骤让一个人在界面上点一下通过。这个动作成本很低却能把系统的容错率提高一大截。用多 Agent 做了半年多实际项目后我最深的一点体会是多 Agent 的价值从来不是“多个模型一起思考会很聪明”而是通过职责切分把模糊的大问题变成明确的小问题再用协议把它们粘合成一条可信的流水线。真正让系统稳定的不是哪一个 Agent 的表现而是角色边界、交接协议和兜底机制这些“组织制度”。最后分享一个我在每次配置新工作流时都会用的小技巧给每个 Agent 写“不做清单”时至少写满五条比如“不要修改需求描述”“不要自行改变输出格式”“不要猜测未提供的信息”。多 Agent 系统里约束带来的秩序感永远比自由发挥带来的惊喜更值钱。