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 应用配置的完整团队你替换掉项目名和具体技术栈就能用。角色名职责关键约束arthur技术架构数据模型与接口契约不写具体业务代码只维护 docs/api.mdbackend后端实现业务逻辑、数据库读写必须遵循 api.md 的签名完成后更新 status.mdfrontend前端实现页面交互、API 调用层调用接口必须与 api.md 保持一致tester测试设计、缺陷记录、回归验证不直接改业务代码只提交缺陷报告reviewer代码审核、安全隐患、性能瓶颈只读文件并输出评审意见不做修改每个角色的 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 高频故障速查表这一节是我实战经验的汇总出现的频率从高到低排列每一项都是我真实遇到过的。问题现象根因排查与修复Agent 总是忘记读接口文档直接按旧签名写代码角色 Preamble 中没有强制“先读文档”在 agents.md 每段 Preamble 顶端加入先读 docs/api.md 的指令两个 Agent 同时改同一个文件导致一方白干缺少文件所有权表在 CLAUDE.md 建立目录归属表要求跨域修改必须先经 Controller 同意测试 Agent 只“看”代码从不真正运行测试角色定义没赋予运行命令的权限在 Preamble 中写明“可执行 npm test、pytest 等命令必须输出真实日志”Agent 在任务完成后不明确返回一直游离缺少终止条件描述为每个角色补充“完成定义”哪些文件更新、哪些测试通过、报告写到哪并行任务过多Controller 输出混乱一次性派发太多任务且无优先级分批派发任务第一批只派 2-3 个等文档和状态更新后再派下一批Agent 反复建议方案却不落地角色定位偏向“顾问”而不是“执行者”Preamble 中明确“直接修改代码而不是提交建议”除非是 reviewer 角色集成测试通过但代码库风格混乱缺少全局风格规范CLAUDE.md 中添加命名规范、组件写法、导入顺序等约定上下文还是不够用Agent 表现越来越差任务粒度太大拆分任务让每个 Agent 专注小模块而非整个子系统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 当单兵武器而是把它当成一支可以由你调度的军团。