前两篇讲了 Tracing 和评估。这一篇讲 Replay 调试——LangSmith 的一个杀手锏功能，对 Agent 调试价值极大。
传统软件调试靠断点：在代码某行停下，看变量，单步执行。但 Agent 这种程序，断点调试不好使——它是多步的、有状态的、不确定的。Replay 提供了一种更适合 Agent 的调试方式。
传统断点调试对 Agent 的局限
传统断点调试假设：代码是确定的，同样输入同样路径。但 Agent 不是：
- 多步且有状态：一个 run 跨很多步，每步的状态都不同，断点看哪个？
- 不确定：同样输入，模型可能走不同路径，断点这次停的位置下次不一定停
- 难复现：线上的 bug，本地复现不了（因为模型行为不确定）
所以 Agent 调试需要新工具。Replay 就是。
Replay：取一次 run，改输入重跑
Replay 的机制：取出某次 run 的状态（trace + checkpoint），改它的输入或中间状态，重新跑。
这建立在前面两个东西上：
- Tracing（第 38 篇）：记录了这次 run 的每一步
- Checkpoint（第 14 篇）：记录了这次 run 每一步的 state
有了这两个，Replay 能把某次 run「定格」，让你从任意一步重新开始，改了再跑。
Replay 解决什么问题
Replay 最擅长解决「这个 run 为什么是这个结果」的问题。
比如线上一个 Agent 给了奇怪回答。你想搞清楚：是输入的问题？某一步模型判断的问题？工具返回的问题？
用 Replay：
- 取出这次 run 的 trace + checkpoint
- 从某一步开始 replay，改改输入看结果变不变
- 定位「这一步换这个输入，结果就对了」——说明是这一步的问题
这比断点调试直观得多——你不用在代码里打断点，而是直接在「run 的历史」上做实验，看哪一步改了能让结果变对。
Replay vs 普通重跑
有人问：我直接拿原输入重新跑一次 Agent，不也行？为什么非要 Replay？
区别在于确定性：
- 普通重跑：模型行为不确定，同样输入可能走不同路径，复现不了原来的问题
- Replay：基于原来的 trace/checkpoint，能精确复现原来的路径，在确定的基础上改
普通重跑因为模型不确定性，可能跑出来不一样的结果，没法定位。Replay 锁定了原来的路径，改动的影响才清晰。
一个类比：数据库的时间点恢复
Replay 的机制，类似数据库的 PITR（Point-in-Time Recovery，时间点恢复）——把数据库恢复到某个历史时刻，从那里重新开始。
Agent 的 Replay 也是：把 Agent 的状态恢复到某个历史步骤，从那里重新跑。这是「有状态长流程程序」调试的通用范式，不只是 LangChain 有，是这类程序的共同需求。
收束：Agent 时代的新调试范式
这一篇讲了 Replay 调试：
- 传统断点对 Agent（多步、有状态、不确定）不好使
- Replay：取一次 run 的状态，改输入重跑
- 建立在 Tracing + Checkpoint 之上
- 解决「这个 run 为什么是这个结果」
- 比普通重跑确定，能精确复现
- 类似数据库 PITR，是长流程调试通用范式
下一篇讲 部署——LangServe 到 LangGraph Platform 的演进。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。我相信 AI 是程序员的最佳搭档。
如果你想跟完这套「图解 LangChain」，欢迎关注公众号 「十三Tech」。全系列 42 篇，会按认识基础、LangGraph 状态机、Agent 与 middleware、RAG 检索、Tools/MCP/记忆、生产化收束这条线更新。
