最近总有读者来催《WorkBuddy 实战蓝皮书》的多 Agent 篇。说实话这一章我拖了一阵子因为多 Agent 这个功能只要调得好价值非常明显可一旦没有把角色、上下文和流程理顺翻车速度也相当快。在我自己的实践里使用 WorkBuddy 搭建工作台时遇到的效率问题大部分都不是模型不够聪明而是任务被一个 Agent 从头干到尾角色目标相互干扰输出自然变得又长又不精准。WorkBuddy 提供的多 Agent 能力本质上是把这些步骤拆给更专注的角色来做。如果你打算用 WorkBuddy 处理内容生产、资料整理、全栈项目辅助或者科研文献梳理这篇多 Agent 实战记录应该对你有用。我会从底层思路讲到可复现的搭建过程再穿插我自己踩过的坑。1. 多 Agent 是真需求还是为了玩概念1.1 当单个 Agent 开始“不够用”很多刚接触 WorkBuddy 的人一开始都是拿它当一个超级问答框来用的。比如丢一段素材进去让它“帮我写个初稿”或者“读一下这篇 PDF然后做个总结”。这种用法在任务短、目标单一的时候没问题真正的问题出在那些需要跨多个环节的任务上。举个例子你想做一篇行业调研文章正常流程是先收集资料再整理成大纲然后写出初稿接着校对事实和结构最后还要按你的语气统一润色。如果这些事情全部交给同一个 Agent它会在同一个上下文里反复切换身份。刚刚还是资料员下一秒又要变成编辑再过一会儿又成了校对。结果就是前面的资料还没整理完它就开始急着给结论写初稿的时候又把校对规则忘了你让它按“简洁、克制”的风格写它写着写着又开始铺排比句。上下文越长这种“角色漂移”就越明显最终输出的质量只能用碰运气来形容。我自己最深刻的体验是单 Agent 不是不能干活而是它干不了需要“精工”的活。一个人既做资料搜集又做最终审稿就好比让同一个员工既写代码又做安全审计最后大概率是“自己写的东西自己觉得没问题”。多 Agent 的出现恰恰是把这种天然应该分离的角色拆开。1.2 WorkBuddy 里多 Agent 解决什么问题多 Agent 并不是 WorkBuddy 发明的新概念但它把这件事的落地门槛降低了很多。在 WorkBuddy 里你可以把“一个人”拆成“一个团队”比如设置一个研究 Agent、一个写作 Agent、一个审校 Agent各自拥有独立的系统提示词、Skill 技能和输入输出规范。任务在执行的时候每个 Agent 只处理自己被分配的那一段互不干扰。这样做最直接的好处是角色边界清晰。研究 Agent 不需要关心文字是否优美它只需要把资料查全、查准输出一份带引用来源的事实清单。写作 Agent 拿到这份清单后只需要专注于结构、表达和可读性。审校 Agent 再独立地检查逻辑、事实和风格问题。每一环的输入输出都可控出问题时也更容易定位到底是在资料阶段错的还是在写作阶段错的不会一锅粥。用流水线来理解就很容易Agent 是工位上的师傅Skill 是师傅手里的工具Workflow 是传送带。师傅之间不抢活传送带负责把半成品送到下一个工位。我要强调一下WorkBuddy 里的“多 Agent”和你手动开多个聊天窗口完全不一样。手动复制粘贴是在靠人做衔接而用 Workflow 编排之后上一个 Agent 的输出会自动变成下一个 Agent 的输入中间不需要你当“人肉交换机”。1.3 适合尝试多 Agent 的几类场景不是所有任务都需要多 Agent。如果你只是写一段 200 字的朋友圈文案那就没有必要搭一条流水线单 Agent 反而更快。我实际用下来适合多 Agent 的场景一般有几个共同特点环节多、角色角色冲突明显、输出需要反复修正。下面是我觉得最值得用 WorkBuddy 多 Agent 的几类场景场景单 Agent 痛点多 Agent 解法内容生产既要查资料又要写稿还要改风格写着写着就“串味”资料调研、初稿、审校、润色各自独立互不干扰代码辅助一个 Agent 又设计方案又写代码又评审自己写的代码很容易“自我感觉良好”需求分析、技术方案、编码、代码评审分成不同角色科研文献整理文献阅读、信息提取、综述撰写混在一起摘要质量不稳定文献检索、PDF 解析、综述生成、格式校对分步执行数据处理提取、清洗、分析、结论生成步骤长一个 Agent 记不住前面的约束每个环节一个专用 Agent各自处理一段数据并留下结构化结果全栈项目辅助前端、后端、数据库、部署混杂在一个上下文里经常答非所问不同技术栈使用不同 Agent各自维护自己的上下文我给的建议是第一次接触多 Agent不要想着一口气搭出很复杂的系统。先从一个“单 Agent 做着别扭、但流程很清楚”的任务开始把它拆成三段搭一个最简单的流水线。等你能熟练控制角色和上下文切换之后再去碰并行分支和智能决策。多 Agent 能带来的收益很大但前提是你先把基础功练扎实。2. 动手之前先理解多 Agent 的四个核心部件2.1 Agent会思考的角色在 WorkBuddy 里新建一个 Agent本质上就是创建了一个带有专用身份指令的角色。它可以有自己的名字、职责描述、能力边界、输出格式和限制条件。比如我一个“资料研究员”Agent系统提示词大概是这样的你是一名严谨的资料研究员。你的任务是围绕给定主题查找信息并输出一份事实清单。你只能基于真实存在的资料进行总结不得编造数据。请标记不确定的信息。输出格式为 Markdown 列表每条包含来源标题和链接。这个系统提示词的作用是让 Agent 在未来每次运行时都带着这个身份进入状态。它不需要你每次对话都重复“你要严谨”“你要查资料”这些约束已经写死了。多 Agent 里的 Agent 和 WorkBuddy 里的“技能”不一样。Agent 是“角色”技能是“工具”。你可以让两个 Agent 使用同一个技能比如研究 Agent 用网页搜索技能写作 Agent 也可以用网页搜索技能来核对数据但两者的目的不同。关键点在于每个 Agent 的系统提示词应该突出“它该关注什么”和“它不该碰什么”。一个常见的错误是把所有 Agent 的系统提示词都写得特别长好像要把全世界的知识都装进去。实际上越聚焦的 Agent表现越稳定。2.2 Skill可复用的能力Skill 是 WorkBuddy 里很核心的一层。它代表一个可复用的能力单元比如网页搜索、PDF 解析、表格读取、代码执行、数据库查询、文本总结、风格改写等等。Skill 有点像给 Agent 装的插件Agent 负责判断“什么时候用”Skill 负责“把事情做出来”。在多 Agent 场景里Skill 的粒度很重要。我一开始犯过的一个错误是把一个“文章写作”Skill 做成了一整个大杂烩里面既包含查阅资料又包含生成大纲还包括润色。结果就是它和 Agent 的角色重叠运行时候谁主导谁服从都说不清楚。后来我改成更细粒度的 Skill比如“网页内容提取”“PDF 转文本”“Markdown 表格生成”“列表式摘要”让每个 Skill 只做好一件事。这样在设计 Workflow 的时候我可以非常清楚地指定研究 Agent 调用“网页搜索”和“网页内容提取”两个 Skill写作 Agent 只调用“Markdown 写作”审校 Agent 只调用“文本审查”。Skill 最大的价值其实是可复用性。你今天搭好了一个“PDF 提取摘要”的 Skill明天可以在任何 Agent 里直接挂上不需要再写一遍提示词。它也是多 Agent 工作流里最容易沉淀的部分。建议你从第一次搭建开始就把 Skill 当作独立资产来管理不要和某个具体任务绑死。2.3 Workflow串起一切的编排层如果说 Agent 是角色Skill 是工具那 Workflow 就是把它们串起来的流程骨架。在 WorkBuddy 里Workflow 可以简单地理解成一张流程图有节点有连线。每个节点可以是一个 Agent也可以是一个 Skill 动作连线定义了执行顺序和数据流向。最基本的 Workflow 是串行A 跑完把结果给 BB 跑完再把结果给 C。这是 90% 场景的起步版本。稍微复杂一点可以加入并行分支和条件判断。比如当一个审校 Agent 发现“初稿有事实错误”时Workflow 可以自动把初稿和审校意见一起送回写作 Agent 进行二次修改如果审校通过就继续走向最终的风格润色节点。有一点需要提前说清楚Workflow 编排的是“数据流”而不是“对话流”。你不需要关注 Agent 内部具体说了什么只需要定义“上一步输出的哪个字段会成为下一步输入”。你可以在 Workflow 的节点参数里指定输入来源例如input: research_agent.output或context: review_agent.feedback。这样做的好处是每个环节都可以单独测试调试体验会好很多。2.4 关于模型的几个务实选择多 Agent 容易让人产生一种错觉觉得要给每个 Agent 配不同的模型才高级。实际经验告诉我不要一开始就这么干。模型越多成本越高排查问题也越复杂。刚开始搭建时我建议所有 Agent 都用同一个模型先把编排逻辑跑通再逐个替换。等到你对整个工作流已经很熟了可以按下面这个思路去差异化Agent 角色模型偏好原因资料搜集阶段成本低、速度快的模型信息检索不需要太强推理重点在召回率和速度写作、方案设计综合能力强、文本质量高的模型需要理解上下文并输出高质量长文审校、逻辑检查偏好保守、遵循规则严格的模型它要挑毛病不能被“创造性”带偏风格润色有语言风格控制力的模型目标是消除 AI 味不是增加华丽词藻这里要特别提醒模型能力强不代表流程一定好。WorkBuddy 里决定上限的是 Agent 角色定义和 Workflow 设计模型选择更多是决定单点质量。先跑通流程再谈模型调优这个顺序不要搞反。3. 一套能直接跑通的实操工作流3.1 先明确场景再动手建流程很多人一上来就打开 WorkBuddy 开始新建 Agent结果建了半天连 Agent 之间的任务边界都没说清楚。我现在的习惯是先在纸面上把任务拆解清楚再打开界面配置。这里用一个真实案例来说明。假设我需要为公众号写一篇关于某个开源项目的实操教程。整个任务可以拆成这样收集开源项目的官方文档、README、常见问题整理出关键信息提取出教程需要覆盖的知识点形成大纲基于大纲写初稿审校初稿检查事实错误、结构混乱和表达冗余对初稿做“去 AI 味”处理改得更像一个真实用户的体验分享生成摘要、标题建议和关键标签。这六步天然适合做成一个三 Agent 的流水线研究 Agent 负责第 1、2 步写作 Agent 负责第 3 步审校润色 Agent 负责第 4、5、6 步。你会发现任务拆分完之后Agent 的角色定义基本就已经出来了。3.2 我实际创建的三个 Agent我实际在 WorkBuddy 里新建了三个 Agent名字和职能如下Agent 名称角色职责关联 Skill输出物research-agent资料收集、信息核实、大纲生成web_search、page_reader、pdf_extract事实清单和 Markdown 大纲writer-agent基于大纲撰写初稿关注结构完整、表达清晰markdown_writer初稿 Markdown 文档review-agent检查事实错误、逻辑漏洞、风格问题并输出优化建议text_review、style_rewrite审校意见和修订稿创建 Agent 的时候WorkBuddy 会让你填系统提示词。我给 research-agent 的提示词里特别强调了几件事输出必须带来源不要把搜索结果中的营销内容当成事实“信息不足”时要明确说不足而不是硬凑。给 writer-agent 的提示词里写清楚了目标读者是一线技术人员不需要堆砌概念要把步骤写得能直接照着做。给 review-agent 的提示词里则规定审校意见必须具体到段落、具体到语句不能只说“整体不错”。这三个 Agent 不一定要用三个不同的模型我的第一版全部使用默认模型先把流程跑通。3.3 用 Workflow 和 Skill 把 Agent 串起来Workflow 的配置方式在不同版本里会有差异但底层逻辑是一致的画节点、连数据线。下面这个 YAML 风格的配置可以帮你理解核心结构你在界面里照着逻辑映射到对应设置项即可agents: research-agent: model: default system_prompt: ... skills: - web_search - page_reader - pdf_extract writer-agent: model: default system_prompt: ... skills: - markdown_writer review-agent: model: default system_prompt: ... skills: - text_review - style_rewrite workflow: - step: 1 agent: research-agent input: 开源项目名称 目标读者 output: research_note - step: 2 agent: writer-agent input: research_note output: draft - step: 3 agent: review-agent input: draft output: review_feedback - step: 4 condition: review_feedback.status 不通过 action: 返回 writer-agent 修改输入为 draft review_feedback - step: 5 condition: review_feedback.status 通过 action: 进入 style_rewrite Skill输出最终稿在这个配置里研究 Agent 的输出research_note会成为写作 Agent 的输入写作 Agent 输出的draft会成为审校 Agent 的输入。审校 Agent 返回的review_feedback则被用于条件判断。这里的条件分支是关键如果“不通过”就带着反馈回到写作 Agent 做一次修订如果“通过”就进入润色节点。如果你用的 WorkBuddy 界面支持可视化连线那会更直观。你只需要把每个节点的输入输出字段记好然后像接线一样把它们连上。名字随意但建议统一用xxx_output、xxx_feedback这种命名运行日志会好读得多。3.4 第一次运行实测记录我第一次把这条工作流跑起来的时候情况远没有想象中顺利。第一个问题出现在 research-agent 和 writer-agent 的交接上。research-agent 输出了一份特别详细的资料清单但 writer-agent 拿到的似乎只是全文的一小部分导致初稿缺了三个关键章节。排查后发现问题出在 Workflow 的输入字段设置上。我只把research_note这个字段传给了 writer-agent但 research-agent 真正重要的内容其实在“关键信息摘要”这个子项里。后来我在研究 Agent 的输出规范里加了一条输出必须是一个结构化的 Markdown 文档以“关键事实清单”为第一个二级标题再配一个“可用知识点”清单。这样下游 Agent 就能稳定地从固定位置取到内容。第二版跑通之后新的问题是 review-agent 只会说“内容详实、结构清晰”这种空话根本起不到审校作用。我随后修改了它的系统提示词要求它必须按“三个维度”输出事实疑点、结构问题、表达冗余。每个问题都必须指出具体段落并用引用原文的方式标注。加上这个约束之后审校意见的质量才真正达到能用的程度。第三次运行终于让我可以从流程里抽身了。整条工作流跑完大约花了四分钟其中大部分时间在资料搜索上。最终稿跟我亲手修改过的版本相比至少完成了 80% 的工作量。剩下的 20%主要是对信息准确性和语气细节的人工确认。记住这个比例它能帮你判断多 Agent 是否真的在节省时间。4. 任务编排与上下文传递的关键细节4.1 串行、并行、条件分支分别怎么选Workflow 最常用的三种连接方式就是串行、并行和条件分支。串行适合强依赖的任务前一步没跑完后一步就无从开始。比如提纲没确定就去写正文那正文大概率要返工。并行适合互相独立的任务比如在同一篇教程里几个章节分别由不同的 Agent 或 Skill 去写最后再合并。我刚开始用并行的时候也吃了一些苦头。并行不是越多越好因为下游合并 Agent 需要同时处理多个输入如果你的合并规则写得不清楚结果会比串行更乱。我的经验是只有当每个分支的输出本身是“独立成品”时才适合并行。比如三份产品的使用心得分别写成三份文档最后汇总时只需要简单拼接而如果三份内容互相引用、彼此依赖那就老老实实走串行。条件分支则是最能体现 Workflow 价值的地方。审校不通过就回炉通过就继续下一步这就是一个简单的条件分支。条件分支的关键是判断条件必须能明确从结果中读出。你需要在 Agent 的输出格式里提前定义好状态字段比如status: fail/pass而不是让它输出一大段文字让你去猜。这一点在系统提示词里就应该写清楚。4.2 上下文传得好Agent 才不掉链子多 Agent 之间传递的上下文决定了整个工作流的质量。很多时候流程跑出来的结果很水不是因为模型不好而是因为下游 Agent 拿到手的输入要么太碎要么太杂。传递上下文时我遵循三个原则。第一只传“必要的”内容。writer-agent 不需要研究 Agent 搜索到的全部原始网页它需要的是整理好的事实清单和知识点。第二尽量用结构化格式传输不要用一大段散文。JSON、Markdown、表格都行关键是要让下游 Agent 能按字段读取。第三每一步的输出都要考虑“下游要用什么”而不是“这一步自己想输出什么”。举个例子research-agent 的输出我会要求它包含四块结论摘要、关键事实列表、待核实信息、资料来源。writer-agent 在写作时只需要读取“关键事实列表”和“结论摘要”其余内容不需要。这样设置之后上下文稳重清晰出错概率自然降低。有一点要特别提醒如果你在 Workflow 里把每步的完整日志都传给下一步上下文会迅速膨胀。前几步可能感觉不明显跑到后面Agent 的注意力会被无关内容稀释。记住多 Agent 的上下文管理本质上就是在做“信息过滤”。过滤得越好输出的精准度越高。4.3 想减少“AI 味”给下游 Agent 加一层风格约束在 WorkBuddy 里加入一个独立的风格润色 Agent是解决“AI 味”最有效的手段之一。这个方法适合所有内容生产场景我在自己的 WorkBuddy 工作台里专门加了一个 polish-agent。这个 Agent 的任务非常单一不新增内容不做事实核查只负责把文本风格从“AI 腔”改成“真人腔”。它的系统提示词我写得很直接你的任务是消除文本中的 AI 痕迹。删除没有信息量的套话。禁止使用“随着”“综上所述”“不言而喻”“进一步赋能”等表述。每个段落的第一句必须直接给出结论。能一句话说清楚的事情不要拆成三句话。保留数据、来源、专有名词和关键细节。改写后输出全文。加了这一层之后Published文章明显好很多。尤其在一些需要“个人经验分享”感的内容上polish-agent 会帮你把“我们需要认识到……”改成“我实际用下来发现……”把“综上所述该工具具有显著优势”改成“优势很清楚缺点也得直说”。它不会帮你发明体验但会把那些模板化的句子去掉。要注意的是polish-agent 一旦开始“过度发挥”会把一些必要的技术说明也改没了。我给它的限制是“不能删除技术关键词”“不能把长句全部拆成短句”。任何风格改写都要以保留原意和关键信息为前提。4.4 质量反馈要形成闭环多 Agent 工作流真正跑得成熟之后最关键的其实是反馈闭环。也就是下游 Agent 发现问题后不仅要把问题指出来还要把问题和处理建议一起送回上游进行调整形成“审校-退回-修改-再审校”的循环。我在给 review-agent 设计输出格式时用了这样一个结构review_result: status: fail issue_list: - location: 第2节第三段 issue_type: 事实存疑 detail: 文中说该项目支持实时同步但官方文档只提到了手动同步。 suggestion: 删除这句或改成手动同步。 - location: 第4节第一段 issue_type: 表达冗余 detail: 连续两句话重复解释同一个概念。 suggestion: 合并为一句。这个结构传给 writer-agent 后它就能非常明确地知道改哪里、怎么改。而不是收到一句“请整体优化一下”这种模糊反馈。闭环的循环次数也要控制。我一般设置最多两次如果审校连续两次都不通过就停止自动修改转为人工处理。这样可以避免成本和时间的无限消耗。总结一句话多 Agent 的价值不全在“多”而在“环”。把质量反馈做成闭环了整个工作流才是真正可用的自动化系统如果只是各干各的那和手动复制粘贴没有本质区别。5. 多 Agent 实盘问题与排查技巧5.1 Agent 之间互相“打架”最常见的打架情况是研究 Agent 输出的信息和写作 Agent 根据自身知识补写的信息发生冲突。写作 Agent 可能没有认真读取研究 Agent 提供的事实而是自己脑补了一部分内容结果事实就毁了。解决办法有两个一个是把研究 Agent 的输出强制设为写作 Agent 的唯一知识来源并在写作 Agent 的系统提示词里写明“所有事实以输入内容为准不得自行补充未经引用的信息。信息不足时标注为待确认。”另一个是在 Workflow 里把“手工确认后的资料清单”作为闸门资料没确认前不让写作节点启动。后一种更安全适合重要内容。另外一个打架场景是角色边界重叠。比如审校 Agent 也改了写作 Agent 的表述风格导致你拿到的“审校意见”变成了一篇重写稿完全看不出审校的逻辑。所以我在定义角色时会明确写清楚“审校 Agent 只输出问题和修改建议不直接重写全文”除非 Workflow 里单独设置了“修订节点”的权限。5.2 Skill 工具副作用Skill 在多 Agent 里的一个隐患是“副作用”尤其是那些需要写入文件、调用外部 API、执行脚本的 Skill。最常见的问题就是同一个工具被执行了很多次重复下载文件、重复写入数据。我遇到过这样一个 caseresearch-agent 的 Skill 里配置了网页搜索和 PDF 下载它在一个任务里把同一份 PDF 下载了五次因为它在不同轮次的内部判断里都认为“需要再确认一下原文档”。最后工作目录里多了五份一模一样的文件。自那以后我在 Skill 配置里增加了执行次数限制并且要求 Agent 在使用写入类 Skill 前先检查目标文件是否存在。WorkBuddy 里如果支持“工具调用参数”的自定义建议把max_retries: 1这种参数显式写进去。另外尽量把“只读类 Skill”和“写入类 Skill”分开不要让同一个 Skill 既能读取又能写改。副作用越小流程越可控。5.3 死循环和重复劳动Workflow 配上条件分支之后最常见的问题是死循环。审校不通过返回写作 Agent 修改改完审校还是不通过又传回去……如此反复直到 Token 用尽或者你手动打断。我处理这个问题的办法是给条件分支设置最大迭代次数。如果审校环节已经循环了两次系统就不再继续自动修改而是把材料整理成一份“当前版本 审校意见 修改历史”交给人工处理。WorkBuddy 里有条件节点的地方通常都能设置类似次数限制如果没有你可以在 workflow 的第三个节点后面加一个“计数判断”节点手动实现。另外死循环还有一种隐藏形态某个 Skill 因为网络报错反复重试看起来像是在正常执行实际上一直在做无用功。排查时盯着运行日志里的时间戳和调用次数比看结果更快。5.4 Token 消耗失控多 Agent 的 Token 消耗通常会让人感到意外。不是因为模型贵而是因为上下文被反复传递。每走一个节点如果都把原始材料从头到尾传一遍Token 量会成倍膨胀。尤其是那些“输入很长、输出也很长”的中间产物转上两三轮费用就压不住了。我的建议有几点第一上游 Agent 输出时先做压缩只保留必要字段第二下游 Agent 的输入严格引用字段而不是引用全部输出第三每运行一批任务就记录一下各个节点的 Token 消耗找到消耗大头再针对性优化第四如果条件允许给检索类 Agent 配更便宜的模型给写作和审校等核心质量环节配更好的模型。这样既能控制成本又不会牺牲最终质量。5.5 常见问题速查表下面这张速查表是我在多 Agent 实盘中经常对照的一张表你也可以直接用问题表现排查方向推荐解决方式下游 Agent 内容缺失检查 Workflow 输入字段是否传对让上游输出结构化文档下游按字段引用事实错误写作 Agent 自行补充了未提供的信息强制写作 Agent 只以输入为知识来源审校意见是空话审校 Agent 的系统提示词太笼统要求按问题列表格式输出必须引用原文修改后越改越差上下文里混入了不相关的内容减少传递字段只传必要信息和问题清单同一个工具反复执行Skill 没有做幂等处理增加执行次数限制写入前检查文件是否存在工作流卡住可能是条件分支判断条件未设置确保状态字段输出为固定枚举值如 pass/failToken 消耗过高原始内容被多个节点重复传递中间节点做摘要压缩控制输入字段大小Agent 角色冲突两个 Agent 的系统提示词职责重叠明确“该做什么”的同时强调“不该做什么”这张表不是让你把所有问题都套进去而是提醒你遇到多 Agent 流程不稳时先定位是角色定义问题、上下文传输问题还是工具调用问题再动手改。改一个变量重新跑一次比一次性推翻整个配置要高效得多。6. 多 Agent 的进阶玩法6.1 从“流水线”到“团队模拟”当你能熟练跑通流水线式多 Agent 之后可以试试更灵活的玩法团队模拟。这种模式下每个 Agent 不只是按顺序做任务而是带着不同立场参与讨论最后形成一个更综合的结论。比如我做过一个“方案评审”工作流一个 Agent 扮演产品经理从用户需求和商业价值出发提方案一个 Agent 扮演开发者评估技术可行性和实现成本一个 Agent 扮演理性批评者专门挑方案里的风险点最后再由一个决策 Agent 综合分析输出结论。四个 Agent 的上下文里没有任何一个拥有最终决定权这让讨论过程更像一个真实团队的开会现场。团队模拟和流水线最大的区别是信息的流向不再是单项的而是来回往复。决策 Agent 会同时收到三个角色的不同意见它需要处理的是矛盾信息而不是顺承信息。这种模式适合头脑风暴、方案评审和策略讨论。它的缺点也很明显不稳定、耗时长、Token 消耗高。所以不要在日常流水线任务上套用只在真正需要多角度看问题时再用。6.2 给 Agent 加长期记忆WorkBuddy 的会话之间默认是独立的但多 Agent 工作流可以做到“长期记忆”。办法是把关键运行结果持久化到项目文件里下次新任务启动时让 Agent 先读取这个文件作为背景知识。我的做法是在工作流末尾加一个“归档 Skill”负责把本次运行的关键结论、决策理由、遗留问题写入一个项目笔记文件。下次运行同类任务时研究 Agent 先读取这个文件才能开始做新的研究。这样即使过了几周再做同一块内容的续篇新 Agent 也仿佛记得上次做了什么。这里要提醒一句如果是团队共享一个工作区归档文件要有命名规范避免不同项目的记忆互相污染。我通常会按照“项目名-日期-主题.md”的方式命名。另外如果你换了账号也想保留原来的记忆记得把工作区里这些项目记忆文件一并迁过去而不是只迁移 Agent 配置。记忆不在 Agent 配置里在归档文件里。6.3 科研场景怎么用好 WorkBuddy 多 Agent很多科研工作者也在用 WorkBuddy而且尤其适合多 Agent。科研流程通常就是典型的多阶段任务检索文献、阅读摘要、提取关键方法、对比实验数据、整理综述、生成投稿内容。我搭过一个科研辅助工作流文献检索 Agent 负责从数据库里查相关论文阅读 Agent 负责逐篇提取“研究问题-方法-数据集-结论”四项信息综述 Agent 负责把这些信息汇总成结构化的文献综述还有一个审阅 Agent 负责核对每一条结论是否有对应的文献条目防止“编引用”。加了最后这个审阅 Agent 之后综述质量明显提升它能把引文编号错误和断章取义的问题都抓出来。但科研内容终究要谨慎。多 Agent 适合做辅助整理、初稿生成、格式统一这类工作不适合让它直接替你得出结论。设计工作流时一定要在关键节点留出人工确认入口尤其是涉及实验数据解读和学术判断的位置。工具是辅助研究者本人决策这一点不能变。6.4 可控性永远优先于自动化在 WorkBuddy 里做多 Agent玩到最后你会发现最难的不是让它变得更自动而是让它保持可控。自动化的目的是把重复劳动分出去而不是把所有决策都交给流程。我在实际使用中最推崇的做法是从一个最小的单节点开始逐步加 Agent、加连线、加分支每加一层都先跑几遍真实任务验证确认没问题再继续。我现在的工作台上最稳定的一条内容生产流水线不是那个最复杂的反而是结构最简单、反馈闭环最清晰的。复杂本身不是目的效率和质量才是。多 Agent 帮你把流程拆细把上下文接好把反馈闭环做起来它就能成为你真正省力的工作伙伴。如果你现在刚开始接触 WorkBuddy我的建议是先建一个 Agent让它专精一件事再加第二个 Agent让它们形成一次交接最后加第三个 Agent让反馈闭环转起来。每加一个角色你都会对多 Agent 的理解深一层。