在大多数关于 Agent 工程的讨论中，行动已经从提示（prompting）转向了 操作（operating）。以下是对未来前沿领域的一些展望：软件工厂、目标、循环、后台会话、子 Agent、钩子、沙箱、Agent 审批 Agent。对于许多未来的创造者来说，这种行为将在产品发布的第一天就内置其中：Claude Code 和 Codex 直接展现了这一转变。
从工程师的角度来看，你会使用 低自主性 来限制风险并提高可逆性，但针对明确的活动则使用 更高自主性，以及让并行 Agent 集群安全地重构庞大的代码库。关于某个行动的核心问题始终是：这个任务应该被赋予什么级别的自主性，以及什么样的验证机制才能让那个级别变得合理？
前沿的边缘是 管理 Agent，它在被触发时启动，将任务委派给其助手，同时持续验证它们的输出，并且只返回那些必须由人类做出的决策。使用这种设置的人可能已经在运行成百上千个 Agent，主要是在常青代码库上。就像大多数关于自主性的思考一样，每个人对规模的理解仍然不同。
最常被提及的阶梯来自 Steve Yegge 的单轴阶梯，该阶梯在 "欢迎来到汽油镇" 和《务实的工程师》一书中都有提及。如果你想要一个数字来衡量你的人工智能原生程度，这是一个很好的参考：这个阶梯给你一个单一的数字来衡量你对单个 Agent 的信任度。以下是其中一个版本：
在 2026 年初，即使工作开始从委派转向编排，这仍然是衡量风险的一个相当不错的指标。然而在今天，当你能够同时运行多个 Agent 时，许多技能集可能会获得更重要的意义和杠杆作用。 单个阶梯无法帮助你定位多 Agent 技能。
相反，我见过的几乎每一次关于自主性的辩论都混淆了两个本应分开的问题：我们让这个单一的 Agent 离我们自身有多远，以及我们协调多个 Agent 的技能是什么？
为了分别捕捉这两个维度，我们将使用两个轴：自主性（agency）和编排能力（orchestration）。
在自主性轴上，低端包括建议候选行动并等待决策。
中端意味着 Agent 正在处理一个特定任务，但限定其行动范围，并且持续报告它做了什么以及相关证据，以便你可以持续引导它。
在 高自主性 端，Agent 正朝着一个目标工作，进行实验、学习、测试、寻找解决问题的方法、遇到阻碍、提出问题、尝试不同的方法，并将所有这些工作以证据的形式返回。
在编排能力轴上，低端意味着一个 Agent ，一个线程。在中端，你有几个 Agent ，每个在各自的工作树中工作，可能朝着不同的目标努力，但彼此隔离。在高端，你有一个编排器，它可以接收积压任务、问题追踪器、日程或其他队列，并将其转化为持续的工作，你只需要在事情失败时介入：“按例外管理”。包含这些想法的产品和功能包括：
- Claude Code 的 /plan、/goal、/loop、/background、/batch、/code-review、/security-review 模式，子 Agent、钩子、检查点、Agent 委派和管理实践、后台会话、Agent 团队模式、/schedule 参数
- Codex 的本地/云端线程、Goal 模式、工作树、自动化、子 Agent、审查面板、GitHub 代码审查、钩子、沙箱化、自动审查和重新运行
这些能力无法被单一的阶梯所涵盖。
攀登：三个时代与一个统一堆栈
如果你从下往上阅读阶梯，你是在想象同时攀登自主性和编排能力。实际上，这六个级别代表了我们都将经历的三个独立时代：
首先，你处于主导地位，Agent 大多只是辅助，等待你的指引。
其次，Agent 负责一个有限的任务或目标，但你仍然在场，引导它并验证它的工作。
第三，在编排时代，系统能够掌控全局，将工作分发给多个 Agent ，你大多只在出现问题时才介入：“按例外管理”。
这让事情变得更简单，因为阶梯上的纵向位置清晰地捕捉了这两个轴（编排能力只在接近顶部时才启动），使其成为一次通过各个梯级的稳步攀登。然而，这次攀登仍然是我们所有人正在经历的一个转变的一部分。
一个好的工程日会涉及到多个梯级，有时甚至更多：在一个任务的进程中，在几个时代之间切换几次是正常的。
六个级别的详细说明
级别 0：辅助
Agent 给出建议，这些建议大部分是好的，甚至是完美的，但你将始终决定它们是否足够好以至于可以采取行动。可以想象成自动补全、内联编辑建议，或者在一个聊天会话中讨论某个尚未有人认领的变更。适用于代价高昂的错误、微小的改动，或者在你还在形成自己的判断时。验证主要在本地进行。
级别 1：受监督的行动
Agent 代表你进行编辑或运行命令，但在执行任何关键操作之前会征求你的同意。 这是大多数人的默认姿态。可以在本地沙箱中进行，在应用更改前需要批准 - 每次批准都是对更改可以应用的独立验证 - 或者在交互式会话中进行。失败模式是批准疲劳；所有批准看起来都一样，无论它们批准的是什么。你可以通过审视差异、遵循一些启发式规则、在批准前征求他人意见，或者干脆同意让 Agent 负责来解决这个问题。Codex Auto-review 通过将边界条件的最终批准委托给一个独立的审查 Agent 来解决这个问题。
级别 2：限定范围的任务委派
将有限的任务移交给 Agent。 该任务将有明确的目标、约束条件以及完成的定义。你会待在附近，能够打断，但大多情况下不参与。这是软件工程世界的重心。验证正在从你（你可能需要休息和睡眠）转移到 Agent 能够生成的证据上：通过的自动化测试、正确的类型、lint 建议、截图、复现步骤、示例来源等。
级别 3：目标驱动的自主性
Agent 会不惜一切代价来实现一个目标，只有在满足某些条件时才会停止。 在提示模式下，这意味着提示本身就成了目标（例如，“你能把这一页的交互时间降到 1 秒以下吗？”）。在 Codex 中，这是 Goal 模式：Agent 循环执行计划->行动->测试->审查步骤，直到不满足成功标准为止。在 Claude Code 中，是 /goal、/loop 和 /schedule 命令。为了让这个级别有用，停止条件必须以可自动化的方式进行衡量。
不要让你的 Agent 帮助处理模糊、笼统的目标，例如“普遍改善用户体验”或“让代码库更易于测试”。选择一些具体、可衡量且可自动化的目标：在生产中发现静态分析无法发现的错误、减少加载时间、确保我们有一个严格的 TypeScript 构建且没有显式 any 类型、对所有依赖项进行分诊，只保留我们理解并通过测试的那些，等等。最后，要在生产中发现错误，Agent 需要在一个类似生产的环境中运行。
级别 4：并行委派
跨多个 Agent 并行工作。 每个 Agent 处理任务的一个隔离切片。这个级别最大的瓶颈是分解：定义要委派的正确切片。支持包括：子 Agent、后台会话、/batch、工作树、Agent 团队等。失败模式是假并行：同时运行多个 Agent 处理重叠的切片，这样你得到的不是更多的工作，而是合并冲突和重复的决策。要做好这一点，Agent 需要相互隔离，每个 Agent 拥有自己的文件和状态。每个 Agent 也需要有自己的审查队列。最后，每个 Agent 都会产生成本——就消耗的令牌而言——与同时运行的 Agent 数量成正比。在人类方面，编排税使得添加一个 Agent 的边际成本在几个之后开始上升。
级别 5：按例外管理编排
定义成功的标准以及应遵循的策略。 一个管理 Agent 会根据触发器（例如，新问题、新任务、时间）被唤醒，分派工作 Agent，监控它们的进度，验证输出，在失败时重试，在满足条件时上报给更有能力的 Agent 或人类，汇总结果，并最终将工作产品（例如，PR）和证据返回给外部系统。想象一个工厂：问题追踪器或积压任务是输入，工厂的产品是输出（即，许多已修复的问题和 bug）。Agent 在一个具有足够多隔离墙（如果需要，还有逃生舱）的适当隔离环境中工作，只有一个由管理 Agent 定义的操作系统，定义了这个工厂的预期行为。
这个操作系统的设计留给了人类；OpenAI 已经为 Symphony 提出了一个 规范，其核心是一个 Linear 项目：每个问题都有自己的 Agent 工作空间，Agent 持续确保它正在朝着其工作空间中规范文件定义的目标取得进展。人类审查可以在生成证据的层面进行，但前沿（即在编排世界中最强大的）是构建拥有数百甚至数千个 Agent 的持续运行的 Agent 工厂。在攀登的这个阶段，拥有独立的验证变得越来越重要：独立的实施者和审查者，独立的测试运行者和 QA，独立的安全检查，独立的验收流程门禁。
风险与可逆性设定了天花板
我记得读过一份早期的 Anthropic 研究，关于使用 Claude Code 完成的一些最困难的任务，其中它要求澄清的次数是用户打断次数的两倍多。经验丰富的用户（~750 次会话 vs 低于 50 次）更倾向于自动批准和打断，同时关注进度。
他们还对人们如何使用 Claude Code 进行了更广泛的 分析。他们查看了 2025 年 10 月到 2026 年 4 月期间约 23.5 万人的约 40 万次会话。从每次会话中，他们可以推断出人们做出的决策，比如他们在每个提示中要求了多少个操作，他们选择自动批准哪些操作，他们多频繁地打断等等。人们做出约 70% 的规划决策，但 Claude 完成约 80% 的执行。高自主性不是将人排除在循环之外，而是从让他们执行每一步转变为让他们决定下一步的方向。
如果我们想确定一个大型人工智能系统是否在高自主性下运行，我们应该问三个问题：
- 我们多快能发现自己对其行为的判断是错误的？
- 我们能多干净地撤销它的行为？
- 什么能证明我们对其行为的判断是正确的？
如果对这三个问题的回答分别是：不快、极其困难、并且只能相信摘要，那么它就不是高自主性。
每次 Agent 运行之前，都应该有一个契约来定义它试图做什么。
目标：我们试图达到什么（不是一项活动，不是技术，而是一个结果）。
范围：我们在哪个领域内操作，允许使用哪些技术。
非目标：哪些不是目标的一部分。
工具和权限：Agent 如何与世界交互。停止条件：何时停止；理想情况下，是一个可衡量的变量。
证据：特定的测试、截图、日志、数据库记录或其他可用于确认某事已完成的指标（独立于 Agent）。
上报：在什么情况下让谁介入（包括谁运行 Agent）。
预算：对任务投入的时间、精力和令牌数量的限制（令牌是大型 AI 模型的预算——你也可以包括对它可以尝试任务的次数以及并行度的限制）。
指标让自主性更可靠一点
事后决定指标可能是不够的。指标可以预先设定在一个简洁的文档中。这让自主性感觉更可靠，也让信仰之跃更容易迈出。
虽然衡量成功的方法有很多，但可以考虑为每个自主性级别追踪以下指标的一些版本：
- 干预之间的平均时间
- 最长成功无人值守运行并产出可接受工作的时长
- 在沙箱中运行的操作与上报的操作的比例
- 自动批准的操作与被拒绝的操作的百分比
- 每次人类指令对应的 Agent 平均操作数
- 澄清请求率 / 中断请求率
- 每次接受更改的审查时间
- 每个置信级别的返工率
- 每个置信级别的缺陷逃逸率
- 每次接受更改的令牌成本
这样的指标可以讲述一个故事：一个通过人工交接而保持忙碌的单一 Agent 是级别 4，并带有一个仪表盘。一个保守的 Agent，在没有自动化接收、重试和可靠的证据时不愿意继续，这是带有真正门禁的级别 5。
考虑就绪度
根据风险以及撤销的难易程度对工作进行分类。保守地应用自主性，只有在支持更高层级的证据积累时才提升。一个受强大测试和审查 Agent 保护且拥有干净回滚路径的支付引擎重构，可以支持比缺乏任何标准真相的文档自动化任务高得多的自主性。自主性的级别应该跟随验证过程，而不是任务名称。
四个反模式
除非保持警惕，否则每个系统都容易陷入这四个自主性反模式。
自主性作为身份象征 - Agent 的自主性评级变成了一个毫无意义的身份象征。更高的自主性被视为能力的证明，而非安全的证明，Agent 的运行热度超出了验证的支持范围。解决方法：赞扬和奖励那些锚定在正确自主性级别并坚决避免越界的人。
权限洗白 - 批准疲劳的暴政导致我们授予 AI Agent 和工具远超必要的广泛访问权限。解决方法：更好的边界总是解决方案，例如沙箱配置文件、限定的可写根目录、列入白名单的命令、钩子和自动审查。
摘要替代 - 假设 Agent 的工作摘要足以替代审查。解决方法：像完全人工审查一样，附上相同的证据包（差异、测试、日志、截图、审查者发现、风险、差距等），同时避免认知投降。
集群角色扮演 - 数十个 Agent 并行运行，但人类仍然手动编排每一个依赖关系。解决方法：共享状态、所有权规则和更好的依赖追踪逐步减少手动协调的需要。更小的在制品限制迫使人们专注于编码和记录协调步骤，直到编排自动化。
校准练习
回顾你最近在 Agent 协助下完成的十项任务。对于每项任务，记录所执行的自主性级别、涉及的风险、撤销工作的难易程度、为满足验证要求而生成的证据、审查时间、是否需要返工，以及所选的自主性级别下次是否仍然合适。
如何安全地攀登
每次只在一个轴上移动。从一个负责单个限定范围任务并产生可靠成功证据的受监督的单一 Agent 开始（如果足够整洁，即为自主性级别 1）。然后逐渐在三个正交方向上扩展。并行化读取为主的探索任务（自主性级别 4）。添加在具有约束文件所有权规则的独立工作树上操作的写入 Agent（自主性级别 4）。添加重复性自动化，然后是基于问题、语音等 Agent 主导的编排。杠杆上的每一步都需要一套新的安全机制（例如，新的故障模式）。
命名它们：更长时间的单一 Agent 运行可能导致漂移、上下文腐烂、沟通中断或目标偏离。后台工作可能导致过时的假设和薄弱的手交接。过多的并行工作可能导致合并冲突或重复决策。过多的重复性工作可能导致沉默的令牌消耗或过时的提示。按例外管理可能导致漫长的审查队列和警报疲劳。解决方法不是更努力地信任；而是缩小范围、确保更好的证据、启用更便宜的回滚路径、强化门禁，以及定义更清晰的所有权规则。
使用自主性级别：
- 级别 0 最适合精细工作以及判断仍在形成时。
- 级别 1 最适合大多数探索，如果工作是在已知边界附近进行。
- 级别 2 最适合大多数有限的任务，要知道可能存在未知的依赖和不可预见的问题。
- 级别 3 最适合成功条件能够足够清晰陈述时。
- 级别 4 最适合工作可以纯粹地跨这些成功条件进行拆分时。
- 级别 5 一旦跨各种成功条件所需的协调和沟通被完全编码后。
验证将永远是瓶颈。
尽管目前存在种种虚张声势和工具，一个与 AI Agent 合作的工程团队的成熟姿态是 校准的自主性。
瓶颈在于协调、验证、维护、产品判断和事件学习
在不久的将来，我们将需要设计知道何时工作、何时验证、以及何时提问的循环——但 工程师的技能仍在于选择正确的自主性级别，以及构建模式和可靠的证据来防范其阴暗面。
注：Pangram 标记本文为 100% 人类撰写： [https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26](https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26)
