“I did not expect this to be anywhere near possible so early in 2026.”

—— Nicholas Carlini, Anthropic 安全研究员

16 个 Claude 实例，两周时间，10 万行 Rust 代码，一个能编译 Linux 6.9 内核的 C 编译器。

API 费用：不到 2 万美元。

这不是科幻小说。这是 2026 年 2 月 5 日，Anthropic 发布 Claude Opus 4.6 当天，官方博客上的一篇工程实验报告。

而这篇报告背后的技术，叫做 Agent Teams。

00 先搞清楚：这不是"升级版的 Subagent"

在深入之前，先纠正一个常见误解。

很多人第一反应是：“Agent Teams 不就是 Subagent 的多实例版本吗？”

不是。 差别比你想象的大。

一句话概括：Subagent 是"派任务的下属"，Agent Teams 是"能互相讨论的团队"。

Subagent 完成任务后把结果交回去，它不知道其他 Subagent 在干什么。而 Agent Teams 中的每个 Teammate 不仅能看到共享任务列表，还能直接给其他 Teammate 发消息，挑战彼此的方案，甚至辩论出最优解。

这是质的飞跃，不是量的变化。

01 Opus 4.6：Agent Teams 的"硬件基础"

Agent Teams 不是凭空出现的。它之所以在 Opus 4.6 上首发，是因为需要底层模型能力的匹配。

1M Token 上下文窗口

这是第一个支持 100 万 token 上下文的 Opus 级模型。在 MRCR v2 测试（8 针 100 万变体）中，Opus 4.6 得分 76%，而 Sonnet 4.5 只有 18.5%。

对 Agent Teams 的意义：每个 Teammate 都是一个独立的 Claude Code 会话。100 万 token 意味着每个 Teammate 可以吞入足够多的代码上下文来独立工作，不需要频繁"遗忘"。

自适应思考（Adaptive Thinking）

以前开发者对扩展思考只有"开/关"两个选项。现在 Opus 4.6 引入了四档调节：low / medium / high / max。

模型能自主判断何时需要深度推理。简单任务自动跳过深度思考（省 token），复杂任务自动加深推理链。

对 Agent Teams 的意义：16 个 Agent 并行运行，token 消耗量惊人。自适应思考让每个 Agent 在简单合并操作上"快速通过"，在复杂架构决策上"深思熟虑"——自动调节，无需人工干预。

Terminal-Bench 2.0 领先

这是衡量 AI 代理在真实终端环境中完成任务能力的基准测试。Opus 4.6 拿下最高分。

对 Agent Teams 的意义：Agent Teams 中的每个 Teammate 本质上是一个独立的 Claude Code 终端会话。终端能力的提升直接决定了每个 Teammate 的"战斗力"。

上下文压缩（Context Compaction）

当对话接近上下文窗口阈值时，模型能自动压缩旧上下文。这让长时间运行的 Agent 任务变得可行。

对 Agent Teams 的意义：编译器实验中产生了近 2000 个 Claude Code 会话。没有上下文压缩，Agent 会在长时间任务中"越跑越傻"。

02 Agent Teams 架构：四个核心组件

Agent Teams 的架构出奇地简洁：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

┌─────────────────────────────────────────────┐
│                  Team Lead                   │
│          (你的主 Claude Code 会话)           │
├─────────────────────────────────────────────┤
│                                             │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐   │
│  │Teammate A│ │Teammate B│ │Teammate C│   │
│  │ 安全审计  │ │ 性能优化  │ │ 测试覆盖  │   │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘   │
│       │            │            │           │
│  ┌────┴────────────┴────────────┴────┐     │
│  │        Shared Task List           │     │
│  │   (共享任务列表 + 消息信箱)       │     │
│  └───────────────────────────────────┘     │
└─────────────────────────────────────────────┘

组件一：Team Lead（团队领导）

你的主 Claude Code 会话。负责：

• 创建团队、生成 Teammate
• 分配任务或让 Teammate 自主认领
• 综合各 Teammate 的发现和成果

关键细节：Lead 是固定的，不能转让领导权。一个 Lead 同时只能管理一个 Team。

组件二：Teammates（队友）

每个 Teammate 是一个完全独立的 Claude Code 实例。它们：

• 拥有独立的上下文窗口
• 自动加载项目的 CLAUDE.md、MCP 服务器和 Skills
• 不继承 Lead 的对话历史（只接收 spawn 时的提示词）

组件三：Shared Task List（共享任务列表）

这是协调的核心。所有 Agent 都能看到任务状态，Teammate 可以自主认领未被锁定的任务。

任务有三种状态：pending → in_progress → completed

支持任务依赖：一个 pending 任务如果依赖未完成的任务，不能被认领。

防冲突机制：任务认领使用文件锁。如果两个 Teammate 同时抢同一个任务，只有一个能成功。

组件四：Mailbox（消息信箱）

Teammate 之间直接通信的渠道：

• message：点对点消息，发给特定 Teammate
• broadcast：广播消息，发给所有 Teammate（慎用，token 消耗随团队规模线性增长）

消息自动送达，Lead 不需要轮询。Teammate 完成任务或空闲时，也会自动通知 Lead。

03 十分钟上手：启动你的第一个 Agent Team

Step 1：开启实验特性

Agent Teams 目前是实验功能，默认关闭。在 settings.json 中添加：

1
2
3
4
5

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

或者直接设置环境变量：

1

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

Step 2：用自然语言描述你的团队

不需要写配置文件。直接在 Claude Code 中说：

1
2
3
4
5

创建一个 Agent Team 来审查 PR #142：
- 一个 Teammate 专注安全审计
- 一个 Teammate 检查性能影响
- 一个 Teammate 验证测试覆盖率
让他们各自审查后汇报发现。

Claude 会自动创建团队、生成 Teammate、分配任务。

Step 3：选择显示模式

两种模式：

在 settings.json 中配置：

1
2
3

{
  "teammateMode": "in-process"
}

或者用命令行参数：

1

claude --teammate-mode in-process

Step 4：与 Teammate 直接对话

这是 Agent Teams 最灵活的地方——你可以绕过 Lead，直接跟任何 Teammate 对话。

在 In-process 模式下：

• Shift+Up/Down：选择 Teammate
• Enter：查看某个 Teammate 的会话
• Escape：打断当前回合
• Ctrl+T：切换任务列表视图

Step 5：清理

用完后让 Lead 清理：

1

清理团队

⚠️ 注意：先让所有 Teammate 关闭，再让 Lead 清理。不要让 Teammate 执行清理操作。

04 深度复盘：16 个 Agent 如何写出 C 编译器

这是目前 Agent Teams 最震撼的实战案例。让我们拆解 Nicholas Carlini 的每一步操作。

环境设计：Docker + 共享 Git 仓库

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

┌──────────────────────────────────────────┐
│              Bare Git Repo               │
│           (/upstream)                    │
├──────────────────────────────────────────┤
│                                          │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐ │
│  │Docker #1│  │Docker #2│  │...      │ │
│  │/workspace│ │/workspace│ │Docker #16│ │
│  │ clone ←→ │ │ clone ←→ │ │ clone ←→ │ │
│  │ upstream │ │ upstream │ │ upstream │ │
│  └─────────┘  └─────────┘  └─────────┘ │
└──────────────────────────────────────────┘

每个 Agent 运行在独立 Docker 容器中：

• 挂载共享的 bare git 仓库到 /upstream
• 克隆到本地 /workspace 工作
• 完成后推送回 upstream

通信机制极其简单：唯一的通信渠道就是共享的 git 仓库。没有编排 Agent，没有 Agent 间直接消息传递。

任务协调：文件锁 + 自组织

Agent 通过向 current_tasks/ 目录写入文本文件来"锁定"任务：

1
2
3
4

current_tasks/
├── parse_if_statement.txt        ← Agent #3 正在处理
├── codegen_function_definition.txt ← Agent #7 正在处理
└── optimize_register_allocation.txt ← Agent #12 正在处理

如果两个 Agent 同时尝试认领同一任务，git 的同步机制会迫使第二个 Agent 选择其他任务。

没有"指挥官"。每个 Agent 自行决定做什么，通常选择"下一个最明显的问题"。

六种专业化角色

Agent 自发分化出了不同角色：

注意：这些角色不是预设的。它们是 Agent 在工作过程中自发形成的分工。

成果数据

能编译的项目：Linux 6.9 内核（x86/ARM/RISC-V）、QEMU、FFmpeg、SQLite、PostgreSQL、Redis、Doom。

五大关键挑战（以及解决方案）

挑战一：回归地狱

问题：新功能频繁破坏已有功能。Agent 修了一个 bug，引入了三个新 bug。

解决方案：构建严格的 CI 流水线，每次提交必须通过全量回归测试。

挑战二：上下文窗口被"垃圾"占满

问题：测试输出可能有几万行，直接塞满 Agent 的上下文窗口。

解决方案：

• 测试只打印几行摘要，详细信息写入日志文件
• 错误行以 ERROR 开头并在同一行包含原因（方便 grep）
• 预计算汇总统计数据

这是一个专门为 AI 设计测试输出的典型案例。人类可以滚动查看，但 AI 需要"信息密度极高的摘要"。

挑战三：Agent 不懂"时间"

问题：Claude 无法感知时间流逝。它会花数小时运行完整测试套件，实际上什么实质性工作都没推进。

解决方案：提供 --fast 选项运行 1% 或 10% 的随机样本。样本对单个 Agent 确定性（可复现），但跨不同 VM 随机（确保覆盖所有文件）。

挑战四：Linux 内核编译的并行化难题

问题：编译 Linux 内核不像单元测试那样可以独立运行。16 个 Agent 会同时撞上同一个 bug，互相覆盖修复。

解决方案：用 GCC 作为"已知正确的参考编译器"。随机用 GCC 编译大部分内核文件，仅用 Claude 编译器编译剩余部分。通过对比定位 bug 在哪些文件中。然后用 delta debugging 发现"单独能工作但组合起来失败"的文件对。

这是整个实验中最精彩的工程决策之一。 它把一个不可并行的问题变成了可并行的问题。

挑战五：Agent 冷启动

问题：每个 Agent 在新容器中启动时，没有任何上下文。

解决方案：Claude 自行维护详尽的 README 和进度文件。遇到困难时还会自行记录失败方法和待办任务。

Carlini 的核心洞察

“Most of my effort went into designing the environment around Claude — tests, environment, and feedback systems.”

人类的角色不是"写代码"，而是**“设计让 AI 高效工作的环境”**。

这呼应了我在之前文章中提到的观点：从"代码书写者"到"智能系统指挥者"的转变。但 Carlini 更进一步——他说的是**“环境设计者”**。

你不需要告诉 AI 怎么写编译器。你需要做的是：

1. 设计好测试基础设施
2. 构建好反馈循环
3. 设定好质量门禁

然后，走开。

05 实操场景：什么时候该用 Agent Teams

Agent Teams 不是万能药。它有明确的适用场景和不适用场景。

✅ 强适用场景

场景一：并行代码审查

1
2
3
4
5

创建 Agent Team 审查 PR #142：
- 一个 Teammate 专注安全隐患
- 一个 Teammate 检查性能影响
- 一个 Teammate 验证测试覆盖
各自审查后汇报发现。

为什么有效：三个独立的审查维度，互不干扰，最后综合。单个审查者容易"隧道视野"——一旦开始看安全问题，就忽略性能问题。并行审查消除了这种偏差。

场景二：竞争性假说调查

1
2
3
4

用户反馈应用在发送一条消息后就断开连接。
创建 5 个 Teammate 调查不同假说。
让他们互相讨论，像科学辩论一样反驳对方的理论。
把共识写入调查报告。

为什么有效：单个 Agent 容易"锚定效应"——找到一个看似合理的解释就停止搜索。多个 Agent 互相"攻击"彼此的理论，幸存下来的假说更可能是真正的根因。

场景三：新模块并行开发

1
2

创建 4 个 Teammate 并行重构这些模块。
每个 Teammate 用 Sonnet 模型。

为什么有效：新模块天然独立，每个 Teammate 负责一个，互不冲突。

场景四：跨层协作

前端、后端、数据库——每层由不同 Teammate 负责。当接口需要对齐时，通过消息系统沟通。

❌ 不适用场景

任务粒度的"金发姑娘原则"

• 太小：协调开销大于并行收益
• 太大：Teammate 长时间不汇报，浪费风险增加
• 刚好：自包含的交付物（一个函数、一个测试文件、一份审查报告）

经验法则：每个 Teammate 分配 5-6 个任务，保证每个人都有活干，Lead 也能在某个 Teammate 卡住时重新分配工作。

06 进阶技巧

委托模式（Delegate Mode）

默认情况下，Lead 有时会忍不住自己动手干活，而不是等 Teammate 完成。

按 Shift+Tab 进入委托模式，Lead 被限制为只能使用协调工具：生成 Teammate、发消息、管理任务——不能直接写代码。

适用场景：你希望 Lead 纯粹做"项目经理"的时候。

要求 Teammate 先提方案

对于高风险任务，可以要求 Teammate 在动手前先提交方案：

1
2

创建一个架构师 Teammate 重构认证模块。
在动手改代码之前，必须先提交方案等我审批。

Teammate 会在 Plan Mode 下工作，提交方案后 Lead 自动审核。被驳回则修改后重新提交。

你可以给 Lead 设定审批标准，比如"只批准包含测试覆盖的方案"或"拒绝修改数据库 schema 的方案"。

用 Hooks 强制质量门禁

两个关键 Hook：

• TeammateIdle：Teammate 即将空闲时触发。返回 exit code 2 可以发送反馈让 Teammate 继续工作。
• TaskCompleted：任务标记完成时触发。返回 exit code 2 可以阻止完成并发送反馈。

用法示例：在 TaskCompleted hook 中自动运行测试，测试不通过则阻止任务完成。

07 成本分析：什么时候值得用

先看硬数据。

编译器实验的成本

Opus 4.6 定价

成本决策树

1
2
3
4
5
6
7
8
9

你的任务能拆分为独立子任务吗？
├── 否 → 用单会话 + Subagent
└── 是 → Teammate 之间需要讨论和协调吗？
    ├── 否 → 用单会话 + Subagent（省 token）
    └── 是 → 用 Agent Teams
        ├── 任务价值 > 预估 token 成本的 3x？
        │   ├── 是 → 放心用
        │   └── 否 → 考虑减少 Teammate 数量
        └── 用 Sonnet 模型降低单 Teammate 成本

关键洞察：Carlini 花了 $20,000 用 16 个 Agent 写编译器。如果雇人力团队做同样的事情——从零实现一个能编译 Linux 内核的 C 编译器——成本可能是数十万美元，时间可能是数月甚至数年。

但这是极端案例。对于日常开发，3-5 个 Teammate 的小型 Team 处理代码审查、bug 调查、模块重构，成本通常在几美元到几十美元之间。

08 从 Skills 到 Agent Teams：范式演进

如果你关注过我之前写的 Claude Skills 实战：打造你的 AI Agent 团队，你会发现一条清晰的演进路径：

1
2

提示词 → Skills → Subagent → Agent Teams
(一次性) → (可复用) → (可委派) → (可协作)

人类的角色：从"代码书写者"→“指令发出者”→“任务分配者”→“环境设计者”。

Carlini 在编译器实验中的时间分配是最好的注脚：

• ❌ 不花时间写代码
• ❌ 不花时间指导具体实现
• ❌ 不在线监督 Agent 日常工作
• ✅ 寻找高质量测试套件
• ✅ 编写验证器和构建脚本
• ✅ 观察 Agent 犯错模式并设计新测试
• ✅ 构建 CI/CD 流水线防止回归

这就是 2026 年"高级工程师"的工作方式。

09 冷水时间：已知限制和注意事项

Agent Teams 目前仍是实验性功能，有明确的限制：

1. 不支持会话恢复：/resume 和 /rewind 不能恢复已退出的 Teammate。恢复后 Lead 可能尝试联系已不存在的 Teammate。
2. 任务状态可能滞后：Teammate 有时忘记标记任务完成，阻塞依赖任务。
3. 关闭速度慢：Teammate 会先完成当前工具调用再关闭。
4. 一个 Lead 只能管一个 Team。
5. 不支持嵌套：Teammate 不能再创建自己的 Team。
6. Split Pane 模式不支持 VS Code 集成终端、Windows Terminal 和 Ghostty。
7. 权限在 spawn 时继承：所有 Teammate 继承 Lead 的权限模式，不能在 spawn 时单独设置。

以及 Carlini 的坦率警告：

“The thought of programmers deploying software they’ve never personally verified is a real concern.”

16 个 Agent 可以写出能编译 Linux 内核的编译器。但如果没有人验证过那 10 万行代码中的每一个角落，你敢用到生产环境吗？

Agent Teams 是强大的生产力工具，不是"按下按钮就走人"的魔法。 至少在今天，你仍然需要：

• 设计高质量的测试基础设施
• 建立自动化质量门禁
• 定期审查关键输出
• 对 Agent 的失败模式保持警觉

10 结语

Claude Code 目前已占 GitHub 公开提交的 4%。SemiAnalysis 预测到 2026 年底将超过 20%。

当 AI 编程从"一个助手帮你补全代码"进化到"一个团队帮你交付项目"，整个软件开发的经济学都在改变。

$20,000，两周，10 万行代码，能编译 Linux 内核。

这不是终点。Carlini 自己说了：Opus 4.0 勉强能输出功能性编译器，Opus 4.5 首次通过大型测试套件，Opus 4.6 实现了编译 Linux 内核的突破。每一代模型都在把"勉强能做到"变成"可靠地做到"。

下一个问题不再是"AI 能不能写代码"。

而是——你准备好设计环境，让 AI 团队替你工作了吗？

参考资料

核心文章

• Building a C compiler with a team of parallel Claudes — Nicholas Carlini, Anthropic
• Introducing Claude Opus 4.6 — Anthropic
• Claude Code is the Inflection Point — SemiAnalysis

官方文档

• Orchestrate teams of Claude Code sessions — Claude Code Docs

教程与分析

• Sixteen Claude AI agents working together created a new C compiler — Ars Technica
• Claude Agent Teams Tutorial — NxCode
• How to Set Up Claude Code Agent Teams — Medium
• Building with Opus 4.6 Agent Teams — Firecrawl