本文内容
OpenBot 评测：自托管 AI 同事真正需要什么
AI 同事需要的不只是浏览器和职位名称
OpenBot 是 CopilotKit 发布的 MIT 许可模板，用于在你控制的基础设施上运行 AI 同事。它把智能体界面、浏览器计算环境、文件、命令行和 MCP 集成，与服务端的策略检查及审计网关结合起来。模型由你提供，系统也由你负责运维。
对于需要比成品助手更多控制权的团队，这个方向值得关注。但它不等于开箱即用、完全离线或自动安全的 Grok Bot 替代品。当前 OpenBot README 明确将它定义为处于早期阶段的模板，而不是由他人代为运营的成熟产品。
我们的建议是：当可配置权限和部署控制权确实属于需求时，选一个范围明确、有人监督的业务流程来评估。不要仅仅因为源代码免费就决定采用。
评估方法：基于 OpenBot 提交 1c7bd923fd1ec14ef15f7d6ab6e33ad73c72f2a4 的文档审阅，核查日期为 2026 年 9 月 10 日。我们没有实际部署 OpenBot，也没有开展渗透测试。下文的例子和试点标准是建议方案，不是实测产品结果。
OpenBot 提供了什么？
示例包定义了三个角色：负责日常工作的 General Assistant、回答企业知识问题的 Knowledge，以及处理风险相关任务的 Risk Analyst。这些是可配置角色，不是经过独立验证的三位专家。Risk Analyst 这个名称既不能证明合规能力，也不会自动授予决策权。
AI 同事可以使用保留登录状态的浏览器、处理文件并调用获准使用的工具。当前 MCP 目录包含 Google Drive 和 Notion。平台接受使用 AG-UI 协议的智能体，因此你可以接入受支持的框架或自己的兼容端点，而不是把 OpenBot 当作一个语言模型。
在界面中填写名称、职位和工作指令，只是最容易的部分。模型接入、端点配置、权限、数据源和验收测试仍然需要负责人。当前部署文档还区分了未配置默认智能体端点时，哪些示例角色能够使用。
关键设计：先检查策略，再记审计，最后执行
OpenBot 架构文档 把动作控制放在服务器上，而不是放进模型提示词。对于经由该路径发出的计算机操作，网关先解析目标、评估策略、写入决策记录，随后才转发获准动作。执行失败时还会产生额外记录。
智能体请求 → 解析目标 → 评估策略 → 记录决策 → 执行或拒绝
这比要求模型“谨慎操作”更有依据。审查者可以看到具体是哪条规则允许或拒绝了动作，而不必事后猜测助手的解释是否可信。
但一条授权记录不能证明业务结果正确。网关记账也不会让外部写操作自动具备原子性、可撤销性或安全重试能力。即使两次请求都有审计记录，重复创建供应商仍然是错误。这些业务属性需要单独设计。
这个边界还只覆盖通过平台转发的动作。不能把它理解为：任意代码或独立运行的智能体端点，绝不可能从其他路径执行操作。
OpenBot 默认拒绝所有动作吗？
策略评估器在没有授权时拒绝操作，但随附的启动策略明确允许所有动作。这是两件不同的事。
架构文档写明：策略缺失或为空时不允许动作；拒绝规则优先；错误的拒绝表达式导致拒绝；错误的允许表达式不会授予权限。同时，启动时会提供包含 deny: [] 和 allow: ["true"] 的明确策略，除非环境变量或管理员保存的策略替换了它。
因此，“没有策略就不执行”不代表新安装已经具备严格的企业规则。连接公司账户之前，应当替换宽松的启动配置，并分别验证允许与拒绝的结果。
OpenBot 使用 Common Expression Language（CEL） 编写策略。CEL 是嵌入式表达式语言，不是向另一个模型提问。它可以让规则针对动作上下文进行检查和测试。不过，规则质量仍然取决于应用提供了哪些字段，以及团队实际写下了什么条件。
工具连接与授权之间的区别，可以参考 为什么 MCP 不是安全边界。
每个 AI 同事都有独立隔离环境吗？
隔离效果取决于实际部署方式。 配置了 supervisor 时，每个 Bot 会获得独立的计算机容器、工作区卷和 Chromium 配置文件。没有它时，多个 Bot 可以共享所配置的计算机。
这一点很重要，因为当前 OpenBot 部署指南 还提供了不包含 supervisor 的单容器镜像。在这种模式下，Bot 共享浏览器、文件和登录状态。文档明确提醒：不能把这种共享环境当成不同租户之间的隔离边界。
批准部署之前，要问清楚实际运行的是哪种架构，而不是只确认 README 提到了容器。换一个 Bot 名称不会产生安全边界。独立容器也不会自动限制它能够访问的网络目标或外部账户。
这与 Ramp Inspect 每次编程会话使用可丢弃环境 的模式不同。OpenBot 的持久化同事配置和工作区，需要专门的保留、重置及账户撤权流程。如果需要的是隔离执行平台，而不是完整的 AI 同事应用，可以比较 OpenSandbox。
遇到登录或双因素认证时会发生什么？
OpenBot 文档描述了同一浏览器面板中的人工接管机制。用户接过控制权，完成登录或其他需要关注的步骤，再把控制权交回。人工控制期间，Bot 的浏览器动作会被拒绝，而不是排队等待之后执行。
这是一条有用的交互规则。用户修改页面或输入凭据时，系统不会积累一批等待运行的 Bot 动作。但交回控制权，并不等于批准 Bot 随后的所有行为。
专门的秘密输入流程与聊天分离，其审计事件记录元数据，而不是秘密本身。即便如此，浏览器配置、已登录会话、截图和工具输出仍应按敏感信息管理。密码输入路径受到保护，不代表后续观察结果都没有风险。
试点应使用权限限定在任务范围内的账户，并确认退出登录和撤销访问确实有效。完成双因素认证只能说明用户通过了身份验证，不能自动授权 AI 同事发送消息、接受条款或批准采购。
OpenBot 是完全自托管，还是完全本地运行？
可以自托管 OpenBot，但必须检查完整数据流。 当前配置参考 要求提供 CopilotKit Intelligence 连接设置，同时支持兼容的模型端点。端点可以是供应商 API、模型网关或自己的基础设施。
| 层级 | 文档所述架构中的位置 | 需要决定什么 |
|---|---|---|
| 产品数据与动作审计 | 自己的 PostgreSQL | 备份、访问、保留和恢复 |
| 浏览器登录与工作文件 | 所配置的计算机和持久卷 | 隔离、重置、撤权及加密 |
| 对话与记忆 | CopilotKit Intelligence | 托管或自托管方式、保留期限和适用条款 |
| 推理请求 | 选择的模型端点 | 哪些上下文离开环境，以及如何处理 |
| Drive、Notion 等工具数据 | 已连接服务及返回结果 | 用户身份、目标系统权限和数据暴露 |
本地模型只改变推理这一层。它不会自动把对话存储或已连接的企业服务搬到你的电脑上。
当前托管 Intelligence 配置使用项目运行密钥，不再要求额外的许可证令牌。自托管 Intelligence 可能需要独立的授权配置。应当跟随固定版本的文档，而不是复制旧教程里的启动命令。
除了模型 Token，OpenBot 还有哪些成本？
MIT 许可证覆盖 OpenBot 的代码。预算仍需要包含计算资源、PostgreSQL、存储、备份、模型调用、所选 Intelligence 方案、连接器维护和运维人员投入。
截至 2026 年 9 月 10 日，CopilotKit 价格页 的免费 Developer 方案支持一位开发者、200 个线程和三天保留；本地部署仅含运行时。采用前应确认存储与授权条款，不要将免费理解为无限容量或完全本地。
可以使用以下成本口径：
每项验收任务成本 =（模型 + 托管 + 存储 + 运维 + 人工检查 + 返工）÷ 验收通过的任务数
分母必须对应约定好的业务结果。如果员工仍要重新完成任务或补回丢失的证据，较低的 Token 账单并不意味着节省。本次审阅的公开资料不能证明 OpenBot 对你的工作负载一定更便宜。
OpenBot 与 Grok Bot：比较运营责任，不是假定功能对等
OpenBot 作为 Grok Bot 替代品，是采购选项，不代表功能等价。Grok Bot 官方团队文档 描述了托管计算机、按用户划分的 Firecracker 隔离、同一用户的 Bot 共享计算机以及审批控制。管理功能取决于套餐。
| 决策 | OpenBot | 托管 Grok Bot |
|---|---|---|
| 谁负责运营 | 你维护克隆的应用及其部署 | 供应商运营产品 |
| 如何定制 | 修改源代码、接入兼容智能体和自定义 CEL 策略 | 使用服务提供的功能及管理设置 |
| 隔离边界 | 有 supervisor 时每个 Bot 一个计算机，否则可能共享 | 文档中的计算边界按用户划分 |
| 采购问题 | 定制收益能否覆盖开发维护成本？ | 功能和服务条款是否适合？ |
没有哪一种架构天然更安全或更便宜。对于常见流程，购买有人持续维护的成品可能更合理。定制软件与现成产品决策指南 解释了什么时候拥有和维护自己的系统才值得。
企业怎样开展一个务实的 OpenBot 试点？
从文档准备开始，不要从付款或生产管理开始。一个示例流程是供应商入驻材料整理：读取获准文档、找出缺失证据，然后生成供人工审批的草稿。AI 同事不应激活供应商、对外发送简报或批准发票。
控制方式应遵循 OWASP 关于过度代理权限的建议：减少功能、权限和自主性；在目标系统中实际执行授权；对重要操作要求人工批准。
第 1–3 天：明确边界。 指定负责人、一个流程、固定任务集和预期结果。使用合成文档或获准的测试材料。记录 OpenBot 修订版本、模型与部署方式。替换宽松策略，并在其他用户能够访问服务前配置身份认证。
第 4–7 天：检查控制。 正常读取应成功，禁止的写入应被拒绝。确认无法写入必要审计记录时，系统停止而不是继续动作。测试浏览器人工接管与交回，并检查所选架构中同事工作区和账户的实际隔离。
第 8–10 天：检查运维。 重启部署、恢复审计数据库、检查对话保留真正保存了什么，并撤销一个已连接账户。测试失败调用和重复请求，避免出现重复业务修改。记录恢复行为，而不是把容器健康检查通过当作完整证明。
第 11–14 天：比较结果。 与现有流程比较完成率、审查时间、修正次数、模型费用和运维投入。只有质量稳定、权限按设计运行、总投入确实改善时才扩大使用。否则，应缩小任务、使用确定性集成或购买托管工具。
什么情况下应该选择 OpenBot？
当团队有技术负责人、明确流程，并确实需要定制部署、智能体或动作策略时，受控试点值得考虑。如果主要需求是有人支持、维护简单的助手，或没有人能够负责认证、权限和恢复，就应暂缓。
Wavect 的 AI 咨询服务 可以帮助团队在建设平台前厘清这一决策。合理的首个交付成果是数据流图、权限矩阵、代表性任务集，以及有依据的继续或停止建议。Twinsoft AI 案例 展示了我们围绕可维护性和真实使用准备所做的工作，并不意味着该项目使用过 OpenBot。
可以先 讨论一个 OpenBot 可行性试点，围绕单一流程及验收标准展开，而不是一开始就全公司铺开。
真正的机会不是给 AI 同事尽可能多的访问权，而是让授予的访问权明确、可观察，并值得承担相应运维成本。 OpenBot 为此提供了起点，并没有替你完成这些工作。