生产级 Agent 治理清单：上线前必须回答的 30 个问题
这篇文章解决什么问题
Agent Demo 很容易做出来，但生产级 Agent 难在治理：
- 谁能调用？
- 能调用哪些工具？
- 出错怎么恢复？
- 成本谁负责？
- 数据是否泄露？
- 版本怎么回滚？
- 效果怎么评估？
- 高风险操作谁审批？
这篇文章给出一份上线前检查清单，用来判断一个 Agent 是否具备进入真实业务环境的基本条件。
一、任务边界
- 用户是谁？
- Agent 解决的具体业务问题是什么？
- 输入和输出是否定义清楚？
- 什么情况应该拒答或澄清？
- 什么任务明确不属于 Agent 范围？
如果任务边界说不清，就不要上线。
二、上下文与知识
- 系统规则、用户输入、RAG 证据、工具结果是否分层？
- RAG 文档是否有来源和权限过滤？
- 进入上下文的证据是否可追踪？
- 长任务是否有上下文压缩策略？
- 是否防止 RAG 文档中的恶意指令影响系统规则？
上下文治理决定 Agent 是否稳定。
三、工具和权限
- 工具是否有 schema、描述和参数校验？
- 工具是否按风险分级？
- 高风险工具是否需要人工审批？
- 写操作是否有幂等设计？
- 所有 tool_call 是否进入审计日志？
Agent 的安全边界主要在工具层。
四、状态和恢复
- 是否有结构化 State？
- 长任务是否支持 checkpoint？
- 服务重启后是否能恢复任务？
- 工具失败后是否有重试和降级策略？
- 人工审批状态是否持久化？
没有状态恢复，就不适合长任务。
五、模型调用治理
- 模型调用是否经过统一 Gateway？
- 是否记录模型、Prompt 版本、token 和成本？
- 是否有超时、限流和重试？
- 是否有模型降级策略？
- 是否能回滚 Prompt 或模型策略？
模型调用不能散落在业务代码里。
六、评测和质量
- 是否有 smoke eval？
- 是否有 regression eval？
- 是否有失败样本库？
- 是否能定位失败来自检索、模型、工具还是状态？
- 是否有人工作业反馈闭环？
没有评测，Agent 迭代就是凭感觉。
七、日志与审计
上线前还要确认：
- 日志不包含 API Key。
- 日志不保存完整敏感隐私。
- Trace 能关联 run、step、model_call、tool_call。
- 高风险操作能追溯到用户和审批人。
- 错误类型结构化。
日志既要能排查问题，也不能成为泄露源。
八、成本和限流
必须能回答：
- 每个用户/租户的调用量是多少？
- 每类任务的平均 token 成本是多少？
- 失败重试消耗了多少？
- 多 Agent 是否造成重复调用？
- 是否有每日/每月预算？
- 超预算后怎么降级？
成本不可见的 Agent 很难长期运行。
九、发布和回滚
上线前需要：
- 明确版本号。
- 保存 Prompt 版本。
- 保存工具 schema 版本。
- 保存 RAG 参数版本。
- 灰度发布。
- 回滚方案。
- 发布后观察指标。
Agent 系统的行为由模型、Prompt、上下文、工具和数据共同决定，任何一层变化都可能影响结果。
十、最小上线门槛
一个最小可上线 Agent 至少应该具备：
- 明确任务边界。
- 工具白名单和权限。
- 结构化 State。
- Trace。
- smoke eval。
- 高风险审批。
- 成本记录。
- 错误分类。
- 回滚方案。
不具备这些能力时，可以作为 Demo，但不要包装成生产级系统。
面试表达
可以这样讲生产治理：
我判断一个 Agent 能不能上线，不看它是否能在 Demo 中回答几个问题，而看它是否具备治理能力。上线前我会检查任务边界、上下文分层、工具权限、State 恢复、Trace、Evaluation、模型 Gateway、成本、日志脱敏和回滚。高风险工具必须审批，写操作必须幂等，所有 run/step/tool_call/model_call 都要可追踪。这样即使模型输出不稳定，也能通过系统边界把风险控制住，并通过评测和失败样本持续迭代。