Latch 审批关卡

问题：代理执行链缺少统一决策点

当 Agent 通过 MCP 直接调用工具时，"这一步能不能做"的判断通常散落在提示词或业务代码里。安全边界依赖模型自觉，而非可执行的策略约束；一次高风险操作（执行 shell 命令、向外发送消息）可能已经进入工具调用阶段，才发现缺少人工确认。

核心思路：策略评估前置

Latch 在 Agent 与上游 MCP server 之间插入一个策略与审批层。每次工具调用先经过策略评估，结果只有三种：

• allow：安全操作直接放行，不打断执行流；
• deny：被拒绝的调用不会触达工具；
• require approval：高风险操作暂停，等待人工审查后再继续。

也就是说，"哪些动作算风险"不再交给模型临场判断，而是由策略集中声明——例如 shell 命令与外部发送被标记为需要审批，普通只读调用自动继续。

工作方式与关键步骤

• 将 Latch 作为上游 MCP server 的包装层启动，代理侧的工具端点指向 Latch，而非直接指向原始服务；
• 调用发起后先做策略评估，按返回结果决定放行、拦截或转入审批队列；
• 需审批的操作在检查点暂停，人工确认后才恢复执行。

适用边界与注意点

• Latch 解决的是调用前的策略拦截，不替代工具自身的权限与审计机制；
• 策略声明需要覆盖全部工具入口，绕过包装层的直连调用不受保护；
• 审批延迟会直接叠加到执行链上，延迟敏感的场景需要权衡。