Claude Code 代理团队：AI 辅助开发的未来

一份关于 Claude Code 代理团队的实用指南，讲解多个专门代理如何共享任务清单、通过负责人协调，并在单个项目中并行推进后端、前端、数据库与文档工作。

更新 2026年6月29日 · 15分钟读

在大规模应用或企业环境中，上下文消耗速度比您想象得更快。您一小时前做出的重大设计决策很可能已经不在上下文中，因此您不得不反复向模型重新解释它已经推理过的内容。您大体上做得都对，但问题在于，您让一个助手去完成整个团队的工作。

Claude Code 代理团队正是为改变这一点而引入的。理念是：不再让一个会话按部就班地包揽一切，而是启动多个共享任务清单、可彼此直接通信并并行执行工作的专门代理。

本文将带您了解代理团队如何运作、各个专门角色的职责，以及如何在真实的软件项目中对其进行协同。

刚接触 Claude Code？用一个下午掌握基础，参加我们的Claude Code 101课程。

什么是 Claude Code 代理团队？

Claude Code 代理团队是一层协调机制，允许多个 Claude Code 会话同时在同一项目上协作。其中一个会话充当团队负责人（team lead），并创建其他称为队友（teammates）的会话来处理工作的特定部分。

每个队友都作为一个完整、独立的 Claude Code 实例运行，拥有自己的上下文窗口。它们共享任务清单，任务可随时被领取，并在需要协同时直接互发消息。

这不只是打开几个终端标签页、在每个里运行 Claude 这么简单。那样做的话，彼此独立的聊天窗口既看不到对方的进度，也无法就“谁做什么”达成一致。相较之下，代理团队为每个会话提供共享的工作视图和沟通渠道，由负责人保持所有成员方向一致。

在实践中，这意味着您不再充当会话之间的“传话筒”。团队会自行完成协同，您只需设定方向并审核结果。

为什么需要代理团队

单个 Claude Code 会话在项目足够小的时候没问题，但一旦变大就会受限。

每个 Claude Code 会话都有一个上下文窗口，且其容量有限。随着工作推进，会话会被文件内容、命令输出、设计讨论以及您与它的往返交流填满。到某个时间点，更早的信息将不再位于上下文中，模型会开始遗忘您在同一任务中先前做过的决策。

以下三种情况尤为明显：

大型代码库：拥有数百个文件的代码库无法全部装进上下文。会话会反复读取相同文件，浪费大量 tokens 去重建它本已掌握的理解。
复杂项目：横切性功能（例如在后端、前端和测试中统一加入认证）要求模型同时处理过多关注点。每新增一个关注点，都会与其他内容争夺上下文空间。
多项并行任务：在同一会话中同时要求实现功能、重构模块、编写测试和更新文档，等于是在自找麻烦。

答案与人类团队几十年前得出的结论相同：拆分工作。

如果一个会话在重构中触及极限，就把后端改动交给一个队友、前端改动交给另一个、测试更新交给第三个。每个队友只加载自己工作所需的内容。

同样的思路也适用于研究。一项包含三种相互竞争假设的任务，如果由三个队友各自并行验证一种理论、再汇总结论，比单个会话按顺序逐一尝试要快得多。

专精带来深度，并行带来速度。而两者结合时，您就能完成单个会话要么容易幻觉、要么需要极长时间才能完成的工作。

Claude Code 代理团队如何运作

团队会话会经历五个阶段，编排由 Claude Code 内部完成。

定义目标：用朴素自然语言描述您的需求，就像给初级工程师下达任务一样。负责人阅读并决定如何拆解。
分派工作：负责人创建共享任务清单并启动队友，为每位队友指定名称、角色和初始提示词。您可以明确团队结构，或让负责人自行确定。
并行执行：每位队友领取任务、标记进行中、完成后标记已完成。系统会自动处理依赖关系；文件锁可防止冲突。队友之间可直接互发消息——无需通过负责人中转。
合并结果：负责人收集完成的工作、解决冲突，并产出单一输出：PR、报告、重构后的模块，或其他目标所要求的成果。
结果评审：您像审查任意拉取请求一样进行评审：阅读 diff、运行代码、检查测试。

代理团队的专门角色

角色塑造了代理团队的结构。没有角色划分，您最终会得到做着重叠工作的通用会话。Claude Code 不提供固定清单——您可以在简报中定义角色，或指向保存在 .claude/agents/ 下的子代理定义。

规划代理

在任何代码编写之前，规划代理会将目标拆分为任务。它会探索代码库、绘制依赖关系，并生成由可独立完成的小单元构成的任务清单，确保单个队友无需频繁请示即可完成。

实践中，团队负责人常常兼任这一角色。当工作规模足够大时，您也可以运行专门的规划队友。

编码代理

编码代理负责编写实现。大多数队友都会是编码代理，各自负责不同部分——后端、前端、数据库、AI 功能。关键是避免作用域重叠：两个队友编辑同一文件会互相覆盖。

编码代理适合运行在更便宜的模型上。很多实践者会让负责人使用 Opus，而队友使用 Sonnet，因为执行不需要像协调那样深的推理。

测试代理

测试代理负责编写并运行测试。即便编码队友仍在构建端点，它也可以基于已约定的 API 合同开展工作——这样当代码就位时，测试已经准备好了。

您也可以让一个测试队友全程运行，每当编码队友将任务标记为完成时，它就重新运行测试套件。

评审代理

评审代理阅读 diff，标注漏洞、风格问题、遗漏的边界情况和安全问题。将评审拆分给两个视角不同的队友——一个关注安全、一个关注性能——效果尤其好，由负责人整合其结论。

如果您已为项目编写了子代理定义，队友会自动继承其中的工具和系统提示词。

文档代理

文档代理负责编写文档字符串、更新 README，以及更长篇幅的文档，如架构说明或 API 参考。它很适合作为最后运行的队友——等编码和测试完成后，工作的最终形态已清晰可见。

为何专精能提升效果

通用会话必须同时在上下文中容纳实现、测试、文档与评审反馈。专门化的队友只加载所需内容，从而保持上下文小而聚焦。专精也让调试更简单：出问题时，您能准确知道该查看哪个会话。

使用代理团队进行并行开发

并行性是代理团队的核心意义。

一旦负责人将工作拆解为任务并启动队友，所有人就会同时运行。每个队友都是一个独立的 Claude Code 会话，因此工作不会被单一上下文窗口串行排队。完成多部分功能的总耗时从“各部分耗时之和”降为“最慢部分的耗时”。

以下三种组合在并行中尤为奏效。

前后端并行：当您构建同时涉及两层的新功能时，后端队友可构建 API 端点，前端队友同时构建消费该端点的组件。二者通过直接消息进行协调。一旦后端队友确定响应结构，就将该结构发送给前端队友，双方无需等待对方彻底完成即可继续推进。
实现与测试并行：编码队友编写实现的同时，测试队友依据双方约定的合同编写测试。等编码队友将任务标记完成时，测试已就绪可直接运行。相比“先写代码再补测试”的常规顺序，这要快得多。
文档与代码评审并行：一旦编码队友完成某一部分，文档队友即可开始编写文档字符串与 README 更新，同时评审队友阅读 diff 查找缺陷和风格问题。二者互不阻塞，并各自产出由负责人合并。

瓶颈在于文件冲突。两个队友同时写入同一文件会互相覆盖，因此负责人需要按文件或模块边界拆分工作。只要各部分划分清晰，您就可以根据任务清单支持尽可能多的并行队友。

面向大型代码库的 Claude Code 代理团队

在大型代码库中，代理团队几乎是“必需品”，而非“锦上添花”。

拥有数百甚至上千文件的仓库无法装进单一上下文窗口。单个会话在大型代码库上工作时，会将大量预算花在反复“重新认识”代码上。

借助代理团队，每个队友只加载与其工作相关的文件，因此每个队友的上下文窗口都保持小而聚焦。整体团队可以对整个仓库进行推理，但无需任何单个会话独自承担这一负担。

这在三种情境下最为重要：

横切性改动：跨多个模块、涉及数十个文件的重构，单个会话难以不“丢线”。按模块拆分并将每个模块交给一个队友，可将每位队友的范围控制在可管理的程度。
全仓审计：针对大型代码库开展安全审查或性能审计，适合并行运行多个队友，各自查看仓库的不同部分。随后由负责人将其结论整合为一份报告。
长期项目：历时数周的项目会积累大量上下文，单个会话无法承载。代理团队让您将工作拆分为检查点，每个检查点由一位队友负责，而这位队友无需记住此前的所有细节。

当然，这也有代价。

每位队友都是一个完整的 Claude Code 会话，拥有自己的上下文窗口，因此 token 用量会随团队规模线性增长。四人团队在完成相同工作量时，使用的大致是单个会话的四倍 tokens。有的估算甚至更高。权衡在于更短的整体耗时、更深入的专项推理，这通常能让那些单个会话难以现实完成的工作获得回报。

项目越大，使用代理团队的收益越高。但也别滥用——对于小型缺陷修复，单个会话更便宜且同样有效。

代理团队与 Claude Tag

代理团队并不是 Anthropic 重新思考 AI 如何融入团队工作流的唯一方向。

Claude Tag 是一个独立功能，它将 Claude 作为共享的组织参与者引入 Slack。您在频道中 @Claude，Claude 就会利用您组织的工具和频道上下文接手工作。它会记住讨论内容、主动跟进，并以您组织的身份开展工作。

两者解决的是不同的协同问题。代理团队是在单个开发者的机器上、围绕一个聚焦任务协调多个 Claude Code 会话；Claude Tag 则是在 Slack 中、跨越数天或数周，在一支人类团队中协调一个 Claude 身份。但方向一致：AI 正从“单人孤立使用的工具”转变为“嵌入团队既有工作流的参与者”。

这也改变了 AI 需要擅长的能力。

单兵作战的助手需要成为强大的通才；而一个协调系统则需要成为强大的专才，懂得规划、交接、求助，并与其他代理和人类保持一致。代理团队在 Claude Code 的工作流中实现了这一点，Claude Tag 则将其带入 Slack 的工作流中。

构建代理团队的最佳实践

一个优秀的代理团队，关键在于前期设置。团队本身执行很快，但若任务范围界定不清、角色模糊，您将损失大量时间。

以下是几条最佳实践：

清晰定义角色：每位队友应只有一个关注点并拥有一组明确的文件范围。创建队友时，明确告诉它负责什么、不负责什么，以及可以操作哪些文件或模块。角色模糊会导致工作重叠，工作重叠会导致合并冲突。
在并行前先做任务分解：先规划，后并行。先运行一次规划，按清晰的输入、输出与依赖拆解任务，再交由团队执行。规划只需消耗几千个 tokens，而走错方向的团队可能会耗费几十万。
通过 CLAUDE.md 共享规范：每位队友在启动时都会读取工作目录中的 CLAUDE.md 文件，因此请将共享约定放入其中，包括代码风格、文件布局、测试方法和提交信息格式。
设置评审检查点：定期查看队友进度，纠正跑偏者，并在接受负责人输出前进行评审。对于风险较高的任务，要求在任何队友修改前先获批方案。这会强制队友先展示计划，并等待负责人批准。
控制团队规模：大多数工作流从 3 到 5 位队友开始最合适。超过这个数量，协调开销增长速度会超过并行带来的加速。
避免文件冲突：按文件或模块边界拆分工作，确保每位队友彼此清晰分隔。两位队友编辑同一文件会互相覆盖。如果任务确实需要多位队友修改同一文件，请改为串行而非并行。
预先批准常见操作：队友的权限提示会上报给负责人，四人团队就可能产生四倍的提示。请在启动团队前设置好 permissions.allow 列表，使读取文件、运行测试等常规操作不被打断。
模型与角色匹配：负责人使用 Opus 等更强模型，因协调更受益于深度推理；队友使用 Sonnet 执行具体工作。

简而言之：制定详细的工作计划，像给一小组初级工程师做简报那样为团队做说明，给予清晰的边界与共享规范，并在最后检查他们的成果。您的设置越贴近真实工程团队的运作方式，代理团队的表现就会越好。

Claude Code 代理团队实践

下面演示从头到尾的全过程。

我将演示一个小示例：使用 FastAPI 构建的“hello world”REST API，从 SQLite 数据库读取消息；再配一个调用该 API 并展示结果的简单 HTML 页面。应用包含后端路由、数据库层、静态前端以及一份自述文档，很适合由四人团队协作完成。

启用代理团队

代理团队是实验性功能，默认关闭。您可以通过设置环境变量来启用，无论是在 shell 中还是在 Claude Code 设置文件中。

设置文件位于 ~/.claude/settings.json。打开并添加：

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

如果您不想编辑设置文件，可以在启动 Claude Code 前于 shell 中设置该变量：

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

两种方式均可。一旦变量设置完成，Claude Code 就会识别与团队相关的提示，并在您提出请求时启动协调层。

启动 Claude Code 并向团队做简报

为项目创建一个空目录，并在其中启动 Claude Code：

mkdir hello-api && cd hello-api
claude

现在开始向团队做简报。提示词是自然语言，但您对于角色和边界越具体，团队表现就越好。以下是该 hello world API 的提示词：

Create an agent team to build a small "hello world" REST API.

The project is a FastAPI service that returns a greeting from a SQLite
database, plus a tiny HTML page that calls the API and shows the result.
- One teammate on the database: create app/db.py with a sqlite3 connection
  to a greetings.db file. Define a get_greeting() function that returns
  the message column from the first row. On import, create the table if
  it doesn't exist and seed it with "Hello, World!" if empty.
- One teammate on the backend: build a FastAPI app in app/main.py with
  a GET /greeting endpoint that calls get_greeting() from app/db.py.
  Add permissive CORS and mount the static/ directory at the root so
  the HTML page is served from the same origin.
- One teammate on the frontend: build static/index.html as a single page
  that fetches /greeting on load, shows a spinner while loading, displays
  the greeting in a centered card on success, and shows an error message
  on failure. Inline the CSS and JavaScript.
- One teammate on docs: write README.md with installation, run, and
  open-in-browser steps, plus an API reference table. Also create
  requirements.txt with fastapi and uvicorn[standard].
Use Sonnet for each teammate. Require plan approval before any teammate
makes changes.

该提示词有三点值得注意。文件边界（app/db.py、app/main.py、static/index.html、README.md、requirements.txt）可避免重叠。模型选择（Sonnet）能控制 token 成本。而方案审批会强制每位队友在写代码前先展示其计划，为您提供一个纠偏的检查点。