《WorkBuddy 实战蓝皮书》系列写到第六篇终于轮到多Agent了。前面五篇我一直在聊单Agent怎么调教怎么写Skill、怎么管上下文、怎么选模型温度这些单打独斗的玩法确实能解决不少小问题但只要任务一复杂单Agent的短板就全暴露出来。这篇我把WorkBuddy里多Agent协作的完整玩法拆一遍——从底层概念到一条可复现的“调研-写作-校对”流水线再到我踩过的那些坑基本属于“我熬过夜才拿到的”经验。适合已经入门WorkBuddy、想把活儿做得更稳更快的朋友也适合那些正在犹豫“多Agent到底是不是噱头”的观望者。1. 为什么单Agent撑不住复杂任务先讲我实际遇到的三个问题都是被逼急了才去研究多Agent的。1.1 单Agent绕不开的三道坎第一道坎是上下文冲突。让一个Agent既当调研员又当写作员它就得在同一个上下文里既存资料又组织语言。一开始还好等到资料累积到两三万字最早抓到的关键信息会被慢慢挤出去写出来的东西经常漏事实。更麻烦的是资料自身的风格还会干扰写作风格我拿一堆口语化采访稿喂给Agent它写出来的正式报告里居然混进了“咱就是说”这种调调。第二道坎是角色切换损耗。你可以在系统提示词里写“你现在是资深分析师接下来写报告”模型确实会照做但每次切换角色都要消耗上下文空间去“重新进入状态”。切换的次数一多模型很容易人格分裂——写着写着又跳回调研员口吻还夹带“根据以上搜索结果”这种话。你辛辛苦苦省下的context空间全浪费在这种无效切换上。第三道坎是错误传染。单Agent流程里只要某个环节出一个低级错误比如抓网页时把编码搞乱、引用了过时数据后续所有环节都会基于错误结果继续算。最后整篇文章推倒重来是小事更怕的是错误被模型“自信地”编织成看起来很合理的内容人工审核时反而不容易发现。这三道坎的本质是同一个单Agent违反了单一职责原则。多Agent的核心思路就是把一个大任务拆成多个小任务每个小任务由一个Agent独立承担Agent之间通过明确定义的接口交接互不污染对方的工作现场。1.2 WorkBuddy的多Agent协作范式WorkBuddy的多Agent不是简单地把几个Agent按钮摆在一起它有一套完整的协作范式我拆成四块讲。流程编排。任务从上游Agent流向下游Agent可以串行也可以并行。串行适合有严格先后依赖的流程比如先调研再写作并行适合相互独立的调研方向比如同时查技术文献、竞争产品、用户反馈最后再汇总。消息交接。每个Agent的输出会被固化成“消息包”下游Agent只读取自己需要的部分。这个设计特别重要它相当于给工作流加了一层强类型接口上游产出什么字段下游就消费什么字段。共享记忆区。多个Agent可以往同一个全局变量里写数据。比如调研Agent把资料摘要写入research_notes写作Agent再从中读取。这块后面我会专门讲。Skill挂载体系。每个Agent可以挂载自己的Skill互不影响。同一个项目里调研Agent挂搜索和抓取类Skill校对Agent挂格式校验类Skill不会出现工具权限混乱的问题。这就像一家餐厅后厨。单Agent相当于一个厨师从备菜到摆盘全包菜一多必乱WorkBuddy的多Agent则是切配、炉灶、打荷各司其职菜品在固定窗口交接。厨房里最忌讳一个人同时管三个灶头AI工作台也一样。2. 先把底层概念吃透再动手多Agent排错的时候八成问题都出在概念没理清。这一章我把WorkBuddy里最关键的几个底层机制讲明白。2.1 Agent的真实构成和配置要点WorkBuddy里的Agent本质就是一个具备独立系统提示词、可调用工具、有独立上下文窗口的LLM执行单元。创建Agent时要配齐四样东西名称与职责、基础模型、系统提示词、可用工具集和Skill。名称不是随便起的。我习惯用“动词对象”来命名ResearchAgent、WriterAgent、ReviewerAgent。这样在流程节点里扫一眼就知道这个Agent负责什么不用点进去看详细配置。系统提示词要写清楚三件事你是谁、你负责什么、你的输出格式是什么。这里有个技巧把输出格式直接画成JSON结构写进提示词。比如调研Agent的提示词末尾写{ theme: 任务主题, facts: [事实列表], risk_points: [风险点], sources: [来源链接] }提示词里写明“只输出该JSON结构字段名严格一致”比写十句“请认真调研”都管用。模型对结构化指令的遵从度远高于模糊描述。2.2 消息传递与上下文隔离机制多Agent最容易踩的坑是上下文串了。WorkBuddy默认每个Agent之间上下文隔离A的对话历史不会自动出现在B里只有A主动输出的消息包能被B接到。这个机制带来一个设计原则上游Agent的输出格式就是下游Agent的输入契约。所以我设计多Agent时第一件事不是选模型而是先设计消息包的JSON Schema。接口定稳了后面换模型、加节点都不伤筋动骨。举个例子调研Agent输出{ theme: 多Agent任务拆解, facts: [消息包隔离机制, 共享记忆区设计, 输出Schema先行], risk_points: [上下文溢出, 循环死锁, 上游JSON被Markdown包裹], sources: [workbuddy官方文档, 实战蓝皮书系列] }写作Agent拿到这个JSON按facts组织文章结构按risk_points写避坑提醒。接口稳定流程就稳定。2.3 模型选型与分组策略不要所有Agent都绑同一个模型这是我优化成本后最强烈的建议。三个角色用三种模型调研Agent用长上下文模型因为它要吞下大量网页和文档写作Agent用生成质量高的模型这个钱不能省校对Agent用指令遵从好的小模型就够输入输出都是几千字小参数模型速度快、成本低。我算过一笔账。假设一个调研任务要读三万字资料如果写作Agent也绑长上下文模型它的上下文会被上游传过来的三万字占满根本没空间去组织语言。正确的做法是让调研Agent把三万字压缩成三千字的JSON写作Agent只读这三千字成本直接降一个量级。注意WorkBuddy中不同Agent绑定模型是在项目设置里完成的。我遇到很多人全局只配了一个模型导致多Agent优势完全发挥不出来。先把每个Agent的模型分开这是多Agent优化的第一件事。3. 实操搭一条“调研-写作-校对”流水线理论讲完进入动手环节。我选一个最常见的任务场景输出一篇行业观察文章。整个过程大约二十分钟跟着做就能跑通。3.1 先画工作流再动手别急着拖节点我在WorkBuddy里搭多Agent前一定先在纸上把流程画出来。别觉得这一步多余我见过太多人上来就拖节点结果节点连线乱成一团跑起来才发现少了一个清洗步骤。这次任务的工作流分四步调研Agent接收任务主题调用搜索Skill抓取资料输出结构化JSON清洗节点把JSON里的资料整理成大纲去掉重复信息写作Agent依据大纲生成初稿校对Agent检查事实错误和格式问题输出最终Markdown。每一条连线都要能说清楚“上游给下游传了什么”。如果说不清楚说明任务还没拆透。这个强制自问的动作能帮你避免大部分返工。3.2 逐个创建Agent并挂载Skill在项目工作台新建Agent先建调研Agent。名称填ResearchAgent模型选择长上下文模型系统提示词写“你负责调研与资料整理只做信息搜集不写结论。输出JSON字段为theme、facts、risk_points、sources。禁止输出JSON以外的内容不要用Markdown代码块包裹JSON。”然后给它挂载两个SkillWebSearchSkill搜索、WebFetchSkill读取网页正文。挂载后一定要先手动测试一下。我遇到过Skill名称对不上导致调用直接失败的情况在Skill管理页单独测了五次才发现是权限配置问题。接着建写作Agent。名称填WriterAgent模型选生成质量高的模型系统提示词写“你基于ResearchAgent提供的JSON资料撰写行业观察文章。输出Markdown。开篇直接切入主题不写客套话。全文结构依据facts字段组织每个fact都要在文中体现。”最后建校对Agent。名称填ReviewerAgent模型用小参数模型系统提示词写“你负责校对。检查事实一致性、逻辑断裂、错别字、格式问题。输出修改后的完整Markdown并附加一个issues列表逐条说明修改原因。”写提示词时记住一句话不要写“你是一个优秀的撰稿人”这种空话浪费token。直接写职责和约束模型能理解的比你想的多。提示系统提示词最末尾可以加一句“如果输入信息不足以支撑判断请明确说信息不足不要编造”。这个兜底条款能让校对Agent更老实。3.3 配置流程节点与消息交接在WorkBuddy的Workflow编辑器里拖出三个节点按顺序连接。连接线就是交接通道关键配置在下面这几项。节点输入。调研Agent的输入来自“任务主题”变量这里直接绑定项目输入参数。交接方式。写作Agent的输入选择“上游节点输出字段facts”而不是“全部输出”。这一步非常关键。输出约定。校对Agent的输出路径设为final_report.md运行结束后会自动写入项目文件。失败重试。每个节点设置最大重试2次重试间隔5秒。多Agent流程里偶尔一次服务超时是正常的自动重试能避免整个流程瞬间失败。超时上限。调研Agent设为180秒写作Agent设为300秒校对Agent设为120秒。这个参数根据任务体量来定我给的是一般文章任务的经验值。最容易出错的就是交接时选了“全部输出”。上游把JSON所有字段一股脑传给下游不仅让下游上下文瞬间膨胀还会干扰它对重点字段的注意力。我强烈建议只在输入配置里勾选下游真正需要的字段这个习惯能省掉大量上下文超限的报错。3.4 运行流程与手工校验配置好后点运行输入主题“多Agent编排出行业观察”。运行过程中我会盯几个关键位置调研Agent的日志里是否出现搜索命中记录。如果一次搜索都没有Skill八成没生效清洗环节产出的facts数量。数量太少说明调研覆盖面不够后面文章会很单薄写作Agent接到的JSON是否完整。字段缺失会导致文章结构缺块比如sources没传过来文章参考文献就写不了校对Agent是否真的修改了内容。有些小模型会“假装校对”原样返回输入注意看日志里的diff记录。拿到底稿后我会手动抽三个facts去对应来源核对。这一步不能省再好的编排也不过是让模型犯错率降低不是归零。3.5 参数细节补充温度与输出长度顺便把两个常用参数说一下。调研Agent的温度建议调到0.2让它稳定摘录事实写作Agent的温度可以给到0.7留一点表达上的随机性校对Agent温度降到0.1只求准确。输出长度方面如果跑的是长文任务记得在Agent配置里把max_tokens写足。我见过有人调研Agent输出被默认上限截断JSON解析到一半失败整个流程白跑。这个错很蠢但发生率超高。4. 常见问题与排查技巧实录多Agent跑多了什么奇奇怪怪的故障都能遇到。这一章是我真实踩坑后的速查手册。4.1 高频故障速查表现象原因解决办法下游Agent收到乱码或JSON解析失败上游输出被Markdown代码块包裹提示词里强调“输出原始JSON禁止代码块”流程里加解析节点兜底上下文超限报错上游把全部字段传给下游交接配置中只勾选下游需要的字段流程卡死原地打转Agent之间互相触发形成循环检查Workflow是否成环设置最大轮次上限调研Agent搜不到内容Skill未挂载或接口Key失效在Skill管理页单独测试调用下游输出结构不稳定提示词约束不够硬把输出Schema写进提示词必要时加格式化Agent统一处理多Agent跑起来反而更慢并行度设置不合理节点排队严重IO密集型任务提高并发计算密集型任务适当降低第一条我特别说一下。现在很多模型受指令影响会把JSON用代码块包起来下游解析直接报错。我的对策是在上游提示词最后加一句“禁止使用Markdown代码块包裹JSON直接输出原始JSON”同时在流程里加一个“解析节点”做兜底。双保险之后这个问题基本绝迹。4.2 什么时候该用多Agent什么时候千万别用不是所有任务都适合上多Agent。我判断的标准很朴素。任务能明确拆分成多个弱耦合子任务适合用。比如调研、写作、校对彼此之间有清晰的交接物。子任务之间需要共享大量中间结果、很难定义接口不适合拆硬拆只会让消息包越来越大最后传不动。一个Agent一次能完成且质量达标不要为了“高级感”硬上。还有一类任务千万别拆下游Agent需要上游全部信息才能工作且这些信息无法压缩。这本质上是单Agent的活。强行拆开会让同样的上下文在不同Agent里重复传递成本直接翻倍速度还更慢。4.3 用专项Agent“减少AI味”热词榜单里有条“workbuddy减少ai味”我一开始还以为是什么玄学后来发现真有人用它去改文章风格。多Agent对减少AI味确实有帮助而且思路很直接把“风格控制”单独拆给一个Agent让它最后统一处理比在写作Agent开头就要求“你要写出人类风格”要有效得多。我习惯在流水线最后加一个“风格化Agent”。它的系统提示词写清楚避免“综上所述”“随着……的发展”这类AI套话删除没有信息量的过渡句多用具体名词和动词优先保留数据与细节删掉空泛评价。这个专项Agent不需要理解整个任务只做一件事反而做得比全能Agent稳定得多。5. 进阶技巧记忆、反思与并行加速前面的流水线只是多Agent的入门局。WorkBuddy还支持几个更高级的玩法用好了能进一步拉高效率。5.1 用共享记忆区保存跨节点状态WorkBuddy里有个全局变量区多个Agent可以往同一个变量里读写。这个机制很实用尤其适合保存“历史结论”。比如调研Agent发现“某产品价格是99元”把这个事实写进全局变量price_note。后面写作Agent和校对Agent虽然不认识彼此但都能通过读取price_note来核对价格描述是否一致。这就避免了同一事实在不同Agent手里出现不同版本的情况。实现方式很简单在流程节点里新增一个“记忆写入”动作字段指向全局变量下游Agent的系统提示词里注明“如需核对事实请从全局变量price_note读取”。我习惯把关键数字、关键结论全部沉淀到全局变量区相当于给多Agent体系加了一个共享工作记忆。5.2 反思Agent让流程自己迭代另一个好用的玩法是加一个反思节点。流程走完一轮后反思Agent读取终稿对照原始任务要求打分指出不足然后触发写作Agent再改一轮。我实际跑下来两轮迭代能把文章的完整度提升不少。第一轮写作Agent容易漏掉一些细节反思Agent用“以目标读者视角审查内容完整性”的口吻挑出问题再回炉一次基本就被补齐了。要注意控制迭代次数。我一般设最大两轮成本和时间都可控。超过两轮边际收益会断崖式下降。5.3 并行策略与执行效率最后说说并行加速。多Agent不意味着所有节点都该并行要看依赖关系。调研阶段如果任务主题有多个独立维度可以拆成多个调研Agent并行跑最后用一个汇总节点合并。写作阶段通常只能串行因为要先有完整资料才能动笔。IO密集型任务比如搜索、抓网页并发度可以调高一点计算密集型任务比如纯文本生成并发太高反而会排队。WorkBuddy的并发参数在Workflow的全局设置里。我常用的一个配置是并行调研节点3个写作节点1个校对节点1个。这样既快又不至于把模型服务打到限流。写到这里多Agent篇的主干内容算是讲完了。我自己的体会是WorkBuddy的多Agent能力真正有价值的不是把几个Agent摆在一起装样子而是逼着你去做任务拆解和接口设计。拆得越细接口越明确产出的稳定度就越高。我最初尝试时也犯过错一口气建了七个Agent结果一半在空转后面就学乖了先两三个把流程跑通再慢慢加节点。最后再分享一个小习惯每次跑完一条多Agent流程我会把消息包JSON留一份样本存到项目资料库下次设计新流程时直接拿出来参考。这个习惯帮我省了大量调试时间也推荐你试试。