上一篇：第 18 篇《Agent 如何做 Benchmark》
下一篇：第 20 篇《组件都学完了，为什么还是写不出企业级 Agent》

发布时间：2026-07-12
标签：AI Agent｜LLM｜生产部署｜工程实践｜Checklist

---

本文是 [AI Agent 工程实践] 系列的第 19 篇（第二季收官）。

---

Demo 跑通的那天，我觉得可以上线了。Prompt 能出结果、Tool 能调通、答案看起来不错。

上线第一天：一个长任务跑了 30 分钟后 OOM——没有断点恢复，从头重跑。一个 Tool 返回了脏数据——没有 Trace，花了两小时才定位。用户投诉"答案时好时坏"——没有 Benchmark，不知道是哪个 commit 搞坏的。

我盯着屏幕想：Demo 和 Production 之间，差的从来不是"模型好不好"，而是你的 Agent 有没有这些东西。

Demo Agent 只需要跑通一次，Production Agent 需要跑对每一次。这中间差的，就是这份 Checklist。

---

本文你将学到

✓ 一个真正能上线的 Agent，必须覆盖的十个维度
✓ 每个维度对应的"通过标准"——不是"做了就行"，是"做到什么程度才算"
✓ 一份可直接打印的生产就绪度自检表
✓ 第二季 10-18 篇的完整回链——每个维度对应哪篇详解

适合阅读

✓ Demo 跑通了、准备上生产的人
✓ Agent 上线后问题不断、不知道哪里还缺的人
✓ 想把 Agent 当作"产品"而非"玩具"交付的人

---

问题背景

99% 的 Agent 教程在教你"怎么做一个 Demo"——写 Prompt、调 Function Call、连一个 Tool。Demo 跑通了，教程结束了。

但 Demo 和 Production 之间的鸿沟，没人告诉你。我把踩过的生产事故总结成了十件事，缺任何一件，上线的 Agent 都会在某天出问题。

这十件事不是"最佳实践建议"——是我炸过的十个坑，每一个都有对应的系列文章讲清楚为什么炸、怎么修。这篇是把它们压缩成一张表：上线前逐条检查，全过才算生产就绪。

---

关键观察

Demo Agent 和 Production Agent 的区别，用一张表对齐：

维度	Demo Agent	Production Agent
跑通	手动跑通一次	每次改动后自动 Benchmark 回归
出错	重试 or 放弃	State 断点恢复 + Retry 兜底
调试	看终端输出	Trace 串联全链路
升级	靠感觉"好像变好了"	Benchmark 量化对比
安全	不考虑	Tool 审批 + 数据脱敏

Demo Agent 只需要跑通一次，Production Agent 需要跑对每一次。

能跑通不等于能上线——中间差的就是这份 Checklist。

---

最终方案：Agent 生产就绪十大 Checklist

十维总览

逐项详解

1. Rules · 行为底线

问题：Agent 的行为不受约束，想做什么做什么。

通过标准：

• core/ 常驻规则 ≤ 5 条（超过就是噪声，参见 01 篇）
• heavy/ 能力文件按任务类型触发（不是全开，参见 05 篇）
• 每条规则有明确的触发条件（Trigger），没有"永远加载"的无效规则

对应文章：[01] Rules 分层 / [05] Rule Router

---

2. Review · 复盘闭环

问题：出了问题不沉淀，同一个坑反复踩。

通过标准：

• 有 Daily Review 机制（记录当天被手动修正的输出，参见 04 篇）
• 有 Weekly Review 机制（同类问题 ≥2 次 → 沉淀为规则，参见 06 篇）
• 复盘结果能回流到 Knowledge 或 Rules 层（不是"记了就完了"）

对应文章：[04] Review 复盘 / [06] Knowledge→Rules

---

3. Memory · 记忆系统

问题：Agent 没有长期记忆，每次都从头教。

通过标准：

• 区分了 Conversation / Working / Long / Archive 四层（参见 03/10 篇）
• 长期记忆有 Promition 机制（复用 ≥2 次或用户明确要求才晋升）
• 有清理机制（过期/冷数据/冲突自动降级或删除，参见 15 篇）

对应文章：[03] Memory 设计 / [10] Memory 架构 / [15] RAG 知识治理

---

4. Security · 安全治理

问题：Agent 可能执行危险操作或泄漏用户数据。

通过标准：

• 高危 Tool（Shell/DB Write）有审批机制（参见 13 篇）
• 传给 LLM 的数据经过脱敏（PII / 密钥过滤）
• Tool 的输入有 Schema 校验（类型/范围/正则约束）
• 有 Rate Limit 和 Token 预算上限

对应文章：[13] Tool Calling

---

5. Workflow · 编排能力

问题：多步任务没有编排，Agent 丢步骤或上下文爆炸。

通过标准：

• 复杂任务有 Planner → Execute → Review 链路（参见 11 篇）
• 有回退机制（Review 不通过 → 回到 Execute 或 Planner）
• 状态在节点间传递（不是靠 prompt 拼接，参见 16 篇）
• 没有不必要的 Multi-Agent（步骤多 ≠ 该拆 Agent，参见 08/12 篇）

对应文章：[08] Multi-Agent 决策 / [11] Workflow 实现 / [12] Multi-Agent 失败 / [16] State

---

6. Retry · 容错恢复

问题：Agent 一步出错就全盘垮掉。

通过标准：

• Tool 调用有分类重试（Schema 错修参数 / 超时退避 / 工具不存在换工具，参见 13 篇）
• Agent 有断点恢复能力（挂了从 checkpoint 续跑，参见 16 篇）
• 重试有上限（不是无限重试，超限后降级或人工介入）
• 有 Waiting 状态（不等外部事件时不阻塞，参见 16 篇）

对应文章：[13] Tool Calling / [16] State

---

7. Trace · 调用链

问题：出了错不知道哪个环节的问题。

通过标准：

• 每次 Agent 运行有唯一的 Trace ID（不是零散日志 ID）
• 每个 LLM 调用 / Tool 调用 / 状态转换都是一个 Span（参见 17 篇）
• Span 记录了 input/output tokens、latency、是否成功
• 能从 Trace 还原完整决策链（"为什么得出这个结论"，参见 17 篇 Audit）

对应文章：[17] Observability

---

8. Metrics · 指标

问题：不知道 Agent 整体健康度。

通过标准：

• 有成功率（Success Rate）——不是靠感觉
• 有成本（Token 消耗 × 单价）——知道花了多少钱
• 有延迟 P50/P95/P99——知道多快
• 有 Tool 调用次数——知道效率
• 指标有 Dashboard（不是翻日志找，是一眼看）

对应文章：[17] Observability / [18] Benchmark

---

9. Benchmark · 回归评测

问题：改了一行 Prompt，不知道是变好还是变坏。

通过标准：

• 有标准任务集（不是顺手跑几个 case，参见 18 篇）
• 每次 commit 自动跑 Benchmark（CI/CD，不是手动跑）
• 有四维评分（Success Rate + Cost + Time + Tool Calls）
• 和历史 baseline 对比——退化自动阻止合并

对应文章：[18] Benchmark

---

10. Logging · 审计与合规

问题：出了安全事故无法追溯。

通过标准：

• 有结构化日志（JSON，不是 print 字符串）
• 每条日志含 Trace ID + 时间戳 + 用户 ID + 操作类型
• 日志有保留策略（不是永远不删，也不是随便删）
• 敏感数据不写入日志（PII、密钥脱敏后再记录）

---

完整生产就绪度自检表

#	检查项	通过	对应篇
1	Rules：core ≤ 5 条，heavy 按触发条件加载	☐	01/05
2	Review：有日/周复盘，复盘结果回流到 Rules	☐	04/06
3	Memory：四层分层 + Promotion + 清理机制	☐	03/10/15
4	Security：高危 Tool 审批 + 数据脱敏 + Schema 校验	☐	13
5	Workflow：Planner→Execute→Review + 回退机制	☐	08/11/12/16
6	Retry：Tool 分类重试 + Agent 断点恢复	☐	13/16
7	Trace：Trace ID 串联 + 完整 Span + Audit Trail	☐	17
8	Metrics：四维指标 + Dashboard	☐	17/18
9	Benchmark：标准任务集 + CI 回归 + 四维评分	☐	18
10	Logging：结构化 + Trace ID + 审计保留	☐	—

十个全过，Agent 才不是 Demo。 缺一个，生产环境会在某一天替你做 checklist——用事故的方式。

---

代码或配置示例

生产就绪度自检脚本

def production_readiness_check(agent) -> dict:
    """上线前自检——十个维度逐一检查"""
    checklist = {
        "rules": check_rules_layer(agent),        # core ≤ 5, heavy 有 trigger
        "review": check_review_loop(agent),        # 日/周复盘存在
        "memory": check_memory_layers(agent),      # 四层分层 + promotion
        "security": check_security(agent),         # 审批 + 脱敏 + schema
        "workflow": check_workflow(agent),         # P→E→R + 回退
        "retry": check_retry(agent),               # Tool 分类重试 + checkpoint
        "trace": check_tracing(agent),             # Trace ID + Span
        "metrics": check_metrics(agent),           # 四维指标 + Dashboard
        "benchmark": check_benchmark(agent),       # 任务集 + CI + 回归
        "logging": check_logging(agent),           # 结构化 + 审计
    }
    passed = sum(checklist.values())
    return {
        "total": len(checklist),
        "passed": passed,
        "ready": passed == len(checklist),         # 全过才是生产就绪
        "details": checklist,
    }

跑一遍这个脚本，比"感觉可以上线了"可靠一万倍。

---

总结

✅ Demo Agent 只需要跑通一次，Production Agent 需要跑对每一次。
✅ 十个维度的生产就绪标准：Rules / Review / Memory / Security / Workflow / Retry / Trace / Metrics / Benchmark / Logging。
✅ 每个维度不是"做了就行"，是"做到什么程度才通过"——Checklist 给出了明确的通过标准。
✅ 十个全过，Agent 才不是一个 Demo。缺一个，生产环境会用事故来提醒你。

---

第二季回链

第二季 · 工程实现（10-19） 把第一季的架构决策落地为可运行的工程系统：

篇	主题	对应清单项
10	Memory 架构实现	Memory
11	Workflow 实现	Workflow
12	Multi-Agent 失败分析	Workflow
13	Tool Calling	Security / Retry
14	MCP 协议	—（基础设施）
15	RAG 知识治理	Memory
16	State 状态管理	Workflow / Retry
17	Observability 可观测性	Trace / Metrics
18	Benchmark 评测	Metrics / Benchmark
19	生产 Checklist（本篇）	全部

---

本文是 [AI Agent 工程实践] 系列的第 19 篇（第二季收官）。

系列导航

上一篇：第 18 篇《Agent 如何做 Benchmark》
下一篇：第 20 篇《组件都学完了，为什么还是写不出企业级 Agent》