2 篇博文 含有标签「reproducibility」

这张故障工单具有只有真实事故才具备的典型特征。在 02:14，支持代理关闭了一个本应进入 30 天宽限期的客户账户。客户发现了。工单落到你的桌面上，“复现步骤”一栏下面只有一行字：未知。

你打开追踪记录。你看到代理调用了 close_account 而不是 set_grace_period。你看到工具执行成功了。你看不出的是模型为什么选择了那个分支 —— 而且当你通过同一个代理重新运行同一条客户消息时，它做出了正确的选择。做了两次。现在的事故复盘报告中，原本该写根本原因的地方出现了一个段落大小的空洞，而你唯一能诚实写下的只有“无法复现”。

你的 Agent 上周二在生产环境出了故障。一个客户报告了错误的回答。你调出日志，看到最终输出，也许还有几条中间的 print 语句——然后你就卡住了。你无法重新运行 Agent 来重现同样的故障，因为模型不会产生相同的 token，你的工具调用的 API 现在返回了不同的数据，嵌入在提示词中的时间戳也已经变了。Bug 消失了，你只能盯着间接证据发呆。

这就是 AI Agent 的根本调试问题：传统软件是确定性的，所以你可以通过重建输入来复现 bug。Agent 系统不是。每次运行都是模型采样、实时 API 响应和时间依赖状态的独特组合。没有专门的工具，事后调试就变成了取证猜测。

确定性重放通过在执行过程中记录每个非确定性来源，并在重放时替换这些记录来解决这个问题——把你无法复现的 Agent 运行变成你可以像调试器一样逐步跟踪的东西。