實測 Grok Bot：變身「雲端AI團隊」同題硬剛兩款國產Agent

一套代碼能跑遍所有芯片。作者丨吳海明 編輯丨李娜 岑峰 01Grok Bot 的進化：從“聊天框”到“雲電腦”馬斯克最近又給 Grok Bot 加上了新技能點。（）10 月 7 日，他在X上表示 Grok Bot 將接入 Claude Opus 5.5、Midjourney 和 Suno等第三方頂級模型；而最近更是迎來了一次核心範式的躍升：主 Bot 會發現可替用戶承擔的工作，並主動提議接手。也就是說，它不再只是被動等待提問的聊天機器人，而是變為“主動找活幹”的AI雲端團隊。它不像傳統聊天助手那樣，主要圍繞一個對話框展開工作。

用戶可以創建多個具有不同名字和職責的 Bot，例如研究員、項目經理、運營專員，讓它們各自負責一類工作。主 Bot 會根據每日任務執行情況，幫助用戶發現下一步工作，並主動提議接手，把需要決定的事留給用戶排版。（示意圖：無需用戶主動發問，Grok Bot 根據已有工作上下文，主動提醒 AAAI-27 審稿截止日期，並提出進一步核查 OpenReview 中尚未提交的稿件。）前腳剛蒐集完資料，後腳就主動擬好郵件等你確認審批；你關閉了電腦，它在雲端還在和它的“AI 同事們”交接工作。這種以 Grok Bot 為代表的“多智能體協作”與“主動式 Agent”，究竟進化到了什麼程度？

幾個 Bot 一起打配合，比單個智能體強多少？為此，我們策劃了一場“同題硬核測試”：找來 Grok Bot 以及兩款國產 Agent——WorkBuddy 和 Qoder CN，讓它們分別組建 AI 團隊，完成一項極易出錯的研究任務：撰寫《大模型路由研究綜述》。這個測試，需要完成文獻檢索、方法梳理、數字核查和獨立審稿，這個題目要求智能體能區分多個名字相似度極高的研究，也要求審稿意見落實到最終文件，還要求智能體能在分工、交接和糾錯過程中都能在交付物中留下痕跡。

經過實測，Grok Bot 用 12 分 49 秒交稿，速度最快、收錄論文最多；WorkBuddy 用 21 分 43 秒，交出了最接近編輯底稿的正文；Qoder CN 用 14 分 42 秒，呈現出一次有價值的智能體交叉糾錯。三份交付也分別留下文件引用、數字口徑或方法歸類方面的問題。由此判斷，多智能體產品下一步要比拼的是交付可靠性：核查結論能否穿過每次交接，準確落到最終文件。02三款 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 展現了極致的“速度與廣度”： 僅用 12 分 49 秒完稿，耗時最短，檢索覆蓋的論文庫最龐大；WorkBuddy 勝在“工程化底稿質量”： 耗時最長（21分43秒），但交出的正文邏輯最嚴密，最接近人類編輯可直接使用的初稿；Qoder CN 則演繹了最精彩的“交叉糾錯”： 耗時中等（14分42秒），其內部的獨立審稿機制成功攔截了引用出處不明的漏洞，證明了“AI 監督 AI”的可行性。

03拆解 Grok Bot：當AI開始自己找活幹在三個產品評測過程中，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 在文獻調研後主動發起將調研結果推進到了郵件的用戶審批截圖04從接任務到主動找活，多智能體賽道卷什麼？

這輪同題測試中，Grok Bot 用 12 分 49 秒交出覆蓋面最廣的論文研究包，Bot 之間的分工、核查和退稿都有記錄，同時 WorkBuddy 的正文更適合作為編輯底稿，Qoder CN 展示了有效的交叉糾錯。三款產品共同表明，多智能體已經能夠承擔研究流程中的具體工序，而成果質量仍要落實到讀者結合自己的專業水平進一步優化。對比 WorkBuddy 和 Qoder，Grok Bot 展現出產品形態的另一面，把智能體放進了一套持續運行的雲環境，這樣一來，Bot 可以跨會話保留材料，也能接著同伴的工作往下做。

相應地，長期任務能否在故障後恢復、共享資料如何控制訪問、每項任務消耗多少資源，都成為產品能力的一部分。此外，交互方式也在變化。Grok bot 把具名 Bot、工作狀態、例行任務和交付物放到同一個界面；用戶可以看見誰在處理任務，並在需要判斷時接手。同時，通過 “Grok 報告新增五篇論文，生成郵件草稿，把發送動作留給用戶確認”這一片段，Grok 能根據此前設置過的賬號和檢索任務，來“主動發現工作”。這是一項非常有趣且有用的能力，不過，未來衡量主動提議能力，還要看建議是否切中需求、是否頻繁打斷用戶，以及哪些動作必須停下來等待授權。

馬斯克近期在 X 上提出，Grok Bot 今後會按任務選用包括第三方服務在內的後端模型。這也可能意味著產業將進一步細分，模型研發與智能體產品研發的分工將更清晰，兩類團隊也仍會向彼此的領域延伸，從智能體產品角度來看，決定產品競爭力的，是這套流程能否穩定交付，並讓用戶看清數據流向、任務成本和結果依據。因此，三款產品顯著的不同在於 Grok Bot 已把雲端常駐、跨會話接力和主動提議帶進同一工作環境，三款產品仍各有成稿缺口，說明檢索、核查與審稿的成果還需要準確進入最終文件。

隨著模型和 Bot 可以按任務組合，產品競爭將越來越取決於這條鏈路能否持續運轉：任務中斷後接得上，關鍵決策由用戶把關，過程與成本查得到，成品經得起專業複核。點擊 關鍵詞 查看對應實測內容AI 產品評測 AgnesCode丨飛豬 AIWorkBuddy更多 AI 產品評測多模態評測vivago R1Seedance 2.5 vs 可靈 3.0Minimax H3 vs Seedance 2.0 Fast更多多模態評測基模評測Qwen3.8-27B丨GLM 5.3GPT‑6 Astra、Fable 5.

1 和 Sol更多基模評測上車，帶你看遍全球 AI 頂會精華可獨家暢覽：專家演講PPT大會報告全文熱門論文解讀學術新星訪談掃描上方二維碼或點擊「閱讀原文」關注專區。未經「AI科技評論」授權，嚴禁以任何方式在網頁、論壇、社區進行轉載！公眾號轉載請先在「AI科技評論」後臺留言取得授權，轉載時需標註來源並插入本公眾號名片。