agmsg：用 SQLite 当黑板，让 Claude Code 和 Codex 互相喊话

它解决的是复制粘贴的痛点

CLI 智能体越来越多，但每个都是独立的会话。你让 Claude Code 写代码，让 Codex 做审查，结果你得把代码从 A 窗口复制到 B 窗口，再把评论复制回来。agmsg 的目标就是消灭这个中间人。它的设计文档说得很直白：你不再是智能体之间的信使。它用共享的 SQLite 文件作为通信地板，每个智能体通过 hook 或 monitor 流读取新消息，发送则是往数据库里追加一行。这个设计刻意避开了 MCP、消息队列和守护进程，整个项目就是一组 Bash 脚本。对于只想让两个智能体协作的工程师，这比搭一个完整的消息基础设施轻得多。

没有守护进程，SQLite 就是消息总线

agmsg 的核心机制很简单：每个智能体有一个 hook 或 monitor 流，读取同一个 WAL 模式的 SQLite 数据库。发送消息就是调用 send.sh，追加一行记录。没有 socket，没有 broker，没有常驻进程。数据库文件是共享的，智能体轮流读写。WAL 模式允许多个读者和一个写者并存，所以并发不是问题。历史消息会持久化在数据库里，会话结束后依然存在，history.sh 可以把旧房间重放到一个新的智能体会话中。这个设计的一个直接后果是：消息传递的延迟取决于智能体轮询数据库的频率，而不是推送。README 里演示了两个 monitor 模式的 Claude Code 实例玩井字棋，说明在 monitor 模式下，智能体可以实时感知对方的新动作。

安装路径不少，但都通向同一个目录

无论你选择哪种安装方式，agmsg 最终都会落在 ~/.agents/skills/agmsg/。最快的路径是 npx agmsg，它只是一个引导程序，会下载并运行官方的 setup.sh。如果你想要始终跟踪 main 分支的最新代码，可以 git clone 后运行 ./install.sh，这种方式会直接从 main 安装。npm 包和 Claude Code 插件是从 tagged release 构建的，所以可能落后 main 几个修复版本。安装时你可以指定命令名称，比如 ./install.sh --cmd m，这会决定技能文件夹的名称以及智能体中的触发方式。Claude Code 和 Copilot CLI 使用斜杠命令，比如 /m，而 Codex、Gemini CLI 和 Antigravity 使用 $m。安装后需要重启智能体才能识别新技能。

Windows 下的坑：没有 PowerShell 实现

agmsg 的实现完全是 Bash 脚本，没有 PowerShell 重写。在 Windows 上，你必须依赖 Git Bash 来运行这些脚本，并且要确保所有智能体共享同一个 $HOME 和 SQLite 数据库。README 特别警告：原生 Windows 的 Codex 命令和 hook 通常从 PowerShell 启动，而 PowerShell 无法直接执行裸的 .sh 文件。因此 agmsg 会自动生成一个 commandWindows 条目，调用 Git Bash 来执行。这个细节很容易被忽略，但如果你在 Windows 上使用 Codex，它可能是你遇到的第一个障碍。另外，如果你的最小 Linux 容器缺少 sqlite3，安装时会报错，你需要先安装 sqlite3 再重新调用。

不是 MCP，也不是子代理

agmsg 明确把自己和 MCP 区分开。它不是 MCP 服务器，没有额外的运行时，只是 bash 加 sqlite3。它也不是子代理机制。spawn 命令可以启动一个新的对等智能体，但那个智能体是独立的会话，不是当前智能体管理的子进程。这意味着你无法像管理子代理那样控制它，只能通过消息来沟通。这个设计选择是刻意的：它保持了对等关系，而不是主从关系。但这也意味着，如果你需要严格的父子任务编排，agmsg 不是合适的工具。它更适合让多个独立的智能体各自负责一块任务，然后通过消息协调。

限制：单机、无路由、无队列

agmsg 的架构决定了它的边界。没有 broker 意味着没有消息路由、没有优先级、没有消费者组。所有消息都堆在同一个 SQLite 表里，智能体需要自己过滤哪些消息是给自己的。README 提到可以通过远程设置同步团队，但那需要一个自托管的参考服务器，而且显然不是生产级消息总线。另外，虽然 WAL 模式支持多读单写，但写入仍然是单点的，如果多个智能体同时写入，需要依赖 SQLite 的锁机制。对于高吞吐或跨机器的场景，这个设计会很快成为瓶颈。它适合的是单机上的几个智能体互相协作，而不是大规模的事件驱动架构。

替代方案：MCP 和消息队列的对比

如果你需要更正式的智能体通信，MCP 是常见的替代方案。MCP 提供了标准化的工具调用和资源访问协议，有服务器和客户端的概念，适合需要动态发现工具的场景。而 agmsg 刻意不做这些，它只是一个文件共享。另一个方向是使用真正的消息队列，比如 Redis 的 pub/sub 或 NATS，这些可以提供持久化、路由和消费者组，但需要额外的守护进程和网络配置。agmsg 的优势在于零依赖，劣势在于功能简陋。如果你的智能体需要调用对方的工具，而不是仅仅交换文本消息，MCP 可能更合适。如果只是需要让两个智能体互相传递任务描述和结果，agmsg 的 SQLite 文件可能就够了。

维护成本与许可证

项目使用 MIT 许可证，这意味着你可以自由修改和分发，但要注意许可证原文中的免责声明，这里不构成法律建议。维护成本方面，agmsg 的代码量很小，核心是几个 Bash 脚本，所以排查问题相对容易。但 Bash 脚本的跨平台兼容性是个长期负担，尤其是 Windows 下的路径处理。另外，由于 npm 包和插件版本可能落后 main，你需要决定是跟踪 main 还是使用稳定版。README 提供了版本检查命令，/agmsg version 可以显示你当前运行的版本，如果包含 -g 和 commit hash，说明你领先于最新 release。升级时，直接重新运行安装脚本即可，但要注意自定义的命令名称可能会被覆盖。

编辑结论

如果你同时维护多个 CLI 智能体，并且受够了在终端之间手动搬运上下文，agmsg 值得一试。它适合那些已经接受 SQLite 作为共享状态、并且愿意为每个智能体配置 hook 的团队。不适合需要消息路由、持久化队列或跨机器可靠投递的场景，因为它的设计前提就是单机、无守护进程。在采用之前，先确认你的环境有 bash 和 sqlite3，并且你的智能体支持 hook 或 monitor 模式。对于 Codex 用户，要特别注意 Windows 下 Git Bash 的路径配置，否则 hook 可能无法执行。如果你需要跨机器同步，先阅读 docs/remote-setup.md 中自托管参考服务器的说明，但要知道那只是一个参考实现，不是生产级消息总线。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes