别再当 AI 之间的“传话员”:这个开源工具让 Claude Code 和 Codex 直接聊天

最近，越来越多开发者开始同时使用两个甚至多个 AI 编程助手。

有人习惯让 Claude Code 负责高频实现，再把复杂问题交给 Codex 推演；有人用一个 Agent 写代码，另一个 Agent 专门做 Review；还有人会把 Gemini CLI、Codex 和 Claude Code 放在同一个工作流里，各自处理擅长的任务。

问题是：AI 变多以后，人类反而容易沦为最忙的那一个。

复制 Claude Code 的实现，粘贴到 Codex 窗口；复制 Codex 的审查意见，再粘贴回 Claude Code；等修改完成以后，再重复一次。

一天来回几十次，不仅打断专注，还容易贴错上下文。

日本开发者 Koichi 最近开源的 agmsg，就是为了解决这个看起来很小、实际非常消耗注意力的问题：

让多个 CLI AI Agent 直接发送消息，不再需要人类手动搬运。

项目地址：

https://github.com/fujibee/agmsg

两个 AI 都很聪明，但中间还缺一条线

Koichi 的日常开发方式很典型。

他以 Claude Code 为主要实现工具，用它快速推进日常编码；遇到复杂逻辑或需要更高确定性的 Review 时，再把任务交给 Codex。

这种组合的重点，不是谁比谁更强，而是两者的工作风格不同：

• ●Claude Code 更适合持续推进实现，交互节奏快，执行步骤多；
• ●Codex 更适合处理棘手逻辑、做代码审查和正确性检查；
• ●两个 Agent 互相补位，比只依赖单一工具更稳定。

但当工作流真正跑起来以后，一个低效环节暴露出来：两个 Agent 之间没有直接的消息通道。

于是，人类承担了最机械的工作：复制、切窗口、粘贴、等待、再复制。

这不是算力问题，而是协作基础设施的问题。

agmsg 是什么？

agmsg 可以理解为 CLI AI Agent 之间的本地消息总线。

Claude Code、Codex、Gemini CLI，以及其他支持 Agent Skills 的 CLI 工具，都可以通过它加入同一个团队，然后互相发送消息。

它的核心设计非常克制：

• ●使用共享 SQLite 数据库保存消息；
• ●采用 WAL 模式，支持多个读取者和一个写入者并行工作；
• ●依赖只有 bash 和 sqlite3；
• ●不需要 Python；
• ●不需要启动专用服务；
• ●不依赖网络，消息全部保留在本地文件系统。

对于一个负责“传话”的工具来说，这种轻量设计非常重要。

如果安装一个消息桥接工具，还要额外启动服务、维护端口、配置认证、排查网络问题，它很快就会比复制粘贴更麻烦。

agmsg 的思路正好相反：把复杂度压到最低，只做一件事，让 Agent 之间可靠地交换消息。

30 秒跑起来

根据项目 README，最快的安装方式是一条命令：

执行远程脚本前，建议先打开 GitHub 仓库审阅内容。谨慎一些，也可以先克隆项目再安装：

安装完成后，重启 Claude Code 或 Codex，让工具加载新的 Skill。

然后分别运行：

第一次使用时，工具会询问团队名称和 Agent 名称。

只要两个 Agent 加入同一个团队，它们就可以互相传递消息。后续不必记复杂命令，直接用自然语言交代即可：

从文本文件到 SQLite：为什么这个设计足够实用

agmsg 并不是一开始就使用 SQLite。

作者先研究了 Claude Code 自带的 team 和 subagent 能力。这些机制更适合短生命周期任务：拆分一个子任务，执行完成，然后结束会话。

但如果目标是让多个 Agent 长时间持续协作，问题就不同了。

最初的文本文件方案足够简单，也能工作。但一旦进入“持久运行 + 并行访问”的场景，同时写入、文件损坏、消息历史管理都会逐渐变成实际问题。

SQLite 是一个合适的折中：

• ●比纯文本文件可靠；
• ●比单独部署数据库轻量；
• ●支持事务；
• ●消息历史天然可以查询；
• ●WAL 模式能够覆盖本地多 Agent 并发读写的需求。

这也是 agmsg 最值得借鉴的地方：它没有为了展示能力堆叠功能，而是围绕实际摩擦选择最小可用架构。

四种接收模式，适配不同 Agent

不同 CLI Agent 的底层能力并不完全一致。

Claude Code 提供 Monitor 工具和更丰富的 Hook 机制；Codex 目前没有对应的 Monitor 能力。

为了抹平差异，agmsg 提供了四种接收模式：

1. monitor：实时推送

monitor 是 Claude Code 的默认模式。

它通过 SessionStart Hook 启动 Monitor，并阻塞读取 SQLite 消息流。新消息到达后，会实时进入当前会话，延迟约为数秒。

适合希望两个 Agent 持续对话、减少人工检查的开发者。

2. turn：回合结束后检查

turn 是 Codex 的默认模式。

它会在 Agent 完成一轮回复后，通过 Stop Hook 检查是否有新消息。Codex 没有 Monitor 工具，因此无法像 Claude Code 一样持续监听。

它不是完全实时，但已经能够显著减少人工搬运。

3. both：实时监听加兜底检查

both 以 monitor 为主，同时保留 turn 检查作为兜底。

当监听流程异常时，消息仍有机会在回合结束时被发现。

4. off：完全手动

off 关闭自动接收，只在手动运行 /agmsg 时检查收件箱。

适合希望严格控制消息干扰的用户。

monitor 模式让 Agent 真正开始“对话”

手动检查和回合结束检查虽然能解决问题，但仍然存在时间差。

真正让 agmsg 变得有意思的是 monitor 模式。

作者做过一个演示：把两个启用 monitor 的 Claude Code 实例放进同一个团队，让它们通过 agmsg 玩井字棋。

人类只给出一次任务，之后两个 Agent 会互相发送落子信息，并自行完成整局游戏。

这当然不是生产场景，但它验证了一个关键点：

当消息通道足够轻量、足够实时以后，多 Agent 协作不再只是“人工调度多个聊天窗口”，而是 Agent 之间可以形成真正的反馈循环。

放到开发工作流里，这意味着很多过去需要手动转发的任务可以自然串起来：

• ●实现 Agent 完成代码后，通知 Review Agent 开始检查；
• ●Review Agent 返回问题清单；
• ●实现 Agent 根据清单修复，再主动请求复审；
• ●需求分析 Agent 将边界条件发给技术负责人角色；
• ●不同项目中的 Agent 复用同一个团队身份，共享消息历史。

它解决的不是大问题，而是高频问题

agmsg 没有试图发明一个庞大的多 Agent 平台。

它解决的是一个非常具体的问题：当开发者同时使用多个 CLI AI Agent 时，如何停止充当它们之间的“人工 API”。

它的价值也恰恰来自这种聚焦：

• ●本地运行，数据边界清晰；
• ●安装简单，依赖少；
• ●不修改 Agent 本体；
• ●支持 Claude Code、Codex 和 Gemini CLI；
• ●既能手动控制，也能逐步升级到更自动化的协作方式。

随着 AI 编程工具越来越成熟，下一阶段的效率差异可能不再只来自“选哪个模型”，而是来自“如何组织多个模型协同工作”。

模型能力不同并不可怕。真正浪费时间的是：已经拥有多个聪明 Agent，却仍然让人类负责复制粘贴。

如果你正在同时使用 Claude Code 和 Codex，可以试试 agmsg。