一、导读
2026 年 10 月 29 日，一个叫 OpenBot 的 TypeScript 项目在 GitHub 日榜上再涨 705 星（仓库 nightly-labs/openbot，当日榜第 8 位，也是当日榜单中唯一「以大模型为核心能力」且站内尚未发布过的合规项目）。它做的事情可以用一句话概括：把 Codex、Claude Code、Grok CLI、Gemini、OpenCode、Cursor CLI、Cline CLI 这些各自为战的编码智能体，装进同一台本地电脑，给每一个智能体一间独立办公室（workspace）、一条任务队列、一段长期记忆，再给它们一间共享会议室（channel）互相派活。
它不训练模型，也不托管模型，而是把用户已经付费的 ChatGPT / Claude / Gemini / Grok 订阅「复用」成一支常驻团队。核心结论有三条：第一，它的价值不在模型能力，而在协调层——队列、交接、审批、上下文预算与记忆治理；第二，它的架构选择极其明确：本地优先、进程隔离、SQLite 单一事实源、协议边界（contracts）优先；第三，它的安全姿态是「诚实但激进」——智能体默认 danger-full-access + approvalPolicy: never，官方 README 自己把这一点写成了警告块，这既是它最大的效率来源，也是它最大的风险来源。
本文拆解它的架构原理与应用场景，并如实标注边界。
二、项目速览
| 维度 | 内容 |
|---|---|
| 仓库 | nightly-labs/openbot |
| 开发方 | Synthetify Labs（波兰，GitHub 组织 nightly-labs） |
| 主语言 | TypeScript（Electron + SolidJS + Bun workspace） |
| Star 总数 | 约 3,823（截至 2026-10-30，GitHub API） |
| 当日涨星 | 705（GitHub Trending daily，2026-10-29 数据） |
| License | PolyForm Noncommercial 1.0.0（≤ v0.1.11 为 Apache-2.0；商用需单独授权） |
| 首次发布 | 仓库创建于 2026-08-12；最新 Release v0.54.0（2026-10-29） |
| 平台 | macOS 13+ / Windows 10+ / Linux（AppImage），另有 iPhone、Android、Web 客户端 |
| 支持 Provider | Codex（ChatGPT 计划）、Claude Code、Grok CLI、OpenCode、Gemini、Cursor CLI、Cline CLI，以及任意 OpenAI 兼容端点、Ollama / LM Studio 本地模型 |
需要特别说明：官方定位是「local-first, not offline-only」——工作区、会话、队列、文件留在本机，但每一次模型调用仍然要连到对应厂商的云。这一点常被误读为「离线可用」，实际不是。
三、为什么是它：从「单人单聊」到「多人多智能体」的错位
过去一年，编码智能体的形态经历了两次跃迁。第一次是 CLI 化：Claude Code、Codex CLI、Gemini CLI 把「模型 + 工具循环 + 沙箱」打包成命令行程序，开发者可以并行开好几个终端。第二次是「常驻化」：Grok Bot 这类产品把智能体搬进云端常驻电脑，给它自己的浏览器、文件系统和终端，关掉笔记本它还在跑。
但两次跃迁都留下同一个空洞：协调。一个 Codex 会话和一个 Claude 会话之间，无法交换一个文件、无法传递一个状态、无法互相评审。用户被迫成为人肉消息总线——把 A 的输出复制到 B 的输入，把 B 的报错贴回 A。当任务需要「研究 → 编码 → 测试 → 评审」四段接力时，这个空洞会迅速吃掉所有收益。
OpenBot 的定位正是填这个洞。它的三个判断很关键：
- 基础设施应该归用户。Grok Bot 把智能体放在厂商的云电脑上，模型选择与计费都被托管；OpenBot 反其道而行，把智能体放在你自己的桌面或家用服务器上，模型逐智能体自选。代价是明确的：你的机器必须开着。
- 复用已付费的订阅。它不引入新的模型账单，而是通过 Codex App Server、Claude Code、Grok CLI 等官方 CLI 复用用户已有的 ChatGPT / Claude / xAI 订阅，或用 Ollama / LM Studio 跑本地模型。
- 持久化优于一次性。每个智能体有名字、指令、独立工作区、独立会话与记忆，而不是每次从空白对话开始。
涨星动因由此可以解释：它踩中了 2026 年下半年最热的两条线——「多智能体协作」与「本地优先 / 数据主权」，同时又给出了一个足够具体的产品形态（桌面应用），而不是又一个需要自己拼装的框架。
四、架构原理
4.1 整体架构：一个 Bun workspace，三层进程，一条依赖方向
OpenBot 是一个 Bun workspace，仓库里同时装着桌面端、浏览器端、移动端、两个 Cloudflare Worker、一个自托管 Signal 服务，以及若干共享包。它的目录结构与依赖方向是理解整个系统的钥匙（来源：仓库 docs/architecture/structure.md，读取于 2026-10-30）：
apps/
auth-api/ Web 与 /app 浏览器入口、账号、成员、连接票据、计费
mobile/ Expo React Native，远程连接 team host 的客户端
site-router/ Cloudflare Worker，从私有 R2 提供已发布站点
packages/
contracts/ 进程与网络边界的类型、限额、纯校验（无 Electron / Node / SolidJS 依赖）
ui/ 桌面、Web、Storybook 共享的 SolidJS 控件
team-client/ 共享的团队连接、恢复、WebRTC 帧、灵动岛状态、例程调度
remote/
api/ Bun 写的 Signal 服务：SDP、ICE、票据校验、TURN 凭据、多平台中继
src/
backend/ 智能体运行时、provider 适配器、事件存储、队列、浏览器宿主
main/ Electron 生命周期、可信 IPC、宿主服务器、操作系统适配
preload/ Electron main → renderer 的窄类型桥
renderer/ SolidJS 界面
依赖方向被硬性约束为单向：
renderer ──► @openbot/contracts ◄── preload ◄── main ──► backend
▲ │
└──────── auth-api ──────────┘
这条线由 biome.json 里的 noRestrictedImports 规则强制：renderer 不能 import src/main 或 src/backend；preload 桥不含业务规则，只把类型化调用映射到 IPC channel；contracts 包不允许出现 Electron、Node.js、SolidJS、provider、Cloudflare 依赖（noNodejsModules 保证 Node 不进 contracts）。这是一条非常「教科书」的边界纪律，直接后果是：协议先于实现，跨进程/跨网络的数据形状可以单独版本化与冻结。
4.2 数据流：事件驱动 + SQLite 投影
OpenBot 的数据流不是「请求—响应」，而是「事件—投影」。核心链路如下：
Provider CLI (Codex/Claude/Grok/ACP)
│ 产出事件（消息、工具调用、审批请求、错误）
▼
AgentService ──写入──► openbot.db (SQLite) ──投影──► main process
│ │
│ ▼
│ renderer / web / mobile
│
└──► AttentionRegistry（待处理对象：问题、审批、浏览器接管）
关键设计是：provider 代码不能写 UI 状态。它只能把事件发给 AgentService，由后者先写 SQLite 投影，再由 main 进程把变更推给 renderer。这条规则的意义在于崩溃恢复——openbot.db 是智能体、会话、队列、反应、附件、provider 会话绑定的唯一事实源，重启后一切可重建。
同一层里还有几个「单一所有者」的存储对象，职责切得很干净：
RoutineStore：在一个事务里保存例程与其 webhook 触发器；MailboxStore：拥有附件记录、暂存生成物、邮箱提交与文件删除 outbox；AttachmentFiles：只负责草稿与传输文件的复制、限额、哈希、清单、托管路径检查与清理，不读写数据库；ConversationRuntime：持有活跃工作与有界近期缓存，已释放的全量历史 API 每次请求都从 SQLite 重建，不污染工作缓存。
~/.codex、~/.claude、~/.grok、~/.gemini、~/.cursor、~/.cline、~/.pi 以及 OpenCode / Muse 的 XDG 目录被明确划为「provider 拥有的登录与恢复状态」，不是 OpenBot 的会话存储。这条边界避免了「两个系统都以为自己拥有会话历史」的经典混乱。
4.3 模块拆解：Provider 适配层与工具发现
Provider 适配层是 OpenBot 最厚的一层（docs/architecture/providers.md 单文件超过 8 万字符）。它的设计有两个值得学的点。
第一，统一工具目录 + 延迟披露。 agent/tool-catalog.ts 向所有适配器暴露 11 个直接工具和 3 个发现工具。直接工具包括 ask_user、attach_files_to_response、list_agents、send_message、search_memories、remember、forget_memory、react_to_user_message、request_api_key、routine_no_update、routine_report_failure。发现工具是 tool_search / tool_describe / tool_call：
tool_search用本地关键词匹配，精确名优先，其次词匹配，平局按目录稳定序；默认返回 5 条、最多 10 条。最多 3 条「强结果」（精确名，或查询词覆盖工具名每个词）会连原始 schema 一起返回，让智能体省掉一次 describe 步骤——因为每个模型步都要重发完整上下文，少一步省下的输入比多带 schema 更划算。tool_call接受{ name: "namespace.tool", arguments: {...} }，路由只解析原始内置名，保留 request / thread / turn / call 标识与 abort 信号，随后进入与直接调用相同的 dispatch。发现工具不能调用另一个发现工具。
第二，上下文预算是可测量的硬约束。 agent/developer-instructions.ts 把稳定规则放最前、profile 与工作区设置其次、记忆最后；详细的浏览器、管理、例程、托管、数据、视觉指引通过 tool_search / tool_describe 按需加载。仓库里有一个 bun run check:agent-context 脚本，测量指令文本、可见工具定义、目录与指引的字节数，任何一项增长都会让 CI 失败。这是把「提示词工程」变成「工程约束」的少见做法。
第三，历史检索不靠模型。 替换 provider 会话时，handoff 上限 32,000 字符，其中 24,000 留给最近消息、4,000 给较旧摘录、2,000 给捕获的工作步骤、2,000 给指令与引用。被省略的文本由两个延迟工具恢复，且不产生模型调用：history_search（默认 5 条、最多 10 条，每条摘录 ≤400 字符，序列化结果 ≤8,000 字符）与 history_read（默认 10 条、最多 20 条，结果 ≤16,000 字符，nextOffset 续读大消息）。摘录不是语义摘要，这一点被明确写进文档——它避免了「摘要失真导致智能体基于幻觉继续工作」的隐患。
4.4 核心机制一：Channel（共享会议室）与「谁来做这个任务」
Channel 是 OpenBot 解决多智能体协调的核心抽象。一个 channel 拥有：一个 host、一个目的、参与智能体、一个被选中的 lead，以及若干关联的智能体会话。智能体成员资格决定「谁可以接活」，但不限制人类访问——每个已认证的服务器成员都能读取并使用其中的 channel。
底层由 ChannelStore 在 SQLite 中保存权威 transcript、channel 配置、任务、分派、摘要、执行线程与人类已读位置。每条 channel–agent 组合对在 projection_threads 里有一条独立的执行线程，普通智能体线程永不被替换——provider 会话、轮次、问题、审批、附件、压缩、重启恢复都走这条显式执行线程，且这些内部记录不会在导航里多出条目。
最值得研究的是 ChannelService 如何选「所有者」，因为它刻意尽量不用模型。优先级链条是：
- 被显式选中的接收者；
- 回复上挂着的任务；
- 对某条成员消息的回复（该消息没有任务）；
- 对唯一未闭合任务的明确跟进，或对「同一请求由多个成员拥有的多个根任务」的跟进；
- 只有一个可用成员的 channel。
以上选择全部不使用模型。只有当请求不属于上述任何情况时，才动用 lead 的 provider、模型与推理设置，在一个不带工作工具的独立会话里做路由，并把「可接受结果的 schema」与 channel 摘要（而非完整 transcript）作为输入。路由只选中角色或领域真正触及该请求的成员（agentIds）。
这个设计的取舍很清楚：确定性优先，模型兜底。绝大多数派活是可以用规则判定的，用规则既便宜又稳定；只有真正模糊时才付一次模型调用的钱，并且刻意不给它工具——因为路由决策不应该有副作用。
4.5 核心机制二：Routine（例程）与 Webhook 触发
Routine 是 OpenBot 的「定时 / 事件驱动」层。一个例程只有一个触发器：schedule 或 webhook。Webhook 触发器属于它的例程，含公开 URL（注册前为 null）、可选的事件类型（null 表示接受所有类型）与最多 128 个 JSON Pointer 过滤器（每个只比较一个标量，全部匹配才触发）。过滤器和载荷模板不执行代码——这是明确的安全选择。
完整链路是：签名请求 → 路由 → 例程 → 运行。所有权切分如下：
| 数据 | 所有者 | 位置 |
|---|---|---|
| 触发器、路由 ID、加密密钥、URL | 宿主 SQLite | projection_routine_webhooks 等 |
| 回执（不含 body） | 宿主 SQLite | projection_webhook_receipts |
| 待撤销路由 | 宿主 SQLite | projection_webhook_route_revocations |
| 路由 ID → host / 账号、链接时间、撤销时间 | 账号服务 D1 | webhook_routes |
| 路由 ID → ingress socket | Signal 内存 | SignalService |
密钥是 whsec_ 前缀加 32 随机字节的 base64url，用宿主的密钥密码器（Electron safeStorage）加密；保存结果只返回一次明文密钥。rotateSecret 替换密文后旧密钥立即失效。一个宿主最多 64 条路由（WEBHOOK_ROUTES_LIMIT），main 与账号服务双重检查。
还有一个容易被忽略但很关键的细节：路由 ID 永不复用。账号服务从不删除路由行、也从不释放它的 ID，「即使宿主或账号被删除」——因为发送方仍然可能往旧公开 URL 投递，ID 一旦被另一个宿主复用就会造成串号。这是典型的「分布式系统中 ID 生命周期必须长于实体生命周期」的教训。
例程的另一个亮点是 routine-flows（例程流）：它把某个例程的答案交接给其他智能体，用三张表（links / node positions / steps）记录，并在 turn、queue、routine 事件上做 sweep。规则包括：一个 link 只对「它之后启动的运行」生效；有多个输入的智能体等齐所有输入后合并成一条消息；所有输入都失败的智能体被跳过，失败永远不会让流程永久等待。交接本身是一次邮箱投递（RoutineScheduler.enqueueHandoff），因此不改变原运行的状态机。
4.6 核心机制三：安全姿态与 Computer Use
必须把这一段单独拿出来，因为它是 OpenBot 最需要读者清醒的地方。
README 顶部有一个警告块：OpenBot 是开发预览版，智能体当前以 danger-full-access 和 approvalPolicy: never 运行。在首次启动的一次性同意之后，它们可以读写文件、执行命令、使用网络、控制内嵌浏览器，且不再有逐动作确认。SECURITY.md 里写得更直白：「Full local access is an explicit current product decision, not a security boundary.」（完全本地访问是当前明确的产品决策，不是安全边界。）
这个选择带来的是效率：智能体可以真正自主地连续工作数小时。代价同样明确：它属于「你愿意在这台机器上丢文件」的场景。官方给出的缓解手段是产品级而非内核级的——openbot-approval-automation-v3.json 记录哪些智能体拥有 Full access（即每个智能体权限档位中 autoApprove 的那一半：Workspace only / Ask first / Full access），以及「只运行你信任的任务、保留备份」。
Computer Use 的实现值得一提，因为它展示了「第三方二进制如何被正确托管」。cua-driver 是一个第三方 MIT 二进制，OpenBot 拥有它的运行方式：
- main 进程启动一个长驻
serve守护进程并持有它；每个 provider CLI 只对着这个守护进程 spawn 自己的短命cua-driver mcp --socket代理。所有屏幕捕获、可访问性读取、输入投递都发生在守护进程内部。 - 守护进程直接 spawn，绝不通过
open(1)或NSWorkspace。因为 macOS 通过向上遍历启动链寻找「负责进程」，直接 spawn 才能让 OpenBot 位于链顶，从而让用户把「屏幕录制」与「辅助功能」授权给 OpenBot 本身，而不是某个第三方 helper。 - 控制 socket 放在私有的每用户 runtime 目录、权限
0o700，不放/tmp——因为谁能连上它就能驱动整个桌面。它也不能放在userData下，因为 macOS 上sockaddr_un.sun_path只有 104 字节，而隔离的开发 profile 光 worktree 哈希就吃掉大半。Windows 用命名管道（无长度限制），名字随机且保存在 profile 里，避免「每次启动都换名字」导致 Codex 工具指纹变化、从而每次重启都替换所有会话。 - 二进制被打包而非按需下载，在
native-runtime.lock.json中钉住，安装脚本只复制白名单路径并逐个校验摘要——上游目录结构变化会让构建失败，而不是悄悄发布一个意外的文件。
在自托管服务器上，OpenBot 起两个 Xvfb display，用 OPENBOT_AGENT_DISPLAY 指定智能体 display；Electron 保留自己的 DISPLAY。这里有个真实的坑被写进了文档：openbot.service 同时持有 Xvfb，停止时会给单元内每个进程同时发信号，如果 Xvfb 先停，OpenBot 会在关闭数据库之前就被结束——因此单元的 ExecStop 先只给 OpenBot 发 SIGTERM 并等它退出。
4.7 与其他架构路线的差异
把 OpenBot 放进当下三条主流路线里对比，差别会非常清楚。
| 路线 | 代表 | 智能体在哪 | 模型谁选 | 协调方式 | 数据在哪 |
|---|---|---|---|---|---|
| 云端常驻电脑 | Grok Bot | 厂商云电脑 | 托管 | 平台内建 | 厂商云 |
| 终端多开 | Claude Code / Codex CLI 本身 | 本机终端 | 用户 | 无（靠人肉复制粘贴） | 本机 |
| 框架自建 | LangGraph / AutoGen 类 | 用户自建 | 用户 | 代码编排 | 用户自建 |
| 本地协作工作区 | OpenBot | 本机桌面 / 家用服务器 | 用户逐智能体选 | channel + 队列 + 交接 | 本机 |
OpenBot 的独特之处在于：它既不像 Grok Bot 那样把基础设施交出去，也不像裸 CLI 那样没有协调层，也不像框架那样要求你写代码编排。它把「协调」做成了产品内建能力——FIFO 队列（可暂停、恢复、取消、崩溃安全持久化）、托管文件传输、智能体间消息（含回复、表情、图片）、共享 channel（单一任务所有者 + 显式委派 + Stop / Resume / Reassign / Archive / Restore），以及一个常驻的内嵌浏览器（智能体可打开、检查、控制）。
五、应用场景
场景一：多智能体接力完成「研究 → 编码 → 测试 → 评审」
业务痛点：一个中等规模的功能开发，需要先查资料、再写代码、再跑测试、最后评审。单个智能体做完四段会严重稀释上下文；多个终端并行则没人负责交接，用户必须手工搬运产物。
如何用 OpenBot 解决：在同一个 channel 里建四个智能体（Researcher / Coder / Tester / Reviewer），选一个 lead。lead 通过 openbot.list_agents 找到领域匹配的成员，用 send_message 派活；channel 的确定性路由规则会先尝试「显式选中 → 回复挂载的任务 → 唯一未闭合任务」等路径，避免每次都付模型调用。产物通过托管文件传输在成员之间流转，而不是靠用户复制粘贴。
集成步骤（最小可用）：
# 1. 安装并连接 provider（以 Codex 走 ChatGPT 计划为例）
npx openbot install # 桌面端安装器会探测你机器上的编码工具
# 2. 在应用内用一句话描述智能体，审阅生成的指令后保存
# 3. 用本地脚本 API 从终端派活（需在智能体设置里开启 Local scripts）
alias openbot-cli='node "/Applications/OpenBot.app/Contents/Resources/cli/openbot-cli.mjs"'
openbot-cli list
openbot-cli run "Researcher" "调研 X 方案并输出对比表" --wait
收益与量化指标：官方未公布端到端任务完成率基准（待确认）。可确认的量化点是上下文与队列层面：替换 provider 会话时 handoff 上限 32,000 字符且预算被显式切分；history_search / history_read 的返回上限分别为 8,000 / 16,000 字符，且零模型调用完成检索——这意味着长会话的「记忆回捞」成本是常数级的，不随会话长度线性增长。队列状态崩溃安全持久化，重启不丢任务。
适用边界与不建议的场景：不适合需要严格逐动作审批的合规环境（默认 Full access）；不适合需要跨机分布式执行的场景——channel 与队列是单宿主内的。
场景二：把「定时情报简报」做成例程 + Webhook
业务痛点：团队需要每天定时汇总某类信息，或在外部系统发生事件时立刻触发一次分析。传统做法是写 cron + 脚本 + 邮件，维护成本高且没有智能体能力。
如何用 OpenBot 解决：给一个智能体建一个 schedule 例程（每天定点跑），或建一个 webhook 例程（外部系统 POST 触发）。Webhook 支持最多 128 个 JSON Pointer 过滤器做精确匹配，全部匹配才触发；过滤器和模板都不执行代码，因此不存在模板注入面。
集成步骤（最小可用）：
# 从终端触发一次例程运行（本地脚本 API）
long-job; curl -sS -X POST "$(cat "$OPENBOT_AUTOMATION/url")/v1/agents/<agentId>/routines/<routineId>/run" \
-H @"$OPENBOT_AUTOMATION/headers" \
-H 'Content-Type: application/json' \
-d '{"payload":"long-job ended with code 0"}'
收益与量化指标：路由与过滤全部确定性执行，无模型成本；密钥轮换即时生效（旧密钥立刻失效）；宿主上限 64 条路由，账号服务与 main 双重校验。例程支持「安静运行」——智能体可调用 routine_no_update 工具或返回 [[no-update]] 标记，此时该轮不产生未读、不改变智能体预览、不发桌面通知与完成音；官方文档说明因为模型经常写一句短话而不是精确 token，工具是主路径。
适用边界与不建议的场景：Webhook 的 ingress 要求宿主在线；自托管服务器需要自己保证可达性。不适合需要「跨多个宿主共享同一路由」的场景——路由 ID 与宿主强绑定且永不复用。
场景三：本地模型 + 云端模型混编，按任务难度分流
业务痛点：简单任务（格式化、改名、跑测试）用云端大模型太贵；困难任务用本地小模型质量不够。团队又不想维护两套工具链。
如何用 OpenBot 解决：OpenBot 会自动探测本机的 Ollama（127.0.0.1:11434）与 LM Studio（127.0.0.1:1234），把本地模型作为 OpenCode 的 provider 接入；同时把 Claude Code / Codex 作为高难度 provider。同一个 channel 里可以同时存在本地模型智能体与云端模型智能体，简单活派给本地、难活派给云端。
集成步骤（最小可用）：
# 1. 启动 Ollama 或 LM Studio
ollama serve
# 2. 在 OpenBot 的 onboarding / Settings 里，本地服务器会出现在 "Found on this computer"，点 Add
# 3. 建一个跑在本地模型上的智能体，给它一个任务
# 4. 切换 provider 时保留工作：改 provider，工作区与会话不变
openbot-cli agent set-model "Ada" claude-opus-5-5 --effort high
收益与量化指标：官方明确指出 Ollama 的默认上下文可能只有 4,000 token（小显存卡），而智能体与编码工具至少需要 64,000 token 上下文，因此必须在 Ollama 侧调高——这是可复现的配置门槛。本地模型请求不出本机，数据主权收益是确定的。
适用边界与不建议的场景：必须选支持 tool calls 的模型，小模型或未针对工具训练的模型会以错误格式发出工具调用。本地模型无需账号，但质量与上下文窗口是硬约束。
场景四：把智能体接到 Slack / Discord / Telegram
业务痛点：团队沟通在 IM 里，但智能体在本地桌面里，两边割裂。
如何用 OpenBot 解决：一个 workspace 安装同一个 OpenBot Slack 应用，workspace 被链接到连接它的宿主。人们 @OpenBot 或私聊它，workspace 的 Slack Orchestrator（连接对话框添加的一个智能体）接收每个新会话、询问队友并贴出答案——每个答案都来自 OpenBot。
集成步骤与安全细节：桌面端向 POST /v2/slack/authorize 请求 Slack 安装 URL（带一次性 host key）；Worker 在 /v2/slack/callback 交换 code（因为应用的 client secret 在那里）；D1 里只链接 workspace 与宿主（不存 token），bot token 用宿主密钥封装。Slack 把事件投到单一 URL https://signal.openbot.run/v1/slack/events，Signal 校验签名、只读 app ID 与 workspace ID，把原始 body 转给持有该 workspace 路由票据的 ingress socket，并在 2.5 秒内返回宿主答案，否则返回 503 让 Slack 重投。路由票据是 ES256 JWT，5 分钟过期，每次 socket 连接都要新取一张。
收益与量化指标：workspace 解绑或迁移时，Worker 通过签名的 auth-event outbox 发 slack-route-revoked，Signal 丢弃路由并拒绝持有该链接或更早链接的票据——失去 workspace 的宿主无法用旧票据继续占用它。这是可验证的撤销语义。
适用边界与不建议的场景：需要公网可达的 Signal 服务；企业内网需要评估出站依赖。
场景五：把智能体当「团队资产」发布与复用
业务痛点：一个好用的智能体配置（指令、技能、例程）散落在个人机器上，无法在团队内复用。
如何用 OpenBot 解决：Agent Template 是一个「仅链接式」的本地智能体副本——含名称、标题、指令、头像、例程、marketplace 技能（引用已批准版本）与本地技能（其 SKILL.md 文本），但不含工作区文件、不含记忆。聊天头部的 Publish 按钮打开 PublishAgentDialog，agent-template-service.ts 构建快照，在某个文本字段看起来像密钥时直接停止，然后 POST 到账号 Worker。Worker 在 D1 agent_templates 里按「账号 + 本地智能体」保持一行，因此第二次发布更新同一个链接。取消发布清空内容与图片、设置 unpublished_at，但保留行，所以同一个智能体再次发布会拿到同一个链接。
收益与量化指标：一个账号最多发布 5 个智能体，且这个上限写在与行写入同一条语句里——客户端或两个并发请求都无法越过它；未发布的行不计数。发布前 renderer 会画一张 1200×630 的分享卡（用 data: URL，因为 CSP 拒绝 blob:），Worker 只接受该尺寸的 PNG 并存入 R2。
适用边界与不建议的场景：没有人工审核、没有 marketplace 列表；模板不含记忆，因此「同一个智能体」在新环境里是重新开始积累记忆的。
六、快速上手
# macOS：下载 OpenBot-*-arm64.dmg 或 -x64.dmg，拖入 Applications 打开
# Windows：下载 OpenBot-*-x64.exe 运行安装器
# Linux：下载 AppImage 后
chmod +x OpenBot-*.AppImage
./OpenBot-*.AppImage
Ubuntu 23.10+ 与 Debian 13 上，非特权 user namespace 被 AppArmor 限制，OpenBot 会在启动时退出，需要安装随包提供的 profile：
sudo install -m 0644 build/linux/openbot.apparmor /etc/apparmor.d/openbot
sudo systemctl reload apparmor
无屏幕的服务器可以装成常驻服务：
curl -fsSL https://raw.githubusercontent.com/nightly-labs/openbot/main/scripts/install-server.sh | sudo bash
sudo openbot login
Docker 方式（seccomp profile 让 Electron 沙箱保持开启）：
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 ...
本地脚本 API 的最小示例（需先在智能体设置的 Permissions 里打开 Local scripts）：
alias openbot-cli='node "/Applications/OpenBot.app/Contents/Resources/cli/openbot-cli.mjs"'
openbot-cli list # 列出开启了 Local scripts 的智能体
openbot-cli run "Ada" "跑一遍测试并告诉我哪里失败" --wait
openbot-cli run "Ada" - --wait --json < task.md # 从 stdin 读任务，输出单个 JSON
openbot-cli status "Ada" <deliveryId> # 查询早前 run 留下的投递
openbot-cli agent set-account "Ada" <accountId> # 或 "default"
openbot-cli agent new-chat "Ada" # 清空聊天，保留智能体设置
退出码语义清晰，适合脚本编排：0 完成；1 轮次失败/被停止/被取消/请求被拒；2 命令行错误或两个智能体重名；3 智能体在等人（问题、审批或浏览器接管）；4 等待超时（智能体继续跑）；5 OpenBot 未运行、无智能体开启 Local scripts 或找不到智能体。--timeout（默认 30m）只停止等待，不停止工作。
七、横向对比
| 维度 | OpenBot | Grok Bot | Claude Code / Codex CLI 裸用 | 自建框架（LangGraph 类） |
|---|---|---|---|---|
| 部署位置 | 本机桌面 / 家用服务器 | 厂商云电脑 | 本机终端 | 用户自建 |
| 模型选择 | 逐智能体自选（7 家 + 本地） | 托管 | 单一厂商 | 用户自选 |
| 多智能体协调 | channel + 队列 + 交接 + 例程流 | 平台内建 | 无 | 代码编排 |
| 持久化工作区 | 有（每智能体独立） | 有（云端） | 无（会话级） | 需自建 |
| 崩溃恢复 | SQLite 单一事实源 + 队列持久化 | 平台保证 | 无 | 需自建 |
| 上下文治理 | 32k 字符 handoff 预算 + 零模型检索 | 不透明 | 无 | 需自建 |
| 权限模型 | 默认 Full access（非安全边界） | 平台审批 | 各自沙箱 | 需自建 |
| License | PolyForm Noncommercial（商用需授权） | 闭源订阅 | 各自条款 | 各异 |
| 成本 | 复用已有订阅 / 本地模型免费 | 订阅捆绑 | 已有订阅 | 模型 + 自建运维 |
| 离线可用 | 否（local-first ≠ offline） | 否 | 否 | 取决于模型 |
八、局限、风险与社区观察
维护活跃度：非常高。仓库创建于 2026-08-12，到 2026-10-29 已发到 v0.54.0，10 月 28–29 两天内连发 v0.53.0 / v0.53.1 / v0.53.2 / v0.54.0 四个版本，PR 编号已到 #3847 量级。提交者集中在少数几位（Sniezka1927、NorbertBodziony、nrb-dev、jemitoburt 等），属于「小团队高频迭代」形态——好处是响应快，风险是巴士因子低。
License 风险（最重要）：PolyForm Noncommercial 1.0.0 明确禁止商业使用，商用需向版权方单独购买（Settings → Billing 里的 Starter 1 用户 / Team 2–10 用户，或联系 licenses@openbot.run）。只有 ≤ v0.1.11 的版本仍是 Apache-2.0。任何公司内部把它用于生产开发流程，都需要先解决授权问题。此外，贡献者需签署 CLA，把版权转让给 Synthetify Labs——这对想 fork 后自立的团队是一个需要提前评估的点。
安全风险：默认 danger-full-access + approvalPolicy: never 是最大的风险面。官方自己声明「完全本地访问是产品决策，不是安全边界」。这意味着：不要把它指向包含敏感凭据的目录；不要在没有备份的机器上运行；不要把不受信任的任务交给它。同时注意「本地优先不等于离线」——Codex 连 OpenAI、Claude 连 Anthropic、Grok 连 xAI、Gemini 连 Google、Cursor 连 Cursor、Cline 连 Cline，访问的网页会联网，安装的插件可能连自己的服务。
平台粗糙处：Linux 上无语音提示；远程桌面只在 x64 AppImage 的 X11 会话下可用（Wayland 不支持，arm64 不含）；Ubuntu 23.10+ / Debian 13 需要手工装 AppArmor profile。Gemini 登录需要桌面浏览器与 xdg-utils，因为 Google 把回调发到 127.0.0.1。
生产可用性：官方定位是「development preview」。它已经具备自托管服务器（Ubuntu + systemd）、Docker 容器、AWS ECS 三种部署形态，以及 macOS 多租户 Host Manager（openbot-host setup --create-user client-acme），说明工程上在往可运维方向走；但预览版定位 + 默认全权限的组合，意味着当前更适合个人开发者与愿意承担风险的小团队。
待确认项：官方未公布端到端任务完成率、多智能体协作的 token 成本对比、以及 Computer Use 在真实业务任务上的成功率基准。文档中提到的「Benchmark v2 在 claude-haiku-5-5 上测量了记忆评审质量」未给出具体数值。
九、小结与行动建议
- 先解决授权再谈落地。若用于公司业务，PolyForm Noncommercial 是硬门槛，需先购买商业授权或评估替代方案；个人非商业使用则无此问题。
- 把第一次运行放在可丢弃的环境里。默认 Full access 意味着「丢文件」是可接受成本的一部分。建议先在专用机器或虚拟机、有完整备份的目录下试跑，再考虑接入真实项目。
- 优先用它的协调层，而不是把它当聊天窗口。OpenBot 的差异化在 channel + 队列 + 例程 + 交接；如果只是想要一个更好看的 Claude Code 界面，收益有限。真正值得投入的是把「研究 → 编码 → 测试 → 评审」这类多段流程拆成多智能体接力。
- 用本地脚本 API 把它接进你已有的自动化。
openbot-cli run ... --wait加清晰的退出码语义（尤其3= 等人、4= 超时但继续跑），可以低成本地把智能体嵌进 CI、构建脚本或内部工具链，而不必改造成 OpenBot 内部流程。 - 关注两件事的演进：一是权限模型是否从「全权限」走向可配置的逐动作审批（这决定它能否进入企业环境）；二是 License 是否放宽。这两点比功能列表更能决定它的长期价值。
数据来源与获取日期：GitHub Trending daily（2026-10-29 抓取）、GitHub REST API /repos/nightly-labs/openbot 与 /releases（2026-10-30 查询）、仓库内 README.md、SECURITY.md、docs/architecture/*（structure / agents / providers / browser / computer-use / channels-and-messaging / servers / skills-and-plugins / integrations / events）、docs/automation.md（2026-10-30 读取），以及 openbot.run 官方站点与第三方评测页面（heatdrop.ai、everydev.ai、hysenlabs.com、mindstudio.ai，2026-10-30 检索）。文中所有 star 数、涨星数、版本号、字符预算与上限数字均来自上述来源；官方未公布的效果指标已标注「待确认」。
读者留言
COMMENTS 暂无还没有留言，来说第一句？