返回博客列表

OpenMausBot 拆解：开源版 Grok Bot 怎么把一队 agent 装进聊天 app

2026-10-30T15:00:00+08:00
开源项目AI AgentClaude CodeElectronGrok Bot

milind-soni/OpenMausBot，TypeScript 写的 Apache-2.0 项目，2026 年 8 月 11 日建仓，两个半月涨到 7968 stars、1151 forks，今天还在高频推送。它的自我定位是开源版 Grok Bot：一个 Telegram 风格的聊天桌面 app，侧边栏里每个联系人都是一个真 agent，背后是你自己机器上已经登录的 claude、codex、grok CLI，各自有独立的模型、记忆、云电脑和连接的应用。

一句话判断：如果你已经为 Claude Code 或 Codex 付了费，又想要多 agent 分工、审批卡和可视化的云桌面，又不打算把数据交给一家闭源 agent 公司，这个项目值得装一遍。但它还在 0.1.x（当前 0.1.134），573 个 open issues，单人主导，离“稳定日用”还有距离。

如果你已经被 Grok Bot、Muse、dots 这波“agent 团队”产品刷过屏，这篇拆的是开源阵营的答卷。

本文提纲

  • 它是什么：先排除三个误解
  • 怎么跑起来：三种安装方式与前提条件
  • 日常怎么用：bot、channel、审批卡、触发器与语音
  • 双进程架构：一个零传输的 UI 加一个驱动注册表
  • 核心机制：统一任务运行时与十条不变量
  • 权限模型：四级 level、继承规则与防注入信封
  • 记忆和数据：local-first 到底 local 在哪
  • 三个真正的创新点
  • 横向比较：五个闭源产品和终端基线
  • 成本、风险与失效边界

它是什么：先排除三个误解

第一个误解：它是一个新模型或新 agent SDK。不是。OpenMausBot 自己不含任何模型，agent 能力全部来自本机安装的三个 CLI 之一：claude（Claude Code）、codex（OpenAI Codex CLI）、grok（xAI CLI）。驱动目录里还能看到 openai-chat、openai-compat、antigravity、muse-code、cerebras、groq、mistral、minimax、openrouter 等引擎适配，但主线是前三个 CLI。你用的是自己已有的登录态和订阅，中间没有代理服务器。

第二个误解：它是个聊天机器人套壳。不是。每个 bot 都能操作一台电脑：Boat 提供的云端 Linux 桌面（赞助商的付费服务）、本地隔离 VM，或者在通过安全认证的平台上直接控制你自己的机器（macOS 和 Ubuntu Xorg 需显式开启）。此外通过 Composio 接 500 多个应用，Gmail、Slack、GitHub、Notion 走 OAuth 授权。

第三个误解：它和 xAI 有关系。没有。README 顶部专门声明这是受 Grok Bot 启发的独立项目，与 xAI、Meta、OpenAI、Manus 均无关联；项目曾用名 OpenGrokBot，别名 MausBot。声明里还有一条防诈骗提示：本项目没有任何加密货币代币，任何用 Maus 或 SupaMaus 名义发的币都与维护者无关。一个 8 月才建仓的项目需要专门防冒名发币，也算这个时代的特色。

它的产品形态可以这样概括：把“一个助手一个对话框”改成“一个 agent 团队一个聊天 app”。你可以建多个 bot，像管联系人一样置顶、归档、复制；可以开 channel（工作、个人、按项目分），每个 channel 有独立的对话记录、共享指令、工作目录和 bot 名单；还有 Chief of Staff 角色负责把任务拆给其他 bot，bot 之间可以互相派活。

怎么跑起来：三种安装方式

最简单的是直接下安装包，macOS（Apple silicon 和 Intel）提供签名公证过的 .dmg，Windows 有 x64 安装程序，Ubuntu 24.04 有 .deb 和 beta 状态的 AppImage。安装包里内嵌了 harness server，不用单独起服务。

Windows 有个已知的坑：安装程序还没有代码签名，SmartScreen 会报“未知发布者”，要手动点“更多信息 → 仍要运行”。Linux 只保证 GNOME 桌面，Wayland 会话下 bot 控制本机的功能直接关闭（后面安全那节展开）。

从源码跑的方式：

git clone https://github.com/milind-soni/OpenMausBot && cd OpenMausBot
pnpm install

pnpm dev:server    # harness server → 127.0.0.1:8799
pnpm dev           # 聊天 app → http://127.0.0.1:5199
pnpm dev:desktop   # Electron 外壳，上面两个要保持运行

前提条件写得很明确：macOS、Windows 或 Ubuntu 24.04 x64，Node 24+，pnpm，以及至少一个已登录的 agent CLI。CLI 装好登录后会自动出现在模型选择器里，不用手动配 key。也可以在 Settings → Engines 里把引擎指向自定义 CLI 二进制，比如某个固定版本或你自己的 wrapper。

第三种方式是无界面的 headless CLI，给脚本和 CI 用。装 openmausbot npm 包后可以这样驱动一个正在运行的工作区：

openmausbot team apply team.yaml
openmausbot run "Room Lead" "Rehearse the launch of https://example.com" --export ./out

输出一个 JSON 文档，退出码可以直接在脚本里分支判断。这意味着它不只给人用，也可以把整个 agent 团队塞进流水线。

日常怎么用

装上之后，核心交互是四样东西。

bot 与 channel。右键 bot 可以编辑资料、复制、置顶、隐藏，和聊天软件管联系人一样。真正有用的是 channel：每个项目一个 channel，独立对话记录和工作目录，bot 名单可以随时调整，不用为每个项目克隆一遍 agent。

审批卡（approval card）。bot 要执行 shell 命令、改文件、或者有问题要问时，聊天流里会弹出内联卡片，Allow / Deny 或直接在对话里回答。云端电脑和本地电脑都经过同一个 permission broker，风险动作不会静默发生。不过要注意它的默认策略：每个 bot 和对话默认是 Full access，理由是“T3 Code 默认也这样”，托管的企业工作区才默认 Ask。这个取舍后面细说。

触发器（trigger）。直接用自然语言对 bot 说“每个工作日早上 9 点给我发收件箱摘要”或“表单 webhook 来了就起草回复”，bot 会用自己的 trigger 工具当场建好，聊天里出现一张可编辑、暂停、撤销的卡片，不需要二次确认。调度和 webhook 统一在侧栏的 Triggers 页管理。有个安全细节：bot 创建的 webhook 永远看不到自己的 secret，链接只能由人从卡片或 Triggers 页复制。

团队包（team file）。这是生态玩法：在 BotMRR（botmrr.io）上浏览按场景打包好的团队，点 Add to OpenMausBot，app 弹一个审核页，确认后一次性创建 bots、Chief of Staff、channels、playbooks、连接器清单和例行任务。包格式是一个 Markdown 文件加 YAML frontmatter：OpenMausBot 读结构化 frontmatter 完成安装，而 Grok、Claude、ChatGPT 和人可以直接读 Markdown 部分的 playbook。包里不带凭证、对话记录、权限、记忆和电脑访问，连接默认关闭，例行任务默认暂停。规范在 openmausbot-teams 的 FORMAT.md，也可以从本地文件或公开 GitHub URL 导入。

此外还有语音：可以让 bot 朗读回复，或者直接 call 过去，它会边干活边汇报、口头请求审批。TTS 支持 ElevenLabs、Fish Audio、xAI Grok、macOS 本地语音和自建 Chatterbox 服务器五种后端。

双进程架构：零传输的 UI

README 里“How it works”一节把架构讲得很干净：整个系统只有两个进程。

flowchart LR
    UI["Chat app
React 19 + Vite + Tailwind
127.0.0.1:5199"]
    REG["Driver registry
+ fan-in event bus"]
    BROKER["Permission broker"]
    CL["claude CLI"]
    CX["codex CLI"]
    GR["grok CLI"]
    BOAT[("Cloud computer
Boat / Local VM / host")]
    APPS[("Composio apps
Gmail Slack GitHub")]

    UI -->|"HTTP commands"| REG
    REG -->|"one SSE stream"| UI
    REG --> CL
    REG --> CX
    REG --> GR
    CL -->|"permission requests"| BROKER
    CX -->|"permission requests"| BROKER
    GR -->|"permission requests"| BROKER
    BROKER -->|"approval cards"| UI
    REG -->|"Boat API"| BOAT
    REG -->|"Composio Session"| APPS

    classDef red fill:#FF6B6B,color:#000000
    classDef teal fill:#4ECDC4,color:#000000
    classDef blue fill:#45B7D1,color:#000000
    classDef sage fill:#96CEB4,color:#000000
    classDef yellow fill:#FFEAA7,color:#000000
    classDef plum fill:#DDA0DD,color:#000000
    class UI red
    class REG,BROKER teal
    class CL,CX,GR blue
    class BOAT sage
    class APPS yellow
    linkStyle default stroke:#764ba2,stroke-width:2px

聊天 app 自己不持有任何传输层。它只做两件事：用 HTTP 发命令，把一条 SSE 事件流 fold 进本地状态。README 的原话是“zero client-side transports”，状态管理是 server-backed store 加单个 reducer。这个选择让 app 可以很薄：Electron 外壳、浏览器、配对的手机都只是同一个 server 的客户端，桌面之间还能通过 Tailscale 互联（companion 模式）。

harness server 绑在 127.0.0.1:8799，拥有所有 agent 进程，代码分几块：

层 位置 职责
Drivers server/drivers/ 每个 provider 一个驱动，把各家 CLI 的原生协议（stream-JSON、JSON-RPC、ACP）归一化成一条标准运行时事件流；未知驱动降级为 unavailable，不拖垮整个 fleet
Harness server/harness/ 注册表（配置 → 活实例）和 fan-in 事件总线，每线程记录为 NDJSON
API server/index.ts bots、turns、审批、模型目录、电脑生命周期、连接器、配置，HTTP + SSE
Voice server/tts/ 五种 TTS 后端，云端 key 留在 harness，markdown 先改写成适合朗读的文本
App src/ 聊天外壳
Desktop electron/ 三平台外壳，内嵌 harness；Apple 语音识别仅限 macOS

驱动这层是“BYO agent”能成立的关键。三个 CLI 的协议完全不同：Claude Code 是 stream-JSON，Codex 走 JSON-RPC，Grok 走 ACP。每个驱动要处理的远不止转发：登录态探测（claude-login-auth、codex-device-auth）、版本更新、配额与限流（claude-limits、limit-failover）、后台进程保活（claude-background）、原生权限模式的能力差异。看 server/drivers/ 的文件列表就能感受到工程量：光是 claude 相关就有 catalog、billing、keepwarm、project-mcp、tool-search 等十几个模块。

核心机制：统一任务运行时

这是整个仓库里技术含量最高的部分，文档在 docs/runtime-contract.md，实现在 server/runtime/。

要解决的问题是这样的：人可以直接对 bot 说话，bot 可以把活派给另一个 bot，定时任务、webhook、群聊 goal run、外部 API 调用都能产生工作。早期版本里这些路径长出了两套委派系统、六条唤醒通道、十几个时钟和十种信任措辞（room-handoffs、delegations、aside lane、card-resume maps、Continue: tasks），全是补丁。runtime-contract 把它们收敛成一句话：一条记录、一个生命周期、一条唤醒通道，模块之外谁也不许自己持有工作状态。

核心数据结构是 Assignment，构成一棵树：

  • rootId、parentId、depth 描述委派关系，每次对话、每次 routine 运行都是一个根节点
  • origin 标记工作起点：person、routine 或 outside（webhook、relay、guest、peer、api），在根节点写一次，向下复制，永不改变
  • mode 区分三种动作：work（真干活）、consult（只回答不动手）、notify（单向通知）
  • reply 决定完成后怎么唤醒请求方：resume、poll 或 none

存储用的是 Node 24 内置的 SQLite（node:sqlite），DATA_DIR/runtime.db 里三张表：assignments 一行一条记录，assignment_events 只追加的审计日志，inbox 是唤醒队列。每个状态变更都是一个事务：先写行和事件，再执行动作，所以崩溃最多丢“尚未确认的接收”，不会丢已确认的工作。

生命周期状态机是 queued → running → completed | failed | cancelled，派了活就进 waiting，要向人提问就进 needs_input。这里有两个设计特别值得说。

重启策略保证对外动作最多执行一次。 app 重启后，被打断的 turn 默认重跑一次；但如果这个 turn 已经执行过对外动作（发邮件、发帖、git push、付款），runtime 通过 host 实现的可选端口 outward(a) 从线程自己的活动记录里读到动作标签（不是从模型文本里猜），就直接标记失败而不是重跑，防止“重启后邮件发了两遍”。正在等子 bot 的节点则转成 waiting，绝不重复执行。

预算和时钟各只有三个。 每个根任务有 requests、executions、wakes 三个预算，只在“持久化进展”后刷新；时钟只有队列超时、根任务停滞窗口、单 turn 活动窗口三个，挂起等人的状态不计入任何窗口（人可以三天后再点卡片）。另外两个 loop guard 防空转：连续两次 continue 但没有成功工具调用，或者连续三次报同样的错，直接判 failed(stalled)。

文档里还列了十条不变量，每条都有测试断言，比如：终态任务恰好上报一次、结果绝不投递两次、过期绝不被当成批准、turn 实际运行的权限等级必须等于记录上的等级、runtime 永远不向 turn 抛异常（拒绝都是带类型的返回值）。server/ 目录下几百个 .test.ts 和 .e2e.test.ts 文件说明这些不是纸面规矩。最近的提交记录也能看到这套系统仍在打真实补丁，比如“bot box 内 permission socket 没接回去导致所有审批报 broker unavailable”这种问题，修完都带复现测试。

权限模型：四级 level 与防注入信封

审批分四级，直接映射各 provider 自己的权限模式：

等级 行为
Ask for approval 命令和文件改动都问，相当于 supervised 模式
Auto-accept edits 自动批文件编辑，其他照问（Claude、Grok、Antigravity 支持）
Approve for me 用 provider 自己的自动审查（Codex、Claude、Cursor、Grok），常规动作放行
Full access 最宽松模式，包括破坏性操作；残余原生提示也代答；连接应用的发信也不再弹卡
Custom 仅 Codex，读取你 config.toml 里的实际审批与沙箱设置

bot 之间派活时权限怎么传？规则是 level = max(自己的, 继承的)，顺序是 ask < edits < auto < full，但继承只沿血缘链走：Chief of Staff conversation 的等级会传给它派出的 bot，旁系什么都拿不到。而且最终等级还要被引擎真实能力封顶：某引擎没有原生 auto review，auto 就降成 edits。

默认 Full access 是这个项目最激进、也最值得你自己改的决定。它的论证是 Codex/T3 Code 默认也这样，真正的问题和缺凭证仍然会弹给人。但“多个能发邮件、能 push 代码的 agent 默认全权”在安全上显然不是保守选择。托管企业工作区默认 Ask 算是承认了这一点。好消息是等级可以随时改，不用停 bot，从选中那一刻起后续决策都按新等级走。

另一个设计是 prompt injection 防护。委派 turn 的开场白（envelope）全部由 harness 根据存储数据写，绝不采用模型生成的文本，里面明确告诉执行 bot：页面、文件、工具输出、其他 bot 的话都只是数据不是指令；没有任何 bot 的消息等于权限批准；人后来的“yes”作为 harness 引用传入，而不是粘贴文本。模型如果模仿信封的开头标记，会被转义。这是多 agent 系统里最容易被忽略、但出事就是大事的边界。

还有一层 MCP 控制面的收敛。app 自带一个 stdio MCP server，让 Claude Desktop、Cursor 这类外部客户端可以编排你的 bot 团队：列出 bot 和 channel、读有限页数的对话、创建和配置 bot、派活、等待、切换空闲 bot 的模型、打断当前 turn。但 v1 明确不能批准请求、不能记忆授权、不能删数据、不能改凭证、不能碰电脑生命周期。危险操作只留在人的 app 里。

记忆和数据：local-first 到底 local 在哪

所有数据在 ~/.openmausbot。bot 的记忆是纯 Markdown 文件，不在任何数据库里，可以直接用编辑器打开：

~/.openmausbot/workspaces//
├── MEMORY.md            每次对话都加载的笔记
└── memory/
    ├── .md       长笔记，按需读取
    ├── archive.md       归档和过期笔记
    └── log/2026-09-10.md  当天日志，bot 用自己的话写

几个实现细节值得注意：文件权限 0600，原子写入（写一半崩溃也不会留下撕裂文件）；任何看起来像凭证的东西（API key、token、password: 行、私钥块）落盘前替换成 «redacted N chars»，bot 读了你的 .env 然后“热心记住”这条路被堵死；bot 读自己的记忆文件夹在任何等级下都不弹审批，但命令里只要多一个管道、重定向或分号就照常要批准。

对话记录走 SQLite（messages.db），全文搜索用独立 worker。密钥是只写的：UI 永远只显示“已配置”标记，不回显。

需要诚实指出 local-first 的边界：云电脑是 Boat 的（赞助商服务，试用后收费），Gmail 这些连接走 Composio 的云，TTS 用 ElevenLabs 或 Fish Audio 时音频要出本机。代码和数据在你手里，但“手”有多长取决于你开了哪些集成。

本机控制的安全边界也值得一看。Linux 打包时只下载 tag 固定的 Cua Driver 0.19.3 上游归档，校验大小、SHA-256、成员白名单和内部可执行文件哈希，装好的 app 永远不自更新原生自动化代码。Wayland 下直接 fail-closed：不启动驱动、清除历史 opt-in，等 issue #345 的“真座位安全门”解决。这种“不确定就不开”的处理，比强行支持然后出事故强。

三个真正的创新点

第一，把聊天 app 作为 agent harness 的交互范式跑通了工程闭环。 Grok Bot 先提出了这个形态，但闭源。OpenMausBot 把它拆成可复制的架构：薄客户端 + 本地 harness + CLI 驱动 + 统一 SSE 流。bot 即联系人、channel 即上下文、Chief 即编排器，配套的运行时契约（任务树、重启不重发对外动作、十条不变量）才是真正难的部分，UI 皮反而最容易抄。

第二，BYO CLI 而不是 BYO API key。 多数“多模型 agent”产品让你填各家 API key，按 token 收费、请求经过它的服务器。OpenMausBot 直接驱动你已登录的官方 CLI，订阅还是你原来的订阅，协议差异由驱动吸收。代价是它被 CLI 的行为绑死：CLI 改协议它就得跟（仓库里 codex-unsupported-calls、claude-tool-search 这类文件就是跟进成本的证据），而且非桌面服务器场景没那么顺。

第三，几厘钱的分诊模型。 room 设成 Auto 后，没人被点名的消息交给一个专用决策模型判断该谁回：默认用 TypeSafe 的 Jev 分类器（校准过概率，0.6 阈值实测得出），也可以走 OpenRouter 的 Decisions API，几百毫秒、几分之一美分一次；拿不准或超过 1.5 秒就回退给 room lead。它绝不替你干活，只决定谁干活。用便宜小模型做路由、贵模型做执行，这个分层比“所有消息都丢给 Opus”省钱得多。

可移植团队包算半个创新：一个 Markdown 文件装好整个部门，人和各家 AI 都能读，凭证和权限一律不带。它解决的是 agent 配置的“可分享”问题，但格式能不能成为事实标准，取决于有没有别的客户端愿意读，目前还只是这一个项目的生态。

横向比较

README 直接列了五个对标产品，我把它们和“自己开终端跑 CLI”的基线放一起：

方案 模型 电脑 数据位置 门槛
OpenMausBot 你已有的 claude / codex / grok CLI，每个 bot 可换 Boat 云机 / 本地 VM / 本机 ~/.openmausbot，本地 免费开源，云电脑另付费
Grok Bot（xAI） 只有 Grok 一台共享云电脑 xAI 侧 SuperGrok 或 Cursor 套餐
Meta Muse Meta 系模型 Meta 云 VM Meta 侧 美国、加拿大可用
OpenAI dots 只有 GPT ChatGPT 内 OpenAI 侧 Pro / Business Premium
Cue（Manus） Manus 系 自带手机号、邮箱、钱包 Manus 侧 邀请制
Instinct（Spear Street） 闭源 云电脑代管密码 厂商侧 邀请制
终端里的 Claude Code / Codex 任选 你的机器 你手里 已有订阅即可

这张表能看出 OpenMausBot 放弃了什么、换来了什么。

相比五个闭源产品，它换来模型自由（每个 bot 独立选模型，对话中途可换）、数据本地、可审计、无邀请制；放弃的是开箱即用的云手机/钱包（Cue 的核心卖点）、厂商兜底的账号安全，以及“不用懂工程”的体验。Muse 和 dots 的用户根本不需要知道 CLI 是什么。

相比终端基线，它换来多 bot 编排、可视化云桌面、审批卡、定时触发、团队包和 MCP 控制面；放弃的是极简。如果你所有工作都是一个 Claude Code session 加几个 skill 能搞定的，这个 app 是纯负担，多一层 Electron、多一个 8799 端口的 server，还要养 CLI 兼容性。它的甜区是“你确实需要多个专职 agent 并行、还要定期跑、还要人审批关键动作”的场景。

和 LibreChat、OpenWebUI 这类开源聊天前端也有本质区别：那些是多模型聊天 UI，agent 的“手”是外挂；OpenMausBot 的手（云机、VM、本机控制、500 个连接应用）才是主角，聊天只是观看和批准的界面。

成本、风险与失效边界

钱的账要算清。app 免费、Apache-2.0，但三样东西持续产生费用：你自己的 Claude/Codex/Grok 订阅（agent 并行越多烧得越快）、Boat 云电脑（试用后付费）、Composio 的第三方应用额度。语音走 ElevenLabs 或 Fish Audio 另有 key。决策模型每次路由几分之一美分，便宜但不是零。

项目成熟度是最大风险。8 月 11 日建仓到现在两个半月，版本号 0.1.134，发布速度惊人也说明 API 和行为还在动；573 个 open issues；核心维护者基本是 Milind Soni 一个人（提交里大量 Co-authored-by Claude Opus 5.5，算是重度 dogfooding，但 bus factor 仍然是 1）。云电脑能力依赖赞助商 Boat，赞助商策略变化会直接影响这个功能。Windows 未签名、Linux beta、Wayland 不可用，平台覆盖不均衡。

还有几类场景它帮不了你。没有 CLI 订阅的人用不了主线能力，它不是免费模型入口；企业级 SSO、审计、合规这类需求虽然仓库里有 enterprise 和 Team Cloud 目录，但成熟度要自己验；bot 的判断仍然是模型判断，审批卡防的是“静默执行”，防不了“模型说服你点 Allow”，Full access 默认开着的时候连这层都没有，建议新建 bot 先设 Ask 跑几天再放权。

我的建议路径：先下 .dmg 当单用户工具用，只接一个 CLI、不开本机控制，对着一个真实项目跑一周，观察审批流和记忆文件的实际内容；确认顺手后再开 channel 和 Chief of Staff 做多 bot；云电脑和 Full access 最后开。它值不值得长期投入，主要看你对“数据必须在本机”这件事有多在意，以及能不能接受 0.1.x 的节奏。

参考文档与链接

你会给一队能发邮件、能 push 代码的 agent 默认开 Full access 吗？评论区聊聊你的权限策略。

作者: itech001 来源: 公众号：AI人工智能时代(the-ai-era) 网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

本文首发于 AI 人工智能时代，转载请注明出处。

分享给朋友
上一篇 · 2026-10-30
claude-seo 拆解：26 个 Skill、19 个 Agent 怎么拼成一次审计

相关阅读

claude-seo 拆解：26 个 Skill、19 个 Agent 怎么拼成一次审计

2026-10-30 Claude CodeSEOGEO

yetone/magpie：一个本地网关，让所有 Agent 随便挑模型

2026-10-28 MagpieAI AgentLLM 网关

25 万 Star 的 REA：看上哪个功能，让 AI Agent 直接逆向过来

2026-10-15 REA逆向工程MCP

Cumora.ai：AI Agent 不是聊天框，是能主动找你说话的同事

2026-08-31 CumoraAI Agent多智能体协作