8 月 11 日，SpaceXAI 发布了 Grok Bot 的早期 beta 版——一个定位为"AI 队友"的 Agent 产品。与现有 Agent 工具的差异浓缩成一句话：每个用户的 Bot 共享一台永久的云电脑，能登录你日常使用的应用和网站，在你关上笔记本之后继续工作。
Grok Bot 面向 SuperGrok Heavy、Cursor Ultra（$200/月）和 Cursor Teams Premium（$120/席位/月）用户开放，覆盖 macOS、Windows、Linux 和 iOS 桌面端，Android 即将推出。Elon Musk 同时预告 Grok 4.6 将于本周晚些时候发布，届时扩大 beta 范围。
SpaceXAI 内部已先行部署数月。官方博客描述的场景包括：销售 Bot 从通话记录中提取信息更新 CRM 并起草跟进邮件，运营 Bot 处理 Gmail 中的发票并安排新员工入职，工程 Bot 在产品 UI 中复现 bug、提交工单并将修复方案交给调试 Bot。这些用例尚未经过独立验证，但清晰勾勒出了 Grok Bot 的目标——不是回答问题，而是完成需要跨应用操作的、多步骤的实际工作。
一台共享的云电脑
Grok Bot 的核心架构决策是"一台电脑、多个 Bot、共享状态"。官方 FAQ 明确：每个用户拥有一台持久化云电脑，该用户创建的所有 Bot 共享这台电脑的文件、浏览器会话和登录凭据。隔离边界在用户层级，而非 Bot 层级。
这一设计与当前主流 Agent 产品形成明确分野。Claude Cowork 提供远程会话和定时任务，但本地资源需要桌面应用保持连接；Manus Cloud Computer 提供专用持久化 Ubuntu 虚拟机，但云浏览器和沙箱环境相互隔离；OpenAI 的 ChatGPT Work 和 Codex 提供了广泛的连接器和工作面，但没有 Grok Bot 这种"一个用户、一台共享机器、一群 Bot"的模型。
共享架构的卖点清楚：采购 Bot 可以把供应商表格留给财务 Bot，客服 Bot 可以永久登录店铺后台，研究 Bot 不必每天早上重建环境。保存的流程和工作记录在 Bot 之间自然流转，不需要人工在不同聊天窗口之间粘贴笔记。
但同样的架构也把信任集中到了一个点。如果一个 Bot 打开恶意页面、处理了被污染的文件或执行了注入指令，它操作的是一台其他 Bot 也在使用的机器。为一个角色建立的浏览器会话可能被另一个 Bot 使用。一个错误的配置可以比创建它的任务活得更久。
Kingy.ai 的分析指出：SpaceXAI 将 Bot 命名为"队友"暗示了独立身份，但从公开文档看，它们在技术上更像是使用同一台工作站和同一串钥匙的不同操作员。Bot 级权限控制、最小权限访问、凭据分段、事件日志和恢复工具都未在公开材料中出现。
三次更名和一笔未完成的交易
Grok Bot 上线当天，一个细节引起了注意：SpaceXAI 的 Grok Bot 页面，所有下载链接指向 downloads.cursor.com，企业销售表单是 cursor.com/contact-sales，两个可购买的订阅方案叫 Cursor Ultra 和 Cursor Premium Teams——与 Cursor 现有的开发者套餐完全相同。App Store 上的 iOS 应用将开发商标注为 Anysphere（Cursor 母公司），而产品本身以 Grok 品牌在 SpaceXAI 网站上销售。
这是 SpaceXAI 与 Cursor 之间复杂所有权结构的最新注脚。时间线大致如下：
- 2026 年 2 月，SpaceX 以全股票交易收购 xAI，将其作为全资子公司，估值 $2,500 亿；
- 5 月完成合并，xAI 品牌逐步停用；
- 6 月 16 日，SpaceX IPO 后数日，宣布以 $600 亿全股票收购 Cursor 开发商 Anysphere——这是迄今金额最高的初创公司收购案；
- 7 月，xAI 正式更名为 SpaceXAI；同月 Grok 4.5 发布，这是 SpaceXAI 与 Cursor 联合训练的首个模型；
- 截至 Grok Bot 上线当日（8 月 11 日），$600 亿收购交易尚未正式完成交割。
据 The Information 报道，Cursor 内部代号 "Sand" 的通用 Agent 产品将重新命名为 Grok Bot，Cursor 品牌将在未来数月逐步退出新产品命名。Grok Bot 因此成为第一家以 Grok 品牌出货、基础设施和付费体系却完全依赖 Cursor 的产品——两家公司在法律意义上尚未合并，但在产品层面早已融为一体。
定位夹在中间
Grok Bot 进入了一个每个主要玩家都已布局的 Agent 市场，而它将自身定位在了一个微妙的中间地带。
在自托管一侧，OpenClaw（前身 Clawdbot/Moltbot）以 MIT 许可证开源，对话和长期记忆以 Markdown 和 YAML 文件存储在本地 ~/.openclaw 目录中，模型无关、可接入任何 API 或本地 Ollama 模型。代价是需要用户自行安装、加固、维护，并且只在宿主机在线时运行——这正是许多用户将其部署在 VPS 上的原因。
在云端一侧，Claude Cowork 提供远程会话、排程任务、连接器和显式的权限与管理模型，computer use 仍标注为研究预览。ChatGPT Work 和 Codex 提供最广泛的集成生态，但公开文档没有 Grok Bot 的多 Bot 共享电脑机制。Manus 提供专用持久化服务器和经过认证的云浏览器，但将命令行环境和浏览器环境分为不同层。
Grok Bot 的选择可以概括为：用共享持久化换取协作连续性，用云电脑消除本地运维负担，代价是更大的单一信任域和更不透明的安全边界。它在概念上最连贯——创建同事、给他们一台电脑、让他们记住并协调——但在工程上需要回答的问题也最多。
安全的问题清单
让 Agent 登录你的邮箱、CRM 和供应商账户，与让聊天机器人回答问题，两者要求的信任等级完全不同。Hacker News 上的早期反馈显示，用户对受控于 Musk 的 AI 系统持有长期登录凭据表达了不安，虽然具体的技术担忧未经独立核实，但指出了一个结构性事实：能登录你账户的 Agent 需要远比聊天窗口更高的信任门槛。
从公开材料中，以下五个问题的答案仍不明确：
凭据边界：公开 FAQ 说所有 Bot 共享登录信息，但没有说明管理员能否阻止一个研究 Bot 使用财务 Bot 的会话、为单个 Bot 分配凭据、设置按站点作用域或要求提权操作重新审批。
注入攻击面：一个网页、邮件附件或支持工单可以包含引导 Agent 行为的指令。当 Agent 只能生成文本时，攻击面是错误答案；当它能浏览已认证系统、移动文件和提交表单时，同一攻击可以变成未经授权的操作。Grok Bot 的"Auto Review"功能声称处理敏感操作，但公开材料未解释它如何区分合法指令和嵌入在不受信内容中的恶意指令。
隐私模式不等于数据流图谱：Cursor 的隐私模式在开启时阻止客户数据用于训练，但存在滥用监控例外和不支持零数据留存模型的情况。SpaceXAI 的消费者隐私政策允许第三方服务按各自政策处理数据。Grok Bot 的数据从云电脑流向何处、经过哪些子处理器、保留多久——这些映射尚未公开发布。
审批默认值：Grok Bot 需要审批才执行敏感操作，但哪些操作默认阻止、管理员能否定义审批类别、审批请求如何描述下游影响、用户是否会不经意间将"全部批准"正常化——这些问题均未说明。
审计和恢复：加密保护存储和传输中的数据，但不会告诉操作者 Bot 做了什么、为什么这么做、使用了哪个身份、如何撤销结果。防篡改事件日志、屏幕录制、命令历史、快照、凭据吊销行为和按时间点回滚——均未出现在公开文档中。
Grok 4.6 与下一步
Grok Bot 的 beta 扩展节奏与 Grok 模型的迭代速度直接挂钩。Musk 在 Bot 发布同日表示，将在"修复早期 beta 的基础问题后"扩大测试范围，时间点是 Grok 4.6 发布之后。
Grok 4.6 是一个 1.5 万亿参数的模型，复用 Grok 4.5 的 V9 基础架构，改进集中在监督微调和强化学习。原定的"8 月 7 日前后"目标已延至本周。如果 Grok 4.6 按时落地，这将是 SpaceXAI 在四个月内发布的第三个主要模型版本。
更大的图景是，Grok Bot 不是孤立的产品。SpaceXAI 的 Agent 产品线正在快速成形：Grok Build（5 月上线，终端编程 Agent，7 月开源了 harness 和 TUI）、Build Mode（7 月底上线，聊天内创建网站和应用）、Grok Automations（定时任务和触发器），现在加上 Grok Bot（持久化云工作 Agent）。从写代码到运行工作流再到 7×24 自主执行，每层都在补全。
这套矩阵的战略逻辑相当清晰：Cursor 提供桌面分发渠道和经过认证的用户群，Grok 提供模型家族和消费品牌，而持久化云电脑将联合体的野心从"帮助写代码"扩展到"运营业务工作流"。但这也同时提高了治理失误的代价。Grok 过去曾因生成有害内容引发监管审查——这些历史不意味着 Grok Bot 会重蹈覆辙，但意味着买方应要求证据，而不是将"队友"标签当作信任担保。
对于符合条件的团队，最合理的策略是进行一个狭窄的两周试点：选择一个频繁、可逆、容易打分的工作流，使用独立的测试账户和最小权限，保持输出为草稿状态，在文档中植入对抗性内容测试注入防护，测量完成率而非表面流畅度，在扩展权限之前确认错误率、控制措施和恢复流程可靠。
Grok Bot 的核心理念是对的：有用的 Agent 需要连续性。它们需要一个工作场所、持久状态、可复用流程和彼此传递任务的能力。一台共享的云电脑同时提供了这四样。但连续性把昨天的便利变成了明天的攻击面。真正的检验不是 Grok Bot 能否在你睡觉时工作，而是你醒来后能否精确证明它做了什么。