Grok Bot 使用指南

什么是 Grok Bot

Grok Bot 是长期存在的智能代理。它不同于普通单次对话，具备以下特点：

• 有独立记忆，能跨对话保留信息
• 可以保存「例程」（定时或事件触发的自动任务）
• 所有 Bot 共享一台属于你的云电脑
• 能操作你的本地文件、已登录的浏览器，以及已连接的外部服务

适合交给 Bot：

• 需要每天/定期重复执行的检查与摘要
• 需要在你离开后继续运行的任务
• 需要记住长期偏好、项目状态或历史决策
• 涉及你电脑上的文件、程序或浏览器登录状态
• 跨多个服务的工作流（邮件 → 表格、日历 → 提醒等）

不适合用 Bot：

• 一次性问答
• 临时生成内容
• 不需要记忆和后台运行的简单查询

判断标准：如果这件事需要「记住上次的情况」或「在我离开后继续做」，就考虑 Bot；否则直接对话即可。

每个 Bot 都有独立的长期记忆。它会记住：

• 你明确要求它记住的事实
• 对话中的关键决定和偏好
• 已完成任务的状态

记忆不是无限的，重要信息应明确告知。不要让 Bot 记忆密码、API 密钥等敏感凭证，这些应通过官方连接器处理。

当事实发生变化时，要主动告诉 Bot 更新，而不是假设它会自动感知。

例程由两部分组成：

• 提示（Prompt）：具体要做什么
• 触发条件：何时执行（时间或事件）

时间触发示例：「每天早上 8 点」。
事件触发示例：「当 GitHub 有新 Pull Request 时」。

好的例程提示必须自包含，包含：数据来源、处理逻辑、输出格式、异常时如何处理。因为例程执行时你不在旁边解释。

设置时要明确告诉 Bot「请保存这个例程」，并给出完整提示。

Bot 运行在你的云电脑上，而不是我自己的工作区。

• 它可以访问你的桌面、下载、文档等本地文件夹
• 可以运行你已安装的程序
• 可以使用已登录的浏览器会话

因此，「整理下载文件夹」「读取我电脑上的文件」「填写已登录网站的表单」这类请求，必须交给 Bot。

服务连接也有区别：一次性操作如果我已连接可以直接处理；重复性任务或只有 Bot 持有的连接，应交给 Bot。同一任务不要同时走两条路径。

1. 先搜索：分配任务前先搜索现有 Bot，避免重复创建
2. 异步发送：必须使用异步模式发送任务，获得句柄
3. 持续等待：用句柄等待最终结果，不要只看确认回复就停止
4. 明确例程：长期任务要明确要求保存例程，并写清触发条件和完整提示

如果多个 Bot 都可能承担一项持续性职责，应先询问你的选择，而不是自行决定。

常见问题

• 任务没结果 → 确认使用了异步模式，并持续等待到最终回复
• Bot 说没权限 → 检查对应服务是否已连接
• 例程没运行 → 问 Bot「列出我的例程」，确认触发条件
• 重复创建了 Bot → 下次先说「先搜索现有的」

进阶建议

• 例程提示要写得自包含
• 复杂流程拆成多个小例程
• 定期清理不再需要的例程
• 重要操作始终保留人工最终确认

本指南的信息来源

• 平台内部机制：来自实际调用 Grok Bot 工具时的规则（搜索优先、必须异步发送、持续等待、例程由提示+触发条件组成、共享云电脑等）。
• 官方文档：docs.x.ai/grok-bot 与入门指南。
• 社区实践：X 上 Sawyer Merritt 的 20 课教程、@bot 团队 power-user tips、Memory Map 等文章，以及真实用户的多 Bot 分工经验。

社区高频实用技巧（可直接借鉴）

• 每个 Bot 只负责一个清晰的「工作岗位」，而不是一个大而全的聊天。
• 设一个 Chief of Staff / 总控 Bot，负责协调其他专家 Bot。
• 例程不要跑得太频繁（每小时或每天几次通常足够），避免噪音。
• 用「Teach a Task」或明确要求保存 skill，把成功流程固化。
• 重要写操作（发邮件、改文件、花钱）保留人工确认。
• 定期让 Bot 列出例程和记忆，做一次清理。
• 把长期有效的事实写进 Bot 描述或明确要求记住，而不是只放在聊天里。

这些技巧来自社区真实使用反馈，和平台机制相互印证，建议结合自己的场景选择性采用。