这篇是《WorkBuddy 实战蓝皮书》系列的第六篇聊的是一直想单独拿出来讲清楚的话题多 Agent。前几篇我们把安装、Skills、记忆、模板都过了一遍做到这一篇最核心的事只剩下一件——怎么让 WorkBuddy 从“一个很会聊天的助手”变成“一个能自己分工协作的虚拟团队”。如果你已经用了一段时间 WorkBuddy发现单条对话越来越难装下复杂任务或者同一个任务反复改角色提示词还是会串味那这篇文章就是给你准备的。我会直接按我自己的实操路径来讲先说为什么多 Agent 值得折腾再说角色怎么拆、Skills 怎么配合、输出怎么去 AI 味最后把账号记忆、缓存目录、Linux 部署这些容易卡住人的细节一起收掉。所有示例都是我在系列前几篇中沉淀下来的配置格式不是空谈概念。1. 为什么多 Agent 是 WorkBuddy 的“工作台”核心1.1 单条对话的瓶颈上下文污染与角色混乱先把一个很反直觉的结论放在前面模型能力再强单条对话也不适合承载复杂任务。你可能会觉得“我直接把整份需求发给它让它一步步做完就行”我一开始也这么干结果每次做到一半就开始翻车——要么是它忘了最开始定的输出格式要么是把两个不同阶段的要求混在一起最后给你的东西像一份“四不像”报告。这里的问题不完全是模型笨而是上下文污染。一条对话里塞进目标、背景资料、操作步骤、输出要求、临时补充指令这些东西没有隔离模型在处理后面内容时前面所有信息都会搅在一起。尤其当任务的阶段性很强时比如“先做调研再写方案最后做评审清单”你在同一个对话里反复切换立场模型很容易迷失。WorkBuddy 解决这个问题的思路不是让你去调一个更聪明的单模型而是像开公司一样把不同职责拆给不同的 Agent 去承担。测试下来的感受是让每个 Agent 只专注一个阶段、一类动作准确率比“一个 Agent 从头干到尾”高出一大截。1.2 多 Agent 不是“开一堆窗口”而是建立项目团队很多人第一次接触多 Agent会在 WorkBuddy 里创建好几个助手然后分别开窗口问。这不是多 Agent这是多窗口。真正的多 Agent 协作要满足三个条件第一个条件是角色有边界。每个 Agent 有自己独立的提示词、知识库、Skills 和输出偏好。第二个条件是信息有交付物。Agent 之间不是靠“我记得你刚才说了什么”来协作而是靠文件、工作区、约定好的结构化文本互相衔接。第三个条件是流程有顺序。任务像流水线一样从前一个 Agent 流到后一个而不是所有 Agent 同时去抢同一份任务。我举个例子你可以想象一个“写一篇公众号长文”的任务。我习惯拆成四个角色调研员负责搜集素材并输出带来源的要点摘录策划负责基于素材列大纲和标题方向写手负责根据大纲完成正文审校负责检查逻辑漏洞和文案腔调。每个角色只处理上一个角色给它的文件然后输出给下一个。整个过程里我的作用是定流程和做关键决策而不是反复替模型整理思路。1.3 我踩过的“伪多 Agent”坑说完理想状态再说说最常见的翻车方式。我第一次搭多 Agent 的时候给每个 Agent 写了一大段复杂的提示词以为提示词越详细角色就越立体。结果第一个任务跑下来发现调研员和写手的输出都带着同一股“教科书味”因为它们在底层用的模型是同一个而且我根本没给它们不同的输出约束。后来我才明白光有提示词不够你得在输出约束、Skills 调用和知识库隔离上做出实质差异。否则你只是在同一个模型外面套了层不同的“人设”这种差异很脆任务一复杂就崩。2. 把任务拆成多个 Agent角色编排的具体玩法2.1 拆分原则按“交付物”拆不按“动作”拆多 Agent 编排的第一步不是急着创建角色而是先把任务拆开。我的经验是按交付物拆而不是按动作拆。什么叫按动作拆比如“让它先搜索、再总结、再写文案”这听起来像是阶段但搜索和总结之间没有清晰的交接边界Agent 会重复劳动。按交付物拆的意思是每一个 Agent 的产出必须是一份可以被下一个 Agent 直接消费的东西。拿一个更具体的例子做一份短视频脚本。我会拆成三条流水线——选题 Agent 交付的是“选题分析单”包含目标人群、痛点、钩子方向脚本 Agent 交付的是“分镜脚本稿”审核 Agent 交付的是“审核意见表”。每一份交付物都有固定结构下一个 Agent 就基于这份结构继续工作不用漫无目的地猜测。2.2 我惯用的三种 Agent 角色模型实际配置时我习惯把 Agent 分成三类你可以直接参考这套模型去搭建自己的团队Agent 角色核心职责典型交付物关键约束调研/信息型收集、筛选、归纳外部信息带引用的要点摘要、对比表格注明来源不主动下结论生产/实施型基于给定的资料完成内容产出文章、方案、代码、脚本严格遵循输入文件的格式要求质检/审校型检查前一个 Agent 产出的问题问题清单、修改建议、评分项只挑问题不只给夸奖这三个角色对应的思维方式完全不同调研型要做减法生产型要做加法质检型要做“找茬”。如果混在一个 Agent 里模型很容易在“我要客观”和“我要产出”之间反复摇摆但拆开之后每个 Agent 的气质明确输出质量立刻就不一样。我在 WorkBuddy 里就是这么建的一个项目对应一组 Agent不会去建那种“全知全能型 Agent”。2.3 在 WorkBuddy 中落地项目隔离与模型选择关于落地配置这里写一下我习惯的一套设置方式供你参考。我用的 WorkBuddy 版本支持在项目工作区内管理多个 Agent每个 Agent 会自动关联独立的会话记忆。我的配置顺序是先建项目工作区把任务相关背景资料全部放进工作区。再按上面三类角色建立 Agent每个 Agent 命名清楚比如“调研端木”“写作端木”“审核端木”。为每个 Agent 单独指定模型偏好信息收集任务用响应快、检索强的模型长文本生产用推理能力更好的模型审校用上下文理解更稳定的模型。每个 Agent 都挂上对应的 Skills而不是让所有 Agent 共享全部 Skills。这里面最容易被忽略的就是第四步。如果所有 Agent 都能调用所有 Skills那它们的能力就还是一团浆糊隔离性等于没有。你可以在实际配置时留意一下这个点。3. 用 Skills 打通协作边界协议、调用与壁垒3.1 Skill 的本质把协作协议变成文件多 Agent 之间要协作不能靠“口头约定”。如果调研 Agent 说“我总结好了”但是写作 Agent 不知道这份总结放在哪里、用什么格式保存那协作链条就断了。所以我的做法是把协作协议全部固化到 Skill 里。一个 Skill 对我来说就是一组“可复用的专业流程打包”。它里面既包含触发条件什么场景下该用、工作流程分几步做也包含输出格式模板交付物长什么样。写多 Agent 协作的时候我会专为各个 Agent 之间的交接设计一套“交接 Skill”比如说调研 Agent 完成工作后必须生成一份 markdown 格式的调研简报.md里面要有几个固定区块核心结论、关键信息、信息缺口、风险点。有了这个协议写作 Agent 不需要去问“你的结果在哪”它只需要在启动时检查工作区里有没有对应的文件即可。3.2 一次跨 Agent 调用的完整握手过程我把一次完整的跨 Agent 协作拆开来看大概是这样的第一步任务启动。我在 WorkBuddy 中选定主控 Agent让它接手整个任务的流程编排。第二步主控 Agent 根据流程规划先把“信息采集”子任务分配给调研 Agent并指定调用research_summary这个 Skill。第三步调研 Agent 完成任务后按照 Skill 规定的输出模板把结果写入工作区的指定文件比如artifacts/research.md。第四步主控 Agent 检查文件是否生成再决定是否将任务推进到下一环节。第五步写作 Agent 读取artifacts/research.md按自己的写作 Skill 产出初稿再写入artifacts/draft.md。第六步审校 Agent 读取初稿输出审核意见主控 Agent 汇总所有产物给用户。这套流程看起来多了一层“中间人”但实际跑起来非常顺。因为每一步都有明确的输入输出模型不会自己发挥到偏离轨道。而且文件系统本身就是天然的“记忆保险柜”——就算中间对话断了、记忆清了只要文件还在任务就能接着跑。3.3 Skill 的命名、边界与避坑我之前在系列第二篇里详细写过 Skills 的结构这里只强调几个和多 Agent 相关的特别关注点。第一个是命名要带场景前缀。比如policy_writer_assistant、code_review_checklist不要起那种泛泛的名字如写作助手或检查。因为多 Agent 环境下系统要根据任务描述去索引合适的 Skill名字太泛会让模型选错。第二个是 Skill 内部只写“这一个子任务”的内容不要顺手把别的角色的职责也写进去。一个常见的错误是调研 Skill 里写了一大段“所以你应该这样组织文章结构”这就是越界了。多 Agent 的设计哲学是各司其职Skill 也必须严格遵守这个边界。第三个是给 Skill 增加 disable 条件列出不该用它的情况。例如“如果已存在审核通过的交付物则不再重复生成”。这能防止模型连续触发同一个 Skill 造成重复劳动。4. 多 Agent 输出如何减少 AI 味4.1 为什么 Agent 越多AI 味可能越重这是特别容易忽视的问题。单个 Agent 输出 AI 味你还能手动改一改。多 Agent 流水线一旦跑起来AI 味是会叠加的调研 Agent 给你一份充满模块化表达的资料汇总写作 Agent 基于它去写正文语气会进一步模板化审校 Agent 如果不懂得辨别“什么是有真实感的表达”它甚至会把一些鲜活的口语当作“不够正式”而改掉。我试过把同一篇文章分别用单 Agent 和多 Agent 生产多 Agent 版本反而更容易出现“首先、其次、最后”式的三段展开以及大段正确的废话。这说明问题不是出在模型上而是出在流程设计上——我们没有给每个环节设置“去 AI 味”的关卡。4.2 我给多 Agent 团队设定的四条去 AI 味约束第一条约束禁止无信息量的过渡句。我在写作 Agent 的 Skill 里面直接塞了一条负面清单——不使用“随着科技的发展”“值得一提”“综上所述”“值得注意的是”这类句式。每写一句话必须携带事实、案例或观点否则删掉。第二条约束用第一人称经验串场。比如你在写一篇 WorkBuddy 使用教程直接写“我在第一次配置时出现了……”这比“用户可能会遇到”要真实得多。我要求 Agent 在表达建议时优先使用“我试过”“我习惯”“实测下来”这样的口吻而不是“我们建议”。第三条约束保留粗糙但有信息量的细节。AI 味的重要来源是“追求完美表达”而丢掉了细节。我在审校 Skill 里反而要求如果发现原文有具体的版本号、文件路径、操作报错信息、具体时长一律保留不要为了顺滑而删除。第四条约束控制结构化痕迹。我要求产出场景的文本不要动辄分点列条能用两三句话讲清的事情就不要用 1. 2. 3.。这一条因为和多 Agent 天然的“步骤化倾向”相反必须写进 Skill 才能生效。4.3 一个直观的“前后对比”效果我之前用这套约束搭了一个写作流输入同样一份素材修改前的开头是“值得关注的是WorkBuddy 多 Agent 功能为用户提供了更高效的协作方式。”修改后的开头是“我用 WorkBuddy 搭多 Agent 工作流前后踩了三次坑才搞清楚角色隔离比提示词更重要。”后者的信息量、个人印记明显更强。这类约束放在各个 Agent 的通用 Skill 里也就是所有角色的公共偏好文件里它们会贯穿整个生产过程。你不需要在每个任务里反复叮嘱配置一次后续所有流水线都会自动遵守。5. 账号记忆不受损多 Agent 记忆的迁移与隔离5.1 记忆的分层逻辑会话、工作区与长期记忆搭好多 Agent 之后你马上会遇到一个新问题记忆怎么管理WorkBuddy 的记忆机制并不是一片混沌按我的理解可以分成三层会话记忆只保留在当前对话里的临场信息跨对话会丢失。工作区记忆绑定在项目工作区里的资料、文件、Skill 配置这部分是稳定的。长期/全局记忆保存你在使用过程中沉淀下来的个人偏好、常用说法、历史对话摘要。多 Agent 之间的记忆隔离主要靠的是“工作区记忆”。因为每个 Agent 默认访问它所属工作区的知识库和文件不同项目之间天然就隔开了。同一个项目下的多个 Agent则可以通过共享工作区又通过各自的 Skill 配置保持行为差异。5.2 换账号之后怎么找回原来的工作记忆有不少人问过“换账号之后如何获得原来账号的记忆”我先明确一点账号迁移不是简单的复制粘贴因为记忆和账号、设备、本地存储目录都有关系。我的可复现做法是下面这套迁移三步走。第一步导出知识库和 Skill。在本地找到 WorkBuddy 的配置目录把里面记录 Skills、角色提示词、知识库文件、模板的目录完整打包。装到新环境后放在同样的配置路径下。第二步迁移工作区文件。把所有项目工作区的成品文件和中间产物一起复制到新环境的工作区同名目录这样文件结构不会乱后续多 Agent 读取路径才能对上。第三步重建身份偏好。如果你在旧账号里积累了大量全局记忆比如常用的语气偏好、回答风格这些不是都能自动跟着账号走。你需要主动把它们固化到人格库或全局指令里我当时是把这些写进了一个独立的global_preferences.md文件然后挂到新环境的全局配置中。这个三步走的特点是在“不依赖官方自动同步”的情况下也能保住核心工作积累因为它把记忆拆成了文件层、偏好层、数据结构层一层一层接走而不是指望某个“一键迁移”按钮。5.3 缓存目录到底什么时候改、怎么改WorkBuddy 用久了之后本地缓存会越来越大而且旧缓存里的模型响应片段有时候会干扰新的多 Agent 任务。特别是你改了 Skill 配置之后如果缓存没清干净模型可能还在用旧逻辑回应新任务表现就是“我已经改了提示词但它还是按老一套来”。关于“怎么更改系统缓存目录”我的建议是不要频繁动但要在两个时机动。第一个时机是你要长期使用、而且系统盘空间紧张的时候把缓存目录挪到空间充裕的存储盘。第二个时机是准备做一次大规模配置调整前把旧缓存清理掉避免旧数据干扰。操作方法上如果 WorkBuddy 客户端本身提供存储路径设置直接在设置里改就行如果没有提供可视化入口就通过修改配置文件的方式指定新路径。需要注意的是改了目录之后原缓存的索引可能需要重新生成第一次启动会慢一些这属于正常现象。提示改缓存目录前先确认知识库和记忆文件不在缓存目录里。缓存目录只放临时数据还好如果与配置目录混在一起建议把它们拆开管理。我见过有人为了清缓存把整个配置目录删了结果多 Agent 的角色定义全没了只能重建。6. 工具链互补Linux 部署、Cursor/CodeBuddy 搭配与科研场景6.1 搭配 Cursor 与 CodeBuddy各管一段不抢活WorkBuddy 处理多 Agent 编排和日常文档工作流很顺手但代码编写和 IDE 内调试并不是它最舒适的场地。我身边有不少人是把 WorkBuddy 和 Cursor、CodeBuddy 配合着用的这里画一条清晰的分工线WorkBuddy 管流程。它负责把调研、写作、审校、资料管理这些内容生产型的任务做成流水线沉淀成可重复的模板。Cursor 管编码。在做小工具、脚本、网页项目时Cursor 的代码理解和上下文补全更强适合在 IDE 里直接改代码。CodeBuddy 管代码相关的问答与代码生成验证。当多 Agent 流程里出现了代码交付物比如生成一段数据处理脚本我会让 WorkBuddy 生成脚本文档再把代码部分交给 CodeBuddy 或 Cursor 去执行验证。这样分工的最大好处是避免在一个工具里强行做另一件工具更擅长的事。你现在看到的这篇内容整个流程在 WorkBuddy 里完成但我写的那些自动化脚本是用 Cursor 配合 CodeBuddy 去调通后再放回工作区的。6.2 Linux 上跑 WorkBuddy 的注意点WorkBuddy 在我这边 Linux 环境里的体验还算完整不过有几个安装和使用上的细节值得单独提一句。第一个是权限与路径。装在系统级目录会有权限限制我建议装在用户目录下避免后续 Skill 读写配置时频繁触发 sudo。第二个是中文显示与字体。Linux 桌面如果缺少中文字体WorkBuddy 界面或导出的 PDF 可能乱码。提前安装好中文字体包就好不需要额外处理。第三个是缓存与工作区路径。Linux 下默认路径可能长得比较绕我建议安装完成后第一时间把数据目录改到一个短路径下比如/home/你的用户名/workbuddy_data。因为有些脚本需要直接引用路径太长容易断。第四个是 PDF 导出。群里经常有人问“从入门到精通 PDF 怎么下载”其实如果你需要的是自己整理的资料直接在 WorkBuddy 里把内容生成排版好再按“从入门到精通”的逻辑编成 PDF 是完全可以的。Linux 上依赖的 PDF 组件需要注意安装完整否则部分模板导出中文字体间距会有问题。6.3 科研场景的全流程参考科研是 WorkBuddy 多 Agent 一个很典型的应用方向。我用它做过文献综述和课题思路梳理流程大致是这样第一步用调研 Agent 收集指定方向的文献要点输出成带引用的阅读笔记。第二步用方法 Agent 针对阅读笔记里的方法论部分做归类把不同文献的研究方法、样本量、局限列成对比表。第三步用写作 Agent 基于对比表撰写综述草稿标注哪一段对应哪几篇文献。第四步用审校 Agent 检查综述的逻辑链条和引用遗漏特别是“观点是否都能追溯到具体文献”。这套流程如果你在普通对话里做文献一多必然乱拆成多 Agent 之后每份产物独立复核时只需要看文件结构就能快速定位问题。我多次实测下来的感受是常规文献综述初稿的时间可以压缩到一个下午。6.4 关于版本选择的克制建议我看到搜索词里有“workbuddy 国际版”“workbuddy 国际版下载”这类关键词这里不说太多只说一点原则选版本时优先看你对模型服务、数据存储位置、语言习惯的需求。国际版在部分模型服务和多语言内容上有差异但日常搭建多 Agent 的核心逻辑是一致的安装渠道认准官方站点和正规应用市场避免从不明来源下载修改包那些包里可能夹带私货。另外多账号同时使用的人比如你有工作号和个人号要特别注意记忆隔离。不同账号难免有不同工作区建议每个账号对应独立的存储目录免得两个项目的文件串在一起。这也是我在经历了一次“工作区文件交错”的麻烦后总结出来的教训。最后再分享一个我最近养成的小习惯每次调整完 Agent 角色或 Skill我会强制自己用一个“预演任务”跑一遍而不是直接用真实任务测试。预演任务很短比如让调研 Agent 输出一个 100 字的迷你摘要让写作 Agent 根据摘要写一个 200 字的段落。全程不超过十分钟但能把配置里的断层试出来——哪个 Agent 没有正确读到上一个交付物哪个 Skill 没有触发哪个路径写错了一跑便知。真正进入多 Agent 工作流之后你会慢慢发现WorkBuddy 的价值不是“用 AI 帮你写东西”而是“用一套可复用的流程把零散的信息变成结构化的产出”。这个转变听起来不大但用起来完全是两种体验。下一篇我打算聊聊如何把这些 Agent 工作流沉淀成自己的模板库让从入门到精通的路径真正变得可复制。如果你在配置多 Agent 时遇到了具体报错或者奇怪的行为欢迎在评论区把现象描述出来我们对照实际场景接着排查。