AI 编码 Agent 之间怎么通信？Agentcomm 用 Git 仓库当消息总线，零依赖也能发消息

当你的 Claude Code 写完一个模块，想让 Codex 接着处理测试——这两个 Agent 怎么互相通知？开个 Slack 频道？写个共享文件？搭个 Kafka？这些方案要么太重，要么需要额外基础设施。

Agentcomm 是一个极简的 AI Agent 消息总线——一个 CLI 工具，让你的 Agent 通过 Git 仓库收发消息。不需要服务器、不需要队列、不需要第三方服务——你的 Git 仓库本身就是消息总线。

问题：多个 AI Agent 在同一个项目上如何协作？

实际开发中，你可能会在同一个项目上同时使用多个 AI 编码 Agent：

• Claude Code 写后端逻辑，Cursor 写前端组件
• Codex 做代码审查，OpenCode 负责测试
• 一个 Agent 生成代码，另一个 Agent 验证其正确性

但目前的生态里，Agent 之间没有标准的通信机制。每个 Agent 有自己的会话上下文，不知道其他 Agent 在做什么。常见的临时方案包括：

1. 共享文件：在约定路径写 JSON / Markdown 文件，靠文件修改时间做信号——脆弱、无锁、易冲突
2. Git 提交：Agent 提交代码后，另一个 Agent pull 下来看 diff——但 diff 不包含显式的”任务完成”语义
3. 外部消息服务：Slack、Discord、Webhook——需要额外账号和基础设施

Agentcomm 的解决思路非常优雅：你的 Git 仓库本来就支持读写和推送，那为什么不让它同时充当消息总线？

Agentcomm 是什么？

Agentcomm 是一个开源的（MIT）TypeScript CLI 工具，为 AI Agent 提供了一套简洁的”邮箱”模型。每个 Agent 可以注册自己的身份，向其他 Agent 发送消息，查看自己的收件箱。

核心概念只有三个命令：

消息数据存储在 Git 仓库的一个特殊分支（agentcomm）里。当 Agent A 向 Agent B 发消息时，Agentcomm 在仓库中创建一条消息记录，推送到远程。Agent B 通过 agentcomm inbox 拉取并读取。

六种后端，一套接口

Agentcomm 最巧妙的设计是”One seam, swappable transport”——CLI 命令不变，底层存储可以自由切换。目前支持 6 种后端：

默认情况下，Agentcomm 会自动检测当前仓库的 origin 远程地址。如果 Git 可达，总线自动设为 git+——零配置即可工作。

消息模型：不只是一个收件箱

Agentcomm 的消息模型比简单的”发-收”更丰富。每条消息存储在 agents/.json（注册/心跳）、inbox//_.json（待处理）和 read//_.json（已归档）三层结构中。

是零填充的单调递增前缀，按发送顺序排列。消费消息时，Agentcomm 将其从 inbox/ 移动到 read/——消息不会硬删除，形成完整的审计轨迹。这意味着你随时可以回溯 Agent 之间的所有通信记录，排查协作中的问题。

同时还支持 claim（共享队列） 模式：多个 Agent 可以竞争消费同一条消息（类似消息队列的竞争消费者模式），原子性地从队列中取出——适合任务分配场景。

快速上手：60 秒上总线

以 Claude Code 为例，安装 Agentcomm 插件只需两条命令：

/plugin marketplace add yonidavidson/agentcomm
/plugin install agentcomm@yonidavidson-plugins

agentcomm register

agentcomm send bob "后端 API 已完成，可以开始写前端了"

agentcomm inbox

对于 Codex 和 OpenCode，安装方式类似：

codex plugin marketplace add yonidavidson/agentcomm
codex plugin add agentcomm@yonidavidson-plugins

初始化项目协作配置也非常简单——agentcomm init 会创建 CLAUDE.md（Claude Code 自动读取）或 AGENTS.md（Codex / OpenCode 读取），让所有加入项目的 Agent 自动获知总线信息。

生命周期钩子：Agent 状态的隐式广播

Agentcomm 的每个原生插件都会覆盖 Agent 的生命周期事件——会话启动、长时间运行、任务消化、停止守卫——并将它们映射为总线上的状态更新。Claude Code 的插件将任务事件映射为总线状态；Codex 和 OpenCode 使用显式的状态更新；OpenCode 还通过生命周期钩子自动执行注册和心跳。

这意味着你不仅能发送显式消息，还能通过总线感知其他 Agent 的实时状态——”Claude Code 正在处理模块 X”、”Codex 已经消化完测试结果”——而不需要 Agent 自己手动报告状态。

实际场景：三 Agent 协作流水线

假设你在开发一个 Web 应用，让三个 Agent 协同工作：

1. Claude Code 生成后端 API 代码
2. Cursor 编写前端组件
3. Codex 做端到端测试

工作流可以是这样：

agentcomm register
agentcomm send cursor "POST /api/users 接口已完成，请求/响应格式见 api-docs.md"
agentcomm send codex "后端 API 基本路由已就绪，可以开始写集成测试了"

agentcomm inbox
agentcomm send claude-code "登录页面已对接 /api/users 端点"

agentcomm inbox

所有通信记录都保存在 Git 仓库的 agentcomm 分支中，可以随时查看双向沟通历史。如果某个 Agent 的行为出现问题，审计轨迹让你能够清楚地看到消息流转过程——谁来、何时、发了什么、谁读了。

为什么选择 Git 作为消息总线？

这看起来有点”反常规”，但仔细想想 Git 天然适合这个角色：

• 已有 Git 仓库的项目不需要额外基础设施——不需要安装 RabbitMQ、Redis 或 Kafka
• Git 天然支持推送和拉取——Agentcomm 利用标准的 Git 操作，不需要特殊协议
• Git 分支本身就是通道——agentcomm 分支就是消息队列，主线是代码，两者互不干扰
• 审计性——每条消息的提交记录了发送者、时间戳和内容，天然不可篡改
• 跨平台——Git 是几乎所有开发环境的标准配置，Agentcomm 的 Git 后端零依赖

当然这不是万能的——高频消息场景下 Git 的 push/pull 延迟可能成为瓶颈。对于需要毫秒级响应的场景，Agentcomm 的 SQLite 或 Postgres 后端可能更合适。但对于大多数 AI Agent 协作场景（任务分配、进度通知、模块交接），Git 总线的”秒级延迟”完全够用。

总结

Agentcomm 解决的痛点是真实且普遍的——任何同时使用多个 AI 编码 Agent 的开发者都会遇到”Agent 之间怎么协调”这个问题。它的设计哲学很清晰：不要重新发明基础设施，用好已有的东西。你的代码仓库本来就是协作中心，Agentcomm 只是把协作从”人 ↔ Agent”扩展到了”Agent ↔ Agent”。

如果你的项目中有多个 AI Agent 在并行工作，试试 Agentcomm——它不会让你的 Agent 突然变聪明，但至少它们能互相说上话了。

相关链接：

• GitHub 仓库
• 官方文档站
• 在线演示 — 真实的 Agent 对话分支