AI 智能体自治等级

目录

• 1. 攀登：三个时代和一个栈
• 2. 六个等级
• 3. 风险和可逆性决定上限
• 4. 指标让自治稍微可靠一点
• 5. 思考就绪度
• 6. 四种反模式
• 7. 校准练习
• 8. 如何安全攀升

在大多数关于智能体工程的讨论里，重点已经从“怎么提示模型”，转向“怎么操作和管理持续运行的智能体”。现在的前沿还不够清晰：软件工厂、目标、循环、后台会话、子智能体、钩子、沙箱、负责审批的智能体，都还在快速成形。对很多正在构建未来产品的人来说，这些能力会从第一天就内置进产品。Claude Code 和 Codex 已经把这种变化直接暴露出来。

从工程师的角度看，低自治适合控制风险、提高可回滚性；更高自治适合目标明确的活动，也适合让一组并行智能体安全地重构大型代码库。每次要让智能体执行动作时，问题都一样：这个任务应该处在哪个等级？需要什么验证，才能让这个等级站得住脚？

更前沿的形态是管理型智能体：它在触发条件满足时醒来，把任务分派给辅助智能体，持续验证它们的输出，最后只把必须由人决策的部分带回来。已经使用这类配置的人，可能已经在持续演进的代码库上运行数百甚至数千个智能体。和所有关于自治的讨论一样，每个人对规模的感知仍然不同。

最常被提到的量表，来自 Steve Yegge 在《Welcome to Gas Town^[1]》和 The Pragmatic Engineer 中提到的单维度等级表。如果你想用一个数字衡量自己有多 AI 原生，它是一个不错的参照：只要你能判断自己对单个智能体的信任程度，这个等级表就能给出一个数字。下面是一种版本：

2026 年初，尽管工作已经开始从委派转向编排，这个等级表仍然是衡量风险的一个可用代理指标。但今天，当你可以同时运行多个智能体时，很多技能会变得更重要，杠杆也更大。单维度等级表无法描述多智能体协作能力。

我看到的几乎所有自治争论，都会混在一起讨论两个本该拆开的问题：我们允许这个单个智能体独立走多远？我们协调多个智能体的能力有多强？

为了分别表达这两个维度，可以使用两条轴：自主执行能力和编排能力。

在自主执行能力这条轴上，低端是提出候选动作，然后等待人做决定。

中间位置意味着智能体在处理一个特定任务，但会限定自己的操作范围，并持续回报它做了什么以及对应证据，这样你还能继续引导它。

在高自主执行能力一端，智能体围绕一个目标工作，尝试、学习、测试、寻找解法，遇到阻塞会提问，也会尝试不同路径，并把这些工作以证据形式带回来。

在编排轴上，低端是一个智能体、一个线程。中间位置是多个智能体，各自在自己的 worktree，也就是独立工作目录里工作，可能朝不同目标推进，并且相互隔离。高端则是一个编排器，可以接收 backlog、issue tracker、日程或其他任务队列，把它们转成持续工作流；你只需要在失败时介入，也就是“例外管理”：平时系统自己推进，只在失败或需要决策时让人介入。已经体现这些想法的产品和能力包括：

• Claude Code 的 /plan、/goal、/loop、/background、/batch、/code-review、/security-review 模式，子智能体、钩子、检查点、智能体委派和管理实践、后台会话、智能体团队模式、/schedule 参数
• Codex 的本地/云端线程、Goal mode、worktree、Automations、子智能体、review pane、GitHub code review、钩子、沙箱、Auto-review 和 rerun

这些能力无法放进一张单维度等级表里。

1. 攀登：三个时代和一个栈

如果从下往上读这个等级表，你会把自主执行能力和编排能力想象成同时攀升。实际效果上，这六个等级代表我们都会经历的三个阶段：

第一，你坐在驾驶位上，智能体主要提供帮助，等待你来转向。

第二，智能体接管一个有边界的任务或目标，但你仍在附近引导并验证它的工作。

第三，在编排时代，系统能够运转全局，把工作分发给多个智能体，而你主要在出问题时介入，也就是“例外管理”。

这样看会更简单，因为等级表上的垂直位置正好覆盖了两条轴；编排能力只在接近顶部时出现。它看起来像一次稳定的逐级攀登，而这次攀登本身，也是我们正在经历的变化。

工程工作里状态好的那一天，通常会触碰好几个等级，有时更多。执行一个任务时，在几个阶段之间来回切换很正常。

2. 六个等级

2.1 Level 0：辅助

智能体提出建议，这些建议多数不错，很多时候甚至完美，但是否足够好、能否执行，始终由你决定。可以想象 autocomplete、行内编辑建议，或者在聊天会话里围绕某个还没人真正接手的改动展开讨论。它适合错误代价高、变更很小，或者你还在形成自己判断的时候。验证主要发生在本地。

2.2 Level 1：受监督执行

智能体代表你编辑或运行命令，在执行任何有后果的动作前先征求许可。这是大多数人的默认姿态。它可以发生在本地沙箱里，在应用变更前逐项审批；每次审批都是一次独立验证，用来确认这次变更可以应用。它也可以发生在交互式会话里。失败模式是审批疲劳：所有审批看起来都一样，哪怕它们要批准的内容完全不同。你可能会快速扫一眼 diff，套用一些启发式规则，找另一个人确认，或者干脆让智能体承担责任。Codex Auto-review 把边界条件的最终审批委派给另一个 reviewer agent，可以缓解这个问题。

2.3 Level 2：有边界的任务委派

把一个有边界的任务交给智能体。这个任务有明确目标、约束，以及“完成”的工作定义。你会待在附近，可以随时打断，但多数时候不参与。这是当下软件工程世界的重心。验证开始不能只依赖你本人，因为你也需要休息和睡觉；它会转向智能体能够产出的证据：自动化测试通过、类型正确、lint 建议、截图、复现步骤、基于示例的来源说明等。

2.4 Level 3：目标驱动自治

智能体会采取必要动作来达成目标，只在某个条件满足时停止。在 prompt 模式里，提示词本身就是目标，比如“能不能把这个页面的 time-to-interactive 降到 1 秒以内？”在 Codex 里，这就是 Goal mode：智能体会在 plan -> act -> test -> review 之间循环，直到不再满足成功条件。在 Claude Code 里，对应的是 /goal、/loop 和 /schedule 命令。要让这个等级有用，停止条件必须能以可自动化的方式衡量。

不要让智能体处理含糊的目标，比如“整体提升用户体验”或“让代码库更可测试”。选择具体、可衡量、可自动化的目标：找出静态分析漏掉的生产 bug，降低加载时间，确保 TypeScript 严格构建且没有显式 any，筛查所有依赖，只保留我们理解并能通过测试的依赖。最后，如果要找生产 bug，智能体需要处在接近生产的环境里。

2.5 Level 4：并行委派

跨多个智能体并行工作。每个智能体负责任务中一个相互隔离的切片。这个等级最大的瓶颈是拆解：定义哪些切片适合委派。可用支撑包括子智能体、后台会话、/batch、worktree、智能体团队等。失败模式是假并行：让许多智能体同时处理重叠切片，结果没有得到更多工作，只得到合并冲突和重复决策。要做好这件事，智能体需要相互隔离，各自拥有自己的文件、状态和审查队列。每个智能体都会带来成本，按并行运行的智能体数量消耗 token。对人来说，前几个智能体之后，再加一个智能体的编排成本会迅速上升。

2.6 Level 5：例外管理式编排

定义成功是什么，以及适用哪些策略。管理型智能体会基于触发条件醒来，例如新 issue、新任务或时钟；它会分派 worker agent，监控进展，验证输出，失败时重试，在满足条件时升级给更强的智能体或人类，汇总结果，最后把工作产物（例如 PR）和证据返回到外部系统。可以把它想象成工厂：issue tracker 或 backlog 是输入，工厂产出的产品是输出，也就是许多已经修复的问题和 bug。智能体运行在适当隔离、有足够边界的环境中；必要时也有逃生口。这座工厂该做什么，由管理型智能体定义的“操作系统”来约束。

这个操作系统的设计仍由人负责。OpenAI 为 Symphony 提出过一个规范^[2]，中心是一块 Linear 看板：每个 issue 都有自己的智能体工作区，智能体持续确保自己朝着工作区内 spec 文件定义的目标推进。人工 review 可以围绕生成出来的证据进行。编排世界里更强的做法，是构建持续运行的智能体工厂，里面有数百甚至数千个智能体。走到这个高度，独立验证会变得更重要：实现者和 reviewer 分离，测试运行器和 QA 分离，安全检查分离，验收流程门禁分离。

3. 风险和可逆性决定上限

我记得读过 Anthropic 早期关于 Claude Code 最难任务的一项研究^[3]，里面提到 Claude Code 请求澄清的次数，是用户打断次数的两倍多。经验用户（约 750 次会话，相比不足 50 次的用户）更可能自动批准，也更可能在盯着进度时打断它。

他们还做过更广泛的 Claude Code 使用分析^[4]。样本大约是 2025 年 10 月到 2026 年 4 月之间，来自约 23.5 万人的 40 万次会话。每次会话里都可以推断出用户做出的决策，比如每个 prompt 请求多少个动作、哪些动作选择自动批准、打断频率如何。人类做了约 70% 的规划决策，而 Claude 完成了约 80% 的执行。高自治仍然需要人在循环中，只是人的工作从执行每一步，转向决定下一步应该往哪里走。

如果要判断一个大型 AI 系统是否处在高自治状态，应该问三个问题：

• 多快能知道它做错了？
• 多干净地撤销它做过的事？
• 什么证据能证明它做对了？

如果三个答案分别是：没法很快知道、撤销非常困难、只能相信总结，那它就不是高自治。

每次运行智能体之前，都应该有一份契约，定义它要做什么。

目标：要达成的结果，避免把活动或技术手段当成目标。

范围：在哪个领域操作，允许使用哪些技术。

非目标：哪些内容不属于目标。

工具和权限：智能体如何与外部世界互操作。

停止条件：什么时候停止，最好是可衡量变量。

证据：可以确认事情已经完成的具体测试、截图、日志、数据库记录或其他指标，并且这些证据应独立于智能体。

升级：什么情况下让谁介入，包括由谁运行这个智能体。

预算：这项任务最多投入多少时间、精力和 token。token 是大模型的预算；也可以包括尝试次数上限和并行度上限。

4. 指标让自治稍微可靠一点

事后再决定指标通常不够。指标最好提前写进一份简洁文档。这样自治更可靠，迈出信任那一步也更容易。

衡量成功有很多方法。每个自治等级都可以追踪一组指标：

• 平均干预间隔
• 最长的、无人值守且产出被接受的成功运行时间
• 在沙箱内运行的动作占比，相比需要升级权限的动作占比
• 自动批准动作和被拒绝动作的比例
• 每条人类指令对应的平均智能体动作数
• 澄清请求率和打断请求率
• 每个被接受变更的 review 时间
• 每个置信等级上的返工率
• 每个置信等级上的缺陷逃逸率
• 每个被接受变更的 token 成本

这些指标能讲出一个故事：一个由人持续交接、始终忙碌的单智能体，只是带 dashboard 的 Level 4。一个保守的智能体，如果没有自动化入口、重试机制和足够证据就不愿推进，那才是带真实门禁的 Level 5。

5. 思考就绪度

按风险和可撤销性给工作分类。保守地应用自治，只在支持更高等级的证据累积起来之后再上升。一个有强测试保护、有 reviewer agent 且具备干净回滚路径的支付引擎重构，可以支持比文档自动化任务更高的自治等级，尤其当后者缺少任何权威事实来源时。自治等级应该跟随验证过程，而不是跟随任务名称。

6. 四种反模式

任何系统都很容易落入这四种自治反模式。

自治当身份：智能体的自治评分变成无意义的身份徽章。更高自治被当成能力证明，而不是安全证明，导致智能体运行得超过验证能力。应该赞赏和奖励那些选择正确自治等级、没有越过验证边界的人。

权限洗白：审批疲劳会迫使我们给 AI 智能体和工具过宽的访问权限。边界要收紧，例如沙箱 profile、限定可写根目录、命令白名单、钩子和 Auto-review。

总结替代：用智能体的工作总结替代 review，默认总结已经足够。应该像完全人工 review 一样打包同一套证据包，包括 diff、测试、日志、截图、reviewer 发现、风险和缺口，避免看了总结就放弃审查。

假装有一支智能体舰队：几十个智能体并行运行，但人仍在手工编排每个依赖。共享状态、所有权规则和依赖追踪，可以逐步降低手工协调需求。更小的 WIP 限制会迫使团队把注意力放在编码化、文档化那些协调步骤上，直到编排可以自动化。

7. 校准练习

回顾最近十个你用智能体辅助完成的任务。对每个任务记录实际使用的自治等级、涉及的风险、工作有多容易撤销、为了满足验证要求产出了哪些证据、review 时间、是否需要返工，以及下次再做类似任务时，这个自治等级是否仍然合适。

8. 如何安全攀升

一次只沿一条轴上升。先从一个受监督的单智能体开始，让它处理一个有边界的任务，并产出可以辩护的成功证据；如果做得足够规整，这就是自治 Level 1。然后逐步沿三个正交方向扩展。把读多写少的探索任务并行化，也就是自治 Level 4。加入写入型智能体，让它们在不同 worktree 中工作，并约束文件所有权规则，也是 Level 4。再加入周期性自动化任务，然后基于 issue、语音等输入做智能体主导的编排。每向上走一步，都要补一套新的安全机制，因为会出现新的失败模式。

把这些失败模式命名：更长的单智能体运行可能导致漂移、上下文腐烂、沟通遗漏或目标偏移。后台工作可能导致假设过期和交接脆弱。过多并行工作可能导致合并冲突或重复决策。过多周期性自动化任务可能导致静默 token 消耗或提示词过期。例外管理可能导致审查队列过长和告警疲劳。解决办法是缩小范围、拿出能独立检查的证据、提供更便宜的回滚路径、加固门禁，并定义更清晰的所有权规则，不是单纯提高信任强度。

使用自治等级：

• Level 0 最适合精细工作，以及判断仍在形成时。
• Level 1 最适合大多数探索工作，前提是工作发生在已充分理解的边界附近。
• Level 2 最适合大多数有边界的任务，但要知道它可能存在未知依赖和意外问题。
• Level 3 最适合成功条件能足够清楚表达的场景。
• Level 4 最适合工作可以围绕这些成功条件干净拆分的场景。
• Level 5 最适合跨多个成功条件所需的协调和沟通已经完全编码化之后。

验证永远会是瓶颈。

尽管当前充满豪言壮语，工具也在快速发展，工程团队与 AI 智能体协作时的成熟姿态仍然是校准过的自治。

在不久的将来，我们会希望设计出知道何时工作、何时验证、何时提问的循环。但工程师的能力仍然体现在两件事上：选择正确的自治等级，构建模式和可辩护的证据，防止自治滑向阴暗角落。

注：Pangram 将本文标记为 100% 人类撰写：https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26^[5]