介面也是模型的一部分

假設你請兩位助手修改一條客戶記錄。一位拿到瀏覽器、滑鼠和密碼，另一位拿到一個叫“更新客戶”的函數。第二位先完成。你找到的是更聰明的助手，還是給了其中一位一條更短的走廊？

H Company在9月28日發佈Holo4，讓這個問題有了現實參照。公司介紹，模型能通過圖形界面、代碼、MCP和API工作；其比較說明也承認，不同結果使用的基準版本、任務子集與運行框架存在差異。這份發佈材料值得用來觀察完整工作系統，但我們並沒有因此獲得一場自己完成的受控實驗。Holo4 release

我的判斷很簡單：介面應該放進評測範圍。買智能體，買的是完成工作的方法，模型只是其中一部分。它看得見什麼、能做什麼，以及我們怎樣判定任務完成，都可能在第一個token生成之前改變結果。

更短的走廊，也可以很值錢

回到那條假想的客戶記錄。瀏覽器助手先搜索姓名，打開檔案，找到編輯按鈕，修改字段，再保存。函數助手只需提交標識符與新值。兩者最終可能留下完全相同的記錄。即使推理能力一樣，工作量的差別也可能產生商業價值。

只要函數確實可用、已獲授權而且可靠，企業就應該歡迎這項節省。為了讓比賽看起來公平，強迫所有任務都用滑鼠完成，經營上未必合理。採購測試應反映買家真正能運行的環境。集成做得更好，本來就可以成為產品優勢。

問題出在結論被悄悄放大。“這個配置在測試中更便宜地完成了我們的流程”，可以由合適的實驗支持。“這個模型的推理能力更強”，卻需要另一種比較。介面可能直接減少了幾個犯錯機會。這個系統優勢，應當說清楚來自哪裏。

因此有兩個值得分別回答的問題：這項工作應該用哪個完整產品？改善究竟來自哪個組件？前者幫助部署，後者指導工程，也幫助判斷換了客戶、少了一個集成，或應用改版以後，優勢還能不能保留。

相同畫面，可能藏着不同信息

即使比較的都是瀏覽器，也不能只展示兩張相同窗口的截圖。一位助手可能只能看像素，另一位還能讀到頁面的無障礙結構，包括標籤與角色；第三位可能直接檢索已存記錄。看似使用同一個應用，得到的狀態證據卻不同。

設想一項發票任務：參考編號被窄表格截斷了。人可以把列拉寬，讀取結構化文本的助手可能早已拿到完整編號。視覺助手要先發現並完成一個額外動作，結構化助手卻從一開始就知道這個局部答案。前者失敗，既可能反映模型問題，也可能反映觀察通道的差異。

BrowserGym為受支持的瀏覽器基準提供共同研究環境，提醒我們：環境本身可以被明確描述、拿來比較。但兩個實驗都使用同一個庫，並不自動意味着實驗條件相等。BrowserGym

我建議的評測卡，會把觀察通道放在模型名稱旁邊。截圖、無障礙文本、工具返回值和文件，都要寫清楚。一種配置若能看到更多信息，產品比較應保留並標明這個優勢；研究因果時，則應在實驗允許的範圍內，讓兩邊獲得相同的相關證據。

一次工具調用，可能包辦一串工作

一次點擊和一次API調用都很好計數，實際工作量卻可能差得很遠。點擊可能只是打開菜單，一個工具調用卻可能同時校驗客戶、修改多個字段，再返回結構化確認。業務動作切分方式一變，步驟預算的含義也變了。

假設一個虛構評測給每位助手十步。擁有“大工具”的助手可能在預算內完成，另一位還沒走完導航就超時。這完全可能符合比賽規則，卻不適合拿來證明雙方完成底層業務工作的機會相同。

我會保留動作數，因為它能解釋執行軌跡；同時也記錄耗時、模型用量、工具費用與人工注意力。買家需要總賬單，以及能看懂的失敗路徑。工程師則需要分清：成本來自反覆推理，還是介面選錯了。

小公司可能在這裏找到機會。對重複任務，改善介面或許比更換模型更有用。這需要在具體流程中檢驗，也要計入維護與集成成本。它不等於API總會獲勝。脆弱的集成，能把短走廊變成鎖死的門。

完成，要有自己的一列

一項差點完成的任務，在回放裏也會很好看：報告已起草，客戶找對了，最後一個字段也正確。隨後助手卻保存了錯誤版本，或根本沒有提交。算不算成功，取決於驗收規則；大家看到分數之前，就應該看見這條規則。

OSWorld 2.0在評測界面中區分部分得分與二元完成。這個區分很有用：長流程推進了多少，與要求的結果是否完成，是兩個問題。這裏引用的是方法背景，沒有把其中歷史模型的分數拿來充當今天的排名。OSWorld 2.0

在假想的客戶任務中，完成可以要求：記錄選對、修改符合請求、沒有越權編輯，而且最終狀態可獨立讀取。一句友好的“已完成”，只能證明助手這樣報告過。它必須與應用裏的實際狀態一致，任務才能通過。

部分得分仍有價值。它能指出失敗發生在找記錄、理解指令，還是執行最後一步。把這些診斷結果放在最終驗收率旁邊即可。否則，調試指標很容易悄悄變成經濟性承諾，而剩下的工作還得由買家完成。

公開任務與隱藏任務，是不同樣本

另一種比較誤差更安靜。兩份報告可以用同一個基準名稱，卻運行不同任務集。公開集合供開發使用，保留的隱藏集合用來檢驗泛化。兩邊都可能設計嚴謹，但分數來自不同樣本。

AutomationBench明確區分公開任務集與官方排行榜使用的私有任務集，並提示本地分數不一定與官方分數直接一致。因此，抄下基準名稱還不夠，任務集標籤也要留下。AutomationBench

想象兩位考生在不同城市考駕照。一條路線有複雜路口，另一條有施工和臨時路牌。只看百分比，無法知道兩人跑同一條路線時誰更好。下一步應該是匹配條件後比較，或者把結論收窄到現有證據真正支持的範圍。

買家可以用公開基準篩選候選產品，最終選擇則應更依賴少量、有代表性、已獲授權的自身任務。配置決定完成後，保留一部分案例用於正式評估。如果每個不滿意的案例都變成繼續調參的機會，測試就會慢慢變成排練。

模型沒動，評卷尺也可能變好

評測規則既是軟體，也是規格。它可能包含含糊指令、過於寬鬆的檢查，或每次運行都會變化的環境依賴。修正這些問題，即使模型和行為不變，也可能改變分數。因此，評分器版本也屬於證據。

WebArena-Verified介紹了經過審核的任務，以及根據智能體回答和網絡軌跡進行的確定性評估。這是改進測量工具本身的具體例子。但它的文檔並不替所有客戶流程背書，也不免除我們核對某個評分器到底接受什麼結果的責任。WebArena-Verified

例如，客戶記錄評分器若只檢查目標字段，就可能漏掉助手誤改的第二條記錄。增加“其他記錄保持不變”的檢查，測試便嚴格了。新規則下分數下降，可能只是暴露了原本就存在的問題，不能說智能突然退步。

我會把評分器修訂號、初始狀態與期望終態一併保存。規則改變後，重跑相關比較，或明確註明舊結果適用舊規則。這點記錄工作，總比解釋昨天的冠軍為何通不過今天的普通驗收省事。

給比較安排兩條路線

最有用的評測，我認為應該分兩路。第一路比較真實使用時的完整配置。在相同業務授權下，允許各產品使用自己支持的介面，計入集成、運行與審閱成本。這回答買家的問題：對於明確的一組工作，現成系統哪個更合適？

第二路一次只改一個組件。固定模型，改變介面；再固定介面，改變模型。讓初始數據、任務說明、驗收規則與資源限制足夠穩定，才能解釋差異。這回答建設者的問題：增益究竟來自哪裏？

作者設計的概念比較框架。圖中是擬議評測方案，沒有報告模型實驗或已測得的改善。

混合介面系統還多了一個有趣問題：每個子任務該走哪條路？選擇本身有成本，也可能出錯。產品知道正確函數後，API調用或許十分熟練，卻未必知道什麼時候必須改走圖形界面。應把路線選擇與切換保留在執行軌跡裏，不能當作看不見的後臺管道。

各種限制的意義應儘量可比，即使單位無法完全一致。相同金額、相同時間和相同步數，是三種不同約束。先選適合研究問題的約束，運行前說明，再把其他量放在旁邊。不能看見偏愛的候選產品失敗後，只替它放寬預算。

給完整結果算一筆小賬

下面的數字完全是假設。配置A嘗試十項任務，共花20美元，產出八個通過驗收的結果。配置B也嘗試十項，共花12美元，產出四個合格結果。暫不計集成和審閱，每個合格結果的成本分別是2.50美元與3.00美元，計算就是20除以8、12除以4。

這個例子裏，總嘗試費用較低，平均每個合格結果反而更貴。這沒有測量Holo4或任何產品，只解釋分母為什麼重要。如果沒有結果通過驗收，就報告這個事實，不能替換掉不存在的有效分母，編出有限的成功成本。

再假設A需要昂貴集成，而B的流程由負責人花幾分鐘便能維護，實際選擇又可能改變。固定成本應攤到現實的使用量和生命週期上，人工審閱也要給出明確成本假設。現金支出與估算勞動成本應分別列示，方便讀者代入自己的情況重算。

這筆賬裏沒有藏着一個普遍最便宜的智能體。它只能識別在特定工作量、期限和驗收條件下可能划算的配置。結論範圍較窄，卻更適合真正要付賬的人。

第一個實驗，應該一頁紙講完

我建議的下一步，是一項尚未執行、只用合成客戶記錄的驗收練習。固定一小組修改任務，包括重名、記錄缺失，以及禁止修改的字段；向同一個模擬狀態開放兩種已授權介面。兩條路線都不接觸真實客戶，也不發送消息。

選贏家之前先定義成功。要求的修改必須正確，受保護字段保持原樣，最終記錄接受獨立檢查。對於刻意設置為無法完成或有歧義的案例，恰當拒絕或澄清應算通過。自信地改錯賬戶，應比指出缺失信息得到更差的評價。

完整產品比較與受控組件比較分開進行，失敗軌跡也保留；記錄費用、耗時、介入與驗收。案例和運行次數要足以判斷表面優勢是否只來自一次走運，並與結果一起公佈侷限。這篇文章提出這項工作，沒有聲稱已經執行。

後續監測規則也很小：模型、介面、工作類型或評分器發生實質變化時，再審視選擇。一個新連接器可能和一個新模型同樣重要；移除一項權限，可能使舊性能判斷失效；客戶任務變了，舊贏家也可能不再適用，卻不代表它做原來那件事變差了。

短走廊盡頭的助手，完全可能就是值得僱用的那一位。只要寫清楚，走廊是誰縮短的。一場有說服力的演示，纔會成為別人能用的結果。

分類與關鍵詞

分類：智能體基礎設施；企業軟體；評測。

關鍵詞：計算機操作智能體、介面選擇、匹配評測、完成標準、每個合格結果的成本。

標籤： #AgentInfrastructure #ComputerUse #Evaluation #IAmRobin