Claude Agent Teams：从"一个能写代码的AI"到"能组队交付的AI"
一个 Claude 会话能做的事情，我大概已经摸清了边界。写个函数、改个 bug、生成一段 boilerplate 代码。上限很明确：一个人干一件事。
但如果任务是"搭一个全栈应用"呢？一个 Agent 要同时理解数据库设计、API 开发、前端组件、测试用例，上下文窗口撑不住，注意力也撑不住。
Claude Agent Teams 解决的就是这个问题。让多个 Claude 会话各干各的，像一个团队一样协作。
01 单 Agent 和多 Agent 的真实差距
单 Agent 的工作方式像一个全栈独立开发者：什么都得管，什么都得记。做前端的时候脑子里还得装着后端的 schema，写测试的时候还得记着 API 的返回格式。上下文越来越长，模型的注意力越来越散。
多 Agent 的逻辑完全不同。每个 Agent 只看自己该看的东西，只用自己该用的工具。一个 Agent 在写数据库迁移脚本的同时，另一个 Agent 在搭前端组件。它们并行执行，互不干扰。
Anthropic 的官方文档把多 Agent 的适用场景归结为三类：
上下文保护。当不同子任务之间的信息互相干扰时，把它们隔开。负责安全审计的 Agent 不需要看 UI 组件的代码，负责写 CSS 的 Agent 也不需要知道数据库密码怎么加密。隔离不是限制，是让每个 Agent 的上下文窗口更干净。
并行执行。多个任务同时跑，省时间。原来一个 Agent 按顺序做五件事要一小时，五个 Agent 并行可能十五分钟就结束了。
专精化。当一个 Agent 面前摆着二十个工具的时候，它选错工具的概率会上升。把工具集拆小，每个 Agent 只配三四个相关工具，准确率明显提高。
02 Claude Code 里的 Agent Teams 长什么样
Claude Code 现在支持编排多个独立的 Claude 会话，让它们作为一个协调的团队工作。具体机制包括四个部分。
并行工作：多个 Agent 同时在不同的任务上推进，不需要等前一个做完才开始下一个。
共享任务列表：所有 Agent 能看到同一份任务清单，知道哪些已经完成、哪些还在进行中、哪些被阻塞了。
消息传递：Agent 之间可以互相发消息。前端 Agent 发现 API 接口定义有歧义，可以直接问后端 Agent，不需要人类在中间转达。
Lead Agent 协调：一个 Agent 充当"项目经理"的角色，分配任务、检查进度、处理冲突。其他 Agent 向它汇报。
这套架构的设计意图很明确：复制人类开发团队的工作模式。有人领导，有人执行，有人审查，分工明确，并行推进。
03 绕不开的成本问题
多 Agent 听起来很美好，但 token 消耗是绕不过去的坎。
Anthropic 自己在 multi-agent systems 的技术文档里提到：多 Agent 系统通常消耗 3 到 10 倍的 token。这不是效率低，是结构性的开销。每个 Agent 都需要自己的上下文，协调信息在 Agent 之间传递会被重复编码，Lead Agent 要读取所有 Agent 的状态汇报。
一个单 Agent 任务花 1 万 token，换成 5 个 Agent 协作可能花 5 万到 10 万 token。如果你用的是 Opus 4.6，输入 $5/百万 token，输出 $25/百万 token，一个中等规模的协作任务跑下来几美元到几十美元很正常。
所以不是所有任务都该用多 Agent。一个简单的 CRUD 功能，单 Agent 十分钟搞定的事，没必要拉一个五人团队来做。多 Agent 的价值在大规模、多模块、有并行空间的项目里才能体现。
04 Boris Cherny 怎么用的
Boris Cherny 是比较早公开分享多 Agent 实战经验的开发者。他的日常工作流是同时运行 5 到 15 个 Claude Agent。
不是在一个窗口里。是分散在多个终端标签页和浏览器会话里。每个 Agent 负责一个独立的子任务，他在中间来回切换，检查进度，给反馈。
这种工作方式对人的注意力管理要求很高。他用 iTerm2 的通知功能来追踪哪个 Agent 完成了任务、哪个 Agent 卡住了需要人工干预。某种程度上，他自己就是那个 Lead Agent，负责分配、协调、做最终决策。
他的经验是：Agent 数量超过 10 个之后，协调成本会急剧上升。不是 token 成本，是人的认知负荷。你要记住每个 Agent 在做什么，判断它们的输出是否正确，处理它们之间的依赖关系。跑 15 个 Agent 和管理一个 15 人的远程团队，操心的事差不多。
05 CLAUDE.md 的隐藏作用
多个 Agent 在同一个代码仓库里工作，怎么保证它们遵循相同的规范？
答案是 CLAUDE.md。这个文件放在仓库根目录，所有 Claude Code 会话启动时都会读取它。它充当仓库级的指令集，告诉每个 Agent：项目用什么技术栈、代码风格是什么、提交信息怎么写、哪些文件不能碰。
在单 Agent 场景下，CLAUDE.md 只是个方便的配置文件。在多 Agent 场景下，它变成了团队的行为准则。没有这个文件，5 个 Agent 可能用 5 种不同的命名规范写代码，合并的时候一团糟。
有些团队会在 CLAUDE.md 里写得很细：禁止直接操作生产数据库、所有 API 变更必须向后兼容、测试覆盖率不能低于 80%。这些规则对人类开发者适用，对 Agent 同样适用。
我觉得这可能是 Agent Teams 里最被低估的组件。技术架构再精巧，如果 Agent 们不遵守同一套规矩，最终产出的代码质量不可能高。协调 Agent 的行为比启动 Agent 的会话难得多。
参考链接： https://code.claude.com/docs/en/agent-teams https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them https://vatchechamlian.com/orchestrating-agents-claude.html