在多代理协作场景中，API 调用成本往往随代理数量呈指数级增长。当系统需要数十个代理协同处理复杂任务时，每条跨代理消息的计费可能成为不可忽视的运营支出。围绕这一挑战，社区正在形成两条主要的技术路径：基于点对点协议的直接消息传递，以及基于本地消息总线的进程间通信。本文从工程化视角梳理当前可落地的零 API 成本方案，并给出关键参数配置与选型建议。
中心化架构的成本困境与解耦思路
传统多代理系统依赖一个中央协调器通过 API 依次调用各代理完成任务。这种架构的优势在于实现简单、可控性强，但存在两个核心痛点：其一是每次代理间数据交换都产生 API 费用，其二是协调器本身可能成为吞吐瓶颈。当代理数量从个位数扩展到数十位时，中心化调用的成本结构通常难以接受。
零 API 成本的通信思路本质上是将数据平面与计费平面解耦。如果代理之间能够直接建立数据传输通道，则可以绕过云服务商的按调用计费模型。JuanPabloAJ 在实验中验证了一种极端轻量的方案：利用 Claude、Codex、Ge 等桌面客户端提供的 CLI 接口，通过会话续接参数实现代理间的直接调用。这种方案不产生 API 费用的前提是已购买桌面订阅，且交互规模较小。
对于更通用的场景，P2P 协议提供了更优雅的解决方案。
P2P 协议方案：从 DarkMatter 看工程实现
Hacker News 上近期讨论的 DarkMatter 项目展示了 AI 代理 P2P 通信的完整工程实现。该协议的核心设计理念是让代理像 TCP/IP 协议一样自组织网络，而非依赖中心化的消息代理。其技术栈包含以下关键组件：
身份与信任层：每个代理启动时生成 Ed25519 密钥对作为唯一标识，无需中心化的注册机构。消息采用 Ed25519 签名，接收方验证签名后才处理消息。这种设计确保了即使在不受信任的网络环境中，代理也能识别消息来源并拒绝篡改内容。密钥持久化建议存储在加密的本地文件系统，密钥轮换周期设置为 90 天。
发现机制：DarkMatter 支持两种发现模式 —— 局域网多播和引导节点。局域网多播适用于同一网络域内的自动发现，代理周期性地发送 255.255.255.255 的 UDP 多播报文，目标端口固定为 UDP/45678。引导节点模式则用于跨网络场景，需要预先配置一组长期在线的种子节点地址。建议生产环境至少配置 3 个引导节点以确保可用性。
传输层：协议支持 HTTP 和 WebRTC 数据通道两种传输方式。HTTP 传输适合可靠的请求 - 响应场景，默认超时设置为 30 秒；WebRTC 则适合低延迟的流式数据交换。建立 WebRTC 连接需要通过 HTTP 通道先完成信令交换，信令服务器建议部署在低延迟机房。消息分片阈值设为 16KB 以适配 MTU 限制。
信任评分：每个代理维护一张对等节点的可信度评分表，初始值为 0 分。成功交互加 1 分，交互失败减 2 分，评分低于 - 10 分的节点将被自动列入黑名单 24 小时。该机制有效防止恶意代理的泛洪攻击。
本地消息队列：同主机协作的极简方案
当代理运行在同一台机器或同一局域网时，本地消息队列提供了更简单的实现路径。Redis Pub/Sub 是工程实践中最常选用的组件，其吞吐量可达每秒数万条消息，完全满足中小规模多代理系统的需求。
队列配置参数：建议设置最大内存策略为 volatile-lru，即当内存达到上限时优先淘汰设置了过期时间的键。客户端连接池大小建议设为 CPU 核心数的 2 倍，以平衡并发与上下文切换开销。发布确认模式开启，以确保消息不丢失。
消费者组设计：对于需要负载均衡的多消费者场景，应使用 Redis Stream 而非普通 Pub/Sub。消费者组名称建议包含业务域标识，例如agent-workers:task-queue。每条消息的最大处理时间建议设为 300 秒，超时后重新入队重试，重试次数上限为 3。
监控指标：重点关注 Redis 的内存使用率（目标低于 70%）、命令延迟 P99 值（目标低于 5 毫秒）、以及消息堆积量（目标低于 1000 条）。当堆积量持续增长时，应横向扩展消费者实例。
混合方案：CLI 续接的工程实践
对于已订阅桌面客户端的开发团队，CLI 会话续接提供了零部署的快速启动方式。JuanPabloAJ 的方案核心在于使用codex exec resume --last和gemini -r latest -p命令恢复上一轮对话上下文，而非每次都创建全新会话。
这种方式的工程要点包括：会话目录应设为独立分区并配置定时清理，建议每 24 小时清理一次超过 48 小时未访问的会话文件。代理间传递的 prompt 建议限制在 4000 token 以内，超出部分自动截断并在末尾附加[context-truncated]标记。交互日志采用 JSON Lines 格式存储，每行包含时间戳、发送方、接收方和消息摘要，便于后续审计和问题排查。
该方案的适用边界较为明确：仅适合双代理的低频交互场景，不适合需要高吞吐或复杂路由的生产系统。
方案选型决策树
面对具体业务需求时，可按以下逻辑选择技术路径：
如果代理运行在同一主机且数量少于 10 个，首选本地 Redis 消息队列，延迟最低、运维最简。如果代理分布在同一局域网的不同机器且需要跨网段通信，DarkMatter 类的 P2P 协议是更稳妥的选择，其 NAT 穿透能力和加密传输能应对多数企业网络环境。如果仅需快速验证多代理协作的概念，且团队已订阅桌面客户端，则 CLI 会话续接提供了最低的试错成本。
对于需要长期运行的生产系统，建议在早期引入可观测性基础设施。无论选择哪种方案，都应采集以下核心指标：消息吞吐量（条 / 秒）、端到端延迟（毫秒）、消息失败率（百分比）、以及代理在线率。CLI 模式下还需额外监控会话恢复成功率，该指标低于 95% 通常意味着上下文文件损坏或参数配置错误。
风险提示与适用边界
零 API 成本的方案并非无需关注成本，只是成本结构发生了转移。P2P 方案中 NAT 穿透在某些企业网络环境下可能失败，此时需要回退到中继模式或降级为本地队列。本地消息队列在多机部署时需要额外的网络配置，且不具备跨公网的天然连通性。当代理数量增长到数十个时，网络带宽、内存占用、磁盘 IO 等资源消耗会逐步显现，规模扩展前应进行压力测试。
另一个需要警惕的风险是「过度协商」。LLM 擅长生成流畅但空洞的文本，当多个代理相互迭代时，每一轮输出都可能比上一轮更具说服力，但这并不意味着质量实质提升。社区称之为「polished hallucination」—— 一种更难以察觉的幻觉形式。实践中建议设置最大迭代轮次上限（如 5 轮），并在达到上限后强制输出当前结果或触发人工评审。
资料来源：本文技术细节主要参考 JuanPabloAJ 关于 CLI 会话续接的实验博客，以及 Hacker News 上 DarkMatter 项目的开源实现讨论。