Claude Code Agent Teams：3个AI同时写代码，底层原理和主流框架对比

大家好，我是易安，AI超级个体，大厂程序员二孩奶爸。 Claude Opus 4.6 带来了 Agent Teams 功能，可以让多个 Claude Code 实例并行工作。我用它做了个小项目，踩了一些坑，也顺便把底层原理和市面上几个主流多 Agent 框架做了个对比。这篇文章干货比较多，建议收藏。

Agent Teams 到底是什么

简单说就是一个 Lead Agent 可以 spawn 出多个 Teammate Agent，每个 Teammate 是一个完全独立的 Claude Code 会话实例，有自己的 200K 上下文窗口，并行处理不同的任务。完成后 Lead Agent 负责集成。

不需要特殊的 CLI 命令，用自然语言告诉 Lead Agent 怎么分工就行。

但这里有个关键点很多教程没讲清楚——Agent Teams 和之前的 Subagents 是两码事：

Subagents 更像是"我派你去查个资料回来告诉我"，Agent Teams 则是"我们组个团队一起干"。

底层原理：Agent Teams 是怎么工作的

这部分我觉得是理解 Agent Teams 的关键。搞清楚原理，才能知道什么时候该用、怎么用才高效。

TeammateTool：13 个核心操作

Agent Teams 的底层是一套叫 TeammateTool 的系统，2026 年 1 月社区开发者 kieranklaassen 在 Claude Code 二进制文件上跑 strings 命令时发现了它——当时功能还被两个门控函数隐藏着。11 天后 Anthropic 就正式发布了。

这套系统包含 13 个操作，分三类，同时配合本地文件系统做状态管理：

没有专有云数据库，没有复杂的消息队列。就是 JSON 文件 + 文件锁。并发安全靠原子写入（tempfile + os.replace）和跨平台文件锁。

这意味着你可以直接 cat ~/.claude/tasks/my-team/1.json 看任务状态，甚至手动改它。跟 git 一样，对开发者很友好。

任务依赖：DAG 图

任务之间支持依赖关系，形成有向无环图（DAG）。队友完成任务后，依赖它的任务会自动解除阻塞：

通信机制：邮箱系统

每个队友有个 JSON 格式的收件箱。关键设计——Claude 的文本输出对团队不可见，必须用 write 操作才能让其他队友看到消息。

这很重要：如果 API 队友完成了类型定义，它可以直接通知 UI 队友开工，不需要经过 Lead 中转。测试队友也可以直接请求 API 队友启动开发服务器。这比纯层级汇报灵活很多。

Spawn 后端：三种运行模式

系统会自动检测环境选择后端，tmux 是最稳的选择：

Delegate 模式

按 Shift+Tab 可以把 Lead 切换到 delegate 模式。这个模式下 Lead 只能做协调——生成队友、发消息、管理任务，不能直接改代码。

为什么需要这个？因为 Lead 有时候会"手痒"，明明该分配给队友的任务自己偷偷实现了。delegate 模式是个强制约束。

开启方式

在 ~/.claude/settings.json 里加两个配置：

1{
2  "env": {
3    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
4  },
5  "experimental": {
6    "agentTeams": true
7  }
8}
9

推荐在 tmux 里启动，可以看到分屏效果：

1tmux new -s my-team
2claude
3

实战：3个Agent并行写一个记账工具

我选了一个 Python CLI 记账工具作为测试项目，功能不复杂但可以拆成清晰的并行任务：

每个 Agent 拿到的 prompt 里详细描述了要创建的文件、类名、方法签名、参数类型。三个任务同时发出去，并行执行。

结果

三个 Agent 全部完成，总共生成 7 个文件、21 个测试用例。速度确实快——三个 Agent 最慢的那个大概用了不到 3 分钟，如果串行做至少要 6-7 分钟。

跑测试的时候问题来了：8 个模型测试全过，13 个存储测试全挂。

踩坑：接口契约不一致

这是多 Agent 并行开发最典型的问题——每个 Agent 独立工作，对同一个接口的理解不完全一致。

三个 Agent 之间出现了 3 类冲突：参数名不同、类型不匹配、返回值 key 名对不上。

修复过程

修复分两步：

第一步改测试文件 test_storage.py，对齐实际的 storage.py 接口：

data_dir= 改成 data_path=Path(...) / "data.json"
Category 枚举传 .value 转字符串
date 对象用 str() 转字符串
this_month 改成 monthly_total

第二步改 cli.py，对齐 models.py 的类型要求：

args.category 改成 args.category.value
date 对象用 str() 转换
summary 里的 key 名对齐
delete 命令的 ID 类型从 int 改成 str（因为实际用的是 UUID）

改完之后 21 个测试全部通过，CLI 也能正常跑了：

1✓ 已添加支出: ¥35.50 [FOOD]
2✓ 已添加支出: ¥100.00 [TRANSPORT]
3✓ 已添加支出: ¥299.00 [SHOPPING]
4
5共 3 条记录，合计: ¥434.50
6

框架对比：Agent Teams vs Oh-My-OpenCode vs BMAD-METHOD

市面上做多 Agent 编排的框架不少，我重点对比了三个有代表性的：

Oh-My-OpenCode：希腊神话式的多模型编排

Oh-My-OpenCode 是给 OpenCode（开源终端 AI 工具）做的插件，GitHub 上有 24000+ Star。它的设计挺有意思——用希腊神话人物命名 11 个 Agent 角色：

Sisyphus（西西弗斯）：主编排器。名字来自不断推石头上山的神话，意思是你的任务一定会被完成
Prometheus（普罗米修斯）：规划师，不是简单拆任务，而是通过"采访"帮你厘清需求
Hephaestus（赫菲斯托斯）：自主深度工作者，在写一行代码之前会先并行启动 2-5 个侦察 Agent 做情报收集
Oracle：战略顾问，只读不写

核心设计是多模型混合——Opus 做决策、GPT 做执行、Grok 做搜索、Gemini 做多模态分析。用便宜模型做侦察，贵模型做决策，成本控制比较灵活。

但有个现实问题：2026 年 1 月 Anthropic 限制了第三方 OAuth 访问，明确提到 Oh-My-OpenCode 是封锁原因之一。它之前允许用 Claude Pro/Max 订阅驱动 OpenCode，被认定违反了服务条款。

BMAD-METHOD：文档驱动的敏捷团队

BMAD（Breakthrough Method for Agile AI-Driven Development）走了一条完全不同的路——不追求并行速度，追求流程可控。

它的核心理念是把 AI 组织成一支完整的敏捷团队：分析师、产品经理、架构师、Scrum Master、开发者、QA。每个角色的定义是版本化的 Markdown/YAML 文件，可以 Git 管理。

开发分两个阶段：

第一阶段：规划。Analyst 做调研 → PM 写 PRD → Architect 定架构 → Product Owner 对齐验证 → Scrum Master 生成开发故事。整个过程产出的文档就是持久化的上下文。

第二阶段：执行。开发者 Agent 打开一个故事文件，里面有完整的实现细节、架构指导、设计原理、测试标准。不需要额外沟通，文档即上下文。

BMAD 还有个"文档分片"的概念——把复杂的项目文档拆成原子化的、AI 可消化的片段。这解决了大项目上下文塞不进去的问题。

它是工具无关的，支持 Claude Code、Cursor、Windsurf、GitHub Copilot 等多种 AI IDE。

三个框架的核心差异

怎么选？

Agent Teams 适合：已经在用 Claude Code，项目可以清晰拆分并行任务，接口契约比较明确。胜在零配置、原生体验好。

Oh-My-OpenCode 适合：想混用多个模型控制成本，项目需要复杂的规划-执行分离。但要注意 OAuth 合规问题。

BMAD-METHOD 适合：大型复杂项目，需要完整的文档链路和角色分工。可以和 Agent Teams 互补——用 BMAD 做规划阶段，用 Agent Teams 做并行执行阶段。

其实这三个方案不互斥。BMAD 可以运行在 Claude Code 之上，Oh-My-OpenCode 的设计理念（多模型混用、层级化 Agent）对 prompt 设计也有参考价值。

经验总结

Agent Teams 的优势：

并行确实快，三个 Agent 同时干活，总耗时约等于最慢的那个
队友间可以直接通信，比纯层级汇报灵活
适合拆分清晰的项目：前端/后端/测试、不同模块、不同微服务

Agent Teams 的坑：

接口契约是最大的问题。每个 Agent 独立理解需求，即使 prompt 写得很详细，参数名、类型、返回值格式都可能对不上
Token 消耗大。3 个 Agent 的 token 消耗大概是单个的 4-5 倍（Anthropic 研究员 Nicholas Carlini 用 16 个 Agent 写 C 编译器花了 $20,000）
Lead Agent 的集成工作不可省略。并行开发完一定需要一个"粘合"阶段
/resume 暂时不能恢复 teammate 会话

建议：

prompt 中尽量用代码片段定义接口，不要只用自然语言描述。直接写 class ExpenseStorage(data_path: Optional[Path] = None)，而不是"构造函数接受可选的目录参数"
Lead 用 Opus 做战略决策，队友用 Sonnet 执行具体任务，可以省一些 token
先用 Plan 模式制定计划（便宜），确认后再交给团队并行执行（贵但快）
用 delegate 模式约束 Lead，防止它越权自己写代码
对于小项目（< 500 行），单 Agent 可能更高效，因为省去了集成成本
Agent Teams 更适合中大型项目，各模块之间接口已经明确定义的场景
官方建议 2-5 个队友、每个队友 5-6 个任务。别贪多，协调开销会吃掉并行收益

多 Agent 协作是 AI 辅助开发的下一步，不管用哪个框架，核心问题都是一样的：怎么把"接口契约"定义清楚，怎么在并行效率和协调成本之间找到平衡。跟人类团队协作其实是一个道理——分工越清晰，扯皮越少。

《Claude Code Agent Teams：3个AI同时写代码，底层原理和主流框架对比》是转载文章，点击查看原文。