AI代理时代，Webhook为什么突然不灵了？

你有没有算过，为了接一个HTTP请求，自己搭了多少个服务？

一个做AI代理的开发者最近算了笔账：轻量接收器、消息队列、死信队列、监控、幂等键、顺序控制……四到六个服务，只为可靠地收一个POST。更麻烦的是，大多数代理根本跑在没公网IP的环境里——笔记本在家用路由器后面，Docker容器在公司防火墙后面，云厂商默认不给虚拟机公网IP了。

他最后把整套Webhook架构扔了，换成持久隧道。这篇文章拆解他踩过的坑，以及为什么"反向连接"才是代理时代的默认答案。

一图读懂：Webhook vs 持久隧道

先放下原文的核心对比图。这张图把两种模型的根本差异摊开：Webhook要求消费者暴露可达端点，持久隧道让消费者主动连出去，然后反向收事件。

这个方向差异，决定了后面所有技术选型的走向。

第一层拆解：Webhook的"简单"是幻觉

表面上看，Webhook就是"对方POST过来，我回个200"。但生产环境的清单长得惊人：

• 轻量接收器——必须立刻回200，不能阻塞
• 消息队列——SQS、RabbitMQ、Redis，缓冲峰值
• 消费者——带重试逻辑的独立进程
• 死信队列——存失败事件
• 监控——盯着死信队列报警
• 幂等键——防重复投递
• 顺序控制——如果事件有依赖关系

四到六个服务，还没解决"没公网URL"的问题。

更隐蔽的是静默失败。原文引用生产环境研究：主要SaaS平台的Webhook投递，在峰值负载下近20%失败。不是全生命周期20%，是黑五支付、CI/CD部署、代理并行 burst 的关键时刻20%。一旦失败超出重试窗口，事件直接消失——没有消费者端回放，没有offset可回溯。

第二层拆解：SSE和WebSocket的半吊子方案

Server-Sent Events和WebSocket解决了NAT问题——消费者主动连出去，不需要公网IP。

但服务器端呢？代理对代理通信时，两边都没公网IP，SSE和WebSocket照样需要中继基础设施。你还是在管服务器。

SSE还有个硬限制：浏览器强制每个域名最多6个并发连接（MDN文档确认，Chrome和Firefox都标为"Won't fix"）。代理管道里多路事件流并发时，这个天花板会顶上来。

WebSocket相对灵活，但同样绕不过"谁当中继"的问题。

第三层拆解：持久隧道怎么把方向反过来

核心机制一句话：消费者主动发起向外连接，穿过NAT，然后在这个持久连接上接收事件。

没有入站暴露面。没有公网URL。防火墙友好——看起来像普通出站HTTPS。

Pilot Protocol的实现把这个模型做完整了：内置发布订阅（pub/sub），连接即订阅，断线自动重连，消息持久化到连接恢复。

原文作者的原话：「我花了很长时间用困难的方式做这件事。这是我停止之后发生的变化。」

第四层拆解：代理场景的特殊性

为什么现在才觉得Webhook别扭？因为假设变了：

Webhook时代假设消费者是"有云服务器、静态IP、永久HTTPS端点"的东西。AI代理几乎全不符合：笔记本、Docker容器、无公网IP的虚拟机——这些成了默认运行环境。

云厂商的安全策略也在推这个趋势。不给虚拟机默认公网IP，是"sensible security reasons"（原文用词）。合理，但让Webhook的入站模型更难落地。

代理的工作模式也不同。不是"等服务调用"，是"随时可能被唤醒处理任务"，同时"可能并发发起多个长连接去拉状态"。方向是乱的，拓扑是动态的。

第五层拆解：成本重构

原文没给具体数字，但列了隐性成本转移：

Webhook方案：基础设施成本（队列、死信、监控）+ 运维成本（重试策略调优、幂等实现）+ 故障成本（峰值20%丢失事件的事后修复）。

持久隧道方案：连接维持成本（通常一个TCP长连接）+ 协议层可靠性（内置重连、持久化）。

关键差异：后者把复杂度收进协议实现，而不是摊到运维清单上。

为什么这件事现在值得看

代理基础设施正在分层。底层模型（连接方向、NAT穿透、消息可靠性）的选择，会影响上面每一层怎么建。

Webhook是上个时代的默认答案——服务器对服务器，公网IP是标配。持久隧道正在成为这个新场景的默认答案——客户端主导连接，公网IP是例外。

如果你正在搭代理管道，先问自己：我的消费者有公网端点吗？需要为了接事件而架多少中间件？峰值来了，丢20%能接受吗？

这三个问题的答案，会告诉你该往哪个方向走。