在多代理协作系统中，跨代理消息传递的成本结构往往是制约系统扩展的关键因素。当代理数量从个位数增长到数十位时，传统中心化 API 调用的费用可能迅速超出预算。针对这一挑战，社区正在探索不依赖 API 计费的代理间通信方案，其中基于 CLI 会话续接的轻量路径已在实际项目中得到验证。
中心化调用模式的成本困境
传统多代理系统的典型架构是引入一个中央协调器，通过 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，后者根据反馈修订内容；如此反复迭代，直到输出稳定。这种模式避免了手动在工具之间复制粘贴交互的繁琐过程，同时利用了不同模型家族的视角差异。
工程化配置参数
将 CLI 会话续接方案落地到生产环境时，以下参数配置可作为工程起点：
会话管理：会话文件存储目录建议设为${TMPDIR}/agent-sessions/，并通过 UUID 命名确保不同工作流之间的隔离。会话生命周期应设置为 24 小时，超时自动清理以防止磁盘泄漏。对于并发运行的工作流，建议将会话目录按照业务域进一步划分，便于问题定位和资源隔离。
消息传递：代理间传递的 prompt 建议限制在 4000 token 以内，超出部分自动截断并在末尾附加[truncated]标记。这一限制既保证了交互效率，也避免了超长上下文带来的不可预期行为。命令执行超时建议设置为 120 秒，超时后记录错误日志并触发降级处理。
日志审计：交互日志采用 JSON Lines 格式存储，每行包含时间戳、发送方角色、接收方角色、消息类型和消息摘要。这格式便于后续在 ELK 或 Loki 中进行聚合查询，例如筛选特定工作流的完整交互链路。
监控指标：需要重点采集的指标包括会话恢复成功率（目标不低于 95%）、单次交互的端到端延迟、代理调用频次以及错误率。会话恢复成功率低于 95% 通常意味着上下文文件损坏或参数配置错误，需要及时介入排查。
增强可见性的 tmux 方案
纯 CLI 方式的局限在于可见性不足 —— 开发者难以直观查看交互历史或实时监控进度。针对这一痛点，tmux 方案提供了更好的可观测性。
tmux 方案的核心思想是为每个代理创建独立的 tmux 会话，通过 socket 进行隔离。关键的 tmux 命令包括：创建专用 socket 和隔离会话、向目标 pane 发送命令并提交执行、捕获指定 pane 的输出内容。这种方式虽然增加了依赖（需要安装 tmux），但换来了实时监控和并行运行多代理的能力。
tmux 方案的适用场景包括：需要观察代理交互过程的调试阶段、并行运行多个代理变体进行对比评估、以及需要人工实时介入的复杂工作流。配置时建议为每个业务域分配独立的 socket 路径，例如${TMPDIR}/claude-tmux-sockets/${domain}.sock，避免不同业务的工作流相互干扰。
风险提示与适用边界
需要特别指出的是，这种轻量方案并非没有代价。第一个风险是「过度协商」——LLM 擅长生成流畅但空洞的文本，当多个代理相互迭代时，每一轮输出都可能比上一轮更具说服力，但这并不意味着质量实质提升。社区将这种现象称为「polished hallucination」，即更难以察觉的幻觉形式。实践中建议设置最大迭代轮次上限（推荐 5 轮），并在达到上限后强制输出当前结果或触发人工评审。
第二个风险是可见性瓶颈。轻量方案牺牲了结构化的追踪能力，当工作流变得复杂时，理解代理之间的具体交互可能变得困难。对于需要强可观测性的生产系统，建议在架构层面引入日志聚合和链路追踪基础设施。
第三个风险是桌面客户端版本兼容性。不同版本的 CLI 参数可能存在细微差异，建议在代码仓库中锁定客户端版本，并在发布说明中记录兼容性测试结果。
这种方案的适用边界较为明确：适合双代理或三代理的低频交互场景，优势是零额外依赖、几分钟内可完成配置；不适合需要高吞吐、复杂路由或强可观测性的生产系统。对于后者，基于消息队列或 P2P 协议的方案更为适合。
资料来源：本文技术细节主要参考 JuanPabloAJ 的实验博客，该文详细描述了基于 CLI 会话续接的代理协作实现方式。