实测丨最近爆火的Grok Bot能不能打？我们让它和两款国产Agent同题写论文

“从主动找活到召集 Bot 干活，马斯克的 AI 团队进化到哪一步了？”

(资料图)

作者丨吴海明

编辑丨李娜 岑峰

马斯克的 Grok Bot，最近连自己的工作邮箱都有了。

10 月 14 日，Grok Bot 又更新了一项功能：用户可以给 Bot 的邮箱设置不同别名，例如专门接收新闻简报、购物收据或旅行信息，并让不同邮件分别触发预设的工作流程。

这意味着，用户不必每次打开对话框安排任务。邮件来了，Bot 就可以按照事先设定的规则开始工作。

几天前，Grok Bot 还获得了另一项能力：主 Bot 可以根据已有的工作上下文，主动发现能够替用户处理的事情，并提出接手建议。

Grok Bot 究竟是什么？

今年 8 月 11 日，xAI 正式发布 Grok Bot，将其定位为一组可以持续工作的 AI Teammates（AI 队友）。

它不像传统聊天助手那样，主要围绕一个对话框展开工作。用户可以创建多个具有不同名字和职责的 Bot，例如研究员、项目经理、运营专员，让它们各自负责一类工作。主 Bot 会根据每日任务执行情况，帮助用户发现下一步工作，并主动提议接手，把需要决定的事留给用户排版。

（示意图：无需用户主动发问，Grok Bot 根据已有工作上下文，主动提醒 AAAI-27 审稿截止日期，并提出进一步核查 OpenReview 中尚未提交的稿件。）

这些 Bot 也不必在每次任务开始时重新创建。它们能够保留各自的会话、工作偏好和长期上下文，还可以互相发送消息、进入群聊，将尚未完成的任务交给其他 Bot 继续处理。

支撑这套协作方式的是一台持久化的云电脑。

同一账户下的多个 Bot 共用其中的文件、浏览器登录状态和命令行凭据，并拥有各自的操作界面。前一个 Bot 搜集的资料，后一个 Bot 可以直接接着处理；即使用户关闭本机，后台任务仍能继续执行。

Grok Bot 还试图让这支团队逐渐熟悉用户的工作方式。用户可以将完成过的工作流程保存为 Skill，再通过 Routine 设置定期执行。10 月 2 日新增的主动提议能力，则让主 Bot 能够根据已有上下文，发现可以继续推进的工作，并向用户提出接手建议。

不过，几个 Bot 一起工作，究竟能比单个智能体多做些什么？任务分给不同角色之后，最终成品是否真的会更好？我们找来了 Grok Bot、WorkBuddy 和 Qoder CN，让三款支持多智能体协作的产品完成同一道研究任务。

本文中，我们让Grok Bot、WorkBuddy 和 Qoder CN都完成了同一道研究任务，围绕大模型路由为题写一篇综述，完成文献检索、方法梳理、数字核查和独立审稿，这个题目要求智能体能区分多个名字相似度极高的研究，也要求审稿意见落实到最终文件，还要求智能体能在分工、交接和纠错过程中都能在交付物中留下痕迹。

经过实测，Grok Bot 用 12 分 49 秒交稿，速度最快、收录论文最多；WorkBuddy 用 21 分 43 秒，交出了最接近编辑底稿的正文；Qoder CN 用 14 分 42 秒，呈现出一次有价值的智能体交叉纠错。三份交付也分别留下文件引用、数字口径或方法归类方面的问题。由此判断，多智能体产品下一步要比拼的是交付可靠性：核查结论能否穿过每次交接，准确落到最终文件。

01

三款 AI 团队写同一道综述，谁先交卷？

为什么选大模型路由？

这是一个很容易在资料整理阶段出错的研究主题。不同论文可能使用相近的名称，却采用不同的路由方法；同一项研究在论文、项目仓库与其他介绍材料中，也可能出现口径不同的实验数字。

仅仅搜集十几篇论文、将内容拼成一篇综述，并不意味着任务完成。

我们要求智能体分别承担文献检索、方法梳理、实验与基准核查、独立审稿等职责，并在最终交付中保留可见的任务交接与修订记录。

测试指令如下：

1. 请使用你可用的多智能体协作机制，完成一份截至 2026 年 10 月 15 日的中文研究综述，主题为“大模型路由研究”。

2. 请让不同智能体分别承担文献检索、方法梳理、实验与基准核查、独立审稿等职责，由一位负责人整合结果。

3. 可以按产品支持的方式分工，但必须保留实际可见的任务交接与审稿修改记录；不要编造未发生的智能体协作。

4. 最终交付：①一篇约 3000—4000 字的综述，解释大模型路由要解决什么问题、主要方法如何分类、LLMRouter 的具体贡献及局限；②一张涵盖至少 12 篇原始论文的对照表，列出方法、路由依据、模型池、质量／成本／延迟指标及适用边界；③一个“尚无定论的问题”小节；④简短的协作记录，说明哪个智能体发现了什么问题、谁核实、最终如何修订。

5. 优先阅读论文全文、作者项目与公开代码。

6. 每项关键事实和数字附可打开的原始来源链接；区分论文报告的结果、独立基准结果与自己的推断。

7. 无法核实的说法标为“待核实”，不要填补或编造引用。

8. 完成前请由未负责撰稿的智能体独立检查引用、数字、方法分类和结论边界。

来看看三款产品的表现：

首先是 Grok Bot，Grok Bot 以最快的使用感受完成了任务。如下图所示，Grok 先把任务交给显示的“学术调研师”、“项目经理”和“文章撰写专员”三个具有名字的 Bot，自己负责最终整合。学术调研师给出 19 篇论文的对照表，并提前区分多个高相似度研究名字，项目经理核查数字，撰稿 Bot 收到材料后写初稿，学术调研师再对其审阅。最终， Grok bot 给出了含有八份文档文件的产出，覆盖正文、对照表、开放问题、文献梳理、基准核查、审稿意见和协作记录。

Grok bot 运行截图 1: 任务开始后调用三个 bot 一起干活儿

Grok bot 运行截图 2: 任务完成后给出交付清单

在 Grok bot 执行任务过程中，独立审稿意见抓到了两个未经核查表格确认的百分数，撰稿 Bot 随后将其删去。另一轮交接还纠正了两篇论文的 arXiv 编号，这些是可以从文件与会话互相对应的修订，说明多 Bot 协作在扩大检索范围之外，确实承担了核查职责。

其次是 Qoder CN，在任务开始后，启动了三个检索子智能体分别寻找核心论文、基准与近期进展；随后由方法梳理和事实核查两个角色接手，独立审稿者在成稿后检查，最终 Qoder CN 给出了包含四个文档的交付件：综述、论文对照表、开放问题与协作记录。

Qoder CN 运行截图 1: 任务开始后创建 3 个智能体检索文献

Qoder CN 运行截图 2: 创建方法梳理和事实核查 2 个智能来处理检索后的论文

Qoder CN运行截图 3: 交付件截图

Qoder CN 运行截图 4: 任务结束后 6 个智能体使用总结

在任务执行最后，核查者智能体参考 RouteLLM 论文，认为“最高节省 85% 成本”出处不明；审稿者继续找到项目仓库来确认项目这一表述。此外，论文表格中给出 3.66 倍的成本节省比率，两个数字的评测条件和计算口径需要分别说明，不能直接互换。因此，增加的审稿工序确实改变了稿件内容。

然后是 WorkBuddy，从评测感受上来看，WorkBuddy 花的时间最长，交出的正文也最像一份可继续编辑的研究底稿。在文献检索、方法梳理、基准核查分别安排来三个研究角色并行工作，由负责人整合初稿，再交给未参与撰稿的角色审阅，最终综述围绕“路由信号”和“决策结构”组织方法，明确区分论文自报、独立基准、作者推断和待核实数字，并且读者能够顺着标注回到证据。

WorkBuddy 运行截图 1: 任务开始后创建 3 个智能体检索文献

WorkBuddy 运行截图 2: 任务总共耗时 21 分钟 43 秒，给出完整交付件

WorkBuddy 运行截图 3: 协作纠错是重点总结问题

此外，整个任务 Grok Bot 用时12 分 49 秒，Qoder CN 为14 分 42 秒，WorkBuddy 为21 分 43 秒。智能体数：Grok Bot 的 4 个角色、WorkBuddy 的 5 个角色均包含主智能体，Qoder CN 的 6 个子智能体，另有主智能体。角色数的计数口径并不一致，不能用来推断“智能体越少，运行越快”，耗时包含检索、等待、审稿和交付，并非纯模型推理时间。

三款智能体的耗时和任务执行所用智能体个数

总体来看，三款产品都完成了综述、论文对照表、开放问题和协作记录，审稿环节也留下了可追踪的修订。Grok Bot 以速度和检索覆盖见长，WorkBuddy 的正文最适合作为编辑底稿，Qoder CN 展示了审稿者纠正核查者的交叉检查。

02

拆解 Grok Bot：

几个 Bot 是怎样接力完成任务的？

在三个产品评测过程中，Grok Bot 的协作方式给测试人员带来了较为惊喜的体验，如下视频所示：

这次任务的主会话给出了清楚的动作顺序：Grok 发出分工；调研师送来文献包，项目经理指出数字和链接问题；撰稿 Bot 收到核过的材料写初稿；未参与撰稿的调研师审阅后退回两项硬数字；撰稿 Bot 修订，Grok 最终把文件拷到指定目录，而且用户能清晰看见所有参与行动的 Bot 的运行状态。

这套交接方式依托Grok Bot 的共享云电脑，根据官方说明，Bot 可以在用户关闭本机应用后继续工作，同一账户下的多个 Bot 共用文件、浏览器登录态和命令行凭据，各自有可并行操作的会话窗口。前一个 Bot 保存的资料能被后一个 Bot 接着使用，减少了人工搬运材料的步骤，同时会话窗口用于区分不同的工作界面，不构成 Bot 之间的权限隔离。云端执行并非 Grok bot 的独有创新，多款类似产品也有云环境运行设定，例如 Manus Cloud Computer、WorkBuddy 企业智能体、Qoder Cloud Agents等。

此外，Grok Bot 在 10 月 2 日还公布了“主 Bot 主动发现工作并提出接手”的能力。如下图所示，Grok 在上午报告新增五篇调研论文，并生成一封等待用户确认的邮件草稿。这是 Grok bot 在基于用户前一次任务调研任务之后，主动发起的“把检索结果推进到了邮件”的用户审批。

Grok Bot 在文献调研后主动发起

将调研结果推进到了邮件的用户审批截图

03

从接任务到主动找活

Agent 产品还要解决什么？

这轮同题测试中，Grok Bot 用 12 分 49 秒交出覆盖面最广的论文研究包，Bot 之间的分工、核查和退稿都有记录，同时 WorkBuddy 的正文更适合作为编辑底稿，Qoder CN 展示了有效的交叉纠错。三款产品共同表明，多智能体已经能够承担研究流程中的具体工序，而成果质量仍要落实到读者结合自己的专业水平进一步优化。

对比 WorkBuddy 和 Qoder，Grok Bot 展现出产品形态的另一面，把智能体放进了一套持续运行的云环境，这样一来，Bot 可以跨会话保留材料，也能接着同伴的工作往下做。相应地，长期任务能否在故障后恢复、共享资料如何控制访问、每项任务消耗多少资源，都成为产品能力的一部分。

此外，交互方式也在变化。Grok bot 把具名 Bot、工作状态、例行任务和交付物放到同一个界面；用户可以看见谁在处理任务，并在需要判断时接手。同时，通过 “Grok 报告新增五篇论文，生成邮件草稿，把发送动作留给用户确认”这一片段，Grok 能根据此前设置过的账号和检索任务，来“主动发现工作”。这是一项非常有趣且有用的能力，不过，未来衡量主动提议能力，还要看建议是否切中需求、是否频繁打断用户，以及哪些动作必须停下来等待授权。

马斯克近期在 X 上提出，Grok Bot 今后会按任务选用包括第三方服务在内的后端模型。这也可能意味着产业将进一步细分，模型研发与智能体产品研发的分工将更清晰，两类团队也仍会向彼此的领域延伸，从智能体产品角度来看，决定产品竞争力的，是这套流程能否稳定交付，并让用户看清数据流向、任务成本和结果依据。

因此，三款产品显著的不同在于 Grok Bot 已把云端常驻、跨会话接力和主动提议带进同一工作环境，三款产品仍各有成稿缺口，说明检索、核查与审稿的成果还需要准确进入最终文件。随着模型和 Bot 可以按任务组合，产品竞争将越来越取决于这条链路能否持续运转：任务中断后接得上，关键决策由用户把关，过程与成本查得到，成品经得起专业复核。

点击关键词查看对应实测内容

月之暗面 Kimi

智谱 GLM

深度求索 DeepSeek

阿里 Qwen

字节跳动

更多测评