审批门(permission gate) 工具与循环
别名:
审批门 · 交互门
`approve` 级工具执行前的拦截点,分两层:主循环的**交互门**(会问人、会暂停)与 `executeTool` 的**硬门**(不认人、只认审批记录,拿不出记录即拒绝)。任何绕过交互门的调用方在硬门前都拿不到执行权——安全默认拒绝(fail closed)。
它是什么
审批门(permission gate)是 approve 级工具执行前的拦截点,分两层:主循环的交互门(会问人、会暂停——await getApproval(request))与 executeTool 的硬门(不认人、只认审批记录,拿不出记录即拒绝)。任何绕过交互门的调用方——一个忘了审批的集成、一个 bug、未来的某个界面——在硬门前都拿不到执行权。
硬门的实现
const risk = entry.spec.risk ?? 'auto';
if (risk === 'approve') {
const approved = options.requestId != null && options.approvedRequestIds?.has(options.requestId);
if (!approved) {
return { ok: false, denied: true, error: `tool ${name} requires approval (risk=approve); call denied` };
}
}
这是 fail-closed(安全默认拒绝):拿不出审批记录 = 不执行,而不是「可能没事,放行吧」。交互门在 loop 层、硬门在工具层,两层是纵深防御(见 defense-in-depth):即使交互门被绕过,硬门仍然拦截。
与沙箱的分工
审批门管「该不该做」(意图),沙箱管「能做多坏」(能力,见 sandbox):人类批准了危险参数也没用,路径约束/命令白名单仍然拒绝。Claude Code 的 allow/ask/deny 与 auto mode 分层裁决、OpenAI Agents SDK 的 needs_approval + 中断恢复,是同一思路的厂商实践。
在本教程的位置
第 18 章「主循环:审批门」与「工具层:审批硬校验」两节;第 17 章的 waiting_approval 状态是它的前端接缝。相关词条:人在回路、风险分级。