写多 Agent 这篇之前我已经在《WorkBuddy 实战蓝皮书》前面几篇里把工作台搭建、Skill 配置、记忆管理和提示词调教都过了一遍。如果你一路跟着做下来应该已经能用 WorkBuddy 单个 Agent 跑通不少自动化任务了。但单 Agent 的瓶颈很明显任务一复杂上下文一长它要么开始丢细节要么整个流程卡在某个环节里出不来。这篇我们来聊 WorkBuddy 最值钱的部分——多 Agent 协作怎么把几个各司其职的 Agent 编排成一条能稳定工作的流水线。先给没看过前几篇的朋友交个底WorkBuddy 本质上是一个 AI Agent 工作台你可以把它理解成给大模型装了一整套“工具流程记忆”的底座。单个 Agent 就是一名员工而多 Agent 模式就是让一群员工在同一个项目里分工协作有人拆任务有人干活有人检查结果互相之间通过结构化的消息传递信息。这篇我会带你从零搭一个多 Agent 工作台把角色怎么定、任务怎么拆、上下文怎么传、故障怎么排查这些真问题一个一个解开。1. 先搞清楚为什么单独一个 Agent 搞不定复杂任务1.1 单 Agent 的死穴上下文污染和流程失控我自己在 WorkBuddy 里跑过不少单 Agent 任务最典型的一个翻车现场是“让它帮我完成一份市场调研报告”。我一开始想得很简单把所有要求一次性丢给一个 Agent让它自己查资料、自己分析、自己写报告。结果呢它把调研目标、数据来源、竞品分析、报告结论全部塞进同一个上下文窗口里写到后面它已经开始自相矛盾——前面说市场规模 50 亿后面引用的时候又变成 500 亿最离谱的是它把调研对象从“我们自己的产品”偷偷换成了“竞品的产品”。这其实是单 Agent 模式的结构性缺陷不是 WorkBuddy 的问题换哪个平台都一样。大模型的上下文窗口是有限的任务链条越长早期信息被“稀释”和“遗忘”的概率就越高。而且单 Agent 同时要承担“规划-执行-检查”三个角色等于一个人既当项目经理又当程序员又当测试它根本没有余力在每一步都做质量把关。1.2 多 Agent 的本质把“一个人干所有事”变成“一个团队干一件事”多 Agent 的思路特别朴素既然一个 Agent 干不了那就拆成几个每个只干一部分。关键是拆完之后怎么让这几个 Agent 像一支真正的团队一样配合。WorkBuddy 在这方面做得很实在——它不搞那种“几个 Agent 互相聊天直到完成任务”的花架子而是提供了一套清晰的角色体系和任务流转机制。我常用的一个类比是开餐厅。你不可能让一个厨师同时去采购、切菜、炒菜、端盘子、收银哪怕他再厉害也会手忙脚乱。正常的做法是每个岗位安排专人后厨做完一道菜放到出餐口服务员再端给顾客。多 Agent 工作流也是同样的逻辑一个 Agent 负责拆解任务一个 Agent 负责执行某个子任务做完以后把结果放到一个定义好的“交接区”下一个 Agent 从交接区取结果接着干。这种结构天然抗干扰因为每个 Agent 只需要关心自己那一段上下文不需要背完整条流水线的信息。1.3 什么时候才需要上多 Agent不是所有任务都值得上多 Agent这一点我得说在前面。WorkBuddy 里单 Agent 能跑完的任务非要拆成多 Agent反而会引入额外的通信开销和配置复杂度。我自己判断的标准有三个任务链条太长明显超出单个上下文窗口能承载的信息量任务包含多个阶段每个阶段需要不同的能力或知识结构任务结果需要二次校验光靠一个 Agent 自己检查自己不可靠满足其中两条我才建议拆成多 Agent。比如“收集 20 个网页的数据并生成结构化报告”这种任务单 Agent 其实能跑但质量很难保证但如果把这个任务拆成“网页数据采集 Agent”“数据清洗 Agent”“报告生成 Agent”每一段都很清晰出了问题也容易定位到底是哪个 Agent 的锅。下一篇我会讲任务路由原理正好是这篇的延伸。2. WorkBuddy 多 Agent 的架构设计角色、通信与协作模式2.1 三个核心角色规划者、执行者、审查者WorkBuddy 的多 Agent 体系里最常见的三种角色定位分别是规划者Planner、执行者Executor和审查者Reviewer。规划者负责把一个大目标拆成可执行的子任务然后按依赖关系排好顺序执行者只专注完成分配给自己的那一个子任务审查者负责检查执行结果是否满足要求不满足就退回重做。这三个角色不是死的。你完全可以只配置“规划者两个执行者”也可以配置“规划者执行者审查者执行者”这种更细的链路。WorkBuddy 允许你在同一个工作台里创建多个 Agent每个 Agent 定义清楚它的系统提示词、擅长技能、可使用工具和输出格式然后把这些 Agent 组装成一个有向的工作流。我个人的偏好是第一版先按“规划-执行-审查”三件套来跑通了再往里面加执行者因为审查者这个角色在初期最容易帮你发现流程设计的漏洞。2.2 通信机制结构化消息比自然语言聊天更可靠多 Agent 之间怎么通信是 WorkBuddy 这类平台最核心的设计决策。我没少见到那种“让两个 Agent 在一个群聊里自由对话”的设计表面上很热闹实际跑起来经常是灾难——两个模型说着说着就开始互相客套或者陷入循环“你说得对我再补充一点”“好的你说得对我补充一点”。这种模式本质上就是把模型的弱点放大了而不是在解决问题。WorkBuddy 的做法更接近真实工程Agent 之间通过定义好的结构化消息传递数据。比如规划者输出一个任务列表每个任务带_id、_描述、_依赖关系、_验收标准这些字段执行者接收一个任务对象完成任务后往字段里填入_result审查者读到的是一份完整的任务执行记录。整个过程像极了不同的服务之间通过 API 传 JSON而不是让两个程序互相发邮件聊天。用结构化消息还有个额外好处你可以在关键节点停下来查看数据。某个 Agent 跑出来的结果不对你把它的输入和输出拉出来对比一下马上就能看出来是上游数据传错了还是这个 Agent 的理解有问题。这在排障的时候帮了我大忙。2.3 协作模式的取舍串行、并行还是混合多 Agent 的协作模式可以从另一个维度分类串行、并行和混合。串行模式最简单一个 Agent 干完下一个接着干适合有明确先后依赖关系的任务比如“先调研后写作”。并行模式适合那些互不依赖的子任务比如调研阶段同时让三个 Agent 分别去查市场数据、竞品信息和用户评论最后再汇总。混合模式最复杂但也是真实项目里最常用的——先并行跑一批独立子任务到某个节点需要统一汇总汇总之后再并行分发下一批。WorkBuddy 里实现并行有一个小技巧同一个工作流里如果多个执行者 Agent 之间没有依赖关系调度器会自动尝试并行执行。但要注意并行不是免费的多个 Agent 同时跑意味着占用的算力资源成倍增加而且它们的输出都依赖同一个上游结果如果上游输出质量不稳定下游被带偏的概率也成倍增加。我建议新手先串行跑顺了再调并行。3. 动手搭一个多 Agent 工作台从创建 Agent 到跑通全流程3.1 第一步想清楚你要拆几个 Agent动手配置之前先花十分钟把任务拆解图画出来。我这里用一个我反复用过的例子生成一份“行业竞品分析简报”。单 Agent 干这个任务容易偷工减料我把它拆成了三个 Agent规划 Agent负责理解任务目标拆出分析框架定义每个子任务的验收标准调研 Agent负责根据规划 Agent 给的主题清单逐个收集信息输出带来源的结构化笔记写作 Agent负责把调研笔记整理成连贯的分析简报并标注数据来源你看这个拆法没有走极端——我没有拆出什么“语法检查 Agent”“格式美化 Agent”。拆得太碎反而会让通信成本超过执行收益。WorkBuddy 里新建 Agent 的入口在侧边栏的 Agent 管理页点“新建 Agent”之后需要填的字段包括 Agent 名称、角色描述、系统提示词、关联的技能列表和允许调用的工具列表。3.2 第二步配置每个 Agent 的系统提示词与技能配置系统提示词是这一步的重头戏也是决定多 Agent 效果好坏的最大变量。我踩过的最大的坑是给每个 Agent 的系统提示词写得太泛。举个例子我第一版给调研 Agent 写的提示词是“你是一名专业的行业调研员”结果它跑出来的笔记经常是车轱辘话没有任何结构化信息。后来我把提示词改成了下面这种写法你是一名行业调研员专注于【新能源电池】领域的信息收集。你的任务只有一个在收到任务列表后逐条对每个调研主题输出结构化笔记。每条笔记必须包含主题、5 条以内关键信息、每条信息的数据来源 URL、信息来源的可信度等级高/中/低、以及该信息与任务问题的关联性说明。如果某项主题在你的能力范围内找不到足够信息必须明确标注“未找到足够资料”严禁编造。这种写法的好处是给了 Agent 一个明确的“输出契约”它知道自己要产出什么格式、什么颗粒度、什么边界。同时我把 WorkBuddy 里能用的工具尽量绑定到对应的 Agent 上——调研 Agent 挂上网页检索工具和 PDF 解析工具写作 Agent 挂上文档生成工具和排版工具。这里有个工作台绑定的细节工具绑定之后Agent 的请求会带上工具列表模型可以在响应中调用它们而 WorkBuddy 负责真实执行工具并回填结果。3.3 第三步定义任务流转与交接格式Agent 创建好以后最关键的是在 WorkBuddy 的编排面板里把这些 Agent 串起来。我习惯用画布形式的编排界面拖一个规划 Agent 节点放在最左边拖一个调研 Agent 节点放在中间拖一个写作 Agent 节点放在最右边然后用连线把上下游关系连出来。连线的时候WorkBuddy 会要求你定义上游输出的哪些字段传给下游。这一步千万别图省事直接“全量传递”。比如规划 Agent 输出的字段里有“任务列表”“分析框架”“风险提示”调研 Agent 其实只需要“任务列表”你给多了反而会让它的上下文被无用信息占满。我通常会在传递配置里写清楚映射关系比如 task_list - research_agent.input_tasks这是用一个很常见的字段映射来保证链路清爽的。真实跑过几次之后我把这次编排的经验总结成了三条配置心得这也是我写进公开版本里的方便读者抄作业。第一条所有 Agent 的输入输出尽量只传结构化数据不要传自然语言段落第二条任务描述里必须带验收标准否则下游无法判断结果是否合格第三条关键节点要开持久化日志WorkBuddy 可以记录 Agent 之间的消息内容后面排查问题时这些日志是救命稻草。3.4 第四步跑一次完整流程并检查输出配置完成后我在 WorkBuddy 的“运行”面板里启动了这个工作流。跑了一批真实的调研数据选了 5 个行业的竞品数据之后我把三个 Agent 的输出逐条检查了一遍规划 Agent 输出的任务列表质量很高拆出了 6 个子任务每个都带着明确的验收标准连依赖关系都画对了调研 Agent 给 6 个子任务里的 5 个输出了结构化笔记第 6 个主题因为资料太少老老实实标注了“未找到足够资料”写作 Agent 结合调研笔记生成的简报结构清晰但把两条调研笔记里的“高可信度”数据写错了原始来源还是我人工核对时发现的这个结果说明多 Agent 流程确实降低了“上下文漂移”的概率但完全没有错误也不可能。下游 Agent 的幻觉问题依然存在需要审查者来兜底。所以我在第四步结束后临时又给这个工作流加了一个审查 Agent专门做数据来源校验。多 Agent 的持续调优就是这么迭代出来的不可能一步到位。4. 关键参数与调优模型、上下文、记忆与并发的平衡4.1 每个 Agent 该用多大的模型WorkBuddy 把模型选择做得比较灵活你可以在同一个工作流里给不同 Agent 指定不同的模型。这个能力上了多 Agent 之后太重要了。规划 Agent 是拆解任务的角色它在推测时需要考虑全局约束简单总结一下它的工作把模糊指令变成清醒任务。但如果规划任务本身不够难、外部输入是清晰的 太强的模型就有点过度配置生成速度也拖慢全流程——实际过程中这个差异我是有对比过的。我自己用下来的推荐组合规划 Agent 用中等偏强的模型比如支持较大上下文窗口的那一档执行 Agent 用速度和性价比优先的档位因为它要跑很多轮审查 Agent 反而是唯一一个值得用最强模型的角色因为它需要发现其他 Agent 的错误。你可能会觉得奇怪为什么最重头的执行任务不用最强模型我的经验是执行 Agent 的大量失败其实不是“理解不了”而是“没有足够的提示和上下文约束”这些用流程设计就能解决没必要烧算力。4.2 上下文窗口怎么分配宁可小不可乱多 Agent 场景下最隐蔽的性能杀手就是每个 Agent 的上下文窗口都塞得满满的。WorkBuddy 允许你给每个 Agent 设置上下文保留策略包括保留最近的多少轮消息、是否截断过长的工具返回结果、以及从记忆里带回多少历史摘要。我的建议是给执行 Agent 设一个比较小的上下文上限比如只保留当前任务相关的消息。执行 Agent 不需要记住这个项目从第一天起的所有细节它只需要眼前这个任务。规划 Agent 的上下文可以放宽一点因为它要综合全局信息。但不管哪个角色我都强烈建议开启 WorkBuddy 的自动摘要功能——当上下文接近上限时系统会把旧消息压缩成摘要再继续跑而不是硬着头皮把全部原文塞进去。这个功能一开始容易被忽略我是在跑了几个超长工作流之后才在设置里发现的一开就再也回不去了。4.3 记忆配置多 Agent 之间的共享记忆与独立记忆热词里有“换账号如何获得原来账号的记忆”这在中长篇任务里确实是个高频痛点。WorkBuddy 的底层记忆系统我可以聊两句它能保存工作流级别的共享记忆也可以给每个 Agent 单独配置长期记忆。调优时建议把共享记忆留给那些真正跨阶段的信息比如一个项目的全局目标、关键决定、当前进度至于某个 Agent 在某一步产生的中间过程让它留在自己的独立记忆里就好。我遇到过一个真实案例一个由四个 Agent 组成的法务文档处理工作流每次跑到第三个 Agent 就开始“忘记”前面提取的关键条款。后来我发现根因是第二个 Agent 把关键条款写进了自己的独立记忆没有同步到共享记忆第三个 Agent 根本读不到。解决方法很简单把这些条款的传递方式从“让 Agent 自己决定记什么”改成“在任务流转配置里显式声明为下游输入”问题立刻消失。记住多 Agent 系统的记忆问题7 成靠显式数据流解决3 成才靠模型记忆能力解决。4.4 并行度与资源占用怎么权衡WorkBuddy 的并行度设置默认走的是“自动调度”也就是系统根据各 Agent 的依赖关系决定谁先谁后、哪些能同时跑。如果你开手动模式可以给每个 Agent 设置最大并发数。实际操作里我一般遵循“上游可以多并行下游尽量少并行”的原则调研类、收集类的 Agent 并行度拉满因为它们任务相互独立并行能显著省时间到了写作、审查这类强逻辑阶段我反而会把并发调低一方面避免资源争抢导致响应变慢另一方面逻辑型任务并行跑容易互相干扰输出质量。这里有个容易踩的坑是你把并行度调高了以后单个 Agent 的错误可能会被“放大”。因为多个并行执行的 Agent 都基于同一个上游结果一旦上游结果里有错所有下游会同时错。所以每次改动上游 Agent 的提示词我都建议重新跑一遍完整流程而不是只重跑其中一个环节。5. 故障排查实录自己做多 Agent 时踩过的五类坑5.1 现象一Agent 之间互相“传染”错误格式有段时间我的工作流跑得好好的突然有一天连续几次输出的 JSON 都是坏的不是缺括号就是字段名大小写不一致。我查了半天发现不是某个 Agent 突然变笨了而是上游 Agent 在一次失败重试时把错误格式的样例写进了自己的记忆里导致后面每次输出都跟着学坏。排查方法很简单进 WorkBuddy 的消息日志里看最近几轮的上下文查出是哪一步引入了坏格式。修复动作有两个第一删掉那个 Agent 积累的错误记忆片段第二在系统提示词里加一句“严格按 JSON Schema 输出禁止输出任何非 JSON 内容”。这是我在记录里反复提到的上游数据一旦带病下游全链路带病。切记要在关键节点做数据格式校验不能偷懒。5.2 现象二任务循环Agent 卡在“自我纠正”里出不来多 Agent 场景里最常见的死循环是审查 Agent 觉得执行结果不合格打回去重做执行 Agent 重做完以后审查 Agent 还是觉得不合格哪怕是格式上的微小偏差比如多了个句号、少了个空行。最后这个工作流会一直循环到达到最大重试次数才停下来。这个问题的根源不是我当初以为的“执行 Agent 能力不行”而是我给审查 Agent 写的验收标准太模糊。后来我把审查 Agent 的提示词里改成了“验收标准必须逐条与任务描述中的字段核对除非字段缺失或数据存在事实错误否则应该通过”同时给它定义了明确的验收清单字段完整性、数据来源是否标注、日期格式是否正确。改成清单制之后这个工作流的重试率明显降下来了。如果你也碰到类似情况认真检查审查者的标准别急着换更强的模型。5.3 现象三下游 Agent 的上游数据“对不上号”还有一次我的写作 Agent 输出的报告里引用了调研数据但数据明显是其他行业的完全对不上。我跟进排查后发现问题出在字段映射上我在编排面板里把调研 Agent 输出的“notes”字段默认传递给了写作 Agent但那次调研 Agent 实际返回的字段名改成了“research_notes”因为我在更新提示词时把输出格式改了。传递配置没有同步更新于是写作 Agent 拿到了一个空字段只能开始脑补。这个坑提醒了我改了上游 Agent 的输出格式之后一定记得去检查下游所有节点的字段映射。WorkBuddy 的编排界面里可以看到每个节点的输入字段下拉框但系统不会自动帮你适配新的字段名。我现在的习惯是每次改完 Agent 提示词就在编排面板里把所有连线“从左到右过一遍”确认字段名逐一对应。5.4 现象四记忆干扰老任务的记忆污染新任务多 Agent 跑得多了以后Agent 的长期记忆里会积累大量旧任务的信息。如果你没有给 Agent 建立合理的记忆隔离它很有可能在执行新任务时“灵光乍现”地引用旧数据。有一次我做一个完全不相干的编程任务执行 Agent 居然引用了上一次快消行业调研里的数据虽然它引用得一本正经但实际完全是错误信息。WorkBuddy 的记忆管理页里可以给不同 Agent 配不同的记忆空间也可以给记忆包加标签。我现在严格按“每个工作流使用独立记忆空间”来配置除非是需要跨工作流共享的知识否则不放在共享记忆里。这个问题在单 Agent 场景下就已经存在但在多 Agent 下会被放大因为记忆是分散在每个 Agent 里的一个 Agent 记忆污染影响的是整条链。5.5 现象五长任务跑到最后输出质量明显下降长任务后期质量下降大多数情况下是因为上下文太满导致的。我观察过一次一个调研加写作的工作流跑了将近四十分钟后面写作 Agent 的输出开始变得啰嗦且重复像是“累坏了”的样子。查日志时发现它的上下文保留列表中塞了太多中间过程的工具调用结果而这些结果其实是不会用到的。解决方法是给工具返回结果设置截断或者摘要策略。WorkBuddy 的上下文管理里有一项“工具返回结果保留策略”我把它设成了“只保留工具输出摘要”而不是保留完整原文。这么改完之后同样长的工作流后期输出质量提高了不少。这条经验对任何多 Agent 平台都适用不要把宝贵的上下文花在永远用不上的过程信息上。6. 进阶技巧让多 Agent 协作更顺滑的三个锦囊6.1 锦囊一给每个 Agent 一个“输出契约”我听很多朋友抱怨过多 Agent 跑出来的东西“不能直接用”我自己的经验是问题通常出在输出规范上。与其让每个 Agent 自由发挥不如给它一个强约束的输出模板。比如写作 Agent 的输出模板可以固定为标题、核心论点、支撑论据、数据来源、结论建议五个章节调研 Agent 的模板是每条笔记必须包含原文引用和来源链接。输出契约的好处是下游 Agent 读起来非常轻松因为它不需要再通过理解一段自然语言来“找重点”而是按位置取字段。WorkBuddy 里实现输出契约最简单的方式是在系统提示词尾部粘贴一个 YAML 格式的模板示例再附上一句“只用该格式输出”。这个方法效果立竿见影我强烈建议每个人都试一次。6.2 锦囊二用“人工确认节点”拦下高风险操作多 Agent 全自动执行看起来很美但有些环节不适合全自动。比如给外部系统发消息、创建真实订单、删除数据这类有后果的操作最好在 WorkBuddy 的工作流里插入一个人工确认节点让工作流在这步暂停等待人工点“确认通过”后再往下走。确实全自动跑龙套很爽但出了事故以后你更爽。我的原则是凡是影响外部真实系统的动作一律挂人工确认节点。WorkBuddy 的节点类型里有“人工审查”这个选择配置很简单就是在节点属性里开启“需要人工确认”。加了这一步之后工作流的自动化程度看似降低了但整体的可靠性和安全感是成倍增加的。6.3 锦囊三开历史运行对比每次调优都有参照最后这个锦囊更多是工程习惯问题。WorkBuddy 会保存每次运行的历史记录包括每个节点的输入输出、整个工作流的耗时、以及每个 Agent 的 token 消耗。调优的时候把这些历史记录当 A/B 测试集来用反复对比调整前后的差异。我调优的典型方法是先完整跑一次记录基线然后只改一个变量比如某个 Agent 的模型档位或某个节点的提示词再跑一次对比效果。不要一次同时改三个变量否则出了问题根本分不清是哪次改动导致的。这种克制一点一点的调法最终沉淀下来的配置往往是可持续的。多 Agent 系统的复杂度比单 Agent 高了一个量级没有一套严格的调优流程靠感觉调是很容易滑向失控的。逛到这里你会发现WorkBuddy 里的多 Agent 并不神秘它就是一套机制清晰、需要你精心编排的协作系统。从角色设计、字段映射到上下文分配、记忆隔离每一步都有明确的规则可循。我自己最深的体会是多 Agent 的真正瓶颈从来不是模型能力而是你有没有把任务结构和信息流梳理干净。配置好了一个多 Agent 工作流它不像单 Agent 那样靠“碰运气”出结果而是像一个运转良好的团队稳定、可控、可改进。你要是也搭出了好用的多 Agent 工作流欢迎回来交流你的编排思路。