OpenMausBot(milind-soni/OpenMausBot):把「一队智能体」装进聊天应用的开源 Grok Bot 替代品

一、导读

2026 年 8 月到 10 月,xAI、Meta、OpenAI、Manus 在七周内先后发布了四款「个人智能体」产品,全部闭源、全部把模型与数据留在厂商一侧。OpenMausBot 给出了开源的第五种选择:它把智能体队伍做成一个 Telegram 式聊天应用,每个「联系人」都是一个真实智能体,跑在你本机已登录的 claude、codex、grok CLI 上,数据落在自己的磁盘。它在 2026-11-10 当日涨星 1589、总星 19,608(截至 2026-11-10,GitHub trending 数据),本文拆解它的双进程 harness 架构、权限中介与毫秒级决策路由,并给出四个可直接复现的应用场景。

二、项目速览

项目 内容
仓库 milind-soni/OpenMausBot(又名 MausBot,曾用名 OpenGrokBot)
定位 开源 Grok Bot 替代品:本机优先的多智能体聊天应用
当日涨星 1589(2026-11-10,GitHub trending daily 第 3 名)
总星数 19,608(截至 2026-11-10)
创建时间 2026-08-11(与 Grok Bot 公测同日启动)
技术栈 TypeScript strict、React 19、Vite、Tailwind CSS、Electron、Node 24+
许可证 Apache-2.0(enterprise/ 目录为 source-available 例外)
平台 macOS(签名公证 DMG)、Windows x64、Ubuntu 24.04 x64,iOS/Android 伴侣端
核心依赖 claude/codex/grok CLI(引擎)、Boat(云电脑)、Composio(500+ 应用)、Cua Driver(本机控制)
主要作者 Milind Soni(5367 次提交)、Omkar Satpute(官方博客联合作者)
发布节奏 v0.1.144 至 v0.1.151:2026-11-06 至 11-09 四天八个版本(GitHub Releases)
商业化 免费开源;Pro 每月 49 美元提供常驻云工作区;GitHub Sponsors 接受赞助

三、为什么是它:涨星背后的三股推力

第一股推力是「封闭四巨头」制造的需求外溢。据其官方博客梳理:xAI 的 Grok Bot 自 2026-08-11 起公测,10 月 12 日起并入 X Subscription 的 Premium(30 美元/月)、Super(100 美元)与 Ultra(200 美元)档;Meta Muse 于 9 月 8 日上线,仅限美国与加拿大;Manus 的 Cue 于 9 月 28 日开启邀请制;OpenAI 的 dots 于 9 月 29 日 DevDay 发布,仅限 Pro 与 Business Premium,且欧洲经济区、瑞士与英国被排除在外。四款产品共同点是:模型厂商替你选、智能体跑在厂商云上、数据存厂商侧。想要「自己选模型、数据不出本机」的用户自然外溢到开源方案。

第二股推力是 Grok Bot 自身的供给紧张。官方博客转述 TNW 报道称,11 月初有用户反映 Grok Bot 的每周用量池提前耗尽,马斯克承认「相对收入而言服务 Grok Bot 的成本高得不可持续」(此为项目方转述的二手信息,待确认原始报道)。用量收紧直接抬高了替代品的搜索热度。

第三股推力是项目本身的工程完成度。它不是命令行玩具:macOS 构建已签名公证,Windows 有单机安装器,Ubuntu 有 deb 与 AppImage;四天八个 release 的迭代节奏(11-06 至 11-09)显示维护极其活跃;从驱动适配、权限审批、云桌面到语音通话,整条「消息 → 智能体 → 工具 → 审批 → 电脑使用」的回路在 README 中逐层可查。涨星是市场对这种完成度投票的结果。

四、架构原理

4.1 整体架构:两个进程,一条事件流

OpenMausBot 的核心设计是「应用不持有任何传输通道」:聊天应用(React 19 + Electron,端口 5199)只通过 HTTP 发送类型化命令,并折叠单一 SSE 事件流进本地状态;真正拥有全部智能体进程的是本机 harness 服务(127.0.0.1:8799),它把每个厂商引擎的原生协议归一化为统一的运行时事件流,按线程落盘 NDJSON 日志。

flowchart TB
    subgraph app["聊天应用(React 19 + Electron,端口 5199)"]
        UI["聊天界面 · 模型选择器 · 电脑面板"]
    end
    subgraph harness["Harness 服务(127.0.0.1:8799)"]
        API["HTTP 命令 + SSE API"]
        REG["Driver 注册表"]
        BUS["事件总线(扇入 → 单条 SSE)"]
        BROKER["权限中介"]
        DEC["决策模型路由"]
    end
    subgraph engines["本机引擎 CLI"]
        CLA["claude CLI"]
        CDX["codex CLI"]
        GRK["grok CLI"]
    end
    UI -- "HTTP 命令" --> API
    BUS -- "单条 SSE 流" --> UI
    API --> REG
    REG --> CLA
    REG --> CDX
    REG --> GRK
    CLA -- "权限请求" --> BROKER
    CDX -- "权限请求" --> BROKER
    GRK -- "权限请求" --> BROKER
    REG -- "统一事件" --> BUS
    API -- "Boat API" --> VM[("云桌面 boat.dev")]
    API -- "Composio 会话" --> APPS[("Gmail · Slack · GitHub")]
    API -- "MCP stdio" --> EXT["Claude Desktop · Cursor · CI"]

OpenMausBot 双进程智能体架构手绘图:聊天应用(5199)、Harness 服务(8799,含驱动注册表、事件总线、权限中介与决策模型路由)、本机三个引擎 CLI 与 Boat 云桌面、Composio、MCP 的连线关系

这一分层把「界面」与「智能体运行时」彻底解耦:Electron 壳可以死掉重启,harness 里跑着的引擎进程不受影响;反过来,浏览器、手机伴侣端、脚本 CLI 与 MCP 客户端都可以作为同一 harness 的前端,因为它们消费的是同一条事件流。

4.2 驱动层:一份小契约收编三种引擎

server/contracts.ts 是整个系统的枢纽。每个引擎对应一个驱动文件(Claude 走 stream-JSON、Codex 走 JSON-RPC、Grok 走 ACP 协议),都实现同一份 SendTurnInput 契约。几个值得注意的细节:

  • 会话续接:resumeCursor 携带引擎原生的续接句柄(例如 Claude 的 session id),驱动按 botId 命名空间隔离进程级资源,避免不同机器人互相串线。
  • 稳定/易变系统提示分离:systemStable 与 systemVolatile 拆开,按线程常驻的 CLI 进程以稳定半段为键,请求制驱动则把易变半段塞进最新一条用户消息,保证缓存前缀字节一致——这是省 token 的关键设计。
  • 失败语义分层:TurnNotStartedError 及其子类把「回合从未开始」(引擎拒绝登录、用量限额拒绝)与「进行中失败」区分开,前者允许 harness 安全重试。用量限额还细分为 engine(账号级)、model(单模型窗口)与 credits(额度包)三种作用域,并带 resetsAt 时间戳。
export class TurnUsageLimitRefusedError extends TurnNotStartedError {
  readonly resetsAt: number | undefined;
  readonly scope: "engine" | "model" | "credits";
  constructor(turnId: TurnId, message: string, resetsAt?: number,
    scope: "engine" | "model" | "credits" = "engine", known = false) {
    super(turnId, message);
    this.resetsAt = resetsAt;
    this.scope = scope;
    this.known = known;
  }
}

未知驱动不会崩溃整支舰队:注册表把它降级为「不可用的影子快照」,UI 里置灰并给出原因。新增厂商只需在 server/drivers/ 加一个文件加一行注册,或者零代码接入任何说 ACP 的 CLI、任何 OpenAI 兼容端点。

4.3 权限中介:fail-closed 的审批卡

所有风险动作(shell 命令、文件编辑、智能体反问)都被驱动拦截为权限请求,送入 harness 的权限中介,在聊天界面折叠成 Allow / Deny 卡片。中介的裁决枚举只有四个值:allowed-once(只批当前这一问)、rejected、answered(直接回话)、unavailable(无应答者,默认 fail-closed)。approvalMode 每回合重新断言,防止续接的原生会话残留更宽松的旧模式;访客回合(guestConfined)禁 shell、禁文件夹外读取。云桌面与本机控制走同一套审批语义,行为一致。

4.4 决策模型路由:几百毫秒决定谁接话

群聊里没人被 @ 提及时,谁来接话?OpenMausBot 的答案是「小模型做路由、大模型做工作」:一个决策模型在几百毫秒内、约 0.00003 美元一次的成本下,读房间名、成员描述、最近几行与新消息,返回每个候选机器人的置信概率。默认引擎是 TypeSafe 的 Jev 分类器(校准概率),也可换 Cloudflare Workers AI 的 Clef-flash(免费额度每天一万 Neurons)或 OpenRouter 上的决策类模型(默认 typesafe/jev-1.13)。判定规则硬编码:单个机器人概率 ≥ 0.6 则它单独接话;「多个成员」≥ 0.6 则全员接话;其余回退到房间固定领队。回复下方会标注「Picked by Jev · 94%」这样的来源行。

"decider": {
  "enabled": true,
  "provider": "jev",
  "openrouterModel": "typesafe/jev-1.13",
  "jobs": { "roomRouting": true, "inboxTriage": true }
}

路由是 fail-open 的:超时(预算 1.5 秒)、网络错误、429/5xx、或答案校验失败(选项不在候选中、概率非数字、最概然选项与选择不一致)都直接回退到领队模式,决策模型永远不阻塞回合。密钥优先级固定为自有 Jev 键 → 自有 Workers AI 键 → Cloud 套餐内置 → OpenRouter。每次调用在 ~/.openmausbot/decider-log/ 落一行 NDJSON,只记选择、概率、延迟与状态哈希(16 位),不记消息文本;官方还内置了 53 条标注消息的房间路由回归评测(room-routing.eval.test.ts),用来验证 0.6 阈值在具体模型上是否成立。

4.5 电脑与工具:给每个机器人一台机器

每个机器人可以绑定三种「电脑」之一:Boat 云 Linux 桌面(独立实例、实时屏幕预览、浏览器可接管)、本机隔离 VM,或显式 opt-in 后的宿主机(macOS 与 Ubuntu Xorg 支持,Wayland 因安全闸门未解决而保持禁用)。应用连接走 Composio 会话:OAuth 一次,Gmail、Slack、GitHub、Notion、Linear 等 500 多个应用成为所有机器人的工具。本机控制由打包进发行版的 Cua Driver 0.41.3 承担,构建时只下载 tag 锁定的上游归档并校验 SHA-256、成员允许清单与内部可执行哈希,安装后绝不自行下载原生自动化代码——供应链这层做得比多数同类项目认真。

4.6 与同类架构路线的差异

同期的 Grok Bot 是「一个账号共享一台云电脑」(其官方文档明确提醒不要把不同机器人当作安全边界),Meta Muse 是「单个智能体 + 厂商云 VM」,dots 是「一个常驻智能体 + 厂商云电脑」。OpenMausBot 反着走:进程在本机、每机器人一台机器、数据在 ~/.openmausbot。代价也直接:合上笔记本电脑,本机智能体全部停摆(Pro 档的常驻云工作区是为补这个缺口而设);而没有中间服务器,意味着一切远程访问都要自己配隧道或配对。

五、应用场景

OpenMausBot 一条消息的完整旅程手绘图:从用户发消息、HTTP 命令到 Harness、决策模型路由、驱动派发、审批卡、云桌面、SSE 流式回显到回合结束的八步时序

场景一:一队各司其职的编码与写作智能体

痛点:单个聊天窗口里一个模型既写代码又写文案又做评审,上下文互相污染,换模型要整段重贴。 解决:每个机器人绑定一个引擎与模型——写作机器人挂 Claude、重构机器人挂 Codex、评审机器人挂 Grok,可以中途换模型不丢线程;群聊里 @ 提到谁谁干活,没提谁时决策模型自动路由;危险命令弹审批卡,你只看需要裁决的事。 最小示例:启动后新建三个机器人,分别在模型选择器里选 Claude、Codex、Grok 引擎;建一个「发布准备」频道,成员拉入三者,响应规则设为 Auto(Jev),然后发一句「@重构机器人 把 utils.ts 里的回调改成 async,完成后 @写作机器人 更新 README」。整个过程每个动作都有审批卡与屏幕预览。 收益:模型按任务分治,密钥与订阅复用已有账号,零新增月费(对比 Grok Bot 的 30 美元起);审批卡把「事后审计」变成「事前裁决」。 边界:需要本地常开;如果你想让它在你合盖后继续干活,本机架构帮不了你,要么开 Pro 云工作区,要么放一台常开的 Ubuntu 小主机。

场景二:定时任务与应用事件自动化

痛点:每天早上要人工翻邮箱、汇总群消息、盯表单提交,重复劳动多且容易漏。 解决:触发器即「某事发生时,某机器人做某事」。定时例程支持单次、指定星期几或每 5–1440 分钟间隔(间隔对齐起始时间,上一次没跑完就跳过本轮,不堆积);应用事件通过 Composio 推送——Gmail 每 15 分钟轮询,Slack、GitHub 等即时到达,桌面端用长轮询收取,无需公网地址;Webhook 走 127.0.0.1:8800 专用接收器,Bearer 认证或单次能力 URL。 最小示例:对机器人说「每个工作日早上 9 点,把收件箱里带『发票』主题的邮件汇总发到财务频道」,它会在当轮用 trigger 工具建好例程(聊天里出现可编辑、可暂停、可撤销的卡片);外部系统则调用:

curl -X POST http://127.0.0.1:8800/hooks/<触发器路径> \
  -H "Authorization: Bearer <密钥>" \
  -H "content-type: application/json" \
  --data '{"form":"contact","name":"王先生","need":"报价"}'

收益:例程与应用事件共用一套任务执行器与运行历史,漏跑可见;免费档每天 500 个应用事件、Cloud 档 2000 个,超出部分如实丢弃并在自动化详情里显示。 边界:桌面应用必须保持运行才能收事件;Webhook 接收器只暴露健康检查与钩子端点,公网投递需要自己经 Tailscale Funnel 或反代暴露这一个端口。

场景三:脚本与 CI 里的无人值守团队

痛点:把智能体塞进流水线时,轮询状态、判断完成、防重复投递都很麻烦。 解决:openmausbot 命令行可在无界面环境驱动整个团队:从一个 YAML 文件建队、派活、等全部队友完成、导出产物,--json 输出单文档、退出码可直接分支;同能力也以 stdio MCP 服务器开放给 Claude Desktop 与 Cursor。wait_for_conversation 是阻塞式等待而非轮询循环,返回 settled / needs-user / failed / stalled / timed-out 五态加脱敏的对话尾部;投递带幂等 send_id,重发拿回首次回执而不是产生第二条消息。 最小示例:

openmausbot team apply team.yaml
openmausbot run "领队" "彩排 example.com 的上线流程" --export ./out --json
echo $?

收益:CI 任务失败即得非零退出码;MCP 面有意收窄——v1 不能批准、不能删除、不能碰凭据与虚拟机生命周期,转录读取限 200 条分页、搜索限 100 条,截图像素与授权键一律剥离,把自动化爆炸半径压到最小。 边界:打包版上变更类 MCP 工具需要先完成一次性配对换取 omb_sess_ 令牌,只读工具在环回地址免令牌。

场景四:过安全评审的私有化智能体底座

痛点:企业想用智能体,但「数据必须不出网、代码必须可审计」卡死了所有云端产品。 解决:转录、密钥、事件全在 ~/.openmausbot;密钥只写不读(界面只见「已配置」标志,诊断导出自动掩码);可自托管乃至气隙部署——同一套应用,没有单独的企业版;代码全公开,评审者可以在第一次调用前读完每一行。自托管服务器只开一条路(自有反代、自有域名、Tailscale 或局域网),手机经配对码接入。 最小示例:VPS 上执行 npx openmausbot serve --public-url https://你的域名,打印一条配对链接,桌面应用「+ → 连接服务器」贴入即完成。 收益:对有安全评审的组织,这一条通常直接终结选型讨论;配套的供应链校验(tag 锁定、哈希验证、SBOM 清单)进一步降低引入风险。 边界:API 密钥在自托管模式下以明文存于 0600 权限的 config.json(README 自述),磁盘加密与主机加固仍是你的责任。

六、快速上手

最省事的路径是下载发行版:macOS(Apple silicon 与 Intel 双 DMG,已签名公证)、Windows x64 安装器、Ubuntu 24.04 的 deb 或 AppImage。前置条件只有一条:本机装有并已登录 claude、codex、grok 任意一个 CLI,装好的引擎会自动出现在模型选择器。从源码跑则是:

git clone https://github.com/milind-soni/OpenMausBot && cd OpenMausBot
pnpm install
pnpm dev:server    # harness 服务 → 127.0.0.1:8799
pnpm dev           # 应用 → http://127.0.0.1:5199
pnpm dev:desktop   # Electron 壳

可选增强按需粘贴密钥:Composio 项目键(应用连接)、Boat API 键(云桌面)、ElevenLabs 或 Fish Audio 键(语音)、Jev 或 Workers AI 键(决策路由)——全部可选,本地聊天不配也能用。

七、横向对比

维度 OpenMausBot Grok Bot(xAI) Meta Muse OpenAI dots
形态 一队机器人,聊天应用 一队机器人,聊天应用 单个智能体 单个常驻智能体
价格 免费;Pro 每月 49 美元 Premium 30 / Super 100 / Ultra 200 美元档 免费 + Power 20 / Maximum 100 美元 含于 Pro 与 Business Premium
模型 每 bot 任选(Claude/Codex/Grok) 系统代选,无选择器 Muse Spark 单模型 GPT-6 Astra 单模型
运行位置 本机 CLI + 每 bot 一台电脑 账号共享单台云电脑 厂商云 VM 厂商云电脑
数据位置 本机 ~/.openmausbot 云端(强制) Meta 云(官方文档称可访问) ChatGPT 云
审批 每个风险动作一张 Allow/Deny 卡 判断性动作拉你入场 未公开细节 未公开细节
合盖续跑 否(Pro 补足) 是 是 是
自托管/气隙 是 否 否 否
开放性 Apache-2.0 专有 专有 专有

(表格内容截至 2026-11-10,来源为各产品官方页面与 OpenMausBot 官方博客整理;Muse 与 dots 的审批细节官方未完整公开,标注为未公开。)

八、局限与风险

工程之外要看清四件事。其一,本机优先是双刃剑:合盖即停是物理规律,官方自己的对比文也承认「观察学习工作流」(Grok Bot 的 Teach a task)与「合盖续跑」两行仍属于 xAI。其二,人力集中:5367 次提交里绝大多数来自 Milind Soni 一人,虽然有数位贡献者与活跃的发版节奏,巴士因子偏低,长期维护取决于作者个人投入。其三,平台成熟度分层:macOS 是一级公民,Windows 与 Ubuntu 仍在追赶(Wayland 宿主控制禁用、Ubuntu 整体 beta、Linux 听写仍在计划中),README 的能力矩阵写得诚实,选型前应对号入座。其四,安全边界要自己守住:本地密钥明文落盘(0600)、宿主控制需要显式 opt-in 且依赖人工审核过的第三方驱动、Webhook 公网暴露需要自己搭隧道——「数据在你机器上」不等于「风险全消除」,它只是把控制权(和责任)交还给你。

九、小结与行动建议

OpenMausBot 把 2026 年秋季最热闹的「个人智能体」产品形态拆开重装成了开源版本,工程上最值得学的是三点:应用与运行时分离的双进程架构、把多引擎差异收进一份小契约的驱动层设计、以及「小模型路由 + fail-open 回退」的群聊调度。行动建议:

  1. 已持有 Claude、Codex 或 Grok 订阅的用户,先从发行版 DMG/exe 装起,把两个高频重复任务做成例程试水。
  2. 想评估架构的工程师,直接读 server/contracts.ts 与 server/drivers/,驱动 SPI 是全仓库信息密度最高的部分。
  3. 需要数据不出网的企业场景,优先验证自托管模式与配对流程,再谈规模化。
  4. 依赖合盖续跑的用户,明确它当前做不到,要么上 Pro 云工作区,要么备一台常开主机。
  5. 把它当 Grok Bot 平替之前,先确认自己的用量模式:重交互、轻后台者收益最大;重无人值守者需评估缺口。

参考资料

  1. GitHub 仓库与 README:https://github.com/milind-soni/OpenMausBot(获取日期 2026-11-10)
  2. 决策模型文档 docs/decision-model.md:https://github.com/milind-soni/OpenMausBot/blob/main/docs/decision-model.md(获取日期 2026-11-10)
  3. MCP 服务器文档 docs/mcp-server.md:https://github.com/milind-soni/OpenMausBot/blob/main/docs/mcp-server.md(获取日期 2026-11-10)
  4. 驱动契约源码 server/contracts.ts:https://github.com/milind-soni/OpenMausBot/blob/main/server/contracts.ts(获取日期 2026-11-10)
  5. 官方博客《Grok Bot vs MausBot: a feature-by-feature comparison》:https://www.openmausbot.com/blog/grok-bot-vs-openmausbot(获取日期 2026-11-10)
  6. 官方博客《Muse vs Grok Bot vs Dots vs Cue: which agent to pick》:https://www.openmausbot.com/blog/muse-vs-grok-bot-vs-dots-vs-cue(获取日期 2026-11-10)
  7. GitHub Releases 与贡献者数据:https://github.com/milind-soni/OpenMausBot/releases(获取日期 2026-11-10)
  8. GitHub Trending(当日涨星数据来源):https://github.com/trending?since=daily(获取日期 2026-11-10)
← 返回资讯列表

读者留言

COMMENTS 暂无
仅本站原创文章开放留言 · 请勿留下手机号、邮箱等个人信息

还没有留言,来说第一句?