AI Agent 盲路由：不暴露内网拓扑的消息传递方案

AI Agent 盲路由：不暴露内网拓扑的消息传递方案 | 前端进阶之旅

Full translation

完整中文译文

标准 Webhook 悄悄地暴露了 Agent 的内部网络拓扑——本文介绍一种更简洁的跨 Agent 消息路由方案：网关在转发消息时，永远无法得知消息的实际目的地。

Status: work in progress. 这是一篇关于我正在开发项目的早期文章，并非成品发布公告。在进一步推进之前分享出来是为了收集反馈。具体需要哪类反馈，见文章最后一节。

一张图讲清楚问题所在

假设你在家庭办公室里经营一家私人诊所，希望客户能向你发送机密文件。你会：

A) 在公共广告牌上公布你的家庭住址、门禁密码和楼层平面图，让任何快递员都能长驱直入走到你的办公室门口，还是

B) 租用一个邮政信箱，邮件中转站将你的信件转发到内部信箱，但始终不知道你是谁、信封里装了什么？

任何需要保护机密信息的人都会选 B。

然而当今几乎所有的多 Agent 框架都默认采用方案 A。要让一个 AI Agent 跨越公司边界或不同云向另一个 Agent 发消息，常见模式是使用公开的 HTTP webhook——这意味着暴露真实的 IP 地址、真实的端口，以及往往位于其后的内部服务名称。除了隐私泄露之外，大多数 Agent 根本没有稳定的公网地址可以暴露：它们位于企业防火墙、云 VPC 或 NAT 之后，根本没有开放的入站端口。

另一种常见修复方案——将所有流量通过中心消息代理路由——解决了连接问题，却带来了新问题：该代理能看到每一个发送方、每一个接收方，以及谁在和谁通信的拓扑结构，即便消息内容本身已加密。

我们两者都不想妥协。我们构建的网关能将消息精确送达内部目标，却始终无法得知目标所在的位置。

核心思想：双层信封

把每条消息想象成两个信封，一个套在另一个里面。

外层信封携带只有网关能打开的路由指令。它只透露足够让网关将消息转发到正确内部队列的信息——绝不透露接收方的真实服务器、IP 或内部架构。

内层信封是真正的消息，端到端加密，只有接收方 Agent 能读取。网关转发这些字节，但根本无权打开它们。

外层信封就是我们所说的 JIT（Just-In-Time）路由令牌：一个为每条消息全新生成的、一次性使用的加密数据包。其底层构建过程分为四步：

发送方生成一个全新的一次性密钥对——仅用于本条消息，之后立即丢弃。

它将该密钥与网关的公钥结合，推导出一个共享密钥（标准的 Diffie–Hellman 交换）。

将该共享密钥扩展为加密密钥。

发送方用该密钥加密接收方的真实（但仍是不透明的）目标 ID——这是令牌内唯一指明消息实际去向的内容。

由于每条消息都生成全新的密钥对，即便网关自身的密钥将来某天被泄露，也没有人能回头解密昨天的路由令牌。无论未来密钥发生什么情况，旧消息始终保持不可读取。

消息发送的实际过程

有两个值得注意的点：

发现服务从不给出真实地址。 查询接收方返回的是一个不透明的路由 ID——不是 IP，不是主机名，也不是关于接收方实际运行在哪个云或哪台服务器上的任何线索。

网关是无状态的。 它不持有任何用户数据库、没有消息历史，也不保留谁与谁通信的持久记录。它解密路由指令、转发一些字节，然后在完成后立即遗忘一切。

最简单的体验方式

最直观的体验方式是通过我们的在线演示门户 https://lianxi.io/experiment 和公共网关（https://gateway.lianxi.io）。

第一步：创建一个可被发现的身份

访问 https://lianxi.io/experiment 并创建一个测试账户。

进入 Account & Settings → People → Manage Profiles，点击 Make Discoverable。

复制你新创建的 DID（例如 did:twin:z83ca0ce5dfbeb303c0d699b1844f3718df29ed00439e453e7b72d9152a843fa5）。

第二步：查看 DID Document

你现在可以向公共网关查询公开目录实际透露了关于你身份的哪些信息：

curl -s "https://gateway.lianxi.io/did/<your-did>" | jq .

{
  "id": "did:twin:z83ca0ce5dfbeb303c0d699b1844f3718df29ed00439e453e7b72d9152a843fa5",
  "verificationMethod": [
    {
      "id": "did:twin:z83ca0ce5dfbeb303c0d699b1844f3718df29ed00439e453e7b72d9152a843fa5#key-1",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:twin:z83ca0ce5dfbeb303c0d699b1844f3718df29ed00439e453e7b72d9152a843fa5",
      "publicKeyBase64": "g8oM5d++swPA1pmxhE83GN8p7QBDnkU+e3LZFSqEP6U="
    }
  ],
  "service": [
    {
      "id": "did:twin:z83ca0ce5dfbeb303c0d699b1844f3718df29ed00439e453e7b72d9152a843fa5#messaging",
      "type": "MessagingService",
      "serviceEndpoint": {
        "uri": "https://gateway.lianxi.io/ingress",
        "routing_did": "did:twin:gateway_local",
        "target_id": "spPWV7dxhdWkjfKTW1iAN83m1JY4wZS9CEC4mp7s5Vf7XZtIJDkmHZTcbCcw3wgB0gf1Le6Np+gZRTfApSlc7zPTv+WVO6y8nLEMIIUki0Q4b8jbdxluq5c+hSFBsrRhvZemSOH9LJd7E7cugs37WBph990qPjFgBo0uLueSc9hZSxESCux6ii4+iejhS8/+2Mf8tizTREXUlpV8Jy5CA7Z0Y5FX9FijxnAjlFh+5qJ9"
      }
    }
  ]
}

id：代表该 Agent twin 的唯一加密指纹。
verificationMethod：用于验证签名以及与该 Agent 建立端到端加密会话的公钥。
service.serviceEndpoint：网关入口（https://gateway.lianxi.io/ingress）和 target_id。注意 target ID 完全不透明：没有 IP 地址、没有端口、没有内部服务器名称、也没有队列名称。

第三步：向特定 DID 投递消息

当你向该 DID 发送消息时（例如从另一个 Agent 或直接从演示门户）：

发送方客户端库封装 JIT token：

生成一个一次性临时 X25519 密钥对。
计算 SharedSecret = ECDH(EphemeralPrivate, GatewayPublic)。
使用 XChaCha20-Poly1305 加密接收方的 target_id。
将 [Version (0x01) | EphemeralPubKey (32B) | Nonce (24B) | Ciphertext] 打包为 base64 URL-safe 的 X-Routing-Token。

发送方向公共网关发送消息：

curl -i -X POST https://gateway.lianxi.io/ingress \
  -H "Content-Type: application/json" \
  -H "X-Routing-Token: <ephemeral-jit-token-wrapping-target_id>" \
  -d '{
    "version": "didcomm/v2",
    "id": "msg_88a91bc0",
    "type": "https://didcomm.org/messaging/2.0/message",
    "body": {
      "ciphertext": "U2FsdGVkX19+vX4Wk910... (End-to-End Encrypted Payload)"
    }
  }'

HTTP/1.1 202 Accepted

202 Accepted 表示网关在 2ms 内解密了临时 X-Routing-Token，将仍然密封的消息转发到了接收方的内部队列（v1.<node>.didcomm.<target>），然后立即丢弃了路由上下文。

如果你使用 https://lianxi.io/experiment 的交互式界面，演示门户会自动为你处理令牌推导，你可以在活动流中实时查看收到的消息，且网络拓扑零暴露。

总结

公开 webhook 泄露的不只是一条消息，而是你整个内部网络的拓扑结构。
将路由层与内容层分离。网关只需要知道"去哪里"，永远不需要知道"是什么"或"是谁"。
让每条路由指令都是一次性的且自动过期，这样即使密钥泄露也无法解锁过去。
网关依然能把你的消息送达目的地。只是它永远无法获得足够信息来绘制你的架构图。

期待你的反馈

这仍在积极开发中，希望能听到任何阅读此文的读者声音——无论是 Agent 开发者、安全从业者，还是单纯好奇的朋友。有几点我真诚地不确定：

核心思路：在路由层隐藏网络拓扑，对你来说是否真正解决了一个实际问题，还是在解决一个你其实并不担心的问题？

阐述方式：双层信封的类比在 JIT 令牌机制介入之后还能成立吗，还是变得模糊了？

缺口：在信任此方案用于生产流量之前，你需要看到什么——限速、防滥用、密钥轮换，还是其他？

演示：如果你亲自试过这个流程，发现和投递是否如文中描述的那样工作？

在评论区留言是最便捷的联系方式。如果你花五分钟来挑毛病，我会逐条阅读。