技术 · 熟练
审批门拦下来了，它执行的还是你批的那一下吗？
冻结参数 · 批准不等于执行 · 服务端留痕
「危险动作先拦下来等你点头」这件事，已经有一页讲过了 —— 但拦下来之后还有三个坑。第一个：你批准时看到的那一组参数，跟它真正执行时用的参数，可能不是同一组 —— 只要让它凭记忆重建调用，差一个字符就是另一个动作。第二个：系统的日志会把「用户点了同意」记成一次成功，而下游接口完全可能反过来拒绝或者超时。第三个：客户端记的那份 tool_use 日志不算你的日志 —— 客户端可以自动批准、可以跳过记录，审计要的是服务端在每次调用前后都留下的一条。关键动作只有一个：审批门冻结参数 —— 批准之后执行的是那条被冻结的请求，不是模型重新拼出来的一条。
方法 · 一图看懂
1
先把粒度收对 — 「批准了这个工具」太粗：同一个 server 里 search 与 delete 是两件事
2
冻结参数 — 批准时看到的请求就是执行时用的请求，⛔ 不让模型重建
3
批准与成功分开记 — 同意是同意，成功是成功；两件事分别落一条记录
4
留痕落在服务端 — 客户端日志不算你的日志，审计要的是调用前后各一条
原理 · 为什么有效
为什么这里的粒度必须是「动作 + 资源」，不能是「工具」。一个 MCP server 常常把 search_documents 和 delete_folder 挂在同一张工具表里 —— 你批准了「这个服务器的工具」，等于把它们一起批准了。正确的策略要细到「谁 · 对什么资源 · 做哪个动作 · 在什么条件下」，同一张工具表里的两个动作必须能分别拦住。第二条原理是「冻结」这个词。审批流常见的实现是：拦住 → 问用户 → 用户同意 → 让模型重新发起一次调用。问题是模型重建的那一次，参数是它「记得的」，不是评审者看到的；差一个 ID、差一个路径、差一个数量，就是另一个动作。稳妥的做法只有一条：执行的是审批时被冻结的那条请求。第三条原理最容易被漏：批准 ≠ 执行成功。用户点了同意，只说明这一步被授权；下游 API 仍然可以超时、可以拒绝、可以部分完成。把两件事合成一条日志，你事后就无法回答「这条到底改没改成」。
适用场景
适用：你的 agent 会调用带副作用的工具 —— 删文件、改数据库、发消息、动生产环境配置 —— 而且你打算让它在你不在场的时候也能跑。也适用：你在给团队做 agent 治理，需要向别人解释「哪些动作必须有人点头、点了头之后怎么核」。不适用：只读场景（查文档、检索、看日志）—— 那类用允许清单 + 记录就够，硬加审批门只会造成审批疲劳，而疲劳本身就是安全问题；也不适用：把审批写在提示词里 —— 那不是门，那是建议。
自测 · 5 问
我批的是「这个工具」还是「这个动作 + 这个资源」？同一张工具表里有没有能绕过的那一个？
批准之后，执行的参数是我看到的那组，还是它重新拼的一组？
我的日志里，「用户同意」和「执行成功」是不是被记成了同一条？
这些记录是服务端留的，还是只存在于客户端的会话记录里？客户端自动批准时还会留吗？
哪些动作真的需要有人点头 —— 我有没有把低风险动作也塞进审批，造成审批疲劳？
怎么上手 · 验证步骤
照这个顺序上手：第一步先选一个破坏性动作 —— 只挑一个（比如「删除一批记录」），把它单独关上门，别的先不动；一次全上会立刻变成审批疲劳。第二步写清门要拦什么 —— 在服务端代码里按「动作 + 资源 + 条件」判，把阈值写在策略里（改多少条以上要批、动哪个库要批）。第三步把参数冻结进记录 —— 需要审批的调用先落一条 pending，把人看到的那组参数一起存下来；批准后执行那条存下来的，不让模型重发。第四步把三件事分开记 —— 请求、决定、结果各一条，并且都由服务端写。第五步先测三种结局 —— 批准、拒绝、超时过期，三条都跑通再扩大策略。
做完这一轮，自己对照三件事：① 找一个被拦住的动作，把它批准前后的参数打印出来，逐字段比一遍 —— 有任何一个字段不一致就说明没冻结住 ② 在日志里搜一次那条被拒绝的调用，确认它没有留下「已执行」的记录 ③ 试着在客户端侧把自动批准打开，看服务端还会不会照常留痕 —— 如果会，说明留痕真的在你的服务端，不在客户端。