Grok Bot 已知限制全表：动手之前先知道会撞上什么

大多数介绍 Grok Bot 的文章讲的是它能干什么。这篇讲反面：它干不了什么，以及你会在第几天撞上。

先看清天花板有两个好处：一是不会把时间花在注定跑不通的方案上，二是遇到问题时知道这是产品限制还是自己配错了——这两种情况的处理方式完全不同。

全部条目都标了核实日期。 这个产品迭代很快，光是价格，发布后两周内就降了两次、入门门槛掉了十倍。看到日期就知道该不该重新核一遍。

还没上手的人建议先读Grok Bot 七步入门教程。

五条你在第一周就会撞上的

先给最高频的五个现象，直接按症状查：

这五条里有四条不是故障，是设计。下面逐条说清楚。

一、产品本身的限制

这一类你改不了，只能适应或者换方案。全部核实于 2026 年 9 月上旬。

1. 没有官方的编程控制入口

现状：没有查询管理用的接口、没有官方命令行工具。九月上线的网络回调能从外部叫醒 Bot，但只能触发预先存好的流程，传不进参数、也没有返回值。

影响：你的程序没法列出全队状态、批量改 Bot、读完整执行记录、派一件没设计过的活。

会变吗：可能会。 官方在往开放的方向走，企业版已经有了团队配置和网络策略，但没有公开时间表。

这一条的详细分析在Grok Bot 命令行控制。

2. 模型不可选

现状：模型选择由官方管理，没有面向用户的选择器，服务组合会变。

影响：同一个任务在不同时间可能由不同模型执行，质量会波动。

缓解：把任务写得更具体，减少它自由发挥的空间。

会变吗：企业版有团队模型白名单，但官方自己说执行不保证——开通时会让你确认「Bot 可能不遵守这个白名单」。个人版没有这个选项。

这一条是很多技术团队的否决点。 如果你的流程对模型有硬要求，这个产品不适合。

3. 所有 Bot 共享一台电脑

现状：电脑按用户账号隔离，不按 Bot 隔离。

影响：不能用不同的 Bot 做安全隔离；凭据、文件、浏览器会话全共享。

会变吗：这是产品的核心设计——它让 Bot 之间的交接成为可能，不太可能变。

怎么在这个前提下管权限，见Grok Bot 安全指南。

4. 删除 Bot 不清理共享电脑

现状：删除只移除配置、对话和例行任务，文件和登录会话留下。

影响：以为删干净了，其实没有。

缓解：手动清理——退出登录、删文件、撤销第三方授权、轮换凭据。

5. 一个 Bot 同时只能跑一个操作电脑的任务

现状：每个 Bot 有自己的屏幕，但一个屏幕一次一个任务。

影响：并行必须靠多个 Bot，不能靠一个 Bot 开多线程。

会变吗：受限于「一个屏幕」这个设计，不太可能变。

6. 数量上限

现状：

影响：群聊 6 个这条会限制多 Bot 编排的设计。

会变吗：官方说这些是「实际的限制」，调整的可能性有。

7. 数据在美国，不支持私有部署

现状：云端电脑运行在美国；不支持本地部署、不支持自带镜像。

影响：有数据驻留要求的场景直接排除。

缓解：无。这是硬约束。 官方说「如果你的审查需要书面的驻留承诺，联系账户团队」——意味着可能有企业级方案。

8. 不支持旧版隐私模式

现状：Grok Bot 要求云端数据存储。

影响：开着旧版隐私模式的账号登录会报错。

缓解：改账号的数据设置。

会变吗：不太可能——云端存储是产品前提。

9. 例行任务的事件触发源有限

现状：触发源列表没有邮件，只有 Slack 消息、代码仓库事件、Teams 消息这类。

影响：「收到某封邮件就启动 Bot」做不到。

缓解：自己写一个定时器去轮询邮箱。

会变吗：可能会加。

10. 附件限制

现状：单文件不超过 25 MB，视频不超过 200 MB，桌面端一次最多 6 个附件；加密或有密码保护的文件读不了。

缓解：大文件走别的传输路径，不走对话附件。

二、长期运维会持续遇到的

这一类不是一次性问题，是你每个月都会遇到几次的。

1. 云端电脑重建，什么都没了

频率：镜像更新（不定期）、你主动重置、休眠唤醒。

影响：装过的东西消失、地址变了、凭据换了。

最麻烦的是失效方式：不是报错，是超时。第一次遇到的人通常以为是网络问题，查半天才发现机器换了。

这条不处理，任何自动化撑不过一周。

2. 凭据会变

频率：跟上一条同步——电脑重启或重建后就换新的。

影响：所有依赖它的调用认证失败。

缓解：做自动刷新。配好之后你基本感觉不到这一条；不配的话每周手动救一次。

3. 授权密钥有有效期

现状：私有网络服务的授权密钥最长 90 天。

影响：过期后自动恢复失效，而且你多半不会马上想到是这个原因。

缓解：日历提醒，或者放进月度检查清单。

4. 设备密钥默认半年过期

现状：默认 180 天，到期设备掉线。

影响：半年后突然连不上，原因极其隐蔽。

缓解：给自己常用的那台机器关掉密钥过期。云端那台不用管——它活不到 180 天。

5. 主机身份每次重建都变

影响：远程连接会因为身份变更被拒绝。

缓解：重建后清一次已知主机记录。

6. 用量是共享的、会耗尽

现状：订阅包含每周用量，耗尽后要按需付费或者等下周。

影响：并行和定时任务会加速消耗。一条每十五分钟跑一次的例行任务，一天就是 96 次。

缓解：给自动化设总量闸门；任务写具体点，减少它试探的次数。

还有一条要知道：截至 2026 年 9 月，没有针对 Grok Bot 的单独花费上限，只能靠账号级的按量付费开关控制。

7. 自动审查可能拦下操作

现状：强制对所有用户启用，审查命令行操作、插件调用、操作电脑、自动化写入、委派这五类。

影响：无人值守的任务可能停在审批上，你的脚本会一直等到超时。

缓解：配窄范围的允许规则。

注意：规则存在当前这台桌面设备上，换电脑要重配。

三、一张总表

按严重度排：

看这张表的正确方式：前五条决定你要不要用这个产品，后面九条决定你用起来舒不舒服。

四、什么情况下该换方案

三种情况直接排除，不用试：

还有一种情况要想清楚：如果你的核心需求是让程序从外部管理和编排 Bot，官方至今没有这个接口。自建方案存在，但它依赖未公开的内部接口——不适合放进会造成实际损失的关键路径。

五、看限制的一条心态

产品迭代很快，这张表里的条目会变。

分清哪些会变、哪些不会变，比记住每一条更有用：

围着「会变」的限制做太多工程，不如等它变。 围着「不会变」的限制做适配，那个投入是划得来的。

完整排障手册在哪

这篇给的是限制清单和判断依据。每一条对应的具体排查步骤、恢复脚本和自动化方案，在翔宇工作流 AI 编程实操课的会员专区，47 章、14 万字，其中一整章是按现象查表的排障手册。

相关阅读：Grok Bot 命令行控制、Grok Bot 安全指南、Grok Bot 能干什么（九类场景与开源资源）、七步入门教程。

常见问题

一个账号能建多少个 Grok Bot？

约 50 个，Bot 和群聊合计。单个群聊最多 6 个成员，这一条会限制多 Bot 编排的设计。每个 Bot 最多 50 条例行任务，每条只保留最近 20 次运行记录。录屏教学单次最长 10 分钟。官方称这些是实际的限制，调整的可能性有。

一个 Bot 能同时干两件事吗？

不能。每个 Bot 有自己的屏幕，但一个屏幕一次只跑一个操作电脑的任务。想并行只能靠多个 Bot 同时干，不能靠一个 Bot 开多线程。这受限于「一个屏幕」这个设计，不太可能变。

为什么我删了 Bot，它登录过的账号还在？

删除只移除配置、对话和例行任务，共享电脑上的文件和登录会话会留下。所以删掉一个 Bot 不等于收回了它的权限。要完整下线，得单独退出登录、删文件、撤销第三方授权、轮换凭据。

Grok Bot 的数据存在哪，能私有部署吗？

云端电脑运行在美国，不支持本地部署，不支持自带镜像。有数据驻留要求的场景直接排除，这一条没有缓解办法。官方的说法是如果审查需要书面的驻留承诺，联系账户团队——意味着可能有企业级方案。

能指定 Grok Bot 用哪个模型吗？

不能。模型选择由官方管理，没有面向用户的选择器，服务组合还会变。影响是同一个任务在不同时间可能由不同模型执行，质量会波动。缓解办法只有把任务写得更具体。企业版有团队模型白名单，但官方自己说执行不保证，开通时会让你确认 Bot 可能不遵守这个白名单。这一条是很多技术团队的否决点。

能不能让 Bot 收到某封邮件就自动启动？

做不到。例行任务的事件触发源列表里没有邮件，只有 Slack 消息、代码仓库事件、Teams 消息这类。想实现只能自己写一个定时器去轮询邮箱。这一条官方可能会加。

为什么我的 Bot 突然全部连不上了？

最常见的原因是云端电脑被重建了——镜像更新、你主动重置、休眠唤醒都会触发。重建之后地址变了、凭据换了、装过的东西全没了。失效方式很隐蔽：不是报错，是超时，第一次遇到的人通常以为是网络问题。

附件有大小限制吗？

有。单文件不超过 25 MB，视频不超过 200 MB，桌面端一次最多 6 个附件。加密或有密码保护的文件读不了。大文件要走别的传输路径，不走对话附件。

哪些限制是永远改不了的？

三条基本不会变：所有 Bot 共享一台电脑（这是产品核心设计，它让 Bot 之间的交接成为可能）、一个 Bot 一次只跑一个操作电脑的任务（受一个屏幕的设计限制）、不支持旧版隐私模式（云端存储是产品前提）。数据在美国这一条对个人用户也没有缓解办法。

什么情况下应该换别的方案？

三种情况直接排除：有数据驻留或私有部署要求、流程对模型有硬性要求、需要合规审计明确接口来源。另外如果你的核心需求是让程序从外部管理和编排 Bot，官方至今没有这个接口，自建方案依赖未公开的内部接口，不适合放进会造成实际损失的关键路径。