OpenBot：可自托管的 AI 同事模板

OpenBot 想解决的，是企业把 AI 助手接进真实业务后的一道难题：它能操作浏览器、文件和内部工具，但谁来决定它能做什么，又如何留下可追查的记录？项目给出的答案是自托管、统一权限网关和可人工接管的工作环境。

它更适合被看成企业 AI 工作台的代码底座。目前仍是 Beta，拿来就能跑的范围主要面向本机体验。对前端和全栈开发者，值得看的不是又一个聊天界面，而是聊天、工具调用、权限和审计如何接成一条链路。

先认清交付物：这是模板，接手后要自己维护

OpenBot 明确把自己定位为模板。仓库里的 workspace 都是 private，没有可直接依赖的发布包，也没有注册即用的托管版 OpenBot。团队需要克隆仓库，把 examples/ 下的示例租户包换成自己的 Bot、频道和技能，再部署运行。

默认有 General Assistant 和 Knowledge 两个助手；配置端点后可以加入 Risk Analyst。examples/fintech/catalog/ 还有 10 个职责较窄的示例，例如检查报销是否符合制度、从会议记录提取待办、整理发布说明。它们的价值是展示如何把职责写进配置，而不是证明这些任务已经达到生产可用水平。

接入层使用 AG-UI，也就是 Agent 与用户界面交互的开放协议。LangGraph、Mastra、CrewAI、Pydantic AI、Google ADK 或手写 Agent，只要提供相应端点，就能作为 Bot 接入。前端因此不必为每个 Agent 框架重做一套交互。

统一协议解决接入问题，统一网关才负责约束行动。

这里还有一层部署边界：OpenBot 可自托管，不代表默认不使用外部服务。对话持久化和记忆依赖 CopilotKit Intelligence，它可以使用托管服务，也可以自托管；模型没有随项目附送，需要管理员提供凭证。原文中的概念验证 Bot 使用 OpenAI，LangGraph Bot 支持 OpenAI、Anthropic 或 Google。

为什么权限要在调用工具之前判定

OpenBot 最有分量的设计，是把浏览器、文件、Shell、MCP 和组件调用放进同一个治理入口。

服务器先从自己持有的快照解析目标，再检查策略、写入审计记录，最后才调用执行环境。原文强调，执行前必须已经有记录；动作结束后，审计界面再呈现允许、拒绝或失败的结果。

策略使用 CEL 表达式，可以读取 tool.name、bot.id、actor.id、page.host、command、file.*、mcp.* 和 initiator.* 等字段。最后一项尤其有用：同一个动作，由人主动发起和由定时任务发起，可以获得不同待遇。

规则执行顺序也很明确：deny 优先于 allow，没有策略就不允许，规则损坏就拒绝。大白话理解，就是不能因为配置漏了、写错了，反而放开权限。

执行环境也支持接管。默认由 supervisor 给每个人分配容器，各 Bot 使用各自的目录和浏览器配置；勾选 Isolated 后，某个 Bot 可以独占容器。宿主机支持时，还能用 COMPUTER_RUNTIME=runsc 启用 gVisor。遇到登录或 2FA，用户可以接管；人工操作期间，Bot 的动作会被拒绝，不会排队等着补执行。

MCP 同样受控。未知工具和自定义服务器工具按写操作处理，但目录中的工具如果没有被标成写操作，会被归类为读操作。因此，工具目录本身也是需要审核的权限配置，不能只盯着模型提示词。

远程 Agent 的地址还要单独校验。下面这项配置允许注册指定的私有端点：

AGENT_ENDPOINT_ALLOWED_HOSTS=agents.internal,10.0.0.42:9000

注意第二项带有端口，只允许对应端口；第一项覆盖该主机的任意端口。匹配是精确匹配，不支持通配符，写成 URL 或包含 * 会导致启动失败。这份名单只管 Agent 端点，也不等于授予 Agent 工具权限。

本机跑通不难，交给同事前还有几道配置关

本地开发需要 Docker、Bun 1.4+、CopilotKit Intelligence 项目及许可，以及模型 Key。原文特意指出，部分测试在 Bun 1.3 上会失败。

先执行 cp .env.example .env 和 bun install。如果使用新的托管 Intelligence 项目，初始化流程如下：

npx --yes copilotkit@latest login
npx --yes copilotkit@latest project select
bun scripts/setup-learning.ts

关键是最后一行：它会配置运行时 Key，创建或复用名为 openbot 的 Learning 容器，并写入 .env，同时保留已有 OpenBot Key 和自定义容器分配。但它不会写入 INTELLIGENCE_GATEWAY_WS_URL，使用自托管 Intelligence 时需要自行核对。

补齐 OPENAI_API_KEY 后，用 bash scripts/start.sh 启动。脚本负责 Docker 服务、数据库迁移、API、定时任务 worker 和应用的健康检查。本地开发时 API 在 3001，页面在 http://localhost:3010。

单镜像部署则不同：应用、API、浏览器以及可选 PostgreSQL 都放进一个镜像，对外统一使用 3001。EMBEDDED_POSTGRES=on 启用内置数据库；已有数据库则使用 DATABASE_URL。镜像的 latest 指向最新发布，也可以用 :v0.0.9 这样的标签固定版本。

Intelligence 的 Mac 本地体验支持免费 Developer plan，要求 Docker Desktop，属于预览用途。许可有效期为 30 天，账户状态正常时可通过 npx copilotkit@latest local renew 续期。连接命令 npx copilotkit@latest local connect 会写入 CPK_INTELLIGENCE_API_KEY 等配置；旧的 INTELLIGENCE_API_KEY 仍兼容，两者都有值时优先使用前者。

最容易误用的是 .env.example 默认开启 OPENBOT_SINGLE_USER=true：所有请求都被当成同一位管理员。给其他人访问前，必须关闭它并配置登录。项目支持 Google、Microsoft、Okta，以及运行时注册的 SAML、OpenID Connect；INITIAL_ADMIN_EMAILS 决定首批管理员。

凭证也不能沿用演示配置。示例 KEY_ENCRYPTION_KEY 是公开值，本地体验可用，正式部署应通过 openssl rand -base64 32 自行生成，并通过 /admin/credentials 保存业务凭证。

我的判断

我认可它把权限判断放在模型之外。提示词可以告诉 Agent 不要做某件事，服务器策略则能在执行入口直接拒绝。对接触真实账号和内部系统的助手，这两层不能互相替代。

但原文是一份项目说明，没有给出安全评估、并发性能、维护成本，或与其他方案的对照数据。统一网关是明确的设计主张，不能据此认定所有绕过路径都已消除。原文也承认执行环境存在更底层、受 token 保护的服务端点，要求保持私有，不能绕过网关调用。

自托管也有成本。团队接手的不只是 React 界面，还包括数据库、浏览器容器、身份系统、策略、审计和 Intelligence。相较于直接使用托管助手，它增加了修改空间，也增加了运维责任。若只是内部知识问答，是否需要为每个人准备真实浏览器，应先看任务需求。

组件能力值得前端开发者关注：编译后的 React 组件位于 app/src/components/gallery/，沙箱组件可在 /admin/playground 编写并发布，无需部署。每次调用都检查组件是否存在、已发布、向该 Bot 开放，数据函数按组件授权。这比只让模型返回一段 UI 描述更完整，但原文没有展开沙箱的具体隔离机制，不能替它补上安全结论。

能拿来做什么

• 评估浏览器助手时，按原文顺序做一次验证：让 Bot 操作表单，在 /admin/audit 查看记录，再到 /admin/boundaries 加入 deny 规则重试，确认拒绝实际发生。
• 已有 LangGraph 或其他 Agent 服务的团队，可以先接一个 AG-UI 端点，验证消息、组件和权限链路，再决定是否迁移更多助手。
• 做 React AI 工作台时，可以借鉴组件逐次授权的设计，让服务器决定哪些组件和数据函数可用，并在调用时复查。
• 启用定时任务前，先区分人工请求与计划执行的权限。原文设有 15 分钟最短间隔、最多 20 个启用任务、连续失败 10 次自动关闭，但业务动作仍需要自己的策略。