Sayash Kapoor 為什麼說 AI agent 不能只看成功率？從 benchmark 高分到可靠性評估

Sayash Kapoor 為什麼說 AI agent 不能只看成功率？從 benchmark 高分到可靠性評估

Sayash Kapoor 真正想提醒的，是一個很容易被 AI 展示效果掩蓋的問題：一個 agent 偶爾把任務做完，和它能否穩定、安全、可預期地完成任務，是兩件不同的事。當系統開始替人瀏覽網站、操作軟體、處理文件、發送訊息或串接工作流程，單一成功率只能告訴你它曾經做到過，卻無法告訴你它會怎麼失敗。

Kapoor 與 Arvind Narayanan 等人的研究，將問題從「agent 能不能完成任務」推向更務實的判斷：它是否每次都做得一致？遇到輸入、介面或環境的微小變動會不會崩潰？失敗時是否可被預測、阻止與復原？如果這些問題沒有被測試，再亮眼的 benchmark 成績，也很難替真實工作流程背書。

實體索引｜Sayash Kapoor為什麼說AI agent不能只看成功率？從benchmark高分到可靠性評估

• AI 研究與治理實體：Sayash Kapoor為什麼說AI agent不能只看成功率？從benchmark高分到可靠性評估；核對研究者、模型、資料、benchmark、成功率、可重現性、部署環境與受影響群體。
• 原文錨點：Sayash Kapoor 真正想提醒的，是一個很容易被 AI 展示效果掩蓋的問題：一個 agent 偶爾把任務做完，和它能否穩定、安全、可預期地完成任務，是兩件不同的事。當系統開始替人瀏覽網站、操作軟體、處理文件、發送訊息或串接工作流程，單一成功率只能告訴你它曾經做到過，卻無法告訴你它會怎麼失敗。 編輯插圖：計算、回饋與制度設計如何彼此連動。 Kapoor 與 Arvind Narayanan 等人的研究，將問題從「agent 能不能完成任務」推向更務實的判斷：它是否每次都
• 評估脈絡：把實驗分數、真實任務、誤用、可靠性、公平、資料分布與制度後果分開，說明高分為何不等於可安全使用。
• 編輯界線：區分研究結果、工程限制、政策選擇與推論，不把單一 benchmark 或模型輸出寫成普遍能力。

快速抓住這篇文章

• AI agent 的評估不能只看任務成功率；成本、可重現性、穩定性、魯棒性與錯誤後果同樣重要。
• 不少 agent benchmark 對模型與開發者需求沒有清楚區分，容易讓排行榜上的最佳系統不一定是實務上最適合的系統。
• 若 benchmark 的保留測試不足，agent 可能學會捷徑、過度適應測驗格式，卻在真實環境遇到小變化就失效。
• 可靠性不是「成功或失敗」的二元問題，而是包含一致性、抗干擾能力、失敗可預期性與錯誤嚴重程度。
• 高影響工作不該由平均成功率決定是否自動化；更該看系統出錯時會不會造成不可回復的損失。

背景與核心脈絡

Sayash Kapoor 是研究 AI 評估、agent 基準測試與真實世界可靠性的研究者。他與 Arvind Narayanan 合著《AI Snake Oil》，長期拆解 AI 產業中「展示一次成功，就被推論為可大規模部署」的常見跳躍。

2024 年，Kapoor 與合作者發表〈AI Agents That Matter〉，系統性檢視 agent benchmark 的問題。他們指出，許多評估過度集中於準確率，卻忽略成本；模型開發者與下游使用者的需求被混在一起；保留測試不充分時，系統容易透過捷徑取得高分；評估流程也缺少足夠標準化，導致結果難以重現。

2026 年，Kapoor 與合作者進一步提出「AI agent 可靠性」的評估方向，主張不應只把 agent 壓縮成單一成功分數，而要看它在多次執行中的一致性、對小變化的承受力、失敗能否預期，以及錯誤是否會被控制在可接受範圍。這個脈絡讓 AI agent 的問題不再只是能力競賽，而是工程與治理能否真正承受它進入工作現場。

AI agent的成功率，為什麼不足以代表可靠？

想像一個 agent 可以替你登入後台、整理報表、複製資料、回覆客戶或操作訂單。若它在測試中有八成任務成功，這看起來已經很有吸引力。但如果剩下兩成錯誤剛好發生在刪除檔案、覆寫資料、發送錯誤訊息、修改權限或觸發付款時，平均成功率就完全不足以描述真實風險。

Kapoor 的觀點不是否定成功率，而是要求它回到正確的位置。成功率可以是起點，卻不能是結論。使用者還需要知道：同一個任務連做十次，系統會不會給出一致結果？介面文字、按鈕位置或檔名稍微改變時，它會不會選錯？它失敗時會不會停下來求助，還是繼續執行錯誤步驟？

真正的可靠性，不是系統偶爾表現得像專家，而是它的行為在正常與異常情況下都能被理解、限制與修正。這一點和傳統安全工程的直覺很接近：沒有人會因為一台機器大部分時間正常運轉，就忽略它在關鍵時刻失控的可能。

成功率說明系統曾經做到什麼；可靠性要回答的是，它在不確定環境裡會如何持續做到，或如何安全地失敗。

benchmark高分可能測到的是捷徑，不是實務能力

agent 的發展很依賴 benchmark。研究者把任務設計成可自動評分的測試，系統在這些任務上取得更高成績，就被視為能力進步。這種方法有其價值，因為它能讓不同系統有共同比較基準。

問題在於，任何 benchmark 都有格式、題型、評分規則與固定環境。只要系統反覆針對同一套測驗優化，就可能學會一種不會泛化到真實世界的捷徑。保留測試不足、任務洩漏、環境過於穩定，或評分只關注最後答案，都可能讓一個脆弱系統看起來很強。

這和 Amandalynne Paullada 對 benchmark 的批判相連：測驗不是世界的縮影，而是對世界的一次取樣。它能提供訊號，卻不能替使用者承諾系統在不同資料、不同人群、不同時間與不同制度流程中都會一樣可靠。

因此，Kapoor 的研究主張要區分模型開發者與下游部署者的需求。前者可能需要大規模、低成本、可重複的測試來追蹤技術進步；後者真正想知道的，則是這個 agent 在自己的工作流程裡能否被信任。兩種需求不能被同一張排行榜取代。

成本不是附屬指標，而是部署能力的一部分

若一個 agent 能完成任務，但成本高到無法日常使用，或需要極長時間、過多重試與複雜的人類介入，它的實務價值就會被大幅削弱。Kapoor 與合作者在〈AI Agents That Matter〉中特別指出，單看準確率容易讓研究社群誤以為越複雜的 agent 越好，卻忽略成本與效益之間的關係。

對組織來說，成本不只包括 API 費用或運算資源，也包括監督成本、錯誤回復、人工覆核、權限管理與使用者信任。當一個 agent 需要大量人類在旁邊盯著，它可能仍然有助於加速部分工作，但不應被描述成真正的自動化。

這個判斷很接近 Sarah T. Roberts 對平台勞動的提醒：介面看起來越自動，背後越可能存在被隱藏的人工判斷、例外處理與風險吸收。AI agent 的成本評估若不把這些人算進去，就會高估它的效率。

可靠性要拆開看：一致、抗干擾、可預期與安全

近年的 agent 可靠性研究，將問題拆成多個維度。第一是一致性：相同任務重複執行，結果是否大致相同？第二是抗干擾能力：輸入提示、網頁介面、檔名或任務順序出現微小變化時，系統是否仍能合理運作？

第三是可預期性：當系統要失敗時，是否能在危險操作前顯示不確定、要求確認或交由人類接手？第四是安全性：錯誤的嚴重程度是否被限制？是否有權限分級、操作紀錄、撤銷機制與可回復設計？

這些維度讓人從「它有沒有成功」轉向「它如何成功、如何失敗」。這也是 Deborah Raji 所說的部署問責需要面對的問題：系統若進入真實流程，就不能只在上線前交出一份測試報告，而要有持續監測、回報與調整的能力。

開放世界任務，比封閉測驗更接近AI agent的真實難題

封閉式 benchmark 通常有明確目標、固定工具、可自動評分的答案與有限時間。現實工作卻很少這麼乾淨：需求會改、資料會缺、介面會更新、合作對象會回應、規則會衝突，還可能出現事前沒有預料到的例外。

Kapoor 參與的開放世界評估研究提出，長時間、混亂、需要跨系統協調的任務，必須搭配更細緻的質性觀察與小樣本分析。這不代表封閉測驗沒有價值，而是提醒人們不能把容易量化的任務當成全部能力。

對使用者而言，這帶來一個很實用的判斷：越是需要處理例外、與外部人溝通、修改不可回復資料或代表組織發言的工作，越不能只看產品示範。真正該問的是，它在遇到不完整資訊時會怎麼做？它知道何時該停嗎？

對台灣團隊來說，導入agent應先設計「安全失敗」

台灣公司正在把 agent 用於客服、內部知識庫、資料整理、行銷流程、報表、網站操作與行政自動化。最實際的起點，不是找一個看起來最強的 agent，而是先選擇低風險、可回復、輸出可被人檢查的任務。

一個較穩健的導入流程，至少要先設計五件事：哪些操作永遠需要人工確認；哪些權限不能交給 agent；每一步是否留下操作紀錄；出錯時如何撤銷或回復；系統在不確定時是否會主動停下並交接。這些條件看起來不像炫目的功能，卻決定 agent 能否真正進入日常工作。

對內容團隊尤其如此。讓 agent 協助列題、整理資料、建立初稿與提出檢查清單，通常比讓它直接對外發布、修改正式資料或替品牌回應爭議更可控。把任務切小、把可回復性做大，才是比「全自動」更成熟的策略。

從 Sayash Kapoor 的 agent 評估往下讀，Arvind Narayanan 區分可驗證工具與高風險預測主張，Emily M. Bender 提醒流暢輸出不等於理解，Deborah Raji 則要求測試結果能改變部署決策。三篇一起讀，能讓「agent 會不會做事」轉成更重要的問題：它能否被安全地放進這個流程？

讀者常問

Sayash Kapoor是誰？

Sayash Kapoor 是研究 AI 評估、agent 基準測試與可靠性的研究者。他與 Arvind Narayanan 合著《AI Snake Oil》，並參與多篇關於 agent benchmark、成本、可靠性與真實世界評估的研究。

AI agent和聊天機器人有什麼不同？

聊天機器人主要產生文字回覆；AI agent 則會使用工具、瀏覽網站、操作軟體、串接多步流程或改變外部狀態。因為它可能真的執行操作，所以除了回答正確與否，還要評估權限、確認步驟、可回復性與錯誤後果。

AI agent成功率高，就代表可以自動化嗎？

不一定。還要看同一任務是否能穩定重複完成、介面或提示稍有變化時是否失效、失敗是否可預期、錯誤是否可回復，以及錯誤會不會發生在高影響步驟。成功率是參考點，不是自動化的通行證。

為什麼agent benchmark容易讓人誤判？

benchmark 通常有固定任務、固定環境與可自動評分的答案。系統可能對這套格式過度適應，卻無法處理真實工作中的例外、資料缺失、介面變動與人際溝通。保留測試不足時，排行榜更容易高估可部署能力。

導入AI agent時最先該做什麼？

先從低風險、可回復、輸出可檢查的工作開始，例如整理草稿、比對資料或建立待確認清單。對外發送、付款、帳號權限、正式資料修改與高影響決定，應保留人工確認、操作紀錄、權限限制與緊急停止機制。

收尾

Sayash Kapoor 的價值，在於他把 AI agent 從一場成功率競賽，拉回一個更難也更有用的問題：系統能不能被放心地放進真實世界。

當 agent 開始替人採取行動，真正重要的不只是它能完成多少任務，而是它在不確定時是否知道停下來，以及人是否還保有接手、修正與拒絕的權利。

參考資料

• Sayash Kapoor、Benedikt Stroebl、Zachary S. Siegel、Nitya Nadgir、Arvind Narayanan，〈AI Agents That Matter〉，2024。
• Stephan Rabanser、Sayash Kapoor、Peter Kirgis、Kangheng Liu、Saiteja Utpala、Arvind Narayanan，〈Towards a Science of AI Agent Reliability〉，2026。
• Sayash Kapoor、Peter Kirgis 等，〈Open-World Evaluations for Measuring Frontier AI Capabilities〉，2026。
• Zachary S. Siegel、Sayash Kapoor、Nitya Nadgir、Benedikt Stroebl、Arvind Narayanan，〈CORE-Bench: Fostering the Credibility of Published Research Through a Computational Reproducibility Agent Benchmark〉，2024。
• Arvind Narayanan、Sayash Kapoor，《AI Snake Oil: What Artificial Intelligence Can Do, What It Can’t, and How to Tell the Difference》，Princeton University Press，2024。