# 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 的本地/云线程、目标模式、工作树、自动化、子智能体、审查窗格、GitHub 代码审查、钩子、沙箱、自动审查和重新运行。
这些功能无法放在单一的阶梯上。
## 攀登：三个时代和单一堆栈
如果你自下而上阅读阶梯，你是在想象同时攀登代理权和编排。实际上，这六个等级代表了我们都会经历的三个独立时代：
首先，你坐在驾驶座上，智能体主要只是提供帮助，等待你去引导它。
其次，智能体负责一个有界的任务或目标，但你仍然在周围引导它并验证它所做的事情。
第三，在编排时代，系统能够掌控全局，将工作分发给许多智能体，你主要在出现问题时介入：“异常管理”。
这让事情变得更简单，因为阶梯上的垂直位置巧妙地捕捉了两个轴（编排只在顶部附近开始发挥作用），使其成为通过阶梯的单一稳定攀登。然而，攀登仍然是我们所有人正在经历的转变的一部分。
美好的一天工程工作包括接触几个阶梯层级，有时更多：在任务过程中在几个时代之间切换是很正常的。
## 六个等级详解
**第 0 级：辅助**
智能体提出的建议大多很好，往往完美无缺，但你总是决定它们是否足够好以付诸实施。想想自动补全、内联编辑建议，或者在聊天会话中闲逛，讨论一个尚未有人认领的变更。用于代价高昂的错误、微小的更改，或当你正在形成自己的判断时。验证主要在本地进行。
**第 1 级：监督行动**
智能体代表你进行编辑或运行命令，在执行任何重要操作之前征得你的许可。这是大多数人的默认姿态。这可以在本地沙箱中完成，并在应用更改前获得批准——每次批准都是对应用更改的独立验证——或者在交互式会话中完成。失败模式是批准疲劳；无论批准什么，所有的批准感觉都一样。你可以通过眯着眼查看差异、遵循一些启发式方法、在批准前与另一个人核对，或者干脆同意让智能体负责来解决这个问题。Codex 自动审查通过将边界条件的最终批准委派给单独的审查智能体来解决这个问题。
**第 2 级：范围任务委派**
将一个有界的任务移交给智能体。该任务将有明确的目标、约束条件以及完成工作的定义。你会待在附近，能够打断，但基本不参与。这是软件工程世界的重心。验证正从你身上转移（你可能需要休息和睡眠）转向智能体可以产生的证据：通过的自动化测试、正确的类型、Lint 建议、屏幕截图、重现步骤、通过示例证明的来源等。
**第 3 级：目标驱动的自主性**
智能体不惜一切代价实现目标，只有在满足某些条件时才会停止。在提示词模式下，这意味着提示词本身变成了目标（例如，“你能把这个页面的交互时间降低到 1 秒以下吗？”）。在 Codex 中，这是目标模式：智能体循环执行计划->行动->测试->审查步骤，直到不再满足成功标准。在 Claude Code 中，它是 /goal、/loop 和 /schedule 命令。要使此级别有用，停止条件必须能够以可自动化的方式衡量。
不要让你的智能体协助处理像“普遍改善用户体验”或“使代码库更具可测试性”这样模糊、松散的目标。选择具体、可衡量和自动化的内容：发现生产中逃过静态分析的 Bug、减少加载时间、确保我们有严格的 TypeScript 构建且没有显式的 any、对所有依赖项进行分类以仅保留我们理解并通过测试的依赖项等。最后，为了发现生产中的 Bug，智能体需要处于类似生产的环境中。
**第 4 级：并行委派**
跨许多智能体并行工作。每个智能体都在任务的一个隔离切片上工作。此级别最大的瓶颈是分解：定义要委派的正确切片。支持包括：子智能体、后台会话、/batch、工作树、智能体团队等。失败模式是虚假并行：同时对重叠的切片运行许多智能体，因此你得到的不是更多的工作，而是合并冲突和重复的决策。要做得好，智能体需要彼此隔离，每个都有自己的文件和状态。每个都需要有自己的审查队列。最后，每个智能体都会产生成本——就消耗的 token 而言——与同时运行的智能体数量成正比。在人类方面，编排税使得增加智能体的边际成本在几个之后增加。
**第 5 级：异常管理的编排**
定义成功是什么样子的，以及应该应用哪些策略。管理者智能体将根据触发器（例如新问题、新任务、时钟）唤醒，分派工作智能体，监控它们的进度，验证输出，在失败时重试，在满足条件时升级到更有能力的智能体或人类，聚合结果，并最终将工作产品（例如 PR）和证据返回给外部系统。把它想象成工厂：问题跟踪器或待办事项列表是输入，工厂的产品是输出（即许多已修复的问题、Bug）。智能体在适当隔离的环境中工作，有许多墙（如果需要，还有逃生舱口），只有操作系统——由管理者智能体定义——定义了工厂应该做什么。
这个操作系统的设计由人类决定；OpenAI 为 Symphony 提出了一个规范，其中心是 Linear 看板：每个问题都有自己的智能体工作区，智能体不断确保它按照自己工作区中规范文件中定义的目标取得进展。人工审查可以在产生证据的高度进行，但前沿（即在编排世界中最强大的东西）是构建拥有数百甚至数千个智能体的连续智能体工厂。在攀登的这个阶段，拥有独立的验证变得越来越重要：独立的实施者和审查者、独立的测试运行者和 QA、独立的安全检查、独立的验收流程门。
## 风险和可逆性决定了上限。
我记得读过 Anthropic 早期的一项关于 Claude Code 一些最困难任务的研究，其中它请求澄清的频率是用户打断的两倍多。有经验的用户（约 750 次会话 vs 不足 50 次）更倾向于自动批准并打断以监控进度。
他们还对人们如何使用 Claude Code 进行了更广泛的分析。他们查看了 2025 年 10 月至 2026 年 4 月期间约 23.5 万人的约 40 万次会话。从每次会话中，他们都能弄清楚某人做出的决策，比如他们在每个提示词中要求采取多少行动，其中有多少他们选择自动批准，他们多久打断一次等。人们做出了约 70% 的规划决策，但 Claude 执行了约 80% 的工作。高自主性不是要把人类排除在循环之外，而是从让他们做每一步转变为让他们决定下一步该走哪个方向。
如果我们想确定一个大型 AI 系统是否以高自主性运行，我们应该问的三个问题是：
- 我们要多快才能知道我们在它正在做的事情上错了？
- 我们要多么干净利落地撤销它正在做的事情？
- 什么能证明我们在它正在做的事情上是对的？
如果这三个问题的答案是：不快、非常困难、信任摘要，那就不是高自主性。
智能体的每次运行都应先有一个合约，定义它试图做什么。
目标：我们试图实现的目标（不是活动，不是技术，而是结果）。
范围：我们正在运行的领域，以及允许哪些技术。
非目标：不属于目标的部分。
工具和权限：智能体如何与世界互操作。停止条件：何时停止；理想情况下，是一个可测量的变量。
证据：可用于确认已完成的特定测试、屏幕截图、日志、数据库记录或其他指示器（独立于智能体）。
升级：在什么情况下让谁参与（包括谁运行智能体）。
以及预算：对多少时间、精力和 token 用于该任务的限制（token 是大型 AI 模型的预算——你还可以包括它可以尝试任务的次数限制以及对并行度的限制）。
## 指标让自主性更可靠一点
事后决定指标可能还不够。指标可以提前在一个简洁的文档中到位。这使得自主性感觉更可靠，使得信仰之跃更容易一点。
虽然有很多方法可以衡量成功，但考虑为每个自主性级别跟踪这些指标的某些版本：
- 干预之间的平均时间
- 接受工作的最长成功无人值守运行
- 在沙箱中运行的操作与升级的操作的份额
- 自动批准的操作与被拒绝的操作的百分比
- 每条人工指令的平均智能体操作数
- 澄清请求率
- 打断请求率
- 每次接受更改的审查时间
- 每个置信度级别的返工率
- 每个置信度级别的缺陷逃逸率
- 每次接受更改的 token 成本
这样的指标可以讲一个故事：一个由人工交接保持忙碌的单一智能体是带有仪表盘的第 4 级。一个保守的智能体，如果没有自动接收、重试和像样的证据就不愿继续进行，是带有真正闸门的第 5 级。
## 考虑准备情况
按风险以及可撤销的难易程度对工作进行分类。保守地应用自主性，仅随着支持更高级别的证据积累而提升。一个由强测试和审查智能体保护且具有清晰回滚路径的支付引擎重构，可以支持比缺乏任何规范真理的文档自动化任务高得多的自主性。自主性级别应遵循验证过程，而不是任务名称。
## 四种反模式
除非保持警惕，否则每个系统都很容易陷入这四种自主性反模式。
**自主性即地位** —— 智能体的自主性等级变成了毫无意义的名望徽章。高自主性被视为能力的证明，而不是安全的证明，智能体的运行热度超过了验证所支持的程度。修复方法：赞扬和奖励那些选择正确自主性级别并坚持不懈地避免过度行动的人。
**许可洗白** —— 批准疲劳的暴政导致我们授予 AI 智能体和工具远超必要范围的访问权限。修复方法：更好的边界总是一种修复，例如沙箱配置文件、范围可写根、允许列表命令、钩子和自动审查。
**摘要替代** —— 智能体的工作摘要替代了审查，假设摘要就足够了。修复方法：将与完全手动审查相同的证据包（差异、测试、日志、屏幕截图、审查者发现、风险、缺口等）捆绑在一起，同时避免认知投降。
**舰队角色扮演** —— 数十个智能体并行运行，但人类仍然坚持手动编排每个依赖关系。修复方法：共享状态、所有权规则和更好的依赖跟踪逐渐减少手动协调的需要。较小的在制品限制迫使专注于编码和记录协调步骤，直到编排自动化。
**校准练习**
回顾你使用智能体协助完成的最后十项任务。对于每项任务，记录行使的自主性级别、涉及的风险、工作的可撤销程度、为满足验证要求而产生的证据、审查时间、是否需要返工，以及选择的自主性级别下次是否仍然合适。
**如何安全攀登**
一次只攀登一个轴。从一个单一的受监督智能体开始，执行一个单一的范围任务，产生可辩护的成功证据。