回到原本的研究主線，我還是想先回答一個問題：

Agent Demo 跑成功一次不難，但我們到底要用什麼證據，證明它真的有把事情做好？

如果只是一般問答模型，評估方式相對直覺。

例如問：

台灣的首都是哪裡？

模型回答：

台北。

接著比對答案就好了。

但 Agent 不太一樣。

假設使用者說：

航班取消了，我想改成明天下午。

最後 Agent 回覆：

已幫你完成改票。

光看這句話，幾乎什麼都判斷不了。

真正需要確認的反而是：

它有沒有找到正確 booking？

有沒有查到真的可以改的航班？

有沒有套用正確的票務規則？

缺少資料時有沒有詢問？

需要旅客確認時有沒有先停下來？

Tool 到底有沒有成功？

最後 booking state 真的改了嗎？

所以 Agent Evaluation 和一般 LLM Evaluation 最大的差異之一，是：

評估對象不再只是最後生成的文字，而是 Agent 在環境裡完成任務的整段行為。

這也是我在開始拆不同 Agent Repo 前，先讀 A Survey on Evaluation of LLM-based Agents 的原因。

這篇論文刊登於 Findings of ACL 2026，整理了 Agent Evaluation 的五個主要 perspective，包括核心 Agent 能力、不同應用場景的評估、Generalist Agent、Benchmark 的核心設計面向，以及開發者使用的 Evaluation Framework。

Agent 到底要評什麼？

Survey 整理了五個 perspective，但對我接下來的 Repo 分析而言，我覺得最值得先留下來的其實是三件事。

1. Agent 的「能力」不是一個東西

Survey 把 Core Agent Capabilities 拆成幾個不同問題：

Planning & Multi-Step Reasoning

Function Calling & Tool Use

Self-Reflection

Memory

這個拆法看起來很學術，但其實非常實用。

例如一個 Agent 不斷問：

你想改哪一天？

使用者回答：

明天下午。

下一輪 Agent 又問：

請問你想改哪一天？

從使用者角度看，就是：

Agent 鬼打牆。

但如果真的開始 Debug，原因可能完全不同：

Conversation history 沒送進去

Structured state 沒保存

Memory 沒有 retrieval

已知欄位沒有重新放進 context

Tool 回傳結果沒有寫回 state

模型選錯下一步

表面上都是「記不起來」。

Architecture Layer 卻可能完全不同。

因此看到某個 Repo 寫：

Support Memory

還要繼續問：

它指的是 Conversation History？

Session State？

Persistent Memory？

Retrieval？

還是某種 User Profile？

同一個功能名稱，可能代表完全不同的系統責任。

這也是後面拆 Repo 時，很容易遇到的一件事。

2. 不同 Agent，失敗的定義本來就不一樣

Survey 另外把 Application-Specific Agent Evaluation 分開討論。

例如：

Web Agent

Software Engineering Agent

Scientific Agent

Conversational Agent

這件事情提醒我：

不能因為兩個系統都叫 Agent，就假設同一套 Benchmark 可以直接比較。

Coding Agent 常見的環境可能是：

Repository
+
Filesystem
+
Shell
+
Compiler
+
Tests

它很自然可以問：

程式有沒有成功修改？

Test 有沒有通過？

Build 有沒有成功？

但 Modified Flight 這種客服 Agent，環境可能變成：

Multi-turn Conversation
+
Business Policy
+
Booking Database
+
Transactional API
+
User Cooperation

它的失敗可能是：

修改錯 Booking

少問一個必要資訊

違反票務規則

沒有向旅客揭露費用

沒有取得確認就修改資料

使用者改變需求後仍照舊流程執行

兩種 Agent 都可能具有：

Planning
Tool Use
Memory

但「做對」的定義完全不同。

所以看到某個 Agent Benchmark 分數很高，我現在第一個問題不會是：

這個模型是不是很強？

而是：

這個 Benchmark 到底把什麼定義成成功？

3. Benchmark 不能只看一個 Score

Survey 在討論 Agent Benchmark 時，不只是看最後的分數，還會看幾個不同面向。

第一個是 Environment，也就是 Agent 到底在什麼環境裡完成任務。

一般模型可能只是：

Input
→ Model
→ Output

但 Agent 通常還會操作：

Browser
Database
Filesystem
API
Simulation

因此評估時不能只看 Agent 最後說：

已經完成了。

還要確認：

實際上的資料或系統狀態，真的有被改對嗎？

第二個是 Metric，也就是「怎樣才算成功」。

有些 Benchmark 只看 Final Answer，但 Agent Benchmark 可能還會檢查：

Environment State
Tool Action
Communication
Database

τ²-bench 就是很好的例子。

它會描述任務最後應該滿足哪些條件，但不代表 Agent 一定要照著唯一一條固定路徑完成。

例如：

Agent A
查訂位 → 查航班 → 確認 → 修改

Agent B
查訂位 → 確認需求 → 查航班 → 修改

兩個 Agent 的步驟可能不同，只要必要規則都有遵守，而且最後結果正確，就不一定要因為 Tool Call 順序不同而判錯。

這也讓我開始區分兩件事：

Correctness
→ 最後事情有沒有做對？

Debuggability
→ 如果做錯了，能不能知道錯在哪一步？

第三個是 Safety。

Agent 的錯誤並不是每一種都一樣嚴重。

例如：

少說一句禮貌用語

跟：

沒有取得旅客確認，就直接修改機票

顯然不是同一個等級的問題。

當 Agent 開始可以呼叫 API、修改資料之後，Safety 評估就還要確認：

有沒有做不該做的動作？

有沒有越權？

該確認時有沒有先確認？

不確定時有沒有停下來？

有沒有造成不應該發生的修改？

所以看 Agent Benchmark 時，我現在不會只看最後那個 Score。

我會再往下看三件事：

Environment
→ 它在哪裡完成任務？

Metric
→ 怎樣才算真的成功？

Safety
→ 哪些錯誤是不能接受的？

Benchmark 告訴我「失敗了」，Trace 才可能告訴我「哪裡失敗」

假設現在有兩個 Agent：

Agent A
Task Success = 82%

Agent B
Task Success = 78%

只看這兩個數字，我其實只能知道：

A 多成功了一些 Task。

但我要改系統時，這個資訊還遠遠不夠。

例如那 18% Failure 到底發生在哪裡？

選錯 Tool？

Tool Argument 錯？

Policy 沒有進 Context？

API Call 失敗？

Tool 成功但 State 沒保存？

Agent 沒讀 Tool Result？

該停下來問人卻繼續？

最後回答和實際 Environment 不一致？

這時就需要 Trace / Observability。

所以我目前會把兩者簡單區分成：

Benchmark
→ 有沒有完成？

Trace
→ 它怎麼完成？
→ 如果失敗，失敗在哪？

這篇先停在這個區別就好。

後面還有專門談 Observability 的一天，再處理 Trace 要怎麼收、怎麼分析，以及 LangSmith、OpenLIT 這類工具到底解決什麼問題。

結論：Agent Evaluation 不只是問「最後答對了嗎？」

讀完這篇 Survey 後，我覺得最值得帶到後面的不是某一個 Benchmark 名稱。

而是幾個很基本的區別。

一般 LLM Evaluation 很容易讓人想到：

Input
 ↓
Output
 ↓
Correct / Wrong

但 Agent 更接近：

Task
 ↓
Agent + Environment
 ↓
Trajectory
 ↓
Environment Outcome
 ↓
Communication / Safety
 ↓
Evaluation

所以：

Agent 的最後回答，只是整個任務留下來的一個結果。

如果它說：

已經幫你完成改票。

我真正想知道的是：

事情真的完成了嗎？

資料真的改對了嗎？

該告知的資訊有沒有告知？

過程中有沒有做不該做的事？

如果失敗，我能不能知道它失敗在哪？

下一篇開始，終於真的進 Repo。

先從 anthropics/oncall-kit 開始。

它本身不是另一套全新的 Agent Runtime，卻把 Skill、Playbook、Human Gate、Replay 與真實 On-call 工作流程放在一起。

剛好可以拿來看看：

當「Agent 要遵守工作流程」不再只是一句 Prompt 時，Repo 裡到底會出現哪些東西？

Reference

1. Yehudai et al., A Survey on Evaluation of LLM-based Agents, Findings of ACL 2026
   https://aclanthology.org/2026.findings-acl.1330/

2. Sierra Research, τ²-bench
   https://github.com/sierra-research/tau2-bench

3. 2026 Cathay Technology Conference
   https://www.cathaytechcon.com.tw/2026CTC/