在 Agent 触碰生产数据之前：护栏检查清单

为什么 Agent 是另一个风险类别

产生幻觉的聊天机器人，产出的是一句错话。带工具权限的 Agent，产出的是副作用：一条记录被更新、一封邮件被发出、一行数据被删除。失效面不再是文本质量，而是动作的影响半径。这也正是这里真正重要的控制措施看起来更像基础设施安全、而不像提示词工程的原因。

检查一：它到底能碰到什么

把 Agent 能调用的每个工具、以及每个工具能对状态做什么，全部写下来。多数团队在这一步会发现：某个只读辅助工具和某个会写东西的组件共用一份凭证。请按工具（而不是按 Agent）收敛凭证，并优先使用会过期的令牌。

检查二：不可逆动作上有闸门吗

把每个动作归类为可逆、费力可逆、不可逆。第三类必须有人工确认步骤，而且这个步骤不能被 Agent 正在阅读的内容里一句巧妙的指令绕过。注意，不可信输入不只是用户的提示词——还包括 Agent 消费的文档、网页和工具返回结果。

检查三：能否重放发生了什么

你需要每次工具调用的追踪，含参数与结果，并保留到足以复盘一次事故。出问题时，被问的从来不是「模型说了什么」，而是「它做了什么、以什么顺序做的」。

检查四：有预算吗

给每次运行设上限：步数、token、墙钟时间、金额。失控循环是最常见的 Agent 事故，而预防成本极低。把这个上限暴露在产品里，让用户看到的是「到限了」而不是「卡住了」。

检查五：输出格式错误时怎么办

在你需要之前就定义好失败路径。Agent 返回无法解析的工具调用时，是重试、问用户，还是停下？静默无限重试和静默放弃都是糟糕的默认值；请有意识地选一个，并记录它。

检查六：一个人能关掉它吗

必须有一个单一开关，无需发版就能停止全部 Agent 活动。这听起来理所当然，却经常缺失——因为 Agent 往往作为功能被嵌在其他系统里，而不是作为一个有自己的紧急停止开关的服务来部署。