导航菜单

Matt Palmer 某天早上在手机上花了大约 10 分钟，让 Grok Bot 把他在 X 上关注的 800 到 900 个人整理进了一张 Notion 表。头像、简介、国家、模糊位置、置信度，一项不落。他常住旧金山，哪天要去纽约出差，表里搜一下就能找出当地可以约咖啡的朋友。

放在以前，做这件事要么手动逐个复制，要么让 AI 现写爬虫脚本。但 Matt 觉得这次完全不同：这个 bot 跑完就能扔，想改随时改，也能留着下次接着跑；最关键的是，你批准它干什么，它才敢动什么。

表面上看它还是个对话框，底层其实跑着一台一直在线的云端电脑。
 

视频原片在这里：https://x.com/mattyp/status/2092286281266962681^[1]

YouTube 同款：https://www.youtube.com/watch?v=jwogmXNt7o4^[2]

这篇按他的视频顺序，把核心逻辑拆清楚：底座原理、单个 Bot 的配置、三种跑法、多个 Bot 如何串联、4 个真实工作流，以及官方安装指南与权限边界。

底层逻辑：它不是聊天框，是带电脑的 Agent

Matt 在视频里反复强调一句话：Grok Bot is an agent with a computer。

平时常见的 Agent，大多是大模型挂几个 API 工具。Grok Bot 在此基础上直接给了一台云端 Linux 虚拟机。在对话框旁边点开电脑窗口，就能看到远程桌面：里面有独立的 Chrome 浏览器、终端命令行和文件系统。它打字、点按钮、滚页面的方式，和真人操作一模一样。

官方文档也明确了这一点：账号下的所有 Bot，共用的都是这一台云端电脑，并不是每次触发任务都开一个新沙箱。
 

它跟普通聊天机器人最大的不同有两个。

第一，电脑不在你笔记本上。不管合上笔记本、退出客户端还是去开会，云端的任务都在继续跑，中途用手机随时能看进度。

第二，它是真正端到端地干活。比如让它对比 Costco 和 Amazon 的同款商品加购物车算运费，或者在已登录的 Facebook Marketplace、Craigslist 上搜二手咖啡机。遇到登录、验证码或 2FA 时，它会主动把桌面切给你，你点完它再接过去；需要输密码时，它还会弹加密输入框，保证密码不进对话上下文。
 

Matt 演示随口说一句「帮我搜一株斑叶龟背竹」，右边的云电脑立刻开标签页、搜货、点进详情页。这不再是输出一份购买建议，而是替你把整套操作做完。

先记住这个底座：后面所有的高阶玩法，都建立在「云上有一台一直亮着的电脑」之上。
 

图 1｜Grok Bot 的底座是一台云端电脑：浏览器、终端、文件都在上面，合盖也不停。

Bot 怎么配？其实就三个字段

在 Grok Bot 里新建一个员工，只需要填三项：名字（Name）、职位（Role）、描述（Description）。

名字方便自己辨认，不影响模型行为；职位是一句话概括岗位；真正决定它怎么干活的是描述——它具体管什么、能调哪些工具、输出什么格式、遇到什么情况必须停下来找你确认。
 

Matt 举了个叫 Tech Demos（他私下叫 DevRel bot）的例子。这个 Bot 每天会自动扫他的 X 书签，挑出有价值的技术演示，模仿他的语气写出提示词发给他审核。Matt 点头后，Bot 就会调用 Cursor 插件把活派给 Cloud Agent。Cloud Agent 跑完后，会把截图、演示视频和 GitHub PR 发回对话。
 

只要设定好触发源（新书签、外部数据或手动指令），后面就能挂上一整条自动化生产线。

在生态兼容上，Grok Bot 直接沿用了 Cursor 那一套：支持 MCP、Skills 和原生连接器。Matt 自己连了 Gmail、Google Calendar、Google Drive、Amplitude、X、1Password 和 Notion，同类工具支持挂多账号（比如把 Cursor 工作用的 Notion 和个人 Notion 分开挂）。
 

官方建议也很明确：让一个 Bot 专心领一件长期稳定的任务，比如招募初筛（Talent Scout）、报销处理（Expense Manager）、Bug 复现（Bug Reproduction），这比建一个「什么都会的万能助手」靠谱得多。目前单个账号的 Bot 和群聊加起来最多 50 个。

新建 Bot 面对空白界面不用发愁，Matt 的习惯是直接发文字或语音问它：「我想做某件事，你能怎么帮我？」Bot 会主动列出需要的工具，并反问你缺少哪些配置。
 

图 2｜每个 Bot 是一张职责卡，真正干活的电脑只有一台，全账号共用。

三种跑法与串联机制

Bot 建好后，主要有三种触发方式：

手动发消息：最基础的交互，随叫随到。 设置定时例程（Routine）：告诉它「每个工作日早上 9 点跑一次」，它会自动生成触发器。也可以根据 Slack 消息或 GitHub 事件触发。所有 Routine 都支持查看历史记录、手动试跑、暂停或修改。 被其他 Bot 唤醒：Bot 之间可以互相私聊，也可以拉进群聊协作。

第三种跑法最容易让人产生误解，也是视频里最值得拆解的细节。

如果拉了个多 Bot 群聊，只是在群里发一句「大家有什么想法」，所有 Bot 会按轮询（Round Robin）机制挨个发言。Matt 专门去查了底层代码确认：群聊里并没有一个预置的统筹大脑，系统只是机械地把所有成员轮流叫醒一遍，实际工作里很容易变成低效刷屏。
 

真正实用的串流程方式，是点对点的「定向委派」：让一个 Bot 去调用另一个 Bot。比如 Matt 的写作 Bot 需要写推文时，它会主动私信 Cursor 产品专家 Bot 询问「今天上线了什么新功能」，拿到 Changelog 后再按既定风格撰写草稿。在这里，写作 Bot 充当流程编排者，产品专家 Bot 则是垂直领域的知识库。
 

把 Bot 当作不同工种的同事，固定好上下游链路（比如 A 负责抓取清洗、B 负责起草、C 负责质检），远比把它们扔进同一个大群更可控。
 

图 3｜串流程不要靠群里喊话，点对点委派更稳：一个编排，一个办事。

权限与安全：给云电脑装上刹车片

既然云电脑上登录了个人或工作账号，它会不会失控乱发帖或误删文件？

Matt 给出的答案很直接：它能做的一切，严格受限于你给的权限。底层架构里专门挂了一个 Reviewer Agent 来执行动态审查。
 

在设置中可以配置 Allow / Deny 白名单。Bot 每次执行具体动作前，Reviewer 都会实时对照规则，给出三种判定：直接放行、强制拒绝、拦截并弹窗找你审批。

官方的 Auto Review 逻辑很严密：标记为 Require Approval 的规则优先级最高，绝对拦截；标记为 Always Allow 的规则，只有在审查没有发现任何潜在风险时才会放行；两者发生冲突时，审批优先。在配置规则时，尽量写具体的窄规则，比如「向外部发邮件必须审批」「修改生产环境看板必须审批」「在指定报告目录下执行 git status 允许自动放行」，切忌图省事写出「允许在浏览器执行任意操作」这种宽泛口子。
 

这里必须牢记一个安全雷区：整台虚拟机在账号内是完全共享的。你在 Bot A 里登录了 X 账号，Bot B 打开 Chrome 同样处于已登录状态。Bot 之间不存在环境隔离，千万不要在上面登录涉及极度隐私或高危权限的账号。
 

想教 Bot 一套复杂的操作流程，可以使用 Teach a task 功能录制操作演示，系统会自动提炼成 Skill。官方限制单次录制最长 10 分钟，录制过程不包含音频，演示时切勿在屏幕上展示明文密码。录制出来的 Skill 只是初版草稿，后续仍需手动补全异常重试和审批卡点。
 

案例 1：10 分钟把 X 关注者导入 Notion

这是文章开头提到的真实场景。

Matt 在 X 上关注了 800 到 900 人，不少人在公开简介里写了自己所在的城市。他直接在手机端向 Bot 下达指令：通过 API 或直接翻主页，把关注者的公开信息整理进 Notion 数据库。
 

最终生成的表格包含头像、个人简介、国家、模糊地理位置以及置信度评分。整个过程在手机后台跑完，实际耗时大概 10 分钟。出差前只要在 Notion 筛选城市名，就能快速拉出一份同行联络单。

这个案例的核心价值在于：凡是过去需要人肉机械重复点击、翻页、复制的繁琐操作，都可以先丢给 Bot 处理，人只负责最后的产出核对与决策。
 

图 4｜Matt 用手机花大约 10 分钟，把 800 多人的公开位置收进 Notion，出差前按城市筛选。

案例 2：不写前端界面，直接把软件搬进对话框

Matt 之前花了很长时间 vibe coding 搓了一个力量训练教练 App，具备周期化训练规划、打卡记录和负荷预测功能。但他发现维护独立软件非常耗费精力：界面经常报错、逻辑修补繁琐，每次改动都要经过 Cloud Agent 生成预览再合并代码。
 

后来他把这个软件彻底解构为三层：业务逻辑、底层数据和交互界面。接着做了一个极简重构——把训练逻辑封装成 MCP / Skills 插件，把训练数据存成 Git 仓库里的 JSON 文件，而交互界面直接替换为 Grok Bot 聊天框（取名叫 Arnold）。
 

日常训练时，他只需要在聊天框报一句组数和重量，Bot 就会按照预设算法计算并把更新提交回 Git。一旦逻辑报错，Bot 自己就能定位代码、修改并提交。省去了维护前端界面的成本，整个迭代链路短了一大截。
 

这个实践给个人开发者的启发很直接：如果你的小工具本质上就是「逻辑 + 数据」，不妨先别花精力做界面。把数据放在 Git 或网盘，把 Bot 当作计算运行时，直接用聊天界面作为输入输出。
 

案例 3：充当 Cursor 的「外环」，保护代码上下文

Cursor 工程师 Lauren 曾跟 Matt 聊过一个观点：Grok Bot 是绝佳的外环（Outer Loop）。Matt 随后便专门搭建了一个名为 Outer Loop 的专属 Bot。
 

在复杂的工程任务中，研发流程被清晰地拆分为内外两环：外环负责背景调研、跨系统搜集材料（遍历 Notion 需求、Slack 讨论、内部文档与代码仓），梳理清楚问题后撰写出高精度提示词；内环则是 Cursor Cloud Agent，只专注于干净的代码实现。
 

为什么要分两层？因为大模型会把上下文里的所有内容都吃进去。如果让同一个 Agent 既负责发散讨论、通读海量文档，又负责落地敲代码，上下文很容易被无关信息污染，后面写出来的补丁会被带跑。外环做足预热与分诊，内环才能专心施工。
 

比如在优化用户积分发放逻辑时，Outer Loop Bot 会先在 Slack 和 Notion 中理清业务规则，输出方案并找 Matt 确认，确认后再向 Cloud Agent 派发编写任务。
 

图 5｜外环负责收集 Notion、Slack、文档，内环只拿干净提示词去写代码。
 

案例 4：跨源检索，把新员工入职流程跑通

在 Matt 看来，这个工作流虽然最不起眼，但在实际工作中最省时间。他入职 Cursor 时的大量适应工作，都是靠 Grok Bot 辅助跑通的。他在 X 上专门写过一篇长文 Chat is all you need。
 

在大团队里，信息往往散落在 Notion、Slack、邮件群、GitHub 和内部 Wiki 各个角落，新人光是找资料就要耗费大量精力。Matt 搭建了一个 Cursor 产品专家 Bot，既能解答业务问题，也能查询组织协作流程。
 

在录制这次分享视频前，Matt 想确认 Grok Bot 群聊机制的具体底层逻辑，该 Bot 直接翻阅了内部代码库，准确告诉他：所有 Bot 都在房间内，没有中心编排节点，由主机按照 Round Robin 机制依次唤醒。他这才敢在视频里把机制讲清楚。
 

他还配了一个助理 Bot：自动将有价值的链接归档至 Notion，接入 Gmail 与日历起草日程回复，并在每周一推着他做周计划与复盘。
 

借助 Bot 并不意味着入职熟悉期能瞬间缩减到一天，但它减少了找资料的摩擦：只要答案曾存在于内部系统的某个角落，就能快速调取出来。
 

上手指南：官方安装与冷启动步骤

视频中展示的是配置完毕的状态。如果是初次接触，建议严格参考官方文档的路径操作。
 

使用门槛：需拥有 SuperGrok Plus / Heavy 订阅，或 Cursor Pro+ / Ultra / Teams（Standard / Premium）账号，统一通过 Cursor 账号授权登录（目前无独立的 Grok Bot 单独订阅）。客户端现已支持 macOS、Windows 桌面端及 iOS 移动端，Linux 桌面版暂未上线。需要注意，若 Cursor 开启了 Legacy Privacy Mode，需先调整为支持云端存储的模式方可正常运行。
 

安装流程：

访问官方入口 https://cursor.com/bot/onboarding^[3] 下载对应系统的客户端。Mac 用户拖入 Applications 文件夹，Windows 用户运行安装程序。 打开应用点击 Get started，在浏览器中完成 Cursor 账号授权后切回客户端。 初次进入时系统会引导了解 Bot、共享云电脑与 Routine 功能，并询问常用工具偏好。该步骤仅用于个性化推荐队友模板，不会自动授权连接外部工具。

创建你的第一个 Bot 时，建议遵循「短名称 + 明确岗位 + 边界清晰的描述」。官方给出的参考模板是 Piper（负责产品性能）：描述中需列明调用哪些可观测性工具、要求区分客观数据与主观推测、优先汇报高影响级问题，并严禁擅自修改生产配置。
 

在写第一条指令时，尽量一次性交代清楚五件事：核心目标、参考来源、绝对禁区、交付物格式、何种情况必须停下等待人工审批。如果初期不想接入第三方账号，可以先尝试轻量级任务，例如丢一份长文档让它提取会议要点和未决议题。
 

遇到需要登录的站点时，在侧边打开 Agent Computer 窗口，手动接管浏览器完成账号密码、Passkey 或 2FA 验证，随后交还控制权，登录态会自动保存在该云电脑中。对于有原生插件支持的服务，优先在 Settings → Plugins 中绑定，稳定性明显优于让 Bot 在网页端模拟点击。
 

踩刹车：哪些边界千万不能越界

Matt 在视频尾声反复强调了 Grok Bot 的三个特征：常驻云端、权限可控、不用自己搭服务器。

但在实际落地过程中，有三个关键边界必须保持清醒。
 

共享环境没有物理隔离。全账号共用同一台虚拟机，登录态、本地文件与终端凭证对所有 Bot 完全透明。切勿将不同安全级别的任务混跑在同一个账号下。

审批机制无法逆转已经发生的外部操作。Deny 按钮只能拦截后续步骤，对于已经发出的邮件或已提交的接口请求无能为力。涉及资金支付、对外通信、数据删除及生产变更的动作，必须强制设为「仅起草、必须人工确认」。
 

测试运行就是实弹演练。配置 Routine、录制 Skill 或挂载新插件时，务必先在测试数据上试跑。官方文档明确提醒，测试模式同样会真实访问网页并执行系统调用。

工具刚刚面世，大家都在摸索它的能力边界。不必一上来就搭建庞大的自动化工作流。从一个明确的单一 Bot、一段清晰的描述、一次必须经你审批的小任务开始，就足够迈出第一步了。