第 15 章 · 审批策略

本章目标：区分“模型认为动作合理”“策略允许自动执行”和“人类本次批准”三个判断层。

1. 审批不是弹窗装饰

Agent 可以提出读文件、写代码、联网、删除和发送消息。不同动作的副作用不同。审批策略决定哪些动作自动执行、哪些必须询问、哪些直接拒绝。它是 Runtime 的规则，不应由模型自己决定是否需要询问。

最常见的结果是 allow、ask 和 deny。allow 代表在当前规则和沙箱内自动执行；ask 暂停 Turn 等待人类；deny 把拒绝作为工具观察返回，模型只能换方案或报告阻塞。

2. 策略依据什么判断

审批可以根据工具、命令前缀、目标路径、网络域名、副作用标注和项目可信度组合。读取 workspace 内普通文件通常风险低；修改 .git、访问主目录、执行网络安装和外部发送风险更高。

策略应尽量可解释。例如：“命令需要访问网络，而当前 workspace-write 禁止网络，因此请求一次扩展权限。”比“是否允许此命令”更利于人类判断。

3. 审批与沙箱不是一回事

审批回答“是否同意”，沙箱回答“技术上能触达什么”。即使人类没有看到恶意参数，沙箱仍应阻止命令访问未授权路径。反过来，沙箱允许 workspace 写入，也不意味着所有写入都无需审批。

两层结合形成纵深防御：

4. 策略模式

on-request 允许低风险动作自动执行，越界时询问；never 表示不能通过询问升级，适合无人值守任务；always 对每个副作用动作询问，安全但会造成审批疲劳。full access 或 bypass 不代表模型更聪明，只代表技术限制更少。

无人值守模式最安全的设计不是自动同意，而是自动拒绝需要升级的动作，让 Agent 在既有权限内寻找方案。

5. 审批请求需要哪些信息

一次好的请求应展示：实际动作、目标、为何必要、会产生什么副作用、是否可撤销、拒绝后有什么替代方案。对于 shell，还应展示规范化命令和 cwd；对于 MCP 工具，应展示目标服务和参数摘要。

批准可以是一次性，也可以形成窄规则，例如只允许 git fetch 前缀，而不是永久允许所有 git 命令。规则越窄，意外授权面越小。

6. 本章实验

实验 05 让你组合动作、目标、策略和沙箱。尝试让 read-only 沙箱修改 workspace，再把审批改为 always。观察审批可以请求扩大权限，但不会神奇地绕开系统边界。