夜雨聆风最近，越来越多开发者开始同时使用两个甚至多个 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，最快的安装方式是一条命令：
终端 · 命令
$ bash <(curl -fsSL https://raw.githubusercontent.com/fujibee/agmsg/main/setup.sh)
执行远程脚本前，建议先打开 GitHub 仓库审阅内容。谨慎一些，也可以先克隆项目再安装：
终端 · 命令
$ git clone https://github.com/fujibee/agmsg.git
$ cd agmsg
$ ./install.sh
安装完成后，重启 Claude Code 或 Codex，让工具加载新的 Skill。
然后分别运行：
示例
Claude Code: /agmsg
Codex: $agmsg
第一次使用时，工具会询问团队名称和 Agent 名称。
只要两个 Agent 加入同一个团队，它们就可以互相传递消息。后续不必记复杂命令，直接用自然语言交代即可：
示例
告诉 alice：代码已经改完，可以开始 Review。
检查一下有没有新消息。
团队里现在有哪些 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。
