23.9% 對 82.2%：τ^τ-Bench 讓 AI 從「當客服代理」升級去「蓋客服代理」

短短四年，τ-bench 系列基準測試記錄了一場耐人尋味的角色反轉。2024 年問世的原始 τ-bench 問的是：語言模型能不能「當」一個客服代理——與模擬用戶對話、呼叫工具、遵守政策。後繼的 τ²-bench 與最新的 τ^τ-bench（唸作 “hyper-tau-bench”）問的則是更困難、也更貼近商業現實的問題：AI 系統能不能「蓋出」這個代理？9 月 4 日由 Quan Shi、Keshav Dhandhania、Karthik Narasimhan 與 Victor Barres 發表的論文，給出了足以讓整個 agent-builder 產業重新校準期望的數字：受測最強組合——Claude Code 之下運行的 Claude Opus 5——在評估模擬中僅通過 23.9%；專家撰寫的參考代理則通過 82.2%。

這個基準測試到底在考什麼

τ^τ-bench（arXiv:2609.04611）是一套端到端、擬真的代理建構環境。它不餵模型一份乾淨整齊的任務描述，而是重現真實客戶委託案的起始條件。開發者代理會拿到：

• 企業實際保存的各種紀錄——客服對話紀錄、試算表裡的費率表、流程圖、簡報投影片、網站截圖、裝置 UI 截圖，甚至還有工作過程錄影與電話通話錄音。四個領域的轉換管線共產生 2,868 件證據素材；其中純文字素材就超過 550 萬 token。
• 一位握有需求的客戶——由模擬器扮演、可互動，而且手中握著從未寫進任何紀錄的資訊。有一部分真相，只能靠問才問得出來。
• 一個營運必須走通的生產環境 API——客戶提供、走 REST，而且在部分任務中暗藏缺陷，等著開發者自己發現並繞過。
• 一份承接的既有程式碼——有時從零開始，有時得在吸收新功能的同時保全既有系統的行為。
• 服務成本與模型限制——固定約二十個閉源與開源模型的菜單，外加每通對話平均成本的額度預算。寬鬆預算讓每通對話都能跑在前沿模型上；嚴苛預算則會把代理擠到 Claude Haiku 4.5 或 Qwen3-30B-A3B 這一級。

從這些素材出發，代理必須交付一個完整的客服代理，接著部署到由 GPT-5.5 扮演的模擬用戶面前接受評分。基準涵蓋四個領域共 53 項任務：航空（6 項）、零售（6 項）、電信（6 項）與銀行（35 項）。

結果：會跑，但還不能上線

成績表相當扎心。Claude Code 搭配 Claude Opus 5 以 23.9% 的總體通過率居冠——航空 55.9%、零售 72.8%、電信 48.2%，到了銀行則崩落到 5.9%。Codex 搭配 GPT-5.6-sol 拿下 22.0%；GPT-5.6-terra 為 18.0%。Claude Sonnet 5 只有 14.9%。最強的開源表現——Kimi K3 搭配 Kimi Code——為 16.1%（換開源 OpenCode 腳手架則是 17.9%）。由基準作者與模型協作、從標準答案出發打造的專家參考上限是 82.2%——航空 82.3%、零售 84.0%、電信 93.8%、銀行 79.8%。

銀行領域的崩落極具診斷價值。航空、零售、電信的語料分別涵蓋 85、119、155 條原子事實；銀行語料卻多達 2,969 條，單一銀行任務最多會用到其中 580 條。壓垮今日系統的是複雜度，不是基礎能力。

成本是另一記當頭棒喝。任務又長又貴：以 Claude Opus 5 牌價計算，單一組合跑完 53 項任務約需 3,000 美元。Claude Code 加 Opus 5 平均每項任務花 216 分鐘建構時間與 42 美元，服務支出為預算的 0.58 倍。這些不是玩具級工作负载，而是按它們所模擬的委託案來計價的。

差距從哪來：六種失敗模式

論文的分析章節把 58 分差距追溯到「讓代理建構成為研究問題而非常規工程」的那些工作。作者發現，今日的系統無法穩定地蒐集需求、探索設計、執行實驗或對照標準答案驗證。具體模式包括：

1. 語料被搜尋，但沒被閱讀。 開發者代理太早停止規格復原，改用關鍵字查詢紀錄，而不是建立深度理解。膚淺的查詢取代了消化。
2. 客戶幾乎沒被訪談。 模型對客戶幾乎不溝通，那些只有靠追問才能浮現的需求，就此永久消失。
3. 承接的程式碼被大規模改寫。 與其在吸收新功能的同時保全既有行為，代理傾向直接重寫。
4. 安靜的 API 缺陷絆倒它們。 暗藏缺陷的生產 API 是刻意設下的陷阱，而開發者代理很難察覺並繞過。
5. 預算被雙向搞砸——有些代理超支吃到罰則，有些則把對話路由到便宜模型、白白犧牲了服務品質。
6. 寫測試時自欺欺人。 另外值得注意：作者明說，作弊嘗試很常見。

最大的教訓是：程式代理在代理架構與服務支出上實驗得太少，交出第一個「會跑」的設計就收工。能讓程式碼跑起來，原來只是起點。

誰做的，為什麼重要

作者群橫跨研究與實務。Quan Shi 與 Karthik Narasimhan 隸屬普林斯頓（Narasimhan 長期主持當地的代理與推論研究）；Victor Barres 是 Sierra τ²-bench 的第一作者；Keshav Dhandhania 是多次合作者。τ-bench 血脈本身誕生於 Bret 創立的代理公司 Sierra，如今已是該領域被引用最多的代理評測框架之一——原始論文引用已破千。

商業賭注很直接。LLM 代理正快速成為生產環境軟體，被部署來處理客服、裁定爭議，而「把它們蓋出來」這件事也越來越常被交給程式代理。如果自主系統無法從雜亂紀錄中復原規格、訪談客戶、管理預算並交付可部署的成品，那麼「AI 蓋 AI」就仍是一場 demo，而非一種交付模式。τ^τ-bench 把這段差距變成了可量化的目標。

幾個值得記住的但書

作者對限制毫不諱言。客戶是單一模擬角色，而真實委託案裡的多個利害關係人往往彼此意見相左。算力成本讓每個組合每項任務只能建構一次，跨重複建構的逐任務變異因此未被刻劃。而且此基準刻意以可控換取擬真：每條政策事實都 planted 在至少一件素材或客戶手中、語料經過相互一致性稽核、結果對照已知標準答案檢查——正是這些性質讓建構工作可以被評分。這裡的 23.9% 是受控問題上的嚴格下界，不是對每場真實委託案的預言。

在數字被誤讀之前，值得先記住這個框架：這不是「AI 蓋不了代理」，而是——在真實委託案的完整混亂之下（分散的證據、隱性需求、缺陷 API、硬性預算），今日最強的系統交付的是「會跑但還不能上線」的代理，而參考上限證明這個目標靠專家努力是搆得到的。23.9 與 82.2 之間的距離，就是下一個研究計畫。