24小时TTL的Webhook捕获器，吞掉了一个第25小时才触发的Bug

一个临时 Webhook 接收器，本意是让 AI Agent 不用自建服务器就能测试 Stripe、GitHub 等服务的回调 payload。它的设计很简单：单次使用的 HTTPS URL、接收任意 POST、最多存 100 条事件、24 小时后自动删除。

听起来是个干净利落的工具。但作者最近分享了一个翻车经历：这个 24 小时 TTL，悄悄把一个集成测试变成了"虚假信心"。

问题出在哪

作者把这个临时 Webhook 捕获器接到了一个支付服务商的回调上。第一次 Webhook 正常触发，ACK 也返回了——但支付方那边有个重试逻辑的 Bug：如果 ACK 慢了，它会恰好等 24 小时再重试。

等到第 25 小时重试发出的时候，捕获器已经自动删除了。重试请求打到的是一个不存在的 URL，返回 404。而支付方的后台仪表盘却依然显示"已送达"（delivered）。

结果就是：作者花了整整两天排查，怀疑是自己捕获器在丢事件。实际上捕获器完全正常工作——它只是按时消失了，而这个"按时消失"恰好掩盖了对方重试逻辑的 Bug。

Webhook 与 ACK 机制：Webhook 是服务端主动向调用方预先注册的 URL 推送事件的模式，与轮询（polling）相对。接收方处理完事件后通常需要返回一个 2xx 响应，这个响应即 ACK（acknowledgement，确认）。如果发送方在超时时间内没有收到 ACK，就认为投递失败，并按既定的退避策略重试。正因如此，ACK 的延迟与重试策略紧密耦合——很多服务商会采用指数退避，但也有实现会在特定条件下退化成固定间隔甚至极端长的等待。本案例中支付方正是在 ACK 慢的情况下等待了整整 24 小时再重试，这个时长恰好与捕获器的 TTL 持平，使得重试撞上了已删除的 URL。理解 ACK 与重试语义，是判断"谁该为丢事件负责"的关键。

静默过期为什么危险

这个问题值得所有做开发者工具的人思考。

临时性工具（ephemeral tools）的核心价值在于"用完即走"——不占资源、不留垃圾、自动清理。但自动清理带来的副作用是：过期是静默的。用户看不到倒计时，调用方不知道资源什么时候消失，一旦测试对象的行为跨越了 TTL 边界，故障就会被错误归因。

作者的原话很精准："如果测试脚手架会在定时器上消失，你正在测试的东西就可能以一种看起来像你的工具坏了的方式失败。"

这是调试中最糟糕的一类故障——错误信息不在真正出问题的地方。

TTL（Time To Live，存活时间）：TTL 原本是网络与缓存领域的常见概念，指一条数据或一个资源在被自动失效之前允许存在的最长时间。在云原生与临时基础设施语境中，TTL 通常由一个后台回收器（reaper）周期性扫描并删除过期对象，而不是由用户主动触发。这种惰性回收的特点是：删除动作发生在服务端，调用方对此一无所知。与之相对的是显式释放（如调用撤销接口），调用方能立即得到反馈。静默 TTL 的隐患在于，它把"资源不存在"与"资源从未存在"变成了同一种错误表现（通常是 404），调用方无法区分这两种含义，也就无法判断是自己配置错了，还是对方的行为跨越了 TTL 边界。

修复方案：让过期变得"响亮"

作者最终的修复不是加存储、也不是延长 TTL。这两条路都只是把问题往后推。

真正有效的做法是两条：

1. 引入 ?ttl= 参数并设置硬性上限。调用方可以自己指定存活时间，但上限由服务端强制，避免无限期占用。
2. 在每一个响应里显式返回 expires_at。调用方每次拿到数据，都知道这块"地毯"什么时候会被抽走。

这两个改动的价值在于：把隐式的生命周期变成显式契约。修复之后，那个支付服务商的重试 Bug 在下一轮测试里就直接暴露了——因为重试真的被捕获到了，而不是撞上一个已经消失的 URL。

对 Agent 工具链的启示

这个案例虽然来自一个小小的 Webhook 捕获器，但指向一个更普遍的工程原则。

现在越来越多的 AI Agent 依赖临时性基础设施做集成测试：临时数据库、临时沙箱、临时 API Mock、临时隧道。这类工具的共同特征是生命周期短、自动回收、无需清理。方便是方便，但它们都携带同一个隐患——过期对调用方不可见。

如果你在设计这类工具，可以对照检查：

• 每个响应里是否带上了资源的剩余寿命或绝对过期时间？
• TTL 是硬编码的还是可配置的？有没有上限保护？
• 资源消失时，调用方收到的是明确的"已过期"信号，还是一个含糊的 404？
• 文档里有没有写清楚"这块资源多久后会消失"？

作者最后把工具打包放在 x402.freeq.one 上，使用方式很直白：发任意 POST 过去，在时钟走完之前把事件读回来。工具本身没变复杂，变的是它对调用方更诚实了。

一个 24 小时的 TTL 本身没有问题。问题在于它太安静了。

临时性基础设施与显式契约：临时数据库、临时沙箱、临时 API Mock、临时隧道这类工具的共同点是按需创建、生命周期短、自动回收。它们极大降低了集成测试的编排成本，但也把生命周期管理从"显式动作"变成了"隐式约定"。工程上更稳妥的做法是把生命周期升格为契约：资源在创建时返回一个绝对过期时间（expires_at），并在每次交互响应中重复携带剩余寿命；调用方据此可以主动判断资源是否还在有效期内，甚至提前续期。这种模式在 HMAC 签名、OAuth token、S3 预签名 URL 等场景早已成熟——它们无一例外都会把过期时间写进凭证本身，而不是依赖双方对时长的默契。