工具调用改变的是故障半径
纯对话模型的错误主要是信息错误；带工具的 Agent 可能改配置、发消息、删文件、提交工单。故障半径取决于你暴露了哪些工具，而不是模型「看起来多聪明」。
因此设计顺序应是：先定允许的工具集合与数据范围，再定提示词与规划策略。反过来做，等于先给钥匙再讨论门禁。
权限分级：读、写、外部副作用分开
最低可行分级：
1. **只读**：查文档、查日志、列目录。
2. **受限写**：写到沙箱目录、创建草稿工单。
3. **高副作用**：发邮件、改生产配置、支付/删除、对外部系统提交。
默认给只读；写操作进沙箱；高副作用必须人工确认或双人复核。不要用「模型判断风险低」替代分级。
确认闸：把不可逆动作拦在执行前
对高副作用工具，执行前展示：将调用的工具名、参数摘要、影响对象、是否可回滚。确认记录写入审计。静默自动执行只适用于可逆且低损的动作。
参数侧还要做白名单校验：路径越界、URL 外域、超量批量，直接拒绝，而不是交给模型「注意安全」。
审计日志：事后能回答发生了什么
每次工具调用记录：时间、会话 id、工具名、参数摘要（脱敏）、结果状态、触发该步的模型决策摘要。出事故时，靠聊天回忆不够。
日志保留策略按合规要求设定，但生产 Agent 至少应能回溯到「哪一步开始偏了」。
回滚点：允许试错的前提
沙箱写操作应可丢弃；对外部系统优先「创建草稿 / 待审」而非直接生效。若必须直接生效，需有补偿事务或明确人工回滚手册。没有回滚点的自主执行，不适合做默认模式。
对抗评测：专门测越权与诱导
在评测集中加入：诱导访问未授权路径、要求跳过确认、伪造上级指令、循环调用耗尽配额。若 Agent 在对抗题上仍执行，说明门禁失败，与任务成功率无关。
局限与替代路线
沙箱会降低「全自动」体验，这是用效率换可控。对研究型个人助手可以更松；对共享生产环境必须更紧。
替代路线是人机协同：Agent 负责检索与起草，人负责确认提交。很多团队最终稳定在这个形态，而不是完全无人值守。
对工程团队的启发
把 Agent 当「带权限的自动化脚本」管理：最小权限、确认闸、审计、回滚、对抗评测。自主性是能力，边界才是产品。
合规自检
- 无导流与行动召唤。
- 含边界与替代路线。
- CSDN 公开首发专稿。
