企业官网建设流程全解析

1. 为什么需要 Agent Teams：单个 Agent 的极限就是团队协作的起点

先从我自己的体验说起。去年我用单个 Claude Code Agent 跑一个中型的 Web 应用项目，功能不算复杂，大概十几个页面、一套权限系统、一个消息队列。前两周非常顺利，一个会话把需求聊清楚，拆任务、写代码、跑测试、修 bug，一气呵成。但项目到中期开始出问题：上下文窗口越来越紧张，我不得不频繁压缩对话历史；改完后端接口，再去改前端调用时，Agent 已经记不清之前定的参数规范；最麻烦的是，当我说“帮我把注册流程的整体安全性过一遍”时，它永远只盯着最近两块代码，不会像人一样把认证、令牌存储、请求校验全部串起来看。

那段时间我的应对办法很原始：手动开多个终端窗口，每个窗口跑一个独立的 Claude Code 会话，自己当“人肉路由器”，把任务分段派发给不同会话，再手工汇总结果。管两三个会话已经手忙脚乱，最后代码库还出现了两个会话各自为政、风格不一致的问题。

所以当我看到 Claude Code 的 Agent Teams 能力时，第一反应是：这不就是把我一直在手动做的事情变成了工具原生支持的机制吗？它允许在一个共享代码库上同时运行多个 Claude Agents，每个 Agent 有独立的会话上下文、任务目标和可以调用的工具，但都工作在同一套文件体系里，并且彼此能看到对方的产出。

读到这里的读者要分一下类。如果你只是用 Claude Code 改改小脚本、写点单元测试，单 Agent 完全够用，Agent Teams 对你来说属于“以后可能用得上”的功能。但如果你的项目已经开始出现这些信号——单个会话上下文不够用、任务批量积压、需要多个技术栈同时改（比如后端、前端、脚本、Docker 配置）、或者你自己已经手动开过好几个 Claude Code 窗口来回切，那这篇内容就是为你写的。我会把 Agent Teams 从“为什么存在”到“怎么配、怎么跑、怎么避坑”完整走一遍，最后附上我在实战中遇到的高频问题速查表。

2. Agent Teams 的设计哲学：把“一个人干所有活”变成“一屋子专家开黑”

2.1 单 Agent 会话在复杂项目里的三个结构性瓶颈

要理解 Agent Teams 的价值，得先看清单 Agent 在复杂项目里到底是哪里不行。我总结为三个结构性瓶颈，不是调参能解决的。

第一个是上下文轮换问题。Claude 的上下文窗口再大也是有限资源。一个会话从需求聊到架构，再从架构聊到具体文件，早期对话中的决策细节会被逐渐挤掉。表现为：Agent 写到一半突然问你已经定过的参数叫什么，或者按旧方案实现了一个你早就推翻的设计。这不是模型变笨了，是信息被轮换出去了。单 Agent 模式下你只能频繁“重新提醒”，浪费 token 不说，还容易引入前后矛盾。

第二个是任务串行问题。单个 Agent 同一时间只能做一件事。写登录接口的时候它没法同时去调 UI 布局，改数据库模型的时候没办法并行写迁移脚本。人干活还能多线程推进——你让后端小王写接口，让前端小李调页面，让测试小张先写用例——但单 Agent 只能一步一步来。项目一大，整个周期被拉成一条巨长的流水线。

第三个是角色分工缺失。单 Agent 写出来的代码往往“风格统一”，但代价是缺少专业视角的相互制衡。写业务逻辑的人不会主动检查 SQL 注入面，写功能的人容易忽略错误处理路径。人在团队协作时，测试工程师会专门挑开发的毛病，安全专家会专门审视认证流程，这种“外部视角”对质量至关重要。单 Agent 再强，本质上是“一个人既写代码又自己评审”，而自我评审天然存在盲区。

2.2 Agent Teams 的两种形态：并行上下文与子代理分发

现在 Claude Code 里的多 Agent 能力分两种形态，很多人一开始容易搞混，我在这里先说清楚。

第一种是传统的 subagents 模式，也就是在单个会话中通过工具调用子代理去处理局部任务。你可以把这种模式理解为“一个项目经理把活儿派给手下的临时工，但所有信息都要回到项目经理这里汇总”。子代理没有独立的长期记忆，跑完任务就把结果交回来，然后消失。它适合单个会话里“帮我看看这个函数哪里有 bug”“帮我画个序列图”这种独立小任务。

第二种就是 Agent Teams，形态完全不同。它启动后，每个 Agent 是一个独立的 Claude Code 会话，有自己的上下文、角色设定、任务状态，并且所有成员共享同一个文件系统。用大白话说，这是一个真正的“多人协作项目”：架构师 Agent 在写设计方案的时候，后端 Agent 已经在按方案签名实现接口，测试 Agent 同时在旁边看接口边界条件够不够。它们之间不需要一个全局大脑来做中转，而是通过代码和文档直接协作。

这两种模式不冲突，实际项目中我经常混用：Team 里的每个专家在执行单步任务时，自己又会调用 subagents 去做局部调查。父 Agent 管全局，子 Agent 跑杂活，层级分明。

2.3 三个核心机制的深层含义：并行、角色、共享状态

Agent Teams 之所以能工作，靠的是三个机制的叠加。理解了这三个机制，你配置的时候就不会抓瞎。

首先是并行执行。Team 启动后，多个 Agent 同时开始处理各自的任务，你不必等一个完成再派下一个。但要清楚，这里的“并行”不等于没有约束，它也有资源上限和任务粒度问题。并行度高了之后，输出汇总、代码冲突、token 消耗都会翻倍，这个后面展开讲。

其次是角色定义。每个 Agent 都有角色头（role header），本质上是一段精心写就的任务说明，告诉它“你是谁、项目现在在什么阶段、你的目标是什么、你可以怎么做、做到什么程度算完成”。角色头写得好不好，直接决定协作质量。很多人把角色头写成一句“你是一个后端工程师”，这种等于没写。后面我会给出一套可以直接抄的角色模板。

最后是共享状态。多个 Agent 同时改同一套文件，如果没有状态同步机制，绝对会互相踩脚——你改的接口我还在按老签名调。解决手段是在项目里维护一份共享规范文档（比如 CLAUDE.md 和 docs/api.md），所有 Agent 在动手前先读，改完后再更新。这不是工具强制要求的，而是实践中必须养成的习惯。

3. 动手搭建你的第一个 Agent Team：配置体系与角色设计

3.1 初始化项目与 Agent 配置文件的组织方式

在配置 Agent Teams 之前，先把项目本身梳理干净。我建议按下面的结构初始化一个空仓库，所有文件都是给 Agent 读的“团队宪法”：

my-project/ ├── .claude/ │ └── agents.md # 团队成员与角色头定义 ├── CLAUDE.md # 全局约定：语言、风格、测试命令、共享规范 ├── docs/ │ ├── charter.md # 项目总目标与技术选型 │ ├── api.md # 接口契约，所有 Agent 都必须遵守 │ └── status.md # 当前任务状态与已完成事项 └── src/ # 代码目录

这里的核心是.claude/agents.md。它是 Agent Teams 的“花名册”，每个团队成员的定义都写在这里。注意，不是把角色定义堆在 CLAUDE.md 里就完事，官方机制会读取 agents.md 来识别可用的团队角色。

一个典型的团队定义文件长这样，这是一个真实项目的简化版，你可以直接复制后改名字和职责：

# agents.md - 专家团队花名册 ## arthur **Role**: 技术架构师 **Focus**: 系统设计、技术选型、接口契约 **Preamble**: 你是项目技术架构师。在动手写代码前，先阅读 docs/charter.md 和 docs/api.md。你的职责是给出模块划分、数据模型和接口签名，所有代码实现必须遵循你定义的契约。当后端或前端 Agent 对设计有疑问时，由你拍板。 **Tools**: read, edit, write, bash, glob, grep **Delegation Considerations**: 可委派子任务给 backend_engineer 和 frontend_engineer，负责审核他们的接口一致性。 **Destructive/System**: 默认关闭。 ## backend_engineer **Role**: 后端开发专家 **Focus**: API 实现、数据库访问、业务逻辑 **Preamble**: 你是后端开发专家。遵循 docs/api.md 中定义的接口契约实现服务端代码。每完成一个接口，需要同步更新 docs/status.md 中的契约表。必须为关键路径编写单元测试。 **Tools**: read, edit, write, bash, glob, grep **Delegation Considerations**: 可调用 testing_specialist 验证自己的测试覆盖。 ## testing_specialist **Role**: 测试与质量保障专家 **Focus**: 测试设计、边界条件、回归验证 **Preamble**: 你是测试专家。不直接实现业务功能，只负责审核现有代码的测试覆盖和边界情况。发现缺陷时，记录到 docs/status.md 的缺陷列表，并给出最小复现步骤。 **Tools**: read, edit, write, bash, glob, grep

每个角色块里的## 角色名是 Agent Team 启动时引用成员用的标识，Preamble 是整个角色定义的核心，你在里面写的每句话都会被当成系统级提示词处理。我强烈建议不要偷懒省略 Preamble，写得越具体，协作质量越高。

3.2 角色头的写法：职责、约束、交付物与终止条件

很多人配置 Agent Teams 失败，根源是角色定义写得太抽象。我见过最典型的失败案例是这么写的：

## backend_engineer **Role**: 后端开发 **Preamble**: 你是一个后端工程师，请完成项目中的后端任务。

这种定义跑起来，Agent 会瞬间变成“自由人”——它确实是个后端工程师，但不知道项目处于什么阶段、代码要跟谁对接、做到什么程度算完、什么时候该停手。结果就是它自己发挥，产出经常跟前端 Agent 的实现对不上。

我把实践后总结出的角色头五要素写在这里，你配置时照着填就行：

• 角色身份：一句话说清楚这个 Agent 在团队里的生态位，是架构、后端、前端、测试，还是文档维护。
• 目标导向：说清楚团队当前阶段最需要它贡献什么。比如“当前阶段重点是实现认证模块”，它就不会跑去优化日志格式。
• 约束边界：明确不能做什么。比如测试专家不能直接改业务代码，架构师不能陷入具体实现细节。
• 交付物格式：要求它输出什么（接口定义、测试用例、设计文档），以及写到哪里（docs/status.md）。
• 终止条件：让它明确什么时候算完成。比如“所有接口均有单元测试且通过”比“完成 TODO”要有效得多。

3.3 Convergent 与 Divergent：两种 Agent Teams 模型怎么选

Claude Code 的 Agent Teams 官方支持两种模型，我在项目里两种都跑过，体会很深。

Divergent 模型适合“头脑风暴”或“方案探索”阶段。多个 Agent 从同一个原点出发，各自独立探索不同方向，产出多样化的候选方案。比如你拿不准数据库用 PostgreSQL 还是 SQLite，可以让两个 Agent 分别做评估报告，最后你汇总决策。这种模式的好处是思路开阔，坏处是并行度高了之后方案之间缺乏一致性。

Convergent 模型适合“执行既定方案”。所有 Agent 围绕同一个明确的 plan 工作，各自负责自己的模块，但最终必须汇合到一个可运行的整体。这是我在大多数项目里的首选，也是协作质量最可控的模式。多个 Agent 在同一个代码库里实现不同模块，所有产出最终要合在一起通过集成测试。用一句玩笑话说，Divergent 是“各画各的草图”，Convergent 是“各砌各的墙，但必须拼成同一栋楼。”

配置模型的方式是在初始化 Team 时指定类型。Convergent 模型下，我会特别注意在共享文档里放一个 plan 文件，里面写清模块边界、接口契约和完成定义，确保每个 Agent 都在按同一张图纸施工。

3.4 一组开箱即用的专家角色模板

如果一时不知道怎么设计角色，可以直接从下面这套模板起步。它是我为一个典型 CRUD Web 应用配置的完整团队，你替换掉项目名和具体技术栈就能用。

每个角色的 Preamble 我都建议加入同一句话：“开始任何任务前，先读取 CLAUDE.md、docs/charter.md、docs/status.md，了解项目当前全局状态。”这是避免 Agent 之间上下文割裂的第一步。

4. 一次完整的多 Agent 协作实战：从任务分派到合并交付

4.1 场景设定：一个带认证模块的内容管理后台

理论讲了一堆，落到实操上才有意义。我用一个真实跑过的项目来演示完整流程。项目是一个内容管理后台，需求包括：

• 用户注册、登录、JWT 令牌刷新
• 文章 CRUD 与草稿状态机
• 基于角色的访问控制（管理员 / 编辑 / 访客）
• 前端页面：登录页、文章列表、文章编辑器、用户管理页

技术栈定为 Node.js + Express + SQLite 后端，React + Vite 前端。这个规模对 Agent Teams 来说不算大，但足够展示协作中所有关键机制。

启动前我先写好三份文档。docs/charter.md 定义项目目标和技术选型；docs/api.md 是接口契约；docs/status.md 是任务状态追踪表。当 Agent 问“当前任务是什么”时，它们都会去读 status.md，这是协作能够收敛的关键。

4.2 启动 Team：任务分派与初始状态同步

第一步，创建一个用于团队协作的主会话（controller session），在这个会话里定义 Team 成员及任务。我的初始化命令大致长这样（细节根据你的 Claude Code 版本可能略有差异）：

claude --team arthur backend frontend tester reviewer --project content-admin

启动后，第一步不要急着让它们写代码。先让 arthur（架构师）读书并输出接口契约和数据模型。其他 Agent 此刻处于等待状态。我通常会单独先跑一个 arthur 任务，等 api.md 初稿落盘，再放开其他人。别小看这一步，接口契约是后续所有并行工作的对齐基准，这一步乱了后面全乱。

实操中我用的是 Team 的任务串流机制：controller 可以把单个任务指定给某一个 Agent，也可以让多个 Agent 同时接不同任务。在启动阶段，我只给 arthur 派任务：“请阅读 charter，设计数据模型和全部接口，写入 docs/api.md”。其他 Agent 等待。

等 api.md 写完后，我再给 backend 和 frontend 同时派活：“按 api.md 实现用户认证模块（backend）”“按 api.md 实现登录页与注册页（frontend）”。由于两个人读的是同一份接口契约，后端定义的POST /api/auth/login返回体 frontend 可以直接对照着写。

4.3 并行开发中的状态同步与互相审阅

并行开发真正跑起来之后，观察 Agent 之间如何协作是很有意思的事。backend Agent 在实现文章状态机时，发现需要在articles表加一个status字段，它会先去改 docs/api.md 里的数据模型部分，然后更新 docs/status.md 的字段说明。frontend Agent 在读 status.md 时发现接口返回体加了新字段，会在编辑器里自动适配，不需要我在中间传话。

这就是共享状态文档的实际作用。没有这套机制，两个 Agent 同时改代码，大概率会出现“frontend 写好了对老接口的调用，backend 已经换了新签名”这种经典错误。

并行阶段我会做一件很重要的事情：定时让 tester Agent 去“打扰”正在开发的 backend Agent。测试专家会读取 backend 刚刚写完的代码，检查边界条件，然后输出一份缺陷报告到 docs/status.md 的缺陷列表。backend 看到缺陷列表更新后，会决定是否需要立即修复。这套“开发 — 测试 — 反馈 — 修复”的循环不需要我干预，两个 Agent 自己就跑起来了。

4.4 合并交付：代码审查、集成测试与质量门禁

所有模块开发完成后，进入合并交付阶段。这时候 controller session 的角色是“技术经理”，它的职责不是亲自写代码，而是调度和验收。

我先让 reviewer Agent 对全部增量代码做一次全面审查，重点看认证流程是否有安全漏洞、数据库访问是否有注入风险、前端的 API 调用层是否跟契约完全一致。reviewer 的输出是一份带严重度分级的评审报告，写进 docs/status.md。

然后我要求 backend 和 frontend 根据评审报告各自认领问题。做法是在 controller 里直接派任务：“请根据 reviewer 的评审报告，修复你们模块下的 todo”。

修复完成后，由 tester 执行集成测试。这里有一个我之前踩过的坑：tester Agent 默认只做静态分析和测试用例设计，它不一定真的会去运行自动化测试脚本。所以我在 tester 的角色定义里明确写了“可以执行项目中的 npm test 命令，并把测试输出记录到 status.md”。加上这一句之后，tester 才开始真正跑测试并把失败堆栈贴进共享文档。

整个流程走完的标志是：集成测试全部通过，缺陷列表清零，api.md 与代码实现完全一致。此时 controller session 会生成一份最终交付总结，包括每个 Agent 完成了什么、还剩什么遗留项。我建议留下这份总结，它就是你项目迭代下一个版本时的起点。

5. 状态管理与文件冲突：多个 Agent 不互相踩脚的五个手段

5.1 并发写冲突的根因：为什么 Agent 之间会“打架”

Agent Teams 跑起来之后最让人头疼的问题就是文件冲突。两个 Agent 同时往同一个文件里写内容，后写的人覆盖先写的人；或者一个 Agent 正读着一个旧的接口定义，另一个已经把定义改了。

根因很简单：Agent 各自持有独立的上下文会话，不会实时感知其他 Agent 的文件修改。你以为它们在“协作”，实际上它们更像是“在同一个仓库里的不同分支上干活，但没有 git 自动合并”。

我对策的核心是：把并发写冲突的概率在设计上降到最低，而不是等冲突发生后再救火。下面是我实际用下来最有效的五个手段，按优先级排序。

5.2 手段一：文件级别所有权，谁的文件谁写

在共享规范里明确每个模块的目录归属。我写的 CLAUDE.md 里会有一张所有权表，比如：

src/server/ → backend 专属 src/client/ → frontend 专属 docs/api.md → arthur 专属（其他人只读） docs/status.md → 所有 Agent 可写，但只追加不覆盖 scripts/ → backend 专属

每个 Agent 开工前先读这张表，“不属于我的目录我不碰”。这个约束看起来简单，但能避免 80% 的写冲突。我见过最惨的一次事故就是 backend 觉得某个 schema 定义不合理，顺手改了前端依赖的一份类型声明文件，导致前端构建直接崩了。

5.3 手段二：共享文档只追加不覆盖

多人协作项目最怕的就是有人默默改掉别人的记录。所以 docs/status.md 这份共享状态文件，我明确要求所有 Agent“只追加、不覆盖”。要标记一个任务完成，不是回头改那一行的状态，而是在文件底部追加一条“完成记录”。

这样做的原因是：Agent 修改旧内容时，它必须先读取整个文件再重写，但它的视角里可能没有包含另一个 Agent 刚追加的条目，结果把别人的更新一并覆盖掉。只追加模式杜绝了这个风险，缺点只是文件会变长，但在一个中型项目里完全可接受。

5.4 手段三：状态快照机制

在并行开发开始前，我要求 arthur 先生成一份项目状态快照文档，包含当前所有文件的清单和每个文件的“负责人”。Controller 会把这份快照作为 Team 启动时的初始上下文分发给所有 Agent。这样每个 Agent 在开工那一刻，对项目结构拥有一致的初始理解。

快照文件不追求完整，只记录关键模块和接口。目的是让 Agent 对“仓库里大概有什么、哪些东西归谁管”有共识，而不是各自从零摸索。

5.5 手段四：强制先读再写

我在每个角色的 Preamble 里都写了一句硬性规定：任何文件修改前，必须先读取目标文件当前内容；任何接口调用前，必须先查 docs/api.md 的最新定义。

听起来像是废话，但这是最容易被忽略的。Agent 有时会凭着上下文中的旧记忆直接动手编码，不去刷新目标文件。加了这个约束后，它能显著减少那些“拿旧方案写新代码”的低级错误。

5.6 手段五：定期存档与冲突仲裁

即使做了以上四点，冲突依然有可能发生。我的最后一道防线是在 Controller 里定期执行“save and update”——让每个 Agent 把最近的产出提交到最新的状态文档，并把冲突项列出来。Controller 负责仲裁：同一文件被两个 Agent 修改时，以先落盘者为准，后写者重做。

在并行任务推进会卡住的时候，我也会主动介入，指名道姓地让某个 Agent 停手，先把冲突区域让给另一个 Agent。Agent Teams 虽然自动化程度高，但不等于不需要人来当仲裁者。最高效的协作方式永远是“人定方向，Agent 执行细节”。

6. 常见问题与排查技巧实录

6.1 高频故障速查表

这一节是我实战经验的汇总，出现的频率从高到低排列，每一项都是我真实遇到过的。

6.2 三个高价值的独门技巧

第一个技巧是“专门养一个文档维护 Agent”。大多数团队配置里没有这个角色，但我强烈建议加一个 doc_writer，它的唯一职责是维护 docs/ 下的状态文档，整理 API 变更记录和决策记录。有了它，其他 Agent 不用频繁打断自己的工作去更新共享文档，协作效率提升非常明显。

第二个技巧是“阶段性并行，不做全量并行”。很多人刚接触 Agent Teams 时容易兴奋，一次性让 5 个 Agent 同时跑所有模块。结果并不是更快，而是文档和状态同步先崩了。我现在的做法是：先让 arthur 设计契约，再让 backend 和 frontend 并行实现，同时让 tester 做静态审查，最后并行 reviewer。每阶段并行度控制在 2-3 个 Agent 内，节奏更可控。

第三个技巧是“关键决策人工锁”。涉及数据模型变更、接口签名修改、第三方依赖选型这类决策，我会要求 Agent 不能自行修改 docs/api.md，只能提交“变更提案”，等我在 Controller 中审核并批准后才生效。代价是稍微牺牲一点自动化程度，但换来的是一致性和稳定性，尤其是项目接近交付时这个技巧非常救命。

6.3 成本与资源控制：多 Agent 不等于多白嫖

有一个现实问题必须坦诚：Agent Teams 会显著提高 token 消耗。每个 Agent 有独立的上下文窗口，再加上 Controller 把任务分发给所有成员、成员产出再汇总回来，token 开销是单 Agent 的数倍。

我实测一个中型迭代（约 8 个功能点、30 个文件变动），单 Agent 大概消耗 1.5M token；用 Agent Teams 跑同样的范围，总消耗在 4M token 左右。多出来的部分大部分消耗在上下文传播、状态文档读取汇总、Agent 之间重复阅读共享文件上。这不是说 Agent Teams 不值得用——对于复杂项目，多花的 token 换来的是整体交付速度提升和更高质量，但你要心里有数。

省流的经验是控制并行度、减少不必要的全局文档重读、让 doc_writer 维护精简版 status 而不是让每个 Agent 每次都读全量文档。另外，如果项目里有敏感信息，需要谨慎考虑授予 Agent 的权限范围，尤其是涉及密钥、内网地址和用户数据的模块，我建议在 agents.md 的 Destructive 级别照实限制。

7. 账号与订阅层面的几个坑

这个部分专门说说我在使用过程中遇到的环境问题，虽然不涉及 Agent Teams 本身的功能，但它们是“能不能用起来”的前置条件。

首先，Claude Code 本体需要正常运行。如果是企业或组织环境统一配置的账号，个别情况下会出现订阅被组织策略限制的情况——具体表现为启动 Claude Code 时提示当前账号没有可用权限。我在给团队推广时遇到过这种问题，处理方式是走组织的正当审批流程，或者使用个人授权账号。这里不展开细节，但如果你碰上了，先不要怀疑工具坏了，优先确认账号授权是否完整。

其次，Agent Teams 对模型版本有隐性要求。早期版本只支持特定模型系列，你在配置时如果发现 Team 相关命令不可用，可以先更新 Claude Code 到最新版本，再检查当前模型是否支持多会话并行。我自己就有一次在旧版本上反复折腾配置，最后发现只是版本不支持，特别浪费时间。

最后提醒一点：在本地开发环境使用 Agent Teams 时，工具需要访问文件系统、可能要执行 bash 命令跑测试路径。如果项目是 Ubuntu 上配置的，记得确认一下目录权限和网络策略；若你想接入本地模型（比如调用 LM Studio 之类），那属于本地推理方案，与 Agent Teams 的多会话机制是两套体系，可以并行使用但配置路径不同，建议分开搭建。

8. 我现在实际用下来的体会与一点扩展想法

文章写到这，Agent Teams 的完整工作流已经铺开了，但我不太想用一句“总之它很强大”来收尾，还是聊聊真实体感和边界条件吧。

我最大的体会是：Agent Teams 不是为了取代人，而是为了把人在项目里做的“调度、对齐、评审”这类管理工作自动化。它最适合的场景是“需求已经明确、技术方案已经定好、需要多人执行和监督”的项目阶段。反过来，如果需求还在飘忽不定阶段，或者连你自己都不知道想要的方案是什么，那先别开 Team——就算开，也是 Divergent 模式用来头脑风暴，而不是 Convergent 模式做执行。

我也要诚实地说，Agent Teams 对项目结构化程度的要求比我最初预想的要高。在规范清晰的仓库里，它跑起来像一个训练有素的外包团队；在代码没有分层、没有约定、没有文档的“屎山”里，它也救不了什么——因为多个 Agent 只会更快地把混乱复制到更多文件里。所以如果你准备在现有的大型项目上使用 Agent Teams，建议先花一个下午把 CLAUDE.md 和模块所有权表补齐再启动，这笔投入回报极高。

最后分享一个我正在扩展的方向：把 documents/charter、计划文件和 ADR（架构决策记录）接入 Agent 的工作流，让每次并行迭代都自动生成下一轮任务的输入基线。这样 Team 不只是执行工具，还兼做项目记忆库。实际效果是，项目做三个月之后，新加入的 Agent 角色只需要读一轮 docs 就能无缝上手，比人类新成员适应项目还快。

Agent Teams 是一个值得长期投入的功能方向。如果你刚开始接触，可以先拿一个小项目练手，两个 Agenter 配一个 Controller 跑一遍全流程，比你读十篇文章管用得多。跑通了之后，你会开始理解那些“自动化项目协作”的产品设计逻辑——本质上不是把 AI 当单兵武器，而是把它当成一支可以由你调度的军团。