智能体在 demo 里惊艳、在生产里翻车，差距往往不在模型，而在上线前漏查了几项。模型选得好、提示词写得妙，也架不住「默认给了全盘文件权限」「工具挂了没有兜底」「一次循环烧穿预算」。本文给一份投产前必查的清单，覆盖权限、可观测、兜底、成本、评估、安全、回滚与数据八项，照着打勾，就能把「能跑」变成「敢放」。
为什么需要上线前清单
传统服务上线有发布单，智能体却常被「它看起来能用」放行。但智能体是非确定性的：同样的输入可能走不同路径，风险不在代码编译期，而在运行期。一份清单的价值，是把那些「事后才想起」的坑前置成发布门禁。它不保证零事故，但能挡掉绝大多数低级翻车——尤其是权限和成本这类一旦出事就难收场的。
权限：模型能调什么、不能调什么
第一道闸是权限。默认最小原则：只给智能体完成任务必需的读写范围，高危操作（删除、外发、支付）必须显式二次确认。别因为「方便调试」就给全盘目录或管理员令牌，那是事故温床。关于怎么把权限拆到刚好够用，智能体权限最小化 给了具体落地方法。
可观测：出问题知道去哪看
放出去之前，先确认你能看见它。每次模型输入输出、每次工具调用的参数与返回、每轮耗时，都要有 trace 串联。没有可观测性，线上出问题你只能盲猜。把这套基座和 智能体调试实践 里的回放复现打通，事故定位能从几小时压到几分钟。
兜底与降级：工具挂了怎么办
智能体依赖的外部工具迟早会挂。上线前必须想清楚：某个工具超时时，是重试、降级还是直接报错给用户？调用失败返回是否结构统一，不会被模型当成正常结果？没有兜底规划的智能体，一次第三方抖动就能把它带崩。
成本护栏：别让一次循环烧穿预算
智能体最危险的失败模式是「自我循环」：反复调工具、反复重试，token 像漏水一样烧。上线前要设硬上限：单轮调用次数、单次会话预算、并发数。护栏不是限制能力，而是给失控兜底——没有护栏，一次 bug 可能是一张天价账单。
评估与红队：上线前先打分数
别靠「我觉得行」放行。用评估集量化关键场景的通过率，再用红队思维故意喂刁钻输入、越权指令、注入内容，看它会不会中招。评估不是上线后的事后诸葛，而是发布门禁的硬指标。方法可参考 智能体评估指南，把通过率钉进发布条件。
回滚与数据：出错能撤、隐私合规
智能体若会写数据，必须能回滚：操作幂等、留审计日志、有撤销路径。同时守住数据底线——别把用户原文、密钥写进日志或拿去训练，敏感字段落盘前脱敏。合规和回滚是「出大事时还能救」的保险，平时不起眼，出事时是救命绳。
把清单固化成发布门禁
清单最大的敌人是「这次赶进度先跳过」。最好的做法是把它做成自动化发布门禁：CI 里跑权限检查、成本护栏单测、评估集，全绿才允许进生产。人靠自律，系统靠规则——把清单固化进流程，它才不会在关键时刻被忘记。
- 权限最小化：只给必需读写范围，删除/外发/支付等高危操作显式二次确认。
- 可观测就位：模型输入输出、工具调用、耗时都有 trace 串联，出问题能定位。
- 兜底规划：工具超时/失败有明确重试、降级或报错策略，返回结构统一。
- 成本护栏：设单轮次数、会话预算、并发硬上限，防自我循环烧穿预算。
- 评估红队：用评估集打通过率，故意喂越权与注入输入看是否中招。
- 回滚能力：写操作幂等、留审计日志、有撤销路径，出错能撤。
- 数据合规：敏感字段脱敏，不把用户原文或密钥写进日志/拿去训练。
- 固化门禁：把以上检查做成 CI 发布门禁，全绿才进生产。
常见问题
小项目也需要这套清单吗？
清单和上线的灰度发布有什么区别？
成本护栏设多严合适？
评估集要自己建吗？
评论 (0)