τ²-bench / τ³-bench：把客服代理放進可重現的多輪對話裡評分
τ-Bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains
秒懂
- 它是什麼？
- 這是一套用模擬使用者與工具呼叫來評測客服型 LLM 代理的框架，涵蓋 airline、retail、telecom、banking_knowledge 等領域，並在 1.0.1 版針對 banking_knowledge 的評分邏輯做了修正。它的價值在於把「代理有沒有照政策做完事」變成可重跑的程式，代價是你得接受領域與版本綁定。
- 適合誰用？
- 如果你要評測的是「代理能不能在多輪對話中依政策呼叫工具完成任務」，而且願意把模型與版本一起寫進報告，tau2-bench 值得裝起來跑；如果你要的是單輪問答準確率、或想拿它當訓練環境，先確認 gym extra 與 task split 是否符合需求。動手前先驗證三件事：banking_knowledge 的分數是否來自 1.0.1 之後的版本、你比對的舊結果是用哪個 split 產生的、以及語音模式所需的 portaudio 與 ffmpeg 是否已在環境中就緒。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 4 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解決的是「代理照不照政策做事」，不是答得對不對
多數 LLM 評測把輸入輸出當成一問一答，但客服場景的失敗往往不在單句回答，而在整段流程：該先查訂單卻直接退款、該確認身分卻跳過、該呼叫工具卻口頭承諾。tau2-bench 把這類問題建模成模擬框架，README 的定位是「a simulation framework for evaluating customer service agents across multiple domains」。每個領域由四塊組成：代理必須遵守的 policy、代理可用的 tools、用來評分的 tasks，以及選配的 user tools 給使用者模擬器使用。目標讀者是做代理產品或代理研究的工程團隊，尤其是需要跨模型比較、或需要把評測寫進內部報告的人。它不處理開放式閒聊，也不衡量語氣好壞；評分焦點是任務是否被完成、動作是否正確。
半雙工與全雙工：兩條完全不同的執行路徑
框架支援兩種模式。文字模式是 turn-based 的半雙工對話，代理與使用者模擬器輪流發言，中間穿插工具呼叫。語音模式走 full-duplex，透過 realtime providers 做端到端音訊評測，README 點名 OpenAI、Gemini、xAI 三家。這兩條路徑的相依性差很多：文字模式只要 uv sync 的核心安裝即可，語音模式要加 --extra voice，macOS 上還需要系統層的 portaudio 與 ffmpeg。README 把編排邏輯放在 src/tau2/orchestrator/README.md，並區分 half-duplex 與 full-duplex orchestration。如果你的評測目標是工具選擇與政策遵循，語音模式帶來的變數（延遲、打斷、語音辨識錯誤）會混進分數裡，反而讓歸因變難。
任務與評分：reward_basis 決定什麼算分
README 指向 docs/evaluation.md，說明 evaluation_criteria.actions 的意義、reward_basis 如何 gate 住 reward，以及如何檢查動作正確性。這代表評分不是單一分數，而是由條件組合而成：任務定義了預期的動作序列，reward_basis 決定哪些面向被納入計分。這個設計的實際後果是，同一個模型在不同 reward_basis 下可能得到不同結論，因此對外發布數字時必須把設定一起揭露。另一個容易被忽略的是 task split。README 的相容性說明指出，若你評測的是代理而非訓練，應使用 base split，因為它對應「the complete task set that matches the original τ-bench structure」，而且這是預設值。換 split 就等於換考卷，跨版本比較前要先確認這件事。
裝起來跑第一輪：uv、.env 與 tau2 run
安裝流程在 1.0 之後改用 uv，不再用 pip install -e .，Python 需求是 >=3.12, <3.14。基本步驟是 git clone 專案、cd 進目錄、執行 uv sync 取得核心（文字模式的 airline、retail、telecom、mock）。需要其他能力再疊加：uv sync --extra voice 加入語音與原生音訊功能，uv sync --extra knowledge 加入 banking_knowledge 的檢索管線，uv sync --extra gym 加入 gymnasium 的 RL 介面，uv sync --extra dev 則是 pytest、ruff、pre-commit，貢獻程式碼時必需。API 金鑰走 .env：cp .env.example .env 之後填入，底層用 LiteLLM，因此支援的供應商都能接。跑一輪的最小指令是 tau2 run --domain airline --agent-llm gpt-4.1 --user-llm gpt-4.1 --num-trials 1 --num-tasks 5，結果寫到 data/simulations/，用 tau2 view 瀏覽。不確定有哪些領域與指令時，tau2 intro 會給概觀。
1.0.1 的相容性斷點：banking_knowledge 的分數不能跨版本比
這是採用前最該讀清楚的一段。v1.0.1 的說明直白寫著：這個版本修掉幾個 banking_knowledge 的任務錯誤，該領域分數因此改變，並且「results produced with tau2-bench < 1.0.1 are not comparable with >= 1.0.1」，受影響的排行榜提交已被重新評分。舊的結果檔可以用 tau2 evaluate-trajs --fresh-tasks 重新計分；若你要重現修正前的行為，得把版本釘在 pre-v1.0.1 這個 tag。其他領域不受影響。這種「修任務等於改考卷」的情況在基準專案裡很常見，但 tau2-bench 把它寫進 README 並提供重評指令，態度是清楚的。對使用者的實際要求是：任何跨時間的比較，都要記錄版本號與是否 fresh-tasks。
banking_knowledge：把 RAG 管線也變成被評測的對象
τ³-bench 新增的 knowledge 領域與其他領域性質不同。README 描述它是 knowledge-retrieval-based 的客服領域，具備可配置的 RAG pipelines、文件搜尋、embeddings，以及 agentic shell-based search，細節在 src/tau2/knowledge/README.md。這意味著分數同時受兩個層面影響：代理的檢索決策，以及你設定的檢索管線本身。好處是你可以拿它比較不同檢索策略；風險是當分數變差時，你很難立刻判斷是模型變笨還是索引設定不對。如果你的團隊沒有能力維護文件與嵌入流程，這個領域會比 airline 或 retail 更難駕馭，因為它多了一層需要你自行負責的基礎設施。
任務品質修正與它的方法論來源
v1.0.0 一併處理了 75 個以上的任務修正，內容包括移除錯誤的預期動作、釐清模糊指令、修正不可能達成的限制，以及在 airline、retail、banking 等領域補上缺漏的 fallback 行為。README 說明這些修正基於 SABER（Cuadron et al., 2025）的分析，並連到 taubench.com 的任務修正說明頁。這件事的意義是：先前版本的部分低分，可能來自題目本身的缺陷而非模型能力。任何引用舊版 tau2-bench 數字的內部報告，都應該重新檢視當時的任務集是否包含後續被修正的題目。反過來說，修正任務也讓歷史分數失去連續性，這正是上一節所說的版本斷點。
什麼情況下不該用它，以及替代方案差在哪
tau2-bench 假設任務有明確的政策與可檢查的預期動作。如果你的場景沒有成文政策、成功標準是主觀滿意度、或對話本身是開放式探索，這套評分機制會逼你把模糊的東西硬寫成規則，得到的數字意義有限。另一個限制是領域綁定：目前列出的領域是 mock、airline、retail、telecom、banking_knowledge，要評測自己的業務就得自己寫領域定義。替代方案可以看 SWE-bench 這類以程式碼測試為判準的基準，差異在於它的評分來自單一回合的測試通過與否，不涉及使用者模擬器與多輪政策遵循；tau2-bench 則把對話軌跡與工具呼叫序列當成評分對象，代價是模擬器本身也成了誤差來源。若你的代理是寫程式而非接電話，SWE-bench 的機制更貼近你要驗證的能力。
維護成本、授權與升級時要付的代價
授權是 MIT，條款寬鬆，可商用與修改，但本文不構成法律意見，實際使用前請自行確認條文。維護面上，README 明說從 τ²-bench 升級時安裝方式與 Python 版本都變了，部分內部 API 也經過重構，並指向 CHANGELOG.md。這代表把 tau2-bench 寫進 CI 的團隊，會遇到版本升級連帶修改評測腳本的成本，尤其是自行擴充領域或自訂代理的專案。專案也提示貢獻者需要 uv sync --extra dev 才能跑 pytest 與 pre-commit。整體而言，這是一套仍在演進的基準，版本號與分數的綁定關係比多數工具更緊。
編輯結論
如果你要評測的是「代理能不能在多輪對話中依政策呼叫工具完成任務」，而且願意把模型與版本一起寫進報告，tau2-bench 值得裝起來跑；如果你要的是單輪問答準確率、或想拿它當訓練環境，先確認 gym extra 與 task split 是否符合需求。動手前先驗證三件事：banking_knowledge 的分數是否來自 1.0.1 之後的版本、你比對的舊結果是用哪個 split 產生的、以及語音模式所需的 portaudio 與 ffmpeg 是否已在環境中就緒。
社群筆記