Grok Bot：完整安装与使用指南

Grok Bot：完整设置与使用指南 2026年8月22日 · 27分钟阅读 · 查看原文 ↗ Grok Bot AI Claude Slack Grok Bot 不是一个聊天机器人。它是一个由智能体组成的团队，每个智能体都有自己的云端电脑（浏览器、文件系统、终端），运行在数据中心里。合上你的笔记本，工作仍在继续。 真正的转变是心智上的：你不再"提示"，而是开始"委派"。"我该怎么措辞"这个技能被"我到底在委派什么，它的权限边界在哪里"所取代。这是一个管理问题，不是提示词工程问题。 嵌入帖子： 作者：Grok Bot（@bot） 帖子 ID：2087224798078517251 来源：https://x.com/bot/status/2087224798078517251 发布于：2026-08-11T17:09:05.000Z 回复：无 正文： > Grok Bot 现已推出，处于早期测试阶段。 > > 机器人是为你做实际工作的 AI 队友。它们登录你的工具，像你一样使用这些工具，然后带着完成的工作回来。 媒体： video: /media/posts/grok-bot-the-complete-setup-and-usage-guide/1.mp4 工作流程的顺序总是相同的： > 用角色代替提示词 → 用访问权限代替指令 → 演示一次 → 划定审批边界 → 设置日程 → 每周审查 跳过这条链中的任何一环，系统要么什么都不做，要么在你睡觉时做错事。 1. 它底层到底是什么 一个机器人 = 三样东西：一个名字 + 一块责任范围 + 一段关于它如何工作的描述。对话线程是持久的，上下文可以在任务之间延续。 一个账户 = 一台共享电脑。关键后果： 浏览器 cookie 和会话在所有机器人之间共享 每个机器人都能看到这些文件 CLI 凭据是共享的 所以如果一个机器人登录了 LinkedIn，所有机器人就都登录了。这消除了交接摩擦，但意味着：如果账户上的另一个机器人不该使用某个凭据，就不要把这凭据放到那台机器上。智能体之间没有隔离。 硬件（非官方报告）：Debian，约 8 vCPU，约 16 GB 内存，约 100 GB 磁盘，无 GPU。box 用户拥有 sudo (ALL) NOPASSWD: ALL——实际上是 root 权限。 限制：每个账户最多 50 个机器人和群聊（合计）；每个机器人最多 50 个例行任务；每个例行任务保留最近 20 次运行记录；群聊容纳 2–6 个机器人。 2. 访问权限与费用 Grok Bot 不单独销售——只捆绑在订阅里： 每个套餐包含每周用量池；超出池子的工作按模型和 token 成本计费（单独一张 Cursor 发票，可在 cursor.com/dashboard?tab=spending 切换）。用量池和按需计费都在 Settings → Usage & Billing 中查看。 什么会消耗用量池：每一张截图都是模型在行动前必须读取的图像。每步都截图的自动化会烧掉用量池。把重复性工作改走连接器（connector），而不是在 UI 上点来点去。 一个真实案例的经济账：一周的 Ultra = 46 美元的席位费 + 142.80 美元的按需计费 = 188.80 美元，对应 339 件完成的工作 ≈ 每件 0.56 美元，而当周签下了 1,840 美元的合同。 嵌入帖子： 作者：Grok Bot（@bot） 帖子 ID：2090852881373311369 来源：https://x.com/bot/status/2090852881373311369 发布于：2026-08-21T17:25:47.000Z 回复：无 正文： > 我们正在让 Grok Bot 更广泛地开放。 > > 所有 SuperGrok Plus、Cursor Pro+ 和 Cursor Teams 订阅者现在都可以使用了。 > > 我们还为所有其他用户提供有限用量的免费试用。 媒体： video: /media/posts/grok-bot-the-complete-setup-and-usage-guide/2.mp4 诚实的结论：如果你已经为 SuperGrok Heavy 付费，Grok Bot 实际上是免费叠加的。如果你没有，那就是每月 200 美元以上，而且你没法单独试用。在每月 20 美元的 AI 预算下，先熟练掌握 Claude Code/Cowork，你会学得更多、更快、更省钱。 3. 安装和你的第一个机器人（分步） 前置条件：上面提到的付费套餐、桌面应用（macOS / Windows）或 iOS、网络连接。起点：x.ai/bot 和 docs.x.ai/grok-bot/get-started。 确认你的套餐。用拥有该订阅的 Cursor/xAI 账户登录。（提醒：即使你已经有 Super Grok Premium，设置时也可能要求提供信用卡——它不会与 X 订阅自动同步。） 下载并安装桌面应用。macOS：打开 .dmg，拖到 Applications，确认"打开"。 用同一个账户登录。引导流程会问你使用哪些工具——这只影响建议，不连接任何东西。 等待云端电脑完成配置（在后台进行）。 创建你的第一个机器人：Cmd/Ctrl+N 或侧边栏的 New → Create new agent → 出现一个叫"New Agent"的机器人 → Bot actions → Edit Profile（名字、头衔、描述、头像）。 第一条消息是一个真实任务，不是问候。 第一个任务应该完全不需要登录。例如：附加一份文档，要求一个带引用的结构化摘要——约 5 分钟出结果，30 秒可验证。要点是：接下来的步骤是关于逐步建立信任。 4. 机器人描述是"招聘"，不是提示词 能从中获得价值的人和快速放弃的人之间最大的区别是：提示词是一个请求，机器人是一个角色。角色会持续存在、积累记忆，并负责一个领域。 用一份真人可以担任的工作来命名它：Inbox Manager、Expense Manager、Talent Scout、Sales Outbound、Bug Reproduction。"General Helper"是个坏主意：指导更少，而且它保存的上下文更难复用。 "这值得单独建一个机器人吗"测试（5 项全部要求） 目标 —— 一块不属于任何其他人的责任范围 数据源 —— 它自己的一套工具、应用和文件 工作风格 —— 与团队其他成员不同 审批边界 —— 一条明确命名的界限，它在这里停下并询问你 日程 —— 工作按时钟重复进行 描述就是组织架构图 这一点至关重要：机器人之间根据彼此的描述来路由工作。一个没有描述的机器人会从组织架构图上掉下来——在物理上就无法给它派活。如果 Mara 的描述写着"负责市场调研、潜在客户发现和竞品抓取"，那么 Chief 会自动把调研任务转给她，无需你介入。 章程模板（可改编复用）： 你是我的收件箱管理员（Inbox Manager）。 // 你负责什么 每天早晨整理我的邮件。归档新闻通讯和收据。 为客户发来的任何东西起草回复。 标出任何提到截止日期、发票或法律问题的内容。 // 好的标准是什么样 上午 9 点前收件箱清零。草稿听起来像我：简短、直接， 没有"希望这封邮件能让您心情愉快"。绝不超过 4 句话。 // 你在哪里停下 绝不发送任何东西。只起草。 绝不归档我会计师或房东的任何东西。 如果一条消息索要金钱或凭据，停下来问我。 四句话，其中两句是限制。典型的角色卡结尾都有一条边界："未经批准绝不联系客户或更改账户"，"绝不更改生产设置"。 描述承载的是永远成立的规则。消息承载的是今天的工作。 第一条消息 —— 5 个字段 缺一个字段，机器人就会在开始前停下来询问： 结果（Outcome）—— 必须完成什么 数据源（Sources）—— 从哪些应用、网站和文件着手 约束（Constraints）—— 要避免什么、先询问什么 交付物（Deliverable）—— 交回什么 审查点（Review point）—— 它在哪里停下来等你 5. 权限边界：可逆性原则 主要的错误是全都批准。其次是全都不批准。按可逆性来批准，而不是按任务大小。 三个等级 **绿色 —— 直接做，不用问（全部可逆）：**search · read · summarize · compare · organize · draft · calculate · research · reconcile → 直接做并记录 黄色 —— 允许，但只能在已批准的工具内：编辑内部文件 · 创建交付物 · 更新内部数据库 · 移动已批准的文档 · 运行已保存的例行任务 红色 —— 始终需要批准： 向公司外的人发送任何东西 花钱或转钱、承诺某个价格 公开发布任何东西 删除任何不是明显垃圾的东西 更改权限或安全设置 修改生产系统 接受条款、注册、同意任何事情 不确定规则：如果你无法在一分钟内撤销它，就先搁置并询问。 边界正常工作的基准：一个 Sales Outbound 机器人产出了 36 份草稿、发送了 0 封。它做了所有可逆的事，并精确地在不可逆的那一步停下。 放在任何章程结尾的那句话： 边界规则：你有完全权限去调研、总结和保存草稿。 未经本线程中明确的人工审核和批准，绝不点击"发送"或对外发送邮件。 （自动审查，在支持的地方：Require Approval 规则总是阻止匹配的动作，Always Allow 在没有其他阻止理由时放行；当两者同时适用时，Require Approval 优先。这是一个基于模型的检查——是对最小权限原则的补充，而不是替代。个人规则会从你所在的任何设备同步；第二次安装需要单独配置。） 本地执行：Settings → General → Agent → Execution on Local Computer。除非机器人有明确理由处理你的本地文件，否则保持"永不允许"。 6. 访问权限：交出的是登录会话，不是聊天里的密码 这是让一切在没有 API 的工具上正常运转的机制——而真实公司里的大多数软件都没有 API。 交互式会话交接： 机器人在它自己的云端浏览器里导航，碰到登录墙 它暂停并把屏幕交给你（对话中的 Agent Computer） 你接管控制，只完成被卡住的那一步，点击 Done 机器人拿到会话，并从同一个页面继续 机器人拿到的是会话，不是秘密。密码永远不会进入对话记录。 **需要你的五个时刻（其他一切都无需你介入即可运行）：**password/passkey · 2FA · CAPTCHA · 支付或身份验证 · 明确要求真人的网站。 > 绝不要把密码或一次性验证码粘贴到普通聊天里。密码有安全密钥请求，数值会被打码。如果某个工具让你把密码粘贴到对话里，那就是错误路径。 会话是持久的，所以该网站的下一个任务通常一开始就已登录——账户上的其他每个机器人也一样。 连接器（插件）—— 优先于在 UI 上点来点去 Settings → Plugins → 选一个连接器 → Add → 在浏览器中完成授权。连接器是账户级的：添加一次，所有机器人都可用。 原生：Notion、Slack、Google Drive、AWS Agents、AWS SageMaker、Browserbase、Composio、Context7 + 自定义。对于没有原生集成的平台（YouTube API、Reddit、LinkedIn、GoHighLevel、Perplexity），把 Composio 作为主插件连接，并在你的共享知识库里存一条规则，说明扩展工具可以通过 Composio 访问。 在消息中：@ 把一个连接器附加到任务上，/ 调用一个已保存的技能。 先不要连接什么：支付系统、密码管理器、客户消息系统、生产数据库、有破坏性权限的账户。从只读开始。 7. 技能：演示一次，而不是解释两次 一个技能是一个可复用的流程。六个必填部分： 何时使用它 所需的输入和访问权限 工作序列 如何验证结果 输出格式 什么需要批准 技能对整个团队可用，在消息输入框里用 / 调用。 教一个任务（录制演示） 这是产品里最好的功能。你在 Agent Computer 视图中录制你的屏幕，最长 10 分钟，没有麦克风音频；机器人分析 DOM 事件和鼠标操作，交回一份方法草稿供你编辑。 如何挑选你的第一次录制：任务必须同时满足三点——（1）重复性，至少每周一次，（2）多工具，2 个以上工具，（3）稳定，步骤很少变化。 > "从这个仪表盘取数，交叉比对那些下降的指标，把它们粘贴到这个文档的正确标题下，如果有任何东西跌幅超过 15% 就 Slack 通知团队负责人"——写出来是一段话，演示只需 40 秒。 把演示变成技能的提示词： 看我完整地做一遍这个工作流。 记录序列、工具、决策、质量检查、异常， 以及审批点。 先不要自主运行它。 当我完成后，把这个演示转换成一个可复用的例行任务， 并向我展示每一步以供审查。 把例行任务以编号清单的形式返回。对每一步，包括 工具、所需输入、预期输出、失败条件，以及 下一步动作。标记每一个需要人工审批的步骤。 不要只教"顺利路径" 一次录制不会展示现实出问题时该怎么办。明确写出以下情况会怎样： 无法验证某个来源 两份文档相互矛盾 所需信息缺失 某个工具不可用 审查者（Reviewer）否决了输出 任务到达审批关卡 异常才是真正的工作流。大多数自动化会坏掉，不是因为它们不知道序列，而是因为它们不知道序列失败时该怎么办。 技能文件中的示例护栏： # 技能：每周竞品指标提取器 ## 工作流 1. 导航到目标仪表盘 URL。 2. 应用筛选：日期范围 = "最近 7 天"。 3. 将 CSV 报告导出到 /workspace/state/weekly_report.csv ## 护栏与边界情况 - 如果仪表盘显示"Rate Limit"警告，暂停 300 秒后重试。 - 如果出现意外弹窗，在继续前用 'Close' 关闭它。 - 在通知 @Klaus 之前，始终验证导出的 CSV 非空。 在网站、连接器或源格式发生任何变化后，重新测试已演示的技能。从一次网站遍历学来的工作流，对该网站的变化毫无防御能力。 8. 例行任务：日程与触发器 例行任务本质上是 cron，只是界面更友好。你用对话方式创建它，没有可视化节点构建器——实际上大约 2 分钟和一条提示词就够了。 两种触发方式： 日程 —— 早上 7 点的每日简报、周五的 pipeline 总结、月末的费用归档 触发器 —— 一条新的 Slack 消息、一封符合模式的来信、文档中的一处变更。触发器让机器人感觉"随时在场"而不是"按时出现"。 创建时指定：日程和时区、输入源、预期结果、审批边界，以及来源缺失时的行为。 // 日程 —— 早晨简报 每个工作日上午 7 点，检查我的日历、收件箱，以及 #launches Slack 频道。给我一份简短简报：今天有什么， 什么需要回复，一夜之间发生了什么变化。 // 触发器 —— 来信捕捉器 每当一封邮件来自不在我联系人中的域名，并且 它提到定价，就从模板起草一封回复并搁置它。 // 日程 —— 每周收尾 每周五下午 4 点，从我的收件箱里拉出本周的收据， 归档它们，并告诉我任何没有对应发票的东西。 // 创建大多数例行任务的捷径 "每周运行一次这个。" ^ 在你喜欢的一个任务之后说这句话。整个流程就是如此。 总是在结尾加一条停止规则（比如"只使用本周的数据"）——它能把昨天的数字挡在周一之外。 总是在启用前做一次测试运行。测试运行会执行真实工作——保持输入安全，并把每个写操作放在审批之后。删除例行任务是永久的。 已知缺口：在群聊里，机器人无法一起保存例行任务。日程必须在每个机器人的单独会话中设置。 9. 机器人团队：Chief of Staff 拓扑 初学者最大的错误是创建一打各自为政的机器人，然后手动管理它们。 人类操作者 │ ▼ CHIEF OF STAFF（"Klaus"） │ （异步的机器人对机器人委派） ┌───────────┬─────────┼─────────┬────────────┐ ▼ ▼ ▼ ▼ ▼ Lead Scout Copywriter Designer Ops Tracker CFO/Audit （"Mara"） （"Cole"） （"Rina"） （"Vince"） （"Owen"） 在应用里看起来是这样：左边是名字组成的侧边栏，右边是对话线程。每个名字都是一个单独的机器人，有自己的记忆和自己的电脑。 角色： Chief of Staff —— 你的单一入口。它不自己做所有事：它接收高层目标，把它们拆成子任务，委派，保留共享上下文，检查每一次交接，只升级真正需要你的事情。 Research / Lead Scout —— 收集证据、记录来源、把事实和假设分开 Strategy —— 把证据变成决策和优先级 Execution / Copywriter / Designer —— 产出工件 Reviewer / Ops —— 对照合同测试结果，否决不达标的 规模规则：从最小的有用团队开始。每多一个机器人，就多一个上下文窗口、多一次交接、多一处信息丢失的地方。只有当工作需要不同的工具、不同的上下文、不同的专长、独立验证或并行执行时，才创建一个专家。对大多数知识工作型任务来说，4 个专家就够了。在第一版能跑起来之前，不要超过 4 个。 超过 4–5 个机器人后会出现的问题：并行交接会产生重复工作和嘈杂的更新。在每一阶段要求单一负责人。 群聊 2–6 个机器人。描述共同结果并指定下一个负责人；机器人自己协商谁来回答，@ 则指定某一个。给群组一个目标，而不是任务清单：清单意味着你已经完成了拆解，机器人只是在执行你的计划。 异步消息：一个机器人给另一个机器人发消息，接收方醒来、处理、稍后回复；整个往来在对话中保持可见。 发送到群组的交接消息是纯文本的。一个需要另一个机器人看图片的机器人必须直接发送。 交接格式 交接不应该意味着"这是我发现的东西"。它应该意味着"这是工件，这是它背后的证据，这是仍不确定的地方，这是确切的下一步动作"。 目标 / 工件 / 证据 / 状态 / 障碍 / 下一步动作 证据随工作一起流转。绝不要让下一个智能体从聊天记录里重建它。 复制机器人 会带过去：资料、设置、已启用的技能、例行任务、头像。不会带过去：对话历史、学到的记忆、聊天附件。副本以 <name> copy 的形式出现——在它接活之前先重命名。 10. 任务合同（Mission Contract）—— 用于复杂任务 与其说"创建一个研究智能体"（那描述的是活动，不是胜利），不如把它表述得让团队知道"完成"意味着什么。 ❌ 每周研究我的竞争对手。 ✅ 每周五下午 4 点，交付一份经过验证的竞品报告，包含五个最重要的产品、定价和定位变化，每条结论的来源，它们对我们业务的可能影响，以及三条建议行动。 合同的七个字段：结果 · 输入 · 输出 · 频率 · 完成的定义 · 约束 · 审批关卡。 构建合同的提示词： 我想让一个 AI 团队负责这个任务：[描述结果]。 先不要创建智能体。 一次一个问题地采访我，直到你理解输出、 频率、来源、工具、质量标准、约束和审批关卡。 然后返回一页任务合同，包含：结果、输入、 输出、完成的定义、日程、约束、所需审批。 不要接受"好"、"有用"或"专业"作为质量标准。用检查项替换它们： 每一条事实性结论都有来源 每个来源都有发布日期 重复项已移除 建议引用证据 最终结果不超长 没有审批不发生任何对外行动 > 如果终点无法度量，智能体就无法可靠地到达终点。 验收标准比角色更重要 /workspace/ ├── bin/ # 自定义 CLI、node 脚本、可执行工具（加入 PATH） ├── config/ # 环境文件、API 配置、持久化设置 ├── skills/ # 技能 markdown 文件和 SOP └── state/ # 长期存储、SQLite、JSON 日志、项目输出 ❌ 找有用的来源。 ✅ 返回 10 个不重复、90 天内发布的来源。每个包含：URL、日期、作者、关键结论和置信度。 审查者指令： 对照任务合同评估每一份交付物。 如果不合格，指出确切的不合格标准，并把它退回给 能够修复它的专家。 包含问题、佐证、所需修正， 以及预期输出。 不要自己重写交付物。 重新检查修正后的结果。 三轮失败后停止，并用一份简明的 失败报告升级。 审查者应该精确地否决，而不是悄悄地修复一切——否则它会变成第二个执行智能体，成为新的瓶颈。 是图，不是链 正向路径：任务 → Chief → Research → Strategy → Execution → Reviewer → Approval 反向路径：Reviewer → Research/Execution → Reviewer 链把工作向前传。图决定工作下一步去哪里。 11. /workspace —— 什么能在 VM 更新后存活 大多数指南都跳过的最重要的技术细节：云端 VM 会定期更新并重建自身。 重建后会消失的东西：/home/box/deps 里的所有东西、/usr/local、全局 apt 包、手动安装的 CLI（Tailscale、ssh、自定义 Python 包、爬虫）、未保存的浏览器状态。 只有 /workspace 能存活。在一台实时机器上更新后检查：只有 /workspace 还在，/home/box/deps 回来时是空的，apt 包和 /usr 都没了，Tailscale 和 ssh 不得不重新安装了不止一次。 结构 从那时起，home 就变成了缓存。团队需要的任何东西都不应该依赖 apt 包。常见错误：机器人自己建议把技能放到 ~/.agents/skills/... —— 那不会在重建后存活。同样的技能放到 /workspace/skills/ 就能存活。 技能文件的自愈头 因为 box 有 sudo NOPASSWD: ALL，机器人可以自愈自己的环境： # Auto-Recovery Header for Skill Execution if ! command -v tailscale &> /dev/null; then echo "CLI dependency missing after VM rebuild. Reinstalling..." sudo apt-get update && sudo apt-get install -y tailscale fi # Resume skill execution tailscale status 团队在开始工作前先恢复自己的工具；缺失的 CLI 会自行重装，任务继续。 12. 不要自动化第一次成功运行 每个人都违反的顺序： 运行一个真实任务 —— 实时的，范围错得起 修正结果 —— 一直改到输出是你会愿意审查的东西 把方法保存为命名技能 —— 带来源、输出格式、审批规则 在第二个输入上测试它 —— 不同账户、不同文件、相同步骤 只有到这时才创建例行任务 > 例行任务会继承所有未言明的假设。这就是顺序如此安排的原因。 三次运行证明（用于团队和任务） 第 1 次 —— 观察。上下文在哪里丢失，工作在哪里重复，哪条指令被误解，哪个审批意外出现，哪个质量检查失败。不要手动修最终结果——去修造成这次失败的章程、例行任务或交接。 第 2 次 —— 修正。给它一个不同但有代表性的任务。检查团队是否在没有新指令的情况下避开了之前的失败。如果同样的错误再次出现，说明修正从未进入持久记忆。 第 3 次 —— 放行。除非以下情况，否则不干预：需要红色操作 / 合同含糊 / 修正循环失败三次。 度量五件事：完成率 · 人工干预 · 审查循环 · 到结果被接受的时间 · 每个被接受结果的成本。 不要自动化第一次成功运行——自动化连续三次成功运行。 13. 每周审查：自动化会悄悄腐烂 网站改了布局，例行任务开始悄悄产出垃圾，而因为机器人在你睡觉时运行，三周都没人注意到。这是所有常驻系统的失败模式。 日历上留 15 分钟。每个例行任务问三个问题：它运行了吗？输出真的对吗？如果我删掉它，我会想念它吗？第三个比看起来更重要——这类系统的自然漂移是一堆半有用的自动化，没人有勇气删除。 列出你本周运行的每个例行任务。对每一个： - 它触发了多少次 - 它产出了什么 - 它跳过、失败或不得不猜测的任何东西 - 任何它为我搁置、而我从没回答的东西 然后告诉我你认为哪一个最没用，以及为什么。 外加一个每周自我改进例行任务： 审查本周完成的每个任务。 找出重复的修正、不必要的交接、重复的工作、 缺失的上下文，以及用户不止一次做出的决定。 提出对智能体章程、共享记忆、例行任务 和验收标准的更新。 在应用任何改动前展示每一个提议的改动。 未经明确批准，绝不更改原始任务合同。 但是：每个例行任务手工抽查一个输出。一个汇报自己工作的机器人，有着和你一样的盲点。 这就闭合了复利循环：执行 → 审查 → 修正 → 记住 → 执行得更好 14. 现成提示词库 研究助手（内容 / YouTube） 这类机器人真正的产出是一张离群视频的排序表，带一个相对频道中位数的倍数： 每天早上 6 点，扫描覆盖 AI、 Claude 和 AI 智能体的顶级 YouTube 频道。找出离群值——那些播放量 明显高于该频道中位表现和订阅数所能预测的视频。 对每个离群值，拉取字幕，告诉我你认为它为什么 有效，并给我 3 个基于它的衍生视频点子。 把整理好的清单作为早晨简报呈现给我。 房产侦察员 每天两次，早晚各一次，扫描[房产网站]上符合以下条件的新房源： [预算区间]、[房产类型]、[区域/街道名称]。 将每个房源与该区域最近的成交可比案例进行对标。 标记任何挂牌价低于可比价 15% 或更多的房源。 把标记的房源放进电子表格，包含地址、价格、预期 市场价值，以及低于市场的百分比。 如果有符合条件的，立即通知我。 CFO / 投资组合分析师 你是我的投资组合分析师。这是我的投资组合：[链接/访问权限]。 每天早上给我：我各个持仓的隔夜变动，今天的 主要市场事件和日历，并标记任何表现出 意外或显著波动的。 如果有什么看起来需要决策——再平衡、某个偏离目标的持仓—— 明确告诉我你会建议什么以及 为什么，但未经我批准不要采取任何行动。 EA / Slack 分流 每天早上检查我们公司的 Slack。给我一个简短总结： 夜里进来的任何紧急事项，任何需要我 特别回复的，以及任何我可以安全忽略的。 只保留要点——我要的是分流，不是逐字记录。 外呼 SDR（小心——红色操作） 你是我的外呼 SDR。 拉取 40 个符合[行业、规模、头衔、地区]的潜在客户。 研究每一个，写一封 3 行冷邮件：一句关于他们的具体描述， 一句关于我们交付的成果，一句温和地请求 15 分钟通话。 把一切记录在 [CRM]。每天早上给我发一条 5 行总结。 停止规则：什么都不要发。把草稿排队等我的批准。 （在原始的"上帝模式"版本里，这个机器人会自己发送并预约通话。在你通过三次运行证明、并准备好承担一批坏邮件发出去的后果之前，不要那样做。） Chief of Staff —— 运营章程 你是负责 [任务] 的 Chief of Staff。 你从请求到获批结果全程负责这个任务。 把每个请求转成计划，把工作分派给正确的专家， 保留共享上下文，检查每一次交接，只升级 需要用户的决策。 你可以调研、计划、委派、起草和审查。 在发送、发布、花钱、删除、联系 他人、登录新账户或更改生产数据之前，你必须询问。 维护一份决策日志。绝不让无依据的主张或未完成的 工作到达用户。 设计最小团队 设计一个能从始至终完成这个任务的、最小的专家团队。 只有当工作需要不同的上下文、工具、 专长或独立验证时，才创建一个专家。 对每个提议的智能体，定义它的角色、输入、动作、输出、工具、 约束、验收标准和交接目的地。 移除任何工作可以被另一个智能体可靠完成的角色。 在扩展之前先测试 Chief 把任务合同转成计划。不要执行它。 向我展示阶段、所需专家、审批关卡， 以及可能的失败点。 如果 Chief 拿不出一份干净的计划——不要创建更多智能体。先修正任务本身。 15. 一个实际案例：为 X 建的内容团队 一个真正有效的结构： 研究机器人 —— 追踪趋势，深挖相关仓库和公开讨论，找出真正值得写的东西，而不是凭空猜内容日历 创意机器人 —— 喂给它几张你喜欢的风格的参考信息图；从那时起，它按那种美学生成视觉，而不是从空白画布开始 草稿机器人 —— 把研究和创意方向变成帖子文案，随时可审 顶层通用机器人 —— 每个人做了什么的每日汇总。这是"知道你的智能体完成了什么"和"希望它们做了点什么"之间的区别。 因为智能体住在同一台电脑上，一个智能体完成的研究立即可供下一个使用——不需要手动复制。 这类系统会收敛出的内容结论：帖子应该真实、有用或有趣（理想情况下三者兼具）。一篇帖子一个想法。多回复，少广播。视频和图片胜过纯文本。但真正的风险不是算法——是无聊。不要试图钻系统空子：规则每个月都在变。 这已经有效的其他方向：SEO/AEO 机器人（趋势研究、简报、内链、为 LLM 如何呈现答案做优化）· PR 机器人（故事角度、媒体数据库、提及监控）· 付费广告机器人（创意角度、出价管理、测试积压）· CRO 机器人（实验设计、落地页变体文案）· 外呼机器人 · 按机上联网情况找航班 · 从食谱照片下单买菜 · 修复数百份扫描件的 GPS 元数据 · 谈判承包商报价 · 在电话前翻译销售演示稿 · 用会议纪要点自动更新演示稿。 一个有说服力的案例：一个机器人处理了约 40 家越南纺织厂——它们用 WhatsApp 而不是邮件回复。它自己就联系上了前 10 家。一份聊天草稿对那个工作毫无价值。 16. 风险、限制、诚实的缺点 你为便利换掉了什么： 你不能选模型——就是 Grok，没有别的 你不拥有这套 harness：它捆绑在订阅里，不是一个独立产品 你的数据存放在他们的云端电脑上 智能体之间没有隔离——共享浏览器、共享文件、共享凭据。任何一次连接的爆炸半径，是你将创建的每一个机器人。 记忆机制（摘要缓冲 / 文件 / 检索）官方没有披露 技术坑： 机器人点击真实界面 → 一次改版或一个随机弹窗就能弄坏它们 "90% 完成和 100% 完成是两码事"；最后一段会在奇怪用例上咬人 群聊不会在团队层面保存例行任务 机器人对机器人的交接消息是纯文本的 截图密集的自动化会烧掉每周用量池 与其他方案的对比： Grok Bot 去掉了维护——同时也去掉了隔离。这个选择真正关乎的是：谁来承担运营，以及你到底愿意把什么登录到一台你看不见的电脑上。 推荐的混合技术栈：Grok Bot 用于 24/7 的运营工作（调研、爬取、视觉任务、社媒监控、线索生成）+ Claude Code/Cowork/OpenCode 用于交互式开发（重构、架构、迁移、快速修 bug）。 要点 到目前为止，每个 AI 产品都把模型放在一个窗口里，把工作留在你手上。Grok Bot 把工作转移了：机器人拥有电脑、登录、记忆和时间——而你拥有决策。 这在技术上是个比听起来更小的变化，在习惯上则是个大得多的变化。 目标不是最大自主性。目标是在受控权限下的可靠自主性。 收藏这篇文章。关注 @0xGenAi 标签：# X # Grok Bot # AI # Claude # Slack # Automation # Youtube # Design # Thread # Guide # Cowork 相关文章 我如何用 Grok Bots 让品牌在 AI 答案里排名，好用到感觉不合法 把这个机器人命名为 `CrowdReply - Scout`。Grok Bot AI MCP Slack