​打开电脑，处理邮件、整理资料、追踪新闻、更新项目进度，再把几个软件里的信息汇总成一份报告。

这些工作单独看都不复杂，麻烦在于它们分散在不同的应用里。即使已经用上ChatGPT或Claude，很多人仍然需要反复复制材料、解释任务背景，再把AI生成的结果搬回原来的软件。

现在，Grok Bot想把其中相当一部分操作接过去。

2026年8月11日，xAI正式发布Grok Bot，推出一套能够持续执行任务的AI Agent系统。用户可以创建具有固定职责的Bot，让它使用云端计算机访问网站、操作软件、整理文件，并在需要时将工作交给其他Bot。

这意味着，一项任务可以在用户关闭电脑后继续运行。对于有明确执行流程的工作，Bot还可以保存操作步骤，并按照设定的时间重复执行。

机制示意｜Grok Bot的云端运行、任务处理与多Bot协作

Grok Bot发布时仍处于Beta阶段。8月26日，官方又扩大了订阅用户的使用范围。进入10月，The X Subscription进一步调整了Grok、Cursor与Grok Bot的订阅关系。

在这段时间里，围绕Grok Bot出现了不少使用方案：有人把它配置成负责整理邮件的助理，有人让它持续跟踪行业情报，还有人用多个Bot分别处理研究、写作和运营。

官方案例中甚至出现了由多个Bot协同管理软件开发任务、准备营销材料和追踪客户信息的工作流。

不过，能够打开网页和执行操作，只解决了自动化的一部分问题。

如果信息来源不可靠，Bot可能认真地整理错误资料；如果任务没有明确边界，原本只需要准备一份草稿，它也可能尝试完成更多操作；如果长期保存的上下文没有得到维护，过去正确的判断也可能逐渐失效。

所以，想用好Grok Bot，需要理解它怎样工作，也需要学会组织任务、保存知识和控制权限。

这篇文章从安装和创建第一个Bot开始，逐步介绍云电脑、应用连接、Skills、Routines、长期记忆与多Agent协作。最后，我们将围绕一个具体的工作目标，设计一套从AI新闻研究到公众号初稿的完整流程。

所有操作以截至2026年10月26日可核对的官方文档为依据。文中的Prompt和工作流属于可复现的教学方案，未提供实际运行记录的部分不作为实测结果。

---

一、Grok Bot究竟是什么？先弄清楚它怎样完成工作

先看一个普通的任务。

假设你正在经营一个AI科技公众号，每天早上都要查看几家AI公司的公告，找出过去24小时发生的重要更新，再判断哪些内容值得写成文章。

使用普通聊天工具时，你可以询问AI最近发生了什么，也可以让它总结网页。但如果想把这个过程固定下来，每天自动重复，还要长期记录已经研究过的选题，事情就复杂了。

你需要考虑任务什么时候开始、信息从哪里获取、结果存在哪里，以及下一次执行时怎样避免重复。

Grok Bot把这些环节放进了一个持续运行的Agent环境。

根据官方产品介绍，Bot拥有自己的任务角色和对话上下文，可以在云端计算环境中使用浏览器、文件系统、终端以及连接的应用。

用户通过自然语言描述目标，Bot会尝试规划执行步骤、调用工具，并把执行结果返回对话。

1. Bot、Agent和大模型有什么关系？

可以先区分三个概念。

大语言模型（LLM）负责理解输入、生成文本、推理和作出下一步判断。

Agent在模型能力之外增加了工具调用与任务执行机制。它可以依据任务目标选择工具，观察执行结果，再决定后续行动。

Bot则是Grok Bot产品中可以长期保留的Agent角色。每个Bot都有名称、职责、对话和相应的工作上下文。

例如，你可以创建一个Research Bot，让它长期负责研究资料；再创建一个Writing Bot，负责将整理好的资料转换成文章草稿。

这两个角色可以分别保存自己的工作要求。

Research Bot关注来源是否可靠、新闻是否过时、事实是否存在冲突。Writing Bot则关注文章结构、观点推进和语言规范。

角色分工越明确，后续重复使用时越容易保持稳定。

当然，给Bot取一个名字，不会自动赋予它某种专业能力。实际效果仍然取决于模型、工具权限、任务要求以及它能访问的数据。

2. 为什么云电脑是关键？

普通的AI对话通常围绕一个会话展开。用户提出问题，模型生成结果，任务在当前交互中完成。

Grok Bot提供的是一个能够保留工作状态的云端计算环境。

根据官方文档，这个环境包含浏览器、文件系统和终端。Bot可以使用它打开网页、处理文件、执行命令，并在任务结束后保留部分工作成果。

最直接的区别发生在设备关闭以后。

假设你安排Bot每天早上7点整理新闻。实际运行任务的是云端计算环境，本地电脑不需要一直开机。只要任务被正确创建、没有被暂停，且服务和用量条件允许，它就可以按照计划在后台启动。

机制示意｜单次对话与持续任务执行

还有一个需要特别说明的细节。

同一个账号下的多个Bot共享一台云电脑。

它们可以拥有不同的工作界面和独立的对话上下文，但共享文件、浏览器登录状态和部分工作环境。

官方将计算环境与用户账号关联，而非为每个Bot建立完全隔离的计算机。

这种设计便于协作。研究Bot保存的资料，写作Bot可以继续读取，不需要用户反复传递文件。

与此同时，权限也会产生关联。如果一个Bot能够访问某份保存在共享工作区的敏感资料，其他Bot通常也可能访问它。

后面讨论安全时，我们会进一步处理这个问题。

3. 它能操作哪些软件？

Grok Bot主要通过两种方式使用外部工具。

第一种是连接应用。

例如Gmail、Google Calendar、Google Drive、Notion和Slack。对于已经提供结构化连接能力的服务，Bot可以通过应用连接完成搜索、读取或获得授权的写入操作。

第二种是Computer Use，也就是通过计算机界面完成操作。

对于没有合适连接器的网站，Bot可以尝试使用浏览器打开页面、点击按钮、填写表单和读取结果。

两种方式各有适用范围。

连接器通常具有较明确的接口和权限范围，处理结构化信息更直接；Computer Use则能够覆盖一部分没有开放API的网页操作，但它需要面对页面变化、验证码、登录过期以及网站限制。

因此，不能把“支持操作网页”理解成能够无障碍控制互联网上的所有服务。

官方也明确提醒，部分网站可能阻止自动化访问，或者要求用户亲自完成身份验证。

4. 什么任务适合交给Grok Bot？

可以从一个简单标准判断：任务是否有明确的输入、操作流程和完成条件。

例如，整理每天收到的工作邮件，提取会议纪要中的待办事项，比较竞争对手的产品更新，或者从指定网页收集资料生成研究简报。

这些任务通常能够定义数据来源、交付格式和检查标准。

相反，选择公司的长期战略、判断一个创意是否足够优秀、决定是否公开发布争议性观点，仍然需要人参与。

Grok Bot可以为这些决策准备材料，但难以单靠自动执行替代完整的专业判断。

对于初学者，最有效的入门方式是找一项已经熟悉、每周都会重复、结果又容易检查的工作，先交给一个Bot完成。

---

二、从零开始：安装、登录，创建你的第一个Bot

理解基本原理以后，接下来进入实际操作。

Grok Bot目前提供桌面和移动端应用。根据官方文档，桌面端支持macOS、Windows与Linux，移动端支持iPhone和Android。

不同系统的版本要求及功能开放情况可能不同，安装前应查看当前的官方入门指南。

1. 先确认账号与订阅

这是很多教程容易写错的地方。

Grok Bot在2026年8月刚发布时，最初的订阅准入范围比较有限。此后官方逐步扩大可用套餐。到了10月，新推出的The X Subscription又整合了Grok、Cursor和X的部分订阅权益。

截至本文资料核查日期，官方说明The X Subscription的Premium、Super和Ultra档位包含Grok Bot，Free及Plus不包含。

The X Subscription	公布的美元月费	Grok Bot
Free	$0	不包含
Plus	$8	不包含
Premium	$30	包含
Super	$100	包含
Ultra	$200	包含

这张表对应官方公布的美元标价，实际显示金额可能受地区、税费和支付渠道影响。

已有的Cursor Pro、Pro+、Ultra以及部分旧版SuperGrok订阅仍有相应访问途径，不能简单按新套餐名称判断权限。

另外，新订阅体系中的Grok Bot会使用跨产品共享的每周额度。旧版套餐的用量计算方式可能不同。详细信息以Plans and billing和The X Subscription定价说明为准。

这也意味着，不建议单凭早期文章里提到的7天试用、单独收费档位或某个固定使用次数决定是否购买。

先确认自己账号显示的权限和收费规则，再开始配置。

2. 下载并登录

建议第一次使用从桌面端开始。

进入Grok Bot官方入口，按照页面提供的下载或账号跳转指引获取安装包。已有Cursor账号的用户，也可以通过Cursor后台寻找Grok Bot的安装入口。

完成安装后，打开应用，选择Sign in。

根据官方入门文档，登录过程使用Cursor账号体系，认证一般在浏览器中完成。已经接入新版统一订阅的用户，按照账号实际提供的登录流程操作。

首次进入时，应用会展示简短的引导，并建立初始Bot。

如果已经有Bot，或者想新增一个专门负责工作的角色，可以从侧边栏的“+”入口创建。

不同版本中，这个操作可能显示为New Bot、Create a Bot或Create new Bot。

给它起一个能反映职责的名字，例如“AI News Research”。

教程示意｜登录与创建Bot界面

3. 第一个任务先不要连接复杂系统

初学者容易一开始就建立十几个Bot，同时连接邮箱、日历和网盘。

这种方式会让问题难以定位。

一个更稳妥的起点，是让Bot完成一次不涉及外部写入的资料整理。

先准备一份PDF，可以是某家AI公司的公开技术报告或者产品公告，然后将其上传到对话。

输入：

你的名字是Research。

你的主要职责是整理技术资料，提取事实，并保留信息来源。

请阅读我上传的PDF，完成以下任务：

1. 用300字以内概括主要内容。
2. 提取文中的关键日期、产品名称和技术术语。
3. 找出作者明确给出的事实与数据。
4. 列出三个值得进一步研究的问题。
5. 对每项关键事实标注对应的章节或页码。

要求：
不得补充文件里没有的信息。
不确定的内容单独列出。
不要修改原始PDF。
不要向任何外部服务发送内容。

请记住这些工作要求，供后续同类任务使用。

这段指令包含五个要素：职责、输入、任务步骤、输出要求和权限限制。

完成以后，重点检查Bot是否正确引用文件内容，有没有把推测写成事实，以及是否遗漏关键日期。

如果发现问题，可以直接反馈具体错误。

例如：

“第二项中的发布日期与PDF不一致，请重新核对原文，并附上页码。”

此时不需要重新创建Bot。它会继续在原有对话里处理修改。

4. 怎样判断第一次使用是否成功？

不要只看回答是否流畅。

检查三个更具体的结果。

首先，Bot能否正确使用提供的材料。其次，它能否按要求输出，尤其是日期、引用和待核实项。最后，当材料缺失时，它能否明确承认无法完成，而非自行补造内容。

如果这些条件成立，就已经完成了一个有价值的入门测试。

下一步再让它访问网页或连接外部应用。

机制示意｜输入资料、执行分析和生成结果

---

三、云电脑与应用连接：让Bot进入真实工作环境

第一个任务解决了如何向Bot分配工作的问题。

但如果每次都需要手动上传资料，能够自动化的范围依然有限。

接下来要让它访问工作资料所在的软件。

1. 从Connect apps连接服务

Grok Bot提供Connect apps入口，能够搜索并添加支持的应用。

以Gmail为例。

在侧边栏找到Connect apps，搜索Gmail，选择添加，然后按照界面引导完成账号授权。

部分应用需要额外点击Authenticate或Authorize。添加成功以后，仍要确认授权状态已经变成Connected。

因为“已经添加应用”和“已经完成账号认证”是两回事。

Google Workspace企业账号还可能遇到管理员审批要求。遇到这种情况，应联系相应管理员，不要通过更换浏览器或其他方式绕过组织的访问控制。

教程示意｜连接面板

应用连接完成后，就可以给Bot安排使用真实数据的工作。

例如：

请使用已经连接的Gmail，检查过去7天收到的邮件。

整理与以下主题有关的内容：
项目进度、客户需求、会议安排。

输出：
1. 需要我回复的邮件。
2. 已经明确的工作决定。
3. 含有截止日期的任务。
4. 尚未解决的问题。

每项保留邮件主题、发件人和原始邮件链接。

只读取和整理，不发送邮件，不修改标签，
不删除邮件，也不要标记已读。

找不到信息时直接说明，不猜测。

这个任务的价值在于省去了手动复制邮件的步骤。

不过，连接Gmail时需要明确权限范围。官方文档指出，Gmail连接可以具备搜索、读取、草稿、发送和标签操作能力，具体动作受账号授权及安全规则约束。

因此，涉及真实邮箱时，应先用低风险任务熟悉Bot的行为。

2. 什么时候使用Computer Use？

假设你需要研究某家软件公司的更新日志，但它没有提供合适的应用连接器。

此时可以让Bot尝试打开官方网站，从网页中找到版本更新记录。

例如：

打开我提供的产品更新日志网页。

找到最近三个正式版本的发布记录，
分别提取：
版本号、发布日期、主要更新内容和原文链接。

只读取公开页面。
如果需要登录、遇到验证码或网站拒绝访问，
暂停操作并告诉我，不尝试绕过限制。

整理完成后保存为Markdown文档。

Bot可以在云电脑里尝试完成浏览、读取和保存。

如果出现必须由用户处理的登录步骤，它可能要求你接管计算机界面。

官方将这类操作称为Take over。用户完成必要的验证后，再交还控制权。

这里需要注意，云电脑与用户本机是两个环境。打开Bot的计算机预览，看到的是它正在使用的云端工作界面。

官方也提供了受权限控制的本地执行能力，但本地执行与云端Computer Use采用不同的权限规则。初学者暂时不需要启用本地命令执行。

3. 为什么优先使用结构化连接？

通过网页操作软件虽然直观，但网页经常发生变化。

例如，原本位于右侧的按钮移动到顶部，登录页面增加新的安全检查，或者数据表格变成分页加载。

这些变化都可能使此前可用的流程失败。

当服务提供稳定的连接器时，优先采用连接器通常更容易维护。网页操作则适合补充无法通过连接器完成的任务。

实际使用时，可以把处理顺序写进Bot的长期要求：

“优先使用已授权的结构化连接。如果连接器无法完成操作，再考虑网页界面。遇到登录阻碍或权限不足时报告原因。”

这样能够减少不必要的网页交互。

4. 给操作留下可检查的记录

Bot能够完成某项操作，不代表用户就应该直接接受结果。

尤其是多个系统之间的信息转移，应该保留执行记录。

例如，让Bot生成一份清单，记录读取了哪些文件、访问了哪些网页、创建了哪些结果文件、哪些操作失败以及哪些内容等待审批。

对于准备发给客户的文件，最好要求它提供可编辑的草稿，而非直接发送。

教程示意｜屏幕UI

这一阶段的目标，是建立一个能访问真实材料、完成有限任务、留下审查记录的Bot。

接下来，就可以让它学习一套固定的工作方法。

---

四、让Bot真正能干活：先把任务设计清楚

同样是一个AI模型，为什么有的Agent能完成复杂任务，有的却在几个步骤以后偏离目标？

很多时候，区别出现在任务设计。

假设你告诉Bot：“帮我研究AI行业。”

它需要自行猜测研究范围、来源、时间区间、分析方法和最终格式。不同理解都可能合理，输出自然会不稳定。

但如果你告诉它每天检查指定公司的官方公告，排除重复新闻，并输出三条有原始链接的重要更新，任务的完成标准就清楚得多。

1. 好任务至少回答六个问题

第一，它负责什么。

第二，需要从哪里获得信息。

第三，在什么条件下启动。

第四，按照什么步骤处理。

第五，什么样的结果才算完成。

第六，哪些操作必须得到用户批准。

可以用一个通用任务框架：

角色：
你是负责[具体工作]的Bot。

目标：
完成[可以检查的结果]。

来源：
只使用[指定数据或允许的来源]。

步骤：
1. ...
2. ...
3. ...

输出：
保存为[文件或消息格式]。
必须包含[关键字段]。

验证：
检查[准确性、完整性、重复项、来源]。

限制：
不得执行[禁止操作]。
遇到[异常情况]时停止并报告。

这个结构既适合Grok Bot，也适合多数具备工具调用能力的Agent系统。

Mahax在2026年8月发表的Grok Bot使用文章里，也采用了类似的角色、目标、周期、输出和规则结构。其价值在于让任务说明更接近实际工作流程，而非一次性提问。

2. 任务越大，越需要拆分检查点

以制作科技新闻简报为例。

如果直接要求Bot“收集、分析并写好今天的新闻”，它可能在找到几篇文章后立即开始写作。

但实际工作还需要处理重复报道、历史新闻和信息冲突。

可以把任务拆成几个阶段。

先收集候选信息，只记录标题、日期和来源。

再判断哪些属于新的、可以验证的事件。

接着筛选值得关注的更新，最后生成简报。

每个阶段都有对应结果。某一步出现错误时，可以只重新执行那一步。

3. 用完成标准取代模糊的质量要求

“写得专业一点”“尽量准确”“内容要有深度”，这些要求对人也不够明确。

可以改成：

“每项事实必须附原始出处；同一事件的转载只保留一个主记录；产品价格必须附核查日期；不把作者观点写成官方结论。”

这样的要求可以直接用于检查结果。

以内容创作为例，还可以要求Bot把最终输出分为事实、分析和待核实事项。

用户能够快速判断哪些内容可以采用，哪些仍然需要研究。

4. 不要让Bot自行扩大权限

假设任务是整理客户邮件，Bot发现部分邮件需要回复。

这并不自动意味着它可以替用户回复。

可以明确规定：“允许生成草稿，但不得发送；允许创建本地报告，但不得更改原始邮件。”

操作范围一旦明确，后续保存为Skill或Routine时，就能继续沿用这些限制。

这是设计长期自动化前必须完成的一步。

---

五、Skills：把一次成功操作保存下来，下次直接复用

假设你已经让Bot成功整理了一期AI新闻简报。

第二天，你还要重复同样的要求：查找新闻、核对日期、排除重复、保留来源，再按固定格式输出。

第三天也是如此。

每次都重新描述整套流程，既浪费沟通，也容易出现细节差异。

Grok Bot的Skills就是为重复使用工作方法而设计的。

根据官方Skills文档，Skill是一组可复用的任务说明，能够包含执行步骤、判断规则、结果格式和安全边界。

1. 什么时候创建Skill？

官方推荐的顺序很明确：

先完成一次实际任务，确认方法可靠，保存为Skill，最后再考虑自动化。

例如，第一次整理新闻时，可能发现Bot将两篇转载当作两条独立新闻。

第二次修改后，又发现它引用了过期价格。

第三次调整规则，最终得到符合要求的结果。

这时再保存流程，比直接把第一版提示词转换成Skill更稳妥。

因为Skill应该保存经过验证的方法，而不只是尚未执行的设想。

2. 创建一个新闻研究Skill

假设已经完成了一次合格的研究任务，可以在对话中输入：

请将我们刚才完成的新闻研究流程保存为一个Skill。

名称：AI News Research

用途：
研究指定时间区间内的AI产品更新。

输入：
研究时间范围、目标公司、信息来源。

执行步骤：
1. 收集候选信息。
2. 核查原始发布日期。
3. 识别同一事件的重复报道。
4. 提取可以验证的事实。
5. 区分事实、作者观点和推测。
6. 标记需要再次核实的内容。
7. 生成研究简报。

输出：
Markdown格式，包含：
标题、日期、来源、事实摘要、
相关背景、重要性判断、待核实事项。

验证要求：
所有关键事实必须对应来源。
不得编造链接或发布日期。
发现来源冲突时保留冲突信息。

安全规则：
只进行研究和资料整理。
不登录未经授权的服务。
不公开发布，不向外发送。

Bot生成Skill后，应检查它保存的步骤是否完整，有没有遗漏时间范围和审批条件。

官方说明，已保存的私人Skills可以在Bot之间共享，桌面端可通过输入“/”查找可用Skill。

如果某个Skill没有显示，需要检查它是否已经为当前Bot启用。

教程示意｜操作界面

3. 通过操作演示创建Skill

除了文字描述，Grok Bot还提供Teach a task功能，用于学习用户演示的浏览器工作流程。

在支持该功能的界面中，用户可以打开Bot的计算机视图，选择Teach a task，说明准备演示的目标，然后亲自完成一次操作。

停止录制后，Bot会根据可见操作生成Skill草稿。

这里需要纠正一些早期教程中的模糊表述。

截至本次核查，官方文档说明该功能记录最长约10分钟的可见计算机交互，不录制麦克风音频。功能仍可能分批开放，用户界面未必已经出现对应入口。

而且，录下操作步骤不等于流程已经具备完整的异常处理能力。

例如，你演示了怎样从网页复制一张表格，却没有遇到表格为空、网页加载失败或按钮位置改变的情况。

Bot也就未必知道这些问题应该怎样处理。

因此，生成Skill以后还需要补充判断规则和失败处理方案。

4. 怎样测试一个Skill？

可以准备一份不同于第一次使用的资料。

例如，首次测试使用产品公告，第二次则使用一份技术报告。

观察它能否识别输入变化，是否仍然按照要求保留原文证据。

如果需要处理完全不同的数据结构，可能应当新建Skill，而不是不断向一个Skill添加大量例外。

一个Skill适合负责一种相对稳定的工作。

这与软件工程中的模块化思路相近：把重复出现、边界明确、容易测试的步骤保存起来，在其他流程中再次调用。

机制示意｜从一次执行到复用的工作流程

---

六、Routines：让Bot按照计划持续工作

保存Skill以后，Bot已经知道任务该怎样完成。

接下来，还需要告诉它什么时候执行。

这就是Routines的用途。

Routine可以理解为由某个Bot负责的自动化任务安排。它规定执行条件、任务内容以及结果交付方式。

官方目前支持按计划运行，并在受支持的连接环境中通过事件触发。

例如，每天固定时间生成简报；当指定Slack频道出现符合条件的消息时，启动一项处理流程。

1. 创建第一条定时Routine

我们继续使用前面的AI新闻研究Skill。

假设希望每天早上7点收到一份简报。

可以向负责研究的Bot发送：

请为AI News Research创建一个Routine。

执行时间：
每天早上7:00。
时区：Asia/Shanghai。

任务：
使用AI News Research Skill，
研究过去24小时内以下公司的官方动态：
OpenAI、Anthropic、Google DeepMind、xAI。

输出：
生成一份Markdown简报，
保存到指定项目文件夹，
并在本对话返回摘要和文件链接。

要求：
每条新闻保留原始链接和发布日期。
不重复昨天已经收录的事件。
没有符合条件的更新时说明“无新增”。
无法访问来源时报告失败，不使用旧信息冒充新消息。
不得公开发布或发送外部邮件。

请先展示Routine配置和预计执行时间，
经我确认后再启用。

这里有几个影响实际执行的细节。

首先，时间需要对应正确的时区。官方文档说明，Routine使用设置中的Timezone，用户可以指定固定时区。

其次，刚创建的定时任务通常会等待下一个计划时间，不会自动立即执行。

例如上午8点05分创建一条每天8点运行的Routine，首次正常触发通常是第二天上午8点。

如果希望立即检查，需要使用Test。

教程示意｜配置面板

2. Test不是模拟运行

官方明确提醒，Routine的Test会执行真实工作。

如果流程涉及修改文件、连接应用或操作网页，测试过程中也可能实际发生这些动作。

所以，测试时应当使用安全数据，限制写入权限。

对于准备发布公众号文章的流程，测试阶段只应当生成草稿，不要让它直接操作发布系统。

3. 如何处理没有新数据的情况？

这是周期性任务很容易忽略的问题。

假设某天没有任何符合要求的新闻，Bot仍然试图生成三条重要更新。

如果任务只要求“每天给我三条新闻”，它可能为了满足数量而选用旧信息，或者扩大原来的时间范围。

解决方法是在Routine里定义空结果行为。

例如：

“如果过去24小时没有满足条件的事件，返回无新增，不改变时间范围，不补充历史信息。”

再进一步，还可以规定当某个网站无法访问时，保留已经完成的部分，并明确列出未检查的来源。

这样生成的报告才具有可追溯性。

4. 事件触发能做什么？

定时触发适合每天、每周重复的任务。

事件触发则用于响应某种变化。

例如，当项目管理系统新增任务，或者某个支持的消息渠道出现指定关键词时，启动一个Bot进行整理。

官方文档列出了Slack、GitHub及Webhook等不同触发途径，但具体支持范围取决于连接方式和账号配置。

这里不建议初学者直接设置“监听所有邮件”或“每有一条新消息就运行”。

触发条件太宽，会增加无效执行，消耗额度，也可能在短时间内产生大量重复任务。

先限定来源、关键词和处理对象，等流程稳定后再扩大范围。

5. 定时任务需要维护

Routine创建完成后，可以在Bot详情中查看、测试、暂停、恢复、修改或删除。

官方文档目前说明，每个Bot最多可拥有50条Routines，界面保留每条Routine最近20次运行记录。

这个限制不代表适合一次性创建50条。

开始时保留两三条高价值任务，更容易判断实际消耗和运行稳定性。

还要定期检查失败记录。外部网页和应用更新后，原本可靠的流程也可能需要重新测试。

教程示意｜运行历史、状态和日期

---

七、长期记忆：怎样把Bot变成自己的第二大脑？

前面已经建立了单次任务、Skills和Routines。

但如果希望Bot长期参与实际工作，还缺少重要的一环：上下文。

对于一个内容创作者来说，最重要的信息可能分散在许多地方。

过去写过的文章、已经否决的选题、常用资料来源、文章风格要求、读者反馈，以及不同项目的进展，都可能影响下一次任务。

如果每次开始新研究都要重新整理这些信息，工作系统仍然存在较大的人工维护成本。

Grok Bot提供长期记忆能力，可以保存角色偏好、工作背景和以往任务的部分摘要。

不过，记忆适合保存稳定背景，关键事实仍应返回原始资料核对。

1. 为什么要把知识保存成文件？

2026年10月，X用户Argona在《How to build a Second Brain that actually does the work》中提出一套基于Grok Bot的第二大脑工作方案。

作者的核心建议，是把长期知识保存在文件中，让Bot在执行任务之前读取需要的内容。

这套方法值得借鉴，因为它改善了两个常见问题。

第一，用户很难准确掌握AI究竟记住了哪些信息。

第二，模型保留的摘要可能无法覆盖原始材料中的全部细节。

如果把项目规范、历史决策和已验证资料保存为文件，用户就有机会直接检查、编辑和维护它们。

对于长期运行的任务，文件可以成为比口头描述更稳定的协作基础。

2. 建立一个简单的知识目录

Grok Bot的云端计算机提供共享工作区/workspace。

可以在其中建立一个单独的资料目录。

例如：

/workspace/ai-editorial/
├── inbox/
│   └── 待处理资料
├── sources/
│   └── 原始来源
├── research/
│   └── 已核实研究笔记
├── topics/
│   └── 选题档案
├── writing/
│   └── 文章草稿
├── rules/
│   └── 工作规范
├── output/
│   └── 最终交付
├── INDEX.md
└── CHANGELOG.md

这个目录只是教学方案，文件夹名称没有特殊技术要求。

其中，sources用于保存原始材料，尽量不修改。

research保存经过整理的事实和研究结果。

topics记录选题状态，例如候选、研究中、已完成或已放弃。

writing放文章草稿，output放经过确认的交付文件。

INDEX.md作为索引，帮助Bot快速找到相关材料。

CHANGELOG.md则记录重要的更新和决策。

机制示意｜长期知识与资料文件组织

3. 让Bot知道怎样维护文件

可以建立一份工作规范。

你是我的内容研究档案管理员。

工作目录：
/workspace/ai-editorial/

每次收到新资料时：

1. 判断资料属于哪个项目。
2. 保留原始文件或原始链接。
3. 记录标题、作者、发布日期和获取日期。
4. 提取事实与重要观点。
5. 标明已核实、待核实或存在冲突的信息。
6. 更新INDEX.md中的文件索引。
7. 在CHANGELOG.md记录本次改动。

未经确认不得覆盖原始资料。
不要自行删除历史研究记录。
不确定资料归属时先放入inbox。

执行新任务时先查看INDEX.md，
再读取与当前任务相关的文件，
不要无差别加载整个资料库。

最后一句尤其重要。

随着资料越来越多，如果每次都把整个文件夹交给模型处理，不仅消耗计算资源，还会引入大量无关信息。

索引的作用就是帮助Agent定位当前任务真正需要的上下文。

4. 把稳定事实与变化事实分开

Argona的方案中还有一个很实用的区分。

有些信息变化较慢，例如用户的写作偏好、常用文章结构、长期研究领域。

另一些信息经常变化，例如产品价格、发布日期、招聘情况、项目状态和公司管理层信息。

前者可以放入长期文件。

后者应在使用前重新读取权威来源。

例如，一份选题档案里可以记录“此前研究过Grok Bot的2026年8月发布情况”。

但不能仅凭这份档案判断2026年10月的订阅价格。

因为后续可能已经发生调整。

这也是为什么一个可靠的知识系统应该保留来源链接、资料日期和最后核查时间。

5. 让Bot学习自己的写作偏好

对于内容创作者，还可以建立writing-style.md。

最简单的办法，是提供几篇自己写过并经过编辑的文章，让Bot提取可以验证的语言习惯。

例如：

请阅读我提供的五篇原创文章。

分析以下内容：
1. 开头通常怎样进入主题。
2. 技术概念如何解释。
3. 常用的段落长度和句式。
4. 观点与事实如何组织。
5. 哪些表达应该避免。

生成writing-style.md。

每条风格判断必须指出具体文章依据。
区分稳定风格和偶然出现的写法。
不要模仿其他作者的固定口头禅。
不要添加我没有使用过的表达习惯。

以后写作前，先读取这份文件，
但仍以当前任务要求为准。

这里保存的文件相当于一份可编辑的文字规范。

它不会让AI自动具备作者的全部判断能力，但能够减少重复说明基础风格要求的成本。

6. 让纠错经验留在系统里

长期使用Agent时，另外一个常见问题是重复犯错。

例如，曾经明确要求不要将媒体推测写成企业公告，下一次任务又出现同样的问题。

可以建立rules/editorial-check.md，记录已经确认的编辑规则。

每次发现错误，要求Bot解释错误类型，并将具体修正方法补充到规则文件。

不过，规则积累也需要维护。

某条修正规则可能只适用于一篇文章，不能直接扩展到所有任务；不同规则之间也可能发生冲突。

可以区分全局规则、项目规则和一次性要求，并定期删除或合并重复条款。

第二大脑的价值来自可维护的上下文，而资料数量本身不构成质量保证。

如果信息缺乏来源、长期无人更新，知识库也可能放大错误。

---

八、多Agent协作：从一个助手扩展到一支工作团队

一个Bot已经可以完成不少任务。

什么时候需要建立第二个、第三个？

判断标准应当来自工作分工，而不是Bot数量。

假设你希望自动整理科技新闻并生成公众号初稿。

新闻研究需要检查来源和时间。选题分析需要判断新闻价值。文章写作需要组织语言和结构。

这些工作虽然相互关联，但评价标准不同。

如果全部交给一个Bot，它需要同时承担研究、判断、写作和质量检查。任务复杂以后，容易遗漏某个环节。

此时可以建立多个专业Bot。

1. 先建立明确的职责

以科技内容生产为例，可以设置四个角色。

News Scout：新闻研究员。 负责收集指定来源的新信息，核对发布日期，返回候选事件。

Research Editor：资料编辑。 负责检查来源，整理证据，识别事实冲突。

Topic Planner：选题分析员。 根据研究结果分析读者价值、信息增量和文章切入点。

Draft Writer：初稿编辑。 根据已经确认的资料完成文章初稿，不自行增加未经核实的事实。

这些角色的工作成果依次传递。

机制示意｜多Bot角色分工

2. 为什么共享工作区很重要？

Grok Bot允许多个Bot访问同一账号下的共享文件和工作环境。

例如，News Scout把候选新闻保存到research目录。

Research Editor读取这些文件，再把核查结果保存到同一项目下。

Draft Writer只需要读取经过核查的材料，就能够开始整理初稿。

用户不必手动把每份文件从一个对话复制到另一个对话。

另外，Bot之间可以通过消息和群组进行协作。官方文档支持在群聊中指定多个Bot，或者使用“@”把任务交给某个角色。

这提供了另一种协作方式：多个Bot在同一任务上下文中明确讨论交接问题。

3. 创建一个协调Bot

当Bot数量增加以后，可以再建立一个负责组织任务的角色。

例如，Coordinator。

它的职责是检查任务目标，决定由哪个专业Bot处理，并收集最终结果。

可以输入：

你是内容工作流协调员Coordinator。

你负责组织以下Bot：

News Scout：收集新闻与来源。
Research Editor：核查事实和整理证据。
Topic Planner：生成选题建议。
Draft Writer：撰写文章初稿。

当我提出内容生产任务时：

1. 判断所需的工作阶段。
2. 将任务交给合适的Bot。
3. 检查上一阶段是否提供必要材料。
4. 记录交付文件与任务状态。
5. 当出现事实冲突或资料不足时暂停后续步骤。
6. 汇总结果，交给我人工审核。

你不得自行发布文章。
不得绕过事实核查步骤。
不得将待核实材料标记为已核实。

发现缺少合适的Bot时，
先提出新的角色方案，等待确认。

这相当于建立了一层任务协调机制。

Mahax在其文章中将类似角色称为Lead Bot，用它协调不同的专业机器人。

不过，增加协调角色并不必然提高效率。

简单任务只有两三个步骤时，一个Bot可能就足够。多Bot会增加任务交接、信息传递和验证成本。

4. 怎样避免多个Bot互相传错信息？

最可靠的办法，是给每个阶段规定交付标准。

研究Bot提交的必须是包含来源与日期的记录。

核查Bot提交的必须有证据状态和待解决问题。

选题Bot必须引用已经核实的事实，不得额外制造新信息。

写作Bot只能使用已经提供的材料，发现证据缺口时应标记问题。

最后，协调Bot检查每份交付是否满足下一阶段的要求。

这样，一个Bot的错误更容易被定位。

如果第一阶段的来源已经不可靠，可以从研究阶段重新开始，而不必让所有Bot重新执行一遍。

---

九、完整实战：从AI新闻研究到公众号文章初稿

现在，把前面介绍的功能组合起来。

我们设计的工作目标是：每天收集AI领域的重要动态，整理出有证据的候选选题，并在人工确认以后生成公众号初稿。

这个案例包含资料收集、长期归档、自动执行和多Bot协作。

为了让读者能够检查效果，首次演练建议选取一组已经公开、时间清楚的历史材料。

例如，使用2026年8月11日Grok Bot发布公告、8月26日扩大套餐开放范围的公告，以及10月订阅调整的官方说明。

这些资料来自同一产品的不同时间节点，既能检验新闻收集能力，也能检验Bot是否会把旧价格误当作当前价格。

第一步：建立研究项目

在共享工作区创建项目文件夹。

/workspace/ai-editorial/projects/grok-bot/
├── source-list.md
├── raw/
├── verified/
├── topic.md
├── draft.md
└── review.md

其中，source-list.md记录允许使用的信息来源。

可以先写入：

项目：Grok Bot研究

官方来源：
https://x.ai/news
https://docs.x.ai/grok-bot/overview
https://cursor.com/docs/grok-bot

研究主题：
产品发布、功能更新、使用方式、
订阅政策和自动化工作机制。

研究规则：
优先使用官方公告和正式文档。
保留原始链接及发布日期。
第三方评论必须标明来源。
遇到矛盾信息时保留不同版本。

初次使用只需要这些基本内容。

第二步：让News Scout收集材料

向新闻研究Bot发送：

研究主题：Grok Bot产品发展。

时间范围：
2026年8月1日至2026年10月26日。

来源：
首先检查source-list.md中的官方站点。

任务：
找出与产品发布、可用套餐、
新增功能和工作方式有关的重要更新。

每条信息保存：
标题、发布日期、原始链接、
主要变化、所属类别。

要求：
不要用转载时间替代事件日期。
重复报道合并。
无法核实的内容标记为待核实。

将结果保存到raw目录。
不要写文章。

这里的输出应该是一份资料清单。

以官方公开信息为准，研究中至少需要区分8月11日的初始发布与8月26日的访问范围扩展。后续订阅政策则需要使用10月的正式资料重新判断。

这个案例的重要性在于，能够检验Bot是否理解时间顺序。

如果它把8月的准入要求直接用于10月的教程，就属于需要纠正的事实错误。

第三步：由Research Editor核对事实

完成收集后，让资料编辑Bot读取raw目录。

请检查项目raw目录里的候选资料。

逐条核对：
1. 来源是否为真实可访问的网页。
2. 文章发布日期与事件日期是否一致。
3. 是否属于公司正式公告。
4. 不同时间的信息是否被混用。
5. 是否存在相互矛盾的产品说明。
6. 是否有未经证实的效率或性能判断。

对每条关键事实添加状态：
已核实、来源观点、编辑推断、待核实。

将核查后的研究材料保存到verified目录。
在文件末尾列出仍需人工确认的问题。

不要删除原始资料。

该阶段结束后，应得到一份有来源、可检查的事实清单。

需要人工抽样打开关键链接，确认Bot确实读取了原文。

如果它只是根据网页摘要生成判断，则不能直接把结果视为完成核查。

第四步：生成候选选题

接下来由Topic Planner读取经过确认的材料。

请基于verified目录的资料，
提出三个面向中文普通AI用户的文章选题。

每个选题包含：

1. 标题方向。
2. 一句话核心观点。
3. 目标读者。
4. 读者为什么需要了解。
5. 已有事实能够支持哪些内容。
6. 仍然缺少哪些资料。
7. 建议采用的文章结构。

要求：
选题必须由材料支持。
不要使用没有证据的排名和效率数字。
不要把产品宣传当成实际测试。
不得为了吸引点击制造虚假对立。

这一阶段可以帮助编辑减少初步整理时间。

但选题价值仍然需要人工判断。

例如，同样是Grok Bot的更新，面向技术开发者可以研究多Agent架构；面向普通用户，则可能更适合解释云电脑和自动化工作流。

选题的最终取舍取决于账号定位、受众需求与信息增量。

第五步：让Draft Writer生成文章

确认选题以后，再向写作Bot提交任务。

它需要读取已核实的材料和写作规范。

请根据以下资料生成一篇中文科技文章初稿：

项目目录：
/workspace/ai-editorial/projects/grok-bot/

必须读取：
verified目录中的事实材料；
已经确认的topic.md；
rules中的写作规范。

要求：
1. 围绕确认后的核心观点展开。
2. 先说明具体变化，再解释相关机制。
3. 技术名词首次出现时进行通俗解释。
4. 重要事实保留原始来源链接。
5. 区分产品功能、厂商说法和编辑判断。
6. 不虚构实验、用户反馈或采访内容。
7. 不添加未经核实的性能和价格数字。
8. 按目标读者的理解程度安排信息。

输出：
一篇完整的Markdown初稿。

完成后另附：
事实核查清单；
引用来源；
仍需补充的信息；
最需要人工修改的三个部分。

只保存为草稿。
不要发布。

此时Bot负责完成资料到文字的转换。

真正的编辑审核仍然需要关注文章立论是否充分、技术解释是否准确、结构是否重复，以及标题是否与证据相符。

第六步：把流程保存为Skills

整个流程确认可用以后，可以分别保存新闻研究、事实核查、选题分析和文章初稿Skills。

建议先保存最稳定的工作方法。

例如，每篇文章都需要核查日期、来源和引用。这个过程适合形成通用Skill。

而标题创意、观点选择和叙事结构具有较强的主观性，可以先保留人工参与。

第七步：创建每日Routine

最后，让Coordinator每天早晨安排研究任务。

创建一个每日内容研究Routine。

时间：
工作日早上7:30。
时区：Asia/Shanghai。

工作流程：
1. 调用News Scout收集过去24小时的AI更新。
2. 调用Research Editor检查来源和日期。
3. 生成最多五条候选事件。
4. 每条事件保留原始链接、摘要与待核实项。
5. 保存到当天的研究目录。
6. 在本对话提交简报。

暂时不要自动进入写作阶段。
等待我确认选题后，
再调用Topic Planner和Draft Writer。

任何外部发送、发布和删除操作均需人工批准。

​

机制示意｜从新闻研究到人工审核的完整工作流

这套流程完成后，内容生产中的重复性环节便有机会被集中处理。

但投入正式使用前，仍应逐一测试每个Bot的输出，再测试整体交接过程。尤其要检查来源缺失、重复运行、额度耗尽和任务中途失败等情况。

---

十、安全、成本与局限：让Agent长期运行前必须知道的事

当Bot只能总结文档时，一次错误通常意味着需要修改答案。

但当它能够发送邮件、编辑文件、运行命令甚至操作外部账户时，错误的影响范围会扩大。

因此，长期自动化系统需要清楚的安全边界。

1. 先理解Auto-review

Grok Bot提供Auto-review机制，用于检查Bot准备执行的操作。

根据官方审批文档，系统会根据操作类型、用户指令和相关规则，决定直接允许还是要求人工确认。

用户可以创建Custom Rules，明确某些动作需要Ask first，或者在符合条件时允许自动执行。

对于刚开始使用的用户，建议保留默认的自动审查机制，并优先使用Allow once。

因为Always allow可能保存后续持续生效的权限规则。

一些高风险操作应长期保留人工审批，例如向外部人员发送信息、公开发布内容、购买商品、转账、永久删除资料或更改生产系统。

同时需要明确：安全审查机制能够降低风险，但不意味着每项操作都获得人工批准，也不能保证不存在错误。

2. 共享电脑不提供Bot之间的安全隔离

前面介绍过，多个Bot可以共享云电脑。

这意味着共享目录中的文件、浏览器登录状态以及部分凭证环境可能被其他Bot使用。

如果一个Bot负责个人邮件，另一个Bot负责客户数据，两者不应仅凭名称和角色分工来实现敏感信息隔离。

需要从数据授权和账号层面管理访问范围。

对于公司资料，还应结合组织的安全政策判断是否允许接入第三方Agent。

3. 谨慎处理密码和敏感信息

官方提供Secure Form、凭证管理以及人工接管等方式处理登录信息。

用户不应把密码、API Key和一次性验证码直接粘贴到普通聊天消息里。

使用共享计算机登录某个账户之前，也需要考虑其他Bot能否继续利用该登录状态。

此外，涉及个人信息、客户数据和内部文档时，除了检查模型是否用于训练，还要核实实际存储位置、保留政策、连接器权限和删除机制。

不能因为某个产品提供隐私模式，就默认所有相关服务采用完全相同的数据处理政策。

4. 成本不能只看月费

Grok Bot的使用成本包含订阅费用和任务消耗。

在新的The X Subscription体系下，Grok Bot使用与Grok、Cursor相关模型的用量池存在共享关系。

这意味着其他产品的使用也可能影响剩余额度。

此外，复杂任务的多次重试、频繁运行的Routines、长时间网页操作和多Bot协作，都可能增加资源消耗。

一个每周运行一次的研究任务，与每小时触发数十次的自动化流程，成本结构显然不同。

因此，建议先进行小规模测试，观察执行频率、成功情况和额度消耗，再决定是否提高自动化程度。

5. 常见失败情况怎样处理？

可以建立一张简单的维护表。

失败情况	可能原因	建议处理
应用已添加但不能读取数据	尚未完成认证、权限不足	检查连接状态
网页任务中途停止	登录过期、验证码、界面变化	人工处理阻碍并重新测试
Routine没有运行	时区、暂停状态或触发规则问题	检查配置与运行历史
输出重复新闻	缺乏历史记录或去重规则	保存历史索引并增加判断条件
生成错误事实	来源失效、资料过期或错误推断	返回原始资料核查
多Bot结果不一致	交接文件或规则不同	建立统一交付格式
任务执行过于频繁	触发条件太宽	缩小来源和触发范围

还需要为每条Routine规定失败以后怎么做。

是否允许自动重试？重试几次？已经写入一半的文件怎样处理？如果数据源失效，是否应停止后续任务？

对于可能重复写入的操作，最好采用幂等设计，也就是同一任务重复执行时，不应造成重复记录或重复操作。

例如，根据原始文章链接判断新闻是否已收录，比单纯按标题去重更可靠。

6. 哪些人适合使用Grok Bot？

了解完基本功能和运行成本，再决定是否使用会更合理。

Grok Bot更适合那些工作内容相对稳定、经常需要跨应用处理资料，又希望减少重复操作的用户。

第一类是内容创作者和知识工作者。

如果每天都要查找资料、整理信息、追踪行业动态，Grok Bot可以承担部分前期研究和归档工作。尤其是长期维护某个研究领域时，持续积累的文件、索引和Skills能够减少重复整理的工作量。

但涉及文章观点、事实判断和最终发布，依然需要人工审核。

第二类是自由职业者和中小团队。

这些用户通常同时承担客户沟通、项目管理、资料整理和内容交付等工作。

例如，设计师可以让Bot整理客户反馈，项目负责人可以让它准备会议材料，独立开发者可以安排它跟踪Issue和更新项目文档。

这些任务的共同特点是流程相对明确，而且交付结果能够检查。

第三类是希望深入实践AI Agent的用户。

对于已经了解大语言模型、Prompt和工具调用的人来说，Grok Bot提供了一套相对完整的Agent运行环境。

用户可以从单个Bot开始，逐步学习云电脑、应用连接、Skills、Routines和多Agent协作。

不需要一开始就部署服务器或者手动搭建整套工作流基础设施。

不过，想研究底层调度策略、精确控制模型选择或定制复杂安全架构的开发者，仍需评估产品提供的配置接口是否满足需求。

反过来，如果你主要使用AI进行简单问答、偶尔修改文案，或者每项工作都没有固定流程，现有聊天工具可能已经足够。

Grok Bot的价值需要通过具体工作衡量。

一条每周运行五次、能够稳定处理重复资料的流程，通常比一套从未实际使用的十Bot架构更有意义。

7. 用一周时间完成第一轮验证

对于第一次使用的用户，建议把最初一周作为验证期。

不急着建立复杂系统，也不要求每天增加新的Bot。

第一天，完成安装和第一个任务。

选择一个自己熟悉的工作，例如整理PDF、总结公开网页或者归纳项目资料。

确认Bot能够正确读取输入，并生成可以检查的结果。

第二天，连接一项真实应用。

例如Gmail或者Google Drive。

先给予必要的最低权限，只进行搜索、读取和整理，熟悉应用授权与工具调用过程。

第三天，完成一项多步骤工作。

让Bot从指定来源读取信息，整理成结构化文档，保存到云端工作区。

要求它记录执行过程，以及实际访问过的文件或链接。

第四天，保存第一个Skill。

选择已经成功完成的任务，修正过程中出现的问题，再将稳定步骤保存为Skill。

随后使用另一份输入材料测试。

第五天，创建第一条Routine。

让Bot每天执行一项低风险任务，例如生成个人资料简报。

先通过Test检查实际行为，再启用正式时间表。

第六天，增加长期上下文。

建立一个简单的项目目录，保存常用规则、研究来源和已确认信息。

检查下一次任务能否正确引用这些资料。

第七天，复盘。

打开Routine运行记录，观察任务是否按计划完成。

将实际输出与人工完成的结果对照，记录执行时间、资料错误、重复内容和人工修正成本。

最终需要回答几个问题：

这项工作是否真的节省了人工操作？结果能否直接使用？任务失败后是否容易恢复？保持运行需要多少额度和维护时间？

如果前六天的任务还没有达到稳定水平，就继续优化单个Bot，没有必要急着增加多个Agent。

8. 设置明确的停止条件

长期运行的自动化系统，需要知道什么时候应该停下来。

例如，新闻研究Bot连续三次无法访问官方网页，就应暂停该来源的检查，记录失败原因，而不是不停重试。

如果研究资料中出现互相冲突的发布日期，应先报告问题，不继续将这些资料交给写作Bot。

对于资金、账号权限、外部通信等敏感操作，应通过审批机制明确阻止未经授权的执行。

成本方面还需要注意一个细节。

根据2026年10月26日核对的官方计费说明，Grok Bot试用额度按照Agent执行步骤和Token消耗，并附带最长7天的试用窗口，不能简单理解成七天内所有任务都能无限运行。

在支持额外按量付费的旧版套餐中，月度消费限额也未必会立即中断正在执行的任务。官方说明，已经运行中的任务可能超过设定限额后才结束。

对于新版The X Subscription，额外用量通过预付余额和充值设置管理。

因此，启用长时间运行的Routines之前，应检查账户实际使用的是哪套计费规则，并确认自动充值与额外消费设置。

对于新手，可以先遵守一条简单原则：

没有明确完成条件、没有失败处理规则、没有预算边界的任务，暂时不要设置为无人值守运行。

---

写在最后：先让一个Bot完成工作

回顾整套流程，Grok Bot提供了几个相互关联的能力。

云电脑让任务能够持续运行；应用连接让Bot访问实际工作资料；Skills保存可复用的执行方法；Routines规定何时启动任务；长期上下文帮助Bot利用过去积累的信息；多个Bot则可以在明确分工下协作。

把这些功能组合起来，用户便有机会建立一套持续处理重复任务的AI工作系统。

但系统是否有用，最终仍取决于实际工作结果。

对于刚刚接触Grok Bot的人来说，不妨从明天早上需要完成的一项任务开始。

可能是整理收件箱，可能是检查五个网站的更新，也可能是把一份会议记录转成待办清单。

把任务交给Bot，观察它怎样执行，检查结果，修正错误。

当同一项工作能够稳定完成，再保存成Skill；当Skill经过多次验证，再让Routine按照计划运行。

如果后续确实需要不同专业角色协作，再增加新的Bot。

这样建立起来的工作系统，每增加一个部分，都有实际任务作为依据，也更容易判断它是否值得继续维护。

对于Grok Bot而言，能否打开十几个Bot的聊天窗口并不重要。更有价值的是，用户交出去的具体工作，能否在可接受的成本和风险范围内得到可靠完成。

这也是从入门走向熟练使用Agent最值得掌握的方法。

---

附录：三个可直接复用的Prompt

Prompt A：建立个人工作档案

你是我的个人工作档案管理员。

请通过逐个提问的方式了解：
1. 我的主要工作与职责。
2. 未来三个月的工作目标。
3. 常用的软件和资料来源。
4. 每周重复进行的工作。
5. 我的沟通和写作偏好。
6. 哪些操作必须得到我的批准。

完成后生成：
me.md：工作背景与长期目标。
workflow.md：重复工作及操作方法。
rules.md：工作规则和权限边界。

所有内容以我明确提供的信息为依据。
没有回答的问题标记为未知。
不得自行推断敏感个人信息。

请先展示文件草稿，经我确认后保存。

Prompt B：将已验证的流程保存为Skill

请复盘我们刚才完成的任务。

确认：
任务输入是什么；
哪些操作成功；
哪些步骤发生了错误；
如何修正错误；
最终结果如何验证。

根据确认后的流程生成一个Skill。

Skill应包含：
适用场景、输入要求、执行步骤、
完成标准、异常处理和安全限制。

只保存能够复现的步骤。
不要把尚未验证的做法写成成功经验。

保存后向我展示Skill内容，
并提出一项用于验证的新测试。

Prompt C：检查已有自动化系统

请检查当前Bot的Skills、Routines和相关工作文件。

生成一份维护报告：

1. 当前有哪些有效Routines。
2. 每条Routine的执行时间和状态。
3. 最近可用记录中的失败情况。
4. 哪些Skills存在重复或规则冲突。
5. 哪些文件可能已经过期。
6. 哪些任务具有外部写入权限。
7. 哪些任务需要进一步人工确认。

请区分：
已经核实的问题；
根据现有记录推断的风险；
无法判断的事项。

只生成报告和修改建议。
不要直接删除文件、停用任务、
更改权限或修改自动化配置。

---

参考资料

官方资料

1. xAI. Introducing Grok Bot. 2026年8月11日。
2. xAI. Grok Bot Overview. 官方产品概览。
3. Cursor. Get Started with Grok Bot. 官方入门指南。
4. xAI. Skills, Routines and Automations. 官方自动化指南。
5. Cursor. Plans and Billing. 订阅、额度与计费规则。
6. xAI. Grok Bot FAQ. 常见问题与产品限制。
7. Cursor. Approvals. 权限审批与安全机制。

参考文章

8. Argona. How to build a Second Brain that actually does the work (Grok Bot full course). 2026年10月14日。
9. Mahax. Grok Bot. What It Is, and How to Actually Use It. 2026年8月24日。
10. Anatoli Kopadze. Grok Bot explained. Running agents has never been this easy. 2026年8月20日。

阅读原文：原文链接