# Google Agents CLI 把 Agent 評估做成可重複執行的品質迴圈

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 原作者：Google Cloud Tech (@GoogleCloudTech) · 策展與摘要：EasyVibeCoding · 平台：X (Twitter) · 熱度：🔥 · 日期：2026-08-28

> 原始來源：https://x.com/GoogleCloudTech/status/2093044070926991653

## 證據與延伸閱讀

- [Google Agents CLI 把 Agent 評估做成可重複執行的品質迴圈](https://developers.googleblog.com/driving-the-agent-quality-flywheel-from-your-coding-agent) — 官方文件 · 最後核對：2026-08-28 · 支持主張：Adds a five-stage Build & Test loop—Prepare Data, Run Inference, Grade, Analyze Failures, and Optimize & Iterate—fed by OTel traces, hand-crafted or synthesized scenarios, and production traces; decoupled optimizer/evaluator scoring; adaptive AutoRaters and custom metrics; and two package paths for ADK agents-cli or framework-agnostic Evaluation SDK users.
- [Google Agents CLI agent evaluation flywheel — @googledevs](https://x.com/googledevs/status/2049292585924002109) — 一手來源 · 最後核對：2026-08-28 · 支持主張：Adds a five-stage Build & Test loop—Prepare Data, Run Inference, Grade, Analyze Failures, and Optimize & Iterate—fed by OTel traces, hand-crafted or synthesized scenarios, and production traces; decoupled optimizer/evaluator scoring; adaptive AutoRaters and custom metrics; and two package paths for ADK agents-cli or framework-agnostic Evaluation SDK users.

## 中文摘要

Google Agents CLI 把 Agent 評估做成可重複執行的品質迴圈

Google 把 Agent 評估拆成可由 coding agent 反覆執行的流程：準備資料、執行推論、評分、分析失敗，再針對問題最佳化。重點不是讓回覆「看起來更好」，而是替每次修改建立可比較的指標，確認修正沒有同時破壞其他行為。

**五階段迴圈** 第一次從 Prepare Data 開始，資料可以來自人工案例、合成情境或 OpenTelemetry traces；之後重複 Run Inference、Grade、Analyze Failures 與 Optimize。`agents-cli` 負責準備資料集、執行 Agent、呼叫 AutoRaters 或自訂指標，並把失敗案例整理成能直接處理的模式。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/7cb1da24df9d91df.jpg)
> Agent 品質飛輪的五個階段：準備資料、執行推論、評分、分析失敗與最佳化，完成後再回到推論階段。

**六個案例抓出一個隱性缺口** 官方範例建立了一個貨幣轉換 Agent，刻意沒有要求回答末尾列出使用過的工具。六個回覆因此都缺少 footer，但內建 AutoRaters 的 `tool_use_quality` 仍是 1.00，`instruction_following` 與 `final_response_quality` 也有 0.83。這些綜合分數能看整體健康度，卻沒有把團隊真正想守住的單一行為獨立呈現。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/740546aeb6b88382.jpg)
> gemini-3.7-flash 基準測試：tool_use_quality 6/6，instruction_following 與 final_response_quality 各 5/6。

團隊接著新增 `tools_footer_present` 專用指標，並同時用模型評分與 regex 檢查。基準版本是 0/6；在 Agent 指令中補上一行 footer 規則後，兩種檢查都變成 6/6，`instruction_following` 與 `final_response_quality` 也上升到 1.00，而 `tool_use_quality` 維持 1.00。這讓修正的效果與沒有退步的部分都能被分開驗證。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/2303620d89178179.jpg)
> 補上一行 footer 規則後，tools_footer_present 從 0/6 變成 6/6；另兩項指標也升至 1.00，工具使用品質維持 1.00。

**開發與正式環境共用評分器** 還沒有真實流量時，可以先用 User Simulator 合成情境；上線後則改評估正式環境 traces，交給 Online Monitors 持續寫入 Cloud Monitoring。兩邊可以共用 AutoRaters，但節奏不同：開發階段按需執行，正式環境持續監測。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/976b3a0178453a3d.jpg)
> 「Same graders, two cadences」架構圖：開發階段按需評估，正式環境持續監測，兩邊共用 AutoRaters（GenAI evaluation service）。

**實作時要守的界線** 如果某項規則能由 regex 或程式碼直接判斷，就應把確定性檢查當成錨點，不必把所有判斷都交給另一個模型。合成情境可能自行加入 Agent 原本不需要遵守的規則；模型型 AutoRater 也可能在不同執行間浮動，因此更適合觀察修改前後的差值，而不是把單次絕對分數當成保證。官方範例使用 `gemini-3.7-flash` 與六個小型案例，結果不能直接外推到其他模型、資料集或正式流量。

安裝方式是 `uv tool install google-agents-cli`。Google 另提供 `google-agents-cli-eval` skill，以及不綁 ADK 的 `agent-platform-eval-flywheel` SDK skill；兩條路徑的共同原則都是先替想改的行為命名，再用同一組案例證明修改真的有效。

## 標籤

CLI, Agent, 教學資源, Google Cloud, Google