你在聊天窗口里对 AI 说：“整理这个项目，运行测试，再把结果发给我。”普通聊天机器人只能给建议；能执行任务的 Agent——会读取文件、调用命令、修改代码并检查结果的 AI——还需要一台可以真正动手的电脑。OpenMausBot 想把这两部分装进同一个开源产品：界面像联系人列表，每个“联系人”背后都是一个 Agent，并可使用云端 Linux 桌面、隔离的本地虚拟机，或在特定条件下操作你的电脑。
这个项目最近进入 gh-trending-typescript，但现有材料没有可核验的星标增量、下载量或第三方传播数据，因此“突然爆红”还不能当作已经证实的结论。以下功能与安全边界也都来自项目仓库，尚无独立信源交叉验证。
它把 Agent 变成了一组“同事”
据项目仓库介绍，OpenMausBot 最初名为 OpenGrokBot，灵感来自 Grok Bot 把多个机器人做成聊天联系人的设计，后来改名并强调与 xAI、Meta、OpenAI、Manus 均无关联。它把每个侧栏角色做成独立 Agent：各自拥有 personality（角色设定）、model（所用模型）、thread memory（这段对话的记忆）、computer（执行任务的计算环境）和 connected apps（连接的应用）。
这不只是换了一层聊天皮肤。你可以把“工作”“个人事务”和不同项目放进不同频道，各自保存对话、共享指令、工作目录和机器人名单。产品还允许自动挑选适合回复的 bot；判断模型关闭或拿不准时，则交给频道里的主 bot。
所谓“自带模型”，也不是把模型文件全部装进软件。仓库称，它会调用用户电脑上已有的 Claude、Codex 和 Grok CLI——CLI 是通过命令行使用服务的工具——并沿用用户已有的登录和订阅。产品主要负责界面、Agent 编排和执行环境，而不是把用户锁在一个模型里。
“自带虚拟机”并不准确
虚拟机是在真实电脑里模拟出的独立计算机，有自己的操作系统和磁盘。让 Agent 在里面工作，可以减少误操作波及宿主机，也就是你日常使用的那台真实电脑。
但 OpenMausBot 并非让每个 Agent 默认附带一台虚拟机。仓库列出三种路径：cloud Linux desktop、isolated Local VM，以及经过平台安全认证、由用户明确授权后的宿主机控制。前者在云端，后两者才涉及本地边界，不能混为一谈。
宿主机控制目前支持 macOS 和 Ubuntu Xorg。项目文档称，团队虽然验证了 Ubuntu Wayland 下的屏幕预览，却没有获得足够可靠的真实桌面输入安全证据，因此关闭了 Wayland 的宿主机控制，并清除旧版本留下的授权；相关问题仍由 issue #345 跟踪。用户可以继续聊天、查看预览，或改用隔离虚拟机。
Local-first，重点是控制权
OpenMausBot 将自己定义为 local-first：数据和主要工作副本优先保存在用户设备上，并以本地操作为核心。仓库称，一个仅绑定 127.0.0.1 的本地 harness server——负责管理 Agent 进程的小型服务——统一调度各个 Agent；对话记录、密钥和事件存放在 ~/.openmausbot。
不过，local-first 不等于完全离线，也不等于数据绝不会离开电脑。云端 Linux 桌面、模型账号和外部应用连接仍可能跨越本地边界。项目还宣称可通过 Composio 连接 500 多个应用，但实际兼容性与数据流向没有独立验证。
为什么值得关注
它抓住了一个正在成形的产品方向：Agent 不再只是回答问题，而是拥有独立身份、记忆、工具和计算环境的一组执行者。开源和 Apache 2.0 许可证让这套形态可以被查看、修改和重新组合。项目提供 macOS Apple silicon、macOS Intel、Windows x64 与 Ubuntu 24.04 x64 版本；Ubuntu 的 .deb 和 AppImage 仍标为 beta。
项目还反复声明没有官方 token，也不认可任何借用 OpenMausBot、Maus 或 SupaMaus 名称的加密货币。这既是风险提示，也侧面说明项目热度已经带来品牌冒用压力。
局限与未知
- Claude、Codex、Grok CLI 的实际兼容范围，尚缺少独立测试。
- 本地虚拟机的隔离强度、数据是否完全不出本机，以及安装包签名和公证状态，尚未得到独立验证。
- 仓库所称“2026 年七周内发布四款闭源 personal-agent 产品”没有列全对象与日期，目前无法核对。