7月17日消息,Anthropic 的 Boris Cherny 发布了一份名为"AI 采纳的步骤"(Steps of AI Adoption)的框架,将工程团队使用 AI Agent 的成熟度分为 5 个阶段,从"受限"(0 个 Agent)到"AI 原生"(1000+ 个 Agent)。Cherny 称这一框架来自他与大量工程团队的日常交流,最常听到的情况是:团队中某个人用 Claude 实现了 10 倍产出,但组织的其他部分还没有跟上。框架的核心观点是,AI 采纳的瓶颈不在 Token 供给量,而在每个阶段特有的信任、审查和治理问题——要进入下一阶段,必须先识别并打破当前阶段的瓶颈,同时建立对应的防护措施。Cherny 表示 Anthropic 自身目前处于第三阶段,正在向第四阶段推进。 五个阶段:角色从配对程序员变成方向控制者
Cherny 将 AI 采纳分为 5 个阶段,编号从 0 到 4。每个阶段有明确的 Agent 数量、工程师角色定义、典型场景和核心瓶颈。
阶段 0 是"受限"(Gated),Agent 数量为 0。特征是组织内只批准了老旧或轻量模型,AI 工具的访问被层层审批流程限制,没有 MCP 治理,安全团队关注的是单 Token 成本而非产出效果。瓶颈在制度层面:缺少技术背景的决策者参与,安全和采购流程未针对 AI 工具做适配。从 0 到 1 的关键是管理层对齐和安全审批框架的建立。
阶段 1 是"辅助"(Assisted),约 1 个 Agent。工程师和 Agent 形成配对编程关系,一次运行一个会话,几乎审查每一次改动才允许合并。一个下午才能完成的任务变成两次会议之间就能搞定的事。瓶颈在工程师的注意力:信任度低导致需要逐行检查输出,工作完全同步。从 1 到 2 的关键是同时运行多个 Agent、引入自验证循环(测试、构建、lint、端到端测试),以及开启自动模式避免反复确认权限。
阶段 2 是"并行"(Parallel),约 10 个 Agent。一名工程师同时编排 5 到 10 个 Agent,每个在独立的 worktree 或 git checkout 中运行。Claude 开始检查自己的代码,自动代码审查和安全审查默认开启。工程师的角色从写代码变成审查多个 diff 流。瓶颈从"写代码"转移到"审查吞吐量"——手写代码减少了,但同时检查六条输出流占用了更多时间。从 2 到 3 的关键是让 Claude 能主动拉取上下文(代码、文档、讨论),以及将工作拆分为循环和例程,让 Claude 可以启动 Claude。
阶段 3 是"有监督自主"(Supervised Autonomy),约 100 个 Agent。Claude 编写几乎全部代码。工程师的问题从"你看过这段代码吗"变成"模型缺少什么上下文,下次怎么解决"。维护和清理工作在后台持续自动运行。瓶颈在信任闭环和团队的决策吞吐量——Agent 树太深以至于无法逐一监督,风险是在信任循环建立之前就盲目扩大 Agent 数量。从 3 到 4 的关键是将领域特定的工作类型(代码迁移、模糊测试、功能开发、反馈修复)规模化自动化。
阶段 4 是"AI 原生"(AI-Native),1000+ 个 Agent。闭环完全建立,大部分 Agent 由 Claude 自行启动。工程师以意图驱动(steer by intent),按异常监控(monitor by exception)。一个季度级的迁移项目变成一个启动后定期检查的工作流。瓶颈在于识别和自动化哪些工作可以规模化执行,以及为不同类型的工作配置正确的防护措施。
瓶颈的迁移规律:从审批到注意力到信任到治理
Cherny 框架中最有信息量的部分不是阶段划分本身,而是瓶颈的演变路径。五个阶段的瓶颈分别是:制度审批(阶段 0)、工程师注意力(阶段 1)、审查吞吐量(阶段 2)、信任循环(阶段 3)、治理和自动化识别(阶段 4)。这个序列揭示了一个模式:每跨过一个阶段,瓶颈就从技术层上移到组织层。阶段 0 和 1 的瓶颈是个体级别的(能不能用、敢不敢放手),阶段 2 和 3 是团队级别的(审查效率、信任建设),阶段 4 是组织级别的(哪些工作该自动化、怎么确保质量)。
与之对应的防护措施也在升级。阶段 1 依赖的是人工逐行审查和支出上限。阶段 2 引入自动化代码审查、安全审查和端到端验证。阶段 3 需要 Agent 沙箱、CLAUDE.md 编码规范和基于使用模式的自动模式分类器调优。阶段 4 的防护措施是成本控制和模型选择的自动化——这时候人的角色不再是审查代码,而是设计审查系统。
每个阶段的"解锁"信号
Cherny 在框架中为每个阶段定义了"解锁"标志——即团队进入该阶段后获得的能力跃升。阶段 1 的解锁是"一个下午的工作变成会议间隙就能完成"。阶段 2 的解锁是"一个团队几周才能消化的待办变成一个工程师的编排任务"。阶段 3 的解锁是"以前需要等人来处理的维护工作现在在后台持续运行"。阶段 4 的解锁是"一个季度级的迁移变成一个可以启动后定期检查的工作流"。这些解锁描述的不是效率百分比,而是工作性质的改变——从"做得更快"到"做以前做不了的事"。
框架的适用边界和潜在偏差
Cherny 的框架需要在两个边界内理解。
第一,这是一份 Anthropic 视角的产品地图。每个阶段列出的"推荐产品"几乎全部是 Claude 生态的组件:Claude Code、Claude Tag、Claude Security Review、Agent SDK、worktree 隔离、/loop、/batch 等。框架将 AI 采纳路径和 Claude 产品路线图做了精确对应。对于已经选定 Claude 作为主力工具的团队来说,这份框架是一份实用的分阶段部署指南。对于使用其他模型或混合方案的团队,阶段划分和瓶颈分析仍有参考价值,但产品建议需要替换。 第二,Agent 数量只是代理变量,不是目标本身。框架中"从 1 到 10 到 100 到 1000"的表述容易被读成"越多越好"。Cherny 自己在帖文中指出,阶段 3 的陷阱恰恰是"在信任循环建立之前就盲目扩大 Agent 数量"。Agent 数量是成熟度的结果而非原因,用它来衡量进展需要配合信任度和质量指标一起看。
这份框架对工程团队的实际价值
Cherny 描述的"一个人用 Claude 产出提升 10 倍,其余人没跟上",是当前 AI 工具在工程团队中最普遍的采纳状态。这个状态对应的是阶段 1——组织中存在零散的高效个体,但没有从个体效率向团队能力的系统性转化。框架的价值在于给出了从个体到组织的完整路径,并且诚实地指出每个阶段的瓶颈不是技术问题而是治理问题:安全审批、审查流程、信任建设、成本控制。这些不是 Token 能解决的,需要管理者和工程师共同推动。Anthropic 自身处于阶段 3 向阶段 4 过渡的事实也值得注意——即使是 Claude 的开发者也还没有达到"AI 原生"状态,这意味着第四阶段目前更接近理论框架而非经验总结。