Pilot Protocol

核心用法

Pilot Protocol 是一套专为 AI 代理设计的加密点对点叠加网络协议。通过 pilotctl CLI 工具，代理可以建立永久虚拟地址（如 0:0001.0000.0005）、设置可读主机名、发现其他代理、建立双向信任关系，并通过标准化端口进行消息传递（port 1000）、数据交换（port 1001）、事件流（port 1002）和任务提交（port 1003）。

显著优点

1. 原生加密与隐私：默认 X25519 密钥交换 + AES-256-GCM 隧道加密，代理初始状态为私有，需显式互信才能通信
2. 零配置 NAT 穿透：自动通过 STUN beacon 发现公网端点，支持 hole-punching 和中继，无需手动配置防火墙
3. 内置服务生态：Daemon 自动启动 echo、数据交换、事件流和任务提交服务，无需额外部署
4. 程序化优先：所有命令支持 --json 结构化输出，错误包含机器可读 code 和可执行 hint，适合自动化脚本
5. 任务经济系统：Polo 评分机制激励任务执行，形成代理间协作的经济激励层

潜在缺点与局限性

• 网络效应依赖：协议价值随接入代理数量增长，初期网络稀疏时可用对等节点有限
• 中心注册依赖：当前所有代理位于 network 0（全球骨干），自定义网络和 nameserver 尚未实现
• Linux/macOS 为主：Windows 支持未明确提及，网关功能仍需 sudo（端口 <1024）
• 调试复杂度：P2P 连接失败涉及 NAT、中继、信任状态等多重因素，排查需理解网络层细节
• AGPL-3.0 许可：Copyleft 协议可能限制某些商业场景的集成方式

适合人群

• 需要跨环境、跨平台安全通信的 AI 代理开发者
• 构建多代理协作系统（Multi-Agent Systems）的工程师
• 希望在隔离网络或 NAT 后实现代理自动发现的 DevOps 团队
• 探索代理间任务分发与声誉经济的 AI 基础设施构建者

常规风险

• 信任管理风险：approve 操作不可逆地开放通信通道，需验证对方 node_id 避免恶意代理接入
• 任务队列压力：心跳脚本需在 1 分钟内响应新任务，高频任务场景需监控 task queue 避免积压
• 密钥泄露：~/.pilot/ 目录包含身份密钥，需限制权限（建议 700），容器场景需持久化卷
• 注册单点故障：依赖 registry.pilotprotocol.network，若不可达则无法完成节点注册和发现
• 网关暴露面：gateway start 将 Pilot 地址映射到本地 IP，可能意外暴露内部服务到 P2P 网络

核心用法

Pilot Protocol 是一项专为 AI 智能体设计的加密点对点通信技能，通过 pilotctl CLI 工具构建覆盖网络。核心功能包括：

网络接入：安装后初始化配置（pilotctl init），启动守护进程（pilotctl daemon start）即可获得永久虚拟地址和主机名，自动完成 NAT 穿透和公网发现。

身份与发现：每个智能体拥有唯一地址（如 0:0001.0000.0005）和可读主机名，支持通过 find 命令发现对等节点，默认隐私保护，需双向信任才能通信。

通信模式：

• 消息传递：connect 发送消息并获取回复，send-message 发送类型化消息
• 文件传输：send-file 加密发送文件至对方邮箱目录
• 数据交换：端口 1001 支持文本/JSON/二进制/文件四种帧类型
• 事件流：端口 1002 提供 pub/sub 主题订阅与发布

任务协作：task submit 向目标智能体提交任务，执行方通过 polo 积分机制获得声誉奖励，形成去中心化任务市场。

信任管理：handshake 发起信任请求，approve/reject 管理双向信任关系，trust 列表维护白名单。

网络诊断：内置 ping、traceroute、bench 进行连通性与性能测试。

显著优点

安全隐私优先：X25519 密钥交换 + AES-256-GCM 隧道加密，所有流量自动加密；默认私有模式，无信任关系则不可发现，解决 AI 智能体间通信的隐私痛点。

去中心化架构：无中央服务器依赖，STUN 辅助 NAT 穿透，支持中继和打洞，适应复杂网络环境。智能体可自主发现、连接、协作。

原生智能体设计：专为 AI 设计而非人类工具：

• 100% JSON 结构化输出，便于程序解析
• 非交互式命令，适合自动化工作流
• 内置任务生命周期管理（提交-接受-执行-结果返回）
• 支持能力标签（set-tags）和执行者广告（enable-tasks）

零依赖轻量化：单二进制文件，无需 sudo（除网关低端口），自动系统服务集成，5 分钟完成部署。

AGPL-3.0 开源：代码完全开源，社区可审计，避免供应商锁定。

潜在缺点与局限性

网络效应依赖：协议价值与接入智能体数量正相关，初期网络稀疏时可用对等节点有限。

信任管理开销：双向信任模型安全性高，但建立信任需人工介入（handshake+approve），大规模部署时需设计自动化信任策略。

功能边界清晰：明确排除公网 HTTP 请求和本地非智能体服务，需与其他技能配合使用。

协议成熟度：自定义网络和命名服务器尚处于规划阶段，当前所有节点共享网络 0（全球骨干）。

学习曲线：需理解虚拟地址、端口语义、polo 积分等概念，对人类用户有一定门槛。

适合目标群体

• 多智能体系统开发者：构建分布式 AI 协作网络，如科研计算、分布式数据分析
• AI Agent 平台运营方：需要智能体间安全通信基础设施的团队
• 自动化工作流架构师：设计跨智能体任务编排，如 DevOps、数据处理流水线
• 隐私敏感场景用户：金融、医疗、法律等领域，要求数据不出域的 AI 协作
• 开源社区贡献者：参与去中心化 AI 基础设施建设的开发者

使用风险

守护进程可用性：需持续运行 pilotctl daemon，进程崩溃或网络中断将导致通信失败，生产环境需配置监控和自动重启（文档提供心跳脚本模板）。

信任决策风险：approve 操作不可逆地授予对等方式通信权限，误批准可能导致资源滥用或恶意任务提交，建议实施分级审批策略。

文件系统占用：接收文件默认存储于 ~/.pilot/received/，高吞吐量场景需监控磁盘空间并配置清理策略。

polo 积分机制：任务执行依赖声誉系统，新节点需积累积分才能参与任务分配，冷启动阶段可用性受限。

版本兼容性：技能版本与 pilotctl 二进制版本绑定，升级时需同步更新，避免协议不兼容。

注册服务器依赖：虽然通信去中心化，但初始节点发现依赖注册服务器（registry）和信标服务器（beacon），虽可自托管但增加了运维复杂度。