Git 作为 AI 代理实时通信协议：Claude Code 与 Codex 的去中心化信令实践

AI 编码代理的协作通信长期面临协议层面的困境：MCP（Model Context Protocol）虽然是当前的事实标准，但其本质是请求 - 响应模式，缺乏原生双向推送能力；Google 提出的 A2A（Agent-to-Agent）协议在理论上更契合多代理场景，却尚未被 Claude Code 或 Codex CLI 原生支持。在这种背景下，开发者社区探索出了一条独特的技术路径 —— 将 Git 的 DAG（有向无环图）语义与 Claude Code 的 Channels 机制结合，构建无需额外消息队列的实时通信桥接方案。

协议困境与破局思路

Claude Code 和 Codex CLI 作为当前最成熟的 AI 编码代理，各自拥有独立的运行时与会话管理机制。传统思路倾向于引入 Redis、RabbitMQ 等消息中间件作为代理间的信令层，但这会增加部署复杂度与运维负担。更关键的挑战在于：如何让两个独立进程中的代理实现 "感知对方存在" 的实时对话体验？

Claude Code 在 v2.1.80+ 版本中引入的 Channels 功能为此提供了突破口。Channels 允许 MCP 服务器向运行中的 Claude Code 会话推送消息，这相当于在 Claude 侧建立了一个异步消息入口。然而 Codex CLI 并不具备对等的推送能力 —— 它只能被动响应 MCP 工具调用。这种不对称性迫使开发者采用 "阻塞式工具调用" 的设计模式：Codex 调用 send_to_claude() 后保持连接等待，直至 Claude 通过 Channel 返回响应。

这种机制虽然实现了 Codex → Claude → Codex 的实时对话流，但本质上仍是半双工通信 ——Claude 主动发起的消息需要 Codex 轮询或再次调用工具才能接收。

Git 式 DAG 的会话语义

Claude Code 的会话存储机制为这种通信模式提供了底层数据结构的支撑。每个会话以 JSONL 文件形式存储在 ~/.claude/projects/<project-slug>/<session-uuid>.jsonl，每条消息是一个独立的 JSON 对象，关键字段包括 uuid、parentUuid、type 和 message。其中 parentUuid 指向上一消息的 UUID，形成类似 Git 提交历史的 DAG 结构。

这种设计使得会话天然具备分支与合并的语义：开发者可以通过指定任意消息的 UUID 作为 parentUuid 来创建会话分支，Claude Code 会在恢复会话时自动重建完整的对话图谱。对于 AI 代理间的通信而言，这意味着消息不再是简单的线性序列，而是可以被追溯、分叉、甚至并行处理的有向图。

在 codex-claude-bridge 的实现中，桥接服务器维护一个内存中的消息队列，将 Codex 的阻塞调用转换为对 Claude Channel 的 HTTP 推送，同时将 Claude 的响应回传给等待中的 Codex 工具调用。Web UI 在 localhost:8788 实时展示对话流，紫色气泡代表 Claude，绿色代表 Codex，灰色为人类观察者输入。

工程实现与配置参数

部署这一方案需要同时配置 Claude Code 和 Codex CLI 的 MCP 服务器。Claude Code 侧通过 --dangerously-load-development-channels 标志启用 Channel 功能，并在 ~/.mcp.json 中注册桥接服务器：

{
  "mcpServers": {
    "codex-bridge": {
      "type": "stdio",
      "command": "bun",
      "args": ["/path/to/codex-claude-bridge/server.ts"]
    }
  }
}

Codex CLI 侧在 ~/.codex/config.toml 中配置对应的 MCP 服务器，关键参数是 tool_timeout_sec = 120—— 由于 send_to_claude() 可能等待 Claude 响应长达两分钟，默认的 60 秒超时会导致连接过早断开。

桥接服务器的环境变量配置包括：

• CODEX_BRIDGE_PORT：默认 8788，Web UI 与内部 API 端口
• CODEX_BRIDGE_URL：Codex 侧 MCP 服务器访问桥接的地址

启动流程需要按特定顺序执行：先启动 Claude Code 并确认 Channel 监听状态，再启动 Codex CLI 验证 MCP 工具注册，最后打开 Web UI 观察对话。对话建议从 Codex 侧发起以获得最佳实时性体验。

局限性与优化方向

当前方案存在三个主要限制。首先是通信不对称：Codex 发起的对话是实时双向的，但 Claude 主动推送的消息需要 Codex 轮询，这在某些协作场景下会造成延迟。其次是部署约束：两个代理必须运行在同一台机器上，桥接服务器通过 localhost 通信，跨机器部署需要额外的网络层改造。最后是 Channels 功能仍处于研究预览阶段，需要显式启用开发标志，API 可能随版本迭代变化。

针对这些限制，社区已探索出若干优化路径。对于通信不对称问题，可以在 Codex 侧实现短轮询或长轮询机制，以较低频率检查 Claude 的消息队列；对于跨机器部署，可将桥接服务器的 HTTP API 暴露为可访问的端点，并引入简单的认证机制。更长期的演进方向是等待 A2A 协议的原生支持，届时代理间通信有望摆脱 MCP 的请求 - 响应限制，实现真正的对称双向通道。

落地建议

对于希望尝试这一方案的团队，建议从以下步骤开始：

1. 环境准备：确保 Claude Code 版本 ≥ v2.1.80，安装 Bun 运行时，准备 OpenAI API 密钥用于 Codex CLI
2. 本地验证：先在单机环境部署桥接，通过 Web UI 观察对话流，熟悉消息路由机制
3. 场景选择：优先应用于 Codex 主导的对话场景，如代码审查、技术方案讨论等 Claude 响应为主的交互
4. 监控兜底：设置工具调用超时监控，避免因 Claude 响应延迟导致 Codex 会话僵死
5. 版本锁定：由于 Channels 是预览功能，建议锁定 Claude Code 版本，避免自动升级导致 API 变更

Git 作为 AI 代理通信协议的核心价值在于复用了成熟的版本控制语义 ——DAG 结构提供了消息的可追溯性，分支机制支持并发对话的探索，而 JSONL 的追加写入模式确保了状态持久化的原子性。这种设计哲学与区块链的不可篡改账本、事件溯源（Event Sourcing）架构一脉相承，为构建可审计、可回滚的 AI 协作系统提供了轻量级的实现路径。

资料来源

• codex-claude-bridge: Bidirectional bridge between Claude Code and OpenAI Codex CLI (GitHub)
• Messages as Commits: Claude Code's Git-Like DAG of Conversations (Piebald Blog)

ai-systems