企业官网建设流程全解析

1. 单人开发的效率瓶颈，卡在了哪里

先说一个我自己反复撞过的墙。过去很长一段时间，我用 Claude Code 做开发，方式是开一个主会话，把需求一次性丢进去，然后持续追问、改错、让它继续写。这套流程在前几个小功能时很顺，但随着项目变大，问题开始积累：会话越长，模型的"遗忘"越明显，经常前面讲好的接口规范，写到后面就悄悄变了样；请求 A 和请求 B 之间互相排队，我只能盯着终端等它跑完一轮再想下一步；更麻烦的是，如果中途插一个紧急 Bug，原本的主线任务上下文会被冲得七零八落，回来时你甚至要重新解释一半需求。

这就是单代理模式的天花板。说白了，Claude Code 多代理协同要解决的不是"让模型变得更聪明"，而是改变开发流程的组织方式——把一个大任务拆成若干可以并行、隔离、独立推进的子任务，交给不同的 Agent 去执行，最后再统一整合。这种方式带来的提升不是 10%、20%，而是数量级的：我实测下来，某些重构和功能开发场景确实能接近"一个人干出一个小团队"的效果。

这篇文章不是什么官方文档的搬运，全部来自我个人的真实使用经验，包括配置方法、编排思路、用过的指令、踩过的坑，以及每个决策背后的原因。如果你正在用 Claude Code 并且觉得效率没达到预期，这篇应该能帮上忙。它的核心信息是：多代理不是玄学，它有一套清晰的工作模式，关键是你会不会拆任务、会不会控制上下文、会不会做质量收口。

2. 为什么单个会话写得再久也快不起来

在碰多代理之前，得先理解单代理为什么慢。这个"慢"不是模型推理速度的问题，而是整个工作流的结构性瓶颈。我拆成三个层面来看。

2.1 上下文窗口是所有问题的总根源

Claude Code 的每个会话都有上下文上限。你往会话里塞的日志、代码、对话历史越多，模型真正能"关注"的有效内容就越少。这和人的工作记忆很像：一次能记住 7 个左右的要点已经很好了，你要硬塞 30 个进脑子，那必然前面记了后面忘。

实际表现就是：聊到第 40 轮的时候，它可能已经不记得最初的架构约定。你说"按之前的风格写"，它写出来的是最近 10 轮对话里那个"风格"，不是最初定的那个。这种情况在单体大会话里几乎是不可避免的，唯一的解法是拆——拆成多个各自上下文干净的会话。

2.2 串行执行让时间变成了死账

单会话模式下，你一次只能让模型干一件事。如果项目里有三个互相独立的功能模块要做，你也得一个接一个来。关键是，很多时候你在等结果时自己也没闲着——你在想下一个模块怎么写、要给它什么指令，但这些思考并不能提前"存起来"给模型用。更尴尬的是，模型写模块 A 时如果卡住了，你的整个时间线全部顺延。

用一个厨房的比喻：一个人做一桌菜和五个厨师各做一个菜，完全不是一回事。单个 Claude Code 会话就像一个全能厨师，什么都会，但只有两只手；多代理协同才是有多个厨师各管一灶，互不干扰。

2.3 上下文污染是"隐形杀手"

很多人都没意识到这一点：单会话里，你让模型写完注册登录，接着又让它写支付模块，紧接着又去处理一个报警 Bug。这些任务之间的上下文是会互相污染的。比如支付模块的代码风格可能带上前一个任务的实现细节，报警 Bug 的处理方式又会影响后面继续写支付模块的思路。

这种污染非常难察觉，等你发现的时候往往已经产生了大量无效代码。正确的做法是让不同任务拥有独立、干净的上下文，这就是多代理协同的出发点。

3. 多代理协同的核心逻辑：分派、隔离、汇合

接下来是这篇文章的关键部分。Claude Code 的多代理协同，本质上是三件事的组合：任务分派（把大任务拆成子任务交给不同的 Agent）、上下文隔离（每个 Agent 只看自己需要的上下文）、结果汇合（把子任务的输出整合回主线）。不理解这三件事，就算配了一堆 Agent 也只会更乱。

3.1 任务分派：让每个 Agent 有清晰的"岗位说明"

在 Claude Code 里，Agent 并不是独立的"另一个 Claude"，它更像是在主会话下挂载的一个有特定系统提示词的子工作单元。主 Agent 负责理解全局需求，然后调用子 Agent 去执行特定类型的任务。这个系统提示词就是"岗位说明书"，决定了这个 Agent 擅长什么、用什么逻辑工作。

比如我常用的一个后端开发 Agent，它的系统提示词会强调：遵循项目既有的分层架构、优先复用已有工具类、命名风格必须符合项目规范。这些约束写清楚之后，这个 Agent 产出的代码会比"通用模式"下的模型输出稳定得多。

3.2 上下文隔离：每个 Agent 只看到自己该看的

这是多代理比单会话快的一个重要原因。子 Agent 不需要知道整个项目的来龙去脉，它只需要拿到自己的任务描述和相关的几个文件路径。比如前端 Agent 不需要知道后端数据库的 Schema，测试 Agent 不需要了解 API 具体实现细节。这种隔离让每个 Agent 的上下文窗口都很干净，模型的注意力全部集中在当前任务上。

3.3 结果汇合：最后一步决定生死

子任务执行完，Claude Code 会把结果返回给主 Agent，由主 Agent 做二次加工和整合。这里有个非常关键的动作：主 Agent 必须做"代码审查"。不是简单地把子 Agent 的产出拼在一起，而是要检查接口是否匹配、风格是否统一、是否有重复定义。我在实际使用中发现，多代理协同的失败案例里，绝大多数不是单个 Agent 写得不好，而是在汇合阶段缺乏严格审查。

3.4 四种典型协同模式，按需取用

我根据自己的实践，总结出四种最常用的协同模式：

这四种模式可以混用。一个项目里，前期用流水线梳理架构，中期用并行推进功能，末期用审查模式把关质量，非常常见。

4. 实操：单人如何编排一套多代理工作流

理论讲完，直接上实操。我默认你已经装好了 Claude Code 并且能正常使用。下面按步骤说清楚。

4.1 第一步：用 CLAUDE.md 建立"项目宪法"

很多人的 CLAUDE.md 写得很敷衍，就两三行项目简介。实际上，这个文件是所有 Agent 的公共上下文基础，相当于整个项目的"宪法"。你需要在里面写清楚：

• 项目的整体架构（目录结构、模块划分、数据流）
• 代码风格约定（命名规范、注释要求、格式化工具）
• 常用命令（测试怎么跑、构建怎么执行、调试手段）

有了这个文件，每个 Agent 在被创建时都能自动读取它，从而对项目有个基础认知。这是后续所有协同的基础，值得花时间认真写。

4.2 第二步：定义你自己的子 Agent

最简单的方式是在项目根目录建一个.claude/agents/目录，在里面放 Markdown 文件。每个文件名就是 Agent 的名字，内容就是它的岗位说明。下面是我实际用过的配置：

--- name: backend-dev description: 负责后端功能模块的开发，遵循项目既有架构，输出高质量的 TypeScript 代码 tools: Edit, Write, Bash, Read --- 你是一名资深后端工程师。开发时遵循以下原则： 1. 严格遵循项目分层架构（controller / service / repository / model） 2. 所有新增代码必须附带单元测试 3. 错误处理必须统一走项目封装的异常类 4. 数据库查询必须走仓库层，禁止在 service 层直接写 SQL 5. 代码风格与现有代码保持一致，优先复用已有工具函数

放在.claude/agents/backend-dev.md。然后就可以在主会话里用@backend-dev的方式调用它。

这里要注意tools字段，它决定了这个 Agent 能操作什么。如果你希望某 Agent 只负责分析不负责改代码，就把Write和Edit去掉，只留Read。这样天然防止它改坏东西。

4.3 第三步：并行发起多个子任务

有两个方法可以发起多代理协同：

方法一是对话流式启动，直接在 Claude Code 对话里用@agent-name呼出。但并行场景下这不太方便，因为你需要同时开启多个交互。

方法二是使用 Claude Code 的命令行模式，或者在一个主会话里通过/agents面板管理多个子 Agent。我更推荐后者：先给主 Agent 一个总览，让它把任务拆解后自动调用多个子 Agent。

一个非常实用的技巧是：给主 Agent 明确指定"分派策略"。例如：

你作为项目负责人，将本次迭代拆成三个子任务： 1. 后端API实现 → 指派给 @backend-dev 2. 前端页面实现 → 指派给 @frontend-dev 3. 接口联调测试 → 指派给 @testing-agent 每个子任务完成后，汇总成果并检查模块间接口是否一致。

这样，主 Agent 就会自动按你的策略去调用子 Agent，而不是漫无目的地自己全做。

4.4 第四步：汇合与审查

子任务全部返回后，让主 Agent 做一次统一审查。我习惯用一个通用审查指令模板：

现在检查所有子 Agent 的交付成果： 1. 是否所有新增代码都符合 CLAUDE.md 中的规范 2. 是否存在重复定义的常量、类型、工具函数 3. 前后端接口是否与约定的协议一致 4. 是否有缺失的错误处理链路 5. 运行测试并修复所有失败用例 如果发现问题，直接修复并报告修改了哪些文件。

这一步非常重要，千万不要省。审查 Agent 或主 Agent 做检查时，可以并行处理上述 5 个维度，速度极快。

5. 完整案例：模拟项目X的重构，多代理如何协同

理论加步骤还不够，直接看一个完整案例。以下是一个模拟项目 X 的后端重构经历，我尽量保留实际指令的原貌，方便你对照理解。

5.1 项目背景和初始条件

模拟项目 X 是一个老的单体 Node.js 服务，约两万多行代码，结构混乱，所有逻辑都堆在几个大文件里。需求是：把后端的支付模块、用户模块、订单模块拆出来独立维护，并且要新增一个积分系统，同时补上缺失的单元测试。如果用单会话模式，我预计需要 5 到 8 小时才能完成；用多代理协同，我给自己限定了 90 分钟。

5.2 主会话里的任务拆解指令

我打开一个全新的 Claude Code 会话，第一条指令是：

你是本次重构的项目负责人。项目背景见 CLAUDE.md。 现在将这次重构拆分为以下工作包，并依次执行： 工作包1：由 @architecture-agent 分析现有目录结构，输出模块拆分方案，包括新目录骨架、模块间接口定义、数据流说明。 工作包2：由 @backend-dev 按工作包1的方案，独立实现用户模块和积分系统的后端代码。 工作包3：由 @backend-dev2（第二个实例）独立实现支付模块和订单模块的代码迁移。 工作包4：由 @testing-agent 为所有新代码补单元测试，并确保覆盖率不低于80%。 工作包5：所有工作包完成后，由你亲自做一次全局代码审查，修复所有问题。 先执行工作包1，完成后再启动工作包2和3（这两个可并行），最后执行4和5。

这里的关键点是：工作包 2 和 3 被明确标记为"可并行"，主 Agent 会创建两个独立的 Agent 实例去执行。

5.3 执行过程中的观察

实际执行时，我注意到几个有意思的现象：

工作包 1（架构）只花了约 6 分钟就产出了模块拆分方案，包括目录结构、接口定义、数据流图（纯 Markdown 文本形式，不涉及图表工具）。因为架构 Agent 的系统提示词里写了"输出格式必须为可执行的 Markdown"，它给出的方案几乎可以直接用。

工作包 2 和 3 并行跑了约 20 分钟。期间我什么都没干，就盯着终端看它们各自读取文件、写代码、跑测试。因为上下文隔离，两个 Agent 互不干扰。如果某个 Agent 卡住了，也不会影响另一个。

最后审查阶段，主 Agent 抓出了 4 个跨模块问题：两个重复定义的常量，一个接口参数命名不一致，一处积分系统对订单模块的错误引用。这些问题在单会话模式下很可能溜过去，因为它没有一个"全局视角"的审查环节。

最终，整个重构在 85 分钟完成，包括修复审查问题的时间。测试通过，代码风格统一，模块边界清晰。这个效率放在单会话模式下，我是完全不敢想的。

6. 多代理协同的常见坑和我的避坑方案

效率高的代价是复杂性也高。多代理协同不是没有坑，下面这五个是我踩过最深的，也是大家最可能遇到的。

6.1 文件写入冲突：两个 Agent 同时改同一个文件

这是并行模式最常见的问题。工作包 2 和 3 如果被分到有公共依赖的文件，比如共同的类型定义文件或工具库，两边同时改就会互相覆盖，导致结果不可预测。

我的解决方案是：在任务拆解阶段就明确文件归属。给主 Agent 额外指令：

在分派任务前，先检查各工作包涉及的文件路径。如果存在交叉，优先把公共文件的修改单独拆成一个小任务，由专门的 Agent 完成，禁止其他 Agent 改动这些文件。

这个方法从源头解决了 95% 的文件冲突。

6.2 上下文简报不足：子 Agent 对项目理解太浅

子 Agent 虽然能读 CLAUDE.md，但很多项目信息并不在 CLAUDE.md 里，而是散布在代码中。如果主 Agent 直接把任务丢给子 Agent，子 Agent 可能连项目里已有的工具函数叫什么都搞不清，导致重新造轮子。

我的做法是：在分派给子 Agent 前，先让主 Agent 快速做一次项目概览，然后把概览摘要写进任务指令里。例如：

@backend-dev 在实现积分系统前，先阅读 src/utils/points.ts 和 src/constants/ 目录， 了解已有的积分计算逻辑和常量定义，在现有基础上扩展，禁止重新实现。

这个步骤虽然多花一两分钟，但能节省子 Agent 自己摸索的大量时间，也可以理解为"给新同事做入职培训"。

6.3 子 Agent 的代码风格漂移：各家自扫门前雪

多个子 Agent 各自开发不同模块时，即使有 CLAUDE.md 约束，还是会因为对"规范"理解不一致而出现风格漂移。比如一个 Agent 用单引号，另一个用双引号；一个把错误处理写在中间件里，另一个写在业务函数里。

解决这个问题，我的经验是两层：第一，CLAUDE.md 里不能只写"代码风格统一"这种空话，要写具体规则，比如"字符串统一单引号"、"错误必须 throw 到 controller 层处理"；第二，靠最后的汇总审查兜底。主 Agent 在汇合阶段逐个文件检查风格一致性。

6.4 成本和时间控制的误区：并行不等于免费

很多人以为并行就是同时跑多个会话，所以时间缩短了成本不变，这是错的。并行模式下，多个 Agent 同时消耗 Token，而且每个 Agent 都要重新读取项目上下文。实测下来，多代理协同的 Token 消耗比单会话多 30% 到 60%。

我的建议是：不要为了并行而并行。任务之间有依赖的，老老实实用流水线模式；只有真正独立的模块拆分，才值得用并行。另外，可以给子 Agent 限定"产出文件量"，比如明确"只允许修改 src/modules 下新增文件"，避免它大范围探查无关代码，白白烧 Token。

6.5 审查机制缺失：输出一堆"能跑但不合格"的代码

这是最危险的坑。并行模式一开，子 Agent 各自交活，整个项目很快就变成一堆"局部合理但全局混乱"的代码。如果没有一个强力的审查环节，几个小时后你可能收获的不是一个重构完的项目，而是一堆互相打架的模块。

我给自己的铁律是：任何并行协同任务，最后一个工作包必须是全局代码审查。这不是可选项，是必选项。而且审查 Agent 的系统提示词里，我会特别强调"发现问题直接修复，而不是只报问题"，这样审查 Agent 既当质检员又当修理工，省去一轮返工。

7. 一些进阶技巧：让协同效果更接近"小团队"

基础配置和坑都讲完了，最后分享几个让我效率进一步提升的技巧。这些不算必需，但如果你想把多代理协同做到极致，值得一试。

7.1 给不同 Agent 设置不同的"性格"

子 Agent 的系统提示词里，除了技术规则，还可以加入工作方式和沟通偏好的描述。比如我给测试 Agent 的提示词里会写"发现 Bug 时，优先提供最小可复现样例，且必须附带失败测试代码，不允许只说'这里有问题'"。这个简单的性格设定，能够大幅减少后续沟通成本。

7.2 用独立会话保存中间产物

如果某个子 Agent 产出了很有价值的中间结果，比如架构方案、模块设计文档，我会立刻让它把内容写到独立文档里保存。这不是为了归档，而是方便其他后续任务快速参考，避免每个 Agent 都重新去代码里翻找。

7.3 定期清理会话历史，避免累积污染

即使有多代理协同，主会话依然会随着时间变长而累积上下文。我的习惯是：每完成一个重要里程碑，就把主会话归档，新开一个会话，并且在 CLAUDE.md 或一个独立的进度文档中记录当前状态。

这个习惯一开始很麻烦，但坚持下来之后，我在任何时间点都能快速"空降"到一个全新会话里继续推进项目，而不必带着前面 200 轮对话的历史包袱。

7.4 尝试"导师-执行者"双代理模式

现在我个人最常用的一种模式是：用主 Agent 当"导师"，先让它对每个子任务做详细设计说明，然后子 Agent 严格按说明执行。这比子 Agent 直接理解需求要可靠得多。

具体操作是，分派给子 Agent 的指令不是一段模糊需求，而是一份主 Agent 生成的"任务规格书"——包含输入、输出、约束条件、涉及文件、验收标准。子 Agent 的工作被极大简化，出错率大幅降低。

8. 实测的效率变化和我最终的理解

写到最后，聊一点个人的体感。刚开始用多代理协同的那一周，我其实很抗拒，因为配置和学习成本确实比单会话高。但坚持用了一个月之后，再让我回到纯单会话模式，我已经完全回不去了。

一个典型的对比是：上个月接了一个第三方支付渠道的接入需求，涉及后端接口、前端回调页、测试用例、商户控制台四块内容。单会话模式下，我预估要一个下午；多代理编排后，实际完成时间约 1 小时 20 分钟，其中包括了最后审查修正的时间。这还不是最夸张的，最夸张的是做老项目模块拆分时，8 小时的预估被压缩到了 90 分钟以内。

但这个效率提升有一个前提：任务边界清晰、模块耦合度低、上下文能有效隔离。如果你的项目是那种牵一发而动全身的紧耦合代码，多代理协同的帮助会打折扣，这时比起开并行，还不如先做重构理顺结构。

最后分享一个小技巧：别把多代理当作黑盒一键启动。我每次执行完一个多代理任务，一定会花 5 分钟翻看主 Agent 的汇报，了解它拆了什么任务、哪个任务用时最长、哪些任务被自动合并了。这个复盘过程比任务本身更能提升你下一次编排的质量。我试过连续三代代理编排同一类型任务后，分派策略已经能做到轻车熟路，几乎不需要手动干预。