这套设计与模型供应商无关。MCP 2025‑06‑18 规范建议工具调用保持人在回路中，并提醒客户端不要信任未知 server 的 tool annotations。更重要的是：协议传输调用，产品决定调用是否被允许。readOnlyHint、destructiveHint 和 idempotentHint 都只是提示，不能替代自己的政策。

先给工具分风险

把工具分为只读、可逆写入、不可逆或外部影响三类。读取公开资料可以自动；创建内部草稿可以自动但需审计；发送消息、转账、删除、发布和修改权限默认需要人工。风险还取决于参数：读取当前用户文件和读取任意租户文件不是同一动作。

政策引擎接收真实用户、租户、工具、参数、资源和任务来源，返回 allow、deny 或 require_approval。模型没有权力修改此结果。工具描述、检索内容和 MCP server 返回值都按不可信输入处理。

审批发生在行动时

计划阶段可以让人确认方向，但真正审批必须在调用名称和规范化参数已经确定之后。审批界面显示动作、目标、影响、来源证据和可撤销性，不只显示模型摘要。批准记录绑定 call id、参数 hash、批准者、时间和过期时间；参数变化即失效。

批量批准要限制同类动作、目标集合、数量与时间窗。不能用“批准这个 Agent”代表未来所有行为。紧急停止必须能阻止尚未开始的调用，并撤销短期凭据。

幂等性是业务合同

模型重试、网络超时和 worker 崩溃都会重复请求。对每个写动作生成稳定业务幂等键，例如 task_id + step + normalized_target。执行器先在数据库占位，再调用外部系统；恢复时查询占位和外部结果，不凭模型记忆判断是否完成。

幂等不只是 HTTP header。若外部服务不支持，应在本地建立唯一约束和 reconciliation 流程。部分成功要保存可恢复状态，不能简单重跑整个批次。读取可以有限重试，权限拒绝和业务冲突不应自动重试。

追加式审计轨迹

每个调用按 proposed、validated、waiting_approval、approved、started、succeeded 或 failed 追加事件。事件包含模型与 prompt 版本、工具 schema 版本、参数摘要、policy decision、审批者、幂等键、结果摘要和 trace id。敏感值使用引用或 hash，不写入普通日志。

结果错误区分协议错误、工具业务错误、权限拒绝、超时和未知状态。未知状态最危险：必须 reconciliation，而不是直接重试。审计记录应能回答“谁授权了什么、执行了几次、外部事实是什么”。

默认拒绝的执行网关

只有注册表中的工具可执行；schema 验证后再做领域授权。凭据按任务最小化并短期有效，token audience 绑定正确资源，禁止把客户端 token 原样转发给下游。出站网络、文件根目录和数据库角色分别 allowlist。

为循环设步骤、时间、成本和失败预算。取消、审批超时或用户撤销后，网关拒绝后续调用。最终回答不是事实来源，外部系统与工具结果才是。

验收失败路径

测试重复提交、批准后改参数、worker 在外部成功后崩溃、伪造 tool annotation、跨租户 id、提示注入、审批过期和取消竞态。断言不仅是“Agent 最终完成”，还包括未批准副作用为零、相同幂等键最多一次、所有状态可解释。

可靠 Agent 的核心不是更长提示词，而是把模型放在提议者位置。政策引擎决定，人工批准高风险动作，执行器持有权限，数据库负责幂等和恢复。这样即使模型、MCP server 或网络出错，系统也能把影响限制在明确边界内。