Agent 最大的特点，也是最大的风险：它能主动调用工具。上一篇文章聊了怎么选一个"敢用"的模型，这一篇聊更实际的问题——模型选好了，怎么让它放心干活？
给 Agent 划边界，不是限制它的能力，而是让它在可控范围内自由发挥。上线之前，这 5 件事值得先定下来。
一、身份权限：最小化
Agent 用什么身份执行任务，决定了它能碰到什么。
常见的做法是给 Agent 开一个独立账号，只授它实际用到的权限：读写哪些表、调哪些接口、访问哪些目录，按需开通；数据库的敏感字段、生产环境的配置，默认拒绝访问，用到再单独开。
用最小权限身份跑 Agent，即便工具调用出错，影响面也只在授权范围内。
二、工具沙箱：隔离执行
涉及文件读写、代码执行、系统命令的 Agent，建议在隔离环境里跑——容器或沙箱都行，出问题关掉重开，不影响主环境。
第三方工具（比如接入的 MCP server）接入前，值得先过一遍它声明了哪些权限、能访问哪些资源。高危写操作——删除、覆盖、转账、对外发消息——默认关闭，只在明确需要时按场景放开。
三、预算配额：熔断兜底
模型调用是实打实的成本，失控的 Agent 会在重试循环里把钱烧掉。
上线前定几个数：单任务的 token 上限、单位时间的调用次数、月预算红线。超过上限自动熔断，停止调用并告警。熔断防的不是正常使用，是出 bug 时的无休止重试。
四、人工审批：关键动作卡点
有些操作不可逆，或会对真实世界产生影响：发邮件、付款、删数据、改配置。
这类动作建议设为"Agent 提议、人工确认"：Agent 把要执行的内容准备好，推给人工审批，确认后才真正执行。审批点不需要多，覆盖不可逆和对外影响这两类就够。
五、可观测与回滚：出了问题能还原
没有日志的 Agent 等于盲跑。上线前把链路日志接好：哪个任务、调了哪个工具、传了什么参数、返回了什么结果，全程留痕。
数据改动最好带备份或版本管理，改错了能回滚。出了问题先还原，再排查，比现场救火省心得多。
上线前自查清单：
- Agent 用的是最小权限身份吗？
- 文件/代码操作在隔离环境里吗？
- 预算和调用次数有上限、超限会熔断吗？
- 不可逆操作有人工审批点吗？
- 全程有日志、能回滚吗？
5 项都打勾，再让 Agent 上线。先画边界，再谈能力。
