Grok Bot：共享一台计算机的多 Agent 团队

前置：08 单 Agent 还是多 Agent，特别是里面「编排在下沉进模型」那一节。

本篇回答：前面六家都在往「隔离更彻底」的方向走，Grok Bot 反过来让所有 Bot 共用一台机器，代价是什么；以及当编排变成一个可以直接调用的模型 ID 之后，你失去了哪些东西。

一、先分清三个都叫 Grok 的东西

「Grok bot」这个词现在同时指向三个架构完全不同的产品，混着谈会得出互相矛盾的结论。

三者不是同一产品的三个版本，而是三种独立的架构选择，各自服务不同的形态约束。下文按这个顺序反着讲：先讲信息量最大的 Grok Bot，再讲 API，最后讲 @grok。

本篇把重心放在 Grok Bot 上——它在前面六家划出的设计空间里落在一个此前没人占过的位置。

二、材料清单

材料	硬度	说明
docs.x.ai/grok-bot/* 官方产品文档（14 页）	✅ 官方一手	罕见地把共享边界的风险写在了自己文档里
docs.x.ai 多智能体模型能力文档与定价页	✅ 官方一手	参数名、配额、单价都是可核对的
xai-org/xai-sdk-python（559★，Apache-2.0）	✅ 官方开源	agent_count 的合法取值在类型定义里写死
xai-org/grok-prompts（4,382★，AGPL-3.0）	✅ 官方开源	⚠️ 最后一次推送 2025-11-17，已停更约九个月

两个产品的上线时间按官方 Release Notes：grok-4.20-multi-agent 在 2026 年 3 月（模型名里的 0309 就是这个日期），Grok Bot 在 2026 年 8 月。Grok Bot 上线不到一个月，文档还在滚动更新，本篇写到的配额和控制项都可能变。

grok-prompts 这个仓库需要额外说一句。它是 xAI 官方开的，README 明确说 ask_grok_system_prompt.j2 就是「Prompt for the Grok bot on X」——这在本专题里是独一份：别家的产品提示词都得靠泄露物拼，Manus 那篇 就是这么还原的。但它九个月没更新，而这期间 xAI 已经发了 Grok 4.20、4.5、4.6，所以这份提示词描述的是 Grok 4 时代的 @grok，不能当作今天线上版本的证据，只能当作「xAI 在那个时间点怎么设计一个大规模回帖 Agent」的一手样本。

三、隔离单位：一台机器，多块屏幕

3.1 与前六家正好相反的那个决定

Manus 一个子 Agent 一台虚拟机，Suna 一个子 Agent 一个沙箱容器，Kimi CLI 一个子 Agent 一份 context.jsonl。粒度不同，方向一致：隔离是收益，共享是风险。

Grok Bot 把这个方向掉了个头。官方文档的原话是：

All of your Bots use the same persistent cloud computer. They share files, browser sessions, and app logins.

The computer is isolated to your account, not to an individual Bot.

也就是说，隔离单位从「一个 Agent 一台机器」退到了「一个用户一台机器」。多个 Bot 在同一台机器上各占一块屏幕（screen），文档对这块屏幕的定性非常明确：

The screens are separate work surfaces, not separate security boundaries.

右图那台机器是按用户分配的，不是按 Bot 分配的。这一条决定了后面所有的收益与代价：交接便宜，是因为没有边界要跨；边界只有一层，也是因为没有边界要跨。

3.2 这个交换换回来的东西

代价明摆着，那收益是什么？

回想 Suna 那篇里的冷启动：每次派子 Agent 都要起沙箱、装依赖、重新走一遍登录。对「查完资料就扔」的任务这不算问题，但对跨系统的长期工作——比如「每周从 Salesforce 拉一次名单，去几个网站查，最后出一份草稿」——重隔离的代价是每一步都在重复同一套认证。

Grok Bot 的赌注是：这类工作里，重复登录的摩擦比串味的风险更贵。所以它把浏览器会话做成共享的，文档里写得很直接：

Because the browser is shared, signing in for one Bot makes the session available to your other Bots.

配套的还有一个共享工作区 /workspace，官方建议把长期项目文件放这儿，因为文件、浏览器状态和已登录会话被设计成能扛过计算机镜像更新与恢复。而临时目录、手装的包、没提交的应用状态则被明确归类为「可替换」，出问题时不保证还在。

3.3 并行度受什么限制

共享一台机器不等于串行。每个 Bot 有自己的屏幕，可以同时干活，但有一条硬限制：

One Bot can run only one computer-use task on its screen at a time.

也就是说，并行度上限等于 Bot 的数量，而账号级的配额是 Bot 与群聊加起来最多 50 个。跟前面五家的并发量级 放一起看：

产品	并发上限	由什么决定
DeerFlow	3	中间件显式限流
Kimi CLI	未硬编码	进程资源
Suna	数十	沙箱数
Grok Bot	≤ 50	Bot 数量配额，每 Bot 同时 1 个操作任务
Manus	上百	虚拟机数量

01 那条「隔离越重并发越高」的规律 在这里依然成立，只是 Grok Bot 换了个理由踩在中间：它的并发不受机器数限制，受角色数限制——而角色是人给的，不是系统按需拆出来的。

四、通信拓扑：具名实体之间的异步消息

4.1 星型之外的第二家

01 的 D2 维度 统计过：五家里四家是纯星型（子 Agent 之间不能说话），唯一的例外是 Claude Code 的 SendMessage。Grok Bot 是第二个例外，而且走得更远。

差别在于通信双方是什么：

	Claude Code	Grok Bot
通信双方	同一次任务里派出的兄弟子 Agent	长期存在的具名 Bot
生命周期	任务结束即销毁	跨会话持续存在
消息语义	任务内协调	唤醒对方处理一件事
人在哪	派完就在外面等	随时可插话，且优先级最高

Claude Code 的兄弟通信是为了修补隔离带来的信息割裂；Grok Bot 的 Bot 间消息是产品的基本交互方式——它本来就把 Bot 当同事，同事之间当然可以直接说话。

4.2 三条通路

第二条通路上那个「仅文本」的限制在实际使用里比看上去重要：一个 Bot 截了图想让另一个 Bot 看，走群聊交接是传不过去的，得直接发给对方 Bot。这是本专题里少见的、被官方文档写明的协议层限制。

三条通路的官方描述分别是：

用户消息抢占。 「A direct message from you takes priority over background work and can redirect the current turn.」——人的插话可以改写当前这一轮。这一点和前面几家「派完就等」的模型 差别很大，也是把 Agent 做成「聊天里的同事」必须付出的工程成本：后台任务得能在任意点接受重定向。

Bot 到 Bot 的异步唤醒。 「A Bot can send an asynchronous message to another Bot. The receiving Bot wakes, handles the request, and can reply later.」注意是「wakes」——Bot 平时不占资源，被消息叫醒。但群聊里的 Bot 间交接消息目前只能是文本，官方建议要传图就点对点发。

群聊，2–6 个 Bot。 不 @ 具体的 Bot 时，参与的 Bot 自己决定谁来回。这条设计和 MAST 的 FC2 类失效（智能体间失配，占 32.35%） 正面相撞——「让它们自己商量谁干」正是最容易产生重复劳动和互相等待的模式。文档自己也给了对策，写在「让 Bot 交接工作」那节：

Ask for a single owner at each stage. Too many parallel handoffs can create duplicate work and noisy updates.

这是一条经验，不是一个约束。 系统没有在机制上强制单一负责人，靠的是你在 kickoff 消息里把归属写清楚。对比 DeerFlow 把并发硬卡在 3，这是两种截然不同的治理哲学。

五、生命周期：本专题最强的持久化

01 的 D5 维度 上，前六家的取值从「一次性」到「可 resume」到「跨会话记忆」。Grok Bot 直接把 Agent 做成了一个长期存在的具名实体，这是取值范围的新上界。

5.1 什么会留下，什么不会

这块最容易想当然，官方文档给的边界很细，值得逐条列：

项	跨会话保留	跨 Bot 共享	删除 Bot 后
对话历史	✅	❌	删除
学到的偏好与角色记忆	✅	❌	删除
routine（定时任务）	✅	❌	删除
/workspace 下的文件	✅	✅	保留
浏览器会话与登录态	✅	✅	保留
命令行凭据	✅	✅	保留
已安装的 connector	✅	✅（账号级）	保留
skill	✅	✅	保留

最后那几行是运维上真正会咬人的地方。官方把它写成了一条明确警告：

Deleting a Bot does not remove shared-computer files or browser sessions.

也就是说，删掉一个 Bot 不等于收回它的权限。文档给的正确顺序是：先停 routine，再在共享计算机上从网站登出，再卸载 connector 并去源系统撤销授权，再删 /workspace 里的敏感文件，最后才删 Bot。

「复制一个 Bot」也有类似的反直觉之处：复制品带走 profile、设置、启用的 skill、routine 和头像，但不带走对话历史、学到的记忆和聊天附件。想按地区拆出多个「客户健康度 Bot」时，复制来的是壳，上下文得重新养。

5.2 从一次性任务到常驻自动化

Grok Bot 把「让 Agent 重复干一件事」拆成了两个概念，划分方式很清楚：

• skill 描述怎么做：什么时候用、需要哪些输入和权限、步骤顺序、怎么验证结果、返回什么、哪一步需要审批。
• routine 描述什么时候跑：绑定在某一个 Bot 上，按时间表或（在支持的地方）按事件触发。

官方对这条链路的表述是「先做一次性任务，把它做可靠，存成 skill，然后才自动化」。事件触发那一档还额外提醒不要写宽泛的监听条件，比如「每一条新消息」——那会同时制造噪音、消耗额度并放大误触发的面。

还有一条别处没见过的：演示教学。打开计算机视图选「Teach a task」，人工把一个浏览器流程做一遍，Bot 把它变成 skill 草稿。限制写得很具体——最长录制 10 分钟、不录麦克风、产出物是草稿需要人补上判断规则与失败处理。

这条路子解决的是前面几家都绕不开的问题：内部系统没有 API，也没有文档，只有一个知道该点哪儿的人。 把提示词写对的成本，在这类场景里经常高于把流程演一遍。

5.3 记忆不是数据源

文档在这一点上比多数产品诚实：

Memory is not a substitute for an authoritative source.

配套给了四条：变动的事实留在源系统、重要决策要让 Bot 去重新拉当前数据、发现过时假设直接纠正、安全边界写进 Bot 的描述而不是靠对话里说过。

最后一条是操作上的关键。Grok Bot 把「一次性指令」和「长期规则」分成了两个位置：

# 写在 Bot 的描述里（长期有效，每次任务都生效）
Never send external messages without approval.

# 写在对话消息里（只管这一次）
Draft follow-ups for these twelve accounts.

写错位置的后果是不对称的：把长期规则写进消息里，下一个任务它就不记得了。

六、刹车：审批只管住还没发生的事

Suna 那两起事故 说明的是：多 Agent 系统最贵的失控不是崩溃，是「一直干净地成功」。Grok Bot 的 Bot 直接操作真实系统——发邮件、改仪表盘、下单——所以刹车比前面几家都重。

第二层那条「Require 优先于 Allow」的冲突消解规则值得单独记：它意味着加一条宽泛的放行规则不会削弱已有的拦截规则，但反过来加一条拦截规则一定会生效——规则集只会越来越严，不会因为顺序问题失效。

还有一条容易忽略的自动刹车：长时间无人看管时，Grok Bot 会询问是否继续运行 routine，没人回答就把它们暂停。这是对「无人值守的自动化在你度假期间持续对真实系统发起动作」这个风险的兜底。

反过来说，共享计算机让最小权限变得难做。文档自己给的建议已经说明了这个困难：连只需要的工具、尽量用源系统的受限服务账号、从只读任务和草稿输出开始。这些都是绕过「Bot 之间没有边界」的补偿手段，而不是系统提供的隔离。

一句话结论：不要把「不同的 Bot」当成权限分区来用。这是官方文档自己写的——Do not use separate Bots as a security boundary.

七、grok-4.20-multi-agent：编排下沉成一个模型 ID

08 结尾那条趋势判断 说编排正在下沉进模型，当时的证据是 Kimi K2.5 的 swarm 模式。xAI 这边把它变成了一个可以直接下单的商品：grok-4.20-multi-agent。

7.1 它是什么

一个模型 ID。换掉模型名，你就从单 Agent 变成了多 Agent，不需要写任何编排代码：

from xai_sdk import Client
from xai_sdk.chat import user
from xai_sdk.tools import web_search, x_search

client = Client(api_key=os.getenv("XAI_API_KEY"))
chat = client.chat.create(
    # 换成这个模型名，服务端会启动多个 agent 互相讨论
    model="grok-4.20-multi-agent",
    # 内置工具在 xAI 服务端执行，你不实现、也看不到调用细节
    tools=[web_search(), x_search()],
    # 不加这个，流式输出里只有最终答案，看不到中间进展
    include=["verbose_streaming"],
)
chat.append(user("Research the latest breakthroughs in quantum computing."))

官方对内部结构的描述只有一句：

multiple agents are launched to discuss and collaborate on your query. Each agent contributes its own perspective, reasoning, and findings. A designated leader agent is responsible for synthesizing the discussion and presenting the final answer back to you.

拓扑是星型带汇总，和 Anthropic 多智能体研究系统 是同一个形状。区别在于这一次整个形状在服务端，你碰不到。

7.2 并发是个二选一的枚举

agent_count 不是一个可调的整数，只有两个合法值。这在开源 SDK 的类型定义里写死：

# xai-sdk-python 里 src/xai_sdk/types/chat.py
# 注意这是 Literal[4, 16] 而不是 int —— 填 8 会在客户端直接抛 ValueError
AgentCount: TypeAlias = Literal[4, 16]

# 映射到 protobuf 里的两个枚举值，服务端也不是接收一个数字
AgentCountMap: dict[AgentCount, "chat_pb2.AgentCount"] = {
    4: chat_pb2.AgentCount.AGENT_COUNT_4,
    16: chat_pb2.AgentCount.AGENT_COUNT_16,
}

走 OpenAI SDK 或 REST 时没有 agent_count 这个参数，改用 reasoning.effort 映射：low / medium 对应 4 个，high / xhigh 对应 16 个。

把并发做成枚举而不是数字，是一个有意思的产品决定。 DeerFlow 把并发卡在 3 是因为它知道自己的进程扛不住更多；xAI 把选项砍到两个，是因为它不打算让你调这个旋钮——你只需要回答「这题深不深」，剩下的它自己定。

7.3 子 Agent 的状态默认对你不可见

这是本篇最该记住的一条。官方原文：

Only the tool calls and the final response from the leader agent are sent back to the user. All sub-agent state — including their intermediate reasoning, tool calls, and outputs — is encrypted and included in the response only when use_encrypted_content is set to True.

注意「encrypted」的含义：即使你打开 use_encrypted_content，拿到的也是一坨密文，用途是在多轮对话里把上下文喂回去，不是给你看的。

把这张图和 08 结尾那句判断放一起看：「模型自主拆任务之后，死循环只会更难查，因为你连调度日志都看不到了。」这里连调度日志的接口都没有——能拿到的只有 usage 与 server_side_tool_usage 两个聚合数字。

7.4 换来的四个限制

方便是有价码的。官方「Limitations」那节列了四条，每条都不小：

限制	影响
不支持客户端自定义工具	只能用内置工具与远程 MCP。你自己的数据库、内部 API 接不进去
不支持 Chat Completions API	得改用 Responses API 或 xAI SDK，老代码要改
不支持 max_tokens	输出长度失去硬上限
只有 leader 的输出可见	无法对子 Agent 单独做监控、评估或断言

第一条是最要命的。多智能体最大的价值场景之一是「把内部系统串起来」，而这个模型正好把内部系统挡在外面——它只擅长研究公开信息，不擅长在你的系统里干活。 官方的示例查询全是「研究量子计算的最新突破」「对比 Rust、Go、Haskell 的取舍」这类题目，不是巧合。

第四条对应 MAST 的 FC3 类失效（任务验证，占 23.5%）。你没法验证子 Agent，只能验证最终产物。

7.5 计费口径

项	价格
输入 token（小于 200k prompt）	$1.25 / 1M
缓存输入	$0.20 / 1M
输出 token	$2.50 / 1M
prompt 达到 200k 之后	整个请求的所有 token 按双倍档计价
web_search / x_search / code_execution	$5 / 1000 次调用
collections_search	$2.50 / 1000 次调用
Batch API	八折
速率上限	9 请求/秒，250 万 token/分钟

token 单价本身不贵，问题在乘数：leader 与全部子 Agent 的所有 token 都计费，任何一个 agent 发起的工具调用也都计费。 官方原话直接给了警告：

a single multi-agent request may use significantly more tokens and tool calls than a standard single-agent request.

以及那句关于 16 个 agent 的：「uses significantly more tokens than the 4-agent setup」——没给倍数。对比 Anthropic 公开的 15 倍 token 数据，这里的成本可预测性明显更差：你既不知道跑了多少步（max_turns 的服务端默认上限未公开），也不知道每个子 Agent 各烧了多少。

能做的只有事后看账：响应里的 usage 和 server_side_tool_usage 是唯一的成本可见性。想控预算，只能自己设 max_turns。

八、@grok on X：并行下沉到工具层的单 Agent

最后回到最多人认识的那个「Grok bot」。它在本专题里的价值不在于架构复杂，恰恰相反——它是一个把所有并行都压进工具层的单体 Agent，且提示词完整公开。

关键几行（ask_grok_system_prompt.j2）：

You are @grok, a version of Grok 4 built by xAI.

- You have access to real-time search tools ...
  Parallel search should be used to find diverse viewpoints.
  Use your X tools to get context on the current thread.
- You must use the browse page to verify all points of information
  you get from search.
- In your final answer, write economically. Please keep your final
  response under 550 characters.
- Do not use markdown formatting.

三条值得抄的设计：

并行放在工具层，不是 Agent 层。 「Parallel search should be used to find diverse viewpoints」——多视角是靠一次发多个搜索请求拿到的，不是靠派多个子 Agent。对「回一条帖子」这个粒度的任务，派子 Agent 的固定开销 根本收不回来。

搜索结果必须二次核实。 「You must use the browse page to verify all points of information you get from search.」搜索摘要不算证据，得点进原页面。这条对应 MAST 里的信息失真类失效，而且是用提示词而不是用代码实现的——成本低，但也没有强制力。

输出上限 550 字符是架构约束，不是文案偏好。 平台形态倒逼：帖子回复不能长。这个约束反过来解释了为什么不需要子 Agent——Kimi CLI 要给子 Agent 的结果做 200 字下限重写，是因为多 Agent 系统的通病是「回收上来的信息太少」；而 @grok 面临的是相反的问题：信息太多，得压进 550 字符。 在这个方向上，多派几个 Agent 只会让压缩更难。

再提醒一次：这份提示词的仓库最后更新于 2025-11-17，描述的是 Grok 4 时代的 @grok。当作设计样本读，不要当作今天线上行为的依据。

九、五个维度上的位置

按 01 的五维度 填表，把 Grok 的两套多 Agent 实现和前六家放一起：

	Grok Bot	grok-4.20-multi-agent	参照：Manus	参照：Claude Code
D1 隔离单位	共享计算机上的一块屏幕（非安全边界）	服务端不可见的一个 agent 槽位	一台虚拟机	上下文窗口 / git worktree
D2 通信拓扑	点对点 + 2–6 人群聊	星型，leader 汇总	星型，官方禁止通信	星型 + SendMessage
D3 结果回收	消息文本（Bot 间交接仅文本）+ 共享文件系统	只回 leader 的工具调用与终稿，子 Agent 全程加密	主 Agent 综合	仅最终结果
D4 递归深度	无嵌套概念，Bot 可建议新建 Bot，账号上限 50	未公开，agent_count 是唯一旋钮	未公开	默认 3 层
D5 生命周期	持久具名实体，跨会话保留记忆、文件、登录态	单次请求，多轮靠 previous_response_id	一次性	background / memory / fork
并发上限	≤ 50 个 Bot，每 Bot 同时 1 个操作任务	4 或 16，二选一	上百	未公开
步数上限	未公开	max_turns 可配，服务端默认未公开	均值约 50	maxTurns 可配
成本刹车	审批 + Auto Review + 长期无人自动暂停 routine	无，全额计费	KV-cache 优化	——

两条横着看才显现的东西：

① Grok Bot 把「隔离」和「持久化」做了一次交换。 前六家的持久化都很弱（Kimi CLI 的 resume 已经是最强的），因为强隔离天然和长期状态冲突——状态存在哪儿？Grok Bot 的答案是「存在那台共享机器上」，于是持久化直接拉满，隔离直接归零。这不是妥协，是同一个决定的两面。

② 编排下沉之后，成本刹车是第一个消失的东西。 08 判断「编排会下沉，治理不会」。grok-4.20-multi-agent 这个样本给出的是一个更悲观的中间态：编排下沉了，治理接口还没跟上。你既不能限制子 Agent 的行为，也不能观察它们，唯一的旋钮是 max_turns 和一个二选一的 agent_count。

十、什么时候不该用

Grok Bot 不该用在这些地方：

• 拿 Bot 当权限分区。 官方文档自己写了 Do not use separate Bots as a security boundary。需要「财务 Bot 看不到 HR 数据」这种隔离，这个产品给不了。
• 多人协作的团队资产。 那台计算机绑在个人账号上，不是团队共享的工作区。
• 需要严格审计链的合规场景。 每个 routine 只保留最近 20 条运行记录，删除 routine 无撤销，删除 Bot 也不清理它在共享机器上留下的登录态。
• 不可逆动作占主线的流程。 审批和「Stop now」都只管住尚未发生的动作。如果流程的主体就是发送、支付、发布，那应该把 Agent 的产出停在草稿，由人执行最后一步。

grok-4.20-multi-agent 不该用在这些地方：

• 要接入你自己的系统。 不支持客户端自定义工具，这是硬伤。
• 要对子 Agent 做评估或监控。 看不见就是看不见。
• 成本必须可预测。 全额计费 + 步数上限未公开 + 16 agent 的倍数未公开，三个不确定叠在一起。
• 已经在用 Chat Completions API。 不兼容，要改造。

它适合的场景其实很窄也很清楚：一次性的、基于公开信息的深度调研，你愿意为质量付钱，且不需要审计过程。这正好是官方所有示例查询的形状。

十一、参考

• Grok Bot 官方文档：https://docs.x.ai/grok-bot/overview
• 共享计算机与应用：https://docs.x.ai/grok-bot/computer-and-apps
• 审批、安全与隐私：https://docs.x.ai/grok-bot/approvals-security-and-privacy
• 消息与协作：https://docs.x.ai/grok-bot/chat-and-collaboration
• skill 与 routine：https://docs.x.ai/grok-bot/skills-routines-and-automations
• 多智能体模型能力：https://docs.x.ai/developers/model-capabilities/text/multi-agent
• 内置工具总览：https://docs.x.ai/developers/tools/overview
• 定价（含工具调用单价）：https://docs.x.ai/developers/pricing
• xAI 官方 Python SDK：https://github.com/xai-org/xai-sdk-python
• xAI 官方提示词仓库（⚠️ 停更于 2025-11-17）：https://github.com/xai-org/grok-prompts
• 上一篇：08 单 Agent 还是多 Agent——本篇是那条「编排在下沉」判断的一个实测样本