Agent 能调工具之后：先定沙箱边界，再谈自主执行

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