先说结论：OpenMausBot 这个项目我盯了一段时间，原仓库 milind-soni/OpenMausBot 现在有 4770 stars，主语言 TypeScript，Apache-2.0 协议。它的中文翻译版刚放出来，仓库在 yangshun2005/OpenMausBot-cn，翻译日期标的是 2026-10-14。注意，是翻译完成，不是功能验证完成——这一点我在下面还会专门说。
我为什么觉得它值得写一篇：它解决的不是"再做一个聊天框"的问题，而是把"多个 Agent 并行干活"这件事，做成了你手机里早就熟悉的那个形态——消息列表。
它到底是个什么东西
官方一句话描述是：Open-source Grok Bot alternative with a virtual machine that bots can use。翻成人话：一个开源版的 Grok Bot 替代品，每个 bot 背后挂着一台虚拟机。
具体形态是这样的：侧边栏里每一个 bot 都是一个真实运行的 Agent，底层跑 Claude 或者 Codex，各自有独立的人格设定、独立的模型、独立的云电脑、独立连接的应用。你跟它对话，就像跟联系人发消息；它干活的时候你能看着；遇到重要操作，它会等你审批。
这个设计思路和"一个对话框里塞一个全能助手"是两条路。单个助手的问题在于上下文会被搅在一起，任务之间互相污染。OpenMausBot 的做法是把每个 Agent 拆成独立会话，各自有对话记忆。项目自己说得很清楚，它是受 Grok Bot 启发的独立项目，同时自称是 Meta Muse、OpenAI dots、Cue by Manus 的开源替代品，并且明确声明与 xAI、Meta、OpenAI、Manus 均无关联。它还有个曾用名叫 OpenGrokBot，别名 MausBot。
项目页面里有一条声明我建议你认真读：它没有任何代币，任何用 OpenMausBot、Maus、SupaMaus 名字的币都跟这个项目无关。这种声明在开源 AI 项目里越来越常见了，看到名字沾边的币，直接跳过。
装起来有多快
中文版 README 顶部加了一段"中文快速上手"，这是面向中文用户的补充导读，不是原文档内容，目的是让你不用啃完整篇 README 就能先跑起来。这个处理我觉得挺实在。
最短路径就是下载安装包：
- Mac（Apple silicon）：OpenMausBot.dmg
- Mac（Intel）：OpenMausBot-intel.dmg
- Windows：OpenMausBot-setup.exe
- Ubuntu 24.04 x64：OpenMausBot-amd64.deb，或者 AppImage 测试版
全部版本在 latest release 页面能拿到。macOS 那边是已签名并公证的 .dmg，Windows 是 x64 安装程序。
如果你习惯从源码构建，package.json 里写的是包管理器 pnpm@10.33.0，Node 要求 >=24。这里有个坑要提前说：README 材料里没有给出完整的源码构建和启动命令，你得回到 README 正文里翻。我试过按常规套路猜命令，猜不出来，别浪费时间。
Docker 那条路是给 harness server 用的，Dockerfile 注释里给了三条命令：
docker build -t openmausbot . docker build --build-arg ENGINES="@anthropic-ai/claude-code @openai/codex" -t openmausbot . docker build --target cloud-home -t omb-cloud-home .第二条可以指定引擎，这个设计挺灵活。Docker 镜像基于 node:24-bookworm-slim。
真正的门槛不在安装，在依赖
这是我最想提醒的一点：OpenMausBot 的 bot 不是跑在它自己的沙箱模型里，而是跑在你本机已经装好的 claude、codex、grok CLI 上，用的是你已有的登录和订阅。
这意味着两件事。
一是它不需要你注册新账号，也不用额外买 API 额度，你现有的订阅直接复用。对已经在用 Claude Code 或者 Codex 的人来说，边际成本接近零。
二是如果你机器上没装这些 CLI，或者登录状态有问题，OpenMausBot 就是个空壳。我见过太多人卡在这一步，装完应用打开发现 bot 不动，回头才发现是 CLI 没配好。所以顺序应该是：先把 claude 或 codex 在终端里跑通，确认能正常对话，再去装 OpenMausBot。
平台限制和几个容易踩的坑
主机控制（host control）这个功能不是全平台都能用。它只在 macOS 和 Ubuntu Xorg 上可用，而且必须显式 opt-in 才会开启。Ubuntu Wayland 那边因为 issue #345 还没解决，主机控制处于禁用状态。如果你是在 Wayland 桌面环境下用 Ubuntu，这块功能暂时别指望。
数据存放位置记一下：transcripts、keys、events 都在 ~/.openmausbot 下面。Docker 环境里 HOME 是 /data 卷，用来做跨容器重启的持久化。要备份或者迁移，认准这个目录。
网络这块，README 材料里没提国内镜像源或者加速方案。如果你在国内构建源码或者拉 Docker 镜像遇到慢的问题，得自己想办法换源，原文没给现成答案。
中文版到底值不值
原项目 README 是英文的，对一个涉及 Electron、Docker、多个 agent CLI 的项目来说，英文文档的阅读成本不低。中文版做了两件事：一是把 README 正文完整翻译过来，二是额外加了一段中文快速上手导读，把"这是什么、解决什么问题、最短安装路径、环境要求、常见坑"这几块单独拎出来。
对刚接触这个项目的人来说，第二件事的价值可能比第一件还大。因为原 README 是那种典型的开源项目写法，信息密度高但顺序不一定适合新手——你得先知道它是什么、装哪个包、依赖什么，再去读架构细节。
不过我要说清楚：这个中文版是翻译完成，不是 QA 验证通过。README 里也写了"如有翻译不准确之处，欢迎提 Issue 或 PR"。所以遇到命令、路径、参数这类关键信息，建议对照一下 README_en.md 原文，别完全依赖翻译。
我的选型判断
如果你在做企业侧的 AI 落地评估，我建议先问三个问题，再决定要不要引入这类工具。
第一，你现有的 agent CLI 生态是什么。OpenMausBot 复用的是 claude、codex、grok 这些 CLI 的登录和订阅，如果你团队本来就在用 Claude Code，接入成本很低；如果你们走的是自建推理服务或者别的框架，那它未必是合适的那一层。
第二，你需要的是"一个助手"还是"一队助手"。单助手场景下，多 bot 的消息列表形态反而是负担，多出来的配置和心智成本不划算。只有当任务确实需要并行、需要隔离上下文、需要不同人格或不同模型分工时，这个形态才成立。
第三，主机控制的合规边界。host control 能操作你的机器，这在个人场景是效率，在企业场景是需要评估的权限面。它默认不开启、需要显式 opt-in，这个设计是对的，但你在推给团队之前，得先想清楚谁能开、开了之后审计怎么做。
落地顺序上，我的建议是：先在一台个人机器上跑通安装和 CLI 依赖，确认 bot 能正常干活；再试 Docker 那条路，验证 harness server 的构建流程；最后才考虑要不要接进团队流程。别一上来就搞集成，这个项目的依赖链条比看起来长。
最后
OpenMausBot 有意思的地方在于它押了一个判断：Agent 的最终形态不是对话框，是消息应用。这个判断对不对，现在下结论还太早，我自己的样本也不多。但作为一个 4770 stars、TypeScript 写的、本地优先的开源项目，它至少把这条路走通了一遍，而且中文版把阅读门槛降下来了。
想动手的话，先确认本机 claude 或 codex 能跑，再去下安装包。这一步过了，后面基本就顺了。
