Addy Osmani 上周发表了一篇文章《Agentic Autonomy Levels》，讨论 Agent 在工程实践中该如何分配自主权。借着这篇文章，我们也可以重新看看：Agent 到底应该怎么用，才更稳、更可控。
现在聊 Agent，重点正在从“怎么写提示词”转向“怎么安排它工作”。在 Claude Code、Codex 这类 Coding Agent 中，goal、loop、后台会话、subagent、hook、沙箱、审批机制，正在逐渐变成真实的产品能力。Agent 不再只是接收指令并返回结果，它正在进入更完整的工作流。
这时，问题也随之出现：一个任务该给 Agent 多大自主权？什么时候需要人审批？什么样的验证方式，才能支撑它继续往下做？
《Agentic Autonomy Levels》提到的“Agent 自主等级”就在回答这个问题：控制风险的任务得低自主性，边界清楚、可验证、可并行的大规模任务则需要更高的自主性。往前一步，现在前沿的形态中出现了一个像“调度员”一样的 manager agent：负责拆解任务、分派 subagent、检查结果，并把真正需要人判断的部分交回来。
但是，Agent 真的需要这样一个“调度员”吗？
Agent 信任程度
目前引用最多的量表是 Steve Yegge 在《Welcome to Gas Town》一文中提出的单轴阶梯，The Pragmatic Engineer 也提到过。它会给你一个数字，衡量你对单个 Agent 的信任程度：
但现在，当你能同时跑多个 Agent 时，协调多 Agent 的技能本身也就变得越来越重要，单个 Agent 的信任度不足以衡量"多 Agent 能力"。
Osmani 认为几乎所有关于 Agent 自主性的讨论都混淆了两个应该分开的问题：
-
我们让单个 Agent 离开自己视线多远?
-
我们协调多个 Agent 的能力如何?
因此，他用两个维度来拆解上面的问题：agency（自主行动力）和 orchestration（编排能力）。
-
agency 轴：低级 Agent 是“提出候选方案，等人决定”，中间是“在限定范围内干活，不断汇报证据，方便你随时纠偏”，高级 Agent 是“朝着一个目标自己去尝试、实验、学习、测试、卡住了会提问，最后把过程连同证据一起交回来”。
-
orchestration 轴：低端编排方式是一个 Agent、一条线程，中间是若干个 Agent 各自在独立的 worktree 里干活，可能目标不同但相互隔离，高端编排方式是编排器能把 backlog、issue tracker、日程表等队列变成持续不断的工作流，人只要处理例外情况。
目前，这些能力能在现有的 Coding 产品中找到对应：Claude Code 的 /plan、/goal、/loop、/background、/batch、/code-review、/security-review、subagent、hook、checkpoint、后台会话、/schedule 等；Codex 的本地 / 云端线程、Goal 模式、worktree、Automations、subagent 、审查面板、GitHub 代码审查、hook、沙箱、Auto-review、rerun 等。
六个 Agent 自主等级
如果把这六个等级拆开看，会发现它其实同时在讲两件事：一是单个 Agent 能自己做多少事，二是系统能不能调度多个 Agent 一起工作。
-
低等级阶段，人仍然坐在驾驶位，Agent 更像一个助手，主要负责补充、建议和执行局部操作。
-
中间等级，Agent 开始接手一个边界清楚的任务。你可以给它一个目标，让它自己推进几轮，但人仍然需要通过测试、diff、日志等方式来确认结果。
-
高级阶段，就会进入多 Agent 编排的阶段。系统可以像一个小型“工厂”一样，把任务拆开，分派给不同的 Agent，再由管理者智能体检查结果、处理异常，最后把真正需要人判断的部分交回来。
所以，这六个等级看起来是一条从低到高的阶梯，背后其实包含两种能力的提升：Agent 自己干活的能力，以及系统调度多个 Agent 的能力。
但这仍然是一次真实的转变，一天正常的工程工作里，你可能会在这几个阶段之间来回切换好几次。
六个等级详解
Level 0：辅助
在这个等级，Agent 主要负责给建议。它的建议可能会很有用，甚至接近完美，但是由你决定是否最终采纳。
它的典型场景包括自动补全、行内编辑建议，或者在一个未明确具体任务的聊天会话里，和 Agent 讨论某个改动该怎么做。
这种模式适合错误代价很高、改动范围很小，或是你还没有一个明确判断的时候。在本地完成基础验证，再由人把关。
Level 1：受监督的操作
在这个等级，Agent 可以代你编辑文件或执行命令，但在做影响的操作前，它会先征求你的许可。
这也是现在大多数人使用 Agent 的默认方式：在本地沙箱里操作，每一步关键动作都要审批；或者在交互式会话里，让 Agent 一边做，你一边 review。
这个等级，常见的问题是“审批疲劳”。尤其是每一次申请看起来都差不多，我们很容易开始机械地点通过。
缓解的方法包括：认真检查 diff，设置一些审批规则，请别人复核关键改动，或是把一部分审查工作交给另一个 Agent。Codex 的 Auto-review，就是让一个独立的审查 Agent 来处理边界情况，把最终审批工作从人手里分担出去。
Level 2：限定范围的任务委托
到了这个等级，你就可以把一个边界清晰的任务完全交给 Agent。这个任务要有明确的目标、约束条件，以及“怎么样算完成”的判断标准。
你可以仍然在旁边监工，随时打断 Agent，但大多数时候不需要一直参与其中。这也是目前软件工程中最常见、最实用的 Agent 使用方式。
在这个阶段，验证重点开始发生变化：逐渐从“人亲自看每一步”转向“Agent 能不能拿出足够的证据”。
这些证据可以是通过的测试、正确的类型检查、lint 结果、截图、复现步骤，或者可追溯的示例。也就是说 Agent 不能只告诉你“我做完了”，还要能证明它做对了。
Level 3：目标驱动
在这个等级，Agent 不再只是完成一个单步任务，而是围绕一个目标持续尝试，直到满足某个条件再停止。
对于普通提示词，只要目标足够明确，它也可以充当一次小型 /goal。像是“把这个页面的可交互时间降到 1 秒以内。”Agent 就会围绕这个指标尝试优化，并用性能数据判断是否达标。
对应到 Codex 就是 Goal 模式：Agent 会反复执行“计划、行动、测试、审查”，直到成功标准不再被满足。在 Claude Code 里，也可以通过 /goal、/loop、/schedule 等命令实现类似功能。
但要让这个等级要发挥好有一个前提：停止条件必须能被自动衡量。
“提升用户体验”“让代码库更好测试”这类无法量化的目标不应该直接丢给 Agent。反之，一些具体、可衡量、可验证的目标，比如：找出静态分析发现不了的生产环境 bug；降低页面加载时间；确保项目能通过严格的 TypeScript 构建，并且没有显式的 any；梳理依赖，只保留能理解、能通过测试的部分…
此外，如果目标是要发现生产环境问题，Agent 也得运行在接近生产环境的上下文里。环境不够真实，结果也很难可靠。
Level 4：并行委托
这个等级开始，会引入多个 Agent 并行工作。每个 Agent 负责一个相对独立的任务切片，同时推进不同部分。
这里最大的难点是“怎么拆”。任务切片如果拆得不好，多个 Agent 看似并行，实际可能在处理重叠问题，最后带来合并冲突、重复决策和额外返工。
支持这种模式的能力包括 subagent、后台会话、/batch、worktree、agent team 等。它们的共同点是让不同 Agent 能在相对隔离的环境里工作。
要让并行委托真正有效，每个 Agent 最好有独立的文件范围、状态空间和审查队列。否则，Agent 数量越多，冲突和协调成本也会变高。
这里还要注意两个成本：一个是 token 成本，每增加一个 Agent，都会增加额外消耗；另一个是人的“编排税”，也就是拆任务、看结果、合并产出的管理成本。当 Agent 数量超过一定规模，继续增加 Agent 的边际收益可能会下降。
Level 5：按例外管理的编排
这是更进一步的形态。
在这个等级里，人先定义好“成功”是什么样，以及系统应该遵循哪些策略。接着，Manager Agent 会在特定条件下被唤醒，比如出现新 issue、新任务，或者到达预设时间。
它会负责派发工作 Agent，监控进度，核验产出，失败后重试；必要时，把问题升级给能力更强的 Agent 或交还给人处理。最后，它会把成果和证据交给外部系统，比如生成 PR，并附上测试结果、变更说明和审查记录。
把它想象成一座 Agent 工厂：issue tracker 或 backlog 是输入，工厂的产出是一批被修复的问题、一组完成的任务，或者一系列可审查的 PR。在这座工厂里，Agent 需要在隔离良好的环境中工作，有足够清晰的边界和保护机制，必要时也要有人工介入的出口。至于这座工厂该处理什么、怎么运转，则由 Manager Agent 背后的“操作系统”来决定。
这个“操作系统”的设计，依旧需要人来实现。OpenAI 曾提出过一个叫 Symphony 的方案，它以 Linear 看板为核心：每个 issue 都有自己的 Agent 工作区，Agent 会持续检查自己是否在朝着工作区中 spec 文件定义的目标推进。
在人类审查这件事上，比较理想的方式是：在 Agent 产生证据的层级进行审查。人不用回到每一步操作里重新盯一遍，而是基于测试、日志、diff、截图、复现路径等证据来判断结果是否可信。
这个方向目前的前沿形态是搭建能够持续运行成百上千个 Agent 的“Agent 工厂”。到了这一步，独立验证会变得尤其重要：实现者和审查者要分开，测试执行和 QA 要分开，安全检查要分开，最终验收也需要单独把关。
自主性的天花板
Anthropic 早前有一项研究数据：在 Claude Code 处理的一批超难任务中， Agent 请求澄清的次数，超过了用户打断次数的两倍。换句话说，很多中断并不是用户主动拦下来的，而是 Agent 觉得信息不够，需要先问清楚。
但经验丰富的用户会更愿意放手。相比使用不到 50 个会话的新用户，使用过约 750 个会话的老用户更倾向于自动批准，让 Agent 先推进，再通过打断来控制方向。
Anthropic 另一项更大范围的分析覆盖了 2025 年 10 月到 2026 年 4 月约 23.5 万人的约 40 万个会话。数据显示：人类做出约 70% 的规划决策，而 Claude 完成约 80% 的执行工作。高自主性不是把人排除在外，而是把人从"每一步都要做"变成"只需要决定接下来的方向"。
判断一个系统是否具备"高自主性"，可以问三个问题：
-
我们能多快发现自己判断错了它在做什么?
-
撤销它做的事能有多干净?
-
什么能证明我们对它所做的事的判断是对的?
如果这三个问题的答案都是"不快""很难""只能信它给的摘要"，那就算不上高自主性。
Agent 运行契约
-
目标：我们想达成什么（是一个结果，不是一个活动，也不是技术手段）
-
范围：在什么领域内操作，允许用什么技术手段
-
非目标：哪些不属于这次目标
-
工具和权限： Agent 能以何种方式与外界交互
-
停止条件：什么时候停下来，理想情况下是可衡量的变量
-
证据：能独立于 Agent 本身、用来确认工作已完成的具体测试、截图、日志、数据库记录等
-
升级机制：在什么情况下该由谁介入（包括谁在运行这个 Agent）
-
预算：允许花费的时间、精力和 token 上限（token 是大模型的预算，也可以包含尝试次数上限和并行度上限）
自主性可靠性的来源
事后诸葛没用，指标应该提前写进一份简明的文档里，这样自主性会显得更可靠，迈出这一步的"信任跳跃"也会容易一些。可以考虑针对每个自主等级追踪这些指标：平均干预间隔时间、最长的无人值守成功运行时长、沙箱内动作与升级动作的占比、自动批准与被拒绝动作的比例、每条人类指令对应的 Agent 动作数、澄清请求率、打断请求率、每次被接受改动的审查耗时、各置信等级下的返工率、各置信等级下的缺陷逃逸率、每次被接受改动的 token 成本。
这些指标能讲出不一样的故事：一个靠人不断交接、维持忙碌状态的单一 Agent ，是“带仪表盘的 Level 4”；一个不见到自动化输入、重试和过硬证据就不肯往前走的保守 Agent ，才是“带真正闸门的 Level 5”。
按风险和"事情有多容易撤销"给工作分类。自主性要保守地使用，只有在支撑更高等级的证据不断积累时才往上提。一个有强测试覆盖、审查 Agent 把关、回滚路径干净的支付引擎的重构，可以有比一个缺乏权威真相来源的文档自动化任务高得多的自主性。自主等级应该跟随验证过程走，而不是跟着任务的名字走。
四个常见误区
-
把自主性当身份象征：自主等级变成一个没有意义的“面子标签”，高自主性被当作能力的证明，而不是安全性的证明，结果 Agent 被跑得比验证能力支撑的更猛。解法：表彰、奖励那些把自主等级定得恰到好处、坚决不越界的人。
-
权限洗白：审批疲劳带来的暴政，导致给 Agent 和工具的权限远远超出实际需要。解法：更好的边界设计，比如沙箱配置、限定的可写根目录、命令白名单、hook、Auto-review。
-
用摘要代替审查：默认 Agent 自己写的工作摘要就足够当作审查依据。解法：像做纯人工审查一样准备同一份证据包（diff、测试、日志、截图、审查发现、风险、缺口等），避免认知投降。
-
假装编排：表面上跑了几十个并行 Agent ，实际上每个依赖关系仍然由人手工协调。解法：共享状态、明确的归属规则、更好的依赖追踪，逐步减少手动协调的必要；更小的在制品（WIP）限额能倒逼团队把协调步骤真正编码和文档化，直到编排本身能自动完成。
如何提升 Agent 等级
一次只在一个轴上往上走。先从单个受监督的 Agent 、单个有边界的任务开始，产出经得起检验的成功证据（如果足够整洁，这就是 Level 1）。然后沿着三个方向逐步扩展：把偏读的探索类任务并行化（Level 4）；让写入类 Agent 在各自独立的 worktree 里工作，并设定明确的文件归属规则（Level 4）；再加入周期性自动化任务，进而基于 issue、语音等触发的 Agent 编排。每往上走一级，都需要一套新的安全机制，因为会出现新的失败模式：
-
单个 Agent 运行时间过长，容易出现漂移、上下文腐化、沟通中断或偏离目标。
-
后台工作容易导致假设过时、交接不到位。
-
并行过度容易导致合并冲突或重复决策。
-
周期性任务过多容易导致 token 悄悄超支或提示词过时。
-
按例外管理的编排容易导致审查队列积压、警报疲劳。
应对方式是收窄范围、拿到更好的证据、降低回滚成本、加固闸门、明确归属规则。
各等级的适用场景：
-
Level 0：适合精细活儿，或者你的判断力还在形成阶段。
-
Level 1：适合大多数探索类工作，尤其是接近"已被充分理解"边界的工作。
-
Level 2：适合大多数有边界的任务，即便可能存在未知依赖和意外情况。
-
Level 3：适合能把"成功"讲清楚的场景。
-
Level 4：适合能按这些成功条件干净拆分的工作。
-
Level 5：适合各个成功条件之间所需的协调和沟通已经被完全编码的场景。
验证很重要
尽管现在有不少虚张声势和工具炒作，一个和 AI Agent 一起工作的成熟工程团队，应有的姿态是校准过的自主性（calibrated autonomy）。在不久的将来，我们会去设计"知道何时该干活、何时该验证、何时该问人"的循环——但工程师真正的功夫，仍然在于选对自主等级，以及构建能守住这些"暗角"的模式和站得住脚的证据。
