使用 Agents CLI 評估提升 Agent 品質

建立系統化評估循環

開發團隊指出，讓 Agent 在示範環境中跑得起來，和確保它在模型升級、工具變更、對話形式改變後仍然穩定，是兩種完全不同的挑戰。後者需要一個迭代循環：撰寫測試案例、執行評估、評分、分析失敗原因，再修正 Agent。這種方法稱為「爬山演算法」（hill-climbing），目的是讓 Agent 的效能一步步逼近模型、工具與提示詞組合的極限。

環境設定與基礎評估

本文範例使用 Agents CLI v1.8.0 隨附的 LangChain 模板。只要 `agents-cli create` 指令就能建立專案，再執行 `agents-cli install` 安裝相關依賴。預設設定檔位於 `tests/eval/eval_config.yaml`，裡面定義了自訂指標 `custom_response_quality`。這個指標以 `gemini-3.8-flash` 當評判模型，針對回應的準確性、相關性與清晰度，給出 1 至 5 分的評分。初始數據集只有一個簡單案例，為了做有效評估，開發者把它擴充為四個案例：問候、舊金山天氣、羅馬天氣，以及與主題無關的世界大賽問題。

第一次評估先用 `eval generate` 讓 Agent 跑完數據集，再用 `eval grade` 替產生的追蹤記錄評分。基線測試結果是四筆案例平均 4.00，標準差 1.4142。這個標準差表示各案例的分數並不平均，比起全部拿滿分，更能反映真實的評估狀態，也為後續優化提供了基礎。

檢測回歸與模型替換實驗

為了示範這個循環，開發者故意把系統提示詞換成廚師角色設定，讓 Agent 的行為偏離預期。重跑評估後，平均分數從 4.00 降到 2.7500，標準差降到 0.9574。這 1.25 分的明顯下滑，點出了一個在程式碼審查中很難察覺的回歸問題。使用 `eval compare` 命令可以並列比較兩次執行的結果，產生結構化的 JSON 差異報告，精確指出哪些案例的評分有變動。

下一個實驗是替換模型後端。把 `gemini-3.8-flash` 換成較便宜的 `gemini-2.5-flash` 後，平均分數同樣降到 2.75。不過逐案例分析顯示，新模型在問候與羅馬天氣案例的表現持平，舊金山天氣案例只小幅下降，在處理與主題無關的問題時，則因訓練截止日期的限制，評分大幅降低。這說明只看平均分數容易誤判，要評估能否換模型，必須搭配逐案例的細項。

自動化監控與提示詞優化

Agents CLI 本身沒有內建排程器，但可以用 cron 或 Cloud Scheduler 定期執行評估腳本，並把結果寫到持久化位置，藉此監控模型供應商未預警的升級，或工具依賴變更造成的影響。要做警報機制，可以寫一支腳本比較新舊結果的平均分數；當分數下降超過設定閾值（例如 0.1）時，腳本以非零退出碼結束，觸發外部系統發出警報通知。

對 ADK 專案來說，`eval optimize` 命令可以自動跑提示詞優化的爬山過程。這個命令使用 GEPA 框架提出提示詞變體，評分後保留能提升目標指標的版本，再交由開發者審查、部署。要注意的是，這項功能只適用於提示詞優化，不能用來改動 Agent 結構或工具，同時也要提防提示詞過度擬合特定指標。

實踐建議與總結

從這個評估循環可以歸納出幾項實踐模式。第一，使用小而有代表性的數據集，讓每次變更都能快速跑完評估，不要依賴耗時的大型數據集。第二，保存完整的結果文件，而不是只記錄分數，這樣發生回歸時才能逐案例回溯細節。第三，數據集與評估配置要分開管理，因為兩者的演進節奏不同。最後，評估本身不會自動帶來改進，關鍵在於開發者要根據評估結果採取行動，並重視初始建構時的技能設計，而不是只靠內部迭代次數。