周三，agmsg在Product Hunt冲上第五，热度还没刹住车。它干的活儿很小：让一堆命令行AI智能体——Claude Code、Codex、Gemini CLI之类——靠一个共享的本地SQLite文件互发消息。没有守护进程，没有网络，中间不搞人肉复制粘贴。

但用的人多了，拼的阵仗也野了。一个反复出现的玩法是：某个智能体盯着自己的进度，一卡壳就跑去问另一个视野更大的模型，把自己从隧道视觉里拽出来。全程无需人类插嘴。智能体被当成团队在用。接着就是无止境的“我还想把那个智能体也加进来”“我要跑这种组合”。问题不坏，却把代码库里一直闷声膨胀的东西端上了台面。

打开网易新闻 查看精彩图片

1.1.0就是冲着这个软肋去的：它把agmsg的可扩展性——也就是新智能体怎么接、接得多安全——整个重写了一遍。

过去，加一种新智能体类型是体力活。核心里到处散落着分支判断：如果是claude-code就这样，如果是codex就那样。每添一个类型，至少改十几个地方。这是典型的泄露抽象——引擎居然背得出自己服务的每一个类型的名字。一个功能补丁根本补不上，得动地基，所以版本号跳成了1.1.0。

现在很简单：一个类型就是一个目录，里面装着数据和行为插件。只要在scripts/drivers/types/下面丢一个目录，配一份清单、几个可覆写的行为，核心自己就能认。核心代码里再没有哪怕一个写死的类型名（我把这一步叫引擎纯化，听着有点过）。

可以把这套机制看作插座和插头。agmsg核心是插座，每个智能体类型都是插头。现在加插头完全不用改插座内部的线。放在以前，不加插头就得拆插座。

实际的好处有两样：第一，加类型基本变成声明式了。以投递逻辑为例，核心用模板方法管住整个流程——apply、on_enable、on_disable、status——每个类型只在自家的_delivery.sh里覆写自己特有那点东西。清单里delivery_modes、stop_output、hook_windows_wrap这些数据驱动的键，能兜住大部分类型间的差异，根本不用碰共享代码。Codex的运行时，以前东一块西一块，现在老老实实待在types/codex/底下。

第二，核心维护成本骤降。把写死的类型名从共享脚本里抽掉，听起来乏味，却是最实在的收益。引擎眼下不偏袒任何一方，修它更省力，加新类型也几乎不会再误伤邻居。

这个插件机制在agmsg里有个正式名称：驱动。它就是连接智能体和核心的适配器。