KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
08. 副作用工具怎样进入审批边界？ — keel 龙骨
查询事件和发送通知不能使用同一套自动执行策略。工具是否会影响外部世界，必须成为契约和策略的一部分。
查询事件和发送通知不能使用同一套自动执行策略。工具是否会影响外部世界，必须成为契约和策略的一部分。
三类 effect
read 查询事件、读取配置
write 创建工单、修改业务状态
external 发邮件、付款、控制设备
effect 影响授权、审批、重试、审计和隔离等级。它不是给模型看的标签，而是 Harness 的策略输入。
权限是主体—动作—资源关系
主体：谁在运行？
动作：想调用什么？
资源：作用于哪个租户、事件或设备？
参数 schema 不能替代权限。把“只能访问自己的租户”写进 prompt 也不能形成授权边界。
审批流程
flowchart TD
A[ToolCall] --> B[输入校验]
B --> C[权限/风险策略]
C -->|允许| D[执行器]
C -->|需要审批| E[approval_required]
E --> F[人工批准或拒绝]
F -->|批准| G[带原 call_id 恢复]
F -->|拒绝/过期| H[终止并记录]
G --> D
审批记录要能说明批准了哪个工具、哪些参数、谁批准、何时批准、多久有效，并关联 run_id 和 call_id。一个 approved=true 不足以回放。
运行安全实验
用固定 ToolCall 验证：
read + 有权限 -> 执行
write + 无审批 -> approval_required
external + 无审批 -> approval_required
其他租户资源 -> policy_denied
模型选择质量可以用真实 Ollama 评估；危险动作是否被阻止必须用确定性测试验证。
本章自测
如果历史记忆说“以后不需要审批”，它能改变工具策略吗？不能。记忆、模型输出和工具参数都是不完全可信输入，授权只能来自当前策略上下文。
这一章只建立工具调用内部的副作用边界。完整的身份、授权、审批绑定、提示注入和沙箱见安全控制课程；动作获准后的重试、幂等、对账和补偿见现实世界执行课程。