AI Agent集群部署的三大隐形难题：寻址、发现与信任

你的 Swarm 部署得很顺利。Orchestrator 启动十个 Agent，分配角色，接通 Prompt 管道。然后第一次真实运行开始，三个 Agent 彼此找不到对方。两个在 NAT 后面，一个重启后丢失了地址，而那个能被访问的 Agent 却不接受来自其他成员的消息——因为没有人建立过信任关系。

这是 AI Agent Swarm 部署中 orchestration 框架不会覆盖的部分。调度、重试、状态管理已经是解决得很好的问题。寻址（Addressing）、发现（Discovery）和成员间的信任（Trust）是网络层的逻辑，忽略这一层，你的 Swarm 在演示中能跑，在生产环境中会散架。

AI Agent Swarm 部署实际涉及什么

当人们谈论部署 Swarm 时，他们通常指的是编排（orchestration）：哪个 Agent 在哪里运行、允许调用什么、如何分配工作和重试。LangGraph、Temporal 和基于 Kubernetes 的调度器等框架在这一块处理得很好，你应该继续用它们来做这件事。

但编排假设成员之间实际上能够通信。这个假设有三个隐藏依赖：

寻址（Addressing） — 每个成员需要一个在重启和 IP 变化中存活下来的身份标识。

发现（Discovery） — 成员需要通过名称或角色找到彼此，而不是通过硬编码的 IP。

信任（Trust） — 成员需要验证自己在和谁说话，并控制谁能访问自己。

如果你在多台机器上部署一个 Swarm——而如果一个 Swarm 只存活在一台机器上，它实际上算不上 Swarm——这三件事就是"部署了"和"在运行"的区别所在。

寻址：Swarm 成员需要一个稳定的身份

这是我第一次跨两个云区域部署多 Agent 系统时遇到的一种失败模式：Orchestrator 重启了一个 Worker Agent，它回来时带着一个新的 IP。其他所有成员都缓存了那个 IP。这个 Worker 是健康的，但无法访问——它没有一个稳定的可到达地址。

容器会被重新创建，虚拟机会被迁移，IP 会被重新分配。如果你的 Swarm 寻址方案是"Orchestrator 本次运行分配的 IP"，那么一次重启就能把一个成员变成幽灵。

解决方法是使用一个在重启、IP 变化和跨云迁移中都能存活的永久虚拟地址。成员注册一次，在整个生命周期中保持同一个地址。一个重启的成员回到同一个地址，这样没有任何人的缓存路由会出问题。这正是 Pilot Protocol 的寻址模型所解决的问题：每个 Agent 获得一个永久虚拟地址，它比任何单一主机都活得久。

发现：成员如何找到彼此

只有寻址是不够的。在一个由十个 Agent 组成的 Swarm 中，每个成员都需要找到其他成员。硬编码地址在 Swarm 变化之前是有用的——而一个 Swarm，按照定义，就是会变化的。

Agent 网络中的发现机制是"集合注册表 + 域名服务器"：成员注册，其他成员通过名称或标签查找它们。你问"研究 Agent 在哪？"，得到一个地址回来，而不需要维护一个 IP 配置文件——那个文件在任何东西移动的那一刻就会过时。

Pilot Protocol 的注册表就是这样工作的。Agent 用名称和能力注册，对等方通过名称或标签找到它们。加入 Swarm 的新成员只需注册就会变得可被发现；当拓扑结构变化时，你不需要重新部署整个集群。

信任：加入不等于信任

这是微妙的部分。一个 Agent 加入了你的 Swarm，并不意味着每个其他成员都应该能向它发送任意内容。在 VPN 中，"加入了"意味着"可信的"——一个凭证让你进来，一旦你在里面，你就在所有东西的内部。这种模式不适用于 Agent，因为一个被攻陷的成员不应该获得对所有其他成员的泛访问权。

另一种方案是明确的、逐成员的信任：每一对成员通过相互批准建立关系。握手是一个请求，接收方决定是否接受。这将成员资格和信任解耦——你的 Swarm 可以有数十个成员，而每个成员只和它实际信任的那些成员通信。

这是 Pilot Protocol 中的信任模型：一个明确的逐对等方握手，两边都需要批准，而不是一个打开一切的单一共享凭证。

使用 pilotctl 部署 Swarm：全程演示

Pilot Protocol 是一个面向 Agent 的开源覆盖网络——它为每个 Agent 提供永久地址、加密隧道、NAT 穿透和上述信任模型。以下是跨两台机器部署一个双成员 Swarm 的实际过程。

首先，在每台主机上安装 CLI：

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

在每个成员上启动守护进程。每个成员获得自己的身份和虚拟地址：

pilotctl daemon start

这会阻塞直到节点注册完成。现在每个成员都有一个永久地址，并且不需要公网 IP——覆盖网络处理 NAT 穿透（STUN、打洞，直连不可行时回退到中继）。

接下来，在成员之间建立信任。这是握手，而且是双向的——接收方在任何流量流动之前批准：

pilotctl handshake research-agent "joining the swarm"
# 在另一个成员上：
pilotctl pending
pilotctl approve <node_id>

检查关系是否建立：

pilotctl trust
pilotctl peers

然后成员之间可以通信了，使用名称而不是 IP：

pilotctl send-message research-agent --data '{"task":"summarize the incident report"}'

这就是整个循环：寻址、发现、信任、通信。每个成员有稳定的身份、按名称找到对等方，并且只和它明确批准过的成员通信。如果一个成员重启了，它回到同一个地址，Swarm 继续工作。

编排仍然负责的部分

这些都不替代你的编排层。你仍然需要调度器来决定哪个 Agent 做什么、重试逻辑、状态管理、人类介入检查点。这些是编排的职责，框架们做得很出色。

网络层添加的是底层基础：稳定寻址、发现和信任，这样编排器的决策能真正到达成员。清晰的划分是：编排决定，网络送达。使用 MCP 或类似协议的框架和 Agent 在其上都运行良好——覆盖网络是下面的传输层，而不是应用协议的替代品。

对于 Swarm 来说，这也可以和 Pilot Protocol 的应用商店模型很好地组合：像网页搜索、浏览器访问或数据增强这类能力，是任何成员可以通过同一个覆盖网络调用的可安装应用。你只需部署一次 Swarm，成员按需获得能力，而不需要重建。

AI Agent Swarm 部署在生产环境中失败的原因与编排无关：成员无法被寻址、无法被找到、或者无法互相信任。添加一个处理这三件事的网络层，Swarm 就不再是演示，而开始成为一种可以重启、可以扩展、可以迁移的基础设施。

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

完整文档——包括更大规模集群的信任和发现细节——在 Pilot Protocol 文档中。