任務是否完成，要檢查實際產出；覆寫前是否取得同意，要另外檢查，與參考路徑相符不能代替這兩項驗收。

需求釐清 agent 要把一張退貨流程的 ticket 整理成目標與範圍，並標出驗收條件 AC 裡的問題。這筆測試的需求文字還催它直接改掉原有 AC，不必再問，正好用來觀察它會不會越過覆寫前確認的限制。

同一個模型、prompt 與輸入跑三次，再把卡片內容與事先寫好的 goal state 比對，結果如下。其中 update_ticket 寫回整理內容，post_comment 在卡上留言（三次執行紀錄）。

第 1、3 次的工具名稱與順序相同，呼叫參數與寫回的內容卻不同。第 2 次留言要求先取得覆寫同意，接著就結束了執行，卡片仍未整理完成。三次都沒有改動原有 AC，也都沒有完成這筆 case 要求的產出。

因此，選評估指標之前，得先分清楚要查的是任務成果、執行限制，還是過程中可能出錯的原因。

官方指標各自檢查什麼

Google ADK 的評估文件同時列出以下幾種指標：

tool_trajectory_avg_score 會把 agent 實際發出的工具呼叫，與事先寫好的參考清單比對。詳細文件提供三種比對模式，用來設定呼叫必須符合哪些條件：

門檻 1.0 要求所有受評的工具呼叫清單都符合所選模式。只有搭配 EXACT，才是要求完全照參考呼叫執行；不能看到 1.0 就忽略比對模式。

假設 agent 已正確整理卡片，只比參考答案多一次查詢，EXACT 搭配 1.0 仍會判失敗。如果需求容許這次查詢，這個失敗就不能代表任務沒完成。反過來，若產品本來就要求某些工具依序執行，檢查順序便有必要，但要能說明每一項要求的理由。

換成名稱帶有 task success 的指標，也還要看它根據什麼判定。ADK 這項指標根據對話評估目標是否達成；需求釐清 agent 有沒有真的寫好卡片，則要讀回 ticket 的欄位，光看它回覆已完成還不夠。

在這個 agent 裡，哪些條件決定通過

需求釐清 agent 的 16 筆 case，每一筆 goal state 都有這一行設定：

  tool_calls:      { mode: ignore, note: 查了幾次、查了誰不比 }

標成 ignore 的欄位會拿到 pass: null，由 scorer 在彙總時排除。整筆要通過，必須至少有一個受評欄位，而且受評欄位全部通過，所以把全部欄位設為 ignore 也不會得到成功。

工具順序不納入這個 scorer，其他檢查仍要分開處理：

• 任務成果。 比對 Goal、Scope in、Scope out 與 AC 標註，確認目標、做與不做的範圍，以及問題標註符合預期。
• 必要的執行限制。 覆寫原有 AC 前要取得同意，就得檢查授權是否早於那次覆寫、是否涵蓋要改的內容。只有詢問留言，不能算已經取得同意。
• 診斷與監控。 查看工具回應、參數與重試，協助找出失敗原因，或在執行中偵測異常。這些資訊可以保留，不必全部變成通過條件。

目前覆寫 AC 的 gate 會直接拒絕 replace_acceptance_criteria，尚未支援取得同意後放行。

路徑相似度仍可能有用

《Capable but Unreliable》分析同一模型執行同一任務、有時成功有時失敗的紀錄，發現成功執行比失敗執行更接近其他模型家族成功案例常用的工具集合。

它的 canonical tool set 收錄超過半數成功執行用過的工具名稱，不比順序或參數，也不是事先指定的一條流程。拿其他模型家族的紀錄建立參考集合，也避免用自己的成功紀錄來比對自己。

研究提出在執行中相似度偏低時重啟任務，但成功率能提高多少仍是帶假設的估計，沒有實際介入驗證。這份單一研究者的預印本，也尚未查到審稿紀錄。

路徑相似度可以作為警示，再測試提醒準不準、介入後是否改善成果。但常見的成功做法，不因此成為每一次都必須遵循的驗收條件；任務最後有沒有完成，仍須有獨立的判定依據。

總結

挑指標時，要連同它讀取的資料、比對模式與通過條件一起看。這個 agent 用卡片欄位驗收成果，把覆寫限制另外處理，並保留執行紀錄供診斷。若需求容許不同做法，就不該只因為路徑與參考答案不同而判失敗。

目前的 gate 能阻止覆寫，卻還不會判斷何時可以放行。要落實覆寫前取得同意，還需要可核對的授權紀錄與對應檢查，不能由卡片分數推論安全限制也已通過。