Grok Bot 在 X 上的讨论：元分析（2026-10-17）

真源：content/harness/2026-10-17-grok-bot-x-meta-analysis.md · 调研日 2026-10-17 · 正文由该 md 转换，改正文先改 md

• 范围：2026-09-17 至 2026-10-17 18:00（上海时间）的 X 帖子与长文，另加少量链接文章。30–90 天前的少量资料单独标出。
• 只读研究：没有发帖、没有发消息、没有改任何 skill 或仓库。
• 时间格式：上海时间 UTC+8（括号里是 UTC 原时间）。热度来自 X API：L=点赞 R=转发 Re=回复 V=浏览。拿不到的写“不知道”。
• 文中引用都是原文摘录，后面附链接。文章转述别人视频或文档的地方会注明“转述”。

1. 样本表（54 条有实质内容的来源；53 条在 30 天内）

类型：官方＝SpaceXAI / Grok Bot 团队；重度用户＝讲自己真实用法；构建者＝做模板、指南或工具；批评＝以问题或风险为主。

30–90 天前的补充来源（只用来补背景，不计入上面 54 条）：HN 讨论约在 2026-08（https://hn-tldr.com/posts/49261514 ，"301 comments"）；Cursor 论坛发布帖 2026-08-11 19:34 UTC（https://forum.cursor.com/t/introducing-grok-bot/168053 ）。

用作佐证、未进表的帖子（只引一句）：@0xMovez 指南条目、@TannerIngalls 2106484865986416808、@thebasedcapital 2108126674751738307、@MrTacticalX 2100637574268158114、@_jsolly 2111400450905796756、@WR4NYGov 2103303713989509137、@ASaltyVet 2111094396188057657、@stnciuu 2111189548877123991、@tvykruta 2103290957982572881、@bruno_hiis 2108246407555760276、@AVB_21 2111407099695575473、@kosehakann 2111404352846156168、@JoshMeyer 2111416357132599740、@scottwatts 2110761379539878294、@diamai_ 2111380097533964737、@SublimeCoderX 2111395107949998393。链接格式统一是 https://x.com/i/status/<id>。

计数说明：#1–#52 加 W1、W2，共 54 条。只有 W2 首发于 08-23（10-13 有更新），在 30 天外，其余 53 条都在 30 天内（最早的是 #4，上海时间 09-17 05:26）。

2. 主题分析

T1 多 bot 分工

• 共识做法：

1. 先让一个 bot 负责完整结果，同一类交接反复出现后再拆出专员。原文："one bot owns the outcome… add another Grok Bot only when one stable stage keeps escaping Chief"（#18）。atlas 引官方指南："Add Project Manager after the handoffs hurt, not before"（W1）。
2. 一个 bot 只做一件事，由一个总控当唯一入口：#19 的 #16–#18 条、#20 第 1 和第 7 步、#21、#24、#25、#22（转述 Lingxi：chief of staff 把活分给 UI / DevX / infra 三个工程 bot）。
3. 拆得细、可组合："create bots thinly… a bot per function"（#16 博客），以及 "one bot per purpose and you function chain them"（#17）。
4. 交接要带固定字段。#24 要五项："the task / the owner / the decision / the evidence / the unresolved blocker"；#25 要回答三个问题："What was done? Where's the evidence? Who owns the next step?"

• 独立来源数：10（#16、#18、#19、#20、#21、#22、#23、#24、#25、W1）。
• 分歧：
• #44 把整套多 agent 迁过去后失败："getting confused on which tools to use, who handles what"，最后改成 "only one agent that employees work with"。
• @TannerIngalls 质疑产品 "forces you to have a 'leader' bot"。
• 规模上说法差很多：转述里有 "15+ bots… a Chief of Staff, two managers, and 13 workers"（@snovvyxbt 转述，原视频没核实），而 #18 认为扩编要放在最后。
• 证据强度：中。多数是指南和转述，少有前后对比的数据。

T2 记忆与技能

• 共识做法：

1. 先把事做成，再存成 skill，最后才排 routine：#18 "skills come before routines"，#27 列出 6 步并提到 "Routines have a Test button"，#28 "get two clean runs… only then attach a routine"，#21 "only after the skill survives a second, different input"，W1。
2. skill 写清楚这几项：什么时候用、输入、步骤、怎么验证、交回什么、哪里要审批（#19 第 6 条，#27）。
3. 会变的事实留在源系统里，长期偏好才进 bot 记忆（#20 第 6 步）。关键决策要重查实时来源，不靠记忆（#19 第 20 条）。
4. 代码库本身就是记忆，反复出现的错误要变成约束：#8 "your codebase is a form of memory to agents… needs to turn into a constraint"。

• 独立来源数：8（#8、#16、#18、#19、#20、#21、#27、#28）。
• 分歧：
• poteto 认为 prose 越少越好："forget rules and skills. you can add those later"（#8），"prose… use it minimally"（#6）。社区主流则是 skill 越多越好。
• #34 指出 Hermes 有后台 curator 自动删掉没人用的 skill，Grok Bot 要手动维护。#26 抱怨 "Cold skills… Duplicate rules pasted into every profile"。
• 证据强度：中。

T3 Routine 与成本、额度

• 共识做法：

1. 触发条件收窄。"every new Slack message" = noise + burned usage（#19 第 11 条）。
2. 没有变化就别出声，不发 "(no change.)" 这类废话（#26 "missing quiet-on-noop"）。
3. 少让 bot 去叫醒 bot。Cursor 员工在论坛的回复（经 W1 转引）："Every turn re-reads that bot's whole conversation"，又说那个账号里 "about a third of all turns were Bots waking other Bots"。建议在 profile 里写："Only message another bot when it needs to act. No acknowledgments, thanks, or progress pings. Send one summary when the work is done."
4. 每个任务开一个新 chat，任务状态放到共享看板（同一条员工回复；W1 也注明 "official docs don't say a new chat reduces usage"）。
5. 只有真正紧急时才用 5 分钟轮询（W1 转引工程指南："can burn tokens much faster than you think"）。
6. 交给 Cursor cloud agent 时要先指定模型。#31 的情况是默认用了 "Claude 4.5 Sonnet with thinking… In one hour, half my Cursor Pro monthly usage gone"。

• 额度抱怨（独立来源）：#39、#40、#41、#42、#43、#44、#31、@AVB_21、@kosehakann、@JoshMeyer、@ASaltyVet、W2，共 12 个。具体数字：#40 "$13 to check client details and draft ONE text message"；#41 "about 2 days out of my Bot team"；#39 用 Heavy "$300/mo… still hit the weekly usage wall before Friday"。官方两次重置额度（#5，另有 09-06 一次：https://x.com/bot/status/2096303514230423629 ）。
• 产品缺什么：按 bot 或任务拆分的用量明细（#42 "only shows a bar — no breakdown by time, agent"，@kosehakann "quota breakdown used by each bot"），还有额度重置后的任务排队（@JoshMeyer）。W1 引官方："A separate Grok Bot spend cap is not available today"。
• 分歧：#33 说把编码转给 Grok Build 能用 "a separate pool of rate limits"。这只是个人说法，10-12 统一订阅之后是否还成立，不知道。
• 证据强度：
• "额度是最大瓶颈"：高，12 个独立来源加上官方两次重置。
• 省额度的具体做法：中，主要依据是一条员工回复加几位用户的经验。

T4 用 cloud agent 写代码

• 共识做法：

1. bot 当大脑，Cursor cloud agent 写代码，开 PR 时附 live preview 或视频，合并前由人批准。依据：#1 "hand off coding tasks to Cursor… share video demos"、#14 "shepherd PRs to green"、#29 "opens a PR with a live preview link. Nothing gets merged until I approve it"、#30、#37、@stnciuu。
2. 让 agent 自己验证并交出证据：#7 "give your agent the ability to verify its own work… a video and/or screenshots for UI work"。#22（转述）里，bot 会在结果 "without screenshots or before/after perf numbers" 时追问。
3. 信任金字塔：代码改进 > 静态分析 > prose > 人审（#6）。#10 主张删注释，因为 "agents love copying what already exists"。
4. 能力上限参考：#11 同时开着 "16" 个 Cursor Project，最常用的指令是 "/bro catch me up… exec summary"。#23 转述工程指南："~15 cloud coding agents to 200+, with PR checks every 30 minutes"。

• 独立来源数：11（#1、#6、#7、#11、#14、#22、#23、#29、#30、#37、@stnciuu）。
• 分歧：
• 合并闸门不同：#29 坚持人批；@stnciuu 是 "CI decides what lands"；@ellfyy_ 转述 "sometimes the PR is already merged before she reads it"（原视频没核实）。
• #30 认为 "Grok bot 不是用來寫代碼的，代碼質量不太行"，要再加 CodeRabbit 等外部审查。
• #52："the pyramid catches bad code. it doesn't catch the wrong code. my agents once reviewed an empty PR and suggested a better title"。
• @WR4NYGov 拿 Build 和 cloud agent 做过双轨对比，没得出结论。
• 证据强度：高，有官方说法，也有多位实践者。

T5 连接器、浏览器与桌面

• 共识做法：

1. 有连接器就先用连接器，没有 API 的工具才让 bot 用电脑操作。登录、2FA、验证码由人接管（#19 第 3 条，#20 第 4 步）。
2. 能直连 REST API 就不用浏览器（#16：PocketSmith、Ghost 都是直连）。

• 独立来源数：5（#16、#19、#20、#51、W2）。
• 分歧：
• #51 希望支持本地电脑操作（595 赞）；@thebasedcapital 反对："one poisoned prompt away from your ssh keys"。
• #16 的作者通过 Tailscale 绕到自己的 Mac mini。
• 体验评价：@MrTacticalX "way too slow"；W2 "browser crashes and profile resets"。
• 已知 bug：自定义 MCP 的 OAuth redirect 出错，用户引用的客服回复说这是 "known bug on our side"（@_jsolly，只有一个来源）。
• 证据强度：中。

T6 安全与隐私

• 共识做法：

1. 同一账号下的 bot 共用一台电脑、一套登录，不能当作安全边界：#18 "bots are not security boundaries"，#21 第 6 步 "scoped accounts, read-only first, sign out when done"，#34，#48，W2。
2. 发送、花钱、删除、生产变更都要人批（#18、#19 第 12 条、#20 第 11 步、#21 第 5 步 "Allow once beats Always allow"）。
3. 模板当第三方软件来审（#19 第 19 条）。
4. 官方客服的上线路径：先只写内部备注，每个写操作都要人批，跑通后才放开（#3 文章："limiting it to internal notes and requiring human approval for every write action"）。
5. 外部输入（邮件、网页）都可能带 prompt injection：#49；#50 问 "can a routine be limited to whitelisted senders?"。#16 作者因为 "lethal trifecta" 没有自托管 OpenClaw，选择了有安全团队的托管产品。

• 独立来源数：9（#3、#16、#18、#19、#21、#34、#48、#49、#50）。
• 分歧：
• #16 认为托管比自托管更让人放心；#49 则要求 "isolated, encrypted vault with per-agent access"。
• @diamai_ 转述 Lee Robinson 的说法："a model reviewing every terminal action would beat the humans approving them most of the time"。这和"人批每一步"的做法相冲突（原讲座没核实）。
• 证据强度：
• 共用电脑、共用登录这一事实：高，官方文档被多方引用，Cursor 论坛发布帖原文是 "treat a login or file placed on it as available to all of your Bots"。
• 真实攻击案例：低。@tvykruta 说的 "$150k NFT theft… morse code" 找不到一手来源。

T7 故障案例

• 箱子回滚：#45 "rolled back to yesterday's snapshot, again this month… 15+ bots"；#46 给出办法：每晚把 bot 的角色、prompt、routine、skill 推到私有 GitHub，打一个已知可用的 tag，绝不提交 secrets。
• 虚假"完成"：#47 引用客服原话 "the false 'done' reports 'are a bug.'"。
• 官方关停过功能：#15 "temporarily disabling grok @bot voice mode for everyone"。
• 计费显示互相矛盾：#43 的 Cursor 页面显示 100%，xAI 仪表盘显示 5%。
• 复杂多 agent 迁移失败（#44）。
• 独立来源数：6（#15、#43、#44、#45、#46、#47）。
• 证据强度：中。除 #15 外都是用户自述，没有官方事故说明。

T8 跨 agent 协作（OpenClaw / Hermes / Dot）

• 做法：
• 多家 agent 放进同一个 Slack 频道，配一个 GitHub Projects 看板，互相审查（#35）。
• 用 webhook routine 接收外部 agent 的指令（@BotDirectoryAI 转述 Moritz Kremb：https://x.com/i/status/2102393063742042512 ）。
• 风险：外来消息就是注入入口（#50）；#16 提到 lethal trifecta。
• 独立来源数：3（#35、#16、#50）。
• 证据强度：低。

3. 主题共识速览

4. 和我们现在的配置对比

依据：用户给的舰队说明，加上 /home/box/agent-data/workflows 里的 engineering-playbook、routine-healthcheck、transcript-healthcheck、pstack、design-a-grok-bot。

我们已对齐

1. RT星云是唯一总控，下面挂专员（Researchy、小豆、码力、审码、绘审、dr eggbot）。这和 T1 的"总控入口 + 一个 bot 一件事"一致（#18、#22、#24）。
2. 码力的流程是 cloud agent 加 /poteto-mode、仓内 verify skill 和截图或视频证据。这和 #7、#6、#22 一致。playbook 里还写了 "No verify-*: create-verification-skill first"。
3. 合并前要审码给出「可合 @SHA」，再加 jc 本人批准，审码最多 3 轮。这和 #29 的人批、#36 的"up to 3 rounds"一致，也比 @stnciuu 的"CI 决定"更严。
4. 不可逆操作要人批，夜间 00:00–08:00 不弹审批卡。这和 T6 共识一致。
5. routine-healthcheck 已经检查这几项：太频繁、长对话上挂常驻 routine、空跑出声、重复或已过期，还会提示"常驻扫描单独放一个 bot"。这和 W1 员工回复、#26 的思路一致。
6. transcript-healthcheck 从对话记录里挖摩擦点再提议 skill。这和 #26 "Skill mining" 一致，也和客服文章里每周汇报不足的做法一致。
7. dr eggbot 负责设计新 bot。#16 作者正是用 "Dr. Egg skill pack" 来建 bot。
8. 和 OpenClaw 的频道规则是"只认 jc 本人的话算批准"。这正好针对 #50 提出的"外部消息就是注入入口"。

值得抄

1. 限制 bot 之间的往来：在各专员 profile 里加一行"只在需要对方动手时才发消息，不发确认、感谢或进度，做完发一条总结"。码力和 Researchy 每接一个任务开一个新 chat，状态放看板。依据是 W1 员工回复（每轮重读整段对话，约 1/3 的轮次是 bot 在叫醒 bot）和 12 个额度抱怨。
2. 每晚 git 备份 + 恢复 tag：把 workflows/*/SKILL.md、各 bot 的 profile 和 routine 配置推到私有仓，排除 secrets，并打一个已知可用的 tag。依据是 #45、#46。我在 workflows 里没搜到备份类 skill。
3. 把反复出现的审码问题变成 lint 或测试，而不是继续往清单里加文字。依据是 #6（金字塔顶层是代码改进）、#8（"turn into a constraint"）、@SublimeCoderX "a lint rule does more than five paragraphs of CLAUDE.md"。
4. 新 routine 上线前必须先过 skill 这一关：手动做成一次，存成 skill，用第二组不同输入跑通，再用 Test 跑一次，然后才排时间。依据是 #21、#27、#28。routine-healthcheck 目前只在"创建前"做一次体检，没要求先手动跑通。
5. cloud agent 每次启动都显式指定模型，并写进派活记录。依据是 #31。playbook 已经写了"follow 码力 bio short table"，只差把实际用的模型写进派活记录，方便事后对账。
6. 事件型 routine 和收件箱只接受白名单发件人。依据是 #50、#19 第 11 条。OpenClaw 频道已经这样做，可以照同一规则扩到 bot 邮箱和事件触发。
7. 清理重复 skill：engineering-playbook 和 engineering-playbook-2 内容完全相同（本地 diff 没有差异）；还有一批 skill-17xxxxx 没有可读名字。依据是 #26 "Duplicate rules"。

不建议抄

1. 搭 8 到 20 个 bot 的组织架构，或者用一键生成团队的 prompt（@marcuslayerx、@s4yonnara 那类）。#18 和 W1 都说扩编放最后，#44 就是复杂栈失败的例子。
2. 再加一层管理型 bot：用量监控 bot（#32）、凌驾在总控之上的 "Meta Boss"（@PaulShipsAI 2108819324546711635）、独立的 Peer Review bot（#36，我们已经有审码）、模板审查 bot（@scottwatts）。这些都会增加 bot 互相叫醒的次数，和第 3 节的成本共识相反。
3. 为了省额度把编码改走 Grok Build（#33）。没有核实，而且会绕开码力现在的 cloud agent 加证据流程。
4. 本地电脑操作，或者让 bot 隧道进个人电脑（#16 Tailscale、#51）。共用电脑加本地密钥的风险太高（@thebasedcapital）。
5. CI 绿了就自动合并、合并后人再看（@stnciuu，@ellfyy_ 转述）。这和"jc 用白话批准"的规则冲突。
6. 默认用 5 分钟轮询。只有 P0 才用，用完就删（我们的 playbook 已经这样写）。
7. 照抄"马斯克写的 12 页 PDF"那类爆款帖（#20，以及 #21 的署名）。署名无法核实，只能参考其中和官方指南重合的部分。

5. 前 5 条建议（P0–P2）

6. 不知道清单

• 各套餐每周 Grok Bot 额度的具体数字。官方只用相对说法（W1）。
• "一个任务一个新 chat"到底能省多少额度。W1 明确说官方文档没这么讲。
• 10-12 统一订阅之后，Grok Build 是否还是单独的额度池（#33 的说法）。
• 箱子回滚的频率、原因，以及官方有没有承认。目前只有用户自述（#45、#46）。
• 虚假"完成"bug 的修复状态。目前只有用户转述的客服原话（#47）。
• 用摩尔斯码绕过检查、"$150k NFT theft"一事。找不到一手来源（@tvykruta）。
• "Elon Musk 写的 12 页 PDF"的真实作者和原文（#20）。
• Lingxi、poteto 讲座视频里的数字，比如 "2,000 PRs"、"15→200+ cloud agents"、"15+ bots"。只有二手转述，原视频没看。
• X 长文（x.com/i/article/...）的正文，例如 @VarunChopr17597、@0xwhrrari 那几篇。没有抓取。
• x.ai 客服文章的确切发布日期。页面上没有日期，只能参考 @bot 帖子时间 2026-09-22 18:11 UTC。
• 网页文章（ghuntley、atlas、cellcog）的阅读量。
• 每个 bot 的记忆在同一账号下是否隔离。没有找到原文说明。
• HN 讨论帖的确切日期。只知道约在 2026-08（hn-tldr 写 "2 months ago"）。

7. 方法

• 先读了 x-api-mcp-guide/SKILL.md。用的是公共 x 命名空间的内置读取，按指南这类读取不花用户额度。
• X 调用一共 25 次：search_posts_all 22 次，get_posts_by_ids 3 次。另有 GetDynamicTools 查 schema 2 次，不算 X API。没有遇到 429。
• 用过的查询："Grok Bot" -is:retweet、from:bot（带回复和不带回复）、from:poteto（两个时间段）、url:ghuntley.com OR from:GeoffreyHuntley、conversation_id:（poteto 两条帖子的回复）、主题词组合（routine/memory/skill、额度、安全、cloud agent/PR、多 bot、浏览器/记忆、OpenClaw/Hermes、经验教训）加 min_likes:，团队成员（mattyp/lingxi/ericzakariasson/n2parko/roshan_s），以及 30–90 天的高赞帖。
• 网页：WebFetch 了 ghuntley.com/bot、x.ai 客服文章、atlas、cellcog；WebSearch 找到 HN 摘要和 Cursor 论坛帖。
• 没有用 Grok CLI（这一步是可选的）。
• 排除了：纯夸赞、@bot 的自动回复（"Sending that to your Grok Bot now" 一类）、币圈刷屏、纯转发。
• 本地对照：读了 engineering-playbook、routine-healthcheck、pstack 等 skill 的头部；用 rg 搜了 backup、snapshot、git push，没有找到备份类 skill；engineering-playbook 和 engineering-playbook-2 做 diff 没有差异。
• 报告里没有放 jc 的个人信息。