OpenMausBot（milind-soni/OpenMausBot）：把 Claude、Codex、Grok 变成自带电脑、事事请示的「AI 员工舰队」

一、导读

2026 年秋天，「一排 AI 机器人聊天的应用」成了继编码智能体之后的下一个产品形态：xAI 的 Grok Bot、Meta 的 Muse、OpenAI 的 dots、Manus 的 Cue、Spear Street 的 Instinct 在七周内密集上线。开源阵营里完成度最高的对应物是 OpenMausBot——GitHub Trending 显示它在 2026 年 10 月 30 日单日涨星 1190、总星 7223（截至 2026-10-30），位列日榜第四。它把 Claude、Codex、Grok 三家 CLI 收进一个本地聊天应用，每个机器人分一台电脑、一件带审批卡片的工具箱，再加一个 300 毫秒选人的决策模型。本文拆解它的双进程架构、驱动适配层、审批分级与工具桥设计，并给出四个可复现的使用场景。

二、项目速览

维度	情况
仓库	milind-soni/OpenMausBot（又名 MausBot，前身 OpenGrokBot）
定位	开源的 Grok Bot 替代品：把多家 agent CLI 收进一个聊天应用
当日涨星	+1190（2026-10-30，GitHub Trending 日榜第四）
总星 / fork	7223 星 / 1091 fork / 540 个开放 issue（截至 2026-10-30）
创建时间	2026-08-11；近 7 天连发 8 个版本，最新 v0.1.132（2026-10-29）
技术栈	TypeScript + React 19 + Electron + Vite + Tailwind CSS
引擎支持	Claude、Codex、Grok 官方 CLI；OpenCode、Gemini CLI、Qwen Code、Cursor CLI、Cline 等 ACP 引擎；OpenAI 兼容端点
外设生态	Boat 云电脑（每 bot 一台）、Composio 500+ 应用、Cua 驱动（本机控制）、五种语音合成
许可证	Apache 2.0（enterprise/ 目录 source-available，删掉即是纯开源版）
主创	Milind Soni（4201 次提交，单人主导）

三、为什么是它：一天 1190 星的三个动因

需求侧，闭源产品锁得太死。 Grok Bot 只能跑 Grok，2026 年 8 月 26 日起捆绑在 SuperGrok（30 美元/月）与 Cursor Pro（20 美元/月）及以上计划里；Meta Muse 是绑在 Meta 云虚拟机上的单 agent，只限美国和加拿大；OpenAI dots 绑 ChatGPT Pro 与 Business Premium。手里已经有 Claude 或 Codex 订阅的用户，被要求为同一个形态再买一份。

供给侧，OpenMausBot 的答案是 bring your own agent。 机器人跑在你已经装好、登录过的 claude、codex、grok CLI 上，直接复用既有订阅与限速，中间没有代理层；对话记录、密钥、事件全部落在 ~/.openmausbot 本地目录。官方对比博客的原话是：对要做安全审查的团队，「数据在你自己磁盘上」这一行通常直接终结讨论。Apache 2.0 许可加上可整体删除的 enterprise/ 目录，也让它成为同类里唯一能放心改造的底座。

节奏侧，小步快跑撞上品类风口。 2026 年 8 月 11 日建仓，不到三个月做到 7200+ 星；近 7 天连发 8 个版本（v0.1.125 到 v0.1.132），一周内落了审批分级、MCP 控制面、团队模板导入等大功能；9 月 17 日上过 Show HN，10 月 28 日再被提交 HN，官网显示已入选 Google for Startups 云计划与 Claude for Startups。引爆 10 月 30 日单日暴涨的直接传播节点未能核实（待确认），但功能密度与品类热度是可查证的底座。

四、架构原理：两个进程、一条事件流、一道审批闸门

OpenMausBot 的整体架构可以概括为「前端零传输、后端一个 harness、引擎各自进程、风险统一过闸」，四层结构与关键数字见下图：

OpenMausBot 架构原理手绘图：聊天界面层 App、Harness server（Driver 注册表、事件总线、权限代理、Jev 决策模型）、引擎进程层与资源层四层结构

flowchart LR
    subgraph app["App（React · 127.0.0.1:5199）"]
        UI["聊天 UI · 模型选择 · 电脑面板"]
        ST["单一 store · 零本地传输层"]
    end
    subgraph server["Harness server（127.0.0.1:8799）"]
        API["HTTP 命令 + 单条 SSE"]
        REG["Driver 注册表"]
        BUS["事件总线 · NDJSON 逐线程落盘"]
        PB["权限代理 Permission broker"]
        DEC["Jev 决策模型"]
    end
    subgraph engines["本机引擎进程"]
        CL["claude CLI"]
        CX["codex CLI"]
        GK["grok 与 ACP 引擎"]
    end
    UI -- "HTTP 命令" --> API
    API -- "一条 SSE 事件流" --> UI
    API --> REG
    REG --> CL & CX & GK
    CL & CX & GK -- "权限请求" --> PB
    REG --> BUS --> API
    DEC -. "房间路由 · 约 300ms" .-> REG
    server -- "Boat API" --> BOAT["云电脑 · 每 bot 一台"]
    server -- "OAuth 一次" --> COMP["Composio 500+ 应用"]

双进程：App 不碰传输，server 拥有一切

官方「How it works」一句话讲完：应用不持有任何传输，只发送带类型的 HTTP 命令、折叠一条 SSE 事件流进状态；harness server 拥有每一个 agent 进程，把各提供商的原生协议归一化成统一的运行时事件流，按线程落成 NDJSON。Claude CLI 的 stream-JSON、Codex 的 JSON-RPC、ACP 引擎的消息协议，到这里全是一条流。好处有三层：崩溃恢复与回放天然可行；手机伴侣、浏览器、桌面端折叠同一份状态；UI 不携带任何业务协议知识，加引擎不用动前端。

绑定 127.0.0.1 是个关键的取舍：信任边界收敛到「本机进程」，权限代理得以在 server 内部串起来，不需要云账号体系。代价是远程访问必须显式配对（扫码、Tailscale 或自备反向代理），webhook 也只能打到本机 8800 端口的专用接收器——官方状态页明确承认「无 always-on 托管中继」是当前缺口。

Driver SPI：一个文件接一家引擎

server/contracts.ts 定义的 ProviderDriver 接口刻意保持很小：decodeConfig、defaultConfig、models 加一个 create 工厂，create 返回的 ProviderInstance 携带能力描述与 snapshot、generateText、reviewPermission 等旁路方法。贡献者文档的说法是「加一家提供商 = server/drivers/ 里一个文件加一行注册」，不写代码的引擎也能经 ACP 或 OpenAI 兼容端点从配置接入。三个设计细节值得展开：

失败即降影。decodeConfig 抛错或 create 被 reject 时，实例退化为 unavailable 的影子快照而不是崩溃——「未知 driver 降级为 unavailable，从不击垮整个车队」写进了分层表。同步抛异常被接口契约直接禁止。
能力位协商。ProviderAdapter 用一组布尔能力位声明该引擎能不能挂 agents MCP、computer MCP、能不能轮中插话（steer）、能不能收结构化图片。原则是「绝不告诉 bot 它的 driver 挂不了的工具」——模型根本看不到跑不了的工具，从源头掐掉幻觉调用。
审批模式每轮重申。SendTurnInput 里 approvalMode 每轮重新下发，注释写明是「防止恢复的原生会话保留过期且更宽松的旧模式」；API 类引擎则拿到 approvalModeNow 回调，每次工具调用前读实时档位，调档即时生效、升降都算。

审批分级：把 13 类引擎的权限模式拉平成五档

Ask for approval、Auto-accept edits、Approve for me、Full access、Custom（Codex 专属，仅桌面端经私有通道进入）五档，每一档映射到引擎的原生权限模式：Claude 的 default、acceptEdits、auto、bypassPermissions，Codex 从 on-request 加 workspace-write 到 never 加 danger-full-access，Gemini CLI 的 --approval-mode 系列。OpenMausBot 不自造沙箱、不自研审查器，做的是「模式翻译 + 残余请求代答」，映射表覆盖 Codex、Claude、Cursor、Antigravity、Grok Build、OpenCode、Qwen Code、Gemini CLI、Cline、Droid、Kimi、Pi 与 API 引擎共 13 类。默认档是 Full access（沿 T3 Code 的惯例），托管的企业工作区默认 Ask。

几条细则很有信息量。机器人读自己目录（人设文件、技能、记忆、会话文件夹）任何档位都不询问，但命令按白名单解析——出现管道、重定向、第二个命令、变量、glob 就照常弹卡，访客轮次的一切读取都问。Chief of Staff 级别下放：主管经 coordinate_bots 派活时，承接线程自动套用主管的档位，只升不降，每一跳沿链追溯到最近的主管会话（实现在 server/host/delegated-level.ts），线程开头会多一行「Approve for me——由 Clive 下放」的说明，解决的是「团队主人一整天都在给各线程手动开权限」的真实痛点。问题卡片任何档位都不代答；Codex 还支持不停车异步提问。每个审批决定写入决策日志，webhook 或定时任务触发的轮次会记录「当时无人在键盘前」。

Jev 决策模型：300 毫秒选人，fail-open

房间回复人设为 Auto 时，由一个专用分类模型（缺省 TypeSafe Jev，可选 OpenRouter 上的 Decisions 模型）决定一条没有 @ 人的消息该由哪个机器人接。它不是生成式模型而是校准概率分类器：输入房间名、成员、最近聊天窗口与新消息，输出各候选概率——单人概率不低于 0.6 由其接手，「若干成员」过线则全员作答，否则回落房间 lead。每次调用约 300 毫秒、约 0.00003 美元，1.5 秒预算内没有可信回答就回落，文档的表述是「永不阻塞或延迟一轮对话」；答案校验（选项不在候选、概率非数字、选中项非最高）失败一律回落。仓库里带 53 条标注消息的回放评测，一次约 0.002 美元，用于验证 0.6 阈值在特定模型上是否成立。决策日志按月存 NDJSON（0600 权限），不含消息文本，只留 16 位状态哈希。把「多智能体路由」从提示词工程降维成一次分类调用，是这份代码库里最务实的决定。

工具桥：把 43KB 工具目录压掉七成

每轮对话默认携带 27 到 39 个自有工具的完整 schema，合计 43 到 57KB JSON，而大多数轮次只调用两三个。开启 agents tool bridge 后，轮次只列出常用的十几个工具，外加 find_tool 与 use_tool 两个元工具，体积压到 14.5 到 15.4KB，降幅 65% 到 74%；use_tool 走与直呼完全相同的校验路径，能力不变。真正值得注意的是启用条件：只在「OpenMausBot 预批准了全部自有工具、不存在按工具名的第三方决策」的引擎上开启（Claude Code 与 API 模型两类），Codex、Pi 与全部 ACP 引擎一律不桥——因为「本会话总是允许」把记住的许可挂在工具名上，桥接后一次允许会静默覆盖所有隐藏工具。post_to_room 与 send_voice_note 永不桥接，因为应用靠工具名识别「已发送」语义以防轮次中断后重发。一个省 token 的特性背后全是安全推理，这是整个仓库的典型气质。

五、应用场景

场景一：一人公司的多引擎员工舰队

痛点：独立开发者或小团队手里往往同时有 Claude、ChatGPT、xAI 多份订阅，却只能在各自的界面里分别使用，跨模型协作靠人肉复制粘贴。

做法：给每个机器人选引擎与模型——写作品牌文案的跑 Claude，做代码重构的跑 Codex，查资料的跑 Grok，可会话中途换模型；把机器人拉进同一房间并设为 Auto，未指名消息由 Jev 自动分派。想一步到位，可以从 BotMRR 市场一键导入整队模板：单个 Markdown 文件，YAML frontmatter 供机器可靠安装，正文 playbook 人也能读；连接默认关闭、定时任务默认暂停，且不携带任何凭据与会话。

最小示例：

openmausbot team apply growth-team.yaml
openmausbot run "Room Lead" "调研 https://example.com 的定价页并导出报告" --export ./out

收益：零新增订阅成本；每个动作有审批卡片兜底；headless 命令带 JSON 输出与可分支的退出码，能直接接进 CI。它还内置一个有界 MCP 控制面，Claude Desktop、Cursor 等外部客户端可以检视机器人、派活、等完成，但审批授权、删除、凭据与电脑生命周期被刻意排除在外。

边界：输出质量完全取决于上游模型，OpenMausBot 不做结果质检；重度使用会先撞上你已有订阅的额度墙。

场景二：收件箱与表单驱动的定时自动化

痛点：每日通报（早九点摘要收件箱）与事件响应（表单提交后起草回复）通常要写脚本、配密钥、租公网地址。

做法：触发器三件套。schedules 支持 5 到 1440 分钟的周期并锚定起始时间，上一次没跑完自动跳过本次，慢任务不会堆积成无限队列；webhook 走 127.0.0.1:8800 专用接收器，secret 只在创建时显示一次，推荐 bearer 认证；app events 由 Composio 把 Gmail、Slack、GitHub 事件推进中转队列，桌面端 long poll 拉取——关机也不丢事件，Gmail 每 15 分钟查一次，推送类应用即时到达，桌面每天 500 条额度、Cloud 2000 条。

示例：对机器人说「每个工作日早上 9 点给我收件箱摘要」，它在自己这一轮里调用 trigger 工具建好计划，聊天里出现带暂停、编辑、撤销的卡片；机器人自己生成的 webhook 永远看不到 secret，链接由人从卡片复制。

收益：自然语言建自动化，运行历史带日历视图，无需公网暴露。

边界：webhook 要求本机应用在线（截至 v0.1.132 无托管常驻中继）；轮询类应用有分钟级延迟。

场景三：带审批闸门的计算机操作代理

痛点：让 agent 操作真实电脑风险高，而全托管产品把每一步藏在你事后才能审计的云端。

做法：给机器人配一台 Boat 云电脑（每 bot 独立隔离、实时屏幕预览、随时可浏览器接管），或指向本机——macOS 全量支持，Ubuntu Xorg 显式 opt-in 后可用，Wayland 直接 fail-closed 禁用（追踪 issue #345）。打包的 Cua 驱动在构建期按 tag 锁定上游压缩包并校验 SHA-256 与成员白名单，装好后应用不自行更新原生自动化代码。shell 命令、文件改动、提问全部以聊天内联卡片出现：Allow once、Always allow this session 或 Deny；对自定义 MCP 读工具还有精确到「机器人 × 服务器实例 × 工具名 × 服务器配置指纹」的长期授权，改一个 URL 或凭据即失效。

收益：动作粒度的授权加全量决策日志；云电脑与本机是同一套交互，不出现两套心智。

边界：默认 Full access 是大胆的取舍——首次启动有显式同意页，README 用警告框声明引擎以 danger-full-access 运行；不要不加审查地把不可信任务交给它。

场景四：VPS 常驻与手机伴侣

痛点：桌面应用锁死在办公电脑，人一出门舰队就断线。

做法：用 npx openmausbot serve 把 harness 跑在 VPS，远程入口三选一——--tunnel 托管公网地址、--tailscale 走自有 tailnet、或 Docker 栈配自己的域名；手机装伴侣应用（iOS 与 Android）扫码配对，配对码一次性短码。浏览器也可当客户端。数据全在服务器 DATA_DIR，桌面端密钥存操作系统加密存储。

收益：全天在线的舰队加随身审批，air-gap 场景同样支持——同一个应用，没有独立的企业分支。

边界：VPS 上的机器人操作的是服务器环境，本机控制不可用；云电脑依赖 Boat 这个付费第三方；服务器模式下 API key 明文存 0600 的 config.json，官方如实标注，公网部署需自行加固。

六、快速上手

前提：Node 24 及以上，本地至少装好并登录 claude、codex、grok 之一，装了哪几个模型选择器里就出现哪几个。

桌面版（推荐，内置 harness server，无需单独起服务）：从 GitHub Releases 下载对应平台安装包。macOS 已签名公证；Windows 安装器未签名，SmartScreen 提示后选 More info 运行；Ubuntu 24.04 提供 deb 与 AppImage（beta，GNOME 为受支持桌面）。

源码运行：

git clone https://github.com/milind-soni/OpenMausBot && cd OpenMausBot
pnpm install
pnpm dev:server   # harness server → 127.0.0.1:8799
pnpm dev          # 网页版 → http://127.0.0.1:5199

npm 全局安装（可跑在终端或服务器）：

npm install -g openmausbot
openmausbot       # 首次启动引导：选 AI 接入方式、选模型、可选配对手机

可选凭据四种：Composio 项目 key（连接 500+ 应用）、Boat API key（云电脑）、ElevenLabs 或 Fish Audio key（语音）、Jev 或 OpenRouter key（房间自动路由）。全部可跳过，本地聊天不依赖任何云 key。

七、横向对比

方案	模型	跑在哪	数据在哪	许可与价格
OpenMausBot	Claude / Codex / Grok / 兼容端点，每 bot 任选	你的机器，可选云电脑	~/.openmausbot 本机	Apache 2.0，免费
Grok Bot（xAI）	仅 Grok	xAI 共享云电脑	xAI 云端	绑 SuperGrok 30 美元或 Cursor Pro 20 美元以上计划
Meta Muse	Meta 模型	Meta 云虚拟机，限美加	Meta 云端	闭源
OpenAI dots	GPT	ChatGPT 内常驻	OpenAI 云端	绑 Pro 与 Business Premium
Cue（Manus）	自有模型	云端，配手机邮箱钱包	Manus 云端	闭源，邀请制
OpenBot（CopilotKit）	任意 AG-UI agent	自托管 Docker	你的 PostgreSQL	MIT，beta，定位是可改造模板

官方对比博客坦承 Grok Bot 仍领先两点：观察你的操作学会工作流，以及合上笔记本继续干活。OpenMausBot 的回击是自托管、多模型与许可自由——截至 2026-10-30 这两点官方仍未跟进（更新日期 2026-10-02 的对比表）。

八、局限与风险

单人主导与超高速迭代。4201 次提交几乎全部来自 Milind Soni，外部贡献薄、1091 个 fork 尚未形成维护梯队；一周 8 个 release 意味着接口与行为随时变化，生产依赖要有锁版本的心理准备。
默认 Full access 的安全面。本机默认给 agent 最宽权限是产品哲学，但误信一个恶意任务或恶意 MCP server 的后果比「默认询问」的产品重；官方在 README 与审批文档里反复警告，托管工作区默认 Ask，第三方 MCP 自报的 readOnlyHint 不被当作授权——这些护栏值得肯定，也提示了风险所在。
平台能力不均。语音通话仅 macOS；Ubuntu Wayland 本机控制禁用；Windows 安装包未签名；iOS、Android 伴侣仍在完善托管连接。
云依赖可选但不免费。Boat 云电脑与 Composio 是第三方商业服务（Boat 试用后收费），Cloud Pro 订阅与 BotMRR 模板市场是商业化尝试，核心链路本地可用，但完整体验绑在第三方可用性上。
密钥管理的诚实短板。服务器与浏览器模式下 key 明文存 0600 的 config.json，仅桌面端走系统加密存储，公网自托管需要自行加固。

九、小结与行动建议

OpenMausBot 的价值不在单个技术点，而在它把 2026 年最热的产品形态「多引擎 agent 车队」做成了可自托管的开源件：driver SPI 的失败即降影、审批模式的每轮重申、Jev 路由的 fail-open、工具桥的安全启用条件，每一处都是做 agent 基础设施可以直接抄的作业。行动建议：

手里有多份模型订阅的个人用户：桌面版直接装，从一个机器人加一个引擎起步，熟悉审批卡片后再考虑放宽档位。
想做 agent 平台的工程师：精读 server/contracts.ts 与 docs/approval-levels.md，这是一份难得的「权限模式翻译层」参考实现。
运营与自动化场景：从 schedules 加 app events 起步，跑顺后再上 webhook。
安全敏感团队：关注托管工作区的 guarded messages 策略，或先用云电脑把风险隔离在本机之外。
长期观察两点：商业化（Cloud Pro、BotMRR）能否摊薄单人 bus factor，以及五家闭源厂商是否会用免费策略反压这个开源生态位。

参考资料

OpenMausBot README（GitHub，获取日期 2026-10-30）：https://github.com/milind-soni/OpenMausBot
docs/approval-levels.md——五档审批与 13 类引擎的原生模式映射（获取日期 2026-10-30）
docs/decision-model.md——Jev 决策模型的设计、日志与评测（获取日期 2026-10-30）
docs/agents-tool-bridge.md——工具桥的压缩率与安全启用条件（获取日期 2026-10-30）
官方博客「Grok Bot vs MausBot：a feature-by-feature comparison」（2026-08-23 发布，2026-10-02 更新）：https://mausbot.com/blog/grok-bot-vs-openmausbot
GitHub API 仓库元数据、releases 与 trending 页快照（截至 2026-10-30）
Show HN: Open-source AI teammates with their own computer（2026-09-17）：https://news.ycombinator.com/item?id=49743842