自治等级不是模型说了算，是能不能撤销说了算

这个方向是错的。讨论 Agent 能做到多自主的时候，话题几乎总是绕回模型：这个模型够不够强，换下一代会不会就好了。

判据齐了不等于可以放权，能放多少取决于动作可不可撤销。环境这一层收口之后，手里有了一组能给出确定结论的判据。

自治等级不是模型能力的问题，是确定性和可逆性这两个维度能不能工程化的问题。给 Agent 放权到什么程度，跟模型强不强只有很弱的相关性。真正划出上限的是两个变量：确定性，也就是这个动作的对错能不能被规则确定地判断；可逆性，也就是做错了能不能撤回来。

该不该放权，先看确定性和可逆性#

这两个维度都不在模型那一侧，模型影响得了判断的质量，影响不了判断可不可判、动作撤不撤得回。我给任何写操作做分级时只看两个维度：确定性看这个动作的对错能不能用规则判出来，可逆性看做错了代价多大、多久能恢复。

确定性只有一种判断方法：能不能写出一条判它对错的规则。查某个订单状态、把一段文本写进草稿、给一批商品打上候选标签，这些动作的结果可验证，规则抓得住对错。而「给这个客户写一段安抚话术」、「判断这笔交易该不该通融」这类动作，对错依赖语境，规则给不出确定的判断。

可逆性看两个数。一个数是恢复到正常状态的时长中位数，另一个数是恢复要付出的代价，有没有人介入、要不要发公告、会不会留下用户可见的痕迹。改一个配置，回滚是一秒的事；往外发一条消息，发出去就发出去了；扣一笔款，撤销要走流程，还可能留下痕迹。

这张表给的是每一格对应的自主程度和交互方式。把确定性当横轴、可逆性当纵轴交叉，自治等级就定下来了，交互方式也跟着定。

确定性	可逆性	该给的自治与交互	典型动作
高	高	完全自主，事后抽检；直接执行，把结果展示出来	生成草稿、打标签、跑只读查询
高	低	自主执行加撤销窗口；执行前预览，或执行后允许撤销	改配置、提交变更、批量更新
低	高	建议加一次确认；行动前明确确认	生成回复草稿、推荐策略
低	低	人主导，Agent 只做信息准备；说明范围、目的和接收方后再让人确认	付款、对外承诺、删除、发布
判不准，或恢复不了	—	降一档自治，转人工	任何验证不了的动作

真正危险的格子只有一个：低确定性加低可逆性那一格。落进这一格的动作，模型再强也不该自己动手，模型能做的上限是把材料准备好，让人来做那个决定。越往自主的一头走，前置条件越硬。只读类直接放开，带建议的动作要一次确认，先执行后复核的动作必须可撤销，不可逆的动作每一步都要人点头——这四格不是权重不同，是前置条件不同。

通用大脑从来不是起点，每家都从一件具体的事切进去。公开案例的切入顺序都印证这条：飞鹤先啃设备运维和人事流程，来伊份先做门店巡检和智能补货，邯郸公积金从离退休提取这类高频适老事项切进去。

这些案例能落进哪一格，看「做完了」有没有定义成一条可断言的业务终态，模型说话多像已经办成事都不算数。工单已派单且住客可见，这才叫办成；接口返回 200 不算办成。判定做实之后，Agent 才敢在那一格里一次做到底，而不是每一步都回头问人。

落到我看过的量级上，也全都在这四格里。设备运维把故障恢复的中位时长从 104 小时压到 47 小时，口径是同一批设备上故障从发生到恢复的时长中位数。

重复故障率从 34% 降到 8%，口径是同一批设备里重复发生的故障占故障总数的比例。这一条比恢复时长变短更能说明问题：重复故障率降下来，说明这套系统不只是响应变快了，还把第一次的处理结果留成了下一次能直接用的判断依据。

客服那边省的是人的时间。这套客服助手上线首月收口了 230 万次会话，口径是首月由 Agent 收口并闭环的会话条数，约等于 700 名全职坐席的产能，量级接近同期人工客服会话量的三分之二。人工会话的处理时长从 11 分钟降到不足 2 分钟，口径是同一批会话由人工接手到闭环的时长均值。

收益是判据的副产品，量级大不大从来不是放权的理由。设备恢复 47 小时、重复故障率 8%、客服收口 230 万次这三个数能同时拿到，前提是落在同一格里的动作可验证、能回退，落点还是在放权边界上，不在模型那一侧。

L2 不是配置出来的，是工程出来的#

模型输出的是建议，不是幂等的操作。不给模型撤回来的能力，模型说的「我做完了」就没有任何兜底。很多自治分级表里写着一个「在边界内自主行动」的等级，却试图只靠一段 Prompt 实现它，这段 Prompt 基本不会生效。

L2 要成立，底下必须有四样东西托着：幂等键、撤销窗口、补偿接口和审计。四样缺一样，L2 就站不住。

• 幂等键。同一个意图重复提交，系统必须认出这是同一次操作，而不是执行两遍。键由会话标识、业务对象和操作类型拼出来，模型自己编的字符串不拿来当键——模型连上一次自己说的键是什么都未必记得住。重试必须带同一把键，已经成功写过的那一次不再执行，超时重发和并发重复提交才不会变成两笔。
• 撤销窗口。执行之后留一段时间，用户和系统都能在这段时间内撤回来，不需要走工单。窗口定多长不按实现方便定，按人什么时候看见结果定——一旦确认消息发出去了，窗口就短不下来。窗口内状态变更要对用户可见，让他知道现在挂着什么待定。
• 补偿接口。窗口过了才发现错了，得有反向操作把状态推回去，而不是让人去手工改。补偿做不出来的动作只能退回人工确认那一档，这也是小额退款走得通、大额退款必须停在 L1 的原因。
• 审计。谁在什么时候以什么依据让 Agent 做了什么，这条记录要能查到当时的输入快照和生效的规则版本，出事之后才答得出「当时是谁批准这次调用的」。

幂等键这一条最容易被跳过，它翻车的路径也隐蔽。模型自己重复生成了一次提交，或者网络超时后客户端重发了一次请求，没有幂等键，用户那笔操作就执行了两遍。这类事故在评测里几乎不会出现，评测不重试，等评测之外第一次撞上重复提交，往往已经在上线之后。

这四样是工程设施，不是提示词技巧。四样齐不齐，直接决定敢不敢把 L2 的开关打开。我在写操作上还坚持一条：模型只生成暂存的变更，由执行层在应用时按当前规则复核一遍。唯一的检查点在应用时，从生成到应用之间，规则、库存、用户权限都可能已经变了。

放权之后还得留一条能立刻收回来的线：每个能力配齐它自身的正例、负例和相邻能力的边界用例，能力改动先走金丝雀，单独关掉某一个能力的开关一直留着，高峰期冻结变更。这些开关平时看不见，出事的时候它们是在几分钟内把影响面收回去的唯一手段。

交易不变量要写在模型碰不到的地方#

涉及交易时，有几类规则我会直接写进执行层，不进模型上下文，也不让模型参与判断。强制这一层不在提示词里，也不在模型里，它落在调用链上，Anthropic 的电商 Agent 把这类规则放在模型之外的执行链里。把强制写在提示词里，等于把锁和钥匙交给同一个人。

只接受本会话下发的标识。 商品 ID、订单 ID、优惠券码，必须是本会话服务端返回过的。模型自己拼出来或者从历史消息里翻出来的标识一律拒收——这是最容易被越权利用的一条路径。

按结果状态查限额，不按单次请求查。 单个请求看都合规，十个请求叠加就越过了折扣、数量和预算上限。限额必须在应用时按当前累计结果判断。这条可以说得更直白：限额只看当前购物车的状态。

同会话的写操作串行化。 并行写会让「同时三个请求各自没超限额、加起来超了」这种情况完全不可见。串行是正确性前提，性能上不吃亏。

第三方文本一律清洗加围栏。 商品描述、用户留言、外部接口返回的文本里，可能藏着能改变 Agent 行为的指令。这些内容只当数据送进来，走的是数据通道，不走指令通道。

哪一段权限条件交给模型去写，答案就会越权可读。权限这一层要跟着动作一起定，小米零售的 AI 问数在权限上就这么做：指标权限和数据范围由系统在查询前注入，按店长、分公司这类角色自动附加可见范围。判「指标是否存在」和判「用户有没有权限」是两条不同的出口，查询还没跑，权限预检已经先给出结论。

别让模型对工具结果做语义重写，这一条容易被忽略，性质跟前面三条不一样：前面三条管的是动作边界，这一条管的是结果可信。电商场景里，如果允许模型改写商品标题、价格或库存的展示文案，链路后段就分不清哪个数字是权威系统返回的、哪个是模型润色过的。结果显示必须是权威系统的原值，可解释性才有意义。

这些规则的共性是：它们属于模型碰不到的那一类规则，不属于模型应该记住的那一类。我特意不把它们写进上下文——写进上下文，模型就知道它们存在，也就有了绕开它们的可能。放在文档里写「禁止调用某接口」，跟真正把那次调用拦下来，是两件完全不同的事。更彻底的做法是：消费者端的工具清单里根本不给扣款接口，支付与下单由受控组件完成，模型手里根本没有扣款工具可调。

确认点由风险决定，不由流畅度决定#

自治等级定了，剩下的是交互：什么时候让用户点一下。这一步最容易被「别打断用户」带偏。我的判据是动作风险，不是对话流畅度。

动作类型	默认交互
只读、可撤销、低成本	直接执行，结果展示出来
有限写入、容易回滚	执行前预览，或执行后允许撤销
对外发送、发布、付费、删除	行动前明确确认
涉及敏感数据或广泛权限	说明数据范围、目的和接收方后再确认
无法可靠验证或恢复	降低自治，转人工

两条边界都要守住。每一步都确认，Agent 会退化成一个昂贵的按钮，用户点确认的时间比自己做完还长。反过来，为了「流畅」把关键确认取消掉，代价是事故。

确认的方式也要按场景分。加购、改数量这类动作交给结果状态直接确认；结账必须经受控组件，并带上服务端本会话下发的标识，模型自己拼出来的标识拒收。搜索结果为空要明确说没有，并给出放宽条件或替代项。遇到规则冲突，展示冲突项让用户裁决，而不是替用户猜。

体验上另有一条判据：感知延迟和任务完成延迟要分开治理，展示基于真实工具参数的进度就能明显减少等待感，但不能用动画去掩盖结果质量或者未完成状态。用户感知到的「快」如果建立在虚假进度上，一旦出错就会全部还回来。更聪明的模型单 token 更慢，但规划更好、轮次更少，p90 和 p99 反而可能改善。只看单次响应时长会做出错误的模型选择。

确认面上还有一条硬要求：展示的是最终状态，不是意图描述。用户要看到的是「这张优惠券将被用在订单 12345 上，实付金额变为 ¥ 87.50」，而不是「我将为你使用优惠券」。

批量操作不能共用一次确认。「这十笔订单都要改，确认吗」这句话把十次决策压成了一次，而用户实际背书的只是其中他最没把握的那一笔。我的规则是一次确认只覆盖一个业务决策，批量只批「执行」这个动作，每笔的判断要单独过一次。省下的那几次点击，会在出问题那天以十倍的价格还回来。

失败态与验证分层，让框架代管一整类错误#

大多数产品的失败提示是一句「抱歉，我做不到」，这句话提供的信息量是零。我认为失败态至少要交付这几样：已经完成到哪一步，改动了哪些状态，失败的直接原因和置信度。接着是哪些产物仍可用、会不会重试、什么时候停。最后落到用户能改什么，怎么回滚或安全退出。

置信度那一栏单独说一下：它必须区分「查过了，没有」和「不确定，没查到」。这两者给用户的下一步完全不同——查过了没有应当结束，没查到应当换个条件再试或者转人工。把它们都写成「没找到」，用户就会自己再问一遍，再问一遍通常还是同样的结果。腾讯那条错误码排查 Agent 把置信度做成了显式字段，并与行动类型绑定：低置信的猜测绝不以结论形式下发，判不出根因就直接走升级路径。

失败态里最容易被忽略的是回滚与安全退出。打标为高置信的条目约占九成，口径是线上近一个月判为高置信的条目数除以同期排查条目总数。九成打在高置信上，说明这个字段的门槛是稳的，不靠模型语气撑出来。没有退出路径的失败，会让用户在半完成状态里反复尝试，每一次尝试都留下新的副作用。

一个内循环要能在没人盯的情况下跑完，控制面至少要有步数上限、整段超时、费用预算、写操作幂等、同参重复调用熔断，以及工具结果按业务 schema 校验。这几项缺一项，那一圈只是在用 token 换偶然成功。停止条件缺一栏的时候，代价不是慢，是同一句话反复解释、费用在涨、单没办。

空结果和不回答是合法的产品行为，这一点本身就是一条产品设计。指标消歧失败的时候给两三个候选让用户选，比硬猜一个强；没有权限的时候明确说没有权限，比换个日期重试一次强。可预测的澄清、拒绝和停止，本身就是信任机制——用户害怕的不是 Agent 做不到，是它做不到还装作做到了。

自治放权越大，验证越要提前。把可答范围收紧、把判定做实之后，系统学会了在答不了的时候明确说答不了，编一个看起来合理的答案反而更糟。把答不了也当成一种合法结果算进指标之后，指标的可信度反而上来了。三层验证栈怎么裁，在讲可验证性那篇已经说过，这里只补放权带来的那一条：越往自主的一头走，秒级那一层越要多拦一点，因为人不再在回路里逐个动作地看。

这一层真正要防的是假完成。成功与否按业务断言判定，不看接口返回的 200：回复「已为您办理」而工单没有派单，就是假完成。自治等级越高，假完成越难被发现——没有人在每一步回头核，而 Agent 自己永远认为它做完了。

下沉规则用的判据跟那一篇是同一条：能下沉的是事实，不是代理指标。放到放权这一侧，判据还要再紧一格——凡是影响撤销能力的规则，一律下沉到执行层，不留在模型上下文里。留在上下文里的规则，模型知道它存在，也就有了绕开它的可能；放进文档里写「禁止调用某接口」，跟真正把那次调用拦下来，是两件完全不同的事。

放权之后，评测的起点也要跟着变。只从干净状态跑，测的是第一次撞上陌生问题时的做法，而线上大部分请求都发生在半完成的状态里。我自己测的时候直接从一个困难状态启动：购物车里已经有商品、地址只填了一半、上一轮刚失败过，再看它能不能接住。配套的是正负对照和边界用例：不只测「该做的做没做」，还要测「不该做的有没有被挡住」。

放权有没有放对，最后要落到一组不随版本漂移的用例上，而不是这一轮的跑分。用例换一批，前面所有关于放权的结论就都作废了。

放权的顺序#

回头看，放权有固定的先后顺序。先把撤销能力做出来，再谈自治等级；先把那几条不变量下沉到执行层，再谈模型能不能自己判断；先定义清楚失败态长什么样，再谈成功率。

按这个顺序做的系统，自治等级是可以往上调的——每往上一格，底下都有对应的兜底。先调等级再补设施，每一次放权都是在增加事故面积。模型能力提升会改变的是「能做的任务范围」，不会改变「做错了能不能撤回来」这条边界。撤销代价一直由工程决定，模型代次插不上手。

放权一旦开出去，走偏没走偏、走偏多少，就变成一个评测问题。指标怎么定义、怎么采样、怎么卡住刷分，是评测那一步要处理的事。