記憶系統該怎麼被驗證？STATE-Bench 給出了一套更有說服力的框架
最近在追 agent memory 的相關研究，看到 Microsoft 開源了 STATE-Bench，讀完之後覺得這個設計思路比我預期的成熟很多，值得好好拆一下。
先說我一直很困惑的事：現在大多數評測記憶系統的 benchmark，測的其實是「retrieval」能力，也就是 agent 能不能在 50 輪對話後還記得使用者說過某件事。這個指標設計本身沒什麼問題，但它沒辦法告訴你記憶系統有沒有讓 agent 真的變得更好用。
STATE-Bench 的出發點就是要填這個缺口。它測的不是「記不記得」，而是「加了記憶之後，任務完成率有沒有提升」。
為什麼要用企業場景？
他們選了三個 domain：客服、旅遊預訂、購物，共 450 個任務。這個選擇不是隨機的，背後有設計邏輯：企業 workflow 的任務有兩個特性特別適合壓測 memory。
第一是 procedural：agent 需要按照固定流程走，比如查預訂狀態、確認用戶資格、計算費用、取得確認才能執行退款。中間少一步，結果就錯。這種任務不靠「記得某個事實」就能成功，靠的是對程序的掌握。
第二是 stateful：這些任務會真的改寫系統狀態，退款就是退款，不能只是「回答正確」。錯誤是有成本的，評測就必須用 deterministic assertion 比對最終狀態，而不是讓 LLM judge 說「嗯差不多對」。
這個設計讓我想起之前做 RAG evaluation 踩的坑，用 LLM 評分很容易對「說話方式對但資訊錯」的回答打高分。STATE-Bench 的 stateful 任務強制讓你面對 ground truth，評測結果才有說服力。
四個維度的指標設計
STATE-Bench 的評測框架拆成四個維度，這個組合我覺得很完整：
1. Task completion rate（pass@1 平均值）
每個任務跑五次，取平均完成率。
2. Agent reliability（pass^5）
五次全部成功才算過。這個指標非常有意思，它測的是穩定性，不是「有沒有可能成功」。現在很多 benchmark 只看 pass@1，但 production 要的是穩定，一個任務只有 60% 成功率，在業務場景幾乎不可用。
3. Agent efficiency（成本）
統計平均 turn 數、不必要的 tool call 次數、input/output token 數。Memory 系統如果有效，理論上應該能讓 agent 更快找到所需資訊、少問重複的問題。
4. User experience score
用 LLM judge 對完整對話打分，分五個子維度，包含使用者付出的努力（user ease）和 agent 在執行前有沒有取得確認（user consent）。
UX 這個維度加進來是我沒預期到的，但加了之後整個框架的完整性就不一樣了。一個任務完成但使用者被問了十個廢問題，和任務完成且使用者只說了三句話，這兩個 agent 在品質上差很多，以前的 benchmark 會覺得它們一樣好。
Baseline 結果說明了什麼？
Microsoft 用 GPT-4.1 跑了無記憶的 baseline，結果是完成率不到 50%，旅遊 domain 的 pass^5 只有約 30%。這意味著有 70% 的任務在五次中至少失敗一次，算是蠻嚴苛的。
這個數字對我來說有點 eye-opening，因為一般大家對 GPT-4.1 的印象應該是很強了，但在這種需要完整遵循程序的任務上還是表現不穩定。
工程與產品的實際用途
對我這種在研究 agent 架構的人來說，STATE-Bench 有一個很吸引人的設計：pluggable memory interface。你可以拿它的環境、任務、user simulator 和評分系統，直接接上你自己的記憶模組，然後比對四個維度的數字。
這讓它從一個 benchmark 變成一個評測平台，你可以問很具體的問題：我的 episodic memory 有沒有讓 pass^5 提升？它讓 turn 數減少了嗎？還是反而因為 retrieval 開銷讓 token 成本變高？
這些問題在以前很難有一套統一的方式回答，現在有了共同的評測框架，至少不同系統之間的比較有了基礎。
對產品團隊來說，四個維度的指標也給了一個更清楚的 tradeoff 語言。如果一個 memory 系統提升了 completion rate 但增加了 cost，要不要用、什麼場景值得用，這就有了可以討論的數字依據。
還沒解決的問題
當然不是說這個 benchmark 就完美了。幾個我覺得還沒解決的地方：
目前只有三個 domain，客服、旅遊、購物有一定的相似性（都是 transaction 類任務），未來如果要延伸到更開放的任務（比如 coding agent、research agent）benchmark 怎麼設計還是個問題。
User simulator 用 LLM 模擬有 1% 的 variance，這個數字看起來小，但如果有些任務本身通過率就在 50% 附近，1% 的 simulator 噪音可能就會造成判斷誤差。
另外 UX 評分是 LLM judge 做的，相對主觀，不同 judge model 之間的一致性目前文章裡沒有深入討論。
但整體來說，STATE-Bench 方向對，而且開源出來，代表社群可以一起改進這些問題。我打算找時間跑一下 baseline，看看自己在研究的幾個 memory 方案在這個框架上表現如何。
作者：陳思維