从聊天框到数字同事：Grok Bot 深度调研，为什么「一台云电脑」重新定义了 AI Agent

AI产品,AI Agent 1 次阅读 26109 字 约 131 分钟

文章目录

coverImg

前言：这里的 Grok Bot，不是 X 上那个回复机器人

最近讨论度很高的 Grok Bot，指的是 xAI 于 2026 年 8 月 11 日发布的通用知识工作 Agent 产品，而不是 X 平台中被 @Grok 后自动回复的聊天机器人，也不是普通的 Grok 对话页。

它最醒目的产品定义是：一组可以被当成同事来委派工作的、始终在线的 AI Bots。这些 Bot 拥有持续运行的云端计算机，能登录用户已有的网页和应用，操作浏览器、文件系统与命令行；任务涉及敏感操作时再回来请求批准。官方发布稿将其概括为“AI teammates you can give real work to”。

这篇文章调研的截止时间为 2026 年 10 月 28 日。Grok Bot 仍在快速更新，价格、套餐、功能与平台支持应以文末官方链接为准。

Grok Bot 官方发布视频封面

图片来源：xAI 官方 Grok 频道发布视频《Introducing Grok Bot》。若外链无法显示，可直接访问：https://www.youtube.com/watch?v=F1_0Lkp16Rc

一、先用一张表看懂 Grok Bot

维度 结论
产品定位 可长期工作的通用型“AI 数字同事”，强调端到端完成任务，而非只输出建议
发布时间 2026-08-11 发布 Beta
所属公司 xAI；2026 年 xAI 被 SpaceX 收购，Cursor 随后也加入 SpaceX 体系
官方网站 Grok Bot 产品官网
官方博客 xAI 官方发布稿：Introducing Grok Bot
核心负责人 Roman Ugarte（@romanugarte_），Grok Bot 产品负责人，曾为 Cursor 早期员工并负责增长
实现周期 核心团队约 4 周做出内部可用版本，再用约 3 周准备公开发布；不是“一个月完成成熟商业产品”
是否开源 Grok Bot 产品本身未开源；不要与开源的 Grok Build、早期 Grok 模型权重或第三方仿制项目混淆
运行方式 客户端负责交互，主要工作在 xAI/Cursor 托管的持久云电脑中运行；也可经授权操作本地电脑或手机部分能力
支持端 macOS、Windows、Linux、iOS、Android；工作在客户端关闭后仍可继续
现行个人价格 Premium 30 美元/月、Super 100 美元/月、Ultra 200 美元/月，均含每周额度；额外用量按 Token 成本计费
最大差异 把“模型 + 工具”包装成可持续协作、可登录真实软件、可被审批约束的同事，而不是一次性聊天会话

二、产品背景：从 Cursor 内部实验，到通用知识工作 Agent

2.1、公司与团队背景

理解 Grok Bot，需要先理解 2026 年 xAI、SpaceX 与 Cursor 之间的变化：

  • 2026 年 2 月，SpaceX 宣布收购 xAI；
  • 2026 年 8 月，Cursor 宣布成为 SpaceX 的一部分；
  • Grok Bot 的账户、认证、隐私设置、团队管理以及不少文档仍与 Cursor 体系深度相连，官方文档甚至明确写明“使用 Cursor 账户登录，没有单独的 Grok Bot 登录”。

这不是一款孤立的 xAI 聊天应用，而是把三类资产组合到一起：

  1. xAI/Grok 的模型能力；
  2. Cursor 在 Agent Harness、云端执行环境、工具调用和开发者产品上的经验；
  3. SpaceX 体系内大量真实、复杂、跨部门的工作流作为内部试验场。

Grok Bot 产品负责人 Roman Ugarte（@romanugarte_） 是理解这款产品的关键人物。他曾是 Cursor 第 15 号员工，负责增长，并参与了 Grok Bot 从早期原型到上线的全过程。官方团队没有披露完整成员名单与精确人数，公开信息只称其为一个与大团队相对隔离的“小团队”。

2.2、它真的是一个月做出来的吗？

“一个月做出 Grok Bot”是传播最广、也最容易被误读的说法。

Roman Ugarte 在 Lenny's Podcast 访谈中披露：小团队从第一行代码开始，用大约 4 周做出可以在公司内部使用的产品，随后又用了约 3 周准备公开发布。期间团队手工引导了约 200～300 名早期用户，以发现工程师群体之外的盲区。

因此，更准确的表达是：

约一个月做出内部可用原型，约七周走到公开 Beta；其底层模型、云基础设施、账户体系和 Cursor 多年的 Agent 工程积累并不是一个月从零造出来的。

Grok Bot 产品负责人访谈封面

图片来源：Lenny's Podcast《How we built Grok Bot in a month》。

2.3、为什么没有直接塞进 Cursor？

Cursor 已经能让 Agent 写代码，也有用户拿它处理非代码任务。但团队选择单独做一款产品，原因不是 UI 不同，而是产品隐喻不同：

  • Cursor 的中心仍是“人坐在编辑器前，与编码 Agent 协作”；
  • Grok Bot 的中心是“把一个结果委派给同事，然后离开”；
  • 前者强调工作台与人机共创，后者强调所有权、异步执行和最终交付。

这种选择让 Grok Bot 可以删除大量开发者专用概念，不要求普通用户理解模型、MCP、工作流编排或上下文窗口，只要求用户像给同事布置任务一样说清楚结果、资料、边界和验收条件。

2.4、背后团队博客与信息入口

类型 地址 适合看什么
产品主页 https://x.ai/bot 当前能力、价格、下载入口
官方发布稿 https://x.ai/news/introducing-grok-bot 产品起点、内部案例、初始定位
官方文档 https://docs.x.ai/grok-bot 使用、安全、记忆、Routine、移动端等细节
更新日志 https://x.ai/changelog/bot 最新版本能力和修复
xAI News https://x.ai/news 公司、模型与产品动态
Cursor Blog https://cursor.com/blog Cursor 团队与工程背景
深度访谈 https://www.youtube.com/watch?v=maSdsTLaMuU 开发周期、产品决策与早期验证过程

2.5、核心价值：补上“最后 10%”

传统 AI 助手常常能完成任务的 80%～90%：给出邮件草稿、生成一段 SQL、告诉你 CRM 应该怎么更新。但最终登录系统、找到对应客户、填写字段、上传附件、检查结果和提交动作，仍由人来完成。

Grok Bot 的核心价值，是让 AI 的输出真正“落在工作发生的地方”：

  • 不只建议如何处理工单，而是进入 Zendesk 处理队列；
  • 不只写跟进邮件，而是读取 CRM 与通话记录、生成草稿并等待批准；
  • 不只分析故障，而是复现 UI Bug、整理截图与日志、创建 Issue，再交给另一个 Bot 修复；
  • 不只生成周报，而是按计划从多个系统取数、更新表格并发送可审阅结果。

这就是官方反复强调的差异：从“回答问题”转向“拥有并完成一项工作”。

三、收费、额度与使用方式

3.1、截至 2026-10-28 的现行个人价格

10 月 12 日，xAI 推出统一的 The X Subscription，把 Grok、Grok Bot、Cursor 与 X 权益重新组合。根据 Grok Bot 官方价格页，现行月付价格如下：

套餐 月付价格 Grok Bot 权益
Premium 30 美元/月 独立云电脑、登录工具、定时 Routine、桌面与移动端、每周 Grok Bot 用量
Super 100 美元/月 Premium 全部能力，约 3.5 倍 Premium 用量，高峰期优先模型访问
Ultra 200 美元/月 Super 全部能力，约 12 倍 Premium 用量，最早体验新产品与模型
Teams / Enterprise 团队计划或联系销售 团队共享 Bot、管理与企业控制，具体价格和额度以销售方案为准

需要特别注意三点：

  1. 没有一个单独售卖的“Grok Bot 套餐”，它是符合条件订阅的一部分；
  2. 套餐包含按周刷新的用量，超过后可产生按需用量，官方表述为按模型与 Token 成本计费；
  3. 官方没有在产品页给出一个简单的“每周可运行多少小时/多少任务”数字，因为复杂网页操作、模型调用与任务长度的成本差异很大。

Grok Bot 首发时支持旧的 SuperGrok 与 Cursor Pro/Pro+/Ultra 等计划，且 Bot 用量与原计划分开。现在仍有部分 legacy 计划可继续使用，因此网上会同时看到 20 美元、30 美元或“Cursor 付费版已包含”等不同答案。它们可能对应不同时点或遗留套餐，不能直接当作今天新用户的统一价格。

3.2、有没有免费版？

官方产品页提供“Get started for free”入口，文档也提到网页/桌面端的限时用量 Credit 试用，但 长期使用需要符合条件的付费计划。试用资格、额度和有效期可能按账户变化，注册页显示结果优先于第三方文章。

3.3、它到底是本地产品，还是云端产品？

答案是：云端执行为主，本地/移动端是交互面和可选执行端。

  • 桌面客户端支持 macOS（Apple Silicon / Intel）、Windows（x64 / Arm64）、Linux（x64 / Arm64）；
  • 手机支持 iOS 18+ 与 Android 9+；
  • Bot 默认在持久化云电脑中使用浏览器、命令行和文件系统，即便用户合上电脑，任务仍会继续；
  • 经用户授权，Bot 也能在本地 Mac/Windows 执行命令；默认策略是每次询问，也可设为始终允许或永不允许；
  • 手机端可在 App 保持前台时调用部分设备能力，如日历、联系人、位置、闹钟；iOS 还支持提醒事项和 Apple Home。

它不是可完全离线、自托管的本地 Agent。对数据主权要求很高、必须断网运行或希望替换任意模型的团队，需要评估其他自托管方案。

3.3.1、在本地客户端对话，是否能直接操作本地电脑？

可以，但不是默认无条件访问，也不能把“桌面客户端”理解成“任务默认在本机执行”。

Grok Bot 桌面 App 只是你与 Bot 对话、查看进度和审批动作的入口。Bot 默认仍在 Cursor 托管的云电脑中工作。如果任务确实需要本机资源，可以在：

Settings → Computer → Your computer → Execution on this computer

为当前 Mac 或 Windows 选择：

策略 行为
Ask every time 默认策略；每条本地命令显示准确命令并等待批准
Always allow 允许 Bot 在该设备上直接运行本地命令，风险最高
Never allow 完全禁止 Bot 操作该设备，官方建议无明确需求时使用

获得授权后，Bot 可以在本机运行命令和脚本、读取本地文件，并在本地机器与云电脑之间移动文件。这项本地执行权限与云电脑中的 Auto Review 是两套独立控制：允许云端动作，不等于允许访问本机；团队管理员还可以设置更严格的上限。

这里的官方表述主要针对桌面端命令、脚本和文件操作，并不意味着 Bot 可以像远程控制软件一样任意点击本机所有 GUI 应用。网页和桌面 GUI 自动化的默认对象仍是它的云电脑；本地能力应按文档明确支持的范围理解。

3.3.2、能否同时操作本地电脑和云端电脑？

要分成“同一工作流能否跨两端”和“同一个 Bot 是否双端同时点击”两个问题：

  • 同一工作流跨两端：可以。 官方安全文档明确支持 Bot 读取本地文件、在本地运行任务，并在本机与云电脑之间移动文件。例如本地执行数据脱敏脚本，把结果传到云电脑，再登录网页后台上传。
  • 云端与本地能力可以同时保持可用。 打开本地执行权限不会关闭云电脑，官方明确说明本地策略不影响 Bot 使用云电脑；云端工作也能在本地设备关闭后继续。
  • 多个 Bot 可以并行。 每个 Bot 在共享云电脑上有自己的屏幕，因此不同 Bot 可并行推理、使用连接器、处理文件和操作云端界面。
  • 不要推导成“同一个 Bot 能同时控制两块桌面 GUI”。 官方只明确保证一个 Bot 在自己的云端屏幕上同一时间运行一个 Computer-use 任务；没有承诺同一个 Bot 会并发点击本地桌面与云端桌面。可靠的理解是：同一个任务可在两端顺序切换或传递文件，需要真正并行时拆给不同 Bot，并设置清晰的文件交接和审批边界。

3.3.3、本地、云端与网络路由的能力边界

能力 云端电脑 本地 Mac / Windows 关键限制
浏览器与网页 GUI 默认支持，可持续运行 不应默认理解为可任意控制本机 GUI 网站可能阻止自动化、要求 CAPTCHA 或人工验证
终端命令与脚本 默认执行面 授权后可执行 本地默认逐命令审批；团队管理员可禁用
文件读写 云端持久文件系统 授权后可读取，并可与云端互传 本地文件不在云端恢复/备份范围内
登录态 同一用户的所有 Bot 共享云端浏览器登录 本地登录态不等同于自动共享给 Bot 所有个人 Bot 共享云端文件、Cookie 和 CLI 凭据，不构成 Bot 间隔离
持续后台工作 支持，关掉电脑仍继续 不支持离线执行，本机必须在线且 App 可用 Routine 的可靠执行底座仍是云端
网络出口 默认使用云端出口 可开启 Route traffic through this computer 这只是让云端浏览器流量经过本机 IP，不等于把浏览器搬到本机；新连接生效，且桌面 App 必须打开
私网 / VPN 受企业网络策略限制 本地路由可能帮助访问，但私网地址默认仍可能被阻止 企业管理员可以关闭本地出口路由；不能视为通用 VPN 穿透方案
手机 App 用于对话、查看、审批和接管云电脑 可调用日历、联系人、位置、闹钟等有限能力 手机 App 需保持前台；共享 Bot、群聊等场景受限

还有一个容易混淆的功能：Route traffic through this computer。它只是把 Grok Bot 云电脑的新 Web 连接经你的桌面网络出口转发，让目标站点看到本机 IP；浏览器和任务仍运行在云端。它与“Execution on this computer”是两项不同权限。

截至 2026-10-28，官方明确表示 Grok Bot 只运行在 Cursor 托管的云电脑上，不支持 On-premise、部署到企业自有边界或 Bring Your Own Image。因此，即使开启本地执行，它仍不是完整的本地部署产品。详细边界可参考云电脑与 App、安全说明与设置文档。

3.4、第一次使用的最短路径

  1. 从 https://x.ai/bot 下载客户端；
  2. 使用符合条件的 Cursor/Grok 账户登录；
  3. 创建一个 Bot，只给它一个清晰岗位，例如“产品性能分析”；
  4. 在第一条消息中写明结果、数据源、限制、交付物和审批边界；
  5. Bot 需要访问某个系统时，通过 Vault、密码管理器或 Secure Form 登录；
  6. 先让它完成一次可审阅任务，修正后再沉淀为 Skill；
  7. 流程稳定以后，才配置定时或事件触发的 Routine。

一个比较好的首次任务模板：

你的职责是每周产品数据复盘。读取指定仪表盘和上周报告，输出一份包含关键变化、证据链接、异常解释与待确认问题的 Markdown 报告。不要修改数据源，不要向任何人发送消息；完成草稿后等待我审批。请记住这些长期边界。

四、核心产品功能：不是一个 Bot，而是一套数字同事系统

4.1、持久化云电脑

官方“Computer and Apps”文档披露，每个用户账户分配一台持续存在的云电脑，包含：

  • 浏览器：可操作无 API、无 MCP 或必须走可视界面的系统；
  • 命令行：可运行脚本、开发工具和本地处理流程；
  • 文件系统：任务之间保留文件与工作结果；
  • 持久登录态：Cookie、网站会话和命令行凭据在任务之间保留；
  • 多屏并行：多个 Bot 拥有各自屏幕，可同时进行电脑操作。

一个经常被误解的细节是：不是每个 Bot 一台完全隔离的电脑，而是同一用户的所有 Bot 共享一台持久云电脑。 文件、浏览器登录和 CLI 凭据对该用户的其他 Bot 可见。独立屏幕是工作面隔离，不是安全边界；真正的强隔离发生在不同用户之间。

核心官方来源： 云电脑与 App

4.2、网页操作与结构化 App 连接

Grok Bot 有两条执行路径：

  • 服务已有连接器时，优先通过结构化 App 能力操作，例如 Gmail、Notion、Slack；
  • 服务没有可用连接器，或必须处理视觉工作流时，直接使用浏览器点击和输入。

这是一项务实的设计：API/连接器更稳定、更容易约束；Browser Computer Use 覆盖面更广，但页面变化、验证码与异常弹窗会降低可靠性。两条路径结合，才能覆盖真实企业软件的“长尾”。

核心官方来源： 云电脑与 App：连接 App 与使用浏览器

4.3、多 Bot 并行、群聊与 Chief of Staff

用户可以创建多个分工明确的 Bot，例如销售线索、费用管理、招聘、Bug 复现和内容运营。Bot 之间可以直接发消息、共享文件，也可加入群聊协调。

官方内部常见的组织方式是 Chief of Staff 模式：一个主 Bot 负责接收目标、拆分工作和汇总结果，多个专业 Bot 分别执行。Grok Bot 也有 Primary Bot 概念，作为主要入口并主动检查进展。

这不是为了展示“多智能体”技术，而是解决人的管理负担：用户只跟一个协调者沟通，不再亲自复制粘贴每个子任务的上下文。

核心官方来源： 消息与协作、官方使用场景：Chief of Staff

4.4、长期记忆

Bot 管理文档显示，每个 Bot 会保留稳定偏好、长期规则、用户事实以及带日期的工作记录。会话重置后记忆仍在，删除 Bot 才会删除它的记忆；少量用户级事实会在自己的 Bots 之间共享。

这里有两个边界：

  • 个人 Bot 暂无传统“记忆管理页”，用户通过自然语言询问、纠正或要求遗忘；
  • 官方明确提醒：记忆不是事实源。关键决策仍需回到 CRM、数据库、文档等权威来源核验。

核心官方来源： 创建、管理与记忆

4.5、Skill 与 Routine：先做对，再自动做

Skills and Routines 文档把复用能力分为两层：

  • Skill：描述如何完成一类任务，包括输入、步骤、决策规则、验收方式、输出格式和审批边界；
  • Routine：规定何时运行，可按时间表，也可由 Slack 消息、GitHub/Linear/Sentry/PagerDuty 事件、邮件或 Webhook 触发。

官方推荐顺序很有价值：先完成一次真实任务 → 修正到稳定 → 保存为 Skill → 最后再变成 Routine。 这比一开始就在低代码画布里搭建一条尚未被验证的流程，更符合复杂知识工作的真实演进方式。

核心官方来源： Skills、Routines 与自动化

4.6、文件与交付物

Grok Bot 支持图片、音视频、PDF、Word、Excel、PowerPoint、CSV、JSON、YAML、源代码、HTML、邮件和 Jupyter Notebook 等输入；也能输出文档、表格、幻灯片、截图日志、草稿消息或带证据的结论。

桌面端每条消息最多 20 个附件；文档/音频等单文件通常上限 250 MB，视频单文件上限 1 GB。它还能在 Google Drive、OneDrive、SharePoint、Gmail 和 Outlook 与云电脑之间移动文件。详细限制见官方文件文档。

核心官方来源： 文件与交付物

4.7、移动端、语音与随时接管

移动端连接同一组 Bot、对话、Routine、连接器和云电脑。用户可以：

  • 文本、听写或实时语音交谈；
  • 查看 Bot 正在操作的云电脑；
  • 遇到 2FA、CAPTCHA 或敏感步骤时接管；
  • 批准或拒绝外部动作；
  • 暂停或恢复 Routine。

这使 Grok Bot 更像可以随时发消息的同事，而不是必须坐在桌前打开的生产力软件。

核心官方来源： 移动端

4.8、安全：Auto Review、Vault 与人工接管

Agent 能真正操作系统后，安全问题从“回答错了”升级成“做错了”。Grok Bot 的核心防线包括：

  1. Auto Review：在执行命令、使用 App 或操作电脑前评估动作；高风险动作显示批准卡；
  2. Custom Rules：用户可用自然语言定义“始终允许”或“必须先问”，冲突时 Ask First 优先；
  3. Vault / Secure Form：密码、卡号与密钥不进入普通聊天，不展示给模型；
  4. 人工接管：SSO、Passkey、CAPTCHA、异地确认或支付验证由人临时接管；
  5. 团队与企业控制：包括强制 Auto Review、审计、DLP、代理、证书与网络策略等。

Auto Review 是基于模型的自动审查，它是风险控制层，不等于绝对安全。官方也建议把发送、发布、购买、删除、改权限和生产变更始终放在明确审批边界之后。详见审批、安全与隐私文档。

核心官方来源： 审批、安全与隐私

五、核心技术能力与底层原理拆解

5.1、先说结论：官方没有公开完整技术栈

截至调研时间，Grok Bot 产品客户端与云端服务没有公开完整源码，官方也没有系统披露前端框架、后端语言、调度系统、数据库、虚拟化实现或完整模型路由策略。

因此，下面分成两类：

  • 已确认：来自官方产品文档、更新日志与负责人访谈；
  • 架构推导：依据产品行为得到的合理抽象，不代表 xAI 对内部实现的确认。

这里的技术拆解采用“产品证据 + 通用 Agent 原理”的方法：官方文档用来确认 Grok Bot 对外提供了什么能力，论文与工程文档用来解释这些能力通常如何实现。凡是没有官方披露的地方，本文都会标记为推导，不把产品表象误写成内部源码事实。

核心依据： Grok Bot 官方总览、云电脑与 App、审批、安全与隐私

5.2、可验证的 Agent 执行闭环

从官方文档可以还原出一个典型执行闭环：

用户目标
  ↓
Bot 的角色、长期记忆与当前对话
  ↓
规划下一步动作
  ↓
选择执行面：结构化 App / 浏览器 / 终端 / 文件 / 设备
  ↓
Auto Review + 自定义规则 + 内置安全检查
  ├─ 低风险：继续执行
  └─ 高风险：等待用户批准或人工接管
  ↓
读取结果、检查是否达到目标
  ├─ 未完成：调整计划，继续循环
  └─ 已完成：生成可审阅交付物并通知用户
  ↓
更新工作记录；必要时沉淀 Skill 或触发后续 Routine

这本质上仍是 Agent Loop：模型观察状态、决定动作、调用工具、读取结果并继续推理。真正决定产品上限的并不只是模型智力，而是执行环境是否持续、工具是否覆盖真实工作、失败能否恢复、敏感动作能否约束、结果能否落地。

用 ReAct 解释这个闭环

可以把上面的流程映射到 ReAct（Reasoning + Acting）范式：

  1. 观察（Observe）：读取对话、网页、文件、工具返回值和当前任务状态；
  2. 决策（Decide）：判断下一步是继续提取信息、调用工具、询问用户，还是结束任务；
  3. 行动（Act）：通过连接器、浏览器、终端或设备执行动作；
  4. 反馈（Feedback）：把动作结果写回上下文，检查是否达到完成标准，再决定是否进入下一轮。

这只是解释 Grok Bot 行为的通用模型，不代表 xAI 已公开确认内部采用 ReAct 实现。它的价值在于帮助读者理解：Agent 不是“生成一段答案”，而是不断在环境中获取新状态并据此调整行动。

技术依据： ReAct 论文、Anthropic：Building effective agents、Grok Bot 审批与安全文档

5.3、Persistent Computer：把状态从对话移到环境

普通聊天产品主要把状态放在消息历史中；Grok Bot 还把状态放在持续存在的计算环境中：

  • 浏览器登录态留在浏览器；
  • 中间文件留在文件系统；
  • CLI 工具和凭据留在运行环境；
  • 不同 Bot 通过共享文件与会话状态交接；
  • 用户离线时云端执行不停止。

这项设计减少了每次任务都要重新认证、重新上传、重新解释环境的成本。它也是 Grok Bot 让人产生“同事感”的核心：同事第二天仍记得项目放在哪里，而一次性聊天窗口往往需要重新开始。

代价是安全边界必须讲清楚。所有个人 Bot 共享同一计算机，因此不能把不同 Bot 当成权限隔离单元；敏感项目要靠账户、最小权限连接、审批规则与及时清理来保护。

结构拆解：四个状态平面

从学习和实现角度，可以把“持久化云电脑”拆成四个平面：

平面 保存什么 解决什么问题
执行平面 浏览器、终端、文件系统、桌面应用 让 Bot 真正执行任务，而不是只给出建议
状态平面 文件、Cookie、网站会话、命令行凭据、工作记录 让任务跨回合、跨 Bot 延续
控制平面 对话、任务状态、通知、暂停/恢复、审批卡 让人可以观察和干预执行过程
身份与权限平面 用户账户、连接器授权、Vault、团队策略 决定 Bot 能看什么、能做什么、何时必须问人

这是根据官方产品行为归纳出的功能架构，不是 xAI 公布的内部服务拓扑。它解释了为什么“云电脑”不只是远程桌面：真正的产品价值在于把执行状态、身份状态和控制状态一起持久化。

技术依据： Grok Bot 总览、云电脑与 App、Bot 管理与记忆

5.4、Computer Use 与连接器的混合路由

纯 GUI Agent 覆盖广，但速度慢、成本高、易受界面变化影响；纯 API Agent 稳定，却无法覆盖没有开放 API 的系统。Grok Bot 的设计是混合执行：

执行方式 优点 局限 适合场景
结构化 App / 连接器 快、字段明确、便于审计与重试 需要集成，覆盖有限 Gmail、Slack、Notion 等标准动作
浏览器 Computer Use 几乎可覆盖人能使用的网页 页面漂移、弹窗、验证码、视觉误判 长尾 SaaS、后台页面、无 API 流程
命令行 可组合、可脚本化、适合数据与工程任务 权限风险更高 代码、批处理、数据转换、诊断
本地/手机能力 可触达用户身边环境 需要设备在线与明确授权 本地文件、日历、提醒、智能家居

这套混合路由是比“支持多少 MCP”更重要的能力：产品可根据目标选择最可靠的可用通道，而不是把用户限制在某一种工具协议里。

如何理解“路由”而不是“工具堆砌”

一个实用的路由器至少要同时考虑四个维度：

  • 覆盖度：目标系统是否有结构化连接器；
  • 精确度：动作能否用明确字段表达，还是必须依赖视觉与页面上下文；
  • 可恢复性：失败后能否重试、回滚或从中间状态继续；
  • 风险等级：读数据、改数据和向外发送的授权要求不同。

因此，连接器适合稳定的读写动作，浏览器适合长尾系统和视觉流程，终端适合可重复的数据处理；真正成熟的 Agent Harness 不是让模型“自由发挥”，而是给每种动作提供合适的执行面、结果格式和失败处理。

OSWorld 之类的研究也说明，电脑操作 Agent 不能只用单轮问答准确率衡量，还要测试真实桌面环境、多应用切换、文件操作和长流程完成率。

技术依据： 云电脑与 App、Anthropic Computer Use Tool、OSWorld：真实计算机环境中的多模态 Agent 基准

5.5、多 Bot 协作的真正难点是共享状态

多个模型并发并不难，难的是避免上下文丢失、重复劳动和权限失控。Grok Bot 通过以下产品原语降低协调成本：

  • Bot 有相对稳定的岗位与独立记忆；
  • 同一用户下共享云电脑与文件；
  • 支持 Bot 私信、群聊与显式线程；
  • Primary Bot / Chief of Staff 汇总结果；
  • 外部动作仍绑定到发起者和审批者，而不是因为“内部转交”就绕过审批。

这种设计更接近组织协作系统，而不是单纯的“多 Agent 对话 Demo”。

多 Agent 的收益来自分工，成本来自协调

把一个任务拆给多个 Bot，通常只有在以下条件成立时才划算：子任务可以并行、角色边界清楚、交接信息可结构化、每个子任务都有独立的完成标准。否则，多个 Bot 只会增加上下文传递、重复执行和冲突处理的成本。

从通用 Agent 架构看，Grok Bot 的 Chief of Staff 可以理解为 orchestrator-workers（编排器—工作者） 模式：编排者负责拆分与汇总，工作者负责局部执行；群聊和共享文件是状态传递机制，审批仍是外部动作的权限闸门。这个映射是架构类比，不是对 Grok Bot 内部代码的断言。

技术依据： 消息与协作、官方使用场景：Chief of Staff、Anthropic：Building effective agents

5.6、安全设计的关键：模型不能直接看到秘密

Vault 的设计重点不是“把密码加密存储”这一句，而是缩短秘密暴露链路：模型知道要使用哪个登录项，却看不到密码、完整卡号或安全码；Secure Form 的值不写入聊天记录；1Password 模式可由用户逐次批准填充。

从原理上看，这是把 推理平面 与 凭据平面 分开：

  • 模型负责决定“需要登录某网站”；
  • 安全组件负责把凭据填入目标字段；
  • 模型只接收登录成功或失败等结果，而不是秘密本身。

但浏览器登录后，Bot 仍可能访问账户内的数据并产生外部动作，所以凭据不可见并不等于没有权限风险，仍需最小权限和审批。

用最小权限理解为什么 Vault 还不够

Vault 解决的是“模型是否直接看到秘密”，并没有自动解决“这个 Bot 是否有权读取或修改目标系统”。完整的防护链应至少包含：

  1. 秘密隔离：密码、卡号和 API Key 不进入普通上下文；
  2. 能力最小化：只开放完成任务所需的 App、账户和操作；
  3. 动作分级：读取、草拟、修改、发送、支付和删除分别处理；
  4. 人在环审批：不可逆或对外动作在执行前暂停；
  5. 审计与恢复：保留操作记录，提供撤销、暂停和人工接管路径。

这与 OWASP 对 Excessive Agency（过度代理权限） 的定义相吻合：风险通常来自功能过多、权限过大或自主程度过高，而不只是模型“会不会泄露密码”。所以，安全 Agent 的核心不是单点的密码保护，而是让模型的可行动范围小于用户账户的全部能力。

技术依据： 审批、安全与隐私、Vault 与安全登录、OWASP LLM06：Excessive Agency

5.7、自然语言自动化：把录制过程变成可维护知识

传统 RPA 记录坐标和点击序列，页面稍有变化就可能失效；Grok Bot 更强调让用户先示范或共同完成任务，再把“意图、判断标准与边界”保存为 Skill，最后由 Routine 调度。

它的优化方向不是把点击录得更精确，而是把流程提升为语义层：

  • 做什么；
  • 用哪些权威数据；
  • 遇到例外如何判断；
  • 什么结果算完成；
  • 哪些动作必须停下来问人。

这让自动化可从“固定路径”进化成“目标驱动”，也更适合充满例外的知识工作。

Skill 与 Routine 的技术本质：策略层 + 调度层

可以把两者理解成两个不同抽象：

  • Skill 是策略层：描述任务目标、输入、步骤、判断规则、验收标准和审批边界；
  • Routine 是调度层：描述什么时候触发这套策略，以及触发后把结果交给谁；
  • 执行器是运行层：在每次运行时重新选择连接器、浏览器、终端或设备，并根据结果调整路径。

这种分层比录制坐标更有韧性，因为页面变化时只需要重新选择执行路径，岗位目标和验收标准仍然可以保留。但它也带来一个要求：Skill 必须写清楚“什么算完成”和“遇到什么情况必须停下”，否则 Routine 只是把不稳定的流程自动重复。

技术依据： Skills、Routines 与自动化、Anthropic：Building effective agents

5.8、近期亮点（截至 v0.77.0）

根据 2026-10-26 的 v0.77.0 更新日志，近期值得关注的能力包括：

  • 1Password 无需共享保险库，逐次批准后直接填充到 Bot 浏览器，Bot 看不到密码；
  • 可从其他 AI 助手导入偏好与上下文到 Primary Bot；
  • 多问题 Question Card，一张卡片逐步收集用户判断；
  • Vault 新增支付方式管理，但每次购买仍需批准；
  • 自定义 MCP 支持私有 CA；
  • Gmail 连接失效后，Primary Bot 可主动提醒重新连接；
  • 团队 Bot 可在 Slack 编辑已发送消息，并支持更细的共享限制与企业审计；
  • Auto Review 减少对可撤销私有动作的打扰，同时保留关键批准。

这些更新说明产品正在同时补三条线：扩大执行范围、降低人在环摩擦、加强企业控制。

从技术视角看，更新日志中的能力并不是零散功能：1Password、Vault 和 Auto Review 在补安全执行链；Question Card 在补结构化的人机交互；导入记忆和 Primary Bot 在补跨任务状态；团队审计和共享限制在补组织级控制面。

核心官方来源： Grok Bot 更新日志

5.9、它是否开源？

结论很明确：Grok Bot 不是开源产品。 官方没有提供 Grok Bot 客户端与云端控制面的公开源码仓库。

容易混淆的是：

  • xAI 曾开放过早期 Grok 模型权重；
  • Grok Build 已宣布开源；
  • GitHub 上出现 Rakazo/Grokbot、OpenBot、OpenMausBot 等第三方替代项目。

这些都不等于 Grok Bot 本身开源。第三方项目可以帮助理解“持久电脑 + Agent + 权限网关”的通用架构，也可能支持本地部署和自选模型，但在账户安全、移动端体验、团队协同、连接器覆盖和托管可靠性上不能直接视为官方等价物。

更严谨的表述应是：在公开的产品主页、官方文档和更新日志中，未见 Grok Bot 客户端与云端控制面的公开源码仓库。因此本文使用“未公开源码”，而不是断言其内部绝对不存在任何可复用代码。

核心依据： Grok Bot 产品主页、Grok Bot 官方总览、Grok Bot 更新日志

5.10、开源社区是否有 Grok Bot 的逆向或复刻实现？

先给结论：有复刻形态，没有可信的官方源码泄露

截至 2026-10-30，本次对 GitHub、项目官网、README、架构文档和安全说明的检索结果是：

  1. 没有发现可信的 Grok Bot 客户端或云端控制面源码泄露、反编译还原或内部 API 逆向项目。
  2. 已经出现多批公开项目，明确使用“Grok Bot alternative”“inspired by Grok Bot”或“reimplementation”等表述，属于基于公开产品行为的 clean-room 复刻。
  3. 它们复刻的是产品形态和通用技术架构：命名 Bot、持久记忆、云电脑/虚拟机、浏览器与终端、Routine、审批和移动端入口；并没有复刻 xAI 的 Grok 模型、账户体系、云端调度、连接器实现或原始 Agent Harness。

其中，BOTROSTER 明确称自己是独立实现、没有 xAI 代码；OpenMausBot 也明确声明与 xAI 无关联；OpenGrokBot 后续已演化为 OpenMausBot。它们的声明共同说明：社区是在“照着产品公开行为重建”，不是在公开 Grok Bot 内部实现。

代表性项目分层

项目 复刻层级 已公开实现 与 Grok Bot 的关键差异 适合学习什么
BOTROSTER 最接近产品外形的 clean-room 实现 命名 Bot、持久对话/记忆/计划，共享一台持久电脑，浏览器、Shell、文件系统、MCP、审批和审计 Apache-2.0；项目自称 pre-alpha，不能视为生产替代品 控制平面、Guest Computer、Agent Loop、审批闸门、持久存储如何拆层
Rakazo 完整产品级替代方案 多 Bot、记忆、Routine、语音、浏览器/终端/文件/桌面、共享或私有 Computer，支持 Docker、E2B、Daytona 等 Provider Apache-2.0；Beta；使用自有模型和自有计算提供商，不是 xAI 云服务 计算机 Provider 抽象、移动/桌面/网页多端、Bot 状态持久化和多 Agent 协作
OpenMausBot 每个 Bot 独立电脑的本地优先实现 每个 Bot 有自己的模型、电脑和 App，支持本地 VM/云端 Linux 桌面、Computer Use、审批卡和人类接管 Apache-2.0；enterprise/ 目录另有 source-available 条款；它更接近“每 Bot 一台电脑”，而 Grok Bot 是同一账户共享一台云电脑 VM 生命周期、模型/CLI 适配、凭据留在本地、审批与接管
OpenBOT 明确标注为 GrokBot reimplementation 本地桌面应用、每 Bot 独立 Chrome Profile、Linux VM、持久工作区、动作审批、登录/2FA/CAPTCHA 人工接管 MIT；当前仍是早期版本，独立 VM 主要依赖 Apple Silicon/macOS 能力 单 Bot 隔离、VM 边界、动作前后截图、人工 takeover 和权限最小化
OpenBot（pmwasim） 控制平面和安全审计实现 本地 Agent Loop、任务/事件历史、可恢复任务、工作区记忆、Skills、Routine、一次性审批和脱敏审计 MIT；更偏 local-first 任务系统，桌面自动化、远程 Worker 和多用户协作仍不是完整能力 如何让 Tool Call 可验证、可暂停、可恢复、可审计，而不是只输出一段最终答案
Celesto / OpenMuse 持久化电脑与沙箱基础设施 轻量 VM、浏览器/CDP、桌面、持久文件和状态、快照恢复、网络策略，本地或云端运行 Apache-2.0；主要是 Runtime/Computer 层，不是完整的 Bot 产品 如何给 Agent 提供隔离、持久、可观察、可接管的执行环境
Browser Use 浏览器 Agent 执行层 开源浏览器 Agent、Playwright/CDP、本地或云浏览器、结构化浏览器动作 MIT；本身不提供 Grok Bot 的 Bot 身份、长期记忆、Routine 或团队协作 浏览器观察—动作—结果闭环，以及 GUI 与结构化工具的边界
OpenHands Runtime 通用 Agent Runtime 层 Docker/Remote Runtime、Bash、文件系统、浏览器、事件流、动作执行器与 Observation 重点是开发/代码 Agent 的执行环境，不是 Grok Bot 式的数字同事产品 Agent 与执行环境解耦、动作路由、Observation 回传和远程沙箱

哪些能力可以复刻，哪些能力无法从公开信息确认？

能力 开源项目可以复刻的部分 仍然无法确认或替代的部分
Bot 身份与记忆 Bot 配置、对话历史、文件、结构化记忆、工作记录 xAI 内部的记忆写入/检索策略、模型上下文拼装细节
持久化电脑 Docker、VM、远程 Sandbox、浏览器 Profile、工作区和快照 xAI/Cursor 云电脑的真实调度、配额、硬件隔离与内部网络策略
Agent Loop Tool Schema、规划—执行—观察循环、重试、暂停、恢复 Grok Bot 使用的具体模型、系统提示、模型路由和内部评估器
App 与浏览器 MCP、OpenAPI、Composio、Playwright/CDP、Computer Use 官方连接器的权限模型、私有集成、生产级稳定性和服务端密钥管理
安全审批 Allow/Deny、一次性批准、Vault、人工接管、审计日志 xAI 线上风控规则、Auto Review 模型、企业租户控制面
Routine 与多 Bot Cron、Webhook、队列、群聊、编排器—工作者模式 官方移动端推送、跨服务调度和大规模长时间运行的可靠性

因此，“复刻 Grok Bot”更准确的含义是：复刻一种 Agent 产品架构，而不是复刻 xAI 的实现本身。如果目标是学习原理，开源项目反而提供了更透明的拆解入口；如果目标是生产替代，必须单独验证安全、稳定性、数据留存、模型成本和升级维护。

推荐的学习与复刻路径

不建议从“做一个聊天界面”开始，而应按执行链逐层搭建：

  1. 先做控制平面：参考 OpenBot（pmwasim），实现任务状态、Tool Call、审批、取消、恢复和审计；
  2. 再做单机执行环境：参考 Celesto 或 OpenHands Runtime，把 Shell、文件和浏览器放进隔离 Runtime；
  3. 加入浏览器 Agent：参考 Browser Use，实现浏览器观察、动作执行、结果确认和失败重试；
  4. 再做持久化：给每个 Bot 绑定工作区、浏览器 Profile、记忆和事件日志，明确哪些状态属于 Bot、用户或共享团队；
  5. 最后做多 Bot 与 Routine：参考 BOTROSTER 或 Rakazo，加入编排、消息交接、定时触发和人类审批；
  6. 用真实任务评估：至少记录完成率、平均步数、失败恢复率、人工接管次数、单任务成本和越权动作数。

这条路径能把“像不像 Grok Bot”转化成可验证的工程问题，也能避免一开始就陷入 UI、Prompt 或模型选型，而忽略真正决定 Agent 能否工作的执行环境和控制平面。

开源项目来源： BOTROSTER、Rakazo、OpenMausBot、OpenBOT、OpenBot、Celesto、Browser Use、OpenHands Runtime

5.11、如何用一个小实验拆解 Agent 原理

如果读者想从“看懂产品”进一步走到“理解原理”，可以用文章前面提到的“每周产品数据复盘”做一个最小实验。不要一开始追求多 Agent 或复杂框架，而是逐层增加能力：

实验层 要回答的问题 可观察指标
任务契约 输入是什么、输出是什么、哪些事情明确不做？ 结果是否符合格式，是否越权
工具路由 哪些步骤用 API/连接器，哪些步骤必须用浏览器或终端？ 成功率、耗时、重试次数
状态管理 下次运行需要保留哪些文件、会话和工作记录？ 是否能从中断处继续，是否重复劳动
验收与证据 怎样证明报告完成，引用是否回到权威数据源？ 事实准确率、证据覆盖率
安全闸门 哪些动作只允许草拟，哪些动作必须人工批准？ 未授权动作数、审批命中率
自动化调度 什么时候从手动运行升级为 Routine？ 运行稳定性、失败恢复时间

这个实验能把“Agent 很聪明”拆成可测量的工程问题：模型决策、工具执行、状态持久化、结果验证和权限控制。也正因为如此，学习 Agent 不应只看提示词，还要同时学习工具协议、状态机、任务评估和安全边界。

延伸依据： ReAct 论文、OSWorld 基准、OWASP Agent Security Cheat Sheet

六、边界与风险：能做事，也意味着能做错事

6.1、成本可预测性不足

按周额度与 Token 成本的组合，对短任务还算直观；对长时间浏览器操作、反复重试和多 Bot 并行任务，用户很难事前把“一个业务结果”换算成成本。团队落地前应记录每类任务的平均消耗，而不是只看月费。

6.2、GUI 自动化仍然脆弱

网站改版、弹窗、会话过期、CAPTCHA、网络抖动和权限变化都会中断任务。结构化连接器应优先，GUI 操作应有结果校验与失败通知；不要因为看见 Bot 能点击网页，就把它当成确定性脚本。

6.3、共享云电脑不是 Bot 间安全隔离

同一账户下的 Bot 共享文件、Cookie 和命令行凭据。岗位分工是认知与产品层面的隔离，不是权限隔离。涉及客户数据、财务或生产系统时，应使用最小权限服务账户，并定期清理会话、文件和连接器。

6.4、数据必须进入云端存储

Grok Bot 需要云数据存储，不支持 Cursor 的 Legacy Privacy Mode。虽然官方称数据传输和静态存储均加密，并提供训练退出选项，但强监管行业仍需逐项评估数据驻留、留存、子处理方、审计与合同条款。

6.5、审批不等于撤销

批准卡只能控制即将执行的动作，不能撤销之前已经完成的工作。一个任务若先导出敏感数据、再请求“是否发送”，风险可能已经发生。因此权限边界应覆盖读取与导出，而不只关注最终发送按钮。

6.6、记忆会过时，主动性也可能放大错误

长期记忆让 Bot 更像同事，但过期偏好、错误事实与含糊规则也会长期影响行为。重要工作必须引用当前权威数据；用户应定期询问 Bot“你记得什么”，纠正或删除陈旧信息。

七、我的思考：Grok Bot 最大的亮点到底是什么？

7.1、不是“更强模型”，而是重新定义交互契约

Grok Bot 最值得关注的不是某个 Benchmark，也不是又多了一个浏览器 Agent，而是它改变了人与 AI 的契约：

  • 聊天助手的契约是“我问，你答”；
  • Copilot 的契约是“我做，你在旁边协助”；
  • Grok Bot 的契约是“这件事交给你，完成后回来，关键节点问我”。

当产品以“同事”而不是“功能”组织能力时，用户自然会给它岗位、目标、权限、资料、验收标准和反馈，而这些恰好也是 Agent 长期可靠工作所需要的上下文。

7.2、“一台云电脑”是最朴素、却最有效的通用接口

现实工作没有统一 API：有旧后台、内部网页、邮件附件、Excel、命令行和必须由人完成的验证。电脑本身就是人类为所有数字工具建立的通用接口。给 Agent 一台能持续存在的电脑，相当于直接复用几十年来的软件生态，不必等待每个系统专门为 AI 重写接口。

它并不优雅，GUI 操作也不如 API 稳定，但覆盖面巨大。连接器负责高频稳定路径，电脑负责长尾，这是 Grok Bot 技术与产品组合中最聪明的部分。

7.3、真正的护城河可能是“工作记忆 + 登录态 + 纠错历史”

模型会快速同质化，单个工具连接也容易复制。一个用了几个月的 Bot 却积累了：

  • 用户的表达风格和决策偏好；
  • 哪些边界必须询问；
  • 已登录的工作环境；
  • 经反复纠正后稳定的 Skills；
  • 与其他 Bots 的分工和交接方式；
  • 大量真实任务的成功与失败历史。

这套状态具有很强的迁移成本。Grok Bot 的潜在护城河不是“今天能点哪个网页”，而是它是否能把组织隐性知识逐渐沉淀为可执行、可审查、可复用的数字工作系统。

7.4、它最适合什么任务？

最适合 Grok Bot 的任务通常具备以下特征：

  • 跨越多个工具，人工复制粘贴很多；
  • 需要每天或每周重复，但每次又有少量判断；
  • 结果可以被检查，错误可在提交前发现；
  • 任务耗时长，但真正需要人的判断节点很少；
  • 有明确权威数据源和完成标准。

例如销售线索研究、CRM 清理、周报汇总、费用核对、客服草稿、Bug 复现、内容排期和招聘初筛。

不适合一开始就完全放权的，是不可逆支付、法律承诺、生产删除、权限授予、高风险医疗/金融决策，以及没有可靠验收标准的开放任务。

7.5、最终判断

Grok Bot 不一定已经解决了 Agent 的可靠性、成本和安全问题，但它给出了一个很有说服力的产品答案：

通用 Agent 不该只是一个塞满工具的聊天框，而应该是拥有持续工作环境、岗位记忆、协作关系和审批边界的数字同事。

“模型能不能做”只是起点；“任务能不能在真实系统中结束、用户能不能放心离开、关键动作能不能被控制”，才决定 Agent 能否从演示走进日常工作。这也是 Grok Bot 当前最大的亮点与行业价值。

八、官方文档导航

主题 官方链接
产品主页与定价 https://x.ai/bot
安装与首次任务 https://docs.x.ai/grok-bot/get-started
创建、管理与记忆 https://docs.x.ai/grok-bot/bots
消息、语音与协作 https://docs.x.ai/grok-bot/chat-and-collaboration
云电脑与 App https://docs.x.ai/grok-bot/computer-and-apps
文件与交付物 https://docs.x.ai/grok-bot/files-and-results
Vault 与安全登录 https://docs.x.ai/grok-bot/vault
Skill 与 Routine https://docs.x.ai/grok-bot/skills-routines-and-automations
审批、安全与隐私 https://docs.x.ai/grok-bot/approvals-security-and-privacy
移动端 https://docs.x.ai/grok-bot/mobile
团队与企业 https://cursor.com/docs/grok-bot/teams
安全 FAQ https://cursor.com/docs/grok-bot/security-faq
更新日志 https://x.ai/changelog/bot

参考资料

[1]. Introducing Grok Bot - xAI

[2]. Grok Bot 产品主页与现行价格

[3]. Grok Bot 官方文档

[4]. Get Started - Grok Bot Docs

[5]. Use the computer and apps - Grok Bot Docs

[6]. Approvals, security, and privacy - Grok Bot Docs

[7]. Skills and routines - Grok Bot Docs

[8]. Grok Bot Changelog

[9]. Introducing The X Subscription - xAI

[10]. How we built Grok Bot in a month - Lenny's Podcast

[11]. Cursor is now a part of SpaceX - Cursor

[12]. xAI joins SpaceX - xAI

[13]. ReAct: Synergizing Reasoning and Acting in Language Models

[14]. Building effective agents - Anthropic

[15]. Computer use tool - Anthropic

[16]. OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments

[17]. LLM06: 2025 Excessive Agency - OWASP

[18]. AI Agent Security Cheat Sheet - OWASP

[19]. BOTROSTER - GitHub

[20]. Rakazo - GitHub

[21]. OpenMausBot - GitHub

[22]. OpenBOT - GitHub

[23]. OpenBot - GitHub

[24]. Celesto - GitHub

[25]. Browser Use - GitHub

[26]. OpenHands Runtime - GitHub

整理者：长路　创建时间：2026.10.28　更新时间：2026.10.30

AI agent云端AgentAI智能体Agent基础设施Grok Bot

评论区请在客户端页面查看