一夜涨近2000星的"开源Grok Bot"，我在1核2GB小机上装了一遍：壳是真的，脑子得自备

GitHub Trending 这两天有个项目蹿得很凶：OpenMausBot，TypeScript 写的。我看它的时候总星数 1.7 万出头，24 小时增星近 2000，附带 364 个 fork，和我看到的第三方星标统计量级一致。它给自己贴的标签是"开源的 Grok Bot 替代品"------就是马斯克那个把 AI 助手做成联系人列表的产品，有人受启发用开源的方式重了一个，跟 xAI 没有隶属关系，国内科技号这两天也开始跟进报道。

这个赛道今年明显热起来了。OpenMausBot 的 README 开篇算过一笔账（四个名字都直接写在那里）：2026 年头七周里有四个闭源"个人 agent"产品接连发布，Meta 的 Muse、OpenAI 的 dots、Manus 的 Cue，加上 xAI 的 Grok Bot，共同点是都把模型、执行环境和你这台电脑隔在自家服务那一侧。它的切入点就是把这层壳开源掉：bot 跑在你本机已经登录的 CLI 上，数据落在你自己的硬盘里，Apache 2.0 协议。

我对这类"给 AI 配电脑"的项目一直有个疑问：宣传里什么都像模像样，可它本质上要靠你机器上已经登录的 claude、codex 或者 grok 命令行工具来干活。那对没有这些订阅的人------比如我------装上之后它到底剩多少东西？这个问题热榜没人答，README 更不会答。正好手头那台 1核2GB 的 Ubuntu 小机闲着，我把它装起来拆了一遍。

装起来：卡在 Node 24

先撞上的不是项目本身，是环境。npm 上的包信息写得很明白：engines: node >=24，而小机上是 Ubuntu 源里的 v22.23.2。它还真不是随便写的------后面会看到，这个项目直接用了 Node 24 内置的 SQLite 模块，旧版本跑不了。

不想动系统默认的 node，我下了 v24.11.0 的官方二进制解压到 /opt/node24，210MB。没用 nvm 是有考虑的：这台小机跑着几个常驻任务，nvm 往 shell 配置里挂钩子，切换或重装容易把别人的环境带偏；解压到 /opt、用的时候 PATH 指过去，删目录就卸载，对一次性的实测更干净。然后用它自带的 npm 装：

bash 复制代码

export PATH=/opt/node24/bin:$PATH
npm install -g openmausbot

27 个依赖，5 秒装完，占 159MB，全程零编译，机器上多出来的入口命令就一个 openmausbot。多数同类项目会绑 better-sqlite3 这类 native 模块，装包时现场编译，经常在国服网络下卡到怀疑人生；它直接用 Node 24 内置的 node:sqlite，代价是逼所有用户升 Node 24。至少在这台小机上，五秒装完确实省了我看编译报错的时间。

装完直接跑 openmausbot，被泼了第一盆冷水：

sql 复制代码

No setup yet. Run openmausbot setup in an interactive terminal first,
or start unattended with openmausbot serve.

裸命令默认走交互式 setup 向导，我这种 SSH 里没终端交互的场景不行，得用 serve。这个区分倒是想得周到------start 是给人用的，serve 是给服务器用的。起服务，第一行日志就很有意思：

csharp 复制代码

(node:11) ExperimentalWarning: SQLite is an experimental feature

Node 24 的 node:sqlite 还是实验特性，启动时会警告。我一开始以为这是脚本里哪个依赖打的，后来数了数，警告打了两次------两个进程，各打一次。这项目真的把官方实验特性当生产依赖在用。

服务起来后两个端口都绑在 127.0.0.1 上：8799 是主服务（harness server），8800 是 webhook 接收器。curl 一下 8800 的健康检查：

ruby 复制代码

$ curl http://127.0.0.1:8800/health
{"app":"openmausbot-webhooks","ready":true}

启动日志里还有两行值得记：一行说 browser engine: unavailable (agent-browser is not installed on this machine yet)------它自带的浏览器引擎要单独用 openmausbot browser install 装；另一行更有意思，open-source edition (enterprise layer present but OMB_LICENSE_KEY is not set)，这个后面单说。

数据落在哪：一个 SQLite 库管到底

README 反复强调 local-first，数据都在 ~/.openmausbot。我进去翻了一圈，结构比想象的干净：bots.json 存 bot 定义，attachments/、events/、meetings/ 各管一摊，核心是那个 messages.db。用 node:sqlite 直接打开看表结构，这库比我预想的有料：

复制代码

chat_followups, command_receipts, memory_files, memory_fts,
memory_fts_config, memory_fts_data, memory_fts_docsize,
memory_fts_idx, messages, messages_fts, messages_fts_config,
messages_fts_data, messages_fts_docsize, messages_fts_idx,
notification_log, thread_state

先说 WAL。目录里躺着 messages.db-shm 和 messages.db-wal 两个文件，说明它开了 WAL 模式，聊天读写走的是 WAL 而不是锁整库------对一个可能同时有多个 agent 进程往里写的场景，这是对的选型。更让我意外的是那几张 _fts 后缀的表。它们是 SQLite 的 FTS5 全文索引，而且不止建了聊天记录一份（messages_fts），bot 的长期记忆也有一套（memory_files + memory_fts）。也就是说"每个 bot 记得自己线程里聊过什么"这个功能，落地上就是一个 SQLite 库里的两张 FTS 表，没有引入任何外部向量库或者存储服务。

剩下的表名也能读出设计意图：thread_state 管线程游标，command_receipts 存命令执行凭证，notification_log 记通知发送记录。审批除了聊天里那张卡片，还有落库凭证可查。查了一下当前库里就 messages 表有内容，躺着一条欢迎消息，memory_files 是空的------bot 还没开始记东西。 bots.json 里那个默认 bot 我也看了眼，有个小细节：soul 字段是空的，旁边 soulHash 躺着 e3b0c442... 开头的一串------熟悉密码学的会笑，那是空字符串的 SHA256。哈希照算不误，设计上是一板一眼的。另外每个 bot 默认 chiefOfStaff: true，approvalMode: "full"，出厂默认就是先审后动。

没有那三把 CLI 会怎样：这是它真正的门槛

先把它的架子看明白，这决定了后面的实验怎么设计。README 里画过架构图，实测对得上：整套东西是两个进程，web 界面（React）只发 HTTP 命令、收一条 SSE 事件流；所有 agent 进程归 8799 上的 harness server 管，每家 CLI 被各自的 driver 包装成统一的事件流，再逐线程落成 NDJSON 日志；危险的 shell 命令和文件改动先过 permission broker，变成聊天里的审批卡片。这个设计带来一个可以直接验证的性质：driver 全部不可用时，架子应该照常运转。

前面都是铺垫，我真正想知道的是这个：不装 claude/codex/grok 任何一家 CLI（我也没有这些订阅），这套系统还剩什么。它自己怎么汇报这件事？打开 /api/config，一整排 provider 全是 configured: false------anthropic、openai、deepseek、groq、openrouter、mistral，一个没落。composio（它接 Gmail、Slack 那些外部应用的通道）直接标 unavailable。等于说联网能力和应用连接这两块，裸机状态下全是关的。倒是 8799 的 /api/health 一切正常，capabilities 里 guardedMessages、guardedRequests、guardedFullAccess 全是 1------审批闸门都装好了，只是没活可放行接口报的都是好话，能不能干活得试，也就是我真正想验的那一下。项目带了个 headless 命令，文档里说可以从脚本直接给 bot 派活：

vbnet 复制代码

$ openmausbot run "MausBot" "list files in current dir"
error: provider instance "" is unavailable --- pick another model in settings

没有崩溃，没有半路卡死，就是一行干脆的报错。这个行为本身我是认可的------README 里写过"未知的 driver 一律降级为 unavailable，不能拖垮整个 fleet"，实测对得上。但结论也很直白：没有那三把 CLI 或者一个 API key，它就是个带完整后台的空壳 。聊天界面能开（8799 根路径返回的是个 933 字节的 HTML 壳，真正的界面靠 JS 拉 /api/bots 渲染，能查到那一个默认 bot 和它的一条欢迎消息），消息落库、审批卡片、线程状态这些骨架都在，唯独真正干活的脑子要你自己带。顺带一句，脚本化检查它活没活着别 curl 根路径，直接打 /api/health。这大概解释了它的走红逻辑：它解决的是"我已经付了 Claude 或者 ChatGPT 的订阅，但受够了在终端里单线程使唤它们"的问题------把 CLI agent 包成联系人、加上审批和电脑，赚的是体验层。至于"没有订阅的人能不能白嫖"，README 从头到尾没承诺过"没有订阅也能用"，这条边界实测画清楚了。

藏在同一个二进制里的企业版

拆的时候翻到一条线，不少报道没提。openmausbot --help 列子命令时，最后一段是 fleet：

lua 复制代码

openmausbot fleet init --domain HOST [--operator USER]
                  | create NAME --admin EMAIL ... [--cap USD]
                  | list | users NAME add|remove EMAIL ...
                  | suspend NAME | resume NAME | delete NAME --yes

多租户：建组织、加用户、封禁、恢复。配合启动日志里那句 enterprise layer present but OMB_LICENSE_KEY is not set------企业版跟开源版共用同一个二进制，买 license 就解锁。这个路数跟 GitLab 当年 CE/EE 合并包的做法一个思路，个人用完全无感，公司想管一队人的 agent 时它已经替你想好了开关。 --cap USD 这个参数我多看了两眼。个人 agent 工具谈钱是个绕不开的话题------每个 bot 背后都是真金白银的订阅消耗，团队场景里谁来兜底是管理员最头疼的事。它把花费上限做进 fleet 的创建流程，配合 suspend/resume，等于把"agent 车队要预算管控"这件事写进了产品流程，文档提醒变成了实际开关。运维侧还有个 sentinel 子命令，只读健康巡检，service install --sentinel 可以让健康扫描每两分钟跑一次代替完整服务常驻------对 2GB 内存的小机来说，省下常驻进程的内存不算小事。

所以值不值得追

我的判断，两句话。

手里有 Claude 或 Codex 订阅、日常拿 CLI agent 干活的人，这个项目值得装：它把散落的 CLI 包成了有记忆、有审批、有定时任务的工作台------README 里叫 triggers，日程和 webhook 都能触发 bot 干活，webhook 接收器实测只开在 127.0.0.1:8800，只暴露 /health 和带密钥的 /hooks 路径，不出本机。本地落盘、默认全审批，架子搭得比大多数同类认真；npm 的发布记录里数了数，半个月发了 24 个版（0.1.125 到 0.1.148，最新一版是今天凌晨刚推的），修复速度也算得上有保障。

没有这些订阅、只是被"开源 Grok Bot"的标题吸引进来的，先冷静。装上你会得到一个精致的壳和一套值得学习的架构（harness 收口所有 agent 进程、permission broker 把每个危险动作变成审批卡、SQLite 一把梭本地存储），但发不出一条真消息。它的爆火建立在"你已经有 agent CLI"这个前提上，这个前提在中文社区里普及率没那么高。

我自己的收获反倒是架构那部分：想把多个 CLI agent 收进一个进程里管，driver 注册表加统一事件流这套设计，值得留着抄。红不红是它的事，对我有没有用是另一码事------这台小机上的一个下午，比刷十条二手解读值。