1. 多 Agent 到底是什么：用一场接力赛讲明白
先说结论：WorkBuddy 里的多 Agent 不是把几个聊天窗口堆在一起，而是一套有分工、有协作、有交接的自动化工作流。如果你用过 WorkBuddy 的单 Agent 模式，体验大概是“你问一句，它答一句”，最多帮你在一个任务里连续处理几步。多 Agent 的逻辑完全不同——你只需要交代一个总目标，剩下的拆解、执行、验证、汇总全部由多个不同角色的 Agent 接力完成。
我给它打了个比方：单 Agent 是一个全能店员，你让它帮你整理货架，它得从头到尾自己干；多 Agent 是一条流水线，有人负责收货，有人负责分类，有人负责贴标签，有人负责质检。每个环节的人只做自己最擅长的事，最后出来的成果不仅快，而且出错率低。这就是 WorkBuddy 多 Agent 最核心的价值——把复杂任务变成标准化流水线。
这套机制特别适合三类人。第一类是做科研的朋友，论文检索、文献梳理、实验设计、结果分析这些环节如果让一个 Agent 全包，很容易出现“上下文太长”“角色混淆”“结论跟数据对不上”的问题；拆成多个 Agent 之后，每个环节各司其职，质量和稳定性都能提升一大截。第二类是搞全栈开发的人，需求分析、代码生成、测试用例、Bug 修复这些任务性质差异很大，用多 Agent 可以让“写代码的 Agent”和“测代码的 Agent”互相制衡。第三类是知识工作者，需要批量整理资料、生成报告、解析文档的，多 Agent 流水线能把过去两小时的手工活压缩到十分钟。
这一篇是《WorkBuddy 实战蓝皮书》系列的第六篇，前面几篇我们聊过环境搭建、基础技能、工作台配置这些基础内容。这一篇要往深走一步，专门拆解多 Agent 的设计思路、实操配置和避坑经验。读完之后你会理解：多 Agent 不是做得越多越好，关键在于角色边界怎么划、上下文怎么传、结果怎么校验。
2. 角色规划与架构设计：三个 Agent 同时开工的第一步
2.1 先想清楚：你的任务真的需要多 Agent 吗
我见过不少新手一上来就把所有任务都套多 Agent，结果反而比单 Agent 更慢。这里有个非常实用的判断标准：任务是否有明显的阶段划分，且每个阶段需要的技能差异足够大。比如“写一篇行业调研报告”，拆下来是信息收集、数据整理、文字撰写，技能栈完全不同，适合拆；再比如“把一个 Markdown 文档转成 PDF”，中间没有复杂推理，拆了反而增加交接损耗。
我自己常用的判断办法是列一张简单的表，把任务的关键动作写下来，再看动作之间是串行依赖还是可以并行。如果两个环节之间必须等结果，比如“先分析数据再写结论”，那串行多 Agent 合适；如果两个环节互不依赖，比如“同时检索文献和调研竞品”，那并行多 Agent 能省时间。WorkBuddy 里的多 Agent 架构同时支持这两种模式，设计的时候先想清楚依赖关系，后面配置才不会乱。
我的建议是：不是所有任务都要多 Agent，但凡是超过 10 个步骤、需要多轮决策、或者对输出质量要求很高的任务，多 Agent 的收益会非常明显。因为单 Agent 的上下文窗口是有限的，一个角色从头干到尾，前面的信息会被后面的冲淡，这就是所谓的“上下文遗忘”。多 Agent 把工作切碎之后，每个 Agent 只用关心自己那一段的上下文，准确性自然高得多。
2.2 角色拆解的黄金法则：任务切分与上下文隔离
多 Agent 能不能跑出效果，七成取决于你角色拆得合不合理。我总结了一句口诀：“一角色一职责，一任务一上下文”。每个 Agent 只负责一个高度聚焦的任务，接收明确的输入、产出一份明确的交付物，不要贪多。
比如做一个“产品需求分析”任务，我会拆成四个角色：
- 需求解析 Agent：负责把产品描述拆成功能点列表
- 市场调研 Agent：负责收集竞品信息，输出对比表
- 技术评估 Agent：负责人评估每个功能点的实现难度
- 报告撰写 Agent：负责把前三者的输出整合成完整报告
这四个角色的上下文是完全隔离的，每个 Agent 只接收它需要的输入。这样做的好处是：不会被无关信息干扰，输出质量稳定，而且任何一个环节出问题只需要单独调试那一个 Agent，不用整个推倒重来。
WorkBuddy 在技能市场里的“多 Agent 工作流”模板基本都遵循这个原则。你如果不会自己设计，可以直接用现成的模板，然后按自己的场景微调角色名称和上下文内容。如果你是从零开始建，可以参考这个步骤：先写你自己的手工工作流（你平时怎么做这件事的每一步），再把每一步映射成一个角色，最后把步骤与步骤之间传递的“产物”定义清楚，这个产物就是两个 Agent 之间的接口。
2.3 三种常见的多 Agent 架构模式
我在实际应用中总结出三种最常见的架构模式，基本能覆盖 90% 的需求场景。
流水线模式：这个最简单，Agent A 的产出成为 Agent B 的输入，层层递进。适合“数据清洗→特征提取→模型训练→报告生成”这类有明显先后依赖的任务。优点是逻辑清晰、调试方便；缺点是慢，任何一个环节卡住，后面全部等待。
路由分发模式：有一个调度 Agent 负责理解总任务，再把它拆成多个子任务往下分发，最后由汇总 Agent 收口。适合“客户反馈分类”“工单自动处理”这类任务量大的场景。我常用它来处理邮件自动分类，主 Agent 判断一封邮件属于“售后”“商务”“技术支持”哪一类，再让对应领域的子 Agent 去撰写回复草稿。
并行协作模式：多个 Agent 同时开工，各干各的，最后汇总。适合“信息收集类”任务，比如同时调研三个竞品，或者同时分析三份文档。速度提升最明显，但对任务独立性要求高，如果几个任务之间有数据依赖，就不适合强行并行。
这三种模式在 WorkBuddy 里可以组合使用。比如一个复杂的调研任务，可以先路由分发拆成多个子调研，子调研内部用流水线，最后再用一个汇总 Agent 合并结果。架构选型的核心逻辑是先看任务依赖图，再看时间和质量的要求，最后确定角色和连接方式。
3. 工作台配置实操：从对话流到多 Agent 编排
3.1 准备工作：需要先安装什么，在哪里配置
在 WorkBuddy 里配置多 Agent，用的是“工作台（Workbench）”模块。简单理解，工作台就是你的流水线组装车间，你可以在图形界面上把 Agent 一个一个放上去，然后连线、配参数、试运行。如果你是第一次用，建议先确保 WorkBuddy 版本已经更新到支持多 Agent 编排的版本，旧版本可能只支持单 Agent 对话流。
安装和基础配置这里不做展开，前面的系列文章里已经写过。如果你是从零开始，这五个基本元素需要先准备齐：我的技能、角色配置、对话流节点、数据连接器（比如你自己的 API Key 或者文件导入通道）、输出目标（报告文件、代码文件或者直接展示在界面上的文本）。
3.2 手把手：搭建一个“文献综述三 Agent”工作流
我拿科研场景来演示一套完整的多 Agent 搭建流程。假设任务是——“给出一篇关于提示工程在数学推理中应用的研究综述”。
第一步，建三个 Agent 角色：
- Agent 1：文献检索员。输入研究主题，输出相关的论文标题、作者、年份、核心方法列表。
- Agent 2：方法分析员。接收 Agent 1 的论文列表，逐篇提取方法细节、实验数据集、性能数字。
- Agent 3：综述撰写员。接收 Agent 2 的分析结果，生成一篇有逻辑结构、有引用的综述文章。
第二步，在 WorkBuddy 工作台里创建工作流，把三个 Agent 拖到画布上，然后建连接关系。这一步的重点是设置“上下文传递方式”。我一般选择“结构化数据传递”，也就是 Agent 1 输出的是一个规范的表格或 JSON 结构，而不是一段散文。因为 Agent 2 更擅长读取结构化内容来提炼信息，如果传给它的是一大段人话，反而增加理解误差。
第三步，设置每个 Agent 的详细指令。这里有个非常关键的细节——指令必须写清楚输入格式和输出格式，否则 Agent 之间的衔接会出现格式不匹配。比如 Agent 1 的指令是：“根据主题检索相关论文，输出为 Markdown 表格，列包括：标题、年份、方法、实验结果、论文链接。”Agent 2 的指令开头就要写明：“你将收到一张论文信息表格，请逐篇分析方法。”
第四步，设定全局参数。比如“最高迭代次数”“输出语言”“是否启用联网搜索”等。多 Agent 场景下，我习惯把“迭代次数”设成 8 到 10 次，避免复杂任务执行到一半被截断。
整体配置好之后，可以先跑一个小样本测试——把输入主题换成一个更简单的同领域话题，看三个 Agent 能不能正常串联起来。跑通了再换正式任务。
3.3 上下文、记忆与知识库：别把多 Agent 做成失忆流水线
很多新手配置多 Agent 第一个踩的坑是：每个 Agent 都像失忆了一样，前面的信息传不下去。这其实不是你配置错误，而是对 WorkBuddy 的上下文处理机制不够了解。
WorkBuddy 的上下文有几个层级：全局上下文（所有 Agent 都能看到）、局部上下文（单个 Agent 的输入输出）、以及临时记忆（某个 Agent 在运行过程中的中间状态）。多 Agent 编排的关键就是搞明白哪些信息要放进全局上下文，哪些只留在局部。
我的推荐做法是：长久的背景信息（比如项目目标、用户偏好、术语表）放进全局上下文；中间产物（比如某一步的表格、摘要）放进传递连接里，不要塞进全局。全局上下文越短，各个 Agent 的执行速度越快、干扰越少。
另外，如果你希望多个 Agent 共享同一份知识库，可以在 WorkBuddy 里配置“共享知识库”连接器。这样做的好处是每个 Agent 不用重新读一遍背景资料，直接从共享库检索即可。有个技巧——把知识库里的内容按 Agent 的职责打标签，比如“#文献检索”“#方法分析”，这样 Agent 检索时的命中率更高，跑得更精准。
4. 实战案例：论文复现与全栈功能开发
4.1 科研场景：三阶段 Agent 让论文复现不再拆盲盒
论文复现是科研里公认的苦活，核心难点在于“论文写的方法描述和实际复现之间隔着大量隐形工程细节”。我搭了一个三阶段 Agent 流水线，专门处理这类任务。
阶段一，信息抽取 Agent。输入 PDF 版本的论文，输出结构化 JSON，提取模型架构、损失函数、优化器设置、数据预处理流程、核心代码伪代码。这步相当于把论文“翻译”成程序员的工程语言。
阶段二，代码实现 Agent。接收结构化信息，结合 GitHub 上公开的同类实现，生成可运行的 Python 代码框架。这个 Agent 的指令有一个重点：“优先使用当前最稳定的依赖版本，注释标明每个模块对应的论文章节。”
阶段三，实验验证 Agent。运行代码，对比论文中报告的指标，输出差异分析报告。如果跑出来的结果和论文差太多，它会自动生成“差异诊断意见”，比如可能是什么模块实现不对。
这套流水线的优势在于，三个 Agent 各管一段，上下文隔离，不会有“越跑越偏”的问题。而且以后换一篇论文来复现，只需要替换阶段一的输入，后面两个 Agent 完全复用。这就把一次性工作变成了可持续复用的流水线能力，是我个人觉得多 Agent 最有价值的地方。
4.2 开发场景：从需求文档到上线代码的 Agent 协作流
全栈开发是另一个非常适合多 Agent 的场景。搭一个需求到代码的 Agent 流水线，能明显减少“来回改需求”和“写一半卡壳”的体验差。
开发流水线一般这样配：
- 需求解析 Agent：把一段口语化的产品需求转成标准 PRD（产品需求文档）
- 架构设计 Agent：基于 PRD 输出技术选型和模块划分
- 编码实现 Agent：按模块生成代码文件
- 测试 Agent：根据代码编写单元测试并执行，反馈失败用例
- 修复 Agent：接收失败用例，定位 Bug，修复后再次提交测试
这个流水线跑起来之后，最实用的体验是：你可以直接把一份简单的功能描述扔进去，等十几分钟拿到带测试的完整代码初稿。开发这行的经验是，初稿当然不能直接上线，但作为 baseline 已经比空白强太多了。而且因为每一步都有独立的 Agent 把关，代码风格的一致性比单 Agent 连续生成要好得多。
4.3 内容场景：用多 Agent 批量生产高质量文章
内容生产应该是很多人入门多 Agent 的第一站。我自己常用的内容流水线是：选题 Agent（基于热点和知识库输出选题方向）→ 素材 Agent（为选题搜集事实、案例、数据）→ 撰写 Agent（完成初稿）→ 风格 Agent（按目标平台调性润色语言）→ 校对 Agent（检查错别字、事实表述、逻辑断点）。
跟直接用单 Agent 写一篇文章相比，多 Agent 流水线的产出“AI 味”会淡很多。原因在于，“减少 AI 味”这个需求不是一个提示词能解决的，它需要多次角色切换和视角审视：素材 Agent 保证信息密度，撰写 Agent 组织初稿，风格 Agent 专门检查像不像真人写的，校对 Agent 查逻辑漏洞。每一个 Agent 都只负责一个目标，比让一个 Agent 同时追求“信息丰富、生动自然、逻辑严谨、零差错”要有效得多。
这里顺便回应一下热词里高频出现的“workbuddy减少ai味”——我的经验是多 Agent 比任何提示词技巧都好使。你试一次就知道，那个风格 Agent 的输出往往能让人第一眼分不出是人写的还是机器写的。
5. 常见问题与排查技巧实录
5.1 任务跑到一半断开：上下文超限与重试策略
多 Agent 流水线跑大任务时，最常碰到的问题就是“任务执行中断”。WorkBuddy 面板上会显示某个节点报错红色的状态，这时第一反应不要重新跑整个流程，要先看清楚是在哪个 Agent 断的。
绝大多数情况是上下文超限，也就是这个 Agent 接收到的输入太大，超过了它的处理上限。解决办法有几个：一是把上游 Agent 的输出压缩，比如让它只输出核心字段而非全文；二是把任务拆细，加一个中间 Agent 专门做信息摘要；三是在 Agent 指令里加一句“重点输出，忽略次要细节”。
WorkBuddy 的重试机制是按节点重试，不是整个流程重跑，所以你在定位到问题之后，调整 Agent 的参数，单独重跑失败的那个节点就行。调参时建议优先看“最高输出长度”和“上下文窗口”这两个参数，渐进式调整比一下子拉高好。
5.2 角色输出格式不匹配：接口设计必须前置
所谓“格式不匹配”，就是 Agent 2 期待收到一个表格或 JSON，结果 Agent 1 传过来一段自然语言。排查这种问题有一个高效技巧：在 WorkBuddy 的日志面板里查看每个节点的“输入摘要”，一眼就能看出上游传过来的数据结构长什么样。
防止这类问题最好的方式是在指令里写明输出 schema。比如要求 Agent 1“只输出三列表格：功能点 / 优先级 / 备注”，Agent 2 的指令接着写“你将收到一张三列表格，请基于功能点和优先级做分类”。接口约定前置，比事后修补高效得多。
作者也可以直接把一份“示例输出”粘贴到 Agent 的 few-shot 区域。这样 Agent 的模仿成本很低，输出稳定性会肉眼可见地提升。
5.3 总输出质量不稳定：加一个审核 Agent 兜底
多 Agent 流水线跑多了之后，你会发现一个模式：90% 的情况下输出稳定，但偶尔会出现某个 Agent 输出明显偏离预期。手动一条条检查三个四个 Agent 的输出效率很低，我建议的做法是——在流水线末端加一个“质检 Agent”。
这个 Agent 的职责不一定是重写内容，而是按预设的检查清单打分。比如查内容完整性（是否覆盖了所有输入要点）、查逻辑一致性（有没有前后矛盾）、查格式合规性（是否符合目标输出规范）。如果得分低于阈值，它可以自动触发一次“重新生成”；如果得分正常，就直接放行。
这一招在长流程里节省的调试时间非常可观，本质上就是在多 Agent 的系统里引入一个独立的验收环节。用过几次你就会体会到：可观测性比一味的优化提示词更重要，因为你必须先看到问题在哪，才知道要优化什么。
6. 多 Agent 场景的边界与扩展方向
6.1 什么情况下不要用多 Agent
诚实地说，多 Agent 不是万能的，有些场景用了反而更糟。根据我的实际体验，下面这三种情况建议退回单 Agent：
一是交互式创作场景。比如你正在跟 WorkBuddy 一起头脑风暴，思维跳跃性很强，这时如果你把它拆成固定角色流水线，反而会限制灵感发散。这种场景更适合用单 Agent 的完整上下文来处理。
二是需求不明确的任务。如果你自己都没想清楚最终产出长什么样，套多 Agent 只会放大错误——每个环节都可能产生偏差，而它们之间又互相依赖，调试成本成倍增加。这种情况下，先用单 Agent 探索理清思路，比一开始就搭流水线要好。
三是超短任务。比如“帮我把这段文字润色一下”“把这三行的格式统一一下”，这样一个 Agent 二十秒就能干完的事，拆成三个 Agent 纯粹是给自己找麻烦。
6.2 进阶方向：让 Agent 互相审查与自动优化
多 Agent 的价值不止于分工，更高阶的玩法是让 Agent 之间形成互相校验的闭环。比如“编码 Agent”写完代码，“审查 Agent”专门挑毛病；“撰写 Agent”写完初稿，“对抗 Agent”刻意从读者视角找逻辑漏洞。这种互相制衡的结构，本质上是在模拟真实团队里的评审机制。
WorkBuddy 目前支持在同一个工作流里定义循环节点，也就是说 Agent 的输出可以送回给上游重新处理。这让“自动优化”成为可能：初次结果出来后，系统可以自动迭代三到五轮，每一轮都根据校验反馈微调，直到质量达到设定阈值。
我在实际项目中常用的一个做法是，给 Agent 设定“质量分数”作为循环条件，低于 75 分就继续循环，高于 75 分就输出。结果通常会稳定在 80 到 85 分之间，比单 Agent 一次成稿的分数高不少。如果你已经熟练掌握了基础的多 Agent 编排，这个方向很值得探索。
6.3 让多 Agent 为“工具箱”赋能：与 CodeBuddy 等工具链的协同
最后说一个很实际的扩展方向——把多 Agent 跟其他的工具链组合在一起。热词里经常出现 workbuddy 和 codebuddy 的对比，其实这两者的定位并不冲突：CodeBuddy 偏向代码领域的深度辅助，WorkBuddy 更擅长工作流的编排和日常自动化。在多 Agent 的工作流里，可以让 WorkBuddy 的调度 Agent 来决定“什么时候把代码任务交给 CodeBuddy 去执行”，这样你就能得到一套既有工作流编排能力、又有专业代码能力的复合系统。
我也常把 WorkBuddy 多 Agent 跟外部数据源、API 服务联动起来。比如“数据采集 Agent”定时抓取页面，“变更检测 Agent”对比历史版本，“通知 Agent”在出现差异时推送提醒。这本质上就是一种轻量级的自动化监控系统，而且完全是用 WorkBuddy 搭出来的。
多 Agent 的上限取决于你的想象力。我见过有人拿它做SOP文档自动生成，有人做课程设计辅助，有人做复杂报表的自动解读，还有人做跨语言资料的自动翻译与校对。如果说 WorkBuddy 单 Agent 是一个聪明的助手，那一组设计良好的多 Agent 协作流，就更接近于一个迷你但完整的数字工作组。我自己用下来的体会是：不要追求一次把所有角色都搭全，先从一个两个 Agent 的简单协作开始，跑顺了再慢慢加角色、加循环、加外部工具。多 Agent 最难的永远是第一步的角色切分，这个想不清楚，后面全是补丁工程。把这篇文章里讲的拆解方法拿去做一次实践，你再回头搭建任何复杂工作流，都会轻松很多。
