OpenBot 自托管 AI 同事：先审批后留痕，平替 Grok Bot

AI 先干了再补日志？
让 AI 干真活之前，先给它装一道闸门。
独立电脑 · 策略审批 · 全程审计

你见过那种“AI 同事”吗？它帮你点按钮、填表单、查资料，但你永远不知道它在你电脑上还点了什么。Grok Bot 把“AI 同事”这个概念带火了，可惜它是闭源的：虚拟机跑在人家服务器上，你看不见它干了啥，更别说自己改。

CopilotKit 开源了 OpenBot，4 天拿到 1,540 颗星。它是这么玩的：给每个 AI 同事发一台独立的电脑——一个装着 Chromium 的容器，有自己独立的浏览器登录态、独立的文件夹。AI 想干任何事，都要先过一道审批闸门，先写一行审计记录，才轮到真正动手。CEO 在 X 上官宣当天，帖子浏览量冲到 43.85 万。

项目亮点：

1. 每个 AI 同事一台隔离电脑：独立浏览器登录态 + 独立 workspace，互不串台  
2. 动作先决策后记录：没有“先干了再补日志”的路径，闸门就是动作本身  
3. 任何 AG-UI 框架都能接入：LangGraph、CrewAI、Mastra、Pydantic AI 都行，治理不绑框架  

01 背景：为什么需要治理

“AI 会自己上网办事”已经不是新鲜事，但能不能放心把账号交给它，一直是道坎。

xAI 的 Grok Bot 把答案做成“托管虚拟机”：AI 同事在云上有自己的电脑，登录态互相隔离。问题是这套东西完全闭源，你没法检查它到底怎么运行的，也没法在自己电脑上复现，更别说改一行策略。

另一边是 browser-use 这类浏览器自动化方案：直接驱动你自己电脑上的 Chrome，用的是你自己的 cookie 和你已经登录的会话。跑起来快，但出了事只能靠考古——翻聊天记录，猜是哪次工具调用出了问题，赌模型当时没说谎。

OpenBot 的解法跟两边都不一样：电脑是隔离的，每 bot 一个容器；代码是开源的，MIT 协议；但每个动作都要过一道审批 + 审计的闸门。用项目自己的话说，这是“一个能用你的工具的 agent，和一个你敢让它碰工具的 agent”之间的区别。

02 原理：审批与审计闸门

你（人）
│ 发消息
▼
server 网关（3001）—— 唯一入口
│ 1. 解析目标：从服务器自己存的页面快照里，找到 ref 指的那个元素
│ 绝不信任模型嘴里说的"我要点的是登录按钮"
│ 2. 评估策略：CEL 表达式，deny 优先于 allow，没有策略=全部拒绝
│ 3. 先写审计行，再放行
▼
agent-computer（4100）—— AI 的那台电脑
│ 一个容器，一个 Chromium，一个独立浏览器 profile
│ 一个 /workspace 文件夹（写不进容器外）
▼
audit 审计表（PostgreSQL）—— 允许/拒绝/失败，全留痕

整个过程一句话：AI 动手之前，先有决策；决策之前，先有记录。记录不是写在旁边的工作报告，而是动作必须穿过的门。

03 痛点场景：三个真实风险

工作中，但凡让 AI 代劳过任何“会留下痕迹”的事，都会遇到下面这些时刻：

痛点 1：让 AI 打开某个网页填个表单。 它在你自己的浏览器里登录着你的账号，一边填表一边把页面上所有能点的按钮都点了一遍。你事后翻浏览记录，根本不知道哪个点击是它干的、为什么干的。

痛点 2：AI 撞上 2FA 验证码。 你把自己手机收到的验证码粘到聊天窗口里发给它。结果验证码、你公司内部系统的账号密码，全都进了聊天记录，AI 服务商的日志里可能也有一份。

痛点 3：公司规定“AI 不能碰任何含 .env 的文件”。 你给 AI 配了一堆工具，结果它绕开规定，用 Enter 键提交了表单——你堵住了“点提交按钮”，没堵住“按回车”。规则是死的，绕路是活的。

OpenBot 就是为了解决这些问题而生的。

04 核心功能：六项能力

SKILL 1：每台 AI 电脑独立隔离

supervisor 服务会给每个 Bot 起一个独立容器，挂两个独立卷：一个存浏览器 profile（登录态），一个存 /workspace（工作文件）。容器加固拉满：丢掉所有 Capability、禁 new-privileges、进程数上限 512，宿主支持的话还能换 gVisor 沙箱。一个 AI 看到的登录态、写出的文件，另一个 AI 碰都碰不到。

关键优势：

• 账号互不串台：sales-bot 登录的邮箱，不会泄露给 code-bot  
• 出事了能一键 Reset：删掉这个容器的 profile，所有登录态归零  
• 端口只绑 127.0.0.1：知道端口号也连不进别人的浏览器  

SKILL 2：动作审批闸门（The Gateway）

server 层的 gateway 是唯一入口，一共干三件事，顺序固定：先从服务器自己缓存的页面快照里解析 ref 指向的真实元素，再跑一遍策略，最后写审计行、然后才动手。没有一条代码路径能“先执行再补记录”。

关键优势：

• 模型说的不算：它声称要点的“Submit”由服务器对照快照核验  
• 允许的动作失败了也会单独记一行：审计里“被放行”和“真的发生”是两种事件  
• 每个拒绝都带命中的规则原文，排障直接点对点  

SKILL 3：CEL 策略，fail-closed

策略用 CEL 表达式写，规则能匹配工具名、意图、Bot ID、操作人、页面 URL、元素属性、按键、文件路径、MCP 服务器等字段。deny 永远先于 allow 执行；策略为空 = 什么都不允许；某条规则写坏了，按“拒绝”处理而不是“放行”。

关键优势：

• 按效果写规则，不按工具名写：默认规则就是“禁止激活任何叫 submit 的东西 + 禁止按 Enter”，点击和回车两条提交路径一起堵  
• dry-run 模式：先只记录不拦截，拿真实流量验证规则再上线  
• 大小写不敏感匹配：拦“submit”也能拦“SUBMIT”  

SKILL 4：遇到坎就叫人（Take the wheel）

AI 撞上登录墙、2FA、验证码时，会主动请求帮助。人在同一个面板里接管浏览器，记录 computer.control_taken；干完该干的事再交回去，记录 computer.control_released。人在驾驶期间，AI 的所有动作一律拒绝而不是排队——两个司机开一辆车，AI 会在人填到一半时点“确认”。

关键优势：

• 只差一个密码时不用交整个浏览器：AI 可以只请求一个“秘密输入框”，人填完 AI 永远看不见内容  
• 交接全程留痕：审计能回答“哪个时间段是人类在驾驶”  
• 拒绝不是报错：AI 收到提示会等待，不会陷入重试循环  

SKILL 5：把秘密挡在模型视野外

审计记录里永远只有“某个字段被填了 N 个字符”，没有内容本身。人的输入走单独的 /human/* 路径，从键盘到浏览器，模型根本不在那条链路上。凭据入库前用 AES-GCM 加密，API 永不返回明文，审计事件自动脱敏。

关键优势：

• 密码、验证码、卡号不进聊天记录，不进模型上下文  
• 审计能看到“有人输入了真实凭据”这个事实，但拿不到值  
• 脱敏名单覆盖 access_token、authorization、password 等 30 多个键名  

SKILL 6：随便带你自己的 agent

只要是说 AG-UI 协议的端点，无论框架还是手写，都能注册成 AI 同事。内置的 PoC Bot（agent-bot）走 OpenAI chat-completions，还配了一个 LangGraph 版（agent-langgraph）。自定义端点的 URL 会用跟浏览器导航一样的规则校验，auth header 只存不读。

关键优势：

• 治理挂在协议上，不挂在框架上：换框架不用重写策略  
• 三个开箱同事只是配置不是代码：改 agents.yaml 就能加第四个  
• 同一个部署能同时跑不同框架的 agent  

05 实用场景：应用落地

CASE 1：公司内部报表网站的日常巡检

需求：运维每天要登录内部报表站，拉一份数据，归档。想交给 AI，但内部站绑定了公司 SSO，登录态很金贵，怕 AI 误点。

OpenBot 方案：

1. 用 /agents 建一个“报表助手”同事，给它配只读策略：只允许 navigate + read，deny 一切 click/type/write_file  
2. AI 的浏览器有自己的独立登录态，和你的浏览器互不相干  
3. 它打开报表页、读数据、写进自己的 /workspace，你随时去 /admin/audit 看它干了啥  

输出：

• 一份“允许了什么、拒绝了什么”的完整审计  
• AI 误点表单会被策略拦下来，理由写进拒绝记录  
• 员工自己的账号全程没被 AI 碰过  

CASE 2：对外网页表单的自动化填报

需求：市场部每天要在外部网站填一批报名表单。用浏览器自动化脚本写起来繁琐，交给 AI 又怕它填错字段提交。

OpenBot 方案：

1. 让 AI 先 computer_snapshot 拿到表单快照，用 ref 精确指认字段  
2. 写一条策略：只允许填这个域名下的表单，deny 提交按钮所在的页面之外的一切  
3. 填完它自己 computer_read 读回页面确认，把结果告诉你  
4. 万一它想提交到别处，网关按策略拒绝并留痕  

输出：

• 可追溯的填报过程，每一步都有审计行  
• AI 填完主动汇报“页面上现在显示什么”，不是只告诉你“我点了”  
• 字段值本身不进审计日志  

CASE 3：验证码和登录这类“人该干的事”

需求：AI 帮你跑一个需要扫码登录的流程，扫码这一步只能人来做。

OpenBot 方案：

1. AI 在扫码页调用 computer_request_help，说明卡在哪  
2. 你点接管，手机扫码，完事交回去，全程事件记入审计  
3. 如果需要的是短信验证码，AI 只会请求一个带字段 ref 的秘密输入框，不会要你交出整个浏览器  

输出：

• 人和 AI 的分工清晰：机器干的活机器干，人的动作人做  
• 验证码只在你键盘和页面之间走了一趟，模型、日志都碰不到  

06 安装步骤：快速上手

环境要求：

• Docker（跑 PostgreSQL、agent-computer、supervisor、内置 Bots）  
• Bun 1.3+  
• 一个 CopilotKit Intelligence 项目（有免费计划，也支持自托管）  
• 一个模型 key（PoC Bot 用 OpenAI；LangGraph Bot 可选 OpenAI/Anthropic/Google）  

安装命令：

# 1. 拉代码、配环境变量
git clone https://github.com/CopilotKit/OpenBot.git
cd OpenBot
cp .env.example .env

# 2. 登录 CopilotKit Intelligence，把 key 写进 .env
npx --yes copilotkit@latest login
npx --yes copilotkit@latest project select
npx --yes copilotkit@latest license --write

# 3. 填 .env 里的 OPENAI_API_KEY
vim .env

# 4. 一键起全栈
bun install
bash scripts/start.sh

脚本会依次拉起 Docker 服务、跑数据库迁移、启动 API server（3001）和前端（3010），然后做健康检查。

快速配置方面，默认是 OPENBOT_DEV_NO_AUTH，跳过登录，所有请求都当成管理员，本地体验够用。想上真实登录，配好四件套再启动：BETTER_AUTH_URL、BETTER_AUTH_SECRET、GOOGLE_OAUTH_CLIENT_ID、GOOGLE_OAUTH_CLIENT_SECRET，再在 INITIAL_ADMIN_EMAILS 里写第一批管理员邮箱。配置配一半服务会拒绝启动，不会半开着门。

07 技术架构：系统结构

数据流程图：

你 → app → server（解析身份、选同事）→ AG-UI 端点（agent-bot / 你的 Bot）
↓ 工具调用回传
server 网关：resolve → decide → record → act
↓
agent-computer（每 bot 独立容器 + 独立 Chromium）
↓
PostgreSQL 审计表（permitted / refused / failed）

技术栈选型：

层级	技术	特点
前端	React + Vite	频道列表、实时屏幕、admin 面板一套搞定
后端	Hono + Bun	轻量 API 运行时，类型安全
策略引擎	CEL（cel-js）	企业网关同款语言，规则可移植
浏览器驱动	Playwright aria-ref	ref 寻址不碰像素，填表单不需要视觉模型
存储	PostgreSQL + pgvector	数据、审计、凭据、知识全在一处
容器编排	dockerode + supervisor	只暴露四个动词，不转发任意 Docker API
线程/记忆	CopilotKit Intelligence	持久对话 + 实时网关

08 知名项目对比：横向评测

特性	OpenBot	Grok Bot	Claude Computer Use / browser-use	macos-harness
开源	✅ MIT	❌ 闭源	⚠️ 部分	✅ 开源
每 agent 独立电脑	✅ 独立容器	✅ 托管 VM	❌ 用你的浏览器	❌ 共享一台 Mac
动作级策略审批	✅ CEL fail-closed	⚠️ 托管策略	❌ 无	❌ 无
审计轨迹	✅ 允许/拒绝/失败全留痕	⚠️ 受限	❌ 靠回忆	❌ 无
人工接管	✅ 同面板交接	✅	❌	❌ 无
凭据不进模型	✅ 隔离路径	⚠️ 声称	❌ 会进上下文	❌
可自托管	✅ Docker Compose	❌	✅	✅
成熟度	⚠️ Alpha	✅ 商业产品	✅	⚠️ Alpha

09 适用人群：谁适合用

• 企业平台工程师：要给团队搭一套“AI 能干真活、但干不了越界活”的内部 agent 平台  
• 安全与合规负责人：需要回答“AI 上周对我的系统做了什么”这类问题，审计表就是答案  
• Agent 框架用户：已经在用 LangGraph / CrewAI / Mastra，想给现有 agent 加一层治理  
• 独立开发者：自托管代替闭源托管，数据留在自己的 PostgreSQL 里  
• AI 产品研究：想研究“agent 治理”到底怎么落地，这套代码是现成的参考实现  

10 项目亮点总结：五个亮点

1. 技术创新：把“治理”做成动作的必经之路——resolve → decide → record → act，四个环节只有一个入口  
2. 安全设计：SSRF 目标校验、三层路径隔离、CapDrop 全丢、loopback 绑定、秘密走独立路径，层层叠起来  
3. 易用性：docker compose 一条命令起全栈，三个内置同事开箱即用，加同事只是改 YAML  
4. 协议开放性：基于 AG-UI，任何框架的 agent 都能接入，治理不绑定厂商  
5. 生态背书：CopilotKit 出品，主仓库 3.6 万 Star，AG-UI 协议就是他们主导的  

11 参考资源

• 项目仓库： https://github.com/CopilotKit/OpenBot  
• 官网： https://copilotkit.ai/openbot  

总结

OpenBot 是一款自托管的 AI 同事平台，把“AI 能用你的工具”升级成“AI 敢让你碰它的工具”。它的核心不是那个浏览器，也不是那台容器，而是夹在两者之间的那道闸门：动作先过审批、先留记录，才轮到执行。

如果你也在折腾 AI Agent 的治理与审计，不妨到 云栈社区 一起交流。