Grok Bot 大师班
**Grok Bot** 将状态从上下文窗口移入**一台持续运行的共享云计算机**,让多个 Bot 共享凭据与文件,实现**零成本交接**与**定时例程**,但

这里汇集了理解、配置并真正发挥 Grok Bot 作用所需的一切。它涵盖了 Bot 的实际定义、底层共享计算机的工作原理、与 Hermes Agent 的对比,以及如何自行运行它。
今年,运行 AI 代理的人群中悄然流行起一种习惯:他们让笔记本电脑半开,以便代理持续工作;一旦合上盖子,运行便会中断。

这种习惯属于那些在本地机器上运行的代理。托管型代理早已解决了合盖问题,并且在过去一年里,它们也在逐步解决记忆问题,一点一点地推进。
例如:
- Devin 在每次会话开始时恢复保存的机器快照,因此任何未提交或未捕获的内容都会丢失。
- Manus 在任务之间让沙盒休眠,并在长时间不活动后将其回收,同时提供始终在线的云端计算机。
- ChatGPT Work 保留浏览器 Cookie,因此一旦你通过接管流程登录某个网站,后续运行会自动识别。
上述每个方案都只为单个代理持久化某一种信息,通常局限于会话或项目范围。你仍然为每个任务获得一台机器,且代理列表之间不共享任何内容。
SpaceXAI 上周推出了 Grok Bot。它不再为每个任务提供一台机器,而是为每个人提供一台机器。它保持常驻,与你的账户绑定,并且整个 Bot 列表共享这一资源。

本指南涵盖了 Bot 的实际定义、系统底层的构建方式、与 Hermes Agent 及其他选项的对比、如何在 macOS 上进行配置,以及哪些角色值得优先构建。
阅读完本文后,你将能在自己的机器上拥有一个可用的 Bot 列表、一个保存的技能,以及一个在笔记本合盖时也能运行的例行程序。
让我们开始吧!
Grok Bot 是什么
一句话版本:Bot 是一个你向其发送消息的具名队友,而实际的计算发生在它下面一层。
“bot”这个词暗示了一个在别处运行的独立程序。它更接近于一个带有自身记忆的已保存角色,坐在一台与你创建的其他所有角色共享的机器上。
一个 Bot 由你编写的三样东西定义:

- 一个简短的名字
- 一项主要任务
- 以及一份关于它应如何工作的描述。
作为回报,你会得到一个持续的对话线程,Bot 会在各轮对话之间保持工作上下文。
根据官方文档,Bot 会保留稳定的工作偏好、重要事实以及工作摘要。它不会重放每一条先前的消息。
计算机是另一半。你账户上的每个 Bot 都使用一台持久的云计算机,带有浏览器、文件系统和终端。它分配给你的用户账户,而不是任何单个 Bot。
每个 Bot 在那台共享机器上都有自己的屏幕。因此,多个 Bot 可以同时驱动浏览器和桌面工具,尽管一个 Bot 在其屏幕上一次只运行一个计算机使用任务。

一个有用的类比是,你可以把它比作办公室环境。
云计算机就是办公室,每个 Bot 是一位拥有自己办公桌的同事。有不同的人、工作和笔记本,但只有一个文件柜和一套钥匙。
这个类比也解释了权衡之处,我们稍后会详细讨论。共享钥匙让交接变得免费。它们也意味着整个团队共享一套后果。
总之,一个 Bot 是一个角色加上一份记忆加上一个线程。底层的机器是单一的、持久的且共享的。
构建方式
在开始设置之前,我们先来看看各个部分是如何协同工作的。
具体来说,关于 Grok Bot,您需要了解以下五个部分:
持久化云端计算机
该计算机运行在 SpaceXAI 的云端,而非您的 Mac 上。因此,关闭应用或笔记本电脑不会中断后台任务或定时例程。

这里有一项持久性契约,意味着在 /workspace 下有一个共享工作区,文件、浏览器状态及受支持的登录信息均设计为在常规计算机更新和恢复过程中得以保留。
其他一切内容均明确为可替换的。临时目录、手动安装的软件包及未提交的应用状态不提供任何保证。持久化的项目文件应存放在共享工作区中。

SpaceXAI 尚未公布操作系统、镜像内容或机器规格。一位检查过环境的用户广泛分享的报告描述称,该系统为 Debian,配备约八个虚拟 CPU、约十六吉字节内存,以及百吉字节级别的磁盘,无 GPU。
共享模型
如前所述,您账户中的每个Bot都使用同一台计算机,文档详细说明了这具体意味着什么。
浏览器Cookie和登录会话是共享的。文件对所有Bot可见。命令行凭据也是共享的。一个Bot可以继续另一个Bot保存的工作。
这意味着,研究Bot可以保存文件,而写作Bot无需上传或额外登录即可获取该文件。交接过程无需任何成本,因为无需重新建立任何连接。

在这种共享设置下,如果账户中的其他Bot不应使用某个凭据或文件,则不应将其放置在计算机上。
操作层
Grok Bot有两种与服务交互的方式。
连接器为Bot提供了一条通往受支持服务的结构化路径。连接器在当前应用中显示为插件,并且是账户级别的,而非每个Bot单独拥有。

浏览器处理其他所有情况,如供应商门户、广告管理器、较旧的内部工具,以及任何没有简洁编程接口的服务。
理想情况下,当有可用的连接器时,应优先使用连接器,因为它通常比通过网站点击操作更可靠。

由于商业软件的编程覆盖范围可能有限,它会退回到像素级控制,这也意味着它会继承底层网站的每一个脆弱点。
因此,布局更改、新的同意提示或会话超时都可能破坏之前运行良好的工作流程。
认证与接管流程
会话在共享浏览器上持续存在,因此通常无需为每个任务重新登录。为一个Bot登录一次,该会话即可供其他Bot使用。
对于任何敏感操作,Bot会将机器控制权交还给您,例如密码、通行密钥、双重验证码、验证码、支付或身份验证,以及明确要求人工操作的网站。
实际操作中,您打开Agent Computer,接管控制,仅完成受阻步骤,交还控制权,并告知Bot继续执行。

对于支持的连接,系统会提供安全的秘密请求方式。该值会被隐藏,不记录在对话记录中,也不会展示给模型。

切勿在普通聊天中粘贴密码或一次性验证码。接管流程的存在正是为了确保这些值不进入对话记录。
Agent记忆
记忆按Bot分别维护。
复制一个Bot会复制其配置文件、设置、已启用的技能、例程和头像,但不会复制其对话历史或已学习的记忆。

该记忆背后的机制并未公开。无论是摘要缓冲区、磁盘文件、检索索引,还是某种组合,文档中均未说明。

总而言之,工程架构是一个持久化机器、一个以连接器优先并辅以浏览器回退的操作层、一个包含人工验证的认证流程,以及每个Bot独立的记忆,其内部机制保持私有。
机器人、技能与日常流程
与其他智能体一样,您应首先执行一个真实任务。随后修正输出直至其可靠。满意后,将方法保存为技能。
此视频展示了该过程:

一旦满意,再将其转化为日常流程。

正确创建机器人
按下Cmd和N键或点击“+”图标,选择创建新智能体,然后打开机器人操作并编辑资料,以设置名称、标题、描述和头像。
您也可以与机器人聊天,描述您的需求以填充这些信息:

描述中应包含需长期遵守的规则,而对话则承载任务特定的指令。
诸如“未经批准不得发送外部消息”的描述应置于资料中。“为这十二个账户起草后续跟进”则属于对话内容。
与其他智能体一样,具体任务优于泛化任务。
例如,人才搜寻者和费用管理者的角色为机器人提供了构建上下文的依据。而通用助手几乎无法提供任何上下文,其保存的上下文也难以复用。
一个账户最多可拥有50个机器人和群聊。从最小实用的配置开始,仅当某项工作具有稳定的专业角色时,再添加机器人。
技能
技能是一套可复用的任务执行指令集,涵盖了步骤、决策规则、预期输出及安全边界。
技能可在您的各个机器人间通用,但使用技能时,机器人可能仍需相应的连接器或登录权限。
在编辑器中输入正斜杠(/)即可引用已保存的技能,而提及机器人、群组、例程及连接器时,则使用@符号。
一个理想的技能应涵盖六项要点:
- 何时使用
- 所需输入与访问权限
- 工作流程顺序
- 如何验证结果
- 应返回的内容
- 以及哪些操作需经批准。
通过演示教学技能
当“教学任务”控件可用时,您可以通过展示浏览器工作流程而非文字描述来教学。
开启一对一对话及其计算机视图,选择“教学任务”,描述预期结果,执行一次工作流程,然后停止录制。
下方视频展示了这一过程:

教学录制可捕捉长达十分钟的可见计算机交互,但请注意,它不会录制麦克风音频。
录制降低了那些从不手动编写流程的人的门槛,同时也将完善该流程的工作转移给了人工。
重要提示:在网站、连接器或源格式发生任何变更后,需重新测试演示过的技能。仅通过一次网站操作学得的工作流程,无法抵御该网站的变化。
日常任务
日常任务为单个Bot分配工作流程,并告知其执行时机。定时调度是最常见的情形,在底层集成支持的情况下,也支持事件触发。
您可以通过向所属Bot用自然语言提出请求来创建日常任务。

一个良好的请求应明确调度时间与时区、输入来源、预期结果、审批边界,以及当某个来源缺失时应采取的措施。
事件触发通过Cursor账户集成实现,例如Slack消息或GitHub通知。这些与Slack和GitHub插件是分开的,可能需要各自的连接流程。
在启用任何功能前,请先进行测试运行。测试运行会执行实际操作,因此请确保输入安全,并将写操作置于审批之后。
一个Bot最多可拥有50个日常任务,应用会为每个任务保留最近20条运行记录。删除日常任务是永久性的,且不支持撤销。
总之,技能描述如何执行,日常任务决定何时执行,而从一个可工作的任务到安全自动化之间的差距,则由您来填补。
与多个Bot协作
单个Bot已足够实用,但理想情况下,添加第二个Bot是为了拥有另一个稳定的专业角色。
群聊可容纳两到六个Bot,用于需要可见性的交接任务。你选择Bot,描述共同目标,并指定谁负责下一步。

你可以正常互动,参与的Bot会决定由谁回应。
或者,当某个团队成员负责请求时,你可以使用“@”符号,并将“所有人”提及保留给真正的群组更新。
Bot之间也会在群组外异步通信。接收的Bot被唤醒,处理请求,稍后回复,交接过程在对话中保持可见。
目前的一个限制是,Bot到群组的交接消息仅支持文本,因此需要另一个Bot检查图像的Bot应直接发送图像。
理想情况下,每个阶段只请求一个Bot。过多的并行交接会导致重复工作和嘈杂的更新,这是当Bot数量超过四五个时常见的失败模式。
你直接发送的消息优先级高于后台工作,可以重定向当前回合。
自动审查
在可用的情况下,Grok Bot 会在工具调用和计算机操作执行前对其进行评估。
- “需要批准”规则始终会阻止匹配的操作。
- “始终允许”规则仅在自动审查未发现其他阻止原因时,才允许匹配的操作继续执行。
- 当两者同时匹配时,“需要批准”规则优先。

需要注意两个重要事项:
- 自动审查基于模型,因此文档将其定位为最小权限原则的补充,而非替代。
- 个人规则存储在当前桌面并同步到其计算机,这意味着第二次安装需要单独检查。

对本地计算机的影响
至此,应该清楚云计算机和你的 Mac 是两回事。
Bot 仅在启用该功能且你批准时,才会在本地运行命令。

该设置可在“设置”->“通用”->“代理”->“本地计算机执行”下找到。
除非 Bot 有特定理由处理你的本地文件,否则将本地执行设置为“从不允许”。这不会以任何方式限制云计算机。
Grok Bot 与 Hermes Agent 对比
两者都为智能体提供了持久化的计算机环境,但相似之处仅止于此。
Hermes 是开源且支持自托管的。您需要自行准备机器,无论是家中的 Mac Mini 还是虚拟专用服务器,并在其上运行智能体。而 Grok Bot 则是一项托管服务,机器由服务商为您配置,您无需直接接触。

两者差异在记忆与技能方面体现得最为明显。
- Hermes 将两者以文件形式呈现,您可以直接阅读和编辑。身份信息存储于 SOUL.md 中,事实记录于 MEMORY.md 和 USER.md 内,并设有严格的字符限制;会话记录可在 SQLite 中搜索;技能则是带有结构化前置元数据的 Markdown 文件,由智能体自行编写和修订。
- Grok Bot 则完全不提供此类文件。其记忆通过行为而非格式来描述,技能需通过界面查看,而非直接打开文件。
Hermes 还附带维护机制,Grok Bot 并无对应功能。后台的 Curator 会自动修剪和归档智能体编写但未使用的技能;配套的 GEPA 流水线则基于执行轨迹离线演化技能,而非让智能体自我评估。
Grok Bot 的优势则体现在另一方向。多智能体协作是其产品的一等公民功能,而非需要自行拼装的组件。群聊、异步交接、所有权转移以及跨成员共享的浏览器会话,均无需配置即可使用。
选择的关键在于谁承担运维工作。Hermes 提供可检查的文件和真正的隔离性,但要求您自行运行和维护机器。Grok Bot 则免除了维护负担,同时也带走了隔离性。
更广阔的格局遵循同样的主轴。ChatGPT Work 和 Claude 的计算机使用功能都能操作软件,但两者都不会像这样维持一台带有持久登录状态的常驻机器。Devin 和 Manus 为每个任务或项目提供一个沙盒环境,而这正是 Grok Bot 所摒弃的模式。
在 macOS 上进行设置
整个设置过程只需几分钟即可完成。
所有说明均在此处列出:https://docs.x.ai/grok-bot/get-started。
基本上,打开 Grok Bot 访问页面,选择对应的下载版本。
打开磁盘映像,将 Grok Bot 拖入“应用程序”文件夹,然后启动它。如果 macOS 弹出提示,点击“打开”确认。
在欢迎屏幕上选择“开始”,在打开的浏览器窗口中完成身份验证,然后返回应用。使用单点登录的组织在此处完成其常规流程。
随后,引导流程会介绍 Bots、共享计算机和例程,并询问你使用哪些工具。你的回答会塑造首批队友建议,但本身不会连接或修改任何内容。

在此过程中,你的云计算机会在后台完成配置,最后一步会打开“遇见未来队友”页面。
接下来,选择一个建议的队友,或选择“创建自己的队友”,然后为其指定一个简短名称、一项主要职责,以及对其工作方式的描述。
一个强有力的首次请求包含五个部分:
- 你希望完成的结果
- 重要的信息来源
- 它必须避免或需要询问的限制条件
- 交付物
- 以及它应在何处停下交由你接手。
从一个无需任何登录的任务开始,比如附加一份文档并要求生成带有引用的结构化摘要,大约五分钟内就能得到结果,同时确认机器运行正常。
当 Bot 遇到需要身份验证的服务时,它会将计算机交给你。从对话中打开 Agent Computer,接管控制权,输入密码、通行密钥或双重验证码,然后交还控制权。
会话随后会在共享计算机上持续存在。您账户上的其他每个 Bot 现在都可以使用它,这正是共享边界从理论变为现实的时刻。
对于受支持的服务,请改为从“设置”和“插件”中安装连接器。在存在连接器的情况下,这是更可靠的路径。
最后,一旦结果可重复,请让 Bot 将方法保存为命名技能。包括源系统、输出格式以及关于哪些内容需要审批的规则。
只有在那之后,您才应创建例程。
作为要点,不要在第一份良好输出时就急于自动化。文档中规定的顺序之所以存在,是因为例程继承了构建它的任务中所有未言明的假设。
总结
Grok Bot 背后的设计决策说起来简单,但影响深远。状态从上下文窗口移出,进入了一台持续运行的机器中。
这样,两个 Bot 之间的交接无需成本,也正是让例程能在早上八点、在您笔记本电脑关机的情况下自动触发的原因。
这也是文档告诉您不要将独立 Bot 视为安全边界的原因,因为自由交接和共享凭据是同一事实的两个方面。
实际路径正是文档所规定、而大多数人跳过的那条。一个窄范围的 Bot,一个真实任务,不断修正直到输出可审查,然后是技能,再是例程,任何重要操作都置于审批之后。
与 Hermes 相比,您是用可检查的文件和真正的隔离,换取一台无需您自己运行的机器。这笔交易哪边更划算,完全取决于您愿意在一台看不见的计算机上登录什么。
随着 beta 版的发展,我会继续撰写关于 Grok Bot 的文章,尤其是在企业控制和任何每 Bot 隔离功能落地之后。
这就是全部内容!
如果您喜欢本教程:
找到我 → @_avichawla
每天,我都会分享关于 DS、ML、LLM 和 RAG 的教程与见解。