一个人走得快，一群人走得远。这句老话在 AI 编程的世界里有了新的含义——只不过"一群人"变成了"一群 AI"。
Boris Cherny 的日常工作方式是这样的：同时打开 5 个终端窗口，每个窗口运行一个独立的 Claude Code 实例。一个负责重构代码，一个负责写测试，一个负责搜索依赖，一个在审查 PR，还有一个在处理 bug 报告。它们并行工作，互不干扰，像一支训练有素的开发团队。
这不是科幻。这是 2026 年 Anthropic 内部的日常。
为什么需要多个 AI
要理解多代理协作的价值，先要理解单代理的局限。
大语言模型有一个被低估的特征：上下文是它的全部记忆，也是它的全部认知边界。你在一次对话中塞进去的东西，就是它"知道"的全部。它不知道你上一次会话做了什么，不知道隔壁终端在跑什么，不知道代码库的全貌——除非你显式地告诉它。
这意味着，当任务变得复杂时，单个 AI 会遇到三个硬墙：
1. 上下文污染
你让 Claude Code 做一个复杂功能。它在尝试方案 A，失败了。换方案 B，又失败了。换方案 C，成功了。但这时候上下文窗口里已经塞满了 A 和 B 的失败记录、错误日志、来回讨论。Claude Code 开始被这些噪声干扰——它会反复引用已经放弃的方案，或者陷入自我怀疑的循环。
TypeScript 社区知名开发者 Matt Pocock 给出了一个精准的类比：LLM 像电影《记忆碎片》的主角——每次上下文被压缩或清除，它就回到初始状态，忘记之前的探索和失败。唯一的记忆是你写在 CLAUDE.md 里的笔记。
2. Smart Zone 和 Dumb Zone
Matt 还提出了一个关键概念。LLM 的性能不是均匀的。会话开始时，上下文窗口干净、信号密度高，模型处于 Smart Zone——推理准确，输出质量高。但随着上下文增长到约 100K tokens，噪声开始淹没信号，模型进入 Dumb Zone——开始重复自己、忽略指令、犯低级错误。
这个分界线不是精确的 100K，而是取决于任务类型和上下文质量。但趋势是明确的：上下文越长，质量越差。
3. 注意力稀缺
即使上下文没有溢出，单个 AI 也很难同时处理多个不同维度的思考。它在写代码的时候，很难同时做架构评审。在做架构评审的时候，很难同时思考用户体验。人类团队之所以需要分工，不是因为我们笨，而是因为深度思考需要排他性的注意力——AI 也一样。
三个层次：从子代理到军团
Claude Code 的多代理系统不是一个功能，而是三个逐渐升级的协作层次。
层次一：子代理（Subagent）
子代理是最基础的多代理形式。主会话保持清洁，把特定任务委托给一个临时创建的独立 AI 实例。
想象你在写一个复杂功能。你需要先了解现有代码的结构。你可以自己逐个文件翻看（浪费主会话上下文），也可以派出一个子代理："去搜索代码库中所有与支付相关的模块，整理出调用关系和数据流"。
子代理在独立的上下文窗口中运行。它可能读了几十个文件，产生了大量中间输出——但这些不会污染你的主会话。它最终只返回一个精炼的结果：一张清晰的调用关系图和一段摘要。
Anthropic 的工程师 Thariq 说得直白：子代理首先是上下文管理工具，其次才是任务执行工具。它最大的价值不是"帮你干活"，而是"把干活的噪声隔离在另一个窗口里"。
每个子代理都可以精确配置：
| 参数 | 作用 | 示例 |
|---|---|---|
| model | 使用哪个模型 | Explore 用 haiku（便宜快速），审查用 opus（深度思考） |
| tools | 允许使用哪些工具 | 代码搜索代理只需 Read，不需要 Edit |
| maxTurns | 最多执行多少步 | 防止代理陷入死循环 |
| color | 终端里的颜色标识 | 绿色 = 数据获取，红色 = 代码修改 |
| memory | 记忆作用域 | project 级让代理跨会话积累经验 |
这种精细控制揭示了一个设计哲学：不是所有代理都需要同样的能力。探索代码的代理只需要读权限，用最便宜的模型就行。写代码的代理需要完整权限，用最强的模型。就像人类团队里，实习生做调研，资深工程师做架构——能力和权限匹配角色。
层次二：Agent Teams
Agent Teams 是 Claude Code 最令人兴奋的实验性功能。和子代理不同，每个 teammate 是一个完全独立的 Claude Code 会话——拥有自己的完整上下文窗口、自己的 CLAUDE.md、自己的 MCP 服务器、自己的技能。
如果子代理是"你派出去的临时工"，Agent Teams 就是"你组建的正式团队"。
Boris 在分享中演示了一个实际案例：用三个 teammate 协作构建一个"时间编排器"命令。
Command Architect（命令设计师）：负责设计用户交互流程和命令结构。它思考的问题是"用户怎么触发这个功能？需要什么参数？输出是什么格式？"
Agent Engineer（代理工程师）：负责实现具体的数据获取代理。它关注"怎么获取时区数据？怎么处理错误？模型用什么？"
Skill Designer（技能设计师）：负责创建可视化技能。它的任务是"怎么把时区数据渲染成漂亮的 SVG？"
三个 teammate 通过共享任务列表协调工作。它们约定了数据契约——比如 Agent Engineer 输出的数据格式必须是 {time, tz, formatted}，Skill Designer 据此设计渲染逻辑。
这种协作需要 iTerm2 + tmux 环境来实现分屏显示。三个 Claude Code 实例在三个终端面板中同时运行，你可以实时看到每个 teammate 在做什么。需要 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 环境变量来启用。
Agent Teams 和子代理的关键区别是独立性和完整性。子代理是主会话的延伸——它从主会话获取任务，返回结果后就消失。而 Agent Teams 的每个成员都是一个完整的 Claude Code 实例，有自己的上下文和记忆，可以独立做出复杂决策。
层次三：/batch 大规模并行
这是 Boris 最喜欢炫耀的功能。/batch 可以把一个操作并行分发到数百个独立的 git worktree 中，每个 worktree 由一个独立的代理处理。
实际例子：Boris 需要在 200 个仓库中统一升级某个依赖版本。过去这需要一个人花一周时间，逐个仓库修改、测试、提交 PR。用 /batch，他只需要描述一次操作——"在每个仓库中把 package X 从版本 2.x 升级到 3.x，运行测试，如果通过就提交 PR"——然后 200 个代理同时开工。
每个代理在独立的 git worktree 中工作，不会互相冲突。每个代理独立测试、独立提交、独立创建 PR。整个过程可能只需要几十分钟。
Boris 自己的数据更有说服力：某天他提交了 266 个贡献（141 个 PR），全部使用 squash merge。PR 的中位数只有 118 行。也就是说，绝大多数修改都非常小而专注——这正是大规模并行最擅长的场景。
一个更深的设计原则
多代理协作背后有一个常被忽略但极其重要的设计原则：独立上下文窗口是发现 bug 的好方法。
Boris 在一次分享中透露了一个内部发现：同一个模型，在不同的上下文窗口中，能发现自己引入的 bug。
如果你让一个代理写代码然后自己审查，它往往会陷入"创作者盲点"——因为它知道自己的意图，所以会不自觉地假设代码是正确的。
但如果你让代理 A 写代码，然后把代码交给代理 B（在独立上下文中）审查，代理 B 没有"意图包袱"，更容易发现逻辑漏洞。
这就像人类工程团队的交叉审查——你更容易发现别人代码里的问题，而不是自己的。AI 也是如此。
这个原则催生了 Claude Code 的代码审查功能：自动派出一组独立代理对每个 PR 进行深度审查。Anthropic 内部数据显示，引入多代理审查后，代码审查不再成为瓶颈，同时每位工程师的代码产出同比增长了 200%。
另一种跨模型验证更进一步：用 Claude 做初始实现，用 GPT（通过 Codex CLI）做独立审查。Plan（Claude Opus）→ QA Review（Codex GPT）→ Implement（Claude Opus）→ Verify（Codex GPT）。不同模型的盲点不同，交叉验证比单模型自审更可靠。
RPI：让多代理不是乱来
多代理协作最怕的不是技术问题，而是协调问题。五个代理各干各的，结果比一个代理更差——这种事经常发生。
Claude Code 社区发展出了一套系统化的多代理工作流，叫 RPI：Research → Plan → Implement。
Research 阶段是可行性分析。六个专业代理串行工作：
- 需求解析器：把模糊的需求变成结构化的功能描述
- 产品经理：写出 PRD，定义用户故事和验收标准
- 代码探索器：在现有代码库中搜索相似功能的实现（用 haiku 模型，只读权限）
- 高级工程师：评估技术可行性，选择实现方案
- CTO 顾问：从战略层面审查决策，防止过度工程
- 文档分析师：把所有分析整合成一份清晰的 Research 报告
完成之后，系统给出一个 GO / NO-GO 决策。如果不可行，到此为止，不浪费更多资源。如果可行，进入 Plan 阶段。
Plan 阶段产出四份文档：产品需求（pm.md）、用户体验设计（ux.md）、技术规格（eng.md）和实施路线图（PLAN.md）。每份文档由不同的专业代理负责。
Implement 阶段按路线图分步执行，每一步都有严格的六步验证门：
代码发现 → 实现 → 自验证 → 独立代码审查 → 用户确认 → 文档更新
其中"独立代码审查"和"用户确认"是两个强制停止点。代码审查由独立的 review 代理执行（不是实现者自己审查）。用户确认要求人类明确批准才能继续下一步。
这个流程的核心思想是：多代理协作的价值不在于"更多 AI"，而在于"更多独立视角"。六个代理串行分析需求，不是因为一个代理做不了，而是因为六个不同角色的代理能从产品、技术、战略、UX 四个维度交叉验证，发现单一视角的盲点。
RPI 的创建者 Dexter Horthy 在 MLOps Community 分享时坦承了他们犯过的错误：研究阶段不应该告诉模型"要构建什么"——那会导致 opinions 而非 facts。正确的研究应该"压缩真相"——只包含客观信息，让下游代理自己得出结论。他还强调了一个核心原则："不要外包思考"——工程师在 AI 辅助编码中仍然是关键环节，不能让 AI 替代所有决策。
为什么这个设计有效
回过头来看，Claude Code 的多代理系统为什么有效？因为它遵循了三个基本原则。
原则一：能力匹配角色
不是所有代理都需要最强的模型。Explore 代理用 haiku（便宜、快速），code-review 代理用 opus（深度、准确），Command 入口用 sonnet（均衡）。模型选择像金字塔——底层大量调用用便宜模型，顶层关键决策用贵模型。
原则二：上下文隔离
每个代理在独立的上下文窗口中工作。一个代理的中间输出、失败尝试、调试日志不会污染其他代理。主会话保持干净，只接收精炼后的结果。
原则三：独立验证
实现者和审查者是不同的代理。写代码和审代码的 AI 实例在不同的上下文中运行，没有"创作者盲点"。这是多代理系统最重要的安全机制——它让 AI 具备了"自我纠错"的能力，只不过纠错的"自己"是另一个独立的实例。
Anthropic 内部有个说法：2026 年的编程不是"一个人写代码"，而是"编排一支 AI 军团"。Boris 本人每天 10-30 个 PR，100% 由 AI 生成，141 个 PR 的中位数只有 118 行。这不是一个人在写代码——这是一个指挥官在调度一支精锐部队。
而他的武器只有一个：终端里并排打开的五个 Claude Code 窗口。
下期预告
下一篇，我们将从理论走向实战。Boris 分享的 50 条黄金法则——从并行工作到计划模式，从 CLAUDE.md 迭代到验证闭环——每一条都来自 Anthropic 内部数百工程师的真实经验。这不是教科书上的建议，这是战场上总结的生存法则。
下期见。
Views: 2