自主性等级 L0–L5

一句话理解：自主性是一个可以按动作、按场景、按数据逐步调节的产品参数，不是“越高越先进”的技术指标。

“我们的 Agent 能完全自主完成任务”听起来很有吸引力，但在真实业务中，一个能自动给客户退款、却偶尔退错的 Agent，比一个每次都请你点“确认”的 Agent 危险得多。反过来，一个连查个数据都要你点三次确认的 Agent，用户用两天就放弃了。

自主性设计的难点不是“选一个等级”，而是 为不同的动作选不同的等级，并知道什么时候可以往上调。这一课给你一把尺子。

L0–L5：本课程使用的自主性分级

下面的分级是本课程为了讨论方便而定义的框架，借鉴了自动驾驶领域 SAE J3016 的 0–5 级思路，但不是行业统一标准。不同公司与研究者有各自的分法，重要的是团队内部用同一把尺子。

等级	名称	AI 做什么	人做什么	典型产品形态
L0	只回答	回答问题、解释概念	自己判断、自己执行全部动作	Chatbot
L1	建议	基于信息给出建议、草稿	采纳或修改后自己执行	Assistant、Copilot
L2	逐步确认	准备好每个动作，等待确认后执行	每一步都审批	早期 Agent、高风险场景 Agent
L3	按风险确认	低风险动作自动执行，高风险动作暂停确认	只审批关键动作	多数生产级业务 Agent
L4	例外审批	在预设边界内自主完成整个任务，越界或异常时才找人	设定边界、处理例外、事后抽查	成熟的 Coding Agent 后台任务
L5	完全自主	自主设定子目标并执行，无需人参与	只监控，必要时紧急停止	目前极少适合真实业务

把六个等级画成台阶：

图 1 · L0–L5：越往右，AI 承担的行动越多，人的角色从执行者变成监督者

和Agent、Chatbot、Copilot 与 Assistant 一课对照：L0–L1 主要是“帮你思考”，从 L2 开始才是“替你行动”。

学术界也有类似尝试。例如 Feng、McDonald 与 Zhang 在论文《Levels of Autonomy for AI Agents》中，按 用户扮演的角色 定义了五个等级：操作者（operator）、协作者（collaborator）、顾问（consultant）、审批者（approver）、观察者（observer）。它与本课程分级的思路一致：自主性的本质是 人与 AI 之间控制权的分配，而且可以独立于模型能力来设计。

自主性是按“动作”设定的，而不是按“产品”

同一个 Agent 里，不同动作应该有不同的自主性。以客服工单处理 Agent 为例：

动作	风险	可逆性	建议等级	理由
查询订单、支付状态、历史工单	低	无副作用	L4	只读，错了也没有损失
生成问题诊断报告	低	可重新生成	L4	产物供人阅读，不直接生效
创建内部工单	中	可关闭	L3 → 自动执行	内部流转，错了可以撤回
给客户发送通知短信	中高	不可撤回	L3 → 需确认	对外、不可撤回
修改订单状态	高	部分可逆	L2	影响下游对账与财务流程
发起退款或赔付	很高	资金难追回	L1	只给建议，由人发起

所以，“我们的 Agent 是 L3”这种说法其实不够精确。更好的说法是：“查询类 L4，写入类 L3，资金类 L1。” 操作分级的完整方法见操作分级。

决定自主性的四个变量

四个变量对自主性的作用方向不同：

图 2 · 四个变量：两个往下拉，两个往上推

错误代价：做错一次损失多大？影响内部还是外部客户？涉及资金、法律、隐私吗？
可逆性：能撤销吗？代码可以 git revert，邮件发出去就收不回。不可逆操作的设计见不可逆操作。
验证能力：有没有程序化的方法立即检查结果？Coding Agent 能跑测试，所以可以给更高自主性。
历史表现：在评测集和线上数据中，这类动作的成功率是多少？

自主性如何逐步提升

自主性不应该一次定死，而是随着数据积累逐步放开：

图 3 · 自主性逐级放开：每一级都要跨过约定好的数据门槛，也能快速降级

几个设计要点：

门槛要提前约定：例如“连续 500 次确认中直接通过率高于某个比例，且没有严重错误”，而不是凭感觉放权。具体比例由业务风险决定。
“确认后修改”是最宝贵的数据：用户修改了什么，说明 Agent 哪里不对，应该进入评测集。见构建评测集。
可以降级：出现严重事故或模型、工具发生变更后，自主性应能快速回退一级。

过高与过低都有代价

自主性过低的症状	自主性过高的症状
用户频繁点确认，逐渐不看内容直接点（确认疲劳）	出现用户意想不到的动作，信任崩塌
完成任务的总时间比人工还长	一次错误造成大范围影响
用户觉得“还不如自己做”	出了问题无法追溯是谁做的决定
Agent 的价值无法体现	合规与审计通不过

注意“确认疲劳”：当每一步都要确认时，确认本身就失去了意义。与其让用户确认 20 个低风险动作，不如只确认 2 个真正关键的动作，并把证据展示清楚。审批体验的设计见审批与接管。

常见误区

“自主性越高，产品越先进。” 用户要的是任务被可靠地完成，不是 AI 有多自主。在高风险领域，恰当的确认是产品竞争力的一部分。
“先做到 L4，再加确认。” 顺序应该反过来：从低自主性起步积累数据，再用数据证明可以放权。
“确认弹窗就是 Human-in-the-loop。” 如果用户看不懂要确认什么、没有证据支持判断，确认只是把责任转嫁给用户。完整模式见Human-in-the-loop。

产品经理检查清单

列出 Agent 的全部动作，每个动作的自主性等级是多少？
每个动作的错误代价、可逆性、验证方式分别是什么？
哪些动作第一版只给建议、不执行？
从当前等级提升到下一级的数据门槛是什么？谁来拍板？
出现什么情况时要降级？降级能否快速生效？
需要用户确认的动作有几个？用户确认时能看到哪些证据？
自主性配置由程序强制执行，还是只写在 Prompt 里？

练习

用 45 分钟，为“SEO 诊断与修复 Agent”设计自主性方案：

列出它可能执行的 6–8 个动作（例如：拉取 Search Console 数据、抓取页面、生成诊断报告、创建修复任务、修改页面 meta 标签、提交站点地图、修改 robots.txt）。
为每个动作填写错误代价、可逆性、验证方式，并给出初始等级。
选一个初始等级为 L2 的动作，写出把它提升到 L3 的具体数据门槛。

动作	错误代价	可逆性	验证方式	初始等级	升级条件
例：修改 robots.txt	很高（可能导致全站不被抓取）	可改回，但影响有滞后	修改后抓取校验规则	L1	暂不升级

下一步

导论到此结束。你已经建立了 Agent 的整体心智模型，下一个模块「软件与工程基础」从第一课「HTTP 与 API」开始，补齐与工程师对话所需的技术语感。

自主性等级 L0–L5