中文精炼导读
核心观点
- Addy Osmani 提出"agentic 自主级别"框架：围绕 agentic engineering 的讨论已从"提示"（prompting）转向"运营"（operating），而几乎所有自主性辩论都把两个应分离的问题混为一谈——"我们让单个 agent 离开自己多远"与"我们协调多个 agent 的技能如何"；为此他引入两个正交的轴：agency（能动性）与 orchestration（编排）。
- agency 轴：低端是"提出候选动作、等待决策"；中端是"agent 在特定任务上工作、但限定它的行为、并不断用证据回报以便你持续操控"；高端是"agent 朝着目标工作、实验、学习、测试、找解法、被阻塞、提问、尝试不同方法，并把所有这些工作作为证据返回"。
- orchestration 轴：低端是一个 agent、一个线程；中端是几个 agent、各在自己的 worktree 里、可能朝向不同目标但互相隔离；高端是"orchestrator 能把积压工作、issue tracker、日程或其他队列变成持续工作，你只在失败时才介入"——"按例外管理"。
- 六个级别：Level 0 Assist（agent 提出大多很好甚至完美的建议、你总决定是否采纳，用于昂贵错误、微小改动或还在形成判断时）；Level 1 Supervised action（agent 替你编辑/运行命令、执行重大事项前询问，是多数人的默认姿态，失败模式是"批准疲劳"）；Level 2 Scoped task delegation（把有明确目标、约束与完成定义的边界任务交给 agent，你保持近距离可打断，是软件工程界的重心）；Level 3 Goal-driven autonomy（agent 为达成目标做任何事、只在某条件满足时停止，前提是停止条件可测量且可自动化）；Level 4 Parallel delegation（许多 agent 并行、各自处理任务的隔离切片，最大瓶颈是分解）；Level 5 Managed-by-exception orchestration（定义成功与策略，manager agent 按触发醒来、派遣 worker、监控进度、验证输出、失败重试、升级、聚合结果，把 PR 与证据交付外部系统——"工厂"）。
- 安全爬升的方法是"一次只沿一个轴向上"：从一个监督的、做单个界定任务并产生可辩护成功证据的 agent 开始，再沿三个正交方向逐步扩展（并行化只读探索、在约束文件所有权规则下增加写 agent、增加定期自动化、再 agent 主导编排）；每上一级杠杆都需要一套新的安全机制并给它们命名（长单 agent 运行的漂移/上下文腐坏、后台工作的过时假设、过多并行的合并冲突、过多定期工作的静默 token 消耗、按例外管理带来的长评审队列与告警疲劳）。
- 关键结论：验证永远是瓶颈；成熟的工程团队姿态是"校准过的自主性"（calibrated autonomy）——工程师的技能仍在于为每个任务选择正确的自主级别、并构建模式与可辩护的证据来防范它的黑暗角落。
内容精讲
文章开篇描述前沿景象：软件工厂、目标、循环、后台会话、子代理、钩子、沙箱、agent 审批 agent……对未来的许多创造者而言，这些行为将自发布第一天就内建进产品（Claude Code 与 Codex 直接展示了这种转变）。从工程师视角，你会用低自主度来限制风险、增加可逆性，用高自主度做明确的活动，以及"并行 agent 舰队安全地重构大型代码库"。关于每个动作的核心问题永远是："这个任务配得上什么级别，什么验证能让那个级别可辩护？"前沿的边缘是"manager agent"——被触发时醒来、委派给助手、持续验证它们的输出、只把必须由人做的决定带回来；用这种设置的人可能已经在运行数百上千个 agent、大多在常青代码库上。
作者指出最常见的参考是 Steve Yegge 的单轴阶梯（《Welcome to Gas Town》与 The Pragmatic Engineer 中提及），它给你一个数字衡量你对单个 agent 的信任。但 2026 年初工作开始从委派转向编排时，单轴阶梯仍是不错的衡量风险的代理；今天许多技能在"能同时跑多个 agent"时才增加意义与杠杆，单根横档无法定位多 agent 技能。因此几乎所有自主性辩论都混淆了两个问题：单个 agent 离你多远，以及你协调多个 agent 的技能。为了分别捕捉这两个维度，作者用两个轴。
"攀登：三个时代与单一栈"解释了六级的整体结构。如果自下而上读阶梯，你其实同时在攀登 agency 与 orchestration。六个级别代表我们都会经过的三个时代：第一，你在驾驶座、agent 大多只是帮忙、等你操控；第二，agent 接管一个有边界的任务或目标、但你仍在场操控并验证；第三，编排时代——系统能运行整场演出、把工作分派到许多 agent、你大多只在出问题时介入（按例外管理）。这让事情简化：阶梯的垂直位置恰当地捕捉了两个轴（编排只在接近顶部时出现），让它成为一次稳定的攀登。不过攀登仍是大家正在经历的转变的一部分——一个不错的工程日会触及好几根横档，在任务过程中切换时代很正常。
六个级别的详细描述是文章主体。Level 0 Assist：agent 的建议大多很好甚至完美，但你总是决定它们是否好到可以行动——自动补全、内联编辑建议、或挂在聊天会话里讨论一个还没人认领的变更；用于昂贵错误、微小改动或还在形成判断时；验证大多在本地进行。Level 1 Supervised action：agent 替你编辑或运行命令、执行任何重要动作前询问你——这是多数人的默认姿态；可以在本地沙箱里做、应用变更前需批准（每次批准都是"变更可应用"的独立验证）、或在交互会话里做；失败模式是批准疲劳——所有批准看起来都一样，不管批准的是什么；解法可能是眯眼看 diff、遵循启发式、批准前与人确认、或干脆同意让 agent 负责；Codex Auto-review 用把边界条件的最终批准委派给独立评审 agent 来解决这个问题。Level 2 Scoped task delegation：把有边界任务交给 agent，任务有清晰目标、约束与"完成"的工作定义；你保持近距离可打断、但基本不参与；这是软件工程界的重心；验证从你（你可能需要休息与睡觉）移向 agent 能产生的证据——通过的自动测试、正确的类型、lint 建议、截图、复现步骤、示例溯源等。Level 3 Goal-driven autonomy：agent 为达成目标做任何事、只在某条件满足时停止；在 prompt 模式里 prompt 本身成为目标（如"能把页面 time-to-interactive 降到 1 秒以下吗"）；在 Codex 里是 Goal 模式（agent 循环 plan→act→test→review 直到不再满足成功标准），在 Claude Code 里是 /goal、/loop、/schedule；要让这级有用，停止条件必须能以可自动化的方式测量——别让 agent 帮忙实现"普遍改善用户体验"这类含糊的毛绒目标，要选具体、可测量、可自动化的（在生产里找静态分析漏掉的 bug、降低加载时间、保证严格的 TypeScript 构建无显式 any、分诊所有依赖只保留我们理解且通过测试的）；而要在生产里找 bug，agent 需要处在类生产环境。Level 4 Parallel delegation：在多个 agent 间并行工作，每个处理任务的隔离切片；这一级的最大瓶颈是分解——定义要委派的正确切片；支撑包括子代理、后台会话、/batch、worktrees、agent 团队；失败模式是"伪并行"——对重叠切片同时跑多个 agent，得到的不是更多工作而是合并冲突与重复决策；要做好，agent 必须彼此隔离、各自拥有自己的文件与状态、各自有评审队列；每个 agent 都会消耗与同时运行数量成正比的 token；在人这边，编排税让添加 agent 的边际成本在几个之后上升。Level 5 Managed-by-exception orchestration：定义成功的样子与应适用的策略；manager agent 基于触发（新 issue、新任务、时钟）醒来、派遣 worker agent、监控进度、验证输出、失败重试、条件满足时升级到更有能力的 agent 或人类、聚合结果、最终把工作产品（如 PR）与证据交付外部系统——想成工厂：issue tracker 或积压是输入、工厂的产品是输出（许多修好的 issue 与 bug）；agent 在适当隔离、带很多墙（必要时有逃生舱）的环境里工作，只有由 manager agent 定义的操作系统规定工厂应做什么；操作系统的设计留给人类——OpenAI 为 Symphony 提出了规范：Linear 看板在中心，每个 issue 有自己的 agent 工作区、agent 持续确保它朝着自己工作区中 spec 文件定义的目标前进；人类评审可以在证据产生的高度进行，但前沿（编排世界里最强大的）是构建"持续 agent 工厂"。
"如何安全爬升"给出了具体路径：一次沿一个轴向上。从一个受监督的、做单一界定任务、产生可辩护成功证据的 agent 开始（如 tidy 的话是自主级别 1）；然后沿三个正交方向逐步扩展：并行化只读探索类任务（级别 4）、在约束文件所有权规则下在分离 worktree 上加写 agent（级别 4）、加定期自动化、再基于 issue/语音等做 agent 主导的编排。每上一级杠杆都需要一套新的安全机制（以及新的失败模式），要给它们命名：更长的单 agent 运行可能导致漂移、上下文腐坏、通信丢失或目标偏离；后台工作可能导致过时假设与薄弱交接；过多并行可能导致合并冲突或重复决策；过多定期工作可能导致静默 token 消耗或过时 prompt；按例外管理可能导致长评审队列与告警疲劳。修复方式不是"更努力地信任"，而是收窄范围、确保更好的证据、启用更便宜的滚回路径、加固门、定义更清晰的所有权规则。各级适用场景总结：Level 0 最适合精细工作与判断仍在形成时；Level 1 最适合多数探索（若工作接近被充分理解的边界）；Level 2 最适合多数有界任务（知道可能有未知依赖与意外坑）；Level 3 最适合成功条件能足够清晰陈述时；Level 4 最适合工作能按这些成功条件干净拆分时；Level 5 最适合跨各种成功条件所需的协调与通信被完全编码之后。
文章以"验证永远是瓶颈"收尾：尽管有当下的豪言与工具，使用 AI agent 的工程团队的成熟姿态是"校准过的自主性"。在近期未来，我们会想设计"知道何时工作、何时验证、何时询问"的循环——但工程师的技能仍在于为每个任务选择正确的自主级别、并构建模式与可辩护的证据来防范它的黑暗角落。
阅读价值
适合工程管理者、agent 平台设计者与所有在用或计划用 agent 做实际工作的开发者：这篇框架文把"agent 该给多少自主权"从直觉变成可操作的六级别模型，并用 agency/orchestration 双轴拆解了单轴阶梯的局限；每级都给出适用场景、支撑工具、失败模式与安全机制，附录式的"如何安全爬升"路径尤其实用。
本文为中文精炼导读,由 AI 基于原文整理,内容与图片版权归原作者所有。原文: https://addyosmani.com/blog/agentic-autonomy-levels/