软件技术分享

关于电子游戏的方方面面

Grok：多代理适合拆哪些子问题、不适合哪些

作者

产品页把 Multi-agent 写成并行代理处理更难的问题，再合并成一带引用的回答。适合能单独核验的分头检索，也适合多源对照。同一份上下文的细改和强顺序步骤、额度紧的小任务，以及对同一份文档的精确引用终审，别开。它不是更准开关。

要点

  • 2026 年 11 月消费端产品页栏目名是 Multi-agent，文中也写 Multi-agent mode：多个代理并行处理子问题，各自展示推理过程供你核对，再合并成一个带引用的回答。产品页还写：升级到 SuperGrok 可获得更高限额、优先权和 multi-agent reasoning。入口、套餐名称，以及聊天里的模式名，以你登录后的现页为准。（Grok 产品页）
  • API 文档把这项能力叫 Realtime Multi-agent Research，模型名是 grok-4.20-multi-agent，目前标 beta，接口可能改。一次请求会拉起多个代理讨论，由指定的 leader agent 汇总终答。可选 4 个或 16 个代理：官方建议 4 个用于聚焦、较快的查询，16 个用于更深、更多面的研究；代理越多，token 和延迟越高。（Multi Agent｜docs.x.ai）
  • 官方计费口径：leader 和所有子代理的输入、输出以及推理 token 都要算；任一代理发起的服务端工具调用也要算。文档写明，单次多代理请求可能比普通单代理请求显著消耗更多 token 和工具次数。（同上）
  • 官方提示建议：把比较维度写死，要求结构化输出，并指明要哪类来源。复杂题目拆成多轮对话，不要一次塞满。宽泛提问（例如“讲讲电动车”）被当作反例。（同上）
  • 适合拆给多代理的，是彼此独立又能分开核验、并且需要同时从网页或 X 做多源对照的研究题。不适合的是必须按顺序推进的步骤，以及必须守住同一份上下文的细改；额度紧的小任务，和对同一份文档做精确引用的终审，也不要放进去。
  • 官方 Consumer FAQs 写过：Grok 偶尔会给出不准确或不合适的信息，用前须仔细核验。打开多代理不会取消这条提醒。（Consumer FAQs）
  • 产品页现行栏目名是 Multi-agent。聊天里的模式名以你登录后现页为准；未登录配置里仍可见 Heavy（Team of Experts · Grok 4.7）和思考框标题 “Grok 4 Heavy”，不要先当成过时营销名丢掉。xAI 另两款独立产品——终端里的 Grok Build（x.ai/build，官方写并行 Subagents）和云端队友应用 Grok Bot（x.ai/bot，官方写明它不是 grok.com／Grok App，可让多名 Bot 同时工作）——也不要和这个 Multi-agent 栏目混成同一个开关。本稿不重算套餐账。

正文

场景

编辑要对三家竞品的公开定价、更新说明和社区讨论做对照。有人把整件事，连同“顺便把导语改得更像上一版口吻”，一起丢进 Multi-agent。

代理分头检索，合成稿看起来很全。官方价和论坛传闻写在同一段里。导语也被重写，上一版已经钉死的限定词没了。用量多扣了一截。

这是典型的捆包风险示意，不是某次逐字实测。能分头查、能单独核对的部分，适合交给多代理；必须守住同一份上下文的细改，不该和检索捆在一次请求里。

可跟做步骤／可抄工作流

1. 先认产品页名称，再对照聊天里的现页模式

打开 Grok 产品页，现行栏目写的是 Multi-agent，下文也出现 Multi-agent mode。产品页把这项能力概括成：并行代理处理子问题，各自展示推理过程供你审计，再合并成一个带引用的回答；并写升级到 SuperGrok 可获得更高限额和 multi-agent reasoning。消费端聊天里的模式名、按钮文案，以及是否要付费档才能打开，以你登录后的现页为准。未登录的 grok.com 会下发模式列表 Auto、Fast、Expert，以及 Heavy（说明是 Team of Experts · Grok 4.7），同页配置里还有思考框标题 “Grok 4 Heavy”；页面正文不见 Multi-agent 字样。不要把 Heavy 或 Grok 4 Heavy 当成已经消失的旧名。它们和产品页 Multi-agent 是不是同一个开关，也以你账号现页为准，不要靠猜测对号。

开发文档里对应的是 grok-4.20-multi-agent，可以称为多代理研究。它目前是 beta。

xAI 另有两款独立产品也谈并行，不要和聊天里的 Multi-agent 当成同一个开关：终端编程代理 Grok Build 会拉起并行子代理（见 Grok Build）；云端队友应用 Grok Bot 可让多名 Bot 同时协作（见 Grok Bot）。消费端 FAQ 写明：Grok Bot 不是 grok.com 或 Grok 手机 App。本稿只谈 grok.com／App 与 API 这条 Multi-agent 研究能力。

2. 先拆题，再决定开不开

把总任务写成一行，再把子问题列出来。每个子问题问自己三句：

  1. 不看其他子问题的答案，这一问能不能单独成立？
  2. 回来之后，我能不能用官方页、公告或原始帖单独核验？
  3. 它是否必须咬住同一段已定稿的措辞，或同一份文档的精确出处？

前两句是“是”、第三句是“不必”的，才适合放进一次多代理请求。第三句是“必须”的，留在普通单线程对话里做。

下面是可抄的拆题纸。

总任务：________________________________

适合并行的子问题（彼此独立，可单独核验）：
1) ________________________________ 核验方式：______________
2) ________________________________ 核验方式：______________
3) ________________________________ 核验方式：______________

不要放进这次多代理请求：
- 必须按顺序做的步骤：____________________
- 必须守住同一份上下文的细改：______________
- 要对同一份文档做精确引用的终审：__________

给多代理的提示范围：只做上面“适合并行”的清单。
合成后不要直接改导语或终审引用；那些另开一轮普通对话。

官方自己的提示建议也站在同一侧：把要覆盖的维度写清楚，要求对照表一类的结构，并指明要哪类证据。文档给的反例是 “Tell me about electric vehicles.” 正例是写死制造商数量，再分别核对电池技术、续航和充电设施，以及某年销量预测。这些维度可以分开核对。复杂题目，官方建议先广后窄，拆成多轮，不要一次塞满。

3. 怎么写一次并行请求

把拆题纸上“适合并行”的部分，写成下面这类提示，按你的题目改括号。检索可以点到，但不要把时间窗纪律整套搬进来。突发新闻怎么卡时间窗，见站内另一篇。

请只研究下面这些彼此独立的问题，不要改我未提供的成稿措辞。

问题：
1) 【主体 A】在【官方站点／公告】上的现行公开价格是什么？请列出页内原文要点和链接。
2) 【主体 B】最近一次公开更新说明写了哪些变更？请列出原文要点和链接。
3) 社区讨论里对【同一产品】的主要抱怨和称赞分别是什么？请与官方说明分开写，不要揉成一句。

输出要求：
- 按问题分节，不要提前写成一篇散文。
- 每一条带来源链接；官方材料和社区材料分开。
- 对不上或打不开的，写“未见／不确定”，不要补齐。
- 最后给一张对照表，标出相互矛盾的地方，不要私自抹平。

消费端如果能看到每个代理的推理过程，产品页的设计就是让你审计，不要只读合并后的终稿。API 默认只回 leader 的工具调用和终答，子代理中间状态默认不明文给你。

代理数量写在 API 文档里：4 个适合聚焦、较快的查询，16 个适合更深、更多面的研究，并提醒 16 个会显著更耗 token。聊天界面里能不能选、怎么选，以现页为准。没有特殊理由，先用更少的配置。第三方指南给过一条使用经验：先看 4 个代理够不够；只有你已经看见 4 个会漏掉关键面，再考虑 16 个。这不是官方保证。

4. 合成之后，你还要做的终审

多代理回来的是一份合并稿，不是已经终审的结论。至少做这三步：

  1. 按子问题把官方材料、社区材料和模型自己的推断拆开。揉在同一句里的，拆开或删掉。
  2. 点开引用和链接。打不开、对不上原文的句子，按未核处理。
  3. 需要改导语、统一口吻，或按某一份文档核对精确引语时，另开一轮普通对话，只带已经核过的事实和那一份原文。不要再把终审扔回一次多代理。

官方文档把“指定来源或视角”写成有效用法，没有把多代理写成正确率开关。Consumer FAQs 的提醒仍然有效：输出可能不准确，用前须核验。

真实用户诀窍／反例

  • 诀窍：先写“可独立核验”清单，再开多代理。 清单写不出来，通常说明题目还不该并行。
  • 诀窍：官方材料和二手讨论强制分栏。 多源对照的价值是把矛盾摆出来，不是写成更顺的一段话。
  • 诀窍：先少后多。 官方把 4 个代理留给聚焦查询，把 16 个留给更深的研究，并标明更耗 token 和延迟。
  • 诀窍：看得到各代理推理就去看。 产品页把“可审计”写进能力说明。只读终稿，等于把合并步骤当成了终审。
  • 反例：把“查三家公开定价”和“按上一版口吻改导语”捆成一次多代理。 前半适合并行，后半要守住同一份上下文。
  • 反例：额度紧时，用多代理改一句邮件、缩一段说明。 官方已提醒单次请求可能显著更耗用量。小任务不值得这样花。
  • 反例：把一份合同或一篇待发稿丢进去，让多代理做精确引语终审。 终审要咬住同一份原文的同一段，不该分头各写各的。
  • 反例：把合并稿直接转发到群里当已核实结论。 官方要求自行核验，多代理没有取消这项义务。

适用边界

  • 本稿覆盖：消费端产品页所称 Multi-agent／Multi-agent mode，以及 docs.x.ai 上的 grok-4.20-multi-agent 研究能力。重点是哪些子问题适合拆、哪些不该拆。
  • 不覆盖：新闻突发检索的时间窗怎么立（见站内《Grok：新闻／突发检索的时间窗纪律》）；也不按周用量重算 SuperGrok 或 The X Subscription 划不划算（见站内档位粗算篇）。额度在这里只作边界提醒。
  • 消费端的按钮文案和模式入口、你的套餐是否包含这项能力，以及 4 个或 16 个代理在聊天界面里如何选择，一律以登录后现页为准。
  • API 仍标 beta，且不支持客户端自定义工具，也不走 Chat Completions，还不支持 max_tokens。这些是集成限制，不要写成消费端操作步骤。
  • 打开多代理不会让答案自动更准。可能出错，也可能更耗用量，官方都已经写过。