OpenMausBot：把一屋子 AI 同事装进聊天软件

设想这样一个场景。你打开一个聊天 App，侧边栏里躺着七八个联系人，每一个都有名字、有头像、有脾气。你跟其中一个说"帮我把这份季度数据整理成周报"，它回你一段话，然后你看见屏幕角落里它在动鼠标、敲键盘、切窗口——它在真的干活。这不是科幻，这是 OpenMausBot 每天在做的事：它把 AI Agent 包装成聊天软件里的联系人，只不过每一个联系人背后都是一个真实的、跑在你本机上的 Claude Code 或 Codex。

图：OpenMausBot 主界面，每个会话都是一个真实运行的 AI Agent

它在补哪块拼图

项目的 README 第一句就把话说得很直白：一个盒子一个助手，是 Agent 的错误形状。2026 年七周之内，四个闭源的个人 Agent 产品相继落地——Grok Bot、Meta Muse、OpenAI dots、Manus 的 Cue——共同点是模型、算力和你的数据全都留在厂商那边。OpenMausBot 明确对标这条产品线，做的却是同一形状的开源本地版：Apache 2.0，模型用你已有的，机器用你已有的，数据留在你自己的磁盘上。

三个设计决定撑起了整个产品。一是自带 Agent（bring your own agents）：机器人直接跑你本机已装好并登录的 claude、codex、grok CLI，复用你现有的账号和订阅，中间不架代理，也不需要注册新账号；还能在 Settings → Engines 里把任意引擎指向自定义 CLI 二进制。二是本地优先：一个小巧的 harness 服务器跑在 127.0.0.1 上，统一持有所有 Agent 进程，transcript、密钥、事件都写在 ~/.openmausbot。三是给 Agent 装上手脚：每个机器人可以使用云端 Linux 桌面、隔离的本地虚拟机，或在平台安全边界已认证的前提下操作你自己的电脑，还能通过 Composio 接入 500 多个应用。

分层架构与多协议驱动

架构分四层，README 里用一张表讲得很清楚。Drivers 层（server/drivers/）每家一个驱动：Claude、Codex、Grok Build 各自通过本地 CLI 的 stream-JSON / JSON-RPC / ACP 协议接入，外加一个云电脑 Agent；这里有个细节值得夸——未知驱动会降级为 unavailable 而不是让整个机器人队列崩溃。Harness 层（server/harness/）负责注册表与事件总线，所有客户端从这一条 SSE 流上折叠状态。API 层（server/index.ts）用 HTTP + SSE 暴露机器人、轮次、审批、模型目录、虚拟机生命周期、连接器与配置。App 层（src/）是聊天外壳，服务端状态存储 + 单一 reducer，客户端零传输逻辑。Desktop 层（electron/）是 macOS/Windows/Ubuntu 外壳，嵌入 harness 并封装平台能力。

语音层（server/tts/）支持 ElevenLabs、Fish Audio、Grok (xAI)、macOS 内置语音与本地 Chatterbox，密钥只留在 harness 上。它还会把 Markdown 改写成"值得听"的口播稿再播——这个细节说明团队认真对待了语音输出这个体验层。

面向自动化的一等公民接口

多数 Agent 产品只做 GUI，但 OpenMausBot 额外提供了两条无人值守通道。MCP 服务（stdio）供 Claude Desktop、Cursor 等外部客户端编排：可以查看机器人和频道、检索 transcript 页面、创建配置机器人与任务、派活、等待完成、切换模型、打断轮次。但权限边界被刻意收紧——不暴露审批授权、删除、任意设置、凭据和虚拟机生命周期。Headless CLI 则是给脚本和 CI 用的：openmausbot team apply team.yaml 从文件建团队，openmausbot run "Room Lead" "排练一下发布流程" --export ./out 派一个活并等它和它拉起的所有同事都干完，把产出导出出来，全程 --json 输出，退出码可供脚本分支判断。

工程实现

这是一个体量相当大的 TypeScript monorepo：package.json 里 engines 要求 Node >=24，包管理器锁 pnpm 10.33，代码规范用 oxlint（deny-warnings），构建是 tsc -b 加 Vite，测试是 Vitest 加 Node 原生 test runner 串联四套。

容器化做得很完整。根目录 Dockerfile 是多阶段构建，运行时层承载 Chrome 库与 agent-browser 及其 Chrome，每个镜像按需加入引擎 CLI，代码变更只重建小的应用层以优化拉取体积；compose.yaml 定义 omb 服务（init 进程回收、shm_size 512m、healthcheck 探 /api/health）与 Caddy 反代（同一网络命名空间终止 TLS），还提供 deploy/docker-compose.yml、fly 与 podman 三套变体。关键安全设计是 harness 服务器在容器内始终绑定 127.0.0.1——回环信任就是这个系统的认证模型，TLS 与认证交给边缘的 Caddy。

测试密度是这仓库的亮点：server/ 与 electron/ 下大量 .test.ts 与 .node-test.mjs 与被测模块同目录内联，含 e2e 用例，还有独立的 evals 套件（golden 基线、live 实测、scenarios、scorers、skill-bench）与多组性能基准脚本（observation、persistence、browser-stream）。

上手门槛

最省事的路径是下载官方构建：macOS 有 Apple Silicon 与 Intel 两个已签名公证的 DMG，Windows 有 per-user 一键安装器，Ubuntu 24.04 有 deb 与 AppImage（GNOME 为受支持桌面）。桌面版内嵌 harness，不需要单独起服务器。

源码运行需要 Node 24+、pnpm 与至少一个已登录的 agent CLI，pnpm dev:server 起 harness 到 127.0.0.1:8799，pnpm dev 起前端到 5199，pnpm dev:desktop 起 Electron 外壳（需保持前两个在跑）。

能力矩阵必须仔细读：机器人控制本机屏幕这项能力，macOS 是 Supported，Ubuntu Xorg 是 Beta 且需显式 opt-in，Wayland 直接禁用（fail-closed，等 issue #345 解决）。Windows 安装包未签名，SmartScreen 会拦，需要手动"更多信息 → 仍要运行"。

争议与局限

最核心的争议是：把 AI Agent 变成聊天联系人这个交互形态，本身就在降低用户对"它在做什么"的感知成本。聊天界面天然让人放松警惕，而背后可能是一台拥有桌面控制权的 Agent 真正在点击、输入、执行。项目对此的回应是把审批做成一等公民（你可以批准重要操作），以及用能力门禁在平台层 fail-closed，但这需要用户真的去理解并配置这些开关。

工程债也很明显：610 个 open issue 配上 0.1.x 的版本号，说明这是一个功能跑在前面、问题堆在后面的高强度项目；仓库体量近 365MB，代码规模很大，学习成本高；Linux 支持整体还在 Beta 档，Windows 打包未签名。

另外要注意它的生态依赖：模型能力完全来自你本机的 CLI 订阅，Composio 应用连接器引入了第三方 OAuth 授权面——500 多个应用一次接入，权限审计的工作量在 OpenMausBot 之外。

行业意义

OpenMausBot 的意义不在于技术新颖——它没造模型、没造框架——而在于它把一个刚刚被四家大厂验证的产品形状（Agent 群聊）以完整开源的形式交到了社区手里，并且坚持了本地优先这条技术路线。它证明"多 Agent 协作界面"不需要云端沙箱也能成立，而更重要的附带产物是它那套 MCP 控制面与 headless CLI 定义了"Agent 团队如何被外部系统编排"的一种相当成熟的答案。

9.5K star、1.3K fork、160 位贡献者的规模，在一个 Electron 应用里并不常见，说明社区对"自己的 Agent、自己的机器、自己的数据"这个诉求的强度。