10 条必备经验，让你的 Grok Bot 变得更好用

Grok Bot、X、Cursor 订阅大一统了，用上的朋友也会越来越多。

整理了 10 条大概率用得上的 Grok Bot 经验与技巧，分享如何搭好 multi-bots 工作流👇

1️⃣ 什么时候用 Bot 更好？

长期、反复执行的非 Coding 任务用 Bot；Coding 继续用 Codex、CC、Cursor

Bot 是 Bots 类 Agent，Codex 是会话型 Agent，你会天然更把 Bots 视作一个需要长期沟通的“人”。

让一个 Bot 长期负责一类事，你就会很自然地像带人一样告诉它哪里不对、下次怎么做。

鼓励 bot 在对话中提取学到的经验，更新 bot 记忆。

Codex 的劣势：在需要长期反复做的事情上，因为同一个项目开了一堆会话，哪个是新的、哪个该弃用、上下文在哪个里面，自己都理不清。

2️⃣ Bots 的上下文机制

要用好一个 Agent 产品，首要的是摸清它的上下文组织逻辑。

目前实践已知：

Bots 之间能私下进行长对话，转接信息与事务；但一个 bot 不能看到另一个的聊天记录，只能转述
Bots 系统内，共用的上下文有：「共用记忆」、「Skill」、「连接器」
每个 bot 单独持有「bot 专属指令」、「单 bot 专属记忆」、「bot 专属例程（自动化任务提示）」
所有 bots 都运行在一个云电脑上，而不是一个 bot 一个云电脑，所以他们可以查云电脑上的任意文件。这也是一个重要的上下文共用位置。

想要让所有 bot 都能够记得某些事情，请使用共用记忆。

另外，Grok Bot 的上下文比较短，需要一直记得的时候，请直接说“请记到共用记忆区 / bot 内专属记忆区”；或者直接落在云电脑的文档 or Skill 里。

3️⃣ 不要上来就把 Bot 拆得太细

管 Bots 就像开一家初创公司，没人能在一开始保证一个“岗位”的职责边界

以都能看懂的社媒运营为例，没必要一开始就拆出采集 Bot、选题 Bot、文案 Bot。Bot 成群看起来很酷，但不是好事。拆得越细管起来越累。

由于 Grok Bot 允许 bots 间通信，如 bot A 交接 bot B；主 bot 向子 bot 传递有用的共用消息，Bots 间任务转接的效率很高。

所以可以像初创公司招人一样：先建个社媒 Bot，把一整块活包下来。等出现需要以下征兆时，再考虑细分，比如：

内部形成了更稳定的差异化工作流：小红书、X、Tiktok都有了独特的 Agent 流程
内部上下文污染现象严重：不同渠道的文风污染、多活动的上下文积累

并且增加 bot 不一定非得考虑永久性 bot，单独去临时起一个 bot，由上层 bot 教它完成亦可。

4️⃣ 如何设计 bots 间的重叠任务？

遇到这种任务重叠的情况，怎么设计 bots 的职责？

Bot A：我负责读你的新邮件
Bot B：我负责收集用户反馈，但有些反馈会进你的邮箱
Bot C：我负责管理付费订阅，但有些续费提醒会进你的邮箱

我的收件箱 Bot 会先处理掉 Gmail 里所有邮件，遇到用户反馈就转通知用户反馈 bot；遇到续费、扣款这类订阅邮件就转给订阅管理 bot。

优化冗余、重叠的工作流，从技术角度来讲，就是减少工具调用次数。

每个 Bot 只管自己那摊事，碰哪些账号、能做什么都很清楚。

5️⃣ 已跑通、有明确标准的自动化流程，可交给 CLI Agent 执行

Grok Bot 的额度有限，也没法自己选模型。

所以已经跑顺、有明确标准的工作流，我会让 bots 通过 CLI 指挥 Codex CLI 或 Claude Code 执行。

Bot 只负责派活和验收。

甚至「定时在某网站，读取某个数值，与前一天比较是否有变化」的任务，都不需要 AI 介入。

这件事是可以固化成脚本的就直接写成纯机械脚本的，每天定时跑，最终只要把增量给到 bot，大幅减少 token 消耗速度。

6️⃣ Wake on Done，让 Bots 能及时知道 CLI 任务是否完成

Grok Bots 现在一大痛点是，命令行 Agent 跑完不会通知你，所以常常会遇到，Bots 让 Codex 去干活，跑着跑着就中断了。

好消息是，Bots 支持 webhook，所以能做更多及时触发的自动化任务

坏消息是，每个 Bots 的 webhook 地址不互通，所以每个 bot 都配一次很麻烦

我推荐用 Wake on Done Skill 解决，让你仅需 1 分钟，一次配置，所有 Bots 都能获得被及时提醒。

传送门：Github - Grok Bot - Wake on Done Skill

能自动帮你配好云电脑、本机的 web hook，起一个中转 bot 专门负责叫醒，任务一结束就把对应的 Bot 叫起来接着干，长任务终于能做到无人值守了。

7️⃣ 自动化操作浏览器，用 Web Access Skill

Grok Bot 现在不支持 Browser Use 能力，拒绝自动使用浏览器。

安装一个 Web Access Skill，这是一个 9K Star 的 Agent 浏览器自动化 Skill，能让你的 Bot 直接操作本机浏览器，还能复用登录态。

传送门：https://github.com/eze-is/web-access

也可以让它操作 CLI Agent，继续套娃做 Browser Use。

8️⃣ 电脑一息屏，Grok Bot 就动不了本机

虽然 Grok Bot 有云电脑，但很多任务还得用到本地机器。

Grok Bot APP 有 App Nap 的限制，用笔记本的话，就算开了息屏不休眠也没用，因为它的 APP 自己会暂停运行，云 Bot 没法操作本地了。

可以让它自己关掉它的 App Nap。必要的时候，还可以用 pmset ，在例程任务之前定时唤醒，让 Mac 到点自己醒过来。

可以参考这个 Prompt：

帮我在这台 Mac 上设置一下：关掉 Grok Bot App 的 App Nap，让它息屏后也能继续运行

如果我有固定时间的例程，再用 pmset 设一个例程前几分钟的定时唤醒。改之前先告诉我你要改什么，改完验证一下是否生效。

9️⃣ 给人看的数据看板，我现在更推荐放 Notion

虽然我们越来越习惯让 AI 现生成 HTML 可视化看板。

一开始我也觉得那似乎以后也用不上 Notion 这种 DB 了。但最近我觉得做长期的个人信息看板，统一放 Notion 好用得多。

比如给你看看我的首页：

或者月订阅看板：

Notion 自带完整的前端块结构，可以随意组织多个看板的布局关系。另外 Database 里每一条数据也都能承载一个完整页面。而且 Notion MCP 读写比我们想象的快很多，无需 AI 也能批量、定时更新 Notion 上的数据。

在 Notion 上加看板，你做的事更像是往现成框架里填内容，很难做丑。也不用指挥 AI 如何把一堆 HTML 组合起来、再额外做一个总览页。

不过有一个不同的是，我不把 Notion 作为源数据库。

源数据放在 bots 的云电脑数据库就可以，让 bots 写个脚本定时同步到 Notion DB，定时更新映射出来的视图，十分好用。

🔟 我目前用 Grok Bot 搭了这些，希望能给你带来一些思路

收件箱 Bot
帮你追踪一切个人信件、消息。
搭得时候能用 MCP 连就用 MCP，比如 Gmail、Outlook；飞书邮箱能用 CLI；实在不行的还能浏览器自动化
产品反馈 Bot
每天看飞书问卷、转发过来的邮件、discord 新消息，汇总用户反馈
订阅管理 Bot
盯着我所有订阅的续费和扣款
商务财务 Bot
管合同和订单，还能连上打印机自动打印合同，签完章还会自动起草回复邮件
社媒数据 Bot
每天采集 5 个平台的数据，同步到 Notion 看板

大概就是这样了，Enjoy Your Grok Bots！