你的 AI 代理在排練時運作良好，但在實際演示中，它卻採取了不同的路徑，導致相同的任務失敗。這在台上會令人尷尬。在實際生產環境中，這是一個可靠性問題：一個曾經成功的工作流程，在用戶下次提出相同請求時可能會失敗。對於關鍵任務，例如核對金融交易或檢查合約義務，這可能會造成嚴重的阻礙。
大多數基準測試將這種變異性隱藏在平均值之後。在 AppWorld 上，一個使用 GPT-4.1 的 ReAct 代理在五次重複運行中，平均成功率為 77.4%。然而，它在所有五次運行中都成功的任務比例僅為 53.0%——這是一個 24.4 個百分點的一致性差距。
大多數基準測試報告的是第一個數字。我們建立了一種方法來衡量第二個數字，並加以改進。
在先前的文章中，我們介紹了 ALTK-Evolve——一個能將代理過去的軌跡轉化為可重複使用準則的系統，這些準則會自動提煉並在推論時注入。它顯著提升了任務成功率，但這些結果也僅僅回答了平均情況的問題。本文則介紹了一致性準則，這是 altk-evolve 中一種新型的準則，建立在我們稱之為「一致性分析器」（Consistency Analyzer）的診斷工具之上，直接針對這個差距進行優化。
準確度掩蓋了不可靠的問題。一個 ReAct 代理（在 AppWorld test_normal 上使用 GPT-4.1），平均成功率為 77.4%，但在所有五次重複運行中都成功的任務比例僅為 53.0%——這是一個 24.4 個百分點的一致性差距。在困難任務上，這個差距甚至達到 30 個百分點。
我們為此專門建立了一個診斷工具。「一致性分析器」會重新取樣代理自身記錄的軌跡，以找出容易「翻轉」的決策點——即模型僅差一個 token 取樣就可能做出不同決策的步驟。它只需要一個追蹤記錄，無需真實標籤（ground truth），透過單次呼叫請求 k 個完成（預設 k=5）來重新取樣該追蹤記錄中的每個決策點，而不是重新執行整個任務。
將這種診斷轉化為準則，能將差距減少近一半——從 24.4 個百分點降至 12.0 個百分點（相同任務的 Pass⁵ 提升 16.0 個百分點，相似任務提升 13.0 個百分點），且不犧牲平均準確度。
標準的代理評估報告的是 Mean@k：將基準測試運行 k 次，然後取平均通過率。通常 k=3，有時甚至只有 1。這是所有排行榜上的數字，也是「77% 準確」在實踐中的意義。
Mean@k 回答的是「這個代理平均表現如何？」它沒有回答真實用戶關心的問題：「如果我再次提出這個確切的問題，它還會表現良好嗎？」為了解答這個問題，你需要 Pass^k：代理在所有 k 次運行中都成功的任務比例。
⚠️ Pass^k 與 Pass@k 不同。熟悉的 Pass@k 是樂觀的——它詢問 k 次嘗試中是否至少有一次成功，這是在可以驗證和重試時的正確問題。Pass^k 則是其悲觀的鏡像：每次嘗試都必須成功。字母相同，問題卻相反。Pass^k 總是 ≤ Mean@k ≤ Pass@k。
一個由 GPT-4.1 支援的 ReAct 代理，其 Mean@5 達到 77.4%——這確實很強。但 Pass^5 卻只有 53.0%。將近四分之一的基準測試任務，代理有時能解決，有時卻不能，而且任務在不同運行之間沒有任何變化。我們將這個差距——Mean@k 減去 Pass^k——稱為「一致性差距」。
這不是一個你可以透過更大的模型來解決的能力問題。它是一個正交的維度：一個代理可以同時具備能力和不一致性。
每次大型語言模型（LLM）代理做出決策——例如呼叫哪個 API、傳遞什麼參數、是否重試——該決策都來自於下一個 token 的機率分佈。重要的是該分佈的形狀。一個「尖銳」（sharp）的分佈將大部分機率集中在單一 token 上：其他候選 token 遠遠落後，因此每次運行都會產生相同的選擇。
而一個「平坦」（flat）的分佈則將相似的機率分散在幾個接近平手的 token 上，哪個 token 獲勝幾乎就像擲硬幣一樣。
這個形狀決定了需要多少雜訊才能改變結果。「尖銳」的分佈具有韌性——GPU 浮點數的非結合性、請求批次處理以及其他平台端效應會輕微地推動數字，但遠不足以改變明確的贏家。而「平坦」的分佈則恰好容易受到這種推動的影響：接近平手的選項可能會在微小擾動下重新排序。由於一個軌跡會串聯數十個決策，每一步微小的翻轉機率會累積成某次運行結果大不相同的巨大機率。這就是 24 個百分點差距的來源。
這也是為什麼這個問題會存在於你的解碼設定之外。貪婪解碼（Greedy decoding）和固定隨機種子（fixed seed）都只控制分佈如何轉化為 token，它們對分佈本身沒有任何影響。在託管端點上，機率會隨著每次運行而略微變化，因此即使在溫度（temperature）為零的情況下，相同的提示詞給相同的模型，今天可能會以一種方式解決接近平手的狀況，明天則可能以另一種方式。
我們的設定是：ReAct 代理在溫度 0.0 的情況下運行，因此上述的變異性都不是普通的取樣造成的。
這將問題轉化為一項搜尋：在給定軌跡中，哪些步驟是「平坦」的——以及一旦你知道了這些步驟，你該怎麼辦？
一致性準則來自一個兩階段的流程，它能與 ALTK-Evolve 現有的機制結合——並由一個新的來源訊號來驅動所寫入的內容。
給定一個已記錄的軌跡，分析器會透過受控的重新取樣來重播每個決策步驟，衡量模型在該點的輸出實際變化程度。具體來說，這是在每個決策步驟進行一次額外的模型呼叫，離線執行——以取樣參數設定為一次抽取 k 個完成（預設 k=5）發出，並針對已記錄的上下文進行重播，而不是新的工具呼叫、新的環境互動，也不是任務的第二次端到端運行。
這會為每個決策步驟產生一個一致性分數，並寫入記分卡中，以精確指出哪些決策在下次運行時有翻轉的風險。檢測是完全黑箱的——無需 logits、無需模型內部資訊，也無需除了你已有的追蹤記錄之外的任何儀器。
每個被標記的步驟都會成為標準 ALTK-Evolve 格式的候選一致性準則，因此它可以融入現有的儲存和檢索流程。以下是一個真實範例，由 GPT-4.1 從 AppWorld 任務「根據我的 SimpleNote 筆記，我的願望清單中有多少活動已完成？」的軌跡中生成：
[準則 1] 在計算筆記內容中勾選框樣式的標記時，請使用行錨定正規表達式匹配，而非簡單的子字串計數——筆記標題通常會在圖例行中重複標記符號。
[準則 2] 查詢筆記時，務必透過檢查多個匹配項並確認正確的筆記後再繼續。
這裡沒有任何任務特定的瑣碎資訊。字串計數錯誤和未經驗證的搜尋結果是許多 AppWorld 任務中都顯示出高度不確定性的決策點。這就是重點：分析器針對的是不穩定性，而非失敗——因此它能捕捉到代理這次碰巧做對，但下次很容易做錯的步驟。
觀看這個兩分鐘的演示——代理在該任務上因計數策略的不確定性，導致五次平行運行結果為 3-2，但在應用這些準則後再次運行：所有五次結果都一致。
我們在 AppWorld test_normal（168 個任務）上，使用 GPT-4.1 上的 ReAct 代理進行評估，為每個任務從單一基準軌跡生成一致性準則，並在 5 次新的運行中進行測試。
Mean@5 (%)，總計——與上述 Pass^5 採用相同尺度。
一致性差距大約減少了一半。總體 Pass^5 從 53.0% 上升到 69.0%，而 Mean@5 從 77.4% 上升到 81.0%，將「看起來有能力」與「值得信賴」之間的差距從 24.4 個百分點縮小到 12.0 個百分點。將近三分之一先前不一致的任務，現在成為代理每次運行都能通過的任務。
中等和困難層級的任務獲益最多。中等難度任務提升 22.9 個百分點（相對增加 44%），困難任務提升 14.3 個百分點（相對增加 45%）——相對而言效果相當，但中等難度任務的絕對提升較大。簡單任務提升 12.2 個百分點，因為其改善空間最小。這正是一致性準則的設計目的：找到並穩定代理自身不確定性滲透到結果中的特定決策點。
Mean@5 從未下降。保持平均準確度是一個硬性要求，而非可有可無：一個透過犧牲 Mean@5 來提升 Pass^5 的系統，只是將不可靠性轉移，而非真正解決問題。在每個難度級別上，平均準確度都保持或有所提升。
將這些準則應用到相同 AppWorld 情境中一個不同但相關的任務——即從中挖掘準則的情境的另一個變體——一致性準則仍然將 Pass^5 提升了 13.0 個百分點，僅比相同任務的數字低 3 個百分點。從一次運行中得出的準則不僅僅是修補那次運行；它捕捉到了可以轉移的通用模式。
更明確的證據來自於一個較弱的模型 gpt-oss-120b。相同任務的 Pass^5 從一個低得多的基準（10.1% → 16.1%）上升了 6.0 個百分點——有趣的是，相似任務的泛化數字（+8.7 個百分點）實際上超過了相同任務的增益，這表明這些準則捕捉到的是真正可重複使用的失敗模式，而非記憶單一軌跡的細節。
在報告 Mean@k 的同時，也要報告 Pass^k。平均值無法區分可靠的代理和僥倖成功的代理；即使 k=3，也會暴露出你未曾察覺的差距。
預期這個差距會隨著任務難度而擴大。在最困難的層級中，單一的平均數字最具誤導性。
不要首先尋求更大的模型。一致性與能力是正交的。更強大的模型會提高 Mean@k；但它不一定會減少一致性差距。
診斷無需評分員，也無需即時重播。每個決策步驟只需一次額外的 LLM 呼叫（預設取樣 k=5 個完成）就足夠了——無需真實標籤，也無需針對環境重新運行任務。這使得它可以在生產流量中使用，因為在生產環境中，你通常甚至無法完整重播一次任務。
試用 ALTK-Evolve——這個開源儲存庫現在包含了這些實驗中使用的一致性分析器和一致性準則生成功能——或者閱讀 arXiv 上的技術報告以了解完整的方法。
如果你在自己的任務中遇到無法重現的準確度數字，並且覺得這很熟悉，我們很樂意聽取你的意見——你的代理中容易「翻轉」行為的具體範例，正是塑造我們下一步開發方向的回饋。請提出問題或參與討論。
Mean@k。將任務運行 k 次，報告平均通過率——大多數基準測試稱之為「準確度」。
Pass^k。代理在所有 k 次獨立運行中都成功的任務比例。總是 ≤ Mean@k。這是用戶兩次運行相同查詢時所體驗到的情況。
Pass@k。k 次運行中至少有一次成功——這是樂觀的對應指標，常見於程式碼生成論文。
一致性差距。Mean@k 減去 Pass^k，以百分點表示。
ALTK-Evolve 開源儲存庫 — github.com/AgentToolkit/altk-evolve
技術報告 — arXiv
一致性準則演示 — 2 分鐘影片