最近群里聊 WorkBuddy 聊得比较多前五篇把基础工作台、Skill、Workspace、记忆管理都过了一遍很多朋友已经开始把 WorkBuddy 当日常主力工具来用了。但大家普遍卡在同一个地方单 Agent 处理复杂任务时要么上下文越聊越乱要么一个 Agent 从头干到尾前面写好的代码后面自己都忘了。于是这一篇也就是《WorkBuddy 实战蓝皮书》第六篇专门把多 Agent 这件事聊透。多 Agent 不是简单地把窗口开好几个也不是让几个 AI 各干各的再拼在一起。真正能落地的多 Agent是在 WorkBuddy 里把任务拆成有边界的工序给每个环节分配一个明确角色通过 Skill、Workspace 和记忆机制让它们各干一段、彼此交接最终汇成完整成果。这篇会从任务拆解、角色设定、Skill 配合、上下文与记忆管理、交接与冲突处理这几个维度展开最后用一个从需求到部署的完整案例把整套流程完整跑一遍。无论你是刚开始接触 WorkBuddy 的新手还是已经搭过几个工作台的老手这篇文章都能让你少走不少弯路。1. 多Agent在WorkBuddy里的价值一个Agent干不完的活才需要一群Agent1.1 为什么单个Agent总是“越干越糊涂”我先说一个很典型的现象你让一个 Agent 从零开始做一个全栈项目它可能在最开始半小时内表现很好——生成目录结构、写好核心模块、给出数据库设计。但当你继续往下推进让它加功能、改接口、补文档的时候问题就来了。它开始忘记最初的架构设计开始出现前后矛盾甚至把之前已经确认过的代码逻辑推翻重来。这不是你用的模型不够强而是单 Agent 的工作方式有天然上限。大模型在长上下文对话中会面临注意力分散和信息遗忘上下文越长早期关键信息被“稀释”得越厉害。这就像让一个人连续工作十几个小时前面几小时记得很清楚的事情后面可能真的就记混了。解决这个问题靠“提醒它注意”没用正确做法是换一种组织结构——把长任务切成短任务让不同 Agent 专注于不同阶段。1.2 WorkBuddy里多Agent的组织方式一个主控加多个专用AgentWorkBuddy 里做多 Agent核心思路不是“开很多个独立会话”而是“一个主控 Agent 负责拆解和调度多个专用 Agent 负责具体工序”。我常用的组织方式是这样的主控 AgentCoordinator负责理解用户需求拆解任务派发任务给子 Agent检查每个子 Agent 的输出决定是否进入下一环节或打回重做。执行 AgentWorker一个环节对应一个 Worker比如“代码编写 Agent”“测试 Agent”“文档 Agent”“部署 Agent”。每个 Worker 只关心自己的职责范围不越界。验收 AgentReviewer对每个环节的产出做质量检查承担“把关人”的角色。验收不通过直接打回上游修改而不是一路错到底。这套结构和真实项目团队非常像有产品经理拆需求有开发写代码有测试找 bug有文档工程师写说明。每个角色各司其职配合起来产出质量远高于一个人从头干到尾。1.3 什么情况下不值得用多Agent多 Agent 不是银弹我见过不少朋友把简单任务也强行拆给多个 Agent 做结果调度开销比任务本身还大。我自己判断的标准很简单如果这个任务能在两轮对话内做完单 Agent 就够如果任务涉及三个以上不同类型的产出物比如代码、文档、测试报告、部署配置或者需要在多个领域知识之间反复切换才值得拆。另外一个重要前提是你的任务要被拆分成“有先后依赖的清晰工序”。如果任务本身模糊到连你自己都说不清第一步做什么、第二步做什么那多 Agent 也救不了你。先自己把任务想清楚再谈怎么分配。2. 动手之前先拆任务角色边界、交付物和验收标准怎么定2.1 任务拆解的第一原则按“产出物”拆分不按“步骤”拆分做多 Agent 编排时最容易犯的错是把任务按步骤拆——“先让 Agent A 做第 1 步再让 Agent B 做第 2 步”。这种拆法有问题因为步骤之间通常强耦合上游只要输出一点点偏差下游就得全盘返工。我更推荐按“产出物”拆分。举例来说做一个需求是“开发一个待办事项 Web 应用”不要拆成“Agent A 写前端页面Agent B 写后端接口Agent C 部署上线”而是拆成Agent A 的产出物《需求分析文档》包含功能清单、页面原型说明、数据字段定义。Agent B 的产出物《技术方案》包含技术选型、项目目录结构、接口设计、数据库表结构。Agent C 的产出物《可运行代码》包含完整的前后端代码且实现了 Agent B 方案里定义的接口。Agent D 的产出物《测试报告与部署说明》包含关键流程测试结果、部署步骤、环境要求。Agent E 的产出物《用户使用手册》包含安装方式、使用步骤、常见问题。每个 Agent 的交付物边界清晰下游拿到的是完整成果而不是半成品协作效率会高很多。即便某一步返工也只是打回对应的 Agent 重新生成那一份产出物不会牵连其他环节。2.2 给每个Agent写“岗位说明书”拆完任务之后下一步是给每个 Agent 写清楚岗位说明书。这个是我在实际使用中被坑过很多次才总结出来的经验。如果你只告诉 Agent“帮忙写个文档”它在内容深度、格式、语气上会有很大的随机性。但如果像给员工布置工作一样说明清楚输出稳定度能提升一大截。我的岗位说明书模板包含六个要素角色身份你是项目的谁负责什么。比如“你是本项目的后端工程师负责实现 API。”输入材料你会拿到什么材料从哪里读取。比如“你将读取workspace/project/tech_plan.md作为技术依据。”交付物你要产出什么文件什么格式。比如“交付api_server.py包含用户注册、登录、任务增删改查接口。”参考规范你有哪些约定要遵守。比如“接口返回格式统一为{code, data, msg}命名使用小驼峰。”环境范围你能动哪些文件不能动哪些文件。比如“你只能修改workspace/project/server/目录下的文件其他目录只读。”完成标志做到什么程度算完工。比如“代码无语法错误使用python -m py_compile校验通过。”一开始我也觉得写这么多背景信息太麻烦但实际跑下来就会发现省掉的都是反复返工的时间。这个“岗位说明书”不一定要一次性写得非常完美可以先写个初版跑一遍看到哪里协作出问题再补充完善。2.3 用Workspace当“公共工作台”文件流当“接口”多 Agent 协作里Agent 之间怎么传数据你当然可以安排主控把 A 的输出复制粘贴给 B但那样既笨重又容易出错。WorkBuddy 里更推荐的做法是把所有中间产出物统一写入工作区的共享目录下游 Agent 直接从对应路径读取。我一般会建立这样的目录结构workspace/ ├── 01_requirements/ # 需求分析产物 │ └── requirements.md ├── 02_design/ # 技术设计产物 │ └── tech_plan.md ├── 03_code/ # 代码实现产物 │ ├── frontend/ │ └── backend/ ├── 04_test/ # 测试与验收产物 │ └── test_report.md └── 05_docs/ # 用户文档产物 └── user_guide.md这样一来“Agent A 完成后把文件写在01_requirements/下Agent B 开工时先读01_requirements/requirements.md”就成了一个稳定的约定。文件本身既是上游的交付物又是下游的输入接口。这个习惯养成之后多 Agent 协作的稳定性会出现质的飞跃——因为你不再依赖对话之间的记忆而是依赖文件系统这种持久化的信息通道。2.4 角色数量不是越多越好三到六个是黄金区间拆任务时还有一个需要克制的地方角色数。我试过把任务拆得非常细安排了十个 Agent结果绝大部分时间耗在来回转交和校验上产出速度反而比三个 Agent 还慢。后来我把经验总结成一条原则一个任务拆成三到六个 Agent 通常是最舒服的区间。三个以下往往说明任务本身不够复杂六个以上则说明拆得过细建议合并同类工序。比如“前端开发 Agent”和“页面样式 Agent”完全可以合并成一个两个“测试 Agent”如果不涉及不同平台也建议合并。3. 给Agent装上“手和脚”Skill、工具链与文件流的配合3.1 WorkBuddy的Skill到底是什么讲到多 Agent 协作就绕不开 Skill。很多从官方文档入门的朋友对 Skill 的第一印象是“给 AI 的提示词模板”这个理解不够全面。在我实际使用体验里Skill 更像一套“能力包”它把某一个领域要用的知识、操作流程、调用外部工具的方式、输出模板打包在一起让 Agent 拿到 Skill 之后不需要你每次苦口婆心地解释“你怎么做这件事”而是直接按 Skill 定义的方法执行。举个例子。我的“前端开发 Skill”里包含了项目使用的框架版本、组件目录规范、状态管理约定、常见 UI 组件库用法、以及“在修改src/components/下文件前先查阅src/components/README.md”的规矩。任何被分配了前端开发任务的 Agent只要加载这个 Skill行为就会立刻规范起来。3.2 编写一个可复用的Skill从平铺直叙到结构化写 Skill 我建议遵循一个简单模板目标、触发条件、执行步骤、输出模板、注意事项。一个相对完整的 Skill 长这样技能名称后端 API 开发助理 目标根据技术方案文档实现符合约定的后端 API 代码。 触发条件主控分配后端开发任务且工作区存在 tech_plan.md。 执行步骤 1. 读取 /workspace/02_design/tech_plan.md提取接口列表与数据模型。 2. 查看 /workspace/03_code/backend/ 目录现有代码确认框架与风格。 3. 按照接口清单逐个实现不允许跳步。 4. 实现完成后运行代码检查命令。 输出模板 - 每个接口标注请求方法、路径、请求参数、返回示例。 - 修改文件时在文件头注释里注明修改人和修改日期。 注意事项 - 不修改前端目录。 - 不改变数据库表结构除非 tech_plan 中有明确说明。 - 遇到不明确的需求停止实现输出“待确认问题”清单。这个 Skill 写好后任何 Agent 加载它都能快速进入“后端工程师”角色。多 Agent 体系里Skill 是让“角色”真正落地的手段。没有 Skill 的 Agent 是一个泛泛的对话助手挂上 Skill 的 Agent 才是某个领域的熟练工。3.3 多个Skill如何串联主控负责选人Skill负责教人在多 Agent 执行过程中Skill 的选择和加载通常由主控 Agent 决定。比如任务推进到“写代码”阶段主控就把“后端 API 开发助理”Skill 分配给代码 Agent推进到“测试”阶段主控加载“测试用例生成与执行”Skill 给测试 Agent。Skill 的衔接点恰恰对应前面任务拆解里的产出物边界上一环节的产出物文件路径明确之后下一个环节的 Skill 里就写明“先读取上一环节的文件”。这里有一个很实用的技巧如果你发现某个步骤的输出经常不符合预期不要急着换模型先看看是不是这个环节缺一个专门的 Skill。很多看似是模型能力的问题其实是“角色规范不足”的问题。给 Agent 补上一份更细致的 Skill输出质量通常立刻上一个台阶。3.4 外部工具与代码执行让Agent真正“动手”多 Agent 场景下每个 Agent 都需要有操纵实际环境的能力。WorkBuddy 里常见的做法是给对应 Agent 开放代码执行能力、文件读写能力和命令行能力。这里的核心原则是最小权限代码 Agent 需要能改代码文件和运行开发服务器就不该让它能随意删除整个工作区文档 Agent 需要读代码来写说明但不需要写代码。最小权限不止是为了安全更是为了减少 Agent 乱操作导致的冲突。我自己的做法是每个 Agent 执行前在岗位说明书里显式写明可写目录和只读目录。同时在目录命名上就做隔离这样即便 Agent 偶尔越界也大概率不会碰到其他 Agent 正在使用的文件。4. 上下文和记忆管理多Agent翻车的高发区4.1 上下文漂移多Agent最容易遇到的问题多 Agent 跑起来之后第一个常见问题就是上下文漂移。什么叫漂移我拿一个场景解释主控 Agent 一开始和用户确认了需求“做一个支持多用户的待办事项应用”但需求文档 Agent 在写文档时不知怎么把重点偏到了“做一个带统计图表的待办应用”。下游代码 Agent 拿到这份需求文档自然按“图表展示”去设计数据库结果做出的东西完全不是用户要的。这类问题往往不是某个 Agent 故意跑偏而是每一步传递时都丢失了一点信息、增加了一点误解误差一路积累就放大了。我用来对抗上下文漂移的方法是把关键决策写进文件不让它留在对话里。需求文档里必须有“目标用户”“核心功能列表”“非目标功能明确不做的事”这样下游 Agent 的参照物是文件本身而不依赖主控 Agent 的口头转述。4.2 WorkBuddy的项目记忆与会话记忆都重要但别混用这里需要分清楚两个概念会话记忆和项目记忆。会话记忆指的是单个会话窗口内 Agent 能记住的聊天内容通常受上下文窗口限制会话一关可能就丢了。项目记忆则是按照项目维度沉淀下来的信息比如项目目标、技术选型、关键决策记录、文件索引等更接近我们说的“项目资产”。在多 Agent 协作中会话记忆主要服务于当前执行过程中 Agent 对前文的即时理解而项目记忆服务于“跨 Agent、跨时间”的稳定共识。你可以这样理解会话记忆是白板上的临时字迹项目记忆是贴在墙上的项目章程。真正重要的东西一定要写进项目记忆不然换一个会话、换一个 Agent一切又要重新解释。4.3 换账号后原来账号的记忆怎么办提前导出项目记忆有些朋友遇到过这个场景因为种种原因换了一个账号登录 WorkBuddy 后发现原来的工作台、项目记忆都不见了就得一切从零开始。这个问题我自己也踩过后来养成了一个习惯把项目记忆以 Markdown 文件的形式外置保存。也就是说重要的项目说明、决策记录、Skill 配置不依赖平台内部的数据库而是作为工作区里的project_memory.md文件独立存在。这样一来换账号之后只要把工作区目录原样拷入新环境让新账号读取project_memory.md所有关键上下文就都回来了。单纯寄希望于平台自动同步风险还是比较高的。这个“记忆外置”的思路本质上就是把记忆从私有格式变成通用格式从依赖单点环境变成依赖可迁移文件这样的方案相对稳妥一些。4.4 记忆写入的节奏不是所有对话都值得记项目记忆也不是写得越多越好。写得太琐碎Agent 加载记忆时会被大量无关信息干扰反而影响判断。我写记忆的原则是只记三类东西一是用户明确提出的需求与变更二是影响后续所有环节的架构决策三是踩过坑之后的修复结论比如“不要在src/core/下直接写业务代码统一放src/modules/”。至于某一行代码怎么写、某个按钮什么颜色这种细节属于会话记忆的范畴写进项目记忆反而是噪音。在实践里我通常会让主控 Agent 在每次完成一个阶段任务后向project_memory.md中追加一条“阶段决策摘要”控制在三到五句话以内。这样项目记忆会随着项目推进有序沉淀越到后面越有价值。5. Agent之间的交接与冲突处理别让两个Agent改同一个文件5.1 交接单模式让每一次交接都有据可查多 Agent 跑久了你会发现真正影响效率的不是单个 Agent 干活快不快而是 Agent 之间交接顺不顺。两个 Agent 之间如果只是口头说一句“我写完了你接着做”接手的那一方往往要花很长时间重新理解上游产出。所以我在 WorkBuddy 里引入了一个非常朴素但极其有效的做法交接单。交接单是一个固定格式的 Markdown 文件比如handoff.md。上游 Agent 完成后写入以下内容本环节完成了什么列出交付文件清单。每个文件的功能定位。有哪些已知的限制或待办。给下游的建议比如“推荐先读 tech_plan 第 3 节”。下游 Agent 开工第一件事就是读取交接单然后按交接单里的指引开展工作。这个文件相当于生产线上的工序卡把交接变成有明确文档支撑的流程而不是靠记忆和感觉。实测下来加了交接单之后多 Agent 协作返工率可以下降不少。5.2 检查点校验每个环节都要有“入料检验”另一个让我少踩很多坑的做法是在任务编排时给每个环节安排检查点也就是让一个验收 Agent 在下游开始前先检查上游交付文件是否满足要求。比如“代码编写 Agent”开工前验收 Agent 检查“技术方案文档”里是否包含接口定义。如果接口定义缺失直接打回去让方案 Agent 补齐代码 Agent 就完全不启动。这看起来是增加了环节但长远来看总时间是省的。因为带着残缺需求去写代码最后必然返工返工成本通常比检查成本高得多。我自己设定检查点时的经验是不要等整个大环节结束才检查而是每个小阶段完成就检查一次。比如“后端代码写完”“前端代码写完”“联调通过”这三个节点分别检查任何一步发现缺陷能及时定位到具体是哪一个 Agent 的问题修复成本低。5.3 并行执行时如何避免相互覆盖多 Agent 并不是所有任务都要串行有些环节确实可以并行。比如“前端开发”和“后端开发”互相依赖较轻的时候可以让两个 Agent 同时开工。但并行也带来一个新问题大家都写同一片工作区可能出现互相覆盖文件的情况。我应对这个问题的办法很简单按目录隔离 文件锁定。在岗位说明书里前端 Agent 明确写“只修改frontend/目录”后端 Agent 明确写“只修改backend/目录”文档 Agent 只写docs/目录。同时在交接单里记录“当前正在被占用的文件路径”新任务如果要动这些文件要么等待要么在副本上操作后合并。用这种物理隔离的方式基本可以避免两个 Agent 打架。5.4 一旦冲突已经发生回滚与重试策略冲突难免会有关键是发生后怎么处理。我自己的策略是在工作区里维护几个核心目录的 Git 仓库如果条件允许建议开启每次 Agent 完成一个阶段就提交一次。这样一旦发现某个 Agent 改了不该改的文件可以直接回滚到上一个稳定版本。如果因为环境条件限制用不了 Git至少做到每次交接前把当前工作区做一次压缩备份。别嫌这个动作麻烦在没有版本回滚能力的情况下贸然让 Agent 继续跑一旦出错整个工作区可能失控损失会大得多。6. 一个完整示例从需求到部署的多Agent流水线跑通全过程6.1 场景设定做一个“团队待办事项”Web应用理论讲了不少下面用一个完整案例把上面的方法串起来。这个案例我实际跑过结构有代表性需求来自用户的一句话“我想做一个团队待办事项 Web 应用支持登录、任务分配、进度跟踪”目标是输出可运行的代码和文档。我拆分的 Agent 阵容一共有五个Agent A需求分析师产出《需求说明书》明确功能清单和用户故事。Agent B架构设计师产出《技术方案》包括技术栈、数据库表结构、API 设计。Agent C全栈开发按技术方案实现前后端代码。Agent D测试工程师执行测试产出测试报告与部署说明。Agent E文档工程师基于实际代码和测试结果撰写用户手册。6.2 工作区与Skill配置我先把工作区目录建立好再准备五个岗位说明书和对应的 Skill。这里给出一份岗位说明书示例Agent C 的角色全栈开发工程师 输入读取 workspace/02_design/tech_plan.md 交付在 workspace/03_code/ 下生成 frontend/ 与 backend/ 约定 - 按照 tech_plan 里的接口定义实现不得擅自改接口字段。 - 后端使用 Python FastAPI前端使用 Vue3。 - 数据库表结构以 tech_plan 为准。 - 写出代码后运行一次编译检查。 禁止修改 workspace/01_requirements/、workspace/02_design/、workspace/04_test/其余四个 Agent 的岗位说明书格式相同只是内容和可写目录不同。6.3 执行顺序与交接细节整个流水线按如下顺序推进第一环节Agent A 读取用户原始需求产出01_requirements/requirements.md写入交接单说明该文档已完成、需要 Agent B 阅读。第二环节验收 Agent 检查requirements.md是否包含功能清单和用户画像。通过后Agent B 开始工作产出02_design/tech_plan.md明确数据库表users、tasks、projects、API 清单登录、创建任务、更新进度、查看项目任务。第三环节Agent C 先读tech_plan.md按其中的接口和表结构实现 FastAPI 后端与 Vue3 前端。实现过程中如果发现需求不明确不允许自由发挥必须停止并输出“待确认问题清单”提交主控处理。第四环节Agent D 启动开发服务器做冒烟测试填写测试用例执行结果输出04_test/test_report.md和04_test/deploy.md。第五环节Agent E 读取03_code/下的实际代码和04_test/deploy.md输出05_docs/user_guide.md。6.4 实测中遇到的三个卡点和对应解法这个流程跑下来我遇到了三个比较典型的卡点这里逐一说明。第一个卡点Agent B 写的“技术方案”过于概念化没有给出可直接落地的 API 设计。处理方法是回到交接单明确要求“API 设计必须包含请求方法、路径、请求体字段、返回示例”后重跑。这让我意识到岗位说明书里的“交付模板”必须列到非常具体否则模型倾向于产出高屋建瓴但无法落地的内容。第二个卡点Agent C 在实现代码时没有完全遵守技术方案里的数据结构自作主张加了一个字段。验收阶段 Agent D 发现了相关问题随后回滚到 Agent C 提交前的版本。这个问题的根源在于岗位说明书里“不得擅自改接口字段”的约定不够显式地被遵守我把这条约定加粗并放进 Skill 的注意事項里后续没有再犯。第三个卡点Agent E 写文档时采用的是“理想化”的操作步骤和实际代码不一致。处理方法是让 Agent E 在写文档之前先实际运行一遍关键命令把真实输出截图或记录下来再写。这说明一个问题文档 Agent 必须要有“贴近产品实际”的能力约束不能凭空想象功能。6.5 跑通之后的调优建议这套流程跑通之后如果你也想在自己的项目里复刻我的建议是第一次不要追求一步到位先按上面的框架搭一个最小版本跑完一遍再根据卡点优化岗位说明书和 Skill。多 Agent 编排本质上是一个不断迭代调优的过程第一次跑通本身就是巨大的进步之后每跑一次把交接单和岗位说明书更新一次整个工作台就会越来越顺。另外初始任务如果过于庞大建议先手动完成一小部分比如手动准备好项目骨架和初始配置再交给 Agent 推进。这能让 Agent 有一个更明确的起点避免开头几轮都在“猜你想要的目录结构”。给 Agent 一个稳定的起点比让它从零开始自由发挥要高效得多。收尾多Agent真正考验的不是工具而是你的组织能力最后说一点个人体会。多 Agent 不是一个“开启开关就自动变强”的功能它更像你组了一个团队团队好不好用取决于你怎么定义角色、怎么设定边界、怎么安排交接。WorkBuddy 提供了承载这一切的舞台——Skill、Workspace、项目记忆、交接单这些机制组合起来才让多 Agent 从“听起来很酷”变成了“真的能稳定产出”。我在实际使用中最深的感受是多 Agent 调优的重点不是提示词技巧而是工程习惯。把产出物写进文件、把岗位说明书写清楚、把检查点设好、把记忆外置这些都是一个资深的协作流程管理者会自然采用的做法。一旦这些习惯建立起来多 Agent 带来的效率提升是指数级的。希望这一篇的经验能帮你少踩几个坑快速把自己的 WorkBuddy 多 Agent 工作台搭建起来。