4 天 1593 star：OpenBot 给每个 AI 同事一台「自己的电脑」

你终于说服老板，让 AI 帮你处理那些重复的网页操作：填表、查数据、发消息。然后你在浏览器里看到它用你的账号登录、打开了你的邮箱、点开了一封带附件的邮件。

那一刻你心里想的不是"真方便"，是"我刚才为什么给它这个权限"。

这是所有做 AI 自动化的人都会撞上的墙：Agent 能干活，但你不敢给钥匙。上周开源的一个项目，正面回答了这个问题的后半句——给了钥匙，怎么保证它不乱来。

每个 AI 同事，一台"自己的电脑"

OpenBot，CopilotKit 出品。CopilotKit 是做开源 Copilot 框架的团队（GitHub 上 CopilotKit 仓库有 1 万多 star），所以这不是个人玩具项目。仓库 8 月 17 日创建，到今天 1593 star、165 fork，MIT 协议，语言 TypeScript，状态栏醒目地写着 Alpha。

它的想法一句话能说清：给每个 AI Agent 一台独立的、属于自己的电脑——独立的浏览器和登录态、独立的文件目录、只有你授权的工具。它在这台电脑里干什么都行，但每一步动作都要过一道网关：先决策、再记录、最后才执行。

架构图上值得盯三秒的是中间那个"Gateway"。README 里有一句话我觉得是全文最值钱的：

“There is no path that acts without the record existing first.”——不存在不先留记录就行动的路径。

这句话和我们平时写代码的习惯是反着的。我们通常先执行、再打日志，日志丢了还能补；它是先写审计行，动作根本没发生之前，记录已经在了。审计不是事后追责的补丁，是动作能否发生的前置条件。这个顺序的差别，就是"能用的 Agent"和"敢放权的 Agent"之间的差别。

一次动作的一生

我把它的执行路径画成了时序图，你跟着走一遍就明白这套设计为什么成立：

Bot 想用浏览器、文件或者 shell，唯一的入口是网关。网关做三件事：

解析目标——它要访问的 URL、要写的文件，都要过一遍目标检查，和浏览器导航用的是同一套校验，不是 Bot 说啥就是啥。

策略评估——规则用 CEL 表达式写，能检查 tool.name、intent、bot.id、actor.id、page.url、page.host、element.*、file.*、mcp.* 这些上下文。三个细节值得抄：deny 规则永远先于 allow 求值；缺策略 = 拒绝（fail closed，不是默认放行）；一条写坏的规则导致的后果是"拒绝执行"，而不是"放开执行"。

写审计行，然后才动手——permitted、refused、failed 三种结果全部入 PostgreSQL，每次拒绝都带着触发它的那条规则名。

执行发生在 Bot 自己的电脑上：supervisor 给每个 Bot 分配独立容器、独立 /workspace 卷、独立浏览器 profile，宿主机支持时可以开 gVisor（COMPUTER_RUNTIME=runsc）再套一层内核隔离。电脑默认只绑 127.0.0.1，容器间靠 token 互认，知道端口也摸不进来。

到这里它还只是个"权限控制做得比较细的沙箱"。真正让它和别的方案拉开差距的，是下面这个设计。

撞到边界，交还人类，而不是悄悄绕过

你给 Bot 配了一个带登录态的浏览器，它填表填到一半，弹出了 2FA 验证码。市面上大多数 Agent 的处理方式是：尝试绕过、失败重试、或者卡死。

OpenBot 的处理是请求接管：Bot 在同一个面板里把手交给你，你输入验证码、点完确认，再交还给它。整个交接过程记录为 computer.help_requested、computer.control_taken、computer.control_released 三个事件。更关键的是，人在驾驶期间，Bot 的动作一律被拒绝，而不是排队等着继续执行——防止它趁你点验证码的时候偷偷把刚才被拒的操作做了。

配合这个机制还有两个细节：

• 密钥不进转录：Bot 请求密钥时，审计只记录"请求了密钥、长度是多少"，不记录密钥内容，聊天记录里翻不出来。
• MCP 默认按写对待：内置了 Atlassian、Box、Slack、Salesforce、ServiceNow 的工具目录，自定义 MCP server 要过 URL 检查，而且任何没被明确归类为"读"的工具，一律按"写"处理。

这套"边界 + 接管"的组合，解决的其实是 Agent 落地的信任问题：你不需要 100% 信任模型，你只需要信任"它越界时我会被叫醒"。

和现有方案比，差在哪

自写脚本是"单点信任"：你把浏览器、账号、文件全托付给一段代码，它干没干越界的事，你事后才知道。云端方案省心，但你的数据、你的登录态在别人手里，权限策略是黑盒。框架自接工具，权限、审计、隔离全要自己造轮子——大多数人造到一半就放弃了。

OpenBot 的生态位是"自己部署 + 可编程治理"：你保留数据所有权，把信任问题交给策略语言和审计日志，而不是交给模型的自觉。协议层它押注 AG-UI（Agent 对用户交互的开放协议），LangGraph、Mastra、CrewAI、Pydantic AI、Google ADK 或者手写的 Agent，只要说 AG-UI 就能接进来当同事。这也是它敢说"bring your own agent"的原因——绑定的是协议，不是框架。

能带走的：可信 Agent 的四件套

OpenBot 这套设计不一定要整套搬，但四个原则可以直接抄进你自己的 Agent 项目：

1. 每 Agent 独立身份和沙箱。 不共享登录态、不共享 workspace。一个容器、一套凭据、一个 profile，出事只炸一个。对应到你的项目：至少给每个 Agent 独立的 API key 和临时目录，别复用同一个生产账号。

2. 策略先于代码。 用声明式规则（CEL 或者 JSON 策略文件）表达"能做什么"，deny 优先、缺省拒绝、坏规则拒绝执行。别把权限判断散落在工具函数里——散落的判断总有一天会漏掉一条路径。

3. 审计先于行动。 执行前先写一行审计，动作结果回填。你想要的不是"出事后能查到日志"，而是"查不到记录的动作根本不该存在"。

4. 人工接管点。 给 2FA、登录墙、高权限操作预埋接管通道，人接管期间 Agent 动作必须被硬拒绝而不是排队。接管点做得好，是你敢放权的底气。

坦白说

• Alpha，README 自己说的：“Expect rough edges and bugs.” 4 天 1593 star 说明热度真，但别拿生产数据直接压上去。
• 默认配置其实没有认证：OPENBOT_DEV_NO_AUTH 模式下所有请求都是管理员，配好 Google OAuth 之前，别把它暴露在公网。
• 它依赖 CopilotKit Intelligence：线程和记忆存在外部服务（有免费版，也能自托管），不是纯本地闭门造车。
• 部署门槛：要 Docker + Bun 1.3+，官方说生产部署目前是单副本，高并发不是它现在的卖点。

想试的话

1
2
3
4
5
6
7
8
9

git clone https://github.com/CopilotKit/OpenBot
cd OpenBot
cp .env.example .env
npx --yes copilotkit@latest login
npx --yes copilotkit@latest project select   # 把 cpk- 开头的 key 写进 .env
npx --yes copilotkit@latest license --write
# .env 里填上 OPENAI_API_KEY，然后：
bun install
bash scripts/start.sh

打开 http://localhost:3010，两个建议的第一次试验：让 Bot 打开 news.ycombinator.com 念一下头条（体验"它的电脑"），再让它去填 httpbin.org 的表单，然后打开 /admin/audit 看它每一步留下的记录——把表单里的字段改成 browser.fill 之外的东西再试一次，看拒绝规则怎么工作。

给 AI 电脑，不给 AI 钥匙。给它一台看得见、管得住、随时能收回的电脑。 这可能是 2026 年 Agent 从"玩具"走向"同事"的必经之路。

搬砖程序员带你飞，专注 Golang / AI / 后端。每天一篇，讲清楚一个技术真相。