Claude Code 和 Codex 可以通过 Git 进行实时对话
一句话看懂：开发者正在利用 Git 版本控制作为底层通信协议，让 Claude Code 和 Codex 等 AI 编程助手通过文件变更进行“异步对话”，实现多代理协作。这种做法打破了 AI 工具孤立工作的局限，但也暴露了代理间因上下文不一致而产生的“相互指责”问题。
事件核心：发生了什么
在 Hacker News 上，多位开发者分享了让不同 AI 编程代理通过 Git 仓库互动的实践。具体做法是：一个代理（如 Claude Code）修改代码并提交到 Git，另一个代理（如 Codex）拉取更新并给出评审或修改。整个过程模仿了开发者间的 Code Review 工作流，但完全由 AI 代理自主完成。
一些开发者甚至为这一流程设计了专门的协议，例如 Agent Communication Protocol（ACP）和基于 Git 的上下文同步项目（如 GitHub 上的 csp 和 beads）。另有开发者通过 Jira 的自定义工作流管理代理任务，让 AI 代理像“不会抱怨的初级程序员”一样根据 Issue 执行操作。
值得注意的是，这种做法并非官方功能，而是社区自发探索的结果。Antropic 和 OpenAI 尚未官方支持多代理通过 Git 协作。
为什么重要
这一探索反映了 AI 编程工具从“孤岛式助手”向“协作式代理网络”演进的趋势。当前 Claude Code 和 Codex 等产品主要面向单次对话或单用户，无法自然形成“代理间的互相校验”。通过 Git 这一成熟工具实现代理间的异步通信，本质上构建了一个可审计、可版本化的 AI 协作层。
但实际效果并不完美。有开发者反馈：当要求 Claude Code 先设计模型，再让 Codex 评审同一模型时，Codex 经常“猛烈批评”前者的设计，并建议大量修改。这说明代理间的上下文不一致可能导致内部矛盾、重复工作，甚至浪费算力。开发者需要自行判断 AI 代理的“自信语气”与代碼实际质量之间的落差。
这一现象也凸显了多代理系统当前面临的共同挑战：缺乏有效的记忆同步和共识机制，导致代理之间容易陷入自我矛盾的循环。
对用户/开发者/创作者的影响
对开发者：该方法提供了一种低成本、可落地的多代理协作路径。开发者可以利用 Git、Jira 等已有基础设施，为 Claude Code 和 Codex 搭建互相审查的流水线，提升代码质量。但需要注意：AI 代理可能对自己之前的输出做出错误判断，开发者仍需人工介入最终决策，不能全盘信任代理的自动争论结果。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
对 AI 工具供应商：社区自发使用 Git 作为通信渠道，实际上是对现有 API 接口不足的弥补。这可能推动 Antropic 和 OpenAI 等公司官方推出更完善的多代理协作协议或记忆同步机制。目前已有像 Agent Communication Protocol（ACP）这样的标准化尝试，值得关注其后续被大模型厂商采纳的进展。
对普通用户/创作者：短期内影响有限，因为当前实践需要较高的技术门槛（了解 Git、代理工具、CI/CD 等）。但如果这种模式被产品化，未来非开发者用户也可能通过界面配置多个 AI 代理互相校验，减少生成内容中的事实性错误。
值得关注的后续
- 标准化协议能否落地：ACP 和 csp 等项目目前仍处于早期阶段，能否被 Claude Code 或 Codex 官方采纳，将决定这一模式是否会从“民间技巧”变为“官方能力”。
- 多代理共识与记忆问题：代理间的“相互指责”本质是缺乏共享记忆。后续是否有工具或算法能够解决 AI 代理之间的上下文一致性，是目前影响该方案实用性的关键瓶颈。
- 可追踪性与审计合规：使用 Git 作为通信层天然提供了完整的变更历史，这对于企业级 AI 使用场景（如代码审计、合规记录）具有吸引力。若大模型公司能在此基础上提供官方工具，将加速企业采纳。
来源：hackernews
