AI 工具调用为什么要有预演模式：先看变更，再决定是否真正执行

AI Agent 最容易让用户不安的不是它不会回答，而是它可能在用户还没看清参数时就执行了动作。删除文件、修改配置、创建资源或发送消息，都应该把“计划做什么”和“已经做了什么”分成两个阶段。预演模式就是在真正提交前生成一份可审查的变更计划。

预演结果要具体到参数和影响范围

一个合格的预演结果至少包含工具名、调用参数、目标资源、预计影响、风险等级、所需权限和过期时间。对于更新动作，最好展示差异；对于批量动作，展示数量、筛选条件和示例。只显示一句“即将执行操作”没有帮助，用户无法判断 Agent 是否理解正确。

风险分级决定谁能提交

读取、搜索和计算类动作可以自动执行；写入、外发和权限变化类动作需要确认；删除、付款、生产发布和跨租户操作应进入更严格的审批。风险级别不能只由工具名称决定，还要结合参数、目标环境、资源数量和用户身份。

预演结果应有短时效。用户确认后，系统再次检查参数哈希、权限和资源状态，避免“先预览、后被别人修改、仍按旧计划提交”。如果状态已经变化，应让用户重新确认，而不是静默套用旧计划。

网关和工具服务各负其责

网关可以统一记录请求、模型、工具名、参数摘要和审批结果，但真正的权限校验必须在工具服务侧完成。工具服务要拒绝客户端伪造的“已审批”字段，并对提交动作提供幂等键和结果查询。对于多模型场景，应该把同一份工具 schema 和风险策略应用到不同上游。

使用 top-api.cc 作为统一调用入口时，可以先把模型输出的工具调用转成待确认事件，再由业务系统提交。这样既能比较不同模型的调用意图，也能避免某个供应商的 SDK 默认行为绕过审批。

测评预演模式的六个问题

• 预演是否展示真实的目标和影响范围；
• 参数被修改后是否要求重新确认；
• 模型切换后风险级别是否仍然生效；
• 审批人是否能看到足够的上下文但不接触多余隐私；
• 提交失败或部分成功时是否有明确回执；
• 重复提交是否会重复产生副作用。

预演模式不是给 Agent 加一层漂亮的确认弹窗，而是把意图、授权、提交和结果拆成可审计的状态机。高风险工具宁愿多一次确认，也不要把用户只能事后发现的动作当成“自动化效率”。

参考资料：OWASP 对过度代理权限和不安全工具调用的风险说明，以及各 Agent 框架关于 human-in-the-loop 的公开文档。产品实现仍需结合自己的权限模型。

如果要在不同模型之间对比工具调用的风险，可以通过 top-api.cc 固定 schema 和策略，把模型差异留在意图生成层，把最终提交留在业务审批层。