核心觀點

一個 AI Agent 曾經完成任務，不代表它下次仍會完成。Hugging Face 與 IBM Research 以 AppWorld 的 ReAct agent（GPT-4.1）為例：重複五次後的平均成功率 Mean@5 為 77.4%，但五次都成功的任務只占 Pass^5 53.0%，相差 24.4 個百分點。這個「一致性缺口」揭示，常見的平均準確率會掩蓋使用者真正遇到的可重現性問題。^[raw/articles/hugging-face-ibm-research-altk-evolve-consistency-2026-09-15.md]

這裡的 Pass^k 不是熟悉的 Pass@k。Pass@k 問「多次嘗試中至少成功一次嗎」，適合可驗證、可重試的任務；Pass^k 問「每一次都成功嗎」，更貼近付款核對、合約義務檢查等不應靠運氣的工作流。因此三者的關係固定為 Pass^k ≤ Mean@k ≤ Pass@k。將它們混為一談，會高估代理在正式環境的可靠程度。^[raw/articles/hugging-face-ibm-research-altk-evolve-consistency-2026-09-15.md]

為何 temperature 0 仍會翻車？

代理每一步都必須決定工具、參數或重試策略。若下一個 token 的機率分布尖銳，微小擾動不會改變選擇；若多個選項機率接近，GPU 浮點運算、請求批次等平台層微差就可能讓結果翻轉。多步軌跡會把每一步的小機率累積成端到端差異，所以即使此實驗使用 temperature 0，仍會出現同一任務有時成功、有時失敗的狀況。這也補充了 AI Agent 生產環境防線：最小權限與稽核控制：權限與稽核之外，流程本身的穩定度也須成為上線門檻。

ALTK-Evolve 的兩階段做法

Consistency Analyzer 先取一條已完成的軌跡，在離線狀態對每個決策點以既有脈絡重取樣（預設一次取 5 個 completion），計算該步輸出變動程度。它不需要標準答案、模型 logits，也不必重新呼叫工具或重跑整個環境；代價是每個決策點額外一次模型呼叫。產出的 scorecard 可定位容易「翻面」的步驟。^[raw/articles/hugging-face-ibm-research-altk-evolve-consistency-2026-09-15.md]

接著系統把被標記的決策轉成可檢索的 consistency guidelines，接入既有 ALTK-Evolve 的指南儲存與推論注入流程。例如，它會提示代理計算核取方塊時採用行首錨定的 regex，而非直接數符號；搜尋筆記後先確認是否有多個候選結果。重點不是修補單一答案，而是把高不確定性的程序決策變成可重用規則。這與 CUGA：IBM 開源代理 Harness 的 24 個真實應用實踐 中以 SKILL.md 累積程序知識的方向相通。

結果怎麼看

在 168 個 AppWorld test_normal 任務上，以每題一條基線軌跡生成指南、再進行五次全新測試，Pass^5 從 53.0% 升至 69.0%，Mean@5 也從 77.4% 升至 81.0%，一致性缺口縮至 12.0 個百分點。中等難度任務的 Pass^5 增加 22.9 點、困難任務增加 14.3 點；官方報告指出平均準確率在各難度皆未下降。相近任務仍有 +13.0 點增益，代表指南可能擷取到可遷移的失穩模式，而非只背下某條軌跡。^[raw/articles/hugging-face-ibm-research-altk-evolve-consistency-2026-09-15.md]

不過這仍是特定 agent、模型與 AppWorld 設定的實驗，不能直接推論所有模型或企業流程都能取得同幅度改善。更合理的解讀是：能力評估必須和重複執行穩定性並列，呼應 Is It Agentic Enough：Hugging Face 開源模型代理基準測試框架 對正確率、失敗率、成本與實際路徑一併量測的主張。

實務意義

部署代理時，至少應在關鍵任務旁報告 Mean@k 與 Pass^k（k=3 也有價值），並從最不穩的決策點建立可檢視、可版本化的操作規則。較大的模型可能提高平均能力，卻不必然消除近似選擇造成的波動；因此不該把「換更大模型」當成可靠性治理的唯一答案。

更務實的導入順序是：先保存可追溯的任務軌跡、辨識重跑會翻轉的工具選擇與驗證步驟，再將規則以明確條件、固定檢查與測試案例固化。對有高風險副作用的動作，仍須保留最小權限、結果驗證和人工升級路徑；一致性指南能降低隨機性，不能取代治理。

相關頁面

反向連結

以下頁面引用了本頁：