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。在不久的将来我们会去设计知道何时该干活、何时该验证、何时该问人的循环——但工程师真正的功夫仍然在于选对自主等级以及构建能守住这些暗角的模式和站得住脚的证据。
