GrokBot 的 11 条使用技巧：搭出一套 Agent 工作系统
沿 Agent Native 原文的 11 条顺序，拆解情况监控、开发委派、通用入口、Agent 协作、项目 Bot、X、Slack、插件、多邮箱、Notion 和追问式日记。
- 原文的 11 条技巧分别对应 11 个可独立使用的工作流，正文按 01—11 原顺序逐条解释，并在开头给出完整一览。
- 监控和触发型 Bot 的共同规则是：对象要短、命中条件要明确、没有变化保持沉默；专用 Bot 则要写清输出、证据和批准边界。
- 外部连接先验证正确身份与只读结果，再开放写入；发送、取消、合并、部署和发布继续等待批准，Notion 写入后必须读回。
Agent Native 的作者把 GrokBot 称为 SpaceXAI 的通用 Agent 平台。它允许你创建多只 Bot，为每只 Bot 分配独立职责、上下文、插件和运行例程，再让它们互相交接。作者和团队长期使用后，整理出了 11 个最有用的工作流。
这 11 条不是一套必须从头到尾照做的安装教程。它们分别处理监控、开发委派、通用入口、跨 Agent 协作、项目管理、X 研究、Slack 触发、插件权限、多邮箱、Notion 写回和深度思考。按原文顺序看，可以逐项判断哪一种工作流值得放进自己的系统。
- 建一只“情况监控”Bot：只在项目、交易、期限或决定发生实质变化时提醒。
- 让开发 Bot 使用 Cursor：把长开发任务交给编码环境，并带回可审查产物。
- 保留一只通用 Bot：给还没有固定归属的想法、问题和任务一个总入口。
- 让 Bot 之间互相沟通：汇总完成项、决定、阻塞和下一步，减少人工搬运上下文。
- 为重大项目单独建 Bot：保存项目目标、人员、文件、决定和未完成事项。
- 把 Bot 接到 X：把帖子、收藏和互动数据整理成研究与内容线索。
- 用事件触发例程监控 Slack：只在指定消息出现时启动，并把高后果动作留给审批。
- 只安装真正有用的插件：为真实工作流增加上下文和动作能力，同时控制权限。
- 连接多个邮箱：跨账户搜索资料，又不混淆发件身份和取消权限。
- 把 GrokBot 接到 Notion：把研究写回既有页面，并读回确认位置与格式。
- 建一只“追问式日记”Bot：通过连续追问把混乱想法变成判断和行动。
01｜建一只“情况监控”Bot
作者把它称为自己最有用的一只 Bot。它不负责生成一份又一份定时报告，而是维护一张很短的“活跃情境”清单：正在等待进展的项目、交易、截止日期或决定，每项只占一行。Bot 连接 Slack、邮件和日历，在工作日每五分钟检查一次；没有实质变化时保持沉默。
一旦变化命中，提醒固定回答四件事：哪个情境变了、发生了什么、为什么值得注意、用户下一步该做什么。提醒末尾再附上完整清单。清单也不必回到监控 Bot 中维护；用户可以在任何对话里要求当前 Bot 把新增或删除事项交接过去。
“每五分钟”只是作者采用的频率，不是所有人的默认答案。这个工作流能否低噪声运行，取决于监控对象是否足够少、“实质变化”是否写得清楚，以及未命中时是否真的不发消息。
三种启动方式，共用一条低噪声规则
工作日每 5 分钟
短名单：项目、交易、期限、决定
无实质变化就沉默指定 Slack 频道或消息条件
交易、发票、阻塞、请求
未命中条件就忽略定期检查某封重要回复
结果到达后提醒
事情解决后删除例程命中后交付：发生了什么 · 为什么重要 · 相关材料 · 下一步
发送、更新或发布继续等待批准
作者原图：工作日每五分钟检查与活跃情境清单。
02｜让开发 Bot 使用 Cursor
GrokBot 适合接收目标和组织上下文，耗时较长的开发工作则交给编码环境。作者的开发 Bot 会把仓库、要实现的结果、视觉方向和不可更改的约束交给 Cursor，让它在新分支上构建、运行并测试应用。
完成的定义不只是“代码已经生成”。Bot 要带回桌面截图、移动端截图和 Pull Request，附上简明改动说明，让用户能够先看结果、再检查代码。合并和部署继续停在人工批准线之前。这样，即使用户从手机发起任务，也能拿到一份可以审查的开发交接，而不是一段无法验证的完成声明。
把专用 Bot 配置成一份可验收合同
开发 Bot 只是一个例子。任何专用 Bot 都可以先填完下面这份任务合同。这里应保留代码块，因为这些字段是一份可复制、可改写的配置，不是普通正文清单。
job: 这只 Bot 唯一负责什么
scope: 可以查看哪些项目、账户、频道或文件
inputs: 开始前必须拿到哪些上下文
trigger: 什么时候运行
ignore_when: 哪些情况保持沉默
output: 返回哪些固定字段或产物
evidence: 用链接、截图、测试、PR 或读回证明什么
approval: 哪些发送、写入、取消、合并或发布动作要等人批准
read_back: 写入外部系统后怎样重新读取并确认结果
职责决定工作范围，触发和沉默条件控制噪声，输出和证据决定怎样验收，批准和读回则约束外部动作。缺少其中任何一组，Bot 都可能“看起来完成了”，却无法证明结果正确落地。
03｜保留一只通用 Bot
作者建议保留一只几乎没有专业分工的 Bot，并把它置顶。语音笔记、快速问题、旧对话检索、策略讨论，以及暂时不知道该交给谁的任务，都先进入这个总入口。用户不必在每次开口前先设计分类体系。
只有当同类工作反复出现，或者开始需要专门工具、长期上下文或固定例程时，才把它拆成专用 Bot。这个门槛避免了另一种常见负担：系统里出现许多名字不同、职责却高度重叠的 Bot，最后用户仍要先判断该去哪里提问。
从一个总入口长出整套 Agent 工作系统
想法、语音、问题、检索和未分类任务先从这里进入
工作反复出现 · 需要独立上下文 · 专用工具 · 固定例程 · 项目所有权
获得清楚职责、长期上下文、工具和完成定义
读取工作资料，按时间或事件运行
结果、阻塞和开放事项回到总入口，高后果动作等人确认
通用 Bot 不是能力更弱的临时入口。它承担的是接收、检索和分流；专用 Bot 承担稳定流程；插件提供外部上下文与动作；例程决定何时自动运行；涉及后果的决定仍回到人。原文后面的 8 条技巧，基本都在给这套分工补充具体部件。
04｜让 Bot 之间互相沟通
多只 Bot 分工之后，用户不必成为它们之间的复制粘贴工具。作者让通用 Bot 像一个轻量级幕僚：主动询问可见的专用 Bot，收集过去七天完成的工作、已经作出的决定、当前阻塞、开放事项或期限，以及下一项需要用户参与的动作。
它返回的不是各段对话的拼接，而是一份压缩后的简报，并排出最值得关注的三件事，说明原因和负责的 Bot。持久事实、近期变化、责任归属和注意力优先级因此汇到同一个入口。
专用 Bot 保留细节，总入口负责综合与排序
- 完成项
- 重要决定
- 当前阻塞
- 开放事项与期限
保留持久事实，压缩近期变化，不粘贴整段对话
- 最应关注的 3 件事
- 为什么需要关注
- 哪只 Bot 负责下一步
群聊用于同一项目的实时协调
作者原图：总入口向多只 Bot 收集上下文并准备汇总。
几只 Bot 需要围绕同一项目实时协调时，可以另开群聊。群聊用于现场讨论和交接；周期汇总用于把结果送回用户。两者分别解决协作过程和管理视野的问题。
05｜为重大项目单独建 Bot
不是每项任务都值得新建 Bot。作者的门槛是：项目是否会持续足够久、重复足够多，或重要到需要独立保存上下文、负责人和例程。如果答案是否定的，让通用 Bot 处理即可。
新项目 Bot 不应从空白开始。让已经了解项目的 Bot 一次性交接目标和完成定义、关键人员、既有决定、文件与链接、不可变约束、审批边界、开放任务和截止日期。新 Bot 只保留一个清楚的主职责；只有存在稳定的周期性工作时，才增加例程。
项目结束后，作者选择隐藏而不是删除 Bot。上下文仍可通过 Command K 找回，主界面又不会长期被过期项目占满。这里保留的是项目记忆，不是继续让已经结束的例程运行。
06｜把 Bot 接到 X
作者把 X 当作视频选题和研究线索的来源。连接主要账号和需要理解的品牌账号后，Bot 可以按内容格式、主题、浏览量和互动分析近期帖子，并为每条结果保留直达原帖的链接。私有互动数据还可以帮助作者观察哪些主题吸引了目标受众；这属于作者的实际用法，不等于平台对所有账号都能给出同样效果。
收藏工作流更具体：每周三和周日查看最近七天的书签，只留下与指定主题有关的内容。每条输出一句核心观点、两三句意义、可能的使用方式和原帖链接，再把相似内容聚合成三个值得继续研究的主题。
链接是这个工作流的证据层。没有原帖链接，摘要很快会变成一组无法回查的二手判断；保留链接后，用户才能核对语境、作者和原始数据。
07｜用事件触发例程监控 Slack
定时例程在某个时间醒来，事件例程在某件事发生时醒来。Slack Watch 要先绑定具体频道或消息条件，并写清哪些内容算重要，例如交易、发票、阻塞或请求。普通聊天不命中条件，Bot 就保持沉默。
触发后，它先总结发生了什么、为什么需要关注，再取回相关链接或文档，并草拟回复或下一步动作。通知和草拟可以自动完成；发送消息、更新数据库、发布内容或把任务交给可能改变外部状态的流程，仍要等待批准。
原文还隐含了一个实用区分：持续状态适合定时检查，即时消息适合事件触发，一次性的等待适合临时例程。比如等待重要邮件回复，可以临时定期检查；回复到达后提醒用户，事情解决后再删除例程。
08｜只安装真正有用的插件
插件让 Bot 读到工作实际发生的地方，也可能允许它在那里执行动作。作者建议从每天已经在用的 Drive、Calendar、Notion、Slack、X、Linear 或 ClickUp 开始；连接理由必须是支持一条真实工作流，而不是“这个集成存在”。
连接后先测试读取：账号或工作区是否正确，Bot 能否找到预期的文档、记录和页面。只读稳定后，再逐步开放草拟、更新、发送或发布。权限只给完成任务所需的最小范围，已经没有实际用途的连接应被移除。
外部连接先验证身份和只读范围，再开放动作
| 连接 | 读取对象 | 允许动作 | 保护线 | 完成证据 |
|---|---|---|---|---|
| Cursor | 代码仓库与约束 | 分支内构建和测试 | 不合并、不部署 | 桌面/移动截图 + PR |
| X | 帖子、收藏、互动 | 筛选、归类、摘要 | 每条保留原链接 | 最近 7 天研究清单 |
| 多邮箱 | 个人、业务、合作账户 | 搜索、审计、起草 | 固定默认发件身份；不直接取消 | 账户、金额、日期、管理链接 |
| Notion | 正确页面与结构 | 只在指定位置追加 | 不删除、不重排 | 写后重新读取 |
| 通用插件 | 账户、文档、记录 | 工作流需要的最小动作 | 先读后写、最小权限 | 正确账户与记录 |
权限阶梯：只读验证 → 草拟待审 → 写入保留批准与读回
作者原图：插件会同时带来上下文和动作能力。
作者给出的插件审计包含五项：连接了哪个账户或工作区；提供了什么上下文；允许执行什么动作；由哪只 Bot 或哪条工作流使用；是否存在不必要或过宽的权限。审计先返回清单，不自行更改权限或断开连接。
09｜连接多个邮箱
多个个人和业务邮箱可以合成一个搜索域，用来寻找订阅、收据、税务文件、旧附件和已经忘记位置的对话。每个账户都要明确标记为个人、业务、合作或其他身份；负责发信的 Bot 还要指定默认发件账户，不能让它自行猜测该用哪个身份。
作者的订阅审计会搜索最近三个月的重复扣费，列出公司、金额、计费周期、所在邮箱、最近扣费日期和账户管理链接，把疑似重复项放在一起，并标出看似闲置的订阅。它交付的是审阅清单，不直接取消任何服务。
重要回复也可以交给临时例程等待：定期检查指定邮箱，邮件到达后提醒用户，情境解决后删除例程。这样既得到跨邮箱检索的便利，又不把发信、取消和长期监控权限混在一起。
10｜把 GrokBot 接到 Notion
Notion 连接的价值不只是“能够创建页面”。它把研究、会议记录和项目状态写回用户已经工作的知识结构里。开始前要确认正确的工作区、数据库和页面层级，并明确允许写到哪里、采用什么格式。
作者的 Add Context 做法很克制：读取指定页面，不改写、删除或重排原内容；只在页面底部追加一个名为 “Additional Context” 的 callout，把详细研究放进折叠区并附来源链接。页面主体因此不被额外材料淹没。
写入后，Bot 重新读取页面，确认新增内容的位置和格式。API 返回成功只能证明请求被接受，读回才能证明用户实际看到的页面符合约定。对数据库更新、会议记录和项目状态，同样应该预先约定目标位置、字段和读回方式。
11｜建一只“追问式日记”Bot
Grill Me Journal Bot 用于处理没有标准答案的想法。它是一只私密 Bot，常从手机上的语音笔记或一段混乱表述开始。Bot 先取回相关上下文，再一次只问一个困难问题，挑战模糊主张、隐藏假设和逻辑缺口。作者通常让它持续七到八轮。
一次问一个难题，直到观点具体到可以行动
挑战模糊主张、隐藏假设和逻辑缺口
作者示例：7—8 轮写入 Bot 的计算机或笔记系统
作者原图：追问结束后把日记保存到工作区文件。
结束时，它交付四样东西：用户实际相信什么的简短总结、最强的未解决问题、三项下一步行动，以及一份可以保存的干净日记。成品写入 Bot 的计算机或用户选择的笔记系统，让这次思考成为之后可以检索和继续使用的文件。
七到八轮是作者的节奏示例。更合适的停止条件是判断已经能够行动：主张说清了，关键假设暴露了，未解问题可以准确命名，下一步也不再只是“继续想想”。
这 11 条可以从任意一条开始。若要压缩成一周的最小配置：建一只情况监控 Bot，只放两个正在等待变化的事项；置顶一只通用 Bot；从本周第一次重复出现的工作里挑一项，填完任务合同；只连接一个外部系统并先验证读取；周末让通用 Bot 汇总一次完成项、决定、阻塞和开放事项。每一步交付可检查结果后，再增加新的 Bot、连接器和例程。