给不同任务挑不同的模型厂商，每家的额度和配置文件各躺一份，谁快用完了一次要等报错才知道；想给几个角色各配一台"能动手"的电脑——查资料、改文件、发消息——又怕权限一旦撒出去就收不回来。
有一个项目专门收拾这两件事。它不是又一个聊天壳，而是把"一个模型配一个对话框"改造成"一支各有电脑、各自模型、各自记忆的 AI 团队"：每个 bot 有独立人格、独立的模型账号、独立的电脑（云端 Linux 桌面、隔离的本地虚拟机，或你自己的机器）和独立的应用连接，模型、算力、数据全部留在本机。它叫 milind-soni/OpenMausBot，一款开源的 Grok Bot 替代品。
下面把它拆开讲清楚：它由哪些部分构成、哪几条设计值得单独拿出来看、以及它的边界在哪里。
一、它到底是什么形态：本地优先的"一队 bot"
一句话定位
一个聊天应用里的一队 AI bot，每个 bot 有自己的模型、自己的电脑、自己的连接应用，跑在自己的机器上。项目另名 MausBot，前身叫 OpenGrokBot；README 明确写了这是独立项目，与 xAI、Meta、OpenAI、Manus 均无隶属关系。
本地优先是硬承诺
README 对 "Local first" 的定义很具体：一个小小的 harness server 常驻 127.0.0.1，由它托管全部 agent 进程；transcript、密钥和事件都落在 ~/.openmausbot 里，而不是云上。也就是说，模型可以来自任何一家厂商，但编排层、记忆层和凭据层都在本机。
每个 bot 的"手"有三种来源
上游把 bot 能用的算力分成三类：一台云端 Linux 桌面、一个隔离的 Local VM，以及在平台安全边界已被认证的前提下直接操作用户自己的电脑；另外还有通过 Composio 接入的 500 多个应用。这三种来源共用同一套审批流——不管危险动作发生在云机器还是本机上。
桌面壳只是最后薄薄一层
形态上它是 Electron 桌面壳（macOS / Windows / Ubuntu）+ 本地 harness server + 聊天前端。应用层不含任何传输实现，只发 typed command，再把一条 SSE 事件流折叠成界面状态。harness server 默认监听 127.0.0.1:8799，负责拉起并托管全部 agent 进程；每个回合的 transcript 按线程落成 NDJSON 文件。
二、它站在谁对面：七周内密集上线的五个闭源对手
同一时间窗口里的对手
README 把动机写得很直白：2026 年七周内有四个闭源个人 Agent 产品密集上线，每一个都把模型、电脑和数据留在厂商那边；OpenMausBot 做的是同一个形态的开源版本。文档里同时列出了五个对标对象。
五个对手各自锁死了什么
Grok Bot 是 xAI 的一组 bot，共用一台云电脑，只能用 Grok 模型，需要 SuperGrok 或 Cursor 订阅。Meta Muse 是 Meta 唯一的个人 Agent，跑在 Meta 云端虚拟机里，只面向美国和加拿大。OpenAI dots 是 ChatGPT 里的常驻 Agent，只支持 GPT，且限 Pro 与 Business Premium 套餐。Cue by Manus 是 Manus 的邀请制 Agent，自带手机、邮箱和钱包。Instinct 是 Spear Street 的邀请制 Agent，在云电脑上替你保管密码。
差异化的落点很具体
对应的差异点也写得很具体：每个 bot 可换模型、数据落在 ~/.openmausbot、用审批卡片代替"直接执行"、OAuth 代替密码托管、500 多个应用连接。这一节的价值不在排他性，而在于它把"个人 Agent"这个形态的边界划了出来——单 Agent 还是一队、能不能换模型、数据在谁手里、危险动作由谁批准。
三、五层结构与"归一化"这条主线
驱动层：每厂商一个 driver
server/drivers/ 目录下一家厂商一个：Claude、Codex、Grok Build 各自走本地 CLI 的原生协议——分别是 stream-JSON、JSON-RPC 和 ACP，另加一个云电脑 agent。同一台机器上不同厂商的 CLI 输出格式完全不同，这一层把它们接成同一种东西。
harness 层：注册表 + fan-in 事件总线
server/harness/ 是活实例的注册表（配置 → 运行中的实例），也是所有客户端共同折叠的那条事件总线。多个 bot 同时说话，界面只需要消费一条流。
API 层：HTTP + SSE
server/index.ts 承担 bot 列表、回合、审批、模型目录、电脑生命周期、连接器与配置，接口形态是 HTTP 加 SSE。它是 harness 与所有客户端之间唯一的一层。
语音层：托管与本地各占一半
server/tts/ 支持 ElevenLabs、Fish Audio、Grok（xAI）、macOS 内置语音，以及本地 Chatterbox 服务。上游的说法是云端 key 留在 harness 一侧，Markdown 会先被改写成适合朗读的内容再交给语音合成。
桌面层：平台差异被显式承认
electron/ 承载 macOS、Windows 和 Ubuntu 三种外壳，内嵌 harness 并接管平台能力。Apple 语音只在 macOS 可用，Ubuntu Xorg 需显式 opt-in 才允许本机控制，Wayland 则保持 fail-closed。
一条关键规则：未知 driver 降级为 unavailable
README 里最该抄走的一句是这个：未知 driver 降级为 "unavailable"，绝不拖垮整个 fleet。单个厂商的驱动挂掉，状态被标记为不可用，其余 bot 照常工作。这是一条局部隔离语义，与"整体链路走完必须响亮失败"是两回事——后者要求宁可报错，也不许假装干完。
四、六条值得单独拿出来看的设计决策
① 权限代理取代"直接执行"
shell 命令、文件改动、提问请求都会变成聊天里的内联卡片：允许 / 拒绝 / 直接回答。云电脑和本机电脑共用同一套审批流。上游的原话是，权限代理把每一个有风险的动作都变成由人做的决定。危险动作不再依赖"agent 应该知道分寸"，而是架构上必须过一道人。
② MCP 控制面是"有边界"的
项目自带 stdio MCP server，供 Claude Desktop、Cursor 这类外部客户端接入。它暴露的是一条刻意收窄的团队控制面：查看 bot 与 channel、读取与检索精简后的 transcript、创建和配置 bot/channel/task、派活、等完成、切模型、打断回合。它不暴露审批授权、删除、任意设置、凭据、电脑生命周期。把"不暴露什么"写进接口契约，而不是靠运行时校验兜底，这是这份设计里最值钱的部分。
③ 团队包只承载"意图"，绝不携带"权限"
一个 Markdown 文件就能装下一个部门：bot 及其指令、图片、技能、群聊、routines、共享指令、Chief of Staff、连接槽位与起始便签。导入前有审阅页；导入后连接一律保持关闭直到批准，routines 到达即暂停，bot 以 Ask 模式入场，技能默认关闭。聊天记录、密钥、密码、模型选择、电脑访问一律不进包，凡是长得像 secret 的文本会被剥掉。机器读 YAML frontmatter，人读普通 Markdown playbook，两边同时成立。
④ 供应链：原生自动化代码的来源可审计
Linux 打包器在构建期只下载 tag 固定的归档，并校验体积、SHA-256、完整成员白名单与内层可执行文件哈希，打包时只带 CLI 与 cursor 主题 sidecar。装好的 app 永不下载、也永不自我更新原生自动化代码。随包附带 Cua 的 MIT 声明、Inter 的 SIL OFL、第三方许可报告与 CycloneDX 清单。
⑤ 平台安全闸是 fail-closed 的，而且会清理历史授权
Ubuntu Xorg 上需显式 opt-in 才启用本机控制；Wayland 在真实席位安全闸未解决前根本不会启动该 runtime，并主动清理历史遗留 opt-in。上游引用的跟踪 issue 是 #345、#29 与 #113。Linux 预览一律由用户主动发起，不自动开启本机控制，也不自动开启 Auto 路由。
⑥ 决策模型做前置分流
接 TypeSafe Jev 或 OpenRouter 的 key 与模型后，房间设为 Auto 时，每条未被 @ 的消息由一个几百毫秒级的小模型判定该由哪个 bot 接；决策模型关闭或不确定时，回落到房间负责人。这是把"意图路由"做成产品功能，而不是靠 prompt 约定。
五、附带能力：把聊天宿主接进脚本、定时与外部客户端
headless CLI：没有屏幕也能驱动
openmausbot 命令可以在没有界面的情况下驱动一个运行中的工作区：从文件装好一队人、给某个 bot 派一件活、等它和它派出去的同伴都干完、再把产物导出。--json 输出单份 JSON 文档，退出码可被脚本分支判断。
Triggers：定时与 webhook
Trigger 的定义是"某件事发生时，某个 bot 做某件事"。bot 可以在对话里用自己的 trigger 工具直接建好定时或 webhook，不需确认，聊天里出现可编辑 / 暂停 / 撤销的活卡片；侧栏 Triggers 页列出全部计划与 webhook，带日历与运行历史。定时可以只跑一次、按周内某几天跑，或每 5–1,440 分钟跑一次；上一轮还在跑时，间隔调度会跳过本次发生，避免慢任务堆出无界队列。webhook secret 只在创建时展示一次，bot 自己永远看不到它——人从卡片或 Triggers 页复制链接。
Channel 分层：工作、私人和每个项目分开
Work、Personal 与每个项目都可以是独立 channel，不必克隆 bot。每个 channel 有自己的 transcript、共享指令、工作目录、responder 规则和可编辑的成员表；可以给 channel 及其 bot 归到一个命名上下文下，随时改名或换成员。
模型与连接器：换引擎不换编排
除本地 CLI 外，也可以接 OpenRouter、Fireworks AI、DeepSeek、Cline，或任何 OpenAI / Anthropic 兼容端点；自定义引擎是版本化的构建物或包装器，放在 Settings → Engines 里。连接器侧覆盖 Composio 应用与 Boat 等云电脑。
六、最值得借鉴的八条工程结论
① 事件流必须带 provider 与模型身份
把 Claude 的 stream-JSON、Codex 的 JSON-RPC、ACP 三种原生协议归一化成一条 canonical runtime event stream，是整个项目的地基。真正值得抄的不是"支持几家厂商"，而是每条事件都带 provider + model 标签——这样"正在降级的 provider 发出的事件"会在流里显形，而不是消失在文本里。一条没有身份标记的事件流，等于让故障静默通过。
② 局部降级与全局硬失败是两套语义
单个 driver 不可用，可以标 unavailable；整体 fallback 链走完，则必须响亮失败。两者可以共存，但绝不能混用：能力链走完要硬失败并告警，局部能力缺失可以降级标注。把这两种语义在文档里分开写清楚，比事后争论"这算不算 bug"有效得多。
③ 交接包卫生：只携带意图，不携带权限
团队包的默认降权形态值得直接借鉴：连接关闭直到批准、routines 暂停到达、bot 以 Ask 模式入场、secret 一律剥除。可借鉴的是"默认降权 + 逐项显式批准"这个形态，而不只是"禁止在交接文档里硬编码某个标识"那一条禁令。
④ 有边界的对外接口面
它的 MCP server 显式排除审批授权 / 删除 / 任意设置 / 凭据 / 电脑生命周期。给外部 agent 或第三方工具开的口子，也应该逐条列出"不暴露什么"，让边界写在接口契约里。
⑤ 供应链与能力安装的 provenance 纪律
tag 固定归档 + SHA-256 + 成员白名单 + 内层哈希 + 安装后不自我更新原生代码 + CycloneDX 清单，与知识库自动化的导入安全闸同向：注册表先做安全裁决，安装产物落盘留证。
⑥ fail-closed 的能力开关要清历史授权
Wayland 未解禁时不仅"不启动"，还主动清理旧 opt-in。浏览器控制、节点配对这类高权限能力的开关，在安全闸未通过时应主动作废旧授权，而不是留着"以后再说"。
⑦ 意图路由做成前置小模型层
几百毫秒级小模型判每条消息该给谁，不确定就回落负责人。对应的工程要求有两条：把"意图分流"放在昂贵模型之前，且回落必须确定，不能"不确定就硬猜"。
⑧ 秘密不进入模型的视野
webhook secret 永远不展示给 bot；凭据在配置层就该被截断，界面只看到 "configured" 标志而不是密钥值。靠提示词约定遮挡秘密，是最不可靠的一层。
七、部署必要性评估：结论是不部署
理由一：形态重复
已经有一套多 agent 宿主 + 定时任务 + 记忆栈，再叠一个聊天宿主属于重复建设；Electron + React 桌面壳对以服务化运行为主的形态没有增量。
理由二：成熟度仍在波动
368 个未关闭 issue（连同 PR 合计 615）相对一个三个月的仓库不算低，说明产品还在剧烈迭代期；上游自己也把 Wayland 支持挂在未解决的 issue 上。
理由三：价值在流程设计，不在可复用代码
它真正的资产是那几条工程纪律（事件流身份、权限代理、默认降权、provenance），而不是某段可以搬走的实现。把纪律读走，比把产品装上更划算。
理由四：依赖取向相反
它的外部依赖集中在云电脑、应用市场与托管语音上，与"本地优先 + 秘密不出机器"的取向并不一致，这决定了它更适合被读，而不适合被整体搬用。
八、三个容易被忽略、但决定成败的细节
① 记忆是文件，不是数据库
harness 把每家厂商的原生协议归一化成一条 canonical runtime event stream，按线程落成 NDJSON 文件，位置在 ~/.openmausbot。于是审计、备份、迁移都退化成"拷贝一个目录"，而不是"连数据库做导出"。
② 密钥只写不读
上游对凭据的处理只有一句话：secrets are write-only——界面永远只看到 "configured" 标志，拿不到值本身。这条把"密钥出现在日志、截图或模型上下文里"这条泄漏路径从架构上堵死，而不是靠流程提醒。
③ 加一个厂商，只要一个文件
README 说得很直接：新增一个 provider，就是在 server/drivers/ 里加一个文件加一行注册；任何说 ACP 的 CLI、任何 OpenAI 兼容端点，不写代码也能通过配置接进来。OpenRouter、Fireworks AI、DeepSeek、Cline 或自有的 Anthropic 兼容端点，同样只是配置项。
九、数据边界与事实核验口径
数字的来源与时点
星标、fork、issue 数、语言、许可证、建仓与推送日期，均为 2026-10-31 13:0x CST 直取 GitHub REST API 的实测值；当日新增星标取自 github.com/trending 页面的当日直取结果。issue 口径分两种写法：GitHub 接口的 open_issues_count 为 615（含 PR），去掉 PR 后的纯 issue 为 368，本文采用后者。抓取过程中 GitHub 接口触发过一轮限流，已重试取全。
上游核验方法
文中出现的每一个专有名词——包括 Grok Bot、Meta Muse、OpenAI dots、Cue by Manus、Instinct、Claude、Codex、Grok Build、ElevenLabs、Fish Audio、Chatterbox、TypeSafe Jev、OpenRouter、Composio、Boat、Claude Desktop、Cursor、Cua Driver、Inter、CycloneDX 等——都回到上游 README 与仓库文档逐条核对过，核对方式为字符串检索 + 人工读原文，确认存在且上下文一致。
已知边界
README 里带 docs/ 链接的细节（团队包格式、MCP 工具清单、决策模型、Linux 桌面指南）本次只核到 README 层面的表述与链接，未逐份展开文档正文；文中凡涉及这些部分的描述，都限定在 README 明文范围内，不做超出上游表述的推断。