在多智能体系统日益成熟的今天，如何让不同供应商的 AI 代理高效协作而非彼此割裂，成为工程实践中的真实痛点。主流方案通常依赖 API 中转，这不仅产生额外费用，还引入了延迟与数据隐私顾虑。本文聚焦本地对等通信架构，探讨如何绕过 API 调用，实现智能体间的直接对话。
为什么需要本地对等通信
当团队同时使用多个订阅制的 AI 编码助手时，每调用一次 API 都意味着成本累积。更深层的问题在于 vendor lock-in：各家的 subagent 虽然好用，但跨供应商的协作往往需要复制粘贴上下文，或者通过人工中转。这种割裂使得多模型视角的协同工作流难以平滑运转。
真正的对等通信价值在于：保留每个智能体的独立上下文的同时，让它们能够相互调用、评论、迭代，而非让某一个中心化的 orchestrator 来决定一切。JuanPabloAJ 在其近期博客中验证了一种实践路径：利用 CLI 工具和会话恢复机制，在不增加 API 开销的前提下，让 Claude、Codex、Gemini 等代理直接 “对话”。
核心思路：会话恢复而非会话创建
传统智能体调用的误区在于，每次交互都新建一个会话上下文。这相当于让对方从头开始了解任务背景，效率极低。本方案的关键突破在于会话恢复（session resumption）：让被调用的智能体从上一次中断的地方继续，而非每次从零开始。
具体到命令行实现，核心指令如下。Codex 侧使用 --last 参数指向最近会话：
codex exec resume --last "请审查这段代码的实现逻辑"
Gemini 侧则使用 -r latest 恢复最新会话：
gemini -r latest -p "给出替代方案的性能对比"
这两个参数的语义一致：智能体不是 “新建一个任务”，而是 “接着上次说完的继续说”。这使得多轮迭代成为可能，而无需在每次调用时传递完整的上下文摘要。
方案一：非交互式直连
最轻量的实现方式是将 CLI 调用嵌入到主智能体的工作流程中。整个流程可以概括为四个步骤：主智能体生成初稿、调用另一个智能体使用恢复模式进行审查、主智能体根据审查意见修订、循环迭代直到输出稳定。
这个模式的工程实现极为简洁：不需要额外的框架依赖，不需要消息队列或 IPC 机制，只需要确保目标 CLI 工具已安装且可访问。调用方只需把另一个智能体视为 “可调用的函数”，通过子进程方式发起请求并捕获输出。
值得注意的参数约定应当事先定义并文档化。JuanPabloAJ 将这些约定维护在一个共享的记忆文件中，其他智能体可以读取并复用这套调用规范。这本质上是一种自描述的接口契约：每个参与通信的智能体都知道该如何 “唤醒” 另一个智能体，以及恢复会话时需要传递什么格式的提示词。
该方案的优点很明显：安装即用、学习成本低、调试周期短。但它也面临可见性瓶颈 —— 当调用链变深时，交互历史分散在各个独立进程中，监控和追溯会变得困难。
方案二：tmux 隔离模式
如果需要更好的可观测性，tmux 提供了更结构化的替代方案。其核心思想是为每个智能体创建独立的 tmux 会话，通过 socket 文件实现进程间隔离与输出捕获。
建立隔离会话的基础命令如下：
SOCKET="${TMPDIR:-/tmp}/claude-tmux-sockets/claude.sock"
mkdir -p "${TMPDIR:-/tmp}/claude-tmux-sockets"
tmux -S "$SOCKET" new -d -s "agent-reviewer"
发送指令到目标会话时，使用 send-keys 配合字面量模式，避免 shell 转义问题：
tmux -S "$SOCKET" send-keys -t agent-reviewer -l -- "$cmd"
sleep 1
tmux -S "$SOCKET" send-keys -t agent-reviewer Enter
捕获输出时，加入 -J 参数处理行滚动历史：
tmux -S "$SOCKET" capture-pane -p -J -t agent-reviewer -S -200
需要直接监控时，使用 attach 命令进入该会话：
tmux -S "$SOCKET" attach -t agent-reviewer
相比纯 CLI 模式，tmux 模式提供了三项关键能力：实时观察多个智能体的输出、并行运行不同任务的智能体、事后回溯任意时间点的会话状态。这些能力在复杂工作流调试时尤为关键。
关键参数与阈值选择
工程落地时，以下参数值得特别关注。
会话恢复超时：建议在发起恢复调用后设置 10 至 15 秒的显式等待，避免智能体因输出未完成而误判为失败。tmux 模式可通过增加 sleep 时长来应对复杂推理任务。
输出截取策略：使用 -S -200 捕获最近 200 行内容，对于代码审查类任务足够覆盖关键信息。更大的上下文需求可调高至 -S -500，但会增加内存占用。
Socket 路径管理：建议使用 /tmp 下的有意义的子目录结构（如 claude-tmux-sockets/），并在任务结束时清理对应的 socket 文件，防止文件系统泄漏。
并发控制：如果需要同时运行多个智能体实例，每个实例必须使用独立的 tmux 会话名称和 socket 路径，否则会出现输出混乱。
监控与可观测性设计
在生产级应用中，简单的输出捕获远不够。建议在两个层面补充监控：
会话状态追踪：为每个智能体会话分配唯一标识符，记录创建时间、最后活跃时间、累计交互轮次。这些元数据有助于识别卡住的会话并触发超时处理。
调用链路日志：每次跨智能体调用应当写入结构化日志，包含调用方标识、被调用方标识、传递的提示词摘要、响应状态码（成功 / 超时 / 错误）。这使得事后复盘工作流成为可能。
对于更高级的可观测需求，可以将 tmux 的输出通过管道写入本地日志服务（如 Loki 或 Filebeat），配合 Grafana 做可视化。
局限性与适用边界
必须诚实面对这套方案的局限性。
可见性上限：即使使用 tmux 模式，跨会话的全局状态仍需自行维护。没有中心化的调度器意味着工作流的编排逻辑完全落在主智能体肩上。
幻觉叠加风险：LLM 最擅长生成流畅但不准确的文本。当两个智能体反复相互审查时，可能产生 “更精美的幻觉” 而非更正确的结果。这需要人工介入设定收敛条件 —— 比如连续两轮审查意见相似度超过阈值时自动终止。
权限与安全：本地执行 CLI 意味着智能体拥有 shell 访问能力。在生产环境中应当以最小权限用户运行，并为关键操作配置确认步骤。
何时选择该方案
这套方法最适合以下场景：已有多个订阅制 AI 工具且希望充分利用、任务需要跨模型视角而非单一模型迭代、团队接受一定的调试复杂度以换取更低成本。
如果你追求的是开箱即用的框架式方案，或者需要大规模跨设备编排，可能需要考虑更结构化的协议如 ACP（Agent Communication Protocol）。但对于快速实验和中小规模协作，这套轻量级方案的工程效率往往更高。
参考资料