跳到主要内容

Agent Production Checklist

学完 Prompt、Context、RAG、Tool Use、Agent、Evals 和 Harness 之后，很多人会自然进入下一个阶段：

我是不是可以把这个 Agent 真正放到生产里用了？

但从工程角度看，Agent 从“能跑 demo”到“能交付上线”之间，往往还隔着很长一段距离。

因为生产环境真正关心的，不只是：

  • 它能不能做出一个看起来不错的结果

还包括：

  • 它稳不稳
  • 可不可控
  • 好不好排查
  • 出问题能不能收住
  • 迭代后会不会退化

所以这篇文档的目标非常直接：

给你一份 AI Agent 上线前值得逐项检查的生产清单。

1. 为什么需要 Production Checklist​

因为很多 Agent 项目在 demo 阶段主要靠这几种方式推进：

  • 试几个案例
  • 看起来不错
  • 改改 prompt
  • 再试几个例子

这在探索期完全正常。

但一旦进入生产，就会遇到更多现实问题：

  • 用户输入更脏
  • 任务范围更广
  • 工具失败更常见
  • 风险更难接受
  • 回归问题更容易出现

也就是说：

生产环境考验的不是“某一次跑得好”，而是“持续跑时是否可靠”。

2. 先看一条最简判断线​

如果一个 Agent 想进入生产，至少应该能回答下面这些问题：

  • 它解决的目标是否清晰
  • 它的边界是否明确
  • 它的工具是否可靠
  • 它的状态是否可控
  • 它的表现是否有评估依据
  • 它的风险是否有护栏
  • 它的问题是否可观测、可回归

如果这些问题里有很多还答不上来，那通常还在探索期，不在生产期。

3. Checklist 第一层：目标与边界​

3.1 目标是否明确​

先确认：

  • 这个 Agent 到底要完成什么任务
  • 成功标准是什么
  • 失败标准是什么

如果目标本身含糊，后面所有工程化都会变得模糊。

3.2 适用范围是否清晰​

要明确：

  • 哪类任务适合它
  • 哪类任务不适合它
  • 什么时候应该直接 fallback

一个成熟系统不是“什么都接”，而是知道自己该处理什么、不该处理什么。

4. Checklist 第二层：Workflow 与 Agent 形态​

4.1 是否真的需要 Agent​

先确认这件事是否必须依赖动态决策。

如果固定 Workflow 就够用，就没必要强行做重 Agent。

4.2 执行模式是否可解释​

例如：

  • 是 ReAct
  • 是 Plan-and-Execute
  • 是 Router + Executor

你最好能说清楚系统现在采用哪种形态，以及为什么。

5. Checklist 第三层：工具设计​

5.1 工具职责是否清晰​

每个工具最好做到：

  • 单一职责
  • 命名清晰
  • 参数明确
  • 返回结构稳定

5.2 工具失败是否可处理​

需要考虑：

  • 超时怎么办
  • 参数错了怎么办
  • 外部接口挂了怎么办
  • 是否支持重试

5.3 工具是否按风险分层​

最好明确：

  • 只读工具
  • 可写工具
  • 高风险工具

这会直接影响后面的 Guardrails 设计。

6. Checklist 第四层：State 与 Memory​

6.1 当前任务状态是否清晰​

系统至少应知道：

  • 当前目标
  • 已完成步骤
  • 当前证据
  • 下一步候选动作

6.2 Memory 是否谨慎设计​

不要把所有历史都塞成长期记忆。

要明确：

  • 哪些信息长期保留
  • 哪些只保留在 session
  • 哪些只属于当前任务状态

7. Checklist 第五层：Prompt 与 Context​

7.1 系统指令是否清晰​

例如：

  • 什么时候该调工具
  • 什么时候该停止
  • 什么情况下不能猜
  • 输出格式怎么约束

7.2 上下文装配是否有选择​

要确认：

  • 历史是不是过长
  • 检索资料是不是太杂
  • 工具结果是不是过度堆叠

很多生产问题其实是 Context 工程问题。

8. Checklist 第六层：Evals 与 Harness​

8.1 是否有代表性的任务集​

至少应包含：

  • 常规任务
  • 关键高价值任务
  • 边界任务
  • 历史失败案例

8.2 是否能做版本对比​

每次改动后，最好都能知道：

  • 哪些任务提升了
  • 哪些任务退化了

8.3 是否有分层评估​

Agent 不应只评最终答案，还应评：

  • 工具调用
  • 步数
  • 成本
  • 任务完成率

9. Checklist 第七层：Observability 与 Debugging​

9.1 是否记录了关键轨迹​

建议至少记录：

  • 每一步决策
  • 工具参数
  • 工具返回
  • 状态变化
  • 停止原因

9.2 问题是否能复现​

如果线上失败无法沉淀成：

  • 任务样本
  • 配置快照
  • 回归案例

那问题就很难真正被修复。

10. Checklist 第八层：Guardrails 与 Human-in-the-Loop​

10.1 高风险动作是否分层​

要明确：

  • 什么可以自动执行
  • 什么必须人工确认
  • 什么应该直接拒绝

10.2 是否有异常接管机制​

例如：

  • 多次失败后转人工
  • 风险不明时要求确认
  • 写入型动作进入审批

11. Checklist 第九层：性能与成本​

11.1 延迟是否可接受​

要确认：

  • 平均耗时
  • 高峰耗时
  • 是否有明显长尾

11.2 成本是否可控​

Agent 非常容易在多步循环里把成本拉高。

所以最好明确：

  • 平均 token 成本
  • 工具成本
  • 单任务成本上限

11.3 是否有限流和步数控制​

没有上限，系统很容易在异常情况下失控。

12. Checklist 第十层：Fallback 与运营​

12.1 是否有 fallback 路径​

例如：

  • 降级成固定流程
  • 改成只读模式
  • 直接交给人工

12.2 是否有上线后的持续观察指标​

例如：

  • 任务完成率
  • 工具失败率
  • 人工接管率
  • 用户满意度
  • 单任务成本

这能帮助你判断系统是真在进步，还是只是问题被藏起来了。

13. 一个很实用的上线前提问清单​

如果要快速做一次自检，你可以连续问：

  1. 我们知道它解决什么问题吗
  2. 我们知道它不该解决什么问题吗
  3. 我们知道它为什么这样规划吗
  4. 我们知道它调错工具时怎么发现吗
  5. 我们知道它失败时怎么复现吗
  6. 我们知道改完后怎么验证没有退化吗
  7. 我们知道高风险动作何时该让人接管吗

如果这 7 个问题都能比较清楚地回答，通常就已经比大多数 demo 更接近可交付系统了。

14. 常见误区​

14.1 构建通过就算可上线​

构建通过只说明代码能打包，不说明 Agent 已经准备好进入生产。

14.2 试了几个案例就算稳定​

单次成功从来不等于系统可靠。

14.3 只关注答案质量，不关注过程质量​

Agent 的很多风险恰恰藏在过程里。

14.4 只做能力，不做治理​

如果只有 Tools 和 Agent Loop，没有 Guardrails、Observability、Harness 和 Evals，系统通常很难稳定进入生产。

15. 一句话总结​

真正值得进入生产的 Agent，不只是“能做出结果”，而是：

目标清晰、流程可解释、工具可靠、状态可控、轨迹可观测、质量可评估、风险可收束、迭代可回归。

从这个角度看，Production Checklist 的价值不在于多一张表，而在于帮助你把“会跑 demo”升级成“能长期交付”的系统。