企业官网建设流程全解析

多 Agent 这个话题，我在写《WorkBuddy 实战蓝皮书》前五篇的时候一直压着没动，因为太容易讲成概念课：一堆术语砸下去，读者看着很高级，回到自己的项目里还是不知道第一步该干嘛。这篇我换一种写法，全程按实战来，把“为什么拆、拆成什么样、怎么交接、怎么验收”四件事讲透，让已经装好 WorkBuddy 的朋友照着配一套最小可用的多 Agent 工作流，大概一个下午就能落地。

先说结论：多 Agent 不是多开几个窗口各问各的，那是“多会话”，不是“多 Agent”。真正的多 Agent 协作，是让不同的 AI 角色在同一个任务框架里分工干活，A 的输出变成 B 的输入，B 的结果再交给 C 检验，角色有边界、交接有标准、产物可验证。这篇适用于已经在用 WorkBuddy 做实际项目的开发者，也适用于想把 AI 从“聊天工具”升级成“虚拟团队”的内容工作者和科研用户。看完你会得到一个能直接复用的配置模板和一个完整的实战样例。

1. 先从“为什么”说起：单 Agent 不够，多 Agent 才有戏

1.1 单 Agent 的真正瓶颈不是“笨”，而是“什么都管”

很多人觉得单 Agent 表现不好是因为模型不够聪明，我用了这么久 WorkBuddy 的经验是：大多数情况下问题出在职责过载，而不是智商不够。一个 Agent 在一个会话里既要做需求分析，又要写代码，还要自查、还要写文档，它的上下文窗口里塞满了各种信息，到后半程注意力早就被稀释了。你不是在跟一个全科医生聊天，你是让同一个全科医生既做诊断、又做手术、又做术后护理、又做病历归档，哪一步都不容易做到极致。

另一个问题是角色冲突。同一个 Agent 写完代码，你让它自己审查，它很难真的狠下心挑自己的毛病。我实际测试下来，自我评审的结果往往是“整体实现不错，建议补充几个边界测试”这种客气话，真正的问题它自己看不见。这就像让一个刚写完文章的人自己做校对，他太清楚自己想表达什么了，反而发现不了句子里的歧义。多 Agent 的核心价值就在这里：把开发者和审查者的角色拆开，让审查者带着“陌生人视角”去看产物。

还有一个容易被忽略的点是效率。很多任务天然可以并行，比如同时排查三个模块的依赖关系、同时写三份独立文档、同时验证多个接口的返回结果。单个 Agent 只能串行处理，白白浪费时间。把这类任务拆给多个 Agent 并行跑，总耗时能压到原来的三分之一甚至更低。

1.2 用一张决策清单判断要不要上多 Agent

多 Agent 不是万能的，我见过最离谱的用法是写个两句话的小工具也要拆三个 Agent，结果光任务交接的 token 都比直接写代码还贵。判断一个任务该不该上多 Agent，我一般看四个问题：

• 任务有没有明显的子目标？比如“完成一次代码重构并保证测试全绿”“整理一批文献并输出综述”，这类任务可以自然切分成多个阶段，适合拆；而“解释一下这个函数在做什么”这种一问一答，单 Agent 更好。
• 子目标之间是强依赖还是各自独立？强依赖选流水线，各自独立可以并行，完全独立且数量多才值得开并行池。
• 是否需要不同专业视角？写完要评审、改完要测试、排完雷要总结，这种需要第二个角色把关的任务，多 Agent 优势很明显。
• 失败成本高不高？如果是改坏了就要返工半天的核心模块，我非常建议至少加一个评审 Agent 做质量闸门；如果是临时跑个脚本，直接用单 Agent 就完了。

我自己有个经验法则：整个任务如果能在 15 分钟内用单个会话跑完，就别上多 Agent。一旦任务需要跨多个模块、涉及多轮修改、最后还要验证和归档，那才值得狠狠心把它拆开。

2. 前期准备：把任务拆成子 Agent 能接住的“颗粒度”

2.1 先写一份“总任务说明书”

很多人上来就急着定义各个子 Agent，这是本末倒置。第一步应该是先写总任务说明书，因为后面每份子任务书都是从这份说明派生出来的，源头不清晰，拆出来的东西只会更乱。

我常用的总任务说明书模板长这样：

任务名称： 背景信息： 目标范围： 约束条件： 交付物： 验收标准： 参考文件：

举个例子，我上一篇里做过一个支付服务模块重构，总任务说明书里有一条约束写得特别死：“必须在保持现有 42 个测试用例全部通过的前提下完成重构，不允许改动对外接口签名。”这条约束最终传达到了重构 Agent 的任务书里，也传到了审查 Agent 的验收标准里，才避免了它“发挥创造力”乱改接口。

总任务说明书不需要写得多华丽，但要写清楚边界。模糊的任务书拆出来的子任务一定更模糊，最后所有 Agent 都在猜你的意图，那还不如你自己直接干。

2.2 子 Agent 的角色卡片怎么设计

在 WorkBuddy 里配置多 Agent，核心工作就是为每个子 Agent 设计一张角色卡片。我会把每个 Agent 当成一个新入职的同事来写它的人事档案，字段包括：

• Name：Agent 的名字，比如payment_analyzer，方便后续交接引用。
• Role：一句话定位，说明它在这个团队里负责什么。
• Backstory：给一小段背景描述，帮模型快速进入角色状态。
• Task Focus：明确列出它只管什么，更重要的是列它“不管什么”。
• Input：它接收哪些信息，通常是总任务书、上游交接包、文件路径。
• Output：它必须产出什么格式的交付物，可以是分析报告、代码 diff、测试日志。
• Allowed Tools：它能调用哪些工具，不能动哪些工具。
• Quality Gate：它的输出达到什么标准才算交付完成。

这里我想重点强调 Task Focus 和 Allowed Tools 这两栏。给 Agent 划边界，比给 Agent 提要求更重要。我早期犯过一个错：分析 Agent 跑着跑着看代码不顺眼，顺手改了源文件，结果原始输入被污染，下游所有 Agent 的分析基础都变了。后来我在角色卡片里写死了“不允许修改任何源文件，只能输出分析报告”，这类事故再没出现过。

一个典型的角色卡片示例：

Agent Name: payment_analyzer Role: 负责支付服务模块的代码结构和依赖关系分析 Backstory: 你是一名有 10 年经验的支付系统架构师，擅长从代码中识别风险点。 Task Focus: - 分析模块依赖、外部 API 调用、数据流路径 - 输出风险清单和建议改动范围 - 不修改任何源码 Input: 总任务说明书、模块源码路径 Output: 一份 markdown 格式的分析报告 Allowed Tools: 读文件工具、代码检索工具、git log 查询 Quality Gate: 必须列出所有外部依赖；每个风险点必须给出代码位置和影响说明

2.3 把重复动作沉淀成 Skill

多 Agent 体系里有一个隐藏成本：每个 Agent 都要在对话里反复学习同一套操作流程。比如多个 Agent 都需要读取项目目录结构，或者都需要按固定格式写交接文档，每次都让模型现场理解，既慢又不稳定。解决办法是把它做成 Skill。

Skill 本质是一段标准操作流程描述，起好名字之后，子 Agent 可以在任务里直接引用它，不用重新描述。我建议 Skill 遵循“一个技能只干一件事”的原则，别做一个“全流程大杂烩”技能，那样 Agent 反而不知道什么时候该调用它。

我在 WorkBuddy 里常用的几个 Skill 有：scan_repo用来扫描项目目录结构、run_tests用来执行测试并格式化输出结果、draft_handoff用来生成标准交接包。这些 Skill 一旦沉淀好，在后续所有多 Agent 任务里都能复用，配置一次，长期受益。

3. 在 WorkBuddy 里搭一套多 Agent 工作流：协作模式与任务交接

3.1 先选协作模式：流水线、并行还是编排者模式

多 Agent 的协作拓扑基本只有三种，核心区别在于子任务之间依赖关系的强弱。

流水线模式适合依赖明确的串行任务，比如“分析 -> 方案 -> 实现 -> 验证”，上游输出就是下游输入，流程清晰，每一环都有明确的质量检查点；缺点是某一环节卡住，整条链停摆，所以每个环节最好都配好重试和上报机制。

并行模式适合多个互不相关的独立子任务，比如同时分析三个模块、同时跑多份数据、同时生成多份报告。这种模式效率最高，但需要有人把分散的结果汇总起来，通常需要一个汇总 Agent 或人工兜底。

编排者模式是有一个主 Agent 负责接收大目标、拆解任务、分发给若干执行 Agent、再回收结果。看起来最灵活，但我实际用下来的感受是：编排者 Agent 本身要阅读大量的子任务反馈，它的上下文反而是最先被撑爆的那个。所以除非任务真的复杂到必须动态调度，否则我建议优先用流水线加局部并行的组合。

三种模式的选择其实很直白：活儿之间有先后关系就串起来，没关系的就并着跑，需要动态决策再考虑编排者。别为了“架构感”强行上编排者，复杂不等于高级。

3.2 任务交接协议：让 Agent 之间“认字不认人”

多 Agent 协作里最脏的活儿就是交接。我见过最失败的交接方式是两个 Agent 各自带着完整聊天记录往下传，token 爆炸不说，下游 Agent 还会被上游一句无关的吐槽带偏，最后跑出来的结果完全不能看。

后来我给自己定了一条规矩：Agent 之间只传交接包，不传聊天记录。交接包是一份结构化 markdown 文档，包含上游产出的关键摘要、文件路径、任务要求、交付格式和验收标准。下游 Agent 不需要知道上游经历了什么思考过程，只需要知道“我拿到的这份半成品是什么、我要把它做成什么样才算完”。

我给交接包定的标准结构如下：

# 交接包：模块重构实施 ## 上游交付摘要 - 已确认的改动范围：src/payment/handler.py、src/payment/client.py - 风险点：外部 API 调用依赖重试机制，不可改动重试策略 ## 输入文件 - src/payment/handler.py - src/payment/client.py ## 本轮任务 - 按照分析报告执行重构 - 不改变对外接口签名 ## 交付要求 - 输出代码 diff - 输出改动文件清单 - 输出变更说明 ## 验收标准 - 42 个现有测试用例全部通过 - 无新增第三方依赖 ## 禁止事项 - 不修改接口签名 - 不修改数据库表结构

这份交接包会把每个 Agent 的上下文需求压到最小。它把你从“上一个 Agent 的思维过程”里解放出来，只关注“当前这步要交付什么”。当你开始用这套交接协议，多 Agent 协作的稳定性会有质的提升。

3.3 一个最小可用的 3-Agent 闭环配置

如果你想第一次尝试在 WorkBuddy 里搭一套多 Agent 工作流，我建议从一个最小的 3-Agent 闭环开始，不要一上来就搞五六个角色。这套闭环包含三个角色：入口 Agent、执行 Agent、评审 Agent。

入口 Agent 负责接住你的原始需求，拆解成任务书，并生成初始交接包。它不负责具体干活，只负责“把话说清楚”。执行 Agent 接过交接包，完成实际工作，比如写代码、写文档、整理数据。评审 Agent 根据验收标准检查执行产物的质量，输出通过或返工的意见。

配置步骤很简单：先按 2.2 里的字段定义三个角色卡片，然后把 3.2 的交接包模板保存成一个 Skill，最后在对话里给入口 Agent 一句话指令，比如“启动标准任务流程：帮我完成 XX”。它会自动生成任务书、拆解任务、通过交接包呼叫执行 Agent，再把产物交给评审 Agent。

这套闭环里我建议留一个人工监督点：执行 Agent 交付产物之后、评审 Agent 给结论之前，人应该快速扫一眼 diff 或产物内容。这不叫半自动，这叫关键节点人工把关。全自动不是目的，稳定可控才是目的。

4. 实战拆解：用 4 个 Agent 完成一次模块重构

4.1 案例背景与角色分工

空谈配置没感觉，我拿一个真实的实战案例来走一遍。项目背景是某某支付服务模块需要重构，目标很明确：在保持现有 42 个测试用例全部通过的前提下，优化代码结构和可维护性，且对外接口签名不允许变。

这个任务我拆成了 4 个角色：

这个角色分工的核心逻辑是：分析的人不管改，改的人不管测，测的人不管审，审的人不管改。每一步都有独立的视角，问题才不容易被“自己人”藏起来。

4.2 每一步的交接内容长什么样

分析 Agent 拿到总任务书和源码路径后，输出一份分析报告。这份报告里最关键的部分是外部依赖清单。有次我实操时，分析 Agent 漏掉了某个 HTTP 客户端的重试机制依赖，重构 Agent 顺手把那段逻辑简化了，结果测试阶段暴露了重试时序问题，整个流程被迫回滚。后来我在分析 Agent 的验收标准里加了一条“必须调用scan_repo工具并交叉验证外部依赖”，这个坑再也没有出现过。

重构 Agent 拿到分析报告后，只读取报告里涉及的几个文件，不读整个仓库，这样可以有效压住上下文。它的交付物里我必查的是改动文件数量，如果重构 Agent 一口气改了 20 个文件，说明它想干的事超出了任务书的范围，我会直接让它重新收敛。

测试 Agent 拿到重构后的代码后，执行两件事：跑全量测试、对失败用例做根因分析。如果测试全绿，它的报告里会包含“哪些模块改动不影响行为”的分析；如果有失败，它会给出“是重构引入的问题还是原代码就有问题”的判断。

审查 Agent 最后上，它不看过程，只看三份交付物。它的核心问题是：这次重构值不值得合入？有没有隐藏风险？如果审查 Agent 给出返工建议，它会明确指出是哪个验收标准没达到，下游重新走对应环节即可。

4.3 人工闸门放在哪

这套 4-Agent 流程里，我设计了三个必须人工介入的监督点。第一，入口 Agent 拆完任务后，我会花两分钟检查任务书是否符合我的真实意图，发现问题立刻改，不然后面全是白干。第二，重构 Agent 交出 diff 后，我快速扫一眼改动规模，确认它没有失控。第三，审查 Agent 给出合入建议后，最终决定权在我，我通常会在 WorkBuddy 里打开代码对比，用最小成本做最后一道确认。

这样做的原因是：多 Agent 帮你把脏活累活跑完，但关键决策还是得人来拍板。你让 AI 替你干活，不是让 AI 替你负责。保留这几个监督点，出问题时你才能兜得住，而不是眼看着流程一路错到底。

5. 多 Agent 协作中的常见事故与排查思路

5.1 三个高频事故场景

第一个事故是上下文串味。比如分析 Agent 在报告里顺嘴提了一句“这个代码风格有点像老系统迁移过来的”，这个信息无关紧要，但被下游重构 Agent 看见了，它可能就把“老系统迁移”当成硬约束，做了很多多余操作。解决思路就是我前面说的“认字不认人”——交接包压缩上下文，让该知道的信息留在报告里，不该带的信息一个字都不传。

第二个事故是 Agent 互相矛盾。上游说“这个模块可以放心重构”，下游说“这里有兼容性风险，谁动谁负责”，两个 Agent 在交接包里来回拉扯，流程卡死。这种情况的根因是缺验收标准，防线不清。我会直接引入第三个独立视角做仲裁，让评审 Agent 基于任务书而不是对话判断谁对谁错。

第三个事故是任务兜圈子。执行 Agent 没有明确的验收标准，自己觉得不够好，反复修改，越改越离谱，token 烧了一大堆，最终产物还不如第一版。这种情况我一般会设定“最多自改两轮，否则上报人工”，用硬性重试上限把循环切断。

5.2 问题速查表：症状、原因与处理建议

下面这张表是我踩过多次坑之后整理出来的，现在基本挂在我工作台旁边，每次多 Agent 流程跑出奇怪结果，我就对着它排查。

排查多 Agent 问题，我有一条核心心法：别急着归因为模型能力不行，先怀疑流程定义不严谨。绝大多数事故都出在职责边界模糊、交接信息过多、验收标准缺失这三个环节，流程理顺了，模型自然就听话了。

5.3 三个能长期省心的配置习惯

第一个习惯是给每个 Agent 限定文件访问范围。别让它在一个大仓库里随便逛，逛得越多，噪声越多，token 烧得越快。在角色卡片的 Allowed Tools 里明确它只能读哪些目录，既能提速，又能避免上下文污染。

第二个习惯是交接包里永远写验收标准。没有验收标准的交接包等于让下游 Agent 盲人摸象，它只能靠猜来确定“完成”的定义。你哪怕只写一句“接口签名不变、42 个测试全绿”这种硬指标，也比任何形容词都管用。

第三个习惯是让评审 Agent 用独立会话。评审 Agent 不要继承开发 Agent 的历史对话，它应该像外聘专家一样，只看到产物本身，不带任何“他这段时间很辛苦”的人情包袱。独立会话能保证评审视角的客观性，这是多 Agent 质量门禁有效的前提。

6. 我常用的参数、习惯与最后一公里的建议

6.1 给不同角色配模型与上下文的习惯

如果 WorkBuddy 允许你为不同角色切换模型和上下文长度，我的建议是：分析类任务用轻量快速模型，它在大量文件里做检索，速度比“聪明但慢”的大模型更吃香；重构和代码生成这类对正确性要求极高的环节，用能力最强的模型，这是投入产出比最高的位置；评审 Agent 也适合用轻量模型，它主要做的是对照验收标准检查产物，不需要马拉松式推理。

上下文长度也要按角色区分。分析 Agent 要读源码，上下文可以给大一些；重构 Agent 的输入主要是分析报告，不需要直接面对整个仓库，给中等长度就够；评审 Agent 只需要读交接包和产物，给最小可用上下文，反而能倒逼它聚焦关键信息。Token 预算我习惯按环节封顶，比如重构环节不得超过总量的 40%，否则直接触发检查，防止单个子任务把全天额度吃光。

另外我常年在 Linux 环境上跑多 Agent 任务，交接包目录我固定在/workspace/handoffs/，所有角色都从这个目录读上游产出、往下游写交付物。路径统一之后有个额外好处：即使你换了账号，也能从交接包目录快速恢复“之前的工作记忆”，而不需要翻对话记录。把角色卡片导出备份，把交接包目录指回来，整个多 Agent 工作台的记忆就回来了，这个习惯帮我躲过了好几次账号切换的尴尬。

6.2 搭建个人多 Agent 工作台的检查顺序

多 Agent 工作台不是一次性配完就完事的，我建议你按这个顺序来验收。第一步，先用单 Agent 把完整的任务书跑一遍，确认任务本身是清晰的，别拿一个连你自己都说不清的需求去测试多 Agent。第二步，加上一个评审 Agent，验证闭环里质量闸门能不能拦住问题。第三步，再把其中真正独立的子任务并行化，观察 token 和时间成本的下降。最后，当你对每一步的稳定性都有数了，再考虑上全自动编排。

我身边不少人第一次搭多 Agent 工作台，一上来就搞七个角色、全自动编排、让 Agent 自己分裂 Agent，结果失败率极高。反而是一步步从 3-Agent 闭环扩展上来的，反而更稳。现在我的个人工作台里跑得最顺的场景，除了代码重构，还有科研文献整理：一个 Agent 做检索和筛选，一个 Agent 做摘要提炼，一个 Agent 做交叉验证。三个角色，一条流水线，比我自己埋头读文献高效得多。

6.3 如果只能记住三条经验

如果这篇内容太多，你只能带走三句话，我想留这三句。

多 Agent 不是数量越多越好，成本是非线性上升的。我见过最离谱的配置是 8 个 Agent 处理一个半小时就能完成的小需求，最后光交接包就写了十几份，效率反而比单 Agent 还低。适合的数量永远是“刚好能覆盖必需角色”的最小值。

每个 Agent 的“不做什么”比“做什么”更重要。你可以在角色卡片里写十个职责，但如果忘了写“禁止修改源文件”“禁止调用写接口”，它照样会在你没注意的地方闯祸。边界感是所有多 Agent 协作里最稀缺的品质。

好的多 Agent 工作流，核心是人定交接、Agent 干活，而不是放手让 Agent 自己搞一个“AI 帮派”。AI 和 AI 之间没有默契可言，它们的每一次合作都依赖你预先写好的交接包和验收标准。你的角色不是监工，而是流程设计师。

我自己从单 Agent 切换到多 Agent 的第一个项目就翻过车：两个 Agent 在交接包里各说各话，谁都不服谁，最后我介入时已经烧掉了一整天的 token。后来我彻底接受了“认字不认人”的交接协议，才真正跑顺了这套模式。如果你正在 WorkBuddy 里搭自己的多 Agent 流程，我建议你先别拆太多，拿一个已经能跑通的小任务试一次 A-B-C 闭环，感受一下交接包带来的确定性。你会发现，把任务一股脑丢给单 Agent 的日子，很可能就这样回不去了。