| 指標 | 數值 | 說明 |
|---|---|---|
| Agent 在 EvoArena 平均準確率 | 39.6% | 涵蓋 terminal、software、social 三域演化任務，現有 Agent 普遍不及格 |
| EvoMem GAIA 提升 | +6.1% | 超出動態基準，連靜態基準 GAIA 也受益——記憶演化機制具通用性 |
| EvoMem LoCoMo 提升 | +4.8% | 長期對話記憶任務中，patch-based 記憶追蹤勝過傳統檢索式記憶 |
| EvoMem 鏈級準確率提升 | +3.7% | 連續演化子任務（chain-level）：完成整個演化序列才算成功 |
| EvoMem 證據捕捉改善 | 顯著 | 機制分析：EvoMem 保留更完整的演化環境狀態，非局部摘要 |
將現有 Harbor 相容基準（terminal、software、social）轉化為「演化鏈」——每個任務是序列中的一步，環境狀態隨步驟改變（API 變更、軟體版本更新、社交偏好漂移）。Agent 必須在每一步更新自己的知識和行為。
核心創新：將記憶變更記錄為「patch」（類似 git diff），而非完整快照。儲存的是「從狀態 A 到狀態 B 的 delta」。Agent 推理時不只查當前記憶，還能追溯「為什麼變成這樣」的演化歷史。
傳統基準只看單步成敗；EvoArena 要求 Agent 完成整個演化子任務序列才算成功。這捕捉了 Agent 的「持續適應力」——即使單步答對，若無法在後續步驟中根據演化更新行為，整條鏈仍算失敗。
機制分析顯示 EvoMem 的核心改善來自於「保留更完整的演化環境狀態」——不是選擇性摘要，而是結構化的變更記錄。這讓 Agent 能追溯推理鏈的完整性。
EvoArena 框架可直接應用於 CI/CD 管線中的 Agent 健康檢查：不只測「現在會不會答」，而是測「環境改了之後能不能跟上」。每次 API 變更、套件升級後，跑一次演化鏈測試。
EvoMem 的 patch-based 方法對 Hermes/DKY 有直接啟發：skill 系統目前每次覆蓋式更新，沒有版本歷史。若改為 patch-based（記錄每次 skill 修改的 diff + 原因），Agent 就能追溯「為什麼加了這個規則」，在出錯時回滾到特定版本。
目前 Agent 評測假設靜態世界；EvoArena 證明這是重大盲點。任何生產級 Agent 部署前都應該經過動態環境壓力測試——API deprecated、工具失效、使用者偏好改變——而不只是 MMLU/SWE-bench 靜態分數。
這篇論文之所以重要，不是因為 EvoMem 的 +1.5% 提升（老實說不大），而是因為它揭露了目前 Agent 評估的根本盲點：所有基準都假設世界是靜態的，但真實世界（和真實使用者）每天都在變。39.6% 的準確率是警鐘——我們在實驗室裡測到的「90% SWE-bench」可能毫無意義，因為部署後的第一週軟體套件就升級了。
對 Hermes 的直接啟發是：目前的驗證流程（curl 200 + SPA fallback + MD5）也是靜態快照。EvoArena 的演化鏈概念暗示——我們該加入「動態驗證鏈」：不只確認首頁正常，而是確認「改完 sidebar → 部署 → 確認所有內部連結 → 確認 GitHub 同步 → 確認 CF Pages 未退化」。每一步都以前一步的結果為前提。
更具野心的是 EvoMem 的 patch-based 記憶。如果把 Hermes 的 skill 檔案管理從「覆蓋式」改為「git-patch 式」（記錄每個 skill 的變更歷史 + 變更原因），當某個 skill 行為退化時，Agent 能追溯「我第 3 次修改時加了這個規則，目的為了修正 X bug，但副作用是破壞 Y」——這比現在「發現壞了就重寫」聰明得多。