成熟度不是模型更强
同一个模型，在没有测试、上下文、权限边界和成本观测时，只能当结对助手；有了可信闭环后，才可能成为异步执行单元。
01 / 结论先行
图表真正衡量的是“人类介入密度”
Agent 数量从 0、1、10、100 到 1000+ 只是可见表象。隐藏的主轴是：每个任务需要多少次人工确认、多少人工审查、多少组织协调，以及失败能否被系统自动发现并纠正。
瓶颈会持续向上迁移
先卡审批，再卡人的注意力，然后卡评审，最后卡组织决策、任务发现、产品品味和治理。AI 不消灭复杂性，只改变复杂性的位置。
并非所有公司都应到第四级
高合规、低毛利、非标准流程多的企业，更合理的目标可能是“局部 AI Native、整体 AI 增强”，而不是全组织运行 1000 个 Agent。
一个人借助 Claude 获得 10 倍产出，不等于组织完成了 AI 转型。真正的问题是：剩余组织是否能吸收这 10 倍产出。
这是 Boris 在发布五级模型时提出的原始观察。它也解释了为什么个人生产力提升常常在代码评审、跨部门决策和上线流程处重新归零。
02 / 五级采用
从审批工具，到按意图治理
原图把 0 级作为起点，再给出 1 到 4 的四次跃迁。每一级都不是“多开几个会话”，而是人的角色与组织稀缺资源发生变化。
STEP 0
0审批者
Gated：工具被流程包围
只批准旧模型或轻量模型；AI 网关、认证和审批叠加延迟；没有 MCP 治理，也没有承载 AI 产物的部署路径。产物往往停留在个人本地。
核心瓶颈
旧安全流程、按 Token 单价而非业务结果管理，以及技术声音无法进入采购与治理决策。
STEP 1
~1结对者
Assisted：人和一个 Agent 同步工作
一次运行一个 Agent，几乎检查每次回复和每处改动。过去占满下午的任务可能在两场会议之间完成，但工作仍然需要人全程盯守。
核心瓶颈
人的注意力和低信任。没有自验证，工作无法异步，人只是把键盘操作换成了监督操作。
STEP 2
~10编排者
Parallel：隔离环境中的并行执行
一人编排 5 到 10 个 Agent，每个 Agent 在独立 worktree 中工作，并在交付前运行测试、构建、Lint 和安全扫描。人看最终 Diff，不看每次按键。
核心瓶颈
评审吞吐与上下文切换。代码生产加速后，人的任务从“写”变成“判断六股输出是否值得合并”。
STEP 3
~100管理管理者
Supervised autonomy：Agent 主动发现并执行任务
维护、清理和修复在后台持续发生。复盘问题从“你读代码了吗”变成“模型缺了什么上下文，如何让下一次不再缺”。
核心瓶颈
对 Loop 的信任、团队决策速度和 Token 效率。最大的陷阱是闭环尚未赢得信任，就先扩大 Agent 数量。
STEP 4
~1000+意图治理者
AI-native：大多数 Agent 由 Agent 启动
任务循环完全闭合，数百到数千 Agent 运行；人通过目标和约束 steering by intent，并按异常而非按步骤进行管理。
核心瓶颈
规模化发现值得做的工作，并为不同任务配置不同护栏、模型和成本预算。
0→1
从准入到可用
高管与采购对齐；建立身份、数据和安全框架；为 AI 生成物提供合法的部署路径。
1→2
从同步到异步
可信自验证、自动审查、隔离工作区和安全命令预授权。后台子 Agent 正是在这里发挥作用。
2→3
从编排到主动
让 Agent 读取代码、Wiki 和讨论；把工作拆成 Loop 与 Routine；允许 Agent 启动并管理其他 Agent。
3→4
从主动到规模化
把迁移、模糊测试、反馈修复等领域流程程序化，同时建立成本路由和分级治理。
03 / 人的角色
五种未来团队原型
Boris 的另一条帖子把工程、产品、设计和数据科学的岗位边界重新切开。未来团队的基本单位不是职位名称，而是一个人在产品生命周期中承担哪种贡献。
AI 让“增加东西”变便宜以后，最稀缺的人不只是 Builder，也包括能删除、收敛和维持系统秩序的 Sweeper。
多数人会跨越两种，有时三种原型。原型不是职能标签：设计师、工程师、PM 和数据科学家都可能成为 Prototyper、Builder 或 Sweeper。
原型探索者PROTOTYPER
产生全新方向，快速试出大量想法，接受其中大部分不会发布。
稀缺能力：探索宽度
构建者BUILDER
把原型快速变成生产级产品或基础设施，处理真实可靠性与规模问题。
稀缺能力：端到端落地
清理者SWEEPER
简化 UI 和代码、撤下无效功能、优化性能、降低系统熵。
稀缺能力：删除与收敛
增长者GROWER
围绕真实用户、留存与反馈持续迭代，推进产品市场匹配。
稀缺能力：信号放大
维护者MAINTAINER
让成熟系统在规模增长时保持安全、可靠、快速和成本高效。
稀缺能力：长期稳态| 产品阶段 | Prototyper | Builder | Sweeper | Grower | Maintainer | 与采用阶梯的关系 |
|---|---|---|---|---|---|---|
| Pre-PMF | 高 | 高 | 高 | 低 | 低 | 适合用 Step 1-2 扩大探索，但要由 Sweeper 防止原型债务堆积。 |
| 已找到 PMF | 中 | 高 | 高 | 高 | 中 | 从 Step 2 向 3 过渡，核心是把增长反馈和维护任务变成可验证 Loop。 |
| 强 PMF / 规模化 | 低 | 中 | 高 | 高 | 高 | Step 3-4 的价值最大，但治理、成本和系统稳定性成为第一优先级。 |
后台子 Agent 是组织转折点
Boris 随后宣布子 Agent 默认在后台运行，人可以继续与主 Agent 对话。这不是一个小交互：它把人从“等待一个 Agent 完成”推到“同时管理多个未完成承诺”，直接支撑 Step 1 到 Step 2 的异步化。
同步等待 → 异步委派
逐步检查 → 最终 Diff 审查
单一上下文 → 多个隔离上下文
写代码瓶颈 → 注意力与评审瓶颈
04 / 隐藏底座
知识库补出的六项组织能力
原图列的是产品和护栏。Obsidian 中关于 AI 原生组织、Harness 工程、Loop 工程、群聊 Agent 与上下文工程的材料，揭示了产品清单背后的能力结构。
01
可消费的上下文
代码、Wiki、讨论、决策与客户反馈必须可搜索、可访问、可追溯。私聊共识和个人脑内偏好不会自动成为 Agent 的上下文。
组织原则：work in public，但按 workspace 安全域隔离。02
可信验证闭环
测试、构建、Lint、浏览器、模拟器、Evals、安全扫描和生产健康检查共同构成反馈信号。没有验证，就没有可委派的自主性。
工程原则：执行者与评判者分离。03
隔离与编排
并行 Agent 要有独立 worktree、清晰任务边界、停止条件和合并策略。后台运行只解决等待问题，不自动解决冲突与重复工作。
运行原则：先让一个 Loop 稳定，再扩大 Agent 数量。04
动态治理边界
权限、沙箱、模型选择、预算、数据域，以及“必须由人核实”的任务清单都要显式化，并随能力变化定期复审。
治理原则：信任但要核实，边界可以移动但不能隐身。05
决策吞吐与品味
代码生成变快后，稀缺资源变成目标定义、优先级、架构判断、产品品味、跨职能决策和删除错误方向的勇气。
组织原则：短决策链比多 Agent 更接近真正的 AI Native。06
经济承受力
高频试错需要利润空间、数据基础、复合人才和组织容错。Token 成本下降不等于总成本下降，规模化会把使用、审查和治理成本一起放大。
商业原则：AI Native 首先是商业模式问题，其次才是技术问题。最大加速比 = 1 ÷ (1 − P)
阿姆达尔定律给出了原图背后的数学直觉：当 AI 加速了可自动化的 P，剩余的 (1−P) 会成为新上限。Step 1 的 (1−P) 是监督；Step 2 是评审；Step 3 是决策、信任与上下文；Step 4 是任务发现、品味、合规和治理。真正的组织竞争力来自持续压缩这些不可加速部分，而不是只把 Agent 数量做大。
05 / 经济适配
大多数企业需要的是“选择性 AI Native”
采用阶梯容易让人误以为所有组织都应该向 Step 4 冲刺。知识库材料给出的更现实答案是：先看业务经济性，再决定哪些工作流值得进入高自治阶段。
启发式区间：毛利率 > 60%
全栈 AI Native 候选
软件、SaaS、金融、内容平台等高毛利业务，更可能承受高价复合人才、并行试错和转型过渡成本。
- 目标可以到 Step 3-4
- 重点投资上下文、验证和成本路由
- 组织设计可向小团队、短决策链靠拢
启发式区间：毛利率 30%-60%
局部 AI Native
专业服务、中高端制造、品牌消费等，更适合在软件研发、营销、客服、研究和数据分析中建立高自治闭环。
- 目标以 Step 2-3 为主
- 用 FDE 或复合型团队打通业务现场
- 保留合规、交付和现实世界节点的人审
启发式区间：毛利率 < 20%
AI 增强优先
传统制造、零售、物流和农业等低毛利、长链条业务，整体 AI Native 化可能得不偿失。
- 聚焦模式化、高频、可验证的环节
- 目标以 Step 1-2 为主
- 衡量单位应是业务结果，而不是 Agent 数量
毛利率区间来自知识库文章的经验性判断，不是普适财务定律。真正决策还要同时看业务链长度、试错周期、监管强度、数据质量和人才供给。
问题类型
高自治最适合封闭问题
组织不应按部门统一规定“AI 到第几级”，而应按任务风险和可验证性分层。
封闭问题：让 Agent 驱动
边界清晰、完成标准明确、反馈可自动获得，适合逐步推进到 Step 3-4。
- 代码迁移、依赖升级、常规缺陷修复
- 模糊测试、报表生成、反馈分类
- 规则明确的客服与运营流程
开放问题：让人驱动
问题本身尚未定义，价值取决于品味、非语言直觉、权衡和责任承担，宜保持 Step 1-2 的人类主导。
- 产品方向、品牌表达、组织战略
- 重大架构抽象和商业模式选择
- 法律、合规、安全信任边界
06 / 落地路线
一个更稳健的 90 天推进法
不要先建“千 Agent 平台”。先选一个真实、高频、可验证的工作流，让它连续跑稳，再把经验编码成组织能力。
选闭环，不选演示
- 选择一个封闭、可回滚、每周重复的任务
- 记录人工基线：周期、成本、缺陷和等待时间
- 明确“AI 可定”和“必须人定”的边界
- 让最重度使用 AI 的 10% 员工跑通端到端流程
升级闸门：结果可重复，失败类型可解释，且没有把风险转移给下游。
把信任写进系统
- 补齐测试、构建、Lint、E2E 与安全扫描
- 整理代码、Wiki、决策记录和领域知识
- 为并行 Agent 配置隔离工作区和合并规则
- 建立单任务成本、模型选择和观测仪表板
升级闸门：Agent 能先自证，人工从逐步盯守转为审查最终产物。
扩大并行，不扩大混乱
- 从 1 个 Agent 扩到 3-5 个，不追求表演性规模
- 将重复任务拆成 Loop、Routine 或事件触发器
- 自动代码审查与人工责任人并存
- 每月审计一条最吵、最贵的旧流程并决定删除或重写
升级闸门：产出提升快于审查成本，质量与事故指标没有恶化。
指标
用结果衡量，不用 Agent 数量衡量
Lead time从任务提出到可用交付的周期
首次通过率Agent 第一次交付即通过验证和审查的比例
自主完成率无需人工中途介入即可完成的任务比例
审查时间每个有效交付物需要的人工判断分钟数
缺陷逃逸率上线后才暴露的质量与安全问题
成功任务成本每个通过验收任务的模型、工具和人工总成本
上下文返工率因缺少领域知识、规范或数据而返工的比例
决策等待占比总周期中等待审批、评审和跨部门响应的时间
07 / 客观校正
这张图很有价值，但不能当行业定律
它是一位 Claude Code 产品负责人的经验模型，具有强工程语境和明显的 Claude 产品视角。把它用于决策前，需要保留以下限制。
Agent 数量是示意，不是实证阈值
~10、~100、~1000+ 没有公开样本量、分布和成功率支撑。一个可靠 Agent 可能比一百个低质量 Agent 更接近成熟。
线性阶梯会掩盖任务组合
同一家公司可以让依赖升级处于 Step 3，让核心架构处于 Step 1，让生产部署保留强人工闸门。成熟度应按工作流评估。
Gated 不总是落后
在金融、医疗、关键基础设施和高风险数据域，严格准入可能是理性治理。问题不在“有没有门”，而在门是否与风险匹配、是否可解释。
模型偏重软件工程
真实企业还包含销售、供应链、线下运营、监管和组织政治。它们的验证信号更弱、现实世界反馈更慢，不能直接复制代码工作流。
产品清单带有厂商立场
Auto mode、Claude Tag、Agent SDK 等确实对应能力，但企业应把能力与具体产品解耦，避免将成熟度等同于采购某一厂商套件。
“更多自动化”也会制造新债务
Skills、MCP、Hooks、策略文件和自动规则会产生配置债务。没有清理周期和责任人，Harness 自身会成为新的复杂系统。
我的结论：这张图最适合用作“发现下一瓶颈”的地图，而不是“追求 Agent 数量”的排行榜。企业每升一级，都应证明三个条件：闭环已经可信、组织能吸收新增产出、商业回报覆盖新增成本。只满足技术条件而不满足后两项，扩张只会更快地产生返工。
08 / 来源
材料与证据边界
原图和 X 帖子提供作者观点；官方文档用于核实相关产品能力；Obsidian 知识库材料用于组织层面的交叉解读。
一手材料与官方文档
证据说明：Boris 的图表明确标注为用户生成、未经 Claude 验证；文中的 Agent 数量、角色和阶段应视为经验模型。Obsidian 中的中文文章包含二手案例与作者判断，本文只把它们用于构建分析框架；涉及具体企业数据时，应回到公司披露或原始研究进一步核验。