OpenBot：把一堆命令行 AI Agent 变成「常驻同事」的本地桌面工作台

如果你同时开着 Codex、Claude Code、Grok CLI 三个终端窗口，每个 Agent 各跑各的、上下文互不相通、产出文件散落在各个临时目录里——这几乎是每个 AI 编程重度用户的日常写照。OpenBot 就是冲着这个痛点来的：它不是又一个 Agent 框架，而是一个本地优先（local-first）的桌面工作台，把你已经在用的那些命令行 Agent 收编成有名字、有头像、有独立工位、能互相发消息的「常驻同事」。

截至 2026 年 11 月，这个来自 nightly-labs 的项目在 GitHub 上已积累约 5.8k Star、594 个 Fork，且仓库并未归档，仍在高频迭代（最新版本 0.62.0，CHANGELOG 显示 0.61.0 于 11 月 4 日发布）。

它从哪里来，为什么长成这样

OpenBot 的作者 Norbert Bodziony 选择了 Electron + SolidJS + SQLite + Bun 这套「重桌面」组合。README 里给出的架构图非常清晰：

Electron main ─┬─ local Codex App Server process over stdio JSONL
               ├─ local Claude Agent SDK session over stream JSON
               ├─ SQLite command log and read projections
               ├─ secure typed IPC handlers
               └─ sandboxed WebContentsView browser host
               ↓
         typed preload bridge
               ↓
         SolidJS renderer
               ↓
Cloudflare Workers ─ TanStack Start + Solid 2 account API
                  ─ D1 accounts / email challenges / hashed sessions
                  ─ R2 account avatars

关键设计取舍在于：模型不在 OpenBot 里，模型在各家 CLI 后面。Codex 走 App Server 的 JSONL 协议，Claude 走 Agent SDK 的 stream JSON，其余（Grok、OpenCode、Gemini、Cursor、Cline、Kimi、Devin、GitHub Copilot）统一走 ACP（Agent Client Protocol）。这意味着 OpenBot 不需要为每个 Agent 重写一套集成，只要某个 CLI 支持 ACP，它就能以「一等公民」的身份出现——项目文档里点名了 Goose 和 Qwen Code 会走同一条路。

账号体系跑在 Cloudflare Workers + D1 上，负责邮箱验证码登录、会话哈希和团队隧道。但 README 明确强调：服务器只处理账号、邮箱挑战码、会话哈希，不碰聊天记录、文件、命令，也不碰远程桌面媒体流。

用一个比喻理解它

把它想成一间联合办公空间（co-working space）：

• 每个 Agent 有自己的工位（~/OpenBot/Agents/ 下的独立工作目录）
• 每个工位有自己的档案柜（SQLite 里的持久对话线程）
• 茶水间是共享区（~/OpenBot/Shared），Agent 之间通过 Transfers/ 目录交接文件，每个交接都有 .openbot-transfer.json 清单，记录归属、接收方、大小和 SHA-256
• 前台是嵌入式浏览器（沙箱化的 WebContentsView），Agent 可以打开网页、读取页面、点击操作
• 内部 IM 是 Agent 之间的消息通道，支持回复、表情回应、传图

与传统「开一个终端跑一次」的用法相比，最大的区别是持久性：工作区、线程、身份、Provider 私有会话四件套在重启和换模型之后都还在。

核心能力拆解

1. 提示词驱动的 Agent 创建 桌面端和移动端都能用自然语言创建/编辑 Agent，保存前可逐节复核它的指令、头像和角色设定。配合 ~/OpenBot/Shared 共享目录，Agent 之间可以交换文件与成果。

2. FIFO 任务队列 每个 Agent 有自己的消息队列，支持暂停、恢复、取消，持久化是 crash-safe 的（崩了重启队列还在）。长对话有上下文监控，在撞到模型上下文窗口前自动 compact。

3. Agent 间协作与频道 共享频道聊天有且只有一个任务负责人（task owner），支持显式委派、共享历史，以及 Stop / Resume / Reassign / Archive / Restore 一整套生命周期控制。

4. 嵌入式浏览器 + Computer Use 持久化的 WebContentsView 浏览器，Agent 可以打开、检视、控制。发行版还自带 cua-driver 二进制，OpenBot 作为子进程启动它并交给各 Provider 使用——这让「让 Agent 点点鼠标」成为可能，而不必把整个桌面交出去。

5. 多 Provider 统一管理 自动检测本机的 Ollama、LM Studio 等本地模型服务器和已安装的 Agent CLI；支持自定义 OpenAI 兼容端点和自定义 ACP Agent。OpenBot 会下载并锁定各家 CLI 版本（版本记录在 native-runtime.lock.json），每小时检查上游更新，但不会修改用户自己装的系统 CLI。

6. 移动端与远程 WebRTC protocol v3 承载 RPC、事件和二进制文件，Signal 负责连接建立，coturn 作 TURN 兜底。移动端用 Expo Go 承载 RTCPeerConnection，无需自建原生开发包。另有 iOS 客户端和 openbot.run/app 网页入口。

上手门槛：桌面版远比想象中顺，服务器版要动点Linux 内功

桌面版（推荐路径）：macOS 13+ / Windows 10+ / Linux AppImage 直接下载安装，不需要装 Bun 和 Node.js。首次启动授权后即可用。Linux 上有两个坑：一是 Ubuntu 23.10+ / Debian 13 因 AppArmor 限制用户命名空间，需手动装 openbot.apparmor profile，否则启动即退出；二是无桌面服务器上 Gemini 登录会失败（Google 回调需要 127.0.0.1 上的桌面会话）。

服务器版（always-on）：Ubuntu 24.04/26.04 + systemd，一条 curl | sudo bash 装完，openbot login 登录。

Docker 版（最实用的容器化路径）：

curl -fsSLO https://raw.githubusercontent.com/nightly-labs/openbot/main/docker/seccomp.json
docker run -d --name openbot --restart unless-stopped \
  --security-opt seccomp=seccomp.json --security-opt no-new-privileges:true \
  --shm-size 1g --stop-timeout 60 -v openbot-data:/data \
  ghcr.io/nightly-labs/openbot:latest
docker exec -it openbot openbot login

镜像基于 ubuntu:24.04（digest 锁定），多阶段构建：先解包 AppImage 拿到 squashfs-root，再装 git/ripgrep/tini 等 Agent 常用工具，最后以 UID 1000 的 openbot 用户运行，tini 作 PID 1 回收 Agent 遗留进程。root 拥有发布目录，用户和 Agent 改不了；chrome-sandbox 无 SUID 位，靠 user namespace + 自定义 seccomp 白名单维持 Electron 沙箱。

开发模式：需要 Bun 1.4.2 + Node.js 24（.nvmrc 里锁的是 Electron 自带的 Node 版本）+ 至少一个 Agent CLI。bun install --frozen-lockfile 后 bun run codex:doctor 做体检，bun run dev:bootstrap 为 worktree 铺好隔离环境。测试栈是 Vitest 4 + Storybook + Testing Library，CI 配置在 .github/workflows/ci.yml。

争议与局限：不回避问题

最大问题是安全。 README 顶部的 WARNING 写得毫不含糊：这是一个 development preview，Agent 当前以 danger-full-access 和 approvalPolicy: never 运行——可以读写文件、执行命令、访问网络、控制嵌入式浏览器，且首次启动同意后不再逐次确认。文档直言这些模式是有意为之的无限制模式，因此当 Provider 和操作系统允许时，Agent 也能访问工作目录之外的宿主机资源。项目同时提供了 AppArmor profile、seccomp 白名单、no-new-privileges、独立沙箱浏览器会话（不能访问 window.openbot 和受管附件）等多层加固，但风险敞口本身依然存在。

许可证是硬门槛。 LICENSE 是 PolyForm Noncommercial 1.0.0——非商业用途免费，任何商业用途均不授权。这不是 MIT/Apache，GitHub API 也因此把它标成 NOASSERTION（它确实不是 SPDX 标准许可证）。对一个想做团队级生产化落地的公司来说，这是必须提前过法务的一票否决项。Nix 安装时甚至需要显式设置 nixpkgs.config.allowUnfreePredicate。

其他现实摩擦：

• 597 个 open issues，迭代极快也意味着 breaking change 频繁，0.62.0 的版本号本身就是「预览版」的信号
• Windows 发行版由 SYNTHETIFY LABS SPÓŁKA Z OGRANICZONĄ ODPOWIEDZIALNOŚCIĄ 签名，旧版本未签名，SmartScreen 仍会拦截
• Linux 远程桌面只在 X11 会话可用，Wayland 不行，arm64 AppImage 也不含
• 依赖数量惊人（bun.lock + 大量 catalog 固定版本），node_modules 体积不小
• 部分 Provider（如 Cursor、Cline、Kimi、Devin、Copilot）Agent 仅限本机运行，团队成员看不到
• Cline 的免费模型 Provider 可能用你的提示词训练模型，需自行评估合规

行业意义：多 Agent 编排的「外壳层」正在成形

OpenBot 代表了一个正在清晰起来的趋势：当 Agent CLI 已经足够多、足够强，真正的稀缺品不再是模型，而是「管理多个 Agent」的那层外壳。

这个外壳要解决四件事，而 OpenBot 都给了答案：身份与工作区（谁是谁、在哪干活）、持久上下文（重启不丢）、Agent 间通信与文件交接、以及人类介入的控制面（Stop / Reassign / Archive 这些按钮背后，是把 Agent 从一次性进程变成可管理资产的理念转变）。

从架构上看，「ACP 作为一等公民」这个决定尤其聪明——它把 N 种集成问题降级成 1 个协议适配问题，让生态扩展性不再受限于 OpenBot 团队的工程速度。5.8k Star 与 594 Fork 说明开发者社区认可这个方向。

至于它能不能从「令人兴奋的技术预览」变成「可采购的企业软件」，答案主要不在技术层面，而在两件事上：许可协议什么时候放开商业用途，以及 danger-full-access 的默认策略什么时候能收敛。这两个问题解决了，剩下的都是工程细节。

快速上手建议

1. 想试鲜、只想本机用 → 直接下载 dmg/exe/AppImage，零依赖，5 分钟看到效果
2. 想当常驻服务用 → Docker 方案最干净，docker run 一条命令 + seccomp 加固
3. 想在团队落地 → 先做法务评估（PolyForm 非商业限制），再评估 Agent 全权限运行的审计需求
4. 想读源码 → src/main（Electron 生命周期与 IPC）、src/backend（Provider 适配、持久化、调度）、src/preload（typed bridge）、src/renderer（SolidJS 界面）、apps/auth-api（TanStack Start 账号 API）、packages/contracts（进程边界契约与纯校验）——这套分层非常清晰