Agent自主权六级模型与任务适配

在大多数关于智能体工程的讨论中，关注点已经从提示转向了运行。前沿仍笼罩在迷雾中，但我们已经能看到这些事物：软件工厂、目标、循环、后台会话、子智能体、钩子、沙箱，以及负责审批其他智能体的智能体。对于许多未来的创造者来说，这种行为从产品诞生的第一天起就会内置其中：Claude Code 和 Codex 直接展现了这一转变。

从工程师的角度看，你会使用较低的自主性来限制风险、提高可逆性，但会对明确的活动采用更高的自主性，也会让并行运行的智能体集群安全地重构庞大的代码库。针对一项操作，核心问题始终是：这个任务应当采用什么级别？什么样的验证能够证明采用这一等级是合理的？

前沿的最尖端是管理者智能体：它会在触发条件满足时唤醒，将任务委派给辅助智能体，同时持续验证它们的输出，最终只把那些必须由人类作出的决策带回来。采用这类配置的人，实际上可能已经在运行数百乃至数千个智能体，而且大多是在持续演进的代码库上运行。和几乎所有关于自主性的思考一样，每个人对这种规模的感知依然不同。

最常被提及的分级体系，是 Steve Yegge 在《Welcome to Gas Town》和 The Pragmatic Engineer 中提到的单轴阶梯。如果你想用一个数字表示自己在多大程度上是 AI 原生的，它是一个不错的参考：只要你清楚自己对单个智能体的信任程度，这套阶梯就能给出一个衡量数字。下面是它的一个版本：

2026 年初，即便工作模式已经开始从委派转向编排，这套分级仍然是衡量风险的一个相当不错的替代指标。但如今，当你能够同时运行多个智能体时，许多技能的重要性和杠杆效应可能都会提高。单独一个阶梯层级无法体现多智能体技能。

实际上，我见过的几乎所有关于自主性的争论，都把两个本应分开的问题混为一谈：我们允许单个智能体离开我们独立行动多远？我们协调多个智能体的能力又如何？

为了分别描述这两个维度，我们将使用两条轴：自主行动能力和编排能力。

在自主行动能力轴上，低端意味着智能体只提出候选操作，然后等待决定。

中端意味着智能体正在处理某个特定任务，但会限定自己的操作范围，并持续汇报它做了什么，同时提供证据，让你能够继续引导它。

在自主行动能力的高端，智能体会朝着一个目标工作：实验、学习、测试、寻找解决问题的方法；遇到阻碍、提出问题、尝试不同方案；最终带着所有这些工作的证据返回。

在编排能力轴上，低端意味着一个智能体、一条线程。中端意味着你拥有多个智能体，每个都在自己的 worktree 中工作；它们可能朝着不同目标前进，但彼此隔离。在高端，你拥有一个编排器，它能够接收待办列表、问题跟踪器、日程或其他队列，将其转化为持续进行的工作；只有在出现失败时，你才需要介入，也就是“例外管理”。体现这些理念的产品和功能包括：

Claude Code 的 /plan、/goal、/loop、/background、/batch、/code-review、/security-review 模式，子智能体、钩子、检查点、智能体委派与管理实践、后台会话、智能体团队模式，以及 /schedule 参数

Codex 的本地/云端线程、Goal 模式、worktree、Automations、子智能体、审查面板、GitHub 代码审查、钩子、沙箱、Auto-review 和重新运行

这些能力无法被放进一条单一的阶梯中。

攀登：三个时代与一套统一阶梯

如果你从下往上阅读这套阶梯，你想象的是同时提升自主行动能力和编排能力。实际上，这六个级别代表了我们所有人都会经历的三个不同时代：

首先，你坐在驾驶席上，智能体主要只是提供帮助，等待你来引导它。

其次，智能体开始负责一个有明确边界的任务或目标，但你仍然在场，负责引导并验证它所做的工作。

第三，在编排时代，系统已经有能力主持全局，将工作分派给多个智能体；你主要只需在出现问题时介入，也就是“例外管理”。

这样一来，事情就变得更简单了，因为阶梯上的纵向位置能够整齐地涵盖这两条轴——编排只会在接近顶部时出现——从而使其成为沿着各个层级稳步向上的单一攀登过程。尽管如此，这场攀登仍然是我们所有人正在经历的一次转变的一部分。

充实的工程工作日通常会涉及多个层级，有时甚至更多：在完成一个任务的过程中，数次切换所处的时代是很正常的。

六个级别详解

智能体提出的建议大多不错，而且往往十分完美，但你始终需要决定这些建议是否好到足以付诸行动。可以把它理解为自动补全、行内编辑建议，或者待在聊天会话里讨论一项尚未有人负责的变更。它适用于错误代价高昂、变更极小，或你仍在形成自己判断的情况。验证主要在本地进行。

Level 1：受监督的操作

智能体代你编辑内容或运行命令，并在执行任何会产生重要影响的操作之前征求你的许可。这是大多数人的默认模式。它可以在本地沙箱中完成，在应用变更之前请求批准——每一次批准都是一次独立验证，用于确认该变更可以安全应用——也可以在交互式会话中完成。其失败模式是审批疲劳：无论审批的内容是什么，所有审批看起来都一样。你可能会通过眯着眼查看 diff、遵循一些启发式规则、在批准前向另一个人确认，或者直接同意让智能体承担责任来解决这一问题。Codex Auto-review 通过把边界条件的最终审批委派给一个独立的审查智能体来解决这个问题。

Level 2：限定范围的任务委派

把一个边界明确的任务交给智能体。这个任务会有清晰的目标、约束，以及一套可实际执行的完成标准。你会留在附近，可以随时中断，但大多数时候不会参与其中。这是软件工程领域当前的重心。验证工作正在从你身上转移——你可能需要休息和睡觉——转向智能体能够提供的证据：自动化测试通过、类型正确、lint 建议、截图、复现步骤、示例形式的来源证明，等等。

Level 3：目标驱动的自主性

智能体会采取一切必要措施来实现目标，只有在满足某个条件时才会停止。在提示模式下，这意味着提示本身成为目标，例如：“你能把这个页面的可交互时间降到 1 秒以内吗？”在 Codex 中，这就是 Goal 模式：智能体会在 plan->act->test->review 步骤之间循环，直到它不再满足继续执行的成功判据。在 Claude Code 中，对应的是 /goal、/loop 和 /schedule 命令。要让这个级别真正有用，停止条件必须能够以自动化方式进行度量。

不要让智能体帮助完成“整体改善用户体验”或“让代码库更容易测试”这类模糊、含混的目标。应选择具体、可衡量且可自动化的目标：发现静态分析无法捕获的生产环境缺陷；缩短加载时间；确保严格的 TypeScript 构建能够通过，并且不存在显式的 any；梳理所有依赖，只保留那些我们理解且能够通过测试的依赖；等等。最后，要想发现生产环境中的缺陷，智能体需要处于一个类似生产环境的环境中。

Level 4：并行委派

让多个智能体并行开展工作。每个智能体负责任务中一个相互隔离的部分。这个级别最大的瓶颈是任务拆解：确定适合委派的正确任务切片。相关支持包括：子智能体、后台会话、/batch、worktree、智能体团队等。其失败模式是虚假并行：同时让多个智能体处理彼此重叠的任务切片，结果非但没有完成更多工作，反而产生了合并冲突和重复决策。要做好这一点，智能体之间必须彼此隔离，每个智能体都要独自负责自己的文件和状态。每个智能体还需要拥有自己的审查队列。最后，每个智能体都会产生与同时运行的智能体数量成比例的成本，也就是消耗的 token。对人类而言，编排成本会让新增智能体的边际成本在达到一定数量后逐渐上升。

Level 5：例外管理式编排

定义成功的标准，以及应当适用哪些策略。管理 AI 智能体会根据触发条件（例如新 issue、新任务、定时器）唤醒，调度工作 AI 智能体、监控其进度、验证输出、失败时重试，并在满足特定条件时升级给能力更强的 AI 智能体或人类处理；它还会汇总结果，最终将工作成果（例如 PR）和证据返回给外部系统。可以把它想象成一座工厂：issue 跟踪器或待办列表是输入，工厂的产物是输出（例如大量已修复的 issue 和 bug）。AI 智能体在适当隔离、设有重重边界（必要时也有逃生通道）的环境中工作，而只有由管理 AI 智能体定义的操作系统，才会规定这座工厂应该做什么。

这个操作系统的设计仍由人类负责；OpenAI 提出了一份 Symphony 规范，其核心是一块 Linear 看板：每个 issue 都有自己的 AI 智能体工作区，AI 智能体会持续确保自己正朝着目标推进，而该目标由其工作区中的规范文件定义。人类可以在证据生成的层级上进行审查，但当前前沿方向（即编排领域中能力最强的做法）是构建拥有数百甚至数千个 AI 智能体的持续运行型 AI 智能体工厂。攀升到这一阶段后，独立验证变得愈发重要：实现者与审查者相互独立，测试运行者与 QA 相互独立，安全检查相互独立，验收也设有独立的流程关卡。

风险和可逆性决定了上限。

我记得读过 Anthropic 早期的一项研究，其中分析了一些使用 Claude Code 完成的最困难任务。研究发现，Claude Code 请求澄清的次数，是用户中断次数的两倍以上。经验丰富的用户（约 750 次会话，而经验较少的用户不足 50 次）更倾向于自动批准操作，同时密切关注进度并在必要时中断。

他们还对人们如何使用 Claude Code 进行了更广泛的分析。他们研究了 2025 年 10 月至 2026 年 4 月期间，约 23.5 万名用户产生的约 40 万次会话。通过每次会话，他们能够分析用户做出的各种决策，例如每条提示词要求执行多少项操作、选择自动批准其中哪些操作，以及多频繁地中断等。人类做出了约 70% 的规划决策，而 Claude 完成了约 80% 的执行工作。高自主性并不意味着把人排除在决策闭环之外，而是让人从亲自完成每一步，转变为决定下一步应该朝哪个方向前进。

如果想判断一个大型 AI 系统是否正在以高自主性运行，我们应该提出以下三个问题：

我们多快能发现它正在做的事情是错的？

我们能多干净利落地撤销它正在做的事情？

什么证据能够证明它正在做的事情是正确的？

如果这三个问题的答案分别是：不能很快发现、撤销极其困难、只能相信它的总结，那么这就不是高自主性。

AI 智能体每次运行之前，都应该先制定一份契约，定义它试图完成什么。

目标：我们试图实现什么（不是一项活动，也不是所采用的技术，而是一个结果）。

范围：我们在哪个领域内操作，以及允许使用哪些技术。

非目标：哪些内容不属于目标的一部分。

工具和权限：AI 智能体可以如何与外部世界交互。停止条件：何时停止；理想情况下，应由一个可度量的变量决定。

证据：可用于确认某件事已经完成的具体测试、截图、日志、数据库记录或其他指标（且独立于 AI 智能体本身）。

升级机制：在什么情况下需要谁介入（包括由谁运行 AI 智能体）。

以及预算：投入该任务的时间、精力和 token 上限（token 是大型 AI 模型的预算——还可以限制它尝试执行任务的次数，以及并行程度）。

指标让自主性更可靠一点

事后再决定采用什么指标，可能还不够。可以提前在一份简洁的文档中设定指标。这会让自主性显得更加可靠，也会让这种信任上的跃迁更容易迈出一点。

虽然衡量成功的方法有很多，但可以考虑为每个自主性级别跟踪以下指标的某种版本：

平均干预间隔时间

无人值守且工作成果获得验收的最长成功运行时间

在沙箱中执行的操作与升级处理的操作所占比例

自动批准与拒绝的操作百分比

每条人类指令对应的 AI 智能体平均操作次数

澄清请求率

中断请求率

每项已接受变更的审查时间

各置信度级别的返工率

各置信度级别的缺陷逃逸率

每项已接受变更的 token 成本

这些指标可以揭示真实情况：一个依靠人类不断交接任务才能保持忙碌的单个 AI 智能体，只不过是带着仪表盘的第 4 级。一个不愿贸然行动，必须具备自动化任务接入、重试机制和充分证据才会继续的保守型 AI 智能体，才是拥有真正关卡的第 5 级。

思考就绪程度

根据风险以及工作的可撤销难度对任务进行分类。保守地应用自主性，只有在支持更高级别的证据不断积累后，才逐步提升自主性。一个受到强大测试保护、由审查 AI 智能体监督且拥有清晰回滚路径的支付引擎重构，可以支持比缺乏任何权威事实来源的文档自动化任务高得多的自主性。自主性级别应该取决于验证流程，而不是任务名称。

如果不保持警惕，任何系统都很容易陷入以下四种自主性反模式。

将自主性视为地位——AI 智能体的自主性评级沦为毫无意义的身份徽章。更高的自主性被视为能力的证明，而不是安全性的证明，导致 AI 智能体的运行强度超出验证机制所能支持的范围。解决方法：认可并奖励那些选择正确自主性级别，并始终避免越界的人。

权限洗白——审批疲劳的压迫促使我们向 AI 智能体和工具授予远超实际需要的访问权限。解决方法：更完善的边界始终有效，例如沙箱配置文件、限定范围的可写根目录、命令白名单、钩子以及自动审查。

用总结替代审查——用 AI 智能体的工作总结替代实际审查，假定总结已经足够。解决方法：提供与完全人工审查相同的证据包（diff、测试、日志、截图、审查者发现的问题、风险、缺口等），同时避免放弃独立判断。

舰队角色扮演——数十个 AI 智能体并行运行，但仍由人类手动编排每一项依赖关系。解决方法：通过共享状态、所有权规则和更完善的依赖项跟踪，逐步减少手动协调的需求。更小的在制品（WIP）限制会迫使团队专注于编码和记录协作步骤，直到编排实现自动化。

一项校准练习

回顾你最近在 AI 智能体协助下完成的十项任务。针对每项任务，记录采用的自主性级别、涉及的风险、工作是否容易撤销、为满足验证要求而生成的证据、审查耗时、是否需要返工，以及下一次是否仍适合采用同样的自主性级别。

每次只沿一个轴提升。首先，让一个受监督的 AI 智能体完成一项范围明确的任务，并生成足以令人信服的成功证据（如果足够规范，这属于自主性第 1 级）。然后，逐步沿三个相互正交的方向扩展。将以读取为主的探索任务并行化（自主性第 4 级）。增加写入型 AI 智能体，让它们在不同的 worktree 中工作，并受到严格的文件所有权规则约束（自主性第 4 级）。加入周期性自动化，然后再加入基于 issue、语音等输入，由 AI 智能体主导的编排。杠杆每提升一步，都需要一套新的安全机制（以应对新的故障模式等）。

明确指出这些风险：更长时间的单 AI 智能体运行可能导致偏离方向、上下文腐化、遗漏沟通或目标跑偏。后台工作可能导致假设过时和交接薄弱。过多并行工作可能导致合并冲突或重复决策。过多周期性工作可能导致 token 在无声中消耗，或提示词逐渐过时。按异常管理可能导致审查队列过长和告警疲劳。解决方法不是更用力地信任，而是缩小范围、确保更充分的证据、提供成本更低的回滚路径、强化关卡，并定义更清晰的所有权规则。

按以下方式使用自主性级别：

第 0 级最适合精细敏感的工作，以及判断仍在形成的阶段。

第 1 级最适合大多数探索性工作，前提是工作范围接近已得到充分理解的边界。

第 2 级最适合大多数边界明确的任务，同时要认识到其中可能存在未知依赖和意料之外的陷阱。

第 3 级最适合能够足够清晰地陈述成功条件的场景。

第 4 级最适合能够围绕这些成功条件干净拆分的工作。

第 5 级最适合各项成功条件之间所需的协调与沟通已经得到完整编码的场景。

验证永远都会是瓶颈。

尽管当下存在种种豪言壮语，也已经拥有各种工具，但工程团队与 AI 智能体协作时，真正成熟的姿态是经过校准的自主性。

在不远的未来，我们希望设计出懂得何时工作、何时验证、何时提问的循环 —— 但工程师的技能仍然在于选择合适的自主程度，以及构建防御性模式和证据来防范其黑暗面。

注：Pangram 标注本文为 100% 人工编写：https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26