OpenBot 将多种编程助手装进桌面工作台

把 Codex、Claude Code 等编程 Agent 放进同一个桌面应用，OpenBot 想解决的是任务执行之外的管理问题：会话怎样长期保留，任务怎样排队，多个 Agent 怎样交接文件，以及离开电脑后怎样继续操作。

它的方向很明确：把临时打开的 AI 助手组织成持续工作的队友。但项目仍是开发预览版，默认执行权限很大。理解它的工作方式，比看支持多少模型更有用。

长期运行的 Agent，比聊天窗口多了什么

OpenBot 给每个 Agent 分配独立会话和本地工作区，并保存模型、推理强度、通知、浏览器和面板状态。用户可以通过提示词创建或编辑 Agent，保存前检查指令、头像和配置。这里的「持续」主要指工作环境和状态能够保留，不等于模型会在后台一直思考。

围绕这些会话，项目补了几层执行管理。

首先是 FIFO 消息队列，也就是先来的任务先处理。队列支持暂停、恢复、取消和崩溃后的持久化恢复。其次是上下文监控，在线程耗尽模型窗口前自动压缩。压缩能让对话继续，但原文没有给出压缩后的信息保留效果，不能据此认定长任务不会丢细节。

协作也有明确结构：Agent 之间可以发送消息、回复、反应、图片和受管理的文件；共享频道为任务指定一名负责人，再显式委派工作，并提供 Stop、Resume、Reassign、Archive 和 Restore 控制。

这套设计的价值在于把协作过程留下来。谁负责、任务停在哪里、文件交给了谁，都有承载位置。不过，README 没有提供多 Agent 相比单 Agent 的完成率、耗时或成本对照。

Skill 则承担可复用流程。Agent 可以创建带有 SKILL.md 的文件夹，通过 create_skill 保存到共享本地库；其他 Agent 再自行安装。库里的更新不会自动覆盖已安装副本，修改过的安装文件也受到保护。这样更容易控制流程版本，代价是需要主动维护副本。

接入多家 Agent，不等于统一了它们的能力

OpenBot 支持本地 Codex App Server、Claude Code，以及通过 ACP 接入的 Grok CLI、OpenCode、Gemini、Cursor CLI 和 Cline CLI。ACP 可以理解为应用与 Agent 进程之间的通信接口：界面可以统一，登录方式、模型权限和服务条款仍由各家决定。

底层结构也能看出它更像一个宿主应用。下面这段原始架构说明了桌面界面、本地执行进程和账户服务之间的关系：

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, and team tunnels
    └── R2 account avatars

要留意 sandboxed WebContentsView browser host 这一行：浏览器有沙箱，并不能推出 Agent 执行命令时也有同等隔离。

各家接入还有不少差异。原文称 Gemini 需要 Google AI Pro 或 Ultra，并按需下载 Antigravity ACP server；Cursor 使用 Cursor plan 或 CURSOR_API_KEY，启动命令是 cursor-agent acp，不是打开编辑器的 cursor。

Cline 使用 cline --acp，自行安装的 CLI 至少需要 3.0.68。原文还明确提醒，免费模型的提供方可能使用提示词训练模型。Cursor 和 Cline Agent 目前留在本机，团队成员看不到；远程 OpenCode Agent 则要求 Team API v4。

这些差异会影响实际选型。支持列表只能证明有接入路径，不能保证某个 Agent 可以远程共享，也不能保证现有订阅覆盖所有模型。

OpenBot 优先使用自己管理的 CLI，显式设置的 OPENBOT_*_PATH 优先级更高。它会在启动时和每小时检查更新，安装最新上游版本；native-runtime.lock.json 只是首次安装的回退版本。因此，定位问题时不能只看仓库里的锁定记录，还要确认实际运行的 CLI。

本地优先，为什么仍然要认真看权限和网络

OpenBot 保存本地状态，但执行任务时仍可能连接多家云服务。

Codex、Claude、Grok、Gemini 等会连接各自提供商；浏览页面和插件也可能访问网络。项目支持自定义 OpenAI-compatible endpoints，并能检测 Ollama、LM Studio，但不能因此把整套产品理解成默认离线运行。

远程访问则采用另一套分工：主机的 Team API 保持监听 loopback，由隐藏的沙箱 Electron 页面通过 WebRTC 连接受邀客户端。条件允许时直接走 DataChannels，直连失败时通过 coturn 转发。Cloudflare 保存账户、配置、成员关系、邀请和逻辑会话等信息；按项目说明，聊天、文件、命令和远程桌面媒体不经过 Cloudflare。

这能解释它的网络边界，却还不是对完整隐私和安全性的独立验证。

更直接的风险来自执行权限。开发预览版的 Agent 使用 danger-full-access 和 approvalPolicy: never。首次明确同意后，读写文件、执行命令、联网和控制内嵌浏览器，都不会逐项确认。

独立工作区用于组织任务，不构成主机文件的访问边界。

每个 Agent 默认使用 ~/OpenBot/Agents/<agent-id>，也能访问 ~/OpenBot/Shared。原文同时说明，只要提供商和操作系统允许，它们也可以访问这些目录之外的主机资源。

Linux 安装细节进一步说明了两种边界的区别。Ubuntu 23.10 及以上、Debian 13 可能因 AppArmor 限制非特权用户命名空间而无法启动，需要安装配置：

sudo install -m 0644 build/linux/openbot.apparmor /etc/apparmor.d/openbot
sudo systemctl reload apparmor

第二行用于重载 AppArmor，让配置生效。项目明确要求不要通过 --no-sandbox 绕过启动问题，因为那会移除 renderer 与计算机其他部分之间的隔离。保留 Electron 沙箱，与约束 Agent 的命令权限，是两件都要处理的事。

平台支持也有条件：桌面支持 macOS 13 及以上、Windows 10 x64，以及 x64、arm64 Linux AppImage；Linux 远程桌面只支持 x64 的 X11 会话，不支持 Wayland，arm64 AppImage 也不包含该能力。

我的判断

OpenBot 抓住了 AI 编程里一个实际问题：当任务跨越多轮对话、多个执行者和多个设备时，需要管理的已经不只是提示词，还有队列、文件、任务归属和恢复状态。原文对这些机制交代得比较具体，这是它比单纯聚合模型入口更有价值的地方。

但「持续的 AI 队友」目前仍是产品定位。README 给出了功能和架构，没有实测证明自动压缩能保住多少上下文，也没有证明多 Agent 委派比单 Agent 更划算。不能把协作界面的完整度，直接当作交付能力的证据。

和直接使用各家 CLI 相比，它增加了统一状态管理，也增加了 Electron、账户服务、远程连接和运行时更新等维护环节。偶尔让 Agent 修改一个文件，这些环节未必划算；经常需要排队执行、跨设备查看和明确交接的任务，更适合拿来验证。

另一个前提是许可。原文标示 PolyForm Noncommercial 1.0.0，并明确说 OpenBot 不是自由软件。代码可见不代表商业用途不受限制，团队采用前需要核对许可范围。

能拿来做什么

• 如果已有多个编程 CLI，可以先用备份完整的小型项目，验证排队、暂停恢复和文件交接是否减少了重复操作，再决定是否迁移日常任务。
• 如果要把前端或 Node 项目的重复流程整理成 Skill，可以关注它的本地库和版本机制，并明确何时更新已安装副本，避免以为修改共享库后所有 Agent 都已同步。
• 如果准备参与开发，按原文固定 Bun 1.4.2 和 Node.js 24，先运行 bun run codex:doctor 检查 CLI 版本、App Server 握手和 ChatGPT 登录；Computer Use 单独用 bun run cua-driver:doctor 检查。
• 如果经常让 Agent 在 git worktree 中工作，可以参考 bun run dev:bootstrap 的初始化流程，把依赖安装、配置复制和独立开发资料准备做成固定步骤，减少每次开工前的环境整理。