測評 AI 這件事，如今越來越難做了。

幾年前，AI 還是聊天機器人時，測評主要就是做題：寫作的、數學的、編程的……最後形成一套跑分，用分數代表模型能力。

但當 AI 從聊天框裏走出來，變成能夠調用工具、操作網頁、處理文件、跨系統執行任務的 Agent，情況就變得複雜起來。

平時我們看到的，是 AI 出現在手機上，能夠刷淘寶、加購物車，最後下單。實際上在商家的那一端，也有 AI 的參與，承擔着比選購和下單更復雜的工作。

在專門考察電商環境中模型表現的 RealReplicaBench 測試中，經過 107 個真實商業任務的考覈，所有參評模型都沒有達到 60 分——都沒有及格。

選手一共 13 位，但連同 GPT、Claude、GLM、Qwen 、Deepseek 和（毫無意外排名最末的）Gemini ，它們當中最高分只有 56.1 分。

以最高分的 Claude Opus 5 為例，在 Accio Work 執行框架中的通過率（66/107） ，要比 OpenClaw 上（60/107）和 PI （65/107）上的通過率更都要高，整體來看 Accio 框架對多數模型的性能增益都更明顯。

執行框架來自阿里旗下Accio Work ，是全球首個聚焦於電商領域的 AI Agent，目標是幫商家在一個 AI 工作台上統一管理、自動操作、快速分析多個平台的店鋪，降低門檻、提升效率，實現生意的增長。

RealReplicaBench 正是脫胎於 Accio Work 的技術團隊，他們觀察到，靠做題是看不出模型解決問題的真實能力的，尤其是在電商中，工作繁瑣而具體：採購要從郵件和報價裏確認信息，發品要處理圖片、價格、物流和後台狀態，經營分析要跨多個平台比對數據……

為了把貨品準確無誤地交到你手上，AI 已經鉚足了勁，卻未必做得夠好，因為真實世界裏的工作，很少是一連串彼此孤立的問題。

看似考做題，實則考「上崗」

如果只看分數，RealReplicaBench 的結果很容易引發誤讀：「怎麼 AI 都不太行」。但摸着良心說，還真不能怪模型們不夠強，這個結果很難簡單歸咎於模型能力——這套「題」，確實難。

傳統 Benchmark 關注答對多少題、完成多少步驟，就獲得對應的分數。類似於考高考，數學最後一道大題不會做，寫個「解」字或把條件抄一下，也能拿點兒分。

可是當 AI 真正進入商業工作流以後，用戶需要的不是一份過程盡力的答卷，而是一項項真正完成、且能夠繼續向下流轉的工作。

對於「完成」的堅持，構成了 Accio Work 團隊技術哲學的核心，這源於他們長期沉浸在電商場景裏形成的判斷，電商工作需要把判斷轉成行動，再讓新的業務狀態成為下一步行動的依據。

供應商有沒有選對，決定後面的採購動作；價格有沒有算對，決定商品能不能正常發布；物流路線是否滿足時限，決定訂艙有沒有實際意義……前面的一次錯誤，可能沿着整個工作流一路傳遞到最後。

因此，重要的不只是某一步「做對了」，更在於每一步的判斷和行動，能不能被完整串起來。

RealReplicaBench 對「完成」的定義也由此變得接近真實交付：一項工作只有在結果能夠被下一環節直接接手時，纔算真正完成。

技術負責人解釋道，「哪怕一個任務已經完成了 80%，如果最後還留下 20% 需要用戶手動處理，而這 20% 恰恰可能是最關鍵的部分，那麼對用戶來說，它依然沒有形成可以直接使用的交付。」

基於這一點，在 RealReplicaBench 的測評中，不存在「將就」；沒有完成，就是 0 分。

如果一定要找一個更直觀的比喻，傳統 Benchmark 更像考交規，科目一，而 RealReplicaBench 更像路考。腦袋裏知道什麼時候該打轉向燈是一回事，真正把車從起點安全開到終點又是另一回事。就算每一次轉向燈都打對了，最後撞車了，也不能稱作是合格的司機。

那麼問題也隨之而來，這種高完成度的表現，究竟要怎麼被做成一套可重複、可驗證的評測 benchmark？

為了測試「真實工作」，先造一個接近真實的世界

任何 Benchmark 都繞不開一個最基礎的問題：它測到的，究竟是不是它想要測的東西。

如果目標是判斷 Agent 能不能完成真實商業任務，那麼只把一個真實需求改寫成幾段文字，再讓模型輸出答案，顯然還不夠。難點往往藏在那些被文字省略掉的地方：頁面狀態會變化，歷史信息和新信息會衝突，系統之間的字段並不統一……

RealReplicaBench 的做法，是儘可能把這些複雜性搬到測試環境中，它不只提供題面，還復刻了前端 UI、瀏覽器操作、CLI、API/MCP、文件系統以及後台狀態，讓 Agent 面對的不是一張紙上的問題，而是一套能夠被真正操作的業務環境。

供應商採購任務就是一個典型例子。Agent 需要從約 300 封高噪聲郵件中還原真實採購需求，還要完成供應商選擇、郵件標籤、回覆草稿和 Kickoff 日曆。它測試的顯然不再是「能否總結郵件」，而是能不能從一堆真實形態的噪聲中還原業務事實，並把這個事實繼續變成行動。

另一個更復雜的任務，則要求 Agent 把 5383 條海關記錄變成一套跨系統採購控制塔。模型要先按品類和供應商聚合數據，再根據採購政策篩選 Top 3 供應商，隨後分別在 Google Workspace、Box 和 Jira 中建立 Dashboard、證據文件夾和項目任務。

這類任務之所以可以作為考題，都在於它們保留了真實工作裏一個很關鍵的特徵：狀態會不斷變化，而 Agent 必須在變化中仍然準確理解上下文，並隨之校準。

前面篩出來的供應商、後面創建的文件夾和 Jira Task，必須屬於同一套業務關係。否則，一個動態 ID 寫錯，後面的交接和審計就可能全部失效。

因此，RealReplicaBench 所測試的，並不是模型在某一個單獨的問題上能達到多高的正確率，這不符合他們的技術哲學，關鍵要看它能不能在複雜環境中持續維持正確狀態，並把一個業務目標真正推進到結束。

用高仿真環境，證明高完成度

把真實環境復刻出來，還只是第一步，真實工作評測還有另一個容易被忽略的問題：模型可以說「任務已經完成」，而用戶卻無法確認，或者確認成本很高。

在聊天機器人中這問題不大，Chatbot 要交付的本來就是文本。可 Agent 不一樣，它的文本輸出只是行動過程中的一部分，因此 RealReplicaBench 的另一個核心設計，是讓 Verifier 直接讀取最終環境狀態，而不是相信 Agent 的自我報告。

例如在物流履約中，Agent 需要為一票從中國到美國的運單枚舉可行路線，把海運、拖車、尾程、保險、清關、Bond 和平台費全部計入，排除超過 30 天或港口銜接不成立的方案，再完成海運段 Booking 和 Shipment Verification。最終的驗證對象不是一段看起來合理的路線建議，而是實際生成的 Shipment ID。

這套邏輯把「完成」的定義從模型的思維鏈中拿出來，交還給環境本身。Listing、Booking、日曆、文件關係、動態 ID，這些真實狀態共同構成了 Agent 是否完成工作的證據。

既然測評不該對一個只有「長得像答案」的答案給分，那麼，每個動作都需要在環境裏留下可以被獨立驗證的後果，這也是為什麼 RealReplicaBench 判分格外嚴格的另一個原因。

Benchmark 背後，是技術實力

為什麼Accio Work 團隊能設計這樣一套 Benchmark？

答案首先來自任務本身。RealReplicaBench 的 107 個任務並不是來自研究者想象中的「電商場景」，而是來自真實商業需求，來自約 160 萬完整對話、20 萬商業執行軌跡和 2000 條高價值工作流，最後通過可復現性與可判定性，收斂成 107 個任務。

供應商採購最後應該留下什麼結果，商品發布什麼時候纔算真正完成，物流任務究竟停在路線建議還是必須產生 Booking，跨系統協作裏哪些對象關係一旦斷掉就無法繼續交接——這些看似屬於評分標準的問題，本身就建立在對真實業務流程的理解之上。

也因此，設計出什麼樣的 Benchmark，往往也會折射出背後的團隊如何理解 Agent。

如果認為 Agent 只是一個更聰明的問答系統，測試自然會圍繞答案質量展開；如果認為 Agent 的價值在於把工作真正推進到結束，那麼測試就必須包含環境、工具、狀態、驗證以及失敗後的歸因。

從這個角度看，RealReplicaBench 表面上是在測試模型，背後實際上也展示了 Accio Work 團隊設計 Agent 的一套方法論：從真實需求定義任務，再復刻工作環境；組織模型與工具完成任務，用環境狀態驗證結果，再根據失敗位置持續優化模型與 Harness。

這也是為什麼這套 Benchmark 對 Accio Work 的意義並不只是一次對外開源。團隊計劃持續加入新的真實任務，讓評測環境滾動更新，並進一步用於模型評測、訓練優化和模型路由。根據不同任務的特點，調度更適合的模型，在效果與成本之間尋找更好的組合。

這樣一套 Benchmark 惠及的不只是電商商家，讓他們能更準確地判斷該選擇什麼模型、什麼 AI 產品；也同樣對整個技術社區有意義。

當 AI 真正開始進入商業工作流，建設 Harness 的能力會逐漸和底層模型本身一樣重要。畢竟，對用戶來說，真正值得付費的從來不是一個「差不多會做」的 Agent，而是一套能夠把工作接過去，並把結果直接交回來的系統。

過去衡量大模型，人們最常問的是它知道多少；後來問題變成了它能不能推理。到了 Agent 時代，評價標準正在繼續向前移動，逐步靠近它到底能不能把事情真正完成。

RealReplicaBench 正在把這個看起來很樸素的問題，變成一套可以重複運行、可以驗證、也可以用於研發迭代的技術標準。Benchmark 測的是模型，最終被檢驗的，其實也是一個技術團隊對「工作如何被 AI 完成」這件事理解得有多深。