在多代理协作场景中，API 调用成本往往是制约系统扩展的关键瓶颈。当多个 AI 代理需要频繁交换中间结果、共享状态或协调任务时，每千次调用的费用会迅速累积。针对这一痛点，社区正在探索三类零 API 成本的直接通信路径：基于 CLI 的会话续接、点对点协议传输、以及本地消息队列。每种方案在延迟、可见性和部署复杂度上各有取舍，本文给出工程化落地的核心参数与监控要点。
从集中式调用到直接通信的范式转移
传统多代理架构依赖一个中央协调器通过 API 调用依次触发各代理完成任务。这种模式虽然易于管理，但存在两个显著问题：其一是每次代理间数据交换都产生 API 成本，其二是协调器本身可能成为性能瓶颈。零 API 成本的通信思路是让代理之间直接建立数据通道，绕过计费层级的约束。
JuanPabloAJ 在实验中发现，如果开发者已订阅 Claude、Codex 或 Gemini 等桌面客户端，可以利用这些工具提供的命令行接口实现代理互调，而无需額外支付 API 费用。这种方式的核心技巧在于「会话续接」：一个代理不是每次都启动全新对话，而是通过 CLI 参数恢复上一次交互的上下文，从而在多轮迭代中累积信息。
三条技术路径的对比与选型
路径一：CLI 会话续接是最轻量的实现方式。它依赖现有订阅账号，通过类似 codex exec resume --last "prompt" 或 gemini -r latest -p "prompt" 的命令让代理恢复上一轮对话。这种方式的优势在于零额外依赖、几分钟内可完成配置；劣势是可见性差 —— 开发者难以直观查看交互历史或监控进度。适用于快速实验或简单的双代理协作。
路径二：P2P 协议通信使用 WebRTC 数据通道或 libp2p 等技术实现代理间的直接连接。这种方式的理论成本为零（仅消耗网络带宽），且支持端到端加密和身份验证。工程实践中需要解决 NAT 穿透问题，建议使用基于 WebRTC 的信令服务器做首次握手，后续数据直接走点对点通道。典型配置参数包括：DTLS 握手超时设置为 10 秒、ICE 候选交换超时 15 秒、消息分片阈值 16KB。
路径三：本地消息队列采用 Redis Pub/Sub 或内存队列作为代理间通信总线。这种方式适合同一主机或局域网内的多代理协作，延迟可控制在毫秒级。关键参数包括：队列长度默认 1000 条消息以防止内存溢出、消费者阻塞超时设置为 5 秒、消息过期时间建议 3600 秒以平衡缓存与内存占用。
面向生产环境的工程化配置
无论选择哪种路径，以下参数配置可作为工程落地的起点。
在 CLI 续接模式中，建议将会话上下文文件存储在独立目录，例如 ${TMPDIR}/agent-sessions/，并通过 UUID 命名确保隔离。每个会话文件的生命周期应设定为 24 小时，超时自动清理以避免磁盘泄漏。代理间传递的 prompt 建议限制在 4000 token 以内，超出则自动截断并附加 [truncated] 标记。
在 P2P 模式中，身份验证采用 Ed25519 公钥体系，每个代理启动时生成密钥对并持久化到本地。消息签名使用 Ed25519 算法，签名验证失败的消息直接丢弃。连接建立后，建议设置心跳间隔为 30 秒、丢包阈值连续 3 次心跳超时判定对端离线。
在本地消息队列模式中，如果使用 Redis，需关注两个监控指标：命令执行延迟（P99 不应超过 50 毫秒）和内存使用率（超过 70% 时触发告警）。消费者实例数建议设为 CPU 核心数的 50% 至 80%，以在吞吐与上下文切换之间取得平衡。
监控与可观测性实践
零 API 成本的方案并非无需关注运维，只是成本结构从按调用计费转向资源消耗。推荐采集以下指标：
基础指标包括代理在线时长、消息吞吐量（条 / 秒）、端到端延迟（从发送方发出到接收方处理的时长）。对于 CLI 模式，还应监控会话恢复成功率，该指标低于 95% 时通常意味着上下文文件损坏或参数配置错误。
高级指标涉及通信模式的异常检测。当两个代理在 5 分钟内交互超过 20 次但未产生有效输出时，系统可能陷入了「过度协商」——LLM 擅长生成流畅但空洞的文本，多轮互评容易产生大量表面共识而非实质改进。建议在此类场景触发人工介入或降级为单代理处理。
日志层面，建议在每条跨代理消息的元数据中嵌入 trace_id、发送方角色、发送时间戳和消息类型标签。结构化日志便于后续在 ELK 或 Loki 中聚合查询，例如筛选特定 trace_id 的完整交互链路。
适用边界与风险提示
上述方案存在明确的适用范围。CLI 会话续接依赖特定客户端的 CLI 接口，不同厂商的工具支持程度不一，且会话续接行为可能随版本升级变化 —— 建议在代码仓库中锁定客户端版本，并在发布说明中记录兼容性测试结果。P2P 方案的 NAT 穿透在某些企业网络环境下可能失败，此时需要回退到中继模式或降级为本地队列。本地消息队列在多机部署时需要额外的网络配置，且不具备跨公网的天然连通性。
值得特别注意的是，零 API 成本不等于零成本。当代理数量增长到数十个时，会话文件磁盘占用、内存队列资源消耗、P2P 连接维护的网络带宽都会成为实际成本。规模扩展前应进行压力测试，记录单代理平均资源占用并据此估算总体成本。
另一个核心风险是「 polished hallucination」。当多个 LLM 代理相互迭代时，每一轮输出都可能比上一轮更流畅、更具说服力，但这并不意味着质量提升。实践中建议设置最大迭代轮次（如 5 轮），并在达到轮次上限后强制输出当前结果或触发人工评审。
小结
零 API 成本的 AI 代理直接通信已在轻量场景中具备实用价值。CLI 会话续接适合快速验证双代理协作，P2P 协议适合对延迟和隐私有要求的内部部署，本地消息队列适合同一环境内的多代理系统。工程化落地时应关注会话生命周期、资源监控和迭代轮次控制三个关键配置点。对于需要长期运行的生产系统，建议在早期引入可观测性基础设施，以便在成本从 API 转移至资源后仍能清晰掌握系统状态。
资料来源：本文技术细节参考 JuanPabloAJ 的实验博客，该文详细描述了基于 CLI 的代理会话续接实现方式。