Agent 回放要断网验证，防止偷偷调用真实工具

Agent 在线上出了问题，拿着 trace 回放却复现不了，未必是模型表现不稳定。dev.to 的这篇文章指出：部分回放框架在缓存未命中时，会静默调用真实工具。流程跑完、输出合理，都不能证明执行由记录驱动。作者提出的验证办法是：阻断出站网络，再检查原来的故障能否复现。

目前能确认什么

问题出在回放框架的兜底逻辑：匹配到缓存就返回记录，匹配不到就执行真实函数。只要外部服务仍可访问，缺失的输入就可能被现场补齐，掩盖记录不完整的问题。

框架声明进入回放模式，不等于执行过程已经脱离外部网络。

作者建议从操作系统层阻断出站访问，并给出 Linux 下使用 unshare 的示例。这种检查独立于框架自身的配置，但该命令有平台和运行环境限制，不能直接照搬到所有 CI 环境。

为支持离线回放，作者还列出五项记录要求：解析前的原始响应体、调用时的工具 schema 哈希、实际响应的模型标识、稳定的时间来源，以及用于比较的故障签名。背景逻辑很直接：只保存处理后的工具结果，可能丢掉排查解析错误所需的原始输入。

我的判断

对维护 Agent 的程序员，最该检查的是缓存未命中后的行为。缺失记录应当显式报错，否则所谓回归通过，可能只是外部服务又成功响应了一次。

断网后复现同一故障，可以支持「这份记录足以排查这个故障」的判断；它不能证明 Agent 的推理正确，也不能证明所有依赖都已记录。

如果故障消失或变了，应先排查遗漏输入、时钟和未被记录器覆盖的调用路径。不过，断网也会改变运行条件，不能仅凭一次结果就确定缺失了哪项记录。节选的跨平台方案尚未展开，具体如何覆盖各类出站调用，还需要完整实现说明。