Agent 上了生产，谁替它按暂停键

这几天 Agent 框架选型的讨论很多，但多数停留在「能不能跑通」。真正的分水岭在生产环境：一个会自己调工具、自己重试、自己反思的 Agent，出了错谁来按暂停键？

三个放权层级

我把 Agent 的权限设计分成三级，按业务后果递增：

只读级：Agent 只能查不能写。搜索、读取、汇总——这类任务放开了跑，错再多也不伤业务。大部分「Agent 焦虑」其实源于把演示级的权限直接搬到了生产。

受控写入级：Agent 可以写，但每次写入走审批队列或白名单校验。关键设计是审批的粒度——按操作类型批（比如「允许更新状态字段」）而不是逐条批，逐条批会把人拖垮，人一疲惫审批就成了橡皮图章。

自主执行级：Agent 自己决定执行。这一级必须有三个前置：可撤销（每个动作有逆操作或快照）、可回放（完整动作链留痕）、有熔断（错误率/成本/循环次数任一超阈值即停）。

暂停键的三个常见设计错误

1. 熔断条件只看报错。Agent 最贵的失败不是报错，是「成功地做错了」——状态码全绿但业务语义错。熔断要挂业务校验（抽样比对、不变量检查），不能只挂异常。
2. 暂停后没有恢复路径。人介入处理完，Agent 从哪继续？如果暂停即终止，团队就会倾向于不设暂停——因为重跑一次 batch 太贵了。暂停必须是「挂起」而非「终止」，恢复时带上下文。
3. 留痕只有日志没有因果链。事后复盘最需要的是「为什么这一步做了这个决定」——模型输入、当时挂载的工具集、温度参数。日志里只有最终动作，等于黑匣子只录了坠机前 3 秒。

一个自查清单

上生产前过一遍：错误动作能不能在 5 分钟内撤销？中断恢复是接续还是重跑？连续失败几次会自动停下来叫人？每个决策点能不能事后还原出当时的输入？

四个问题答不上来任何一个，就还没到放权的时机。

结语

这些做法来自我自己做工具时踩的坑——我们做 AI 翻译工具（随心翻译）时，批处理任务的自动重试和熔断就是按这套思路设计的：宁可多停一次，不可错跑一路。Agent 的能力上限由模型决定，生产下限由放权设计决定。