OpenBot：CopilotKit 开源 AI 同事框架，每个 Agent 配一台独立电脑

先收藏，这个项目 3 天前刚开源，1266 颗星，思路值得认真看。

企业落 Agent，最怕的不是模型不够聪明，是不知道它做了什么、能不能让它做。一个能操作浏览器的 Agent 很酷，但如果它能登任何系统、执行任何操作、事后没人查得到，没人敢在生产环境用。

OpenBot（GitHub 1,266 星，MIT 协议，CopilotKit 出品，3 天前开源）给了这套问题的一个清晰解。核心定位一句话：AI 同事框架，每个 Agent 有自己的一台电脑（浏览器 + 文件 + 工具），每个动作在执行前决策、执行后审计。

它和昨天讲的 OneCLI 是同一波趋势下的不同解法，值得对比着看。

本文提纲

1. 它是什么：Agent 平台跑在你自己的基础设施里
2. 一个 Agent 一台电脑：隔离的真正含义
3. Gateway：唯一入口，动作先决策再执行
4. CEL 策略引擎：失败就拒绝，而非放行
5. Take the Wheel：人接管时 Agent 动不了
6. AG-UI 协议：框架无关的 Agent 接入
7. 六层治理设计
8. 与 OneCLI 的对比：两条路线，同一个方向

它是什么：Agent 平台跑在你自己的基础设施里

OpenBot 是一个跑在你自己基础设施里的企业 Agent 平台。Docker Compose 拉起全部组件，数据落在你自己的 PostgreSQL 里，模型你自己选--不附带任何模型，管理员提供凭据，加密存储，永不记录日志。

预置三个 Agent 作为示例配置（不是代码）：

• General Assistant：日常事务
• Knowledge：公司知识问答
• Risk Analyst：风险与合规

注意是"配置而非代码"--加新 Agent 是编辑 agents.yaml 或在 /agents 页面操作。这意味着扩展 Agent 不需要写代码，降低了运维门槛。

一个 Agent 一台电脑：隔离的真正含义

"每个 Agent 一台电脑"不是比喻，是字面意思：

graph TB
    subgraph HostMachine["Your Machine (Docker)"]
        Supervisor[Supervisor
manages computers]
        Computer1["Bot Computer 1
Chromium + /workspace + profile"]
        Computer2["Bot Computer 2
Chromium + /workspace + profile"]
        ComputerN["Bot Computer N
..."]
        Gateway[Server Gateway
only way in]
    end
    Bot["AG-UI Bot"] -->|tool call| Gateway
    Gateway -->|resolve + decide + audit| Gateway
    Gateway -->|only if allowed| Computer1
    Gateway --> Computer2

    style Bot fill:#FF6B6B,color:#000000
    style Gateway fill:#FFEAA7,color:#000000
    style Supervisor fill:#4ECDC4,color:#000000
    style Computer1 fill:#45B7D1,color:#000000
    style Computer2 fill:#45B7D1,color:#000000
    style ComputerN fill:#45B7D1,color:#000000

每个 Bot 有自己独立的容器，里面装着自己的 Chromium 浏览器、/workspace 卷和浏览器 profile。这意味着：

• 每个 Agent 有自己的登录态、自己的 cookie、自己的会话
• Agent 之间互相隔离，一个被攻破不影响另一个
• 可以用 COMPUTER_RUNTIME=runsc 在 gVisor 下跑容器，加强内核级隔离
• 计算机绑定 127.0.0.1，需要 per-container token--光知道端口号也连不进去

这和 OneCLI 的"一人一 Agent 一沙盒"是同一个思路，但 OpenBot 把"电脑"这个概念做得更完整--不只是文件系统加 shell，还有真实的浏览器和登录态。

Gateway：唯一入口，动作先决策再执行

这是 OpenBot 最核心的设计，文档原话：

Anything a Bot does to a computer, a file, an MCP server or a component goes through one gateway that decides and records it.

Gateway 的工作流程是严格四步：

1. Resolve：从 server 端快照解析目标（不是信任 Agent 传来的地址）
2. Decide：按策略评估是否允许
3. Record：写一条审计记录（此时动作还没执行）
4. Act / Refuse：允许才调用 computer 执行，拒绝则返回触发的规则

关键设计：审计记录在执行前写入。这不是"执行后记录"的日志，而是"先记录再执行"的事前审计。即使执行失败或被中断，记录已存在。这回应了文档提到的一个痛点："多数停滞的 AI 试点项目，根因是无法回答数据去了哪里"。

Gateway 是 Agent 操作计算机、文件、MCP server 和组件的唯一入口。没有绕过 Gateway 直接操作计算机的路径。计算机虽然也暴露了低层的 token 保护的 service endpoint，但文档明确警告："keep them private and do not use them to bypass the gateway."

CEL 策略引擎：失败就拒绝，而非放行

策略规则用 CEL（Common Expression Language）写，可以检查这些字段：

• tool.name：工具名
• intent：意图
• bot.id：哪个 Bot
• actor.id：哪个用户
• page.url / page.host：浏览器目标
• element.*：页面元素
• key / file.* / mcp.*：密钥、文件、MCP 操作

策略执行有三条铁律：

Deny 先于 allow 评估。 先检查拒绝规则，再检查允许规则。一个动作如果同时匹配 deny 和 allow，deny 赢。

缺少策略时什么都不允许。 没有 AGENT_COMPUTER_POLICY 不是"全开"，而是"全关"。这是 fail-closed 设计。

规则出错时拒绝而非放行。 一条写坏的 CEL 规则不会意外打开权限，而是让对应操作被拒绝。

这三条放在一起，构成了一个保守的安全态势：不确定能不能做的，一律拒绝。对比很多系统"没配策略就默认允许"的做法，这个设计是企业级 Agent 该有的态度。

Take the Wheel：人接管时 Agent 动不了

"Take the Wheel"是 OpenBot 最有画面感的功能。Bot 在浏览器里操作遇到登录墙或 2FA 提示时，会主动求助。人接管控制：

• 控制权在同一个 panel 里交接
• 接管记录为 computer.help_requested -> computer.control_taken -> computer.control_released
• 人在驾驶时，Bot 的动作被拒绝而非排队--人操作期间 Agent 不能偷偷干别的

这个设计解决了 Agent 操控浏览器的一个硬问题：Agent 没法过 2FA，也没法判断"这个登录页是不是钓鱼站"。让人在需要时直接接管，不丢上下文，完了再交回去。

对比"Agent 发邮件问你 2FA 码是多少"这种做法，接管模式安全得多--你直接在浏览器里输，2FA 码不进对话记录。

AG-UI 协议：框架无关的 Agent 接入

OpenBot 不绑死某个 Agent 框架。任何能说 AG-UI 协议的 endpoint 都是一个 Bot。AG-UI 是 CopilotKit 主导的开放协议，定位是"Agent 与用户交互的协议层"。

CopilotKit 对三个协议的定位划分很清晰：

协议	层次	职责
MCP	Context	Agent 怎么获取工具和外部知识
A2A	Coordination	Agent 之间怎么协调交接
AG-UI	Interaction	工作怎么变成人能看、能质疑、能中断的东西

实践中，LangGraph、Mastra、CrewAI、Pydantic AI、Google ADK 或手写的 Agent，到 OpenBot 里都长一个样--一个 AG-UI endpoint。治理逻辑跑在协议层而非框架层，换框架不影响治理。

这在架构层面很有意义：治理和 Agent 实现解耦，治理层成了基础设施，Agent 成了可替换的前端。和 deepagents 的"Backend 协议化"、OneCLI 的"Sandbox Supervisor vendor-neutral"是同一思路：把可变部分和不可变部分分层。

六层治理设计

把 OpenBot 的治理设计梳理出来，一共有六个层面：

1. 计算隔离：一 Bot 一容器，独立 Chromium + workspace + profile。gVisor 可选。

2. 动作网关：唯一入口，resolve -> decide -> record -> act。审计事前写入，不可绕过。

3. CEL 策略：deny 优先、fail-closed、规则出错拒绝。可检查工具、意图、Bot、用户、URL、元素、文件、MCP 字段。

4. 人接管：2FA/登录墙时人接管，期间 Agent 动作拒绝执行。事件全程记录。

5. 凭据保护：密钥加密存储，API 不返回，审计事件脱敏。密钥长度记录但不记内容，transcript 里看不到真实凭据。

6. 组件治理：React 组件（Generative UI）需经 server 确认存在、已发布、且对该 Bot 未设禁令才可用。沙盒组件在 /admin/playground 里写，发布不需要部署。数据函数按组件授权。

这六层叠起来，构成了一个"不信任 Agent、但不阻碍 Agent 工作"的治理体系。

与 OneCLI 的对比：两条路线，同一个方向

昨天拆了 OneCLI，今天拆 OpenBot，两个项目都在解决"团队级安全 Agent"问题，但路线不同：

维度	OneCLI	OpenBot
核心模型	一人一 Agent	一 Bot 一电脑
隔离单元	沙盒（文件系统 + shell）	容器（Chromium + workspace + profile）
密钥保护	Rust Gateway 做 MITM 凭据注入	Server Gateway 加密存储 + 脱敏审计
策略层	Gateway 外部策略强制	CEL 规则引擎，fail-closed
人介入	Slack 内审批门	浏览器接管（Take the Wheel）
协议	自有协议	AG-UI 开放协议，框架无关
触达方式	Slack / Dashboard	Channel + 实时屏幕观看
技术栈	TypeScript + Rust	TypeScript + Bun
许可	Apache-2.0 + 企业许可	MIT
YC 背书	YC S26	CopilotKit 自有产品

两者设计哲学的差异很清晰：

OneCLI 侧重密钥。它的核心问题是"Agent 拿到生产密钥跑了怎么办"，解法是 Rust Gateway 做凭据注入，密钥永远不出保险箱。触发场景偏向"Agent 调 API"。

OpenBot 侧重操作。它的核心问题是"Agent 在浏览器里做了什么怎么办"，解法是 Gateway 做事前决策加事后审计。触发场景偏向"Agent 操作 UI"。

这不是非此即彼，而是两个不同场景的正交需求。一个偏 API 调用安全，一个偏浏览器操作安全。理想的企业 Agent 基础设施可能需要两者都有。

还有一个差异值得注意：OpenBot 是 MIT，OneCLI 是 Apache-2.0 加企业许可。MIT 更宽松，没有 copyleft 和商业限制，对自托管更友好。但 OpenBot 依赖 CopilotKit Intelligence 做持久线程和记忆，这是个外部依赖；OneCLI 的 Runner 是纯出站、不碰数据库，架构上更独立。

三个值得借鉴的设计

抛开对比，OpenBot 有三个设计值得单独记一下：

审计记录事前写入。 多数系统的审计日志是"执行后记录"，出了问题才查。OpenBot 的"先写记录再执行"意味着即使执行崩溃，你也知道 Agent 试图做什么。这个时序设计改变了审计日志的性质--从"事后追责"变成"事前留痕"。

失败就拒绝而非放行。 放在策略引擎里这是安全底线，放在整个系统设计里这是个态度：不确定的事情先拒绝。很多安全事故不是策略没写好，是策略没匹配上时默认允许。

人在驾驶时 Agent 动作拒绝执行。 不是"排队等会儿再试"，是直接拒绝。这防止了人在接管处理 2FA 时，Agent 在后台偷偷执行其他操作。这是对"人机协同"的一个严肃思考--协同不是简单的"人忙时 Agent 歇着"。

参考文档与链接

• GitHub: CopilotKit/OpenBot - MIT 协议，1,266 星，TypeScript + Bun，3 天前开源
• OpenBot 官网 - 企业 Agent 平台介绍，含预置 Agent 角色和使用场景
• OpenBot 架构文档 - 八个服务组件的详细说明
• AG-UI 协议 - Agent-User Interaction Protocol，CopilotKit 主导的开放标准
• OpenBot 配置文档 - 环境变量、策略、Docker 配置完整参考
• CopilotKit - OpenBot 的母公司，AG-UI 协议的发起者和维护者
• OneCLI 文章 - 上一篇拆解的团队级 Agent Harness，可对照阅读

---

作者: itech001 来源: 公众号：AI人工智能时代 网站: https://www.theaiera.cn/ 每日分享最前沿的AI新闻资讯和技术研究。

本文首发于 AI人工智能时代，转载请注明出处。