OpenMausBot：在聊天界面调度本地编码代理

OpenMausBot 想把 AI 编程助手做成通讯录：每个联系人背后都是一个能调用工具、操作电脑的 Agent，你可以给它选模型、分配工作目录，再在聊天里查看进度和批准操作。它的价值主张是，把已有的 Claude、Codex 等工具组织成一套可管理的工作环境。

这份项目说明值得看的，是它怎样处理多 Agent 的上下文、权限和自动化边界。不过，功能清单不能直接证明效率提升，原文也没有提供任务成功率或成本对照。读它，更适合找产品与工程设计上的可取之处。

多个 Bot 的价值，要靠上下文隔离兑现

OpenMausBot 也叫 MausBot，前身是 OpenGrokBot，以 Apache 2.0 开源。作者把它定位为 Grok Bot、Meta Muse、OpenAI dots 和 Cue by Manus 的开源替代方案，并声明与相关公司无关联。这里的「替代」是产品形态上的定位，原文没有给出功能逐项对照或效果测试。

它直接调用本机已经安装、登录的 claude、codex、grok CLI，复用现有账号与订阅。用户还能在 Settings → Engines 指定自定义 CLI，包括固定版本或包装脚本。

每个 Bot 可以有自己的模型、指令、电脑和应用连接，模型也能在对话中途切换。频道则负责划分 Work、Personal 或项目上下文：各自拥有聊天记录、共享指令、工作目录、响应规则和成员列表，不必为了换项目复制整套 Bot。

这套设计解决的是「同一个助手混着处理所有事情」的问题。对程序员而言，工作目录和项目指令的隔离，比给 Bot 换头像更有实际意义。

Auto 房间还可以自动选择接手消息的 Bot。Settings → Decision 支持配置 Cloudflare Workers AI token 与 account ID、TypeSafe Jev key，或 OpenRouter key 与模型。作者称决策可在几百毫秒内完成；关闭决策模型或判断不确定时，会退回房间负责人。原文没有给出延迟分布、路由准确率或测试条件，这个速度描述只能作为项目声明看待。

本地优先，具体落在哪一层

项目采用两个进程：React 19、Tailwind CSS 构成的应用通过 HTTP 发送命令，再把一条 SSE 事件流归并为界面状态；本地 harness server 管理 Agent 进程，把不同提供方的协议统一成运行时事件，并按会话记录为 NDJSON。

大白话解释：界面负责展示与交互，服务负责启动 Agent、收集事件和转交权限请求。新增提供方时，前端不必再理解一套原生协议。

开发环境中，应用使用 5199 端口，服务监听 127.0.0.1:8799。聊天记录、密钥和事件存放在 ~/.openmausbot。技术栈还包括 TypeScript strict、Electron 和 Vite；开发要求 Node 24+、pnpm，以及至少一个已登录的 Agent CLI。

从终端启动的最短路径如下：

npm install -g openmausbot
openmausbot

注意第二行会启动服务，终端需要保持打开；Ctrl-C 停止服务，但保留已保存的工作。也可以用 npx openmausbot，通过 --no-open 跳过打开浏览器，通过 openmausbot setup 重新配置。

本地优先说明控制层和记录落在哪里，不能据此推断数据不会离开电脑。

模型推理、Boat 云电脑、Composio 应用连接，都可能涉及外部服务。Composio 提供 500+ 应用连接，Boat 试用结束后收费，云电脑使用可能产生费用。前端只接收密钥是否已配置的标记，也不代表磁盘加密：原文明确说，终端配置中的 API key 以明文写入 config.json，Unix 权限为 0600。

真正需要看清的是权限和后台任务

Bot 可以使用云 Linux 桌面、隔离的 Local VM，或在支持的平台上操作宿主机。Shell 命令、文件编辑和提问会显示成聊天卡片，由用户 Allow、Deny 或回答，权限代理负责承接这些请求。

但这个机制有平台边界。macOS 和 Ubuntu Xorg 的宿主机控制需要明确开启；Ubuntu Wayland 因 issue #345 尚未解决而禁用。Ubuntu 24.04 x64 仍属 beta。Xorg 使用经审查的 Cua Driver 0.41.3，构建时检查归档大小、SHA-256、文件白名单和内部可执行文件哈希，安装后的应用不会自行下载或更新原生自动化代码。这些是具体防线，不能扩大解释成所有操作都已获得安全保证。

外部编排也做了能力收口。stdio MCP server 允许 Claude Desktop、Cursor 查看 Bot 和频道、搜索聊天记录、创建任务、发送工作、等待完成、切换模型和中断执行，但不暴露批准权限、删除、凭据、任意设置或电脑生命周期控制。

自动化部分尤其需要区分「创建触发器」和「批准执行动作」。Bot 可以直接创建触发器，不再单独确认，聊天中提供 Edit、Pause、Undo。调度支持单次、指定工作日或每 5–1,440 分钟运行；上一轮没结束时跳过本轮，避免任务无限排队。Advanced run limit 可以限制卡住的任务，但默认没有超时。

应用事件与 webhook 走两条不同路径。应用事件经 Composio 入队，由桌面长轮询获取，关闭期间事件可等待；Gmail 每 15 分钟检查，Slack、GitHub 等推送型应用即时到达。桌面额度为每天 500 个事件，付费 Cloud 为 2,000 个；自带 Composio key 的服务暂不支持监听应用事件。

webhook 默认监听 127.0.0.1:8800，或 OMB_PORT 加一，可用 OMB_WEBHOOK_PORT 修改。它只暴露 /health 和秘密 /hooks/... 端点，推荐 Bearer 鉴权；程序必须保持运行才能接收投递，公网入口需要单独代理这个接收器。

我的判断

我认可它把聊天界面、执行进程、事件协议和权限代理分开的做法。对已有 CLI 工具投入的团队，复用登录、保留本地记录、提供受限 MCP 控制面，比重新接入一个封闭工作台更容易评估和迁移。

团队配置的分发也有参考价值。一个 Markdown 文件通过 YAML frontmatter 描述可安装结构，普通正文保留工作手册；导入前先审阅，连接等待批准，例程暂停。分享部门时排除聊天、密钥、密码、模型选择和电脑，接收者默认得到 Ask 权限、关闭的技能和暂停的例程。不过，组织管理员分发的模板支持启用技能，不能把普通分享的默认值套到所有入口。

需要打问号的是「多个 Bot 就更高效」。原文没有给出单 Agent 与多 Agent 的成功率、耗时或 token 成本对照。对于边界清楚的小任务，直接使用 Claude 或 Codex CLI，可能更省配置和沟通。多个角色能否减少返工，要看任务分工和交接质量。

README 还同时出现「hosted/mobile connectivity 仍在建设」与手机配对、原生应用、服务器访问方式的描述，却没说明版本对应关系。能看出方向，不能据此保证每种组合都已稳定可用。

能拿来做什么

• 如果你已经使用 Claude 或 Codex CLI，可以先让一个 Bot 在独立工作目录完成一次代码修改，检查指令、工具事件、审批和最终产物能否形成完整记录，再决定是否增加角色。
• 如果准备把它接入前端项目或 Node 工作流，可以先验证本地聊天，再逐项开启 GitHub 等连接和电脑控制，并检查 config.json 的保存位置与文件权限。
• 如果要运行定时任务，可以先手动完成同一任务，再配置调度和 Advanced run limit；同时确认桌面常驻、事件额度以及 webhook 的网络入口。
• 如果团队已有成熟的 AI 工作手册，可以尝试做成带 YAML frontmatter 的 Markdown 包，重点检查导入后的技能、连接和例程状态，不要把配置可复制当成执行质量可复制。