导读：真正让Grok Bot好用的，不是一次创建十几个“AI员工”，而是先把岗位、上下文、交接和验收方式设计清楚。下面这10条经验，覆盖从一个Bot怎么养、多个Bot怎么分工，到如何让CLI Agent干重活、Webhook负责叫醒、Notion负责展示结果。
信息边界：持久云电脑、多Bot并行、任务交接、Routine和订阅范围可由Grok Bot官方页面确认；“上下文较短”“Webhook配置体验”“App Nap影响本机联动”等属于当前版本的个人实测经验，可能随客户端更新而变化。
01 / 长期反复的非编程任务，才适合交给Bot
临时问题继续放在普通对话里；需要长期反复执行、会不断积累规则和偏好的任务，再交给命名Bot。例如收件箱、用户反馈、订阅管理、社媒数据和商务财务。
Bot的优势不是一次回答更聪明，而是你可以持续纠正它：“这类邮件以后怎么分”“这张表哪些字段必须检查”“什么情况必须问我”。每次纠正都应该沉淀到记忆、专属指令或Skill里。
02 / 先画清四层上下文：共用、专属、文件和交接
- 共用层：所有Bot都应遵守的偏好、通用规则、连接器与Skill。
- 岗位层：单个Bot的职责、语气、验收标准、专属记忆和例程。
- 共享文件层：同一云电脑中的数据库、文档和中间产物。
- 交接层：Bot传给另一个Bot的任务摘要、来源、当前状态与下一步。
不要假设Bot A能完整读取Bot B的聊天记录。重要交接应该像团队工单一样，把背景、输入位置、已经完成的步骤和验收条件写明。
03 / 不要一上来把岗位拆得太细
以社媒运营为例，一开始没必要拆成采集、选题、文案、发布和复盘五个Bot。先建立一个“社媒Bot”负责完整闭环，等出现两个信号再拆：
- 不同平台已经形成稳定而明显不同的流程。
- 渠道语气、活动信息或历史上下文互相污染，导致错误增多。
临时任务也不一定要永久新增Bot，可以由上层Bot临时分派一个执行者，任务结束后归档。Bot越多，管理、权限和错误定位成本越高。
04 / 重叠任务只设一个入口，再把结果分流
如果收件箱Bot、用户反馈Bot和订阅管理Bot都直接读取邮箱，就会重复调用工具、重复处理甚至互相打架。更稳妥的方式是让收件箱Bot成为唯一入口：
- 普通邮件由收件箱Bot整理。
- 用户反馈转交产品反馈Bot。
- 续费、扣款和账单转交订阅管理Bot。
这个原则可以概括为：一个数据源只设一个主要读取者，下游Bot接收结构化事件。减少工具调用，也更容易审计。
05 / 跑顺的机械流程交给脚本，重任务交给CLI Agent
Bot额度有限，而且不一定能自由选择最合适的执行模型。已经明确、重复、可验证的流程，可以固化为脚本；需要长时间编码、批量修改或深度研究的任务，可以交给Codex CLI、Claude Code或其他CLI Agent。
Grok Bot只负责三件事：准备任务说明、派发执行、检查结果。比如“每天读取一个数值并与前一天比较”，完全可以由定时脚本只返回增量，没必要每天让大模型重新阅读整个页面。
06 / 用Wake on Done解决“CLI跑完了，Bot却不知道”
长任务最常见的断点不是执行失败，而是执行器已经结束，负责验收的Bot却没有被及时唤醒。作者提供的开源Skill Wake on Done 使用Webhook和中转Bot处理完成通知。
- Bot派出Codex、Claude Code或脚本任务。
- 执行器在结束时发送包含任务ID和状态的Webhook。
- 中转Bot接收通知并唤醒对应Bot。
- 原Bot读取结果、验收并继续下一步。
安全提醒：Webhook地址和密钥不要放进公开Prompt、仓库或截图；必须处理重复通知、失败状态、超时和任务ID校验。
07 / 需要网页交互时，再给Agent接Web Access
Web Access是一个开源Agent Skill，会在搜索、静态抓取与CDP浏览器操作之间选择合适路径，并可连接已授权的Chrome或Edge。它能读取动态页面、点击、滚动、截图和提取媒体，也意味着它可能接触登录态。
正确顺序是：有官方API、MCP、连接器或专用CLI就先用；只有动态页面和真实交互不可替代时，才进入浏览器层。发布、删除、付款、上传与权限修改要保留人工确认。
08 / 本机联动要单独处理Mac息屏和App Nap
Grok Bot的云端任务可以持续运行，但依赖本机文件、浏览器或应用的流程仍可能被休眠影响。原作者给出的实测做法是检查Grok Bot App的App Nap，并在固定例程前用macOS的pmset设置定时唤醒。
可直接交给Bot检查的Prompt：
帮我在这台 Mac 上设置一下：关掉 Grok Bot App 的 App Nap，让它息屏后也能继续运行。如果我有固定时间的例程，再用 pmset 设一个例程前几分钟的定时唤醒。改之前先告诉我你要改什么，改完验证一下是否生效。
这会修改本机电源和应用行为，执行前要确认具体命令、唤醒时间、耗电与安全影响，并保留恢复方法。
09 / Notion适合做展示层，不一定适合做源数据库
长期个人看板需要布局、筛选、关联和人工阅读，Notion现成的块与Database比临时生成HTML更容易维护。Bot可以定时把结果同步到Notion，用户直接查看首页、订阅、内容或项目视图。
更稳妥的架构是：源数据留在Bot云电脑中的数据库或结构化文件，Notion作为展示和协作层。这样既能批量更新，也不会因为人工调整看板而破坏原始数据。
10 / 五个可直接照着搭的岗位Bot
收件箱Bot
聚合邮件和消息，识别紧急事项，再把反馈、账单或业务线索转给对应Bot。
产品反馈Bot
读取问卷、转发邮件和社区消息，合并重复问题并输出趋势与原始证据。
订阅管理Bot
追踪续费、扣款、涨价和到期日，更新月度预算，并在扣款前提醒。
商务财务Bot
整理合同、订单和签章状态，起草回复邮件；对付款、签署和发送保留人工审批。
社媒数据Bot
采集多个平台指标，计算增量并同步到Notion，用于选题、复盘和异常提醒。
做视频网观点：多Bot的上限由管理设计决定，不由Bot数量决定
把一个复杂流程切成十个Bot，不会自动提高质量。没有唯一入口、清晰权限、结构化交接和验收标准，多Bot只会把一次错误复制十遍。
推荐的成熟顺序：先让一个Bot跑通完整工作，再把经验写进Skill；出现稳定分工后才拆Bot；机械步骤下沉给脚本，重任务交给CLI Agent，最后用Webhook和看板把执行链闭合。
站内导航与相关阅读
Grok Bot导航：https://www.zuoshipin.com/link/32197.html
Wake on Done导航：https://www.zuoshipin.com/link/53346.html
Web Access导航：https://www.zuoshipin.com/link/53347.html
Grok Bot企业版解析：https://www.zuoshipin.com/article/32198
DeepSeek Harness插件化Agent教程：https://www.zuoshipin.com/article/20886
