一次通過還不足以判斷 agent 是否穩定，同一筆 case 重跑 k 次後，要一起看單次通過率、至少一次通過，以及全部通過，k 是執行次數。

優惠碼功能的 ticket 有 7 條驗收條件，也就是 AC。需求釐清 agent 要整理出 Goal、Scope in、Scope out，並在 AC 標註區塊列出問題。即使判定程式能正確檢查這些產出，單次結果也無法告訴我們，重新執行時會不會得到相同的判定。

固定輸入，標註還是會變

在前幾天，同一張卡 ac-conflict-001 用 gpt-5.4-mini 跑了三次，prompt 版本都是 cd590b9ba593，每次都從原始 ticket 與新對話開始。這批執行紀錄保留了各次產出與分數。

外部查詢使用同一份 fixture，也就是先前存下來的查詢回應。不過，三次都沒有查背景，只呼叫一次寫回卡片的 update_ticket，因此這批結果的差異不涉及外部查詢回應改變。

人工確認的答案放在 goal state，第 3 條有「彼此衝突」與「與描述不符」，第 4、7 條各有一個「不可驗證」，共 4 個標註。scorer 要求 AC 標註的集合完全相同，多標或漏標都不能過。

第 3 次雖然也是 4 個標註，內容仍不符合期望。三次都有找到第 3 條的「彼此衝突」與第 4 條的「不可驗證」，但第 7 條的「不可驗證」在第 2 次漏掉了；第 3 條的「與描述不符」則三次都沒找到。

重跑讓我們看見哪些問題偶爾漏掉、哪些連續漏掉。至於為什麼漏標，還需要另外追查，光靠標註集合無法判斷模型有沒有讀 description。

同一組結果，回答三個問題

每次執行先依 goal state 判定整筆 case 過或沒過，再把 k 次結果放在一起看。這裡的單次通過率用「通過次數 ÷ k」估計 pass@1；pass@k 看是否至少成功一次，pass^k 則要求 k 次全部成功。

Anthropic 在討論重跑指標時也區分了用途，一次成功就足夠的任務可以看 pass@k，需要反覆可靠執行的任務則要看 pass^k。

優惠碼的卡三次都沒過，兩種要求都沒有達成。為了看清楚差別，下面另列一組「過、沒過、過」的示意結果，這一列不是實驗產出：

repo 的 aggregate 用 results 接收每次完整執行的判定，先數出通過次數 passes，再算出三個結果：

export function aggregate(results: boolean[]): Aggregate {
  const k = results.length;
  if (k === 0) throw new Error('沒有跑過任何一次，算不出 pass@k');
  const passes = results.filter(Boolean).length;
  return {
    k,
    passes,
    passAtK: passes > 0,
    passHatK: passes === k,
    passRate: passes / k,
  };
}

若整份 dataset 每筆各跑 k 次，單次通過率的分母是總執行次數；pass@k 與 pass^k 則先逐筆判斷，再計算符合條件的 case 占全部 case 的比例。

排行榜的百分比，分母是什麼

評 agent 工具使用能力的 Toolathlon 也並列這三欄。下面節錄官方排行榜的 Toolathlon-Verified 版本，數字取自 2026 年 8 月底，k＝3，單位為百分比，pass@1 只列平均值：

Muse Spark 1.2 有 87.0% 的任務在三次裡至少成功一次，要求三次都成功時，比例降到 63.0%。它的單次成功率估計是 75.9%，三欄回答不同問題，也都只代表這份 benchmark 上的表現。

需求釐清 agent 整理完的卡會被拿去開工，使用者很難靠重跑來挑出正確版本。因此這個實驗用 pass^k 檢查重跑的一致性，同時保留單次通過率。即使三次都過，也只是這三次的觀察，不能保證往後每次都過。

要核對的還有實際算了幾次

另一份 Trello 卡片實驗，是讓 agent 按寫作規範產出卡片，再由程式驗收。它的早期報告寫每組跑三次，但 benchmark.json 的 metadata 記錄 runs_per_configuration: 1，產出目錄也只找到 run-1。

這些紀錄顯示報告與留下來的產出不一致，無法據此確定少跑的原因。判定程式倒是有一個可以直接確認的問題，它用 run_dir = run_dirs[0] 取資料夾，就算有三份產出，也只會讀第一份。

因此 harness 要記錄要求的 k、實際完成的次數，以及參與計算的次數，並保留每次的產出和分數。數量對不上時，要列出缺少哪次執行，不能照原定次數標示指標。

需求釐清 agent 的 run-k.ts 會逐次儲存結果，全部完成後才彙總，執行拋錯就中止。上面的 aggregate 只知道陣列有幾份，原本要求跑幾次、是否收齊，仍由呼叫它的程式負責。

總結

優惠碼的卡三次都沒過，卻出現三組不同的標註。單次判定看不到這些差異；把單次通過率、至少一次通過、全部通過放在一起，才能區分成功的頻率與重跑的一致性。

計算前還得核對 k 次是否各有產出、各有判定，而且全部納入彙總。目前三次都漏掉第 3 條的「與描述不符」，原因仍未確認，這三次的分數只能指出需要追查的問題。