Agent 演示时惊艳上生产后吓人一个死循环烧光 API 额度、一次错误的工具调用删了数据、一句诱导让它把内部信息发了出去。上一篇讲了 Agent 的循环原理这篇讲怎么给它装护栏——让能力受限地释放。第一道护栏预算Agent 的循环必须有三重上限步数上限防死循环、token 预算防成本失控、时间上限防挂起。三道线任一触发Agent 软着陆输出当前进展、说明卡在哪里、交还给人。上限不是拍脑袋定的用历史运行数据统计「完成同类任务的平均步数」把上限设为均值的两到三倍。设太紧Agent 在临门一脚被掐死设太松护栏形同虚设。第二道护栏权限分层工具是 Agent 的手脚权限就是手套的厚度。设计原则默认只读写操作白名单危险操作二次确认。具体做法查询类工具直接给创建、修改类工具做参数校验加操作日志删除、支付、对外发送这类不可逆操作Agent 只能「生成待执行的操作单」由人或规则引擎复核后执行。很多人跳过第三层觉得影响自动化程度——但生产环境里一次不可逆的误操作就能毁掉用户对整个系统的信任。第三道护栏审计回放每一步都留痕模型输出的思考、每次工具调用的入参与结果、每轮的耗时与 token 消耗。这些日志的价值在出事之后能回放的 Agent 才能 debug才能优化工具描述才能在纠纷时自证清白。更进一步把审计日志喂回提示词优化统计哪类工具调用失败率高、哪类任务循环次数异常针对性修工具描述或加提示词约束。日志不只是免责证据是迭代燃料。一个反直觉的建议护栏不是加在最后的安全检查而是 Agent 设计的第一层约束。见过太多团队先做一个「全能自由」的 Agent出事后再一层层补限制——补出来的限制互相打架最后推倒重来。从最小权限的最小循环开始逐步放权才是稳的路径。