在多代理协作场景中，跨代理消息传递的成本结构往往是系统设计的关键考量。当代理数量从个位数扩展到数十位时，传统中心化 API 调用的费用可能超出预算预期。针对这一挑战，社区正在探索三条主要的技术路径：基于 CLI 的会话续接机制、基于 P2P 协议的直接消息传递、以及基于本地消息总线的进程间通信。本文从工程化视角梳理这些方案的配置参数与适用边界，帮助开发者在具体场景中做出合理选型。
中心化调用模式的成本瓶颈分析
传统多代理系统的典型架构是引入一个中央协调器，通过 API 依次调用各代理完成任务。协调器负责任务分发、结果聚合与状态管理，这种模式的优点是实现简单、易于调试，缺点是每次代理间数据交换都产生 API 费用，且协调器本身容易成为吞吐瓶颈。假设一个工作流需要 5 个代理完成，每个代理平均产生 3 次跨代理交互，总计 15 次调用；在按调用计费的模式下，这 15 次调用的费用将直接叠加到运营成本中。
零 API 成本的通信思路本质上是将数据平面与计费平面解耦。如果代理之间能够建立直接的数据传输通道，则可以绕过云服务商的按调用计费模型。当然，这并不意味着完全「免费」—— 网络带宽、计算资源、运维成本仍然存在，只是成本结构发生了转移。
路径一：CLI 会话续接机制
JuanPabloAJ 在实验中验证了一种极端轻量的方案：利用 Claude、Codex、Gemini 等桌面客户端提供的 CLI 接口，通过会话续接参数实现代理间的直接调用。其核心命令如下：
codex exec resume --last "prompt"
gemini -r latest -p "prompt"
这里的--last或-r latest参数告诉 CLI 恢复上一次对话的上下文，而非创建全新会话。这一细节至关重要 —— 它使得多轮迭代成为可能，而非每次调用都从零开始。对于双代理协作场景，这种方式可以实现「写完就评、评完就改」的快速闭环。
工程化配置要点包括：会话文件存储目录建议设为${TMPDIR}/agent-sessions/，并通过 UUID 命名确保隔离；会话生命周期应设置为 24 小时，超时自动清理以防止磁盘泄漏；代理间传递的 prompt 建议限制在 4000 token 以内，超出部分自动截断并附加[truncated]标记。日志采用 JSON Lines 格式存储，每行包含时间戳、发送方、接收方和消息摘要，便于审计与问题排查。
这种方案的适用边界较为明确：仅适合双代理的低频交互场景，优势是零额外依赖、几分钟内可完成配置；劣势是可见性差，难以直观查看交互历史或监控进度。
路径二：P2P 协议通信
Hacker News 上近期讨论的 DarkMatter 项目展示了 AI 代理 P2P 通信的完整工程实现。该协议的核心理念是让代理像 TCP/IP 协议一样自组织网络，无需中心化的消息代理。其技术栈包含以下关键组件：
身份与信任层：每个代理启动时生成 Ed25519 密钥对作为唯一标识，无需中心化的注册机构。消息采用 Ed25519 签名，接收方验证签名后才处理消息。密钥持久化建议存储在加密的本地文件系统，密钥轮换周期设置为 90 天。
发现机制：支持两种发现模式 —— 局域网多播和引导节点。局域网多播使用 UDP 端口 45678 进行广播，适用于同一网络域内的自动发现。引导节点模式用于跨网络场景，需要预先配置一组长期在线的种子节点地址。建议生产环境至少配置 3 个引导节点以确保高可用。
传输层：支持 HTTP 和 WebRTC 数据通道两种传输方式。HTTP 传输适合可靠的请求 - 响应场景，默认超时设置为 30 秒；WebRTC 适合低延迟的流式数据交换，消息分片阈值设为 16KB 以适配 MTU 限制。建立 WebRTC 连接需要通过 HTTP 通道先完成信令交换。
信任评分机制：每个代理维护一张对等节点的可信度评分表，初始值为 0 分。成功交互加 1 分，交互失败减 2 分，评分低于 - 10 分的节点将被自动列入黑名单 24 小时。
路径三：本地消息队列
当代理运行在同一台机器或同一局域网时，Redis Pub/Sub 提供了更简单的实现路径。其吞吐量可达每秒数万条消息，完全满足中小规模多代理系统的需求。
队列配置参数：建议设置最大内存策略为 volatile-lru，当内存达到上限时优先淘汰设置了过期时间的键。客户端连接池大小建议设为 CPU 核心数的 2 倍，以平衡并发与上下文切换开销。发布确认模式开启以确保消息不丢失。
消费者组设计：对于需要负载均衡的多消费者场景，应使用 Redis Stream 而非普通 Pub/Sub。每条消息的最大处理时间建议设为 300 秒，超时后重新入队重试，重试次数上限为 3。
监控指标：重点关注 Redis 的内存使用率（目标低于 70%）、命令延迟 P99 值（目标低于 5 毫秒）、以及消息堆积量（目标低于 1000 条）。
选型决策与风险提示
面对具体业务需求时，可按以下逻辑选择技术路径：代理运行在同一主机且数量少于 10 个时，首选本地 Redis 消息队列；代理分布在同一局域网的不同机器时，DarkMatter 类的 P2P 协议更稳妥；仅需快速验证概念时，CLI 会话续接提供了最低的试错成本。
需要特别注意的是「过度协商」风险。LLM 擅长生成流畅但空洞的文本，多轮互评容易产生大量表面共识而非实质改进，社区称之为「polished hallucination」。建议设置最大迭代轮次上限（如 5 轮），并在达到上限后强制输出当前结果或触发人工评审。
资料来源：本文技术细节参考 JuanPabloAJ 关于 CLI 会话续接的实验博客，以及 Hacker News 上 DarkMatter 项目的开源实现讨论。