在多代理协作系统中，跨代理消息传递的成本结构往往是制约系统扩展的关键因素。当代理数量从个位数增长到数十位时，传统中心化 API 调用的费用可能迅速超出预算预期。针对这一挑战，社区正在探索三条主要的技术路径：不依赖 API 计费的 CLI 会话续接机制、基于 P2P 协议的直接消息传递、以及基于本地消息总线的进程间通信。本文从工程化视角梳理这些方案的配置参数与适用边界，帮助开发者在具体场景中做出合理选型。
中心化调用模式的成本瓶颈
传统多代理系统的典型架构是引入一个中央协调器，通过 API 依次调用各代理完成任务。协调器负责任务分发、结果聚合与状态管理，这种模式的优点是实现简单、易于调试，缺点是每次代理间数据交换都产生 API 费用。假设一个工作流需要 5 个代理完成，每个代理平均产生 3 次跨代理交互，总计 15 次调用；在按调用计费的模式下，这 15 次调用的费用将直接叠加到运营成本中。
更关键的问题在于可扩展性。当工作流规模扩大，代理数量增加时，中心化调用的延迟也会线性增长。协调器本身可能成为吞吐瓶颈，导致整体系统性能下降。零 API 成本的通信思路本质上是将数据平面与计费平面解耦 —— 如果代理之间能够直接建立数据传输通道，则可以绕过云服务商的按调用计费模型。
CLI 会话续接机制的工程实现
JuanPabloAJ 在实验中验证了一种极端轻量的方案：利用 Claude、Codex、Gemini 等桌面客户端提供的命令行接口，通过会话续接参数实现代理间的直接调用。其核心命令如下：
codex exec resume --last "prompt"
gemini -r latest -p "prompt"
这里的--last或-r latest参数告诉 CLI 恢复上一次对话的上下文，而非每次都创建全新会话。这一细节至关重要 —— 它使得多轮迭代成为可能，而非每次调用都从零开始。对于双代理协作场景，这种方式可以实现「写完就评、评完就改」的快速闭环。
以代码审查工作流为例，非交互模式的典型流程如下：Claude 先编写一个草稿版本，然后调用 Codex 的 resume 模式让后者评审草稿；Codex 的评审结果返回给 Claude，后者根据反馈修订内容；如此反复迭代，直到输出稳定。这种模式避免了手动在工具之间复制粘贴交互的繁琐过程，同时利用了不同模型家族的视角差异。
工程化配置参数：会话文件存储目录建议设为${TMPDIR}/agent-sessions/，并通过 UUID 命名确保不同工作流之间的隔离。会话生命周期应设置为 24 小时，超时自动清理以防止磁盘泄漏。代理间传递的 prompt 建议限制在 4000 token 以内，超出部分自动截断并在末尾附加[truncated]标记。交互日志采用 JSON Lines 格式存储，每行包含时间戳、发送方角色、接收方角色和消息摘要。需要重点采集的指标包括会话恢复成功率（目标不低于 95%）、单次交互的端到端延迟以及错误率。
这种方案的适用边界较为明确：仅适合双代理的低频交互场景，优势是零额外依赖、几分钟内可完成配置；劣势是可见性差，难以直观查看交互历史或监控进度。
P2P 协议通信的完整方案
Hacker News 上近期讨论的 DarkMatter 项目展示了 AI 代理 P2P 通信的完整工程实现。该协议的核心理念是让代理像 TCP/IP 协议一样自组织网络，无需中心化的消息代理。其技术栈包含以下关键组件：
身份与信任层：每个代理启动时生成 Ed25519 密钥对作为唯一标识，无需中心化的注册机构。消息采用 Ed25519 签名，接收方验证签名后才处理消息。密钥持久化建议存储在加密的本地文件系统，密钥轮换周期设置为 90 天。
发现机制：支持两种发现模式 —— 局域网多播和引导节点。局域网多播使用 UDP 端口 45678 进行广播，适用于同一网络域内的自动发现。引导节点模式用于跨网络场景，需要预先配置一组长期在线的种子节点地址。建议生产环境至少配置 3 个引导节点以确保高可用。
传输层：支持 HTTP 和 WebRTC 数据通道两种传输方式。HTTP 传输适合可靠的请求 - 响应场景，默认超时设置为 30 秒；WebRTC 适合低延迟的流式数据交换，消息分片阈值设为 16KB 以适配 MTU 限制。
信任评分机制：每个代理维护一张对等节点的可信度评分表，初始值为 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 轮），并在达到上限后强制输出当前结果或触发人工评审。对于需要长期运行的生产系统，建议在早期引入可观测性基础设施，以便在成本从 API 转移至资源后仍能清晰掌握系统状态。
资料来源：本文技术细节主要参考 JuanPabloAJ 关于 CLI 会话续接的实验博客，以及 Hacker News 上 DarkMatter 项目的开源实现讨论。