防火墙后无端口部署AI Agent实战

实际的问题

撇开 Agent 特定的语言，这个问题是再普通不过的：你有一个必须接收请求的进程，但它所在网络不允许任何入站连接。

对于 Web 服务，你会用公网 IP 和负载均衡器来解决。Agent 让这件事变得更难，体现在两个方面：

它们经常被部署在数据所在的地方——本地机房、在严格出站规则的 VPC 里、在来回切换网络的笔记本上。没有静态公网 IP 可以用来配置 Webhook。

它们是长时间运行的、有状态的。会话结束就断开的隧道不是生产级的。地址必须是稳定的，即使它背后的机器并非如此。

所以需求是：稳定寻址、无需入站端口、能够经受重启、IP 变化和云迁移。

为什么常规方案不适用

先说说标准工具箱的公平之处，因为每个选项在某些场景下都是对的。

端口转发。经典方案。你在路由器或安全组上开放一个端口，然后映射到 Agent。在 Agent 迁移宿主机、办公室 IP 变更、或者安全审计规则之前都能正常工作。另外，把 Agent 的端点直接暴露到互联网是一个真实的攻击面——Agent 是一个执行动作的进程，而执行面正是提示词注入研究者会戳的地方。

带静态 IP 的反向代理。可靠、无聊、正确——如果你控制着基础设施的话。你需要一个有公网地址的机器来做 TLS 终端，以及一条到 Agent 的安全信道。这是一个正经的部署方案。如果你是把一个 Agent 发往客户的网络，你不会想同时附带一个代理。

ngrok 风格的隧道。对演示和预发环境非常好用。隧道端点是第三方，地址绑定在一个可能会折腾的会话上。对于一个必须稳定运行多年的 Webhook 目标来说，这是一个脆弱的基础——尽管对于"证明它能工作"这一步确实有用。

VPN。把网络连在一起，解决了可达性——但同时也连通了信任。在 VPN 里，如果一个节点在网络上，它就会被视为可信的。对于 Agent 间流量，你通常想要相反的东西：可达性和独立的逐端点信任。（这就是经典的"加入 ≠ 信任"区分，覆盖网络正是为解决这个问题而生的。）

这些方案都没错。只是它们是为另一种部署形态设计的："一个 Agent，在未知防火墙后面，需要从外部访问"。

出站唯一方案：覆盖网络

还有第四种形态值得认真对待：让 Agent 作为覆盖网络上的一个节点运行，连接全部由出站隧道构建。

思路是：Agent 的守护进程向外拨号连接到一个 rendezvous 注册中心，建立加密的 UDP 隧道，获得一个永久的虚拟地址，这个地址在重启、IP 变化和云迁移后依然存在。一旦有了这个地址，其他 Agent——以及需要访问它的服务——就可以直接发送给它，无需在你的方向开放任何入站端口。NAT 穿透（STUN + 打洞，配合中继回退）处理"双方都在 NAT 后面"的场景。

这正是 Pilot Protocol 实现的东西。它是一个面向 AI Agent 的开源覆盖网络：Go 语言编写，零外部依赖，AGPL-3.0 协议。每个 Agent 获得一个稳定地址，通信全程加密（X25519 密钥交换，AES-GCM）。

对生产部署来说关键的是信任模型。在两个 Agent 通话之前，它们做一次明确的握手——双向批准。可达性和信任是解耦的。你可以被网络访问，但不一定被任何对端信任——这对于一个根据消息执行动作的 Agent 来说是好得多的默认配置。

实践中的部署流程

以下是完整的流程，从一台防火墙后面的干净机器开始：

curl -fsSL https://pilotprotocol.network/install.sh | sh

守护进程启动并注册节点：

pilotctl daemon start

这就是"开放端口"的步骤——只是根本不存在端口。守护进程向外拨号；没有打开任何入站的东西。你的 Agent 获得它的虚拟地址，现在可以通过名称被访问了。

另一个 Agent（或你控制的服务）用同样的方式访问它：

pilotctl send-message <agent-address> --data 'task: summarize the new support tickets'

信任是明确的、按对端设置的：

pilotctl handshake <agent-address> "production webhook consumer"

消费端批准之后，消息开始流动。如果 Agent 的机器重启了、迁移到另一个云、或者被分配了新的 IP，地址保持不变——对端不关心 Agent 物理上在哪。

Webhook、其他 Agent 和应用商店

对于"SaaS Webhook 需要访问我的 Agent"这个具体场景，有两个重要的文档页面：

Webhooks — 守护进程可以接收守护进程事件的实时 HTTP 通知，这就是 Agent 无需轮询也能保持响应性的方式。

Gateway — 一个可选的独立二进制文件，把 IP 流量桥接到覆盖网络上，这样普通 TCP 工具（curl、浏览器、任何东西）都能访问覆盖网络上的对端。当调用你 Agent 的东西本身不是 Agent 时，这很有用。

由于 Agent 现在是带有目录的网络上的一个节点，它不只接收——它还能发现。让 Agent 可达的这套部署，同时赋予了它查找服务 Agent 和从应用商店安装能力应用的能力（pilotctl appstore catalogue、pilotctl appstore install <id>、pilotctl appstore call <id> <method> '{}'）。安装一次，Agent 就获得了网络的工具——无需配置任何 API 密钥。

如果你现在正在防火墙后面部署一个 Agent，按照这个清单过一遍：

• 无需入站端口。优先选择出站唯一连接。如果有人要求你开放防火墙规则，先问为什么。
• 地址要稳定。Webhook 目标不能因为机器迁移而改变。永久虚拟地址优于轮换的隧道 URL。
• 信任与可达性分离。在网上不等于被信任。对于任何能触发 Agent 动作的交互都需要逐端点明确批准。
• 默认加密。Agent 流量和任何其他生产流量一样值得保护。
• 可达性是功能，不是终点。一旦 Agent 可达，它就能发现对端、查询服务 Agent、安装应用——部署的投入是值得的。

Agent 本身才是困难的部分。最后一公里——让它可达——不一定要很难。

如果你想在承诺之前先看机制，Pilot Protocol 文档详细介绍了寻址、传输和信任模型，足够你对照自己的部署约束来评估。如果你想跳过阅读直接看运行：

curl -fsSL https://pilotprotocol.network/install.sh | sh