Google ADK2.14.0 穩定化執行介面：多次評測、工具比對與升級限制怎麼看？
Google ADK2.14.0加入多次評測與工具參數比對，穩定化執行介面。拆解平均分、最差值、通過率，以及Firestore回退與技能腳本升級限制。
Google ADK2.14.0 要處理的一個問題，是代理把任務做對一次，還不能說明下一次也能完成。若每次選的工具或參數不同，團隊需要保留重跑的落差，才能判斷改版是否改善。
Google 在2026年11月7日刊出這版 GitHub release，加入多次評測與參數比對，並把多項執行環境、A2A 與評測介面從實驗狀態轉為穩定。
ADK 是建立與執行代理的程式框架。它把模型、工具、會話狀態與評測接在一起，這次更新讓團隊能重複同一測例，再選擇如何合併各次結果。
平均分數、最差一次與通過比例，回答的是不同問題。新版提供這些選擇，但開發者也要說清楚評分規則，不能只把所有結果壓成一個總分。
穩定化同時伴隨行為改變。部分舊功能開關不再生效，工具參數與技能腳本的呼叫方式有修改，Firestore 新寫入的會話則無法直接交給舊版讀取。
我認為這版值得已用 ADK 維護多步驟代理的團隊研究，收益在於評測更能暴露變動，執行介面也較明確。採用前仍要對齊會話儲存與工具格式，不能把穩定標籤當成升級零修改。
先從多次評測的結果怎麼合併開始，才看得出哪些改善真的能支持部署選擇。
Google ADK2.14.0 多次評測如何揭露波動？
新版可讓同一測例從新會話重跑，再保留每次結果，避免只看一次成功。這讓同一份需求的不同執行，都能留在評測紀錄裡。
依官方完整發行說明，開發者可在命令列指定重跑次數與並行數量。前者決定觀察多少次，後者決定同時進行多少個測例。
兩者不能互相代替。把並行數加大可以縮短等待，卻沒有自動增加某個測例的觀察次數，也可能受到模型服務額度限制。
當重跑次數大於一，每次會從測例的初始狀態建立新會話。測例若固定了會話編號，系統會忽略它並提示，避免上一輪留下的狀態影響下一輪。
每次結果要能分辨，而非只剩平均
每一輪都會留下獨立結果與重複序號，命令列可先列整體判定，再展開各次執行。因此，團隊能查看失敗集中在哪一輪，而不必從總分猜原因。
但不同入口的預設並不相同。命令列未指定時每題跑一次，供測試程式使用的 AgentEvaluator 預設跑兩次，並用自己的參數控制次數。
AgentEvaluator 是把代理評測接進程式測試的入口，它不讀取同一份多次執行設定。若團隊同時在命令列和測試流程使用，就要分別確認實際跑了幾次。
結果留得完整之後，還要決定哪一種合併方式代表自己在意的可靠性。同樣三次執行，可能因規則不同而得到相反判定。
平均分、最差一次與通過率有什麼差別？
平均分可以讓一次較差結果被其他好結果抵銷，最差值與通過比例則保留不同限制。因此，選擇規則本身就決定這份評測在回答什麼。
官方設定文件舉了三次回覆相似度分數，分別是0.875、0.182、0.875。平均約0.644，高於0.6門檻，整題會通過。
若改看最差一次，0.182低於門檻，這一項就不通過。若要求通過比例至少90%，三次只有兩次達標，約67%，也會失敗。
所以，平均較適合觀察整體品質變化，最差一次則提出更嚴格要求。這些是同一組官方示例的不同讀法，並非本文另外執行的代理測量。
平均的單位也會改變權重
預設規則把每次執行中的各回合分數放在一起平均。另一種方式則先算每輪總分，再讓每輪占一樣權重，避免回合較多的執行占比也較高。
通過比例還能針對單一指標，或針對整題同時達成所有指標設定。因為一輪可能工具用對卻回答不佳，這兩個分母和通過條件並不相同。
執行當機又是另一類結果。沒有產生評分的當機，不進入通過與失敗的比例分母，但預設容許當機次數是零，所以仍會使整題失敗。
若刻意容許一次當機，三次通過加一次當機的通過比例會是三除以三。報告同時保留三次通過、一次當機，不能只留下100%就說四次全都完成。
這些跨輪合併規則目前由命令列評測使用，AgentEvaluator 與網頁入口不採用。合併方式釐清後，還得回頭定義單次工具呼叫究竟算不算正確。
延伸閱讀：GitHub 公開 Copilot 模型評測：成功率之外，每題成本與推理設定怎麼選？
工具參數如何比對，哪些判斷需要另一個模型？
參數比對可依欄位使用精確、忽略大小寫、數字容差或語意判斷，讓團隊定義哪些差異可以接受。它沒有把看起來相近的請求全部當成成功。
例如找旅館時，城市寫成 Rome 或 rome，可能只是大小寫不同。但房間數由一間變成兩間，就會改變工作內容，不能因為城市正確便忽略。
官方 ToolArgsMatcher 可替不同參數指定規則，並回傳整體是否符合、平均分數與各欄位結果。因此，兩個欄位正確、一個錯誤，可以有部分分數，卻仍判定整個呼叫不符。
數字容差也要主動指定，不能讓任意數值自動通融。忽略某個欄位則表示它不再決定結果，適合每次都會變動的識別碼，卻也會失去檢查該欄位的能力。
語意比較多出一個判斷來源
語意比對會請模型判斷兩段內容是否同義，因此需要額外呼叫和成本。這能處理自由文字的差異，仍不能直接當成人類已驗證工具一定做對。
這個比對器本身仍標為實驗介面，所以不能從其他模組轉穩定，推成每個新增功能都已穩定。設定與使用位置仍應按該模組文件確認。
一般回覆評分也有不同口徑。預設的文字重疊指標不需要模型裁判，但相似的字詞仍可能表達相反意思，例如燈已開與燈已關，不能只靠重疊判定事實正確。
即使評分方式不呼叫模型，產生受評結果的代理仍會執行。官方因此明寫評測需要模型憑證與額度，確定性評分不等於整場評測免費或離線。
評分規則釐清後，再看這次穩定化了哪些實際執行介面，才不會把測試工具的能力和部署承諾混在一起。
執行環境與 A2A 轉穩定，改變哪些工作？
穩定化讓既有環境與代理通訊介面不再標實驗功能，並加入串流檔案與整合入口。它是框架介面的成熟，不是替每一個代理提供成功保證。
本機環境，以及 E2B、Daytona 等執行環境，列在這次轉穩定的範圍。環境負責讓代理執行命令或讀寫檔案，各服務的硬體、隔離與收費仍有自己的條件。
A2A 則是代理之間交換任務與資訊的通訊方式，這次整合轉為穩定，並能從命令列產生代理卡片。卡片用來描述代理，沒有取代各服務自己的登入與權限。
因為大檔案若一次讀入會占用大量記憶體，新版檔案介面可分塊串流讀取。本機、E2B與Daytona的讀檔工具，因此能按行範圍處理，不必先把整份檔案載入。
效能數字仍要保留測量工作
官方另回報一個30節點、200回合的工作流，執行快23%，尖峰記憶體少9%。這組結果說明特定長流程的改善，沒有證明所有代理都省下同樣時間。
新的 TeamsRunner 可把 ADK 代理接到 Microsoft Teams 聊天與頻道。它提供整合元件，不代表每個企業帳號已完成安裝或所有權限都自動具備。
穩定化也會影響舊開關。這次轉穩定的16項工具集與整合功能，已不再被原先的實驗功能停用旗標擋住，而且不會因此顯示錯誤或警告。
所以，團隊若曾把那些旗標當成「這個功能不能用」的依據，就要重新確認行為。介面成熟不代表行為完全不變，既有工具參數也有相似問題。
技能腳本與工具參數，為何需要調整？
新版把技能執行改成經驗證的路徑和參數，也讓列舉型工具參數以型別成員交給程式。因此，一些原本能接受的呼叫格式，現在需要改寫。
技能腳本是代理依一份工作說明執行的程式。使用指定環境時，新的 RunSkillScriptTool 不再接受任意 shell 指令字串，而是接收參數與經確認的腳本路徑。
腳本從技能目錄執行，只接受 Python 或指定的 shell 腳本類型。舊提示或測例若還傳 command，會得到參數錯誤，不能只把套件升級便期待舊呼叫原樣工作。
這項修改收窄了自由指令入口，但官方沒有因此宣稱所有提示注入都已消失。其他工具可做什麼，仍由它自己的介面和權限決定。
固定選項不再只是普通文字
列舉型別用來限制一組固定選項，例如只有待處理與已完成兩種狀態。新版工具收到的會是這個型別的成員，不再只是模型傳來的普通字串。
因此，程式若直接拿它和字串比較，或把它當成一般文字處理，就可能出錯。官方建議比較型別成員，或用 value 取出原值，再接回既有邏輯。
工具回傳給模型的結果仍會轉成對應值，要求確認的回呼也有自己的處理條件。所以，不能只看到內部型別改變，就推成模型一定會收到另一種輸出格式。
呼叫方式能修正，已寫進儲存層的狀態卻可能影響回退。這讓升級最後一個問題，落在版本與資料能否一起恢復。
會話儲存與升級回退有哪些限制？
Firestore 的新序列化可繼續讀舊會話，但新版寫過的內容不能由2.13.0或更早版本讀取。因此，回退套件與回退資料，是兩件需要一起安排的事。
序列化是把程式裡的狀態轉成可儲存形式。新版把事件內容存為 JSON 字串，也改變巢狀清單的包裝，這就是舊讀取程式遇到新資料時的差異來源。
既有會話仍能載入並追加事件，但追加也是新版寫入。只確認升級前的歷史讀得出來，並不足以證明升級後仍能直接降回舊版。
PostgreSQL 也有另一項變更，新建立的 JSON 欄位採 json，既有 jsonb 資料表維持運作。外部查詢若依賴 jsonb 專用操作或索引，需要分清新舊資料表。
因此，這版適合先以實際使用的工具格式與會話儲存做對照。模型服務、沙箱與資料庫的費用仍各自存在，框架採 Apache 2.0 也沒有把整個部署合成免費服務。
延伸閱讀：AgentBug-Smith 是什麼？把 AI 代理框架錯誤變成可重現的測試
Google ADK2.14.0 常見問題 FAQ
多跑幾次，就能直接證明代理可靠嗎？
重跑增加了觀察，但結論仍取決於測例、評分與合併規則。平均、最差值和通過比例可能給出不同結果，不能只留下其中最好看的一個。
這次所有介面都轉穩定了嗎？
公告列出特定模組、工具集與整合，ToolArgsMatcher仍有實驗狀態。應逐項查看所用介面，不能把版本標題當成全部功能的共同承諾。
Firestore 升級後，只降套件就能回到舊版嗎？
新版寫過的會話無法由2.13.0或更早版本讀取。回退規畫要同時考慮資料，不能只更換程式版本。
結論
ADK2.14.0把評測波動、工具正確性與執行介面分得更清楚，也要求既有應用重新檢查一些過去默認的行為。
已有 ADK 工作流的團隊，可以先選一組真實工具與會話資料，用明確的重跑次數和判定規則比較。確認失敗原因與資料回退條件後，再逐步擴大部署，才知道新版改善的是自己的哪一段工作。
