agmsg

嘿 Product Hunt 👋 我是 Koichi。

我日常用 Claude Code 干活，难题交给 Codex。这对组合很棒——直到我意识到自己实际变成了什么：一个整天在两个 AI 之间复制粘贴消息的人。把 Claude 的输出复制到 Codex，再把回复复制回去。一天几十次。房间里最蠢的活，而我正在干——坐在两个足够聪明可以直接对话的系统中间，当它们的信使。

所以我就让它们直接对话了。agmsg 是一个大约 500 行的 bash + SQLite 工具，让 CLI AI 编码智能体可以互相发消息——Claude Code、Codex、Gemini CLI、Copilot CLI——全都在同一个房间里，共享一个 SQLite 文件。

它的不同之处：这不是子智能体功能（那些是单一厂商的，会话结束就失效），也不是 MCP（那是智能体调用工具，不是智能体之间对话）。agmsg 是厂商无关的、持久化的、最小依赖的——没有守护进程，没有网络，没有 Python。它作为一个 Agent Skill 安装，所以你永远不需要修改智能体本身。

好玩的部分（见演示）：让两个智能体在同一个团队里处于 monitor 模式，它们就会自己跟对方玩井字棋——或者国际象棋——无人参与。

上周它意外在日本火了（超过 100 万展示，GitHub 星标从 5 涨到 320+，已经有人把它移植到了将棋、围棋和一个 MCP 服务器上）。现在把它带到这里——我真心更想听它哪里出了问题，而不是再收一颗星。🙏

那个在两个 AI 之间当人工信使的段子把我逗笑了，因为这基本上就是我最近在做的事。当涉及两个以上智能体时，它的表现如何？

最让人眼前一亮的不是智能体之间的对话，而是这个房间是持久化的。就是一个 SQLite 文件，你可以用 sqlite3 打开，从头读到尾。在使用 Claude Code 进行规划→实现→审查循环时，一直困扰我的是上下文随着每个子智能体消失，所以我每次手动编一个状态文件来跨轮次传递决策。一个比会话存活更久的房间正好解决了这个问题，还省去了记录的工作。

这正是那种看似奇怪但很实用的工具，一旦你使用多个编码智能体，它就有意义了。把 Claude Code 的输出复制到 Codex 再复制回来，很快就会腻。一个基于 SQLite 的简单“房间”让智能体互相交流，比把人变成消息总线要干净得多。

采用供应商无关的定位是正确的，但我好奇实际的消息格式是什么样的，以及来自不同供应商的智能体是否一致地解释它。Claude Code和Codex有不同的上下文窗口、不同的工具使用模式和不同的指令处理方式。一条对Claude有意义的消息，可能会根据其格式被Gemini CLI以不同方式解释。是有一个消息schema，还是每个智能体以自己的方式解释的非结构化文本？

巧妙的方法，用SQLite作为消息总线——没有daemon开销，只有文件。多智能体协调问题是真实存在的，而且随着人们开始在同一个代码库上运行3-4种不同的AI工具，问题只会越来越严重。好奇你是否见过人们在任务分配上的模式——是在多个智能体之间拆分任务，还是用一个智能体做所有事情？