# Agentic Autonomy Levels
**作者**: Addy Osmani
**日期**: 2026-07-03T03:29:34.000Z
**来源**: [https://x.com/addyosmani/status/2072885435312042327](https://x.com/addyosmani/status/2072885435312042327)
---
In most conversations about agentic engineering, the action has changed from prompting to operating. Here's a frontier looking into the fog: software factories, goals, loops, background sessions, subagents, hooks, sandboxes, agent-approving agents. For many creators of the future, this behavior will be baked into products day-1: Claude Code and Codex expose the shift directly.
From the engineer standpoint, you'll use low autonomy to limit risk and increase reversibility, but use higher autonomy for explicit activities, and fleets of parallel agents safely refactoring massive codebases. The core question about an action is always: what level does this task deserve, and what verification makes that level defensible?
The edge of the frontier is the manager agent that wakes on its trigger, delegating to its helpers while continuously verifying their output, and returning with only the decisions that must be made by a human. Folks using this kind of setup may indeed already be running hundreds or thousands of agents, largely on evergreen codebases. Like most all thinking about autonomy, how you perceive the scale is still different for everyone.
The scale most often mentioned is from Steve Yegge's single-axis ladder mentioned in "Welcome to Gas Town" and in The Pragmatic Engineer. It's a good reference if you want a number that tells you how AI-native you are: the ladder gives you a single number to measure if you know your trust in a single agent. Here's one version of it:
In early 2026, even while work began to shift from delegation to orchesration, this was a fairly good proxy for measuring risk. Today, however, many skill sets may have increased significance and leverage when you can run many agents at once. A single rung cannot help you place multi-agent skill.
Instead, almost every autonomy debate I've seen conflates two questions that should be separated: how far away from yourself are we letting this single agent go, and what is our skill at coordinating many agents?
To capture these two dimensions separately, we'll use two axes: agency and orchestration.
On the agency axis, low includes suggesting candidate actions and waiting for a decision.
Mid means that the agent is working on a particular task, but scopes what it does, and constantly reports back what it does along with evidence, so you can keep steering it.
At the high agency end, the agent is working towards a goal, experimenting, learning, testing, finding ways to solve a problem, getting blocked, asking questions, trying different approaches, and returns all of this work in evidence.
On the orchestration axis, low means one agent, one thread. At mid, you've got several agents, each working in its own worktree, possibly working towards different goals, but isolated. At the high end, you've got an orchestrator that can take a backlog, issue tracker, schedule, or other queue, and turn it into continuous work, and you only need to step in when things fail: "management by exception." Products and features incorporating these ideas include:
- Claude Code's /plan, /goal, /loop, /background, /batch, /code-review, /security-review modes, subagents, hooks, checkpointing, agent delegation and management practices, background sessions, agent-team patterns, /schedule arguments
- Codex's local/cloud threads, Goal mode, worktrees, Automations, subagents, review panes, GitHub code review, hooks, sandboxing, Auto-review, and rerun
These capabilities don't fit onto a single ladder.
## The climb: three eras and a single stack
If you read the ladder bottom-up, you're imagining climbing both agency and orchestration at the same time. In effect, the six levels represent three separate eras that we all pass through:
First, you're in the driver's seat, and an agent mostly just helps, waiting for you to steer it.
Second, the agent takes charge of a bounded task or goal, but you're still around to steer it and verify what it does.
And third, in the era of orchestration, the system is capable of running the show, dispatching work across many agents, and you mostly need to step in when things go wrong: "management by exception."
This makes things simpler, because the vertical position on the ladder neatly captures the two axes (orchestration only kicks in near the top), leaving it as a single steady climb through the rungs. And yet, the climb is still part of a shift that we're all going through.
A good day doing engineering includes touching several rungs, sometimes more: it's normal to switch between the eras a few times in the course of a task.
## The six levels in detail
Level 0: Assist
The agent makes suggestions that are mostly good and often perfect, but you will always decide whether they're good enough to act on. Think autocomplete, inline edit suggestions, or hanging around in a chat session discussing a change that nobody has taken ownership of yet. Use for costly errors, tiny changes, or when you're forming your own judgment. Verification mostly takes place locally.
Level 1: Supervised action
The agent edits or runs commands on your behalf, asking you before executing anything consequential. This is the default posture for most people. It can be done in local sandbox with approvals before applying changes - where each approval is an independent verification that the change is okay to apply - or in an interactive session. Failure mode is approval fatigue; all approvals feel the same regardless of what they're approving. You might solve this by squinting at the diff, following some heuristics, checking in with another person before approving, or just agreeing to let the agent be responsible. Codex Auto-review solves this problem by delegating the final approval of boundary conditions to a separate reviewer agent.
Level 2: Scoped task delegation
Hand off a bounded task to the agent. That task will have a clear goal, constraints, and a working definition of what done looks like. You'll stay nearby, able to interrupt, but mostly not involved. This is the center of gravity in the software engineering world. Verification is shifting away from you (you may need to rest and sleep) towards evidence that the agent can produce: passing automated tests, proper types, lint suggestions, screenshots, repro steps, provenance by example, etc.
Level 3: Goal-driven autonomy
The agent does whatever it takes to achieve a goal, stopping only when some condition is met. In prompt mode, this means the prompt itself becomes the goal (e.g., "Can you reduce this page's time-to-interactive below 1 second?"). In Codex, this is Goal mode: the agent cycles through plan->act->test->review steps until it stops meeting success criteria. In Claude Code, it's the /goal, /loop, and /schedule commands. For this level to be useful, the stopping condition must be measurable in a way that can be automated.
Don't ask your agent to help with vague, wooly goals like improving user experience in general" or "make the codebase more testable." Pick something specific, measurable, and automated: find bugs in production that elude static analysis, reduce load time, ensure that we have a strict TypeScript build with no explicit anys, triage all dependencies to keep just those that we understand and which pass our tests, etc. And, finally, to find bugs in production, the agent will need to be in a production-like environment.
Level 4: Parallel delegation
Work across many agents in parallel. Each agent works on an isolated slice of the task. The biggest bottleneck at this level is decomposition: defining the right slices to delegate. Supports include: subagents, background sessions, /batch, worktrees, agent teams, etc. Failure mode is false parallelism: running many agents against overlapping slices at once, so instead of more work you get merge conflicts and duplicated decisions. To do this well, agents need to be isolated from one another, each owning their own files and status. Each needs to have its own review queue, as well. And finally, each agent incurs a cost - in terms of tokens consumed - proportional to the number of agents running at the same time. On the human side, orchestration tax makes the marginal cost of adding an agent go up after a few.
Level 5: Managed-by-exception orchestration
Define what success looks like, and which policies should apply. A manager agent will wake up based on triggers (e.g. new issue, new task, clock), dispatch worker agents, monitor their progress, verify output, retry on failure, escalate to more competent agents or humans when conditions are met, aggregate results, and ultimately return work products (e.g. PRs) and evidence to external systems. Think factory: the issue tracker or backlog is the input, and the product of the factory is the output (i.e. many fixed issues, bugs). Agents work in an appropriately isolated environment with lots of walls (and if needed, escape hatches), and only an operating system - defined by the manager agent - defines what the factory is expected to do.
The design of this operating system is left to the human; OpenAI has proposed a spec for Symphony which has a Linear board at the center: each issue gets its own agent workspace, and the agent continuously ensures that it is making progress towards its goal as defined in a spec file in its own workspace. Human review can be done at the altitude where evidence is generated, but the frontier (i.e. what is most powerful in the orchestration world) is to build continuous agent factories with hundreds or even thousands of agents. At this point in the climb, it becomes increasingly important to have independent verification: separate implementers and reviewers, separate test runners and QA, separate security checks, separate process gates for acceptance.
## Risk and reversibility set the ceiling.
I remember reading an earlier Anthropic study on some of the hardest tasks with Claude Code where it asked for clarification more than twice as often as users interrupted. Experienced users (~750 sessions vs under 50) were more likely to auto-approve and interrupt keeping an eye on the progress.
They also did a lot of broader analysis of how people use Claude Code. They looked at ~400K sessions from ~235K people between October 2025 and April 2026. From each session they could figure out the decisions someone makes like how many actions they ask for in each prompt, which of these they choose to auto-approve, how often they interrupt etc. People make ~70% of the planning decisions, but Claude does ~80% of the execution. High autonomy is not about leaving people out of the loop, but moving from having them do every step to having them decide which direction to go next.
If we want to determine whether a large AI system is operating with high autonomy, the three questions we should be asking are:
- How quickly will we know we're wrong about what it's doing?
- How cleanly can we undo what it's doing?
- What would prove we're right about what it's doing?
If the answer to all three is: not quickly, at great difficulty, and trusting the summary, it's not high autonomy.
Every run of an agent should be preceded by a contract that defines what it's trying to do.
The goal: what we're trying to achieve (not an activity, not the technique, but an outcome).
The scope: what domain we're operating in, and what techniques are allowed.
Non-goals: what isn't part of the objective.
Tools and permissions: how the agent can interoperate with the world. Stopping condition: when to stop; ideally, a measurable variable.
Evidence: specific tests, screenshots, logs, database records or other indicators that can be used to confirm something has been done (independent of the agent).
Escalation: who gets involved in what circumstances (including who runs the agent).
And budget: a limit on how much time, effort and tokens are to be devoted to the task (tokens are the budget of large AI models - you can also include a limit on the number of times it can attempt the task and a limit on the degree of parallelism).
## Metrics make autonomy just a little more reliable
Deciding on metric after-the-fact is probably not enough. Metrics can be put in place in advance, in a concise doc. And that makes autonomy feel more reliable and makes the leap of faith just a little easier to take.
While there are many ways to measure success, considering tracking some version of these metrics for each level of autonomy:
- Mean time between interventions
- Longest successful unattended run with accepted work
- Share of actions run in the sandbox vs escalated
- Percentage of actions auto-approved vs rejected
- Mean number of agent actions per human instruction
- Clarification request rate Interrupt request rate
- Review time per accepted change
- Rework rate on each level of confidence
- Defect escape rate on each level of confidence
- Token cost per accepted change
Such metrics can tell a story: a single agent kept busy by human handoffs is Level 4 with a dashboard. A conservative agent, unwilling to proceed without automated intake, retries, and decent evidence, is Level 5 with a real gate.
## Think about readiness
Classify work by risk and by how easily it can be undone. Apply autonomy conservatively, rising only as evidence supporting the higher level accumulates. A payment engine refactor protected by strong tests and reviewer agents with a clean rollback path can support much higher autonomy than a documentation automation task lacking any canonical truth. The autonomy level should follow the verification process, not the task name.
## Four anti-patterns
Every system can easily fall prey to these four autonomy anti-patterns unless vigilantly avoided.
Autonomy as status - an agent's autonomy rating becomes a meaningless badge of status. Higher autonomy is treated as proof of capability, not of safety, and agents are run hotter than verification supports. Fix: Praise and reward those who settle on the correct level of autonomy and relentlessly avoid overstepping.
Permission laundering - the tyranny of approval fatigue leads us to grant AI agents and tools wildly broader access than necessary. Fix: Better boundaries are always a fix, such as sandbox profiles, scoped writable roots, allowlisted commands, hooks, and Auto-review.
Summary substitution - the agent's work summary substitutes for review, assuming the summary is sufficient. Fix: Bundle the same evidence packet as with fully manual reviews (a diff, tests, logs, screenshots, reviewer findings, risks, gaps, etc.) while avoiding cognitive surrender.
Fleet cosplay - dozens of agents run in parallel, but a human persists in orchestrating every dependency manually. Fix: Shared state, ownership rules, and better dependency tracking gradually reduce the need to coordinate manually. Smaller WIP limits force a focus on encoding and documenting the coordinated steps until orchestration becomes automated.
A calibration exercise
Review the last ten tasks you undertook with agent assistance. For each task, record the autonomy level exercised, the risk involved, how easily the work could be undone, the evidence produced to meet verification requirements, the review time, if any rework was needed, and whether the autonomy level chosen would still be a fit next time.
How to climb safely
Move up one axis at a time. Start with a single supervised agent to do a single scoped task that produces defensible evidence of success (an autonomy level 1, if tidy enough). Then gradually expand in the three orthogonal directions. Parallelize read-heavy exploration tasks (autonomy level 4). Add write agents acting on separate worktrees with constrained file ownership rules (autonomy level 4). Add recurring automations, then agent-led orchestration based on issues, voice, etc. Every step up the lever requires a new set of safety mechanisms (such as new failure modes).
Name them: Longer single-agent runs can lead to drift, context rot, dropped communication, or strayed objectives. Background work can lead to stale assumptions and weak handoffs. Too much parallel work can lead to merge conflicts or duplicated decisions. Too much recurring work can lead to silent token spend or stale prompts. Managed by exception can lead to long review queues and alert fatigue. Fix not trusting harder; instead, narrow scope, ensure better evidence, enable cheaper rollback paths, harden gates, and define clearer ownership rules.
Use the autonomy level:
- Level 0 is best for delicate work and when judgment is still being formed.
- Level 1 is best for most exploration, if the work is done close to the boundaries of what is well-understood.
- Level 2 is best for most bounded tasks, knowing there may be unknown depends and unforeseen gotchas.
- Level 3 is best where the success conditions can be stated with sufficient clarity.
- Level 4 is best when the work can be cleanly split across these success conditions.
- Level 5 is best once the coordination and communication needed across the various success conditions is fully encoded.
Verification will always be the bottleneck.
Despite current bravado and current tooling, the mature posture of an engineering team working with AI agents is calibrated autonomy.
The bottlenecks are coordination, verification, maintenance, product judgment and incident learning
In the near future, we'll want to design loops that know when to work, when to verify, and when to ask - but the skill of the engineer will still lie in choosing the right level of autonomy and in building patterns and defensible evidence that guard against its darker corners.
Note: Pangram labels this article as 100% human-written: https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26
## 相关链接
- [Addy Osmani](https://x.com/addyosmani)
- [@addyosmani](https://x.com/addyosmani)
- [30K](https://x.com/addyosmani/status/2072885435312042327/analytics)
- [Welcome to Gas Town](https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04)
- [spec](https://openai.com/index/open-source-codex-orchestration-symphony/)
- [Anthropic study](https://www.anthropic.com/research/measuring-agent-autonomy)
- [analysis](https://www.anthropic.com/research/claude-code-expertise)
- [https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26](https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:29 AM · Jul 3, 2026](https://x.com/addyosmani/status/2072885435312042327)
- [30.7K Views](https://x.com/addyosmani/status/2072885435312042327/analytics)
- [View quotes](https://x.com/addyosmani/status/2072885435312042327/quotes)
---
*导出时间: 2026/7/3 18:01:06*
---
## 中文翻译
# 智能体自主性级别
**作者**: Addy Osmani
**日期**: 2026-07-03T03:29:34.000Z
**来源**: [https://x.com/addyosmani/status/2072885435312042327](https://x.com/addyosmani/status/2072885435312042327)
---
在大多数关于智能体工程的讨论中，操作方式已经从提示词转向了运行调度。这里有一幅望向迷雾的前沿图景：软件工厂、目标、循环、后台会话、子智能体、钩子、沙箱、审批智能体的智能体。对于许多未来的创造者来说，这些行为从第一天起就会内置到产品中：Claude Code 和 Codex 直接展现了这一转变。
从工程师的角度来看，你会使用低自主性来限制风险并提高可逆性，但对明确的活动使用更高的自主性，以及让成群的并行智能体安全地重构大型代码库。关于某个行动的核心问题永远是：这个任务值得什么级别的自主性，以及什么样的验证能让这个级别站得住脚？
前沿的尖端是管理智能体：它被触发后自动醒来，将任务委派给它的助手，同时持续验证它们的输出，并只带回必须由人类做出的决策。使用这类配置的人可能确实已经在运行成百上千个智能体，主要是在常青代码库上。和大多数关于自主性的思考一样，每个人对这种规模的感知仍然不同。
最常被提及的量表是 Steve Yegge 在"Welcome to Gas Town"和 The Pragmatic Engineer 中提到的单轴阶梯。如果你想要一个数字来衡量你的 AI 原生程度，这是一个很好的参考：只要你知道自己对单个智能体的信任程度，这个阶梯就能给你一个单一的数字来度量。以下是其中一个版本：
在 2026 年初，即使工作重心开始从委派转向编排，这仍是衡量风险的相当不错的代理指标。然而今天，当你能够同时运行多个智能体时，许多技能可能具有了更大的重要性和杠杆作用。单一的梯级无法帮助你定位多智能体技能。
相反，我见过的几乎所有关于自主性的争论都混淆了两个本应分开的问题：我们允许这个单个智能体离自己走多远，以及我们在协调多个智能体方面的技能如何？
为了分别捕捉这两个维度，我们将使用两个轴：代理性和编排。
在代理性轴上，低级包括提出候选行动方案并等待决策。
中级意味着智能体正在处理某个特定任务，但会限定它所做的事情的范围，并持续汇报它的进展及证据，以便你能够继续引导它。
在高级代理性一端，智能体朝着一个目标努力，进行实验、学习、测试，寻找解决问题的方法，遇到阻碍时提问，尝试不同的方法，并带着所有这些工作的证据返回。
在编排轴上，低级意味着一个智能体、一个线程。在中级，你有多个智能体，每个都在自己的工作树中工作，可能朝着不同的目标努力，但彼此隔离。在高级一端，你有一个编排器，它可以接收待办事项、问题追踪器、日程表或其他队列，并将其转化为持续的工作，而你只需要在出现故障时介入：“异常管理”。融合了这些理念的产品和功能包括：
- Claude Code 的 /plan、/goal、/loop、/background、/batch、/code-review、/security-review 模式，子智能体，钩子，检查点，智能体委派与管理实践，后台会话，智能体团队模式，/schedule 参数
- Codex 的本地/云端线程，Goal 模式，工作树，Automations，子智能体，审查面板，GitHub 代码审查，钩子，沙箱，Auto-review，以及重新运行
这些能力无法放在一个单一的阶梯上。
## 攀登：三个时代与一个单一阶梯
如果你自下而上阅读这个阶梯，你是在想象同时攀登代理性和编排两个维度。实际上，这六个级别代表了我们都会经历的三个不同时代：
第一，你坐在驾驶座上，智能体大多只是提供帮助，等待你来引导它。
第二，智能体负责一个有边界的任务或目标，但你仍然在旁边引导它并验证它所做的事情。
第三，在编排时代，系统能够主持全局，将工作分发给许多智能体，而你大多只需在出错时介入：“异常管理。”
这让事情变得简单，因为阶梯上的纵向位置恰好涵盖了两个轴（编排只在接近顶部时才起作用），使其成为沿着梯级的单次稳定攀登。然而，这次攀登仍然是我们所有人正在经历的一个转变的一部分。
做好工程工作的一天通常涉及跨越几个梯级，有时甚至更多：在一项任务的过程中，在不同时代之间切换几次是很正常的。
## 六个级别详解
级别 0：辅助
智能体提出的建议大多不错且往往完美，但是否好到可以付诸行动，始终由你决定。想想自动补全、内联编辑建议，或者在一个聊天会话中围绕一项还没有人认领的变更进行讨论。适用于代价高昂的错误、微小的改动，或者当你正在形成自己的判断时。验证主要在本地进行。
级别 1：受监督的行动
代理会代替你编辑代码或执行命令，但在执行任何重要操作之前都会先征询你的意见。这是大多数人的默认姿态。它可以在本地沙箱中进行，应用更改前需要批准——每次批准都是对更改是否可以应用的一次独立验证——也可以在交互式会话中进行。其失败模式是"批准疲劳"；无论批准的是什么内容，所有的批准看起来都一样。你可能通过眯着眼睛看 diff、遵循某些启发式规则、在批准前咨询他人、或者干脆同意让代理自行负责来解决这个问题。Codex Auto-review 通过将边界条件的最终批准委托给一个独立的审查代理来解决这个问题。
Level 2：范围受限的任务委派
把一个有边界的任务交给代理。该任务会有明确的目标、约束条件，以及对"完成"的可操作定义。你会待在附近，能够随时打断，但基本上不参与其中。这是软件工程领域的重心所在。验证正在从你身上转移（你可能需要休息和睡觉），转向代理能够产出的证据：通过的自动化测试、正确的类型、lint 建议、截图、复现步骤、示例式的出处证明等。
Level 3：目标驱动的自主性
代理为达成目标而竭尽所能，直到满足某个条件才停止。在提示模式下，这意味着提示本身成为目标（例如："你能把这个页面的可交互时间降到 1 秒以下吗？"）。在 Codex 中，这是 Goal 模式：代理循环执行"计划->执行->测试->审查"步骤，直到不再满足成功标准。在 Claude Code 中，对应的命令是 /goal、/loop 和 /schedule。要让这一层级发挥作用，停止条件必须是可以自动化衡量的。
不要让代理帮助实现模糊、空泛的目标，比如"总体上改善用户体验"或"让代码库更易于测试"。要选择具体的、可衡量的、可自动化的目标：找出静态分析无法发现的生产环境 bug、缩短加载时间、确保我们有一个不允许显式 any 的严格 TypeScript 构建、对所有依赖项进行分类，只保留我们理解且能通过测试的那些，等等。最后，要在生产环境中查找 bug，代理需要处于类生产环境中。
Level 4：并行委派
跨多个代理并行工作。每个代理处理任务的一个隔离切片。这一层级最大的瓶颈是分解：定义正确的委派切片。支持手段包括：子代理、后台会话、/batch、worktrees、代理团队等。其失败模式是"伪并行"：让许多代理同时处理重叠的切片，结果不是获得更多工作产出，而是得到合并冲突和重复决策。要做好这一点，代理之间需要彼此隔离，各自拥有自己的文件和状态。每个代理也需要有自己的审查队列。最后，每个代理都会产生成本——以消耗的 token 计——与同时运行的代理数量成正比。在人类这边，编排税会让增加代理的边际成本在几个之后不断上升。
Level 5：异常管理式编排
定义成功是什么样的，以及应该适用哪些策略。一个管理者代理会根据触发条件（例如新 issue、新任务、时钟）被唤醒，调度工作者代理，监控它们的进度，验证输出，失败时重试，在条件满足时升级给更胜任的代理或人类，汇总结果，并最终将工作成果（例如 PR）和证据返回给外部系统。可以把它想象成工厂：issue 跟踪器或待办事项列表是输入，工厂的产品是输出（即大量已修复的问题和 bug）。代理在适当隔离的环境中工作，环境中有许多围墙（并在需要时设有逃生舱口），而只有一套操作系统——由管理者代理定义——规定工厂应该做什么。
这套操作系统的设计权留给人类；OpenAI 为 Symphony 提出了一个规范，其核心是一个 Linear 看板：每个 issue 都有自己的代理工作区，代理持续确保自己正朝着其工作区中某个规范文件所定义的目标前进。人类审查可以在证据产生的层面上进行，但前沿（即编排领域最强大的做法）是构建拥有数百甚至数千个代理的持续运转的代理工厂。在这个攀登阶段，拥有独立验证变得越来越重要：分离的实现者和审查者、分离的测试运行器和 QA、分离的安全检查、分离的验收流程关卡。
## 风险和可逆性决定了上限。
我记得读过 Anthropic 早前一项关于用 Claude Code 完成一些最难任务的研究，其中 Claude 请求澄清的次数是用户打断次数的两倍多。经验丰富的用户（约 750 次会话，相比之下不到 50 次）更倾向于自动批准，并在留意进度的同时进行打断。
他们还对人们如何使用 Claude Code 做了大量更广泛的分析。他们研究了 2025 年 10 月至 2026 年 4 月间约 23.5 万人的约 40 万次会话。从每次会话中，他们可以分析出某人做出的决策，比如每个提示中要求执行多少个操作、选择自动批准其中哪些、打断的频率等。人类做出约 70% 的规划决策，而 Claude 完成约 80% 的执行。高度自主并不是把人排除在循环之外，而是从让人执行每一步，转变为让人决定下一步该往哪个方向走。
如果我们想判断一个大型 AI 系统是否在高度自主地运行，我们应该问的三个问题是：
- 我们多快能发现自己对它正在做的事情判断错了？
- 我们能多干净地撤销它正在做的事情？
- 有什么能证明我们对它正在做的事情的判断是对的？
如果这三个问题的答案都是：不能快速完成、非常困难、只能信任摘要，那就不是高自主性。
每次运行智能体之前，都应该先签订一份契约，明确它要做什么。
目标：我们要实现什么（不是活动，不是技术手段，而是成果）。
范围：我们在哪个领域运作，允许使用哪些技术手段。
非目标：哪些内容不属于目标范围。
工具和权限：智能体如何与世界交互。停止条件：何时停止；理想情况下应是一个可度量的变量。
证据：具体的测试、截图、日志、数据库记录或其他可用于确认工作已完成的指标（独立于智能体本身）。
升级：在什么情况下让谁介入（包括由谁来运行智能体）。
以及预算：该任务可投入的时间、精力和 token 的上限（token 是大模型的预算——你还可以加入任务尝试次数上限和并行度上限）。
## 指标让自主性更可靠一点
事后才确定指标可能是不够的。指标可以提前制定，写进一份简明的文档。这让自主性显得更可靠，也让信任的跨越更容易一些。
虽然衡量成功的方式有很多，但可以考虑针对每个自主性级别追踪以下指标的某种版本：
- 两次人工干预之间的平均时间
- 最长的一次成功无人值守且工作被接受的运行
- 在沙箱中运行的操作与升级处理的操作之比
- 自动批准的操作与被拒绝的操作的百分比
- 每条人类指令对应的平均智能体操作次数
- 澄清请求率、中断请求率
- 每个被接受变更的审查时间
- 每个置信度级别上的返工率
- 每个置信度级别上的缺陷逃逸率
- 每个被接受变更的 token 成本
这些指标可以讲述一个故事：一个仅靠人工交接来保持忙碌的智能体，是带着仪表盘的 4 级。一个保守的智能体，在没有自动接入、重试和可靠证据的情况下拒绝继续，是拥有真正把关的 5 级。
## 思考准备度
按风险和可撤销的难易程度对工作进行分类。保守地应用自主性，只有在支持更高级别的证据不断累积时才提升。一个有强大测试保护、配备审查智能体且有干净回滚路径的支付引擎重构，可以支持比一个缺乏任何权威标准的文档自动化任务高得多的自主性。自主性级别应该跟随验证流程，而不是任务名称。
## 四种反模式
任何系统都很容易落入这四种自主性反模式，除非时刻警惕避免。
自主性作为地位象征——智能体的自主性评级变成了毫无意义的地位徽章。更高的自主性被视为能力的证明而非安全性的证明，智能体在验证能力无法支撑的情况下被"开得更快"。修正方法：赞扬和奖励那些确定正确自主性级别并坚决避免越界的人。
权限洗白——审批疲劳的暴政导致我们授予 AI 智能体和工具远超必要范围的宽泛权限。修正方法：更好的边界永远是解药，比如沙箱配置文件、限定范围的写入目录、命令白名单、钩子以及自动审查。
摘要替代——用智能体的工作摘要替代审查，默认摘要已经足够。修正方法：像完全人工审查一样附带同样的证据包（diff、测试、日志、截图、审查员发现、风险、缺口等），同时避免认知上的放任。
舰队表演——数十个智能体并行运行，但人类仍在手动编排每一个依赖。修正方法：共享状态、所有权规则和更好的依赖追踪，逐步减少手动协调的需要。更小的 WIP（在制品）限制会迫使人们专注于编码和记录协调步骤，直到编排实现自动化。
## 一个校准练习
回顾你最近借助智能体完成的十个任务。对每个任务，记录所行使的自主性级别、涉及的风险、工作可撤销的难易程度、为满足验证要求而产生的证据、审查时间、是否需要返工，以及所选的自主性级别下次是否仍然合适。
## 如何安全地攀升
一次只沿一个轴前进。先从一个受监督的智能体开始，执行一个范围明确的单一任务，并产生经得起推敲的成功证据（如果足够整洁，即自主性 1 级）。然后在三个正交方向上逐步扩展。并行化以读取为主的探索任务（自主性 4 级）。添加在独立工作树上行动、受约束的文件所有权规则约束的写入智能体（自主性 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
## 相关链接
- [Addy Osmani](https://x.com/addyosmani)
- [@addyosmani](https://x.com/addyosmani)
- [3万](https://x.com/addyosmani/status/2072885435312042327/analytics)
- [欢迎来到 Gas Town](https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04)
- [spec](https://openai.com/index/open-source-codex-orchestration-symphony/)
- [Anthropic 研究](https://www.anthropic.com/research/measuring-agent-autonomy)
- [分析](https://www.anthropic.com/research/claude-code-expertise)
- [https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26](https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26)
- [升级到 Premium](https://x.com/i/premium_sign_up)
- [2026年7月3日 11:29](https://x.com/addyosmani/status/2072885435312042327)
- [3.07万次浏览](https://x.com/addyosmani/status/2072885435312042327/analytics)
- [查看引用](https://x.com/addyosmani/status/2072885435312042327/quotes)
---
*导出时间: 2026/7/3 18:01:06*
