内容
在关于智能体工程（agentic engineering）的多数讨论中，重点已经从提示（prompting）转向了运行（operating）。这里有一幅面向前沿、望向迷雾的图景：软件工厂、目标、循环、后台会话、子智能体、钩子、沙箱、审批智能体的智能体。对许多未来的创造者来说，这种行为将从产品第一天起就内建其中：Claude Code 和 Codex 直接体现了这一转变。
从工程师的角度看，你会用低自治来降低风险、增强可逆性；但对于明确的活动，以及让成群的并行智能体安全重构庞大代码库，则会使用更高自治。关于一个行动的核心问题始终是：这项任务应当处于什么级别？什么样的验证才能让这个级别站得住脚？
前沿的边界，是那种在触发条件到来时被唤醒的管理型智能体：它把任务分派给助手，同时持续验证它们的输出，并且只带回必须由人类做出的决策。使用这类设置的人，确实可能已经在运行成百上千个智能体，而且大多运行在长期存在的代码库上。和大多数关于自治的思考一样，你对规模的感知因人而异。
最常被提到的尺度，是 Steve Yegge 的单轴阶梯，见于 “Welcome to Gas Town” 以及 The Pragmatic Engineer。如果你想要一个数字来衡量自己有多“AI 原生”，它是个不错的参照：这把阶梯会给你一个单一数值，用来衡量你对单个智能体的信任程度。下面是其中一个版本：
在 2026 年初，即便工作开始从“委派”转向“编排”，这仍然是衡量风险的一个相当好的代理指标。但如今，当你能一次运行很多智能体时，许多技能组合的意义和杠杆作用都可能显著提升。 单一阶梯无法帮助你定位多智能体能力。
相反，我看到的几乎所有自治讨论，都会把两个本应分开的问题混在一起：我们让这个单个智能体离自己有多远？以及我们协调多个智能体的能力有多强？
为了把这两个维度分别表达出来，我们将使用两个轴：智能体自主性（agency） 和 编排能力（orchestration）。
在自主性轴上，低级别包括提出候选动作，并等待决策。
中等级别意味着智能体在处理一个特定任务，但会限定自己做什么，并且持续回报自己的行为及证据，以便你还能继续引导它。
在高自主性端，智能体会朝着一个目标推进，不断试验、学习、测试、寻找问题的解法、遭遇阻塞、提出问题、尝试不同路径，并把所有这些工作都以证据形式带回来。
在编排轴上，低级别是一个智能体、一条线程。中等级别是多个智能体，每个都在各自的工作树（worktree）中运行，可能朝着不同目标，但彼此隔离。高等级别则是有一个编排器，它可以接收待办、工单系统、排期或其他队列，把它们转化为持续的工作，而你只需要在出问题时介入：也就是“例外管理”。融入这些理念的产品和功能包括：
-
Claude Code 的 /plan、/goal、/loop、/background、/batch、/code-review、/security-review 模式，子智能体、钩子、检查点、智能体委派与管理实践、后台会话、智能体团队模式、/schedule 参数
-
Codex 的本地/云线程、Goal 模式、工作树、Automations、子智能体、审阅面板、GitHub 代码审查、钩子、沙箱、Auto-review，以及 rerun
这些能力无法塞进同一把阶梯里。
如果你从下往上读这把阶梯，你会想象自己同时在攀升自主性和编排能力。实际上，这六个层级代表了我们都会经历的三个独立时代：
首先，你坐在驾驶座上，智能体主要只是辅助，等待你来操控它。
其次，智能体接管一个有边界的任务或目标，但你仍在旁边，引导它并验证它的行为。
第三，在编排时代，系统能够主持全局，把工作分发给多个智能体，而你大多只需在出问题时介入：也就是“例外管理”。
这样一来，事情反而更简单，因为阶梯上的垂直位置能够整齐地对应这两个轴（编排只在高处才真正介入），于是它就成了沿着台阶的一次稳定攀升。尽管如此，这次攀升仍然是我们都在经历的一场转变的一部分。
工程实践中美好的一天，通常会接触到好几个台阶，有时甚至更多：在一次任务过程中来回切换几个时代，是很正常的。
Level 0：辅助（Assist）
智能体会提出建议，这些建议大多不错，甚至常常完美，但是否足以采纳，始终由你来决定。可把它理解为自动补全、行内编辑建议，或者在一个聊天会话里等待着，讨论一个尚未有人接手的改动。适合代价高的错误、微小改动，或者你正在形成自己的判断时使用。验证主要在本地完成。
Level 1：受监督的行动（Supervised action）
智能体代表你编辑或执行命令，但在采取任何有后果的动作前会先征求你的同意。 这是大多数人的默认姿态。它可以在本地沙箱中完成，在应用变更前需要批准——每次批准都是一次独立验证，确认该变更可以应用——也可以在交互式会话中进行。其失败模式是审批疲劳；无论审批的是什么，每次审批都感觉一样。你可以通过眯眼看 diff、采用一些启发式方法、在批准前再找另一个人确认，或者干脆约定由智能体承担责任来缓解这个问题。Codex 的 Auto-review 通过把边界条件的最终审批委派给另一个审阅智能体，解决了这个问题。
Level 2：有范围的任务委派（Scoped task delegation）
把一个有边界的任务交给智能体。 这项任务会有明确目标、约束，以及对“完成”的工作定义。你会保持在附近，必要时可打断它，但大部分时间不直接介入。这是软件工程世界的重心。验证会逐渐从你身上转移开来（你可能需要休息和睡觉），转向智能体能够产出的证据：通过自动化测试、正确的类型、lint 建议、截图、复现步骤、以示例为依据的来源证明等。
Level 3：目标驱动的自治（Goal-driven autonomy）
智能体会不惜一切代价去实现一个目标，直到满足某个条件才停止。 在 prompt 模式下，这意味着提示词本身就成了目标（例如：“你能把这个页面的可交互时间降到 1 秒以内吗？”）。在 Codex 中，这是 Goal 模式：智能体在 plan→act→test→review 之间循环，直到不再满足成功条件为止。在 Claude Code 中，则对应 /goal、/loop 和 /schedule 命令。要让这一层真正有用，停止条件必须以一种可自动化的、可度量的方式表述。
不要让智能体去处理那种模糊、空泛的目标，比如“整体提升用户体验”或“让代码库更可测试”。要选具体、可衡量、可自动化的目标：例如在生产环境中找出静态分析无法发现的 bug、缩短加载时间、确保我们拥有严格的 TypeScript 构建且没有显式 any、梳理所有依赖只保留那些我们真正理解并且能通过测试的依赖，等等。最后，如果要在生产环境中找 bug，智能体就必须处在类似生产的环境里。
Level 4：并行委派（Parallel delegation）
让多个智能体并行工作。 每个智能体负责任务中一个隔离的切片。这个层级最大的瓶颈是拆分：要定义出恰当的切片来委派。支持方式包括：子智能体、后台会话、/batch、工作树、智能体团队等。其失败模式是假并行：多个智能体同时作用于重叠切片，结果不是更多产出，而是合并冲突和重复决策。要做好这一层，智能体之间必须彼此隔离，每个都拥有自己的文件和状态。每个智能体也需要自己的审阅队列。最后，每个智能体都会消耗成本——以 token 为单位——并且与同时运行的智能体数量成正比。在人类侧，编排税会让随着智能体数量增加，新增一个智能体的边际成本在一开始几次之后就迅速上升。
Level 5：例外管理式编排（Managed-by-exception orchestration）
定义成功长什么样，以及哪些策略应该适用。 一个管理型智能体会基于触发条件（例如新 issue、新任务、定时器）醒来，调度工作智能体，监控其进度，验证输出，失败时重试，在条件满足时升级给更有能力的智能体或人类，汇总结果，并最终把工作产物（例如 PR）和证据返回给外部系统。可以把它想成工厂：issue 跟踪器或待办列表是输入，工厂的产物就是输出（也就是：大量修复过的问题、bug）。智能体在合适的隔离环境中工作，四周有很多隔离墙（必要时也有逃生通道），而由管理型智能体定义的操作系统，才决定了这个工厂应该做什么。
这个操作系统如何设计，由人类来决定；OpenAI 为 Symphony 提出了一份 spec，其核心是一个 Linear 面板：每个 issue 都有自己的智能体工作区，智能体持续确保自己正朝着在其工作区内 spec 文件所定义的目标前进。人类审查可以在产生证据的高度进行，但前沿方向（也就是编排世界里最强大的东西）是在构建拥有数百乃至数千个智能体的持续运行型智能体工厂。到了这一步，独立验证就变得越来越重要：实施者和审阅者分离、测试运行与 QA 分离、安全检查分离、接收流程门禁分离。
我记得读过 Anthropic 早前关于 Claude Code 最难任务的一项 研究：其中，智能体请求澄清的次数，比用户打断它的次数还要高出两倍多。经验更丰富的用户（大约 750 次会话，而非少于 50 次）更倾向于自动批准，同时在一旁盯着进度，在必要时再打断。
他们还对人们如何使用 Claude Code 做了大量更广泛的 分析。他们研究了 2025 年 10 月到 2026 年 4 月之间，大约 23.5 万人参与的约 40 万次会话。从每次会话中，他们都能推断出一些决策，比如用户在每个提示里要求多少个动作、其中哪些选择自动批准、多久打断一次等等。人类做了大约 70% 的规划决策，但 Claude 执行了大约 80% 的执行工作。高自治并不意味着把人排除在流程之外，而是把他们从“每一步都要亲自做”转变为“只决定下一步往哪个方向走”。
如果我们想判断一个大型 AI 系统是否在高自治下运行，应该问的三个问题是：
-
我们多久会知道自己对它在做什么这件事判断错了？
-
我们要多轻松才能撤销它正在做的事情？
-
什么证据能证明我们对它在做什么的判断是对的？
如果这三个问题的答案都是：知道得不快、撤销很困难、而且只能相信摘要，那它就不是高自治。
每一次智能体运行，都应当先有一份契约，定义它想做什么。
目标：我们想实现什么（不是活动，不是技术，而是结果）。
范围：我们在哪个领域内运作，允许使用哪些技术。
非目标：哪些不属于目标范围。
工具与权限：智能体如何与世界交互。停止条件：什么时候停止；最好是一个可度量的变量。
证据：可用于确认某件事已经完成的具体测试、截图、日志、数据库记录或其他指标（独立于智能体本身）。
升级机制：什么情况下谁需要介入（包括谁来运行这个智能体）。
以及预算：为该任务投入多少时间、精力和 token 的上限（token 是大型 AI 模型的预算——你也可以加入它最多允许尝试任务的次数，以及允许的并行度上限）。
事后再决定指标，恐怕还不够。指标完全可以预先写进一份简明文档里。这样会让自治感觉更可靠，也会让迈出这一步的心理负担稍微轻一些。
虽然衡量成功的方法很多，但不妨考虑为每个自治级别追踪以下某种形式的指标：
-
平均干预间隔时间
-
最长的成功无人值守运行时长，以及其产出是否被接受
-
在沙箱中运行的动作占比 vs. 被升级处理的动作占比
-
自动批准的动作百分比 vs. 被拒绝的动作百分比
-
每条人类指令对应的平均智能体动作数
-
澄清请求率 / 打断请求率
-
每次被接受变更的审阅时间
-
每个置信级别上的返工率
-
每个置信级别上的缺陷逃逸率
-
每次被接受变更的 token 成本
这些指标能讲述一个故事：一个被人类来回接手、一直忙个不停的单个智能体，是带仪表盘的 Level 4。一个保守的智能体，不愿在没有自动化接入、重试和足够证据的情况下继续推进，是有真正门禁的 Level 5。
应按风险以及工作的可回滚程度来分类。自治的应用应当保持保守，只有在支持更高层级的证据不断累积时才逐步上调。一个受强测试和审阅智能体保护、并且有清晰回滚路径的支付引擎重构，能够支持比缺乏任何权威真相来源的文档自动化任务高得多的自治级别。自治级别应当服从验证流程，而不是任务名称。
如果不加警惕，每个系统都很容易落入这四种自治反模式。
自治即身份象征 —— 智能体的自治评级变成了毫无意义的身份徽章。更高自治被当作能力证明，而非安全证明，智能体在验证能力承受范围之外被过热运行。修正方法：表扬并奖励那些能为自治选择正确级别、并坚决避免越界的人。
权限洗白 —— 审批疲劳的暴政让我们给 AI 智能体和工具授予远超所需的访问权限。修正方法：更好的边界永远是解决方案，例如沙箱配置文件、限定可写根目录、允许名单命令、钩子和 Auto-review。
摘要替代 —— 只看智能体的工作摘要来替代审查，默认摘要就足够。修正方法：和完全手工审查一样，附带同样的证据包（diff、测试、日志、截图、审阅发现、风险、缺口等），同时避免认知上的缴械。
舰队 cosplay —— 几十个智能体并行运行，但人类仍在手工编排每一个依赖。修正方法：共享状态、所有权规则和更好的依赖跟踪，会逐步减少手工协调的需求。更小的 WIP 限制会迫使团队聚焦于把协调步骤编码并文档化，直到编排真正自动化。
一个校准练习
回顾你最近十个借助智能体完成的任务。针对每个任务，记录所使用的自治级别、涉及的风险、工作有多容易回滚、为满足验证要求而产生了哪些证据、审查花了多久、是否需要返工，以及这次选择的自治级别在下次是否仍然适用。
如何安全地攀升
每次只沿一个轴上升一级。先从一个受监督的单个智能体开始，让它完成一个单一的、有边界的任务，并产出足以站得住脚的成功证据（如果足够整洁，这就是 Level 1）。然后再逐步向另外三个正交方向扩展。将读多写少的探索任务并行化（自治级别 4）。增加在不同工作树上执行、并受文件所有权规则约束的写入型智能体（自治级别 4）。再加入周期性自动化，然后是基于 issue、语音等触发的智能体主导编排。每上升一步杠杆，都需要一套新的安全机制（例如新的失败模式）。
把它们说出来：更长的单智能体运行可能导致漂移、上下文腐烂、沟通中断或目标跑偏。后台工作可能导致假设过时、交接变弱。过多的并行工作可能导致合并冲突或重复决策。过多的周期性工作可能导致静默的 token 消耗或提示词过时。例外管理可能导致漫长的审查队列和告警疲劳。修正方法不是更努力地相信，而是缩小范围、确保更好的证据、启用更廉价的回滚路径、强化门禁，并制定更清晰的所有权规则。
使用自治级别：
-
Level 0 最适合精细工作，以及当判断仍在形成时。
-
Level 1 最适合大多数探索性工作，前提是工作贴近已知边界。
-
Level 2 最适合大多数有边界的任务，前提是要知道可能存在未知依赖和未预见的坑。
-
Level 3 最适合那些成功条件能够足够清晰表述的场景。
-
Level 4 最适合能够围绕这些成功条件被清晰拆分的工作。
-
Level 5 最适合那些跨各项成功条件所需的协调与沟通都已被完全编码的场景。
验证永远会是瓶颈。
尽管当前工具和当前气势都很强，真正成熟的、与 AI 智能体协作的工程团队姿态，应当是校准过的自治。
在不远的未来，我们会希望设计出知道何时该工作、何时该验证、何时该提问的循环——但工程师的能力，仍将体现在选择正确的自治级别，以及构建能够抵御其阴暗面的模式与可辩护证据上。
