Grok Bot 是 xAI 的常驻工作 Agent。用户可以给 Bot 一台云电脑，让它登录工作应用，通过消息分派任务，并在用户离开后继续运行。它不是 X 或 Grok 应用里的普通问答功能：Grok 主要负责回答，Grok Bot 的设计目标是在多个工具中执行操作，再把完成结果交给人验收。
xAI 于 2026 年 8 月 11 日发布 Grok Bot Beta。此后，产品陆续扩展了套餐范围、X 集成、共享 Team Bots、Routine 和企业控制。下面重点回答三个问题：它究竟怎样工作、云电脑模式增加了哪些风险，以及接入真实账号前该怎么测试。
**信息核对截至 2026 年 10 月 13 日。**文中所称当前接入、订阅、平台与 Beta 状态均以该日期为准。
一句话说明 Grok Bot
Grok Bot 是一个拥有独立云电脑和持续会话的 AI Agent。根据 xAI 的发布公告，Bot 可以使用浏览器与终端，登录应用，跨服务完成任务，并在用户电脑关闭后继续运行。
它与普通聊天机器人有四个本质差异：
- **直接在目标工具里执行。**它可以更新 CRM、处理邮箱或提交工单，而不只是写一段操作建议。
- **持续运行。**云电脑不会因为用户离开而立即停止，但仍受套餐、权限和产品限制约束。
- **保留协作上下文。**xAI 称 Bot 会记住对话、修改意见和用户偏好。
- **能与其他 Bot 协作。**多个专业 Bot 可以并行执行、互发消息或进入同一群聊。
因此，Grok Bot 更像托管式数字员工，而不是一个模型选择器。真正决定效果的不只有模型，还有云电脑、账号、权限、记忆、复核规则和审计记录。
我们的持久化 AI Agent 指南进一步解释了这个品类，并区分真正的持久性——状态、身份和可接续任务——与单纯保留很长的聊天记录。
Grok、Grok Bot 与 @bot 不是同一个东西
| 入口 | 作用 | 常见交互 |
|---|---|---|
| Grok | 回答、分析和内容生成 | 提问或生成内容 |
| Grok Bot | 借助云电脑跨应用执行任务 | 分派工作并验收结果 |
X 上的 @bot | 把 X 上的请求转交给已连接的 Grok Bot | 在帖子或回复中提及 @bot |
X 上的 @Grok | 直接与 Grok 交互 | 在 X 内向 Grok 提问 |
X 的@bot 官方帮助页明确说明，@bot 不会自己回答，而是把请求转发给用户连接的 Grok Bot。这个区别关系到隐私和任务预期：被转发的请求可能调用已连接应用和长时 Agent，而不只是产生一条公开回复。
云电脑模式如何工作
云电脑是 Grok Bot 最关键的架构选择。它不用等待每个服务都提供完整 API，而是可以打开浏览器或终端，使用人与软件交互的界面。这使它能覆盖旧系统和分散的应用。
代价是可靠性更复杂。页面布局会变化，登录会过期，验证码会出现，界面显示成功也不等于数据已正确保存。能够点击页面，不等于能够稳定完成业务流程。
Routine 用来提高重复执行能力。官方称，用户可以让 Bot 跟随一次实际操作，保存流程，吸收修改意见，以后再次运行。更稳妥的理解是：Routine 是一份可执行流程，需要明确负责人、输入、成功条件和异常出口，而不是“教一次就永远不会出错”。
Grok Bot 能做什么
xAI 展示过销售、运营、财务、产品、工程和营销等案例。比部门名称更重要的是共同特征：任务有明确输入、有限的系统范围和可验收结果。
适合优先试点的任务包括：
- 调研客户并准备待审核的外联草稿；
- 根据通话记录更新 CRM；
- 分类邮箱，把模糊或高风险内容交给人处理；
- 复现产品问题并提交带证据的工单；
- 对账并标记异常记录；
- 连接官方 X 插件后，搜索帖子、检查提及、追踪趋势或管理书签。
X 集成公告确认了搜索帖子、阅读时间线、检查提及、获取趋势和管理书签等能力。研究和监控确实会受益，但权限仍应收敛到当前流程真正需要的范围。
多 Bot 不等于自动更准确
xAI 支持同时运行多个 Bot，也展示过由“主管 Bot”协调专业 Bot 的组织方式。2026 年 9 月发布的 Team Bots 进一步提供团队共享的上下文、工具和记忆。根据官方公告，团队可以给一个 Bot 配置文件、指令、技能和授权系统，再让成员共同使用。
任务能够真正拆分时，并行会节省时间，例如研究、写作和复核分别进行。如果所有 Bot 都依赖同一条缺失事实，或者没有人负责最终决策，多开几个 Agent 只会增加活动量。
增加 Bot 前，应先明确谁负责最终产物、哪些上下文可以共享、哪些动作必须交给人、冲突结果如何裁决，以及证据和最终记录存在哪里。
接入范围和价格为什么要看实时页面
Grok Bot 首发时只面向部分 SuperGrok 与 Cursor 订阅。xAI 随后把它扩展到 SuperGrok、Cursor Pro 和 Cursor Teams 等套餐，并说明 Bot 有独立用量，不占原有 Grok 与 Cursor 用量。之后，产品又被纳入更广的 X Subscription，企业接入也已公布。
这段变化说明，旧文章中的固定套餐价很容易过期。当前 X Subscription 同时打包多款产品，不同组织的用量池和权限也可能不同。购买前应查看实际账号和X Subscription 官方公告，不要沿用首发日价格表。
平台范围也在持续变化。首发公告列出桌面端和 iOS，后续版本又扩展了组织能力与集成。尤其是 Beta 功能与 @bot 这类早期入口，可用范围和界面文案都可能继续调整。
真正的安全问题不只是模型是否会拒答
让 Agent 拥有云电脑，与向聊天窗口发送提示词不是同一种风险。关键资产变成登录凭据、活动会话、已连接数据，以及 Bot 修改外部系统的权限。
负责任的试点至少要回答五个问题：
- **身份：**Bot 使用独立服务账号，还是直接继承个人的广泛权限？
- **最小权限：**它是否只能访问当前任务需要的文件、应用和记录？
- **审批：**发送、删除、购买、发布、改权限等动作是否必须停下来等人确认？
- **审计：**复核者能否还原 Bot 打开、修改和发送了什么？
- **恢复：**能否撤销凭据、回滚改动，并安全接续中断任务？
Grok Bot 官方更新日志已经记录审批功能与企业操作记录，但“存在功能”不等于“已经按本组织要求配置好”。接入生产凭据前，应先用非敏感账号验证控制链路。
X 的 Grok 帮助文档也提醒，AI 可能自信地给出错误事实或遗漏上下文。当 Agent 会执行操作时，同一个错误会比聊天中的错答造成更大影响。高影响动作必须有独立于模型自信程度的核验步骤。
哪些情况适合，哪些情况不适合
如果工作分散在多个网页工具中，需要在用户离开后继续执行，会重复发生，并且最终结果可以由人检查，Grok Bot 值得测试。缺少成熟 API 的系统尤其符合它的云电脑优势。
如果现有确定性自动化已经稳定处理流程、数据不能离开受控环境、任务没有客观完成标准，或 Agent 必须获得广泛管理员权限，它就不是理想起点。固定的“条件—动作”流程通常更适合传统工作流引擎；一次性问答则直接用 Grok 更简单。
如果仍在判断该选固定编排还是自适应 Agent，可以参照工作流构建器与 AI 工作区对比，按可预测性、判断需求和工具权限进一步拆分。
如何做一个不过度授权的试点
先选一个低风险、完成标准明确的流程。尽可能创建专用账号并收紧权限，再准备正常案例、模糊案例和故障案例，例如登录过期或必填字段缺失。
验收时不要只看 Bot 是否“说完成了”，而要检查：目标系统是否真的发生正确变化；外部事实是否有证据；该审批时是否停下；复核者能否看懂执行记录；任务多久需要一次人工恢复；保存后的 Routine 下一次是否仍然稳定。
第一个流程稳定之后再扩大范围。一个能处理单个邮箱的 Bot，不应因此自动获得 CRM、财务、发布和管理员权限。
结论
Grok Bot 试图把 AI 助手变成常驻执行者。云电脑、应用登录、Routine、多 Bot 协作和 X 集成，让它能直接在工作发生的地方完成任务；同样的能力也让身份、权限、审批、日志和恢复成为选型核心。
真正的问题不是“Grok Bot 能不能打开我们的工具”，而是“我们能否把工作限定清楚、看见每一个关键动作，并独立核验结果”。能够做到，就值得从受控试点开始；做不到，常驻 Agent 只会让不确定性持续得更久。
https://floatboat.ai/zh/blog/grok-bot