你是不是也有过这种窘境：AI 代理刚跑到一半，你合上电脑去开会，回来任务直接断在半空？很多人以为这是“云端智能”的必然限制，其实只是架构没设计好。Grok Bot 出现后，这个老问题被换了一种方式解决——不是每个任务一台机器，而是每个人一台持续在线的云电脑。
今年，大量尝试 AI 代理的人悄悄养成了一个奇怪习惯：笔记本盖子只敢半合，让风扇吵着也不敢完全关机。原因很简单，一旦彻底合盖，本地运行的代理就会被系统挂起，长任务、爬数据、自动化流程统统中断。有人甚至专门买支架，把电脑立着“保持清醒”，听着就有点心酸。
这种尴尬主要发生在本地机器上跑的代理。托管型代理早就绕开了“合盖即死亡”的问题，过去一年也在一点点补齐内存和状态持久化的短板。比如 Devin 会在每次会话启动时恢复一份机器快照，没提交的改动就算白干；Manus 会让沙箱在任务间休眠，长时间不用就回收，但同时给你一台始终在线的云电脑；ChatGPT Work 则通过保留浏览器 Cookie，让你登录一次网站后，后续任务都能沿用同一会话。
这些方案有个共同点：它们只为“单个代理”或“单个项目”保留一小块持久状态。每个任务像租一间临时工位，用完就撤，代理之间几乎没有共享。你会发现，研究代理下了个文件，写作代理还得再登一次同一个网站，重复劳动非常多。
SpaceXAI 上周发布的 Grok Bot，直接把这个模型翻了个面。它不是“每个任务一台机器”，而是“每个人一台机器”。这台云电脑长期挂在你的账户名下，你创建的所有 Bot 都在这台机器上工作，像一群同事共用一个办公室。
这篇大师课会拆开 Grok Bot 的几层结构：Bot 本质是什么、底层云电脑如何工作、它和 Hermes Agent 以及其他主流方案的关键差异、在 macOS 上的实际安装步骤，还有哪些角色值得你优先构建。读完后，你应该能在自己的账户下搭出一份可用的 Bot 列表，保存好技能和例程，让它们在你合上笔记本后依然按计划运转。
Grok Bot 究竟是什么
Bot：不是程序，而是“有记忆的队友”
一句话说清：Grok Bot 里的 Bot，是一个可以对话的命名队友，真正的计算发生在它背后的共享云电脑上。很多人一听“Bot”就会联想到一个独立进程或容器，其实在这里，它更接近“带独立记忆的角色配置”，驻留在一台所有 Bot 共享的机器里。你为每个 Bot 写三样东西：一个简短名字、一句主要工作、以及一段它应该如何做这份工作的描述。
作为交换，你得到的是一个持久的对话线程，Bot 会在多轮对话中保留上下文。官方文档的说法是：Bot 会记住稳定的工作偏好、关键事实和工作摘要，但不会机械地重放所有历史消息。也就是说，它更像记住“习惯”和“结论”，而不是记住每一句话。
另一半是那台云电脑。你账户下所有 Bot 共享一台持久的云计算机，里面有浏览器、文件系统和终端，这台机器绑定的是“你这个用户”，而不是某一个具体 Bot。每个 Bot 在这台机器上有自己的“屏幕”，可以同时驱动浏览器和桌面工具，不过单个 Bot 在任意时刻只会跑一个计算任务。
在官方文档里，“Bot”指的是一个持久的命名代理，而不是一台独立机器、一个容器或一个单独的模型实例。
一个很好用的比喻是办公室。云计算机是办公室，每个 Bot 是有自己办公桌的同事。大家有不同的职责、不同的笔记本，但共用一个文件柜和一把门钥匙。共享钥匙让交接几乎没有成本，但也意味着所有 Bot 共享同一套后果——谁搞乱了文件柜，大家都要收拾。
如果压缩成一句话：Bot = 角色 + 记忆 + 对话线程；底层机器 = 单一、持久、所有 Bot 共享的云电脑。
架构总览：五个关键部件
动手配置前，先把 Grok Bot 的骨架看清楚，会少踩很多坑。整体上，它由五个部分组成：持久云计算机、共享模型环境、操作层（连接器 + 浏览器）、认证与接管流程，以及按 Bot 维护的记忆系统。我的感觉是，这套设计有点像“把传统运维团队的习惯搬进了 AI 代理世界”。
持久云计算机
Grok Bot 的计算并不跑在你的 Mac 上，而是跑在 SpaceXAI 的云端机器里。你关掉应用、合上笔记本，后台任务和定时例程照样继续执行，不会被本地系统挂起。
这台机器有一块被明确标记为“耐久”的共享工作区 /workspace，这里的文件、浏览器状态和支持的登录信息，会在正常更新和恢复中被保留。其他地方就不一定了：临时目录、你手动装的包、未提交的应用状态，都可能在某次更新后消失。所以要养成一个习惯：所有你希望长期存在的项目文件，都放进 /workspace。
SpaceXAI 没公开操作系统镜像和硬件规格，不过有用户实际登录环境检查过：系统是 Debian，大约 8 个 vCPU、16GB 内存、百 GB 级别磁盘，没有 GPU。这种配置对日常办公自动化、网页操作、轻量开发足够，但不适合大规模训练模型或重度视频渲染。
共享模型与共享环境
前面提到，你账户下所有 Bot 共用一台云电脑，这个“共享”在实践中有不少影响。浏览器 Cookie 和登录会话是共享的，文件对所有 Bot 可见，命令行里的凭据也共用。一个 Bot 可以直接接着另一个 Bot 的工作往下做，比如研究 Bot 把数据拉下来，写作 Bot 直接打开同一个文件继续写。
这听起来很爽，但也有明显风险：不该被其他 Bot 看到的凭据或文件，就不该放在这台共享机器上。尤其是多人共用一个账户时，权限边界会变得非常模糊。有用户反馈过，把个人银行导出的账单放在 /workspace，结果财务自动化 Bot 也能看到，这种场景就很尴尬。
操作层：连接器优先，浏览器兜底
Grok Bot 和外部服务交互有两条路。连接器提供结构化访问路径，在应用里表现为“插件”，是账户级别的，不是某个 Bot 独享。比如 Slack、GitHub、Notion 之类，只要你在设置里装了插件，所有 Bot 都能用。
剩下的所有东西——供应商后台、广告管理器、老旧内部系统、没有 API 的 SaaS——都交给浏览器来处理。Grok Bot 会像一个远程操作员一样点页面、填表单、拉滚动条。经验上，能用连接器就别用网页点击，因为连接器通常更稳定、更可预期。
浏览器操作本质上是像素级控制，底层网站有多脆弱，它就有多脆弱。页面布局一改、新弹出一个 Cookie 同意框、会话超时弹个登录窗，都可能让昨天还跑得好好的流程今天直接翻车。有用户统计过，自己录制的网页自动化流程，平均每 3–4 周就要重测一次。
认证与接管：人机协作的关键一环
Grok Bot 会在共享浏览器里持久化会话，所以你不需要每个任务都重新登录。一次登录，后续所有 Bot 都能复用。但涉及敏感操作时，它会主动把机器“交还”给你，比如输入密码、通行密钥、双因素验证码、支付确认、身份验证，或者网站明确要求人工操作的步骤。
实际体验是这样的：Bot 提示需要你接管，你点开“代理计算机”，看到那台云电脑的实时画面，自己动手完成阻塞步骤，然后点“交还控制”，告诉 Bot 可以继续。这个过程有点像远程桌面，只不过你是在帮 AI 过一道安全门。
支持的连接会用“安全密钥请求”的方式来要凭据，这些值会被掩码处理，不写进对话记录，模型本身也看不到。你在界面里能看到一个“钥匙孔”图标，提示这是安全字段。
一个很重要但经常被忽略的点：不要把密码或一次性验证码直接贴在普通聊天里。接管流程就是为了避免这些信息进入对话记录，降低泄露风险。有用户图省事，把 2FA 码发在聊天里，结果日志导出时才发现全被记录下来了。
代理记忆：按 Bot 分区，但实现细节是黑盒
Grok Bot 的记忆是按 Bot 维护的。你复制一个 Bot，会复制它的配置、设置、启用的技能、例程和头像，但不会带上对话历史和“学到的记忆”。
记忆机制本身没有公开，文档也没说是摘要缓冲、磁盘文件、检索索引还是几种方式的组合。你只能从行为上推断：它会记住你强调过几次的偏好、长期项目的关键事实，但不会无限增长到拖垮性能。
如果从工程视角看，可以把 Grok Bot 理解成：一台持久云电脑 + 以连接器优先、浏览器兜底的操作层 + 人工介入的认证流程 + 按 Bot 划分的私有记忆。这个组合在目前的 AI 代理产品里算是比较激进的一种。
Bots、技能与例程：三层抽象怎么配合
从真实任务到“技能”
和其他代理一样，Grok Bot 的推荐用法是：先让 Bot 跑一个真实任务，边跑边修，直到输出稳定可靠，再把这套做法保存成“技能”。
当你对结果满意后，就可以把这项技能进一步包装成“例程”，让它按计划自动执行。
正确创建一个 Bot：角色比“万能助手”更重要
你可以按 Cmd+N 或点击“+”图标，选择“创建新代理”，打开 Bot 配置界面，设置名称、标题、描述和头像。也可以直接和系统对话，让它根据你的描述帮你生成一份配置草稿。
配置描述里写的是“这位队友应该遵守的规则”，对话里写的是“这次具体要干什么”。比如“未经你批准不得发送外部邮件”属于配置档案，而“帮我给这 12 个客户写跟进邮件草稿”属于对话线程。越具体的任务，越能让 Bot 学到可复用的上下文。
很多人一上来就想做一个“通用助手”，结果发现它什么都懂一点，但什么都不够深。相比之下，“人才侦察专员”“费用报销管理员”这种角色型 Bot 更容易积累稳定记忆。你可以把它理解成：给 Bot 一个岗位，而不是一个模糊的“助理”头衔。
一个账户最多可以拥有 50 个 Bot 和群聊。更好的做法是从一份“最小可用列表”开始，只有当某个任务已经稳定到像一个岗位时，再为它单独创建 Bot。
技能：可复用的“操作手册”
技能是可反复调用的任务执行说明，里面应该写清楚步骤、决策规则、预期输出和安全边界。
技能可以跨 Bot 复用，但前提是 Bot 本身有对应的连接器或登录权限。你可以通过输入斜杠 / 来引用保存的技能，用 @ 提及 Bot、群组、例程和连接器。一个理想的技能，至少应该包含这六点：
- 适用场景：什么时候应该用这项技能
- 所需输入和访问权限：需要哪些账号、文件或数据源
- 工作顺序：大致分几步，每步做什么
- 结果校验：如何判断这次执行是成功的
- 返回内容：应该给你什么形式的输出
- 审批边界：哪些操作必须先征求你同意
通过示范教学技能：录一遍，代替写文档
当“教学任务”控件开放时，你可以直接演示一次浏览器工作流，而不是写一大段文字说明。打开和某个 Bot 的一对一对话，切到它的计算机视图，选择“教学任务”，先用自然语言描述你想要的结果，然后完整执行一遍流程，最后停止录制。
录制最长支持 10 分钟的交互，不会录麦克风音频。对很多人来说，这种方式比写 SOP 文档轻松太多，也更贴近真实操作。你把“流程怎么走”这件事交给人类一次性演示，后面就交给 Bot 去模仿和泛化。
重要提醒：一旦网站、连接器或数据格式有变动，一定要重新测试这些示范技能。通过一次录制学到的工作流，并不能自动适应页面改版。
例程：让技能按时间或事件自动跑
例程的作用，是把某个工作流分配给具体 Bot，并指定它什么时候运行。最常见的是定时任务，也支持事件触发（前提是底层集成支持，比如来自 Cursor 的触发）。你可以直接用自然语言对某个 Bot 说“帮我创建一个例程”，让它来起草配置。
一个靠谱的例程请求，通常会包含：计划名称和时区、输入来源（比如某个文件夹或 Slack 频道）、预期结果、审批边界，以及当输入缺失时应该怎么处理。事件触发目前主要通过 Cursor 账户集成，比如 Slack 消息、GitHub 通知等，需要你单独完成连接流程。
启用例程前一定要先测试一遍。测试会执行真实工作，所以要确保输入是安全的，并且对高风险操作设置审批。很多人一上来就开自动化，结果例程按错误逻辑批量发了邮件，这种翻车案例已经不止一两个。
每个 Bot 最多可以拥有 50 个例程，应用会保留每个例程最近 20 条运行记录。删除例程是不可逆的，删前要确认没有关键业务依赖它。
如果用一句话区分：技能描述“怎么做”，例程决定“什么时候做”，中间那段“要不要做、做到什么程度”的判断，还是要靠你来填补。
多 Bot 协作与自动审核
多 Bot 协作：像开小型项目组
一个 Bot 能解决的问题有限，真正有意思的是当你开始组建一个小团队。群聊可以包含 2–6 个 Bot，适合那些需要可见交接的场景。你选好参与的 Bot，说明共同目标，再指定下一步由谁负责。
你可以像平时聊天一样发消息，由参与的 Bot 自己决定谁来回答。也可以用 @ 点名某个 Bot，或者用 @everyone 做群体更新。Bot 之间还可以互相发私信，接收“唤醒请求”，等有空再处理，交接过程会记录在各自的对话里。
目前的一个限制是：Bot 给群组发的交接消息只能是文本，不能带图片。如果你需要它发截图或图表，得直接发给目标 Bot。说实话，这个限制在处理设计、数据可视化类任务时有点别扭，希望后续版本能放开。
更健康的做法是每个阶段只指定一个 Bot 负责。并行拉太多 Bot 上场，很容易出现重复劳动和噪音，尤其是超过四五个 Bot 时，信息流会变得非常混乱。
你自己发的消息优先级最高，可以随时打断或重定向当前轮次。简单讲，你永远是这个群聊里“话语权最大”的那个人。
自动审核：别把安全全交给模型
在支持的场景下，Grok Bot 会在执行工具调用和电脑操作前做一次自动审核。你可以配置两类规则：
- “需要审批”的规则：只要匹配，就一律拦截，等你手动批准
- “始终允许”的规则：在自动审核没发现问题时，直接放行
两类规则同时命中时，“需要审批”优先。
有两点要特别注意：
- 自动审核本身是基于模型的判断，官方文档也强调，它应该是“最小权限原则”的补充，而不是替代。换句话说，不要因为有审核就乱给权限。
- 个人规则是存储在当前桌面并同步到那台云电脑上的。如果你换了一台本地设备登录，要记得再检查一遍规则是否同步。
本地机器的角色：默认别让 Bot 动你电脑
说到这里，应该已经很清楚：云计算机和你的 Mac 是两台完全不同的机器。Grok Bot 只有在你明确允许时，才会在本地执行命令。
你可以在“设置 > 通用 > 代理 > 本地计算机执行”里调整权限。比较稳妥的做法是：除非某个 Bot 有非常明确的理由需要操作本地文件，否则就把选项设为“从不允许”。这不会影响它在云电脑上的任何能力，却能避免很多意外，比如误删本地文件、乱改配置之类的。
Grok Bot vs Hermes Agent：谁来管机器
记忆与技能：可检查文件 vs 黑盒界面
Grok Bot 和 Hermes Agent 的共同点，是都给代理配了一台持久计算机。但相似点大概也就到此为止了。Hermes 是开源、自托管的，你得自己准备机器（家里的 Mac mini、闲置服务器或 VPS），在上面跑代理；Grok Bot 则是完全托管的产品，机器由服务商提供，你看不到底层系统。
差异最明显的地方在记忆和技能：
- Hermes 把一切都暴露成文件：身份写在
SOUL.md，事实写在MEMORY.md和USER.md（有字符限制），会话记录可以在 SQLite 里搜索，技能是带结构化元数据的 Markdown 文件，代理可以自己读写和修改。 - Grok Bot 则把这些都藏在系统里，只通过界面暴露行为。你能看到“它记住了什么样的偏好”，但看不到底层是怎么存的，也不能直接编辑记忆文件。
Hermes 还提供了一些维护工具，比如 Curator 用来修剪和归档长期不用的技能，GEPA 用离线方式进化技能，而不是让代理自己给自己打分。Grok Bot 目前没有对应的“记忆维护后台”，更多是靠你手动管理技能和例程。
一个有意思的认知差异是：Hermes 把“代理当成一个可以自己维护知识库的程序”，而 Grok Bot 把“多代理协作”当成产品核心，记忆细节则交给平台托管。
多代理协调：Grok Bot 的强项
Grok Bot 的优势在于，多代理协调是它的默认形态，不需要你自己拼装。群聊、异步交接、所有权传递、共享浏览器会话，这些都开箱即用。你只要想好“谁负责哪块”，就能很快搭出一个小团队。
选择哪一个，本质上是在选“谁来承担运维”。Hermes 给你可检查的文件和更强的隔离，但你得自己养机器；Grok Bot 让你完全不用管机器，却要接受共享环境和黑盒记忆的权衡。
放到更大的生态里看也类似。ChatGPT Work 和 Claude 的“计算机使用”都能操作软件，但不会给你一台持久机器，也不会长期保留登录状态。Devin 和 Manus 则是“每个任务或项目一个沙箱”，这正是 Grok Bot 刻意放弃的模型。
在 macOS 上从 0 到 1 搭建 Grok Bot
安装与首登：几分钟搞定
整个安装过程其实很短。官方文档在这里：https://docs.x.ai/grok-bot/get-started?ref=dailydoseofds.com
基本步骤是：打开 Grok Bot 的访问页面，下载 macOS 版本；打开磁盘映像，把 Grok Bot 拖进“应用程序”文件夹，然后启动。macOS 会弹出安全提示，你点“打开”即可。欢迎界面里选择“开始使用”，浏览器会弹出一个认证窗口，你在里面完成登录，再回到应用。企业用户如果走单点登录，也是在这一步完成。
引导流程会简单介绍 Bots、共享计算机和例程，并问你平时常用哪些工具。这些答案只会影响系统给你的首批“队友建议”，不会自动帮你连接账号或改配置。
云计算机会在后台自动配置，最后一步是“遇见你的未来队友”。你可以从系统推荐里选一个，也可以点“创建自己的”，填上简短名称、主要工作和工作描述。
第一个任务：用 5 个要素写好请求
一个有力的首个请求，通常包含这 5 个要素：
- 你希望完成的结果
- 关键信息来源（文档、网站、数据库等）
- 必须避免或需要先问你的限制
- 交付物的形式（报告、表格、邮件草稿等）
- 什么时候应该暂停，等你确认再继续
建议从不需要登录的简单任务开始，比如上传一份文档，让 Bot 生成带引用的结构化摘要。大多数用户的体验是，几分钟内就能拿到结果，这既是一次功能测试，也是确认云电脑是否健康的一种方式。
当 Bot 第一次需要访问需要认证的服务时，它会把机器交给你。你点开“代理计算机”，接管控制，输入密码、通行密钥或双因素代码，然后把控制权还给 Bot。之后，这个登录会话会在共享云电脑上持续存在，你账户下的其他 Bot 也能直接使用。
支持的服务，尽量从“设置 > 插件”里安装连接器，这比纯网页操作稳定得多。有用户反馈，用连接器跑的例程，连续运行一个月都没出过错，而同样逻辑的网页点击版本，每周都要修一次。
当你发现某个任务的结果已经可以稳定复现，就可以让 Bot 把这套方法保存成一个命名技能，写清楚源系统、输出格式和审批规则。等技能成熟后，再考虑把它包装成例程。
一个容易被忽略的经验：不要急着把第一次跑顺的流程直接自动化。官方文档的顺序是有道理的——例程会继承任务中所有隐含假设，如果这些假设没被你说清楚，自动化只会把错误放大。
关键 takeaway：把云电脑当“团队办公室”来用
Grok Bot 的底层设计看起来很简单：把状态从上下文窗口里搬出来，放进一台持续运行的云电脑。但这个选择带来的连锁反应非常大。两个 Bot 之间的交接几乎没有成本，例程可以在你合上笔记本后自动触发，登录状态和文件都能被整个“团队”复用。
同一时间，这也解释了为什么文档一再提醒：不要把不同 Bot 当成安全边界。免费交接和共享凭据，本质上是同一枚硬币的两面。你获得了一个高效的“虚拟办公室”，也要接受所有 Bot 共用一把钥匙的风险。
实践路径其实很清晰：先给一个专职 Bot 安排一个真实任务，反复修到输出可审查，再抽象成技能，最后才是例程，关键操作一律加审批。这个方法在不少团队里被反复验证有效，值得你收藏下来，遇到类似场景时照着走一遍。
如果你正纠结要不要把关键业务交给 AI 代理，这篇内容可能比问身边人更有用。你可以先从一个小角色开始试水，慢慢感受“把一整台云电脑变成团队办公室”是什么体验，然后再决定要不要把更多工作交出去。
常见问题
Q：Grok Bot 会一直占用一台云电脑吗，会不会很贵？
A：Grok Bot 为每个账户分配一台持久云电脑，但计费通常按使用套餐或席位来算，而不是按“机器在线时长”单独收费。原因在于，这台云电脑是为你的所有 Bot 共享设计的，平台会在资源层面做多租户优化，而不是给你一台完全独占的物理机。实际使用中，更关键的是控制好例程数量和任务复杂度，避免长时间跑无意义的重任务；如果你发现代理经常在跑一些可以合并的流程，优先优化技能和例程，比纠结“机器是不是一直开着”更划算。
Q：Grok Bot 访问公司内部系统安全吗，会泄露账号密码吗？
A：在设计上，Grok Bot 通过接管流程和安全密钥请求来保护敏感信息，密码和一次性验证码不会写入普通对话记录，模型本身也看不到这些字段。安全的关键在于：一是只在接管界面输入凭据，不要图省事直接发在聊天里；二是为高风险操作配置审批规则，避免代理在你不知情的情况下批量执行敏感动作。对于特别敏感的系统，可以考虑只在云电脑里登录低权限账号，或者干脆限制 Bot 不访问这类系统，把它当成“只读助手”来用。
Q：怎么判断一个任务适不适合做成例程自动化？
A：一个任务适合做成例程，通常满足三个信号：执行频率稳定（比如每周一次）、输入来源清晰（固定文件夹、表格或 API）、出错代价可控（即便出错也能回滚或人工补救）。判断时可以先让 Bot 手动跑 3–5 次，每次都记录输入、输出和你中途修改的地方，如果修改点越来越少，说明流程已经比较稳定，可以考虑抽象成技能并再包装成例程。反过来，如果每次都要你大量干预，或者依赖很多临时判断，就不适合完全自动化，最多做成半自动工具。
Q：Grok Bot 和本地自动化工具（比如 Raycast、Alfred）怎么配合？
A：Grok Bot 更擅长在云端跑长任务、跨网页和 SaaS 工具协同，而 Raycast、Alfred 这类本地工具更适合处理你电脑上的快捷操作。一个比较实用的组合方式是：让 Grok Bot 在云电脑上完成数据收集、整理和草稿生成，再通过同步文件夹或 API 把结果拉回本地，由 Raycast 脚本触发后续本地动作。这样可以把“云端长流程”和“本地即时响应”拆开，各自发挥优势，同时通过严格限制本地执行权限，降低 Bot 误操作你电脑的风险。
Q：如果网站频繁改版，示范录制的技能是不是很快就失效？
A：确实存在这个风险，尤其是对那些前端更新频率高的 SaaS。示范录制的优势是上手门槛低，但它对页面结构变化非常敏感，一旦按钮位置、文案或弹窗逻辑变了，原来的路径就可能走不通。比较稳妥的做法是：对核心业务流程，优先寻找是否有官方 API 或连接器；如果只能用浏览器录制，就给这些技能设一个“保质期”，比如每月固定时间让 Bot 自测一次，并在失败时提醒你检查。你也可以为关键步骤增加人工审批，让流程在出问题时停下来，而不是悄悄跑错一整批数据。
写到这里，我也不太确定哪一种用法最适合所有人，但可以肯定的是：越早把这些判断标准内化成自己的习惯，你和 AI 代理的合作就会越顺手。留一点空间给试错，也留一点耐心给迭代，Grok Bot 才能真正变成你团队里“值得信任的那位同事”。
