日期: 2026年6月5日

解码 Claude Code（五）— 多代理协作：从单兵作战到 AI 军团

一个人走得快，一群人走得远。这句老话在 AI 编程的世界里有了新的含义——只不过"一群人"变成了"一群 AI"。

Boris Cherny 的日常工作方式是这样的：同时打开 5 个终端窗口，每个窗口运行一个独立的 Claude Code 实例。一个负责重构代码，一个负责写测试，一个负责搜索依赖，一个在审查 PR，还有一个在处理 bug 报告。它们并行工作，互不干扰，像一支训练有素的开发团队。

这不是科幻。这是 2026 年 Anthropic 内部的日常。

Team Collaboration

为什么需要多个 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 阶段是可行性分析。六个专业代理串行工作：

  1. 需求解析器：把模糊的需求变成结构化的功能描述
  2. 产品经理：写出 PRD，定义用户故事和验收标准
  3. 代码探索器：在现有代码库中搜索相似功能的实现（用 haiku 模型，只读权限）
  4. 高级工程师：评估技术可行性，选择实现方案
  5. CTO 顾问：从战略层面审查决策，防止过度工程
  6. 文档分析师：把所有分析整合成一份清晰的 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: 29

解码 Claude Code（四）— 技能系统：用 Markdown 打造可复用的 AI 能力

如果 AI 编程助手只能做一件事，它永远比不上能做一百件事的助手。但如果这一百件事每次都要你手把手教，那也不比自己做快多少。真正的效率飞跃，来自把"教过一次的经验"变成"随时可调用的能力"。

这就是 Claude Code 技能系统要解决的问题。

Code Skills

从一个真实场景说起

Anthropic 内部有数百个活跃技能，每天都在被工程师使用。这些技能不是什么高深的 AI 黑科技——它们就是 Markdown 文件。

一个典型的技能长这样：

---
name: code-review
description: "当用户要求审查代码变更时使用此技能"
when_to_use: "用户说'审查这段代码'、'review这个PR'、或提到代码质量时"
model: sonnet
effort: high
---

你是一名高级代码审查者。请检查以下内容：

1. 逻辑错误和潜在 bug
2. 安全漏洞
3. 性能问题
4. 代码风格一致性

对于每个发现，给出严重程度（🔴 严重 / 🟡 警告 / 🟢 建议）和修复建议。

就这么简单。一个 YAML 头部描述元数据，一段 Markdown 正文描述指令。没有 JSON schema，没有 Python 插件系统，没有 npm 依赖——纯文本。

Anthropic 的工程师 Thariq 在分享中提到一个有趣的数据：内部最受欢迎的技能不是那些复杂的工作流编排，而是最简单的几行规则——比如"每次保存文件后自动格式化"，或者"提交代码前检查有没有遗留的 console.log"。

技能的九种类型

Thariq 把 Anthropic 内部的数百个技能归纳为九大类型，覆盖了软件开发的几乎所有环节：

1. 库/API 参考
把常用库的 API 文档整理成技能，让 Claude 不用每次都去查文档。比如"React Server Actions 最佳实践"，里面包含了完整的用法示例和常见坑。

2. 产品验证
定义什么是"好的用户体验"，让 Claude 在写代码时有判断标准。比如"移动端适配检查清单"，列出了触摸目标大小、字体层级、断点处理等标准。

3. 数据获取与分析
教 Claude 如何连接内部数据库、如何写特定格式的查询、如何解读结果。

4. 业务流程自动化
把重复的业务操作封装成技能——生成周报、同步状态、发送通知。

5. 代码脚手架
项目初始化模板、新组件创建规范、文件命名约定。

6. 代码质量审查
这是使用最频繁的类型。代码审查、安全扫描、性能检查。

7. CI/CD 部署
定义构建、测试、部署的完整流程。

8. Runbooks
故障排查手册——出问题时 Claude 照着步骤走就行。

9. 基础设施运维
Kubernetes 配置、服务器管理、日志分析。

这九种类型揭示了一个关键洞察：技能的本质不是"教 AI 新能力"，而是"把团队的最佳实践固化成可复用的知识单元"。

两种技能模式

技能系统有两种工作模式，它们看起来相似，但设计哲学完全不同。

模式一：主动技能（Skill）

这是最常见的模式。用户通过斜杠命令或自然语言触发，技能像一个独立的工具被调用。

比如"天气 SVG 生成器"技能——你问"今天天气怎么样"，Command 组件收到请求后，让 Agent 去获取天气数据，然后调用这个技能把数据渲染成一张漂亮的 SVG 图表。

关键特征：

  • 用户可见，可以主动调用
  • 接收对话上下文中的数据作为输入
  • 独立执行，产出自包含的结果
  • 类比：工具箱里的专用工具

模式二：代理技能（Agent Skill）

这种技能不直接被用户调用。它被注入到某个代理的启动上下文中，作为该代理的"领域知识"。

比如一个"天气数据获取"技能——它不会被用户直接使用，而是被预加载到天气代理的知识中。当天气代理启动时，这个技能的完整内容已经被塞进了上下文窗口。代理知道该调用哪个 API、参数格式是什么、怎么解析返回值。

关键特征：

  • 用户不可见（user-invocable: false）
  • 在代理启动时注入，不是运行时调用
  • 提供指令性知识而非可执行操作
  • 类比：新员工的入职手册

这两种模式的配合方式很优雅：代理技能负责"怎么获取数据"，主动技能负责"怎么呈现结果"。获取和渲染解耦，各管各的。

写好技能的九条铁律

根据 Thariq 分享的 Anthropic 内部经验，写好一个技能需要遵循九条最佳实践。

1. 不说废话

技能正文里不要写"你是一个优秀的 AI 助手"之类的客套话。每一行都应该是有信息量的指令。模型不需要鼓励，它需要规则。

❌ "请仔细检查代码，你很棒的！"
✅ "检查以下三项：空指针引用、SQL 注入、未处理的 Promise"

2. 建 Gotchas 区

这是整个技能系统里价值最高的部分。Gotchas 就是"踩坑记录"——记录那些看起来正确但实际会出错的地方。

## Gotchas
- Stream API 的 `.collect()` 在空流上不会抛异常，但会返回空集合
- `@Transactional` 只对 public 方法生效，private 方法上的注解会被静默忽略
- Docker 多阶段构建中，COPY 指令的路径是相对于前一个阶段的

Thariq 特别强调：在技能被 Claude 加载时，Gotchas 区域的信号量（即注意力权重）最高。因为这些是来自真实失败的经验，模型会优先参考。

3. 文件系统渐进式披露

不要把所有内容塞进一个巨大的 SKILL.md。告诉 Claude 文件结构，让它按需读取。

## 参考文件
- `api-spec.yaml` — 完整的 API 规格
- `examples/` — 使用示例
- `gotchas.md` — 常见陷阱

这样 Claude 在处理简单问题时只读 SKILL.md 本身，遇到复杂场景才去翻参考文件。上下文更精简，响应更快。

4. 不要过度约束

这是最常见的错误。给目标和约束，不要给步骤式指令。

❌ "第一步打开文件，第二步找到函数，第三步修改参数..."
✅ "将所有 API 调用从 REST 迁移到 GraphQL，保持向后兼容"

原因很简单：模型比你更擅长规划执行步骤。你规定步骤反而限制了它的优化空间。

5. 描述字段是触发条件，不是摘要

技能的 description 字段不是给人类看的简介，而是告诉模型"什么时候该用这个技能"的触发条件。

description: "当用户提到部署、发布、上线、或者需要将代码推送到生产环境时使用"

模型会根据这个描述判断是否激活技能。写成摘要就失去了这个功能。

6. 想清楚设置流程

有些技能依赖外部配置——API 密钥、数据库连接、MCP 服务器。在技能里明确写出设置步骤，避免 Claude 盲目尝试。

7. 记忆与数据存储

告诉 Claude 技能产出的数据应该存哪里。是写入文件、更新数据库、还是只在对话中返回。这避免了结果丢失或重复计算。

8. 脚本与代码生成

技能不只是文字指令，可以包含完整的脚本模板。比如一个"数据库迁移"技能，里面可能包含 SQL 模板、回滚脚本、验证查询。

9. 按需 Hooks

Hooks 是确定性挂载到代理生命周期的钩子函数。比如 PostToolUse Hook 可以在每次文件写入后自动运行格式化。不是每个技能都需要 Hook，但在需要自动化流程时它非常强大。

编排的艺术：Command → Agent → Skill

技能不是孤立使用的。Claude Code 的架构推崇一种三层编排模式：

Command（入口）→ Agent（执行者）→ Skill（能力单元）

以"天气查询"为例：

  1. Command 收到用户请求"今天天气怎么样"，先用轻量模型（haiku）询问用户偏好（摄氏还是华氏）
  2. Agent 被派出去获取天气数据，它启动时已经预加载了天气获取技能（Agent Skill），知道该调用哪个 API
  3. Skill 被调用来把数据渲染成 SVG 图表（主动技能）

每一层各司其职：Command 负责交互和路由，Agent 负责执行和获取数据，Skill 负责专业输出。这种分离让每个组件可以独立替换——换一个城市的天气 API？改 Agent Skill。换一种图表风格？改主动 Skill。用户交互流程变了？改 Command。互不影响。

Boris 在分享中提到一个深刻的设计原则：入口轻，执行重。Command 用便宜快速的模型，Agent 用中等模型处理逻辑，只有在真正需要深度思考的时候才用 Opus 这种顶级模型。整个调用链的模型选择像一个金字塔——底层频繁调用用便宜模型，顶层复杂决策用贵模型。

10 个官方内置技能

Claude Code 自带 10 个内置技能，覆盖了最常见的开发场景：

技能 用途
code-review 深度代码审查
batch 大规模批量操作
debug 系统化调试
loop 定时循环任务
claude-api SDK 开发辅助
fewer-permission-prompts 减少权限弹窗
run 启动应用服务
verify 验证代码变更
run-skill-generator 生成新的启动配方
simplify 代码精简

其中最值得细说的是三个：

/batch 是 Boris 最喜欢炫耀的功能。它能把一个大规模变更并行分发到数百个独立的 git worktree 中，每个 worktree 由一个独立的 Agent 处理。Boris 曾经一次性让 Claude 在 200 个仓库中统一升级依赖版本——整个过程全自动，每个仓库一个独立 PR。

/loop 是定时任务的优雅实现。/loop 5m /simplify 会每 5 分钟运行一次代码简化技能，最长持续 3 天。任务绑定在会话上，退出 Claude 就自动停止。底层使用 CronCreate/CronList/CronDelete 工具，但用户完全不需要知道这些。

/simplify 的设计很有意思。它不是让一个 Agent 去简化代码，而是同时派出 4 个独立的 review Agent，从不同角度审查代码质量。4 个 Agent 各自给出简化建议，然后汇总决策。这种"多视角并行审查"的模式，比单个 Agent 反复检查更有效。

从个人技能到团队知识库

技能的威力在于它的分发方式。

小团队把技能文件夹检入 Git 仓库，所有人共享。每次有人踩了新坑，就更新 Gotchas。技能在 PR review 中不断迭代，越用越精准。

大团队用插件市场。Anthropic 内部有一个技能商店，工程师可以发布、搜索、安装技能。好的技能会自然浮上来——不是因为有人推广，而是因为用的人多。

Boris 有一个观点值得深思：技能系统的终极目标不是让 AI 更聪明，而是让团队的知识不再只存在于个人的脑子里。 每个人的经验、踩过的坑、总结的最佳实践——都变成一个 .md 文件，可以版本控制、可以 review、可以传承。

当资深工程师离职时，他留下的不是空荡荡的工位，而是一套经过千锤百炼的技能文件。新来的工程师不需要"跟老人学习三个月"——Claude 已经学会了所有前人的经验。

这可能是技能系统最深远的影响。

下期预告

下一篇，我们将深入 Claude Code 最令人兴奋的能力：多代理协作。Boris 怎样同时指挥 5 个 AI 实例并行工作？Agent Teams 和 Subagent 有什么区别？从单兵作战到 AI 军团的组织方法是什么？

下期见。

Views: 21