Google agents-cli 讓 AI Agent 自我改進：7 條評估規則與實作流程

AI Agent 已經能幫忙寫 Prompt、執行測試，甚至修改另一個 Agent 的指令。Google 最新分享的 agents-cli 工作流，則把這些步驟串成「執行、評分、修正、重跑」的自我改進迴圈。

但這不代表 Agent 可以完全自己變強。真正困難的工作，已經從「怎麼寫 Agent」往上移到「怎麼定義做得好」。如果評分標準寫錯，Agent 反而會愈改分數愈高、實際表現愈差。

先說結論：這套方法值得有正式 AI 產品的團隊採用，尤其適合客服、流程審核與內部助理等重複任務。不過導入重點不是打開自動優化，而是先把業務規則寫成可以驗證、可以說明失敗原因，而且不能被優化流程自行修改的標準。

自我改進 AI Agent 是什麼？

自我改進 AI Agent，指的是系統能反覆執行案例、找出失敗、修改 Agent 指令，再重新測試。它不是重新訓練底層模型，也不代表 AI 會自行決定產品方向。

Google 的流程可以拆成四步：

1. 讓 Agent 跑一組測試案例，留下完整執行紀錄。
2. 用事先定義的指標替結果評分，並說明失敗原因。
3. 由 Coding Agent 根據原因修改 Agent 的 Prompt 或指令。
4. 重跑案例，將新結果與原始版本比較。

這裡的評估指標（metric），就是判定結果好壞的具體規則。它可能是「取消訂閱前是否先提出保留方案」，也可能是「回覆是否包含必要的法遵聲明」。

真正的差別在於，團隊不再逐次手動修改 Prompt，而是把修改流程自動化。人仍負責定義目標、保管測試資料，以及決定新版能不能進入正式環境。

Google agents-cli 是什麼？

agents-cli 是 Google 提供的命令列工具與 Agent Skills，協助 Coding Agent 建立、評估及部署以 Agent Development Kit（ADK）開發的 Agent。ADK 是 Google 用來組合模型、工具、工作流程與狀態管理的開發框架。

它不是新的 Coding Agent，也不會取代 Codex、Claude Code 或 Antigravity CLI。比較接近的理解是：Coding Agent 負責閱讀需求與修改專案，agents-cli 則提供一套 Google Cloud Agent 開發流程與可執行指令。Google agents-cli GitHub

官方目前列出的前置需求包括 Python 3.11 以上、uv 與 Node.js，安裝指令為：

uvx google-agents-cli setup

只在本機建立、執行與評估 Agent 時，可以使用 Google AI Studio API key。API key 是讓程式獲准呼叫服務的驗證字串，因此不一定要先建立 Google Cloud 環境。要部署到雲端或使用相關雲端功能，才需要 Google Cloud 專案。

為什麼分數變高，Agent 反而可能變差？

自動優化最危險的誤解，是把「測試分數提高」直接當成「產品品質提高」。Agent 只會朝你給它的指標前進，無法自行判斷這個指標是否代表真實需求。

以取消訂閱客服 Agent 為例，公司的規則可能要求先提出保留方案，再確認取消。如果評估只檢查是否成功呼叫取消工具，Agent 即使省略保留方案，也可能得到滿分。

更麻煩的是，推理紀錄可能顯示 Agent 知道這條規則，也正確呼叫工具，但最後回覆仍引用過期資料。系統沒有當機，文字讀起來也合理，使用者收到的答案卻是錯的。

因此，評估不能只看 Agent 想了什麼或呼叫哪些工具，還要檢查使用者最後看到的結果。我的判斷是，這也是自我改進流程最有價值、同時最容易被低估的一部分：真正的產品規格開始從 PRD 裡的敘述，轉成可以重複執行的品質測試。

agents-cli 如何跑完評估與修正迴圈？

在這套流程中，執行軌跡（trace）是一次 Agent 工作的完整紀錄，通常包含 Prompt、最終回覆、工具呼叫與中間事件。先留下軌跡，團隊才能知道 Agent 是在哪一步出錯。

第一步是用測試資料執行 Agent 並產生軌跡：

agents-cli eval generate \
  --dataset tests/eval/datasets/cancellation_cases.json \
  -o artifacts/traces/

第二步是依照團隊定義的指標評分：

agents-cli eval grade \
  --traces artifacts/traces/ \
  --config tests/eval/eval_config.yaml

評分結果不應只有 0 或 1。只要判斷帶有語意，例如語氣是否合適、說明是否完整，評審最好同時回傳一行原因，讓下一輪知道該改什麼。

修改後，再把基準版本與新版結果放在一起比較：

agents-cli eval compare \
  artifacts/grade_results/results_baseline.json \
  artifacts/grade_results/results_after_fix.json

agents-cli 的現行 CLI 文件也提供 eval run，可把產生軌跡與評分串成一次操作。agents-cli CLI Reference

自我改進 Agent 的 7 條規則

1. 從一個失敗案例開始

一次丟入大量案例，看起來比較完整，卻容易同時出現多種失敗。團隊很難判斷下一步該改 Prompt、工具、資料，還是流程設計。

更實際的方法是先挑一個最重要、已知會失敗的案例。修到穩定通過後，再加入下一個。這符合 MVP 的做法，也能降低每次改動的影響範圍。

2. 要求評審說明原因

只有分數，無法告訴 Coding Agent 該怎麼修。每個非純規則型的評估，都應回傳結果與簡短理由。

例如「未通過：最後回覆直接確認取消，沒有先提出保留方案」，就比單純的 0 更適合拿來驅動下一輪修改。原因也方便人類檢查評審是否誤判。

3. 能用程式判定，就不要交給另一個模型

「是否先呼叫保留工具」可以用程式檢查，就不需要請另一個大型語言模型判斷。這類規則型檢查成本較低、結果固定，也不會因模型抽樣而改變。

LLM-as-a-judge 是讓大型語言模型擔任評審，適合判斷語氣、完整性與解釋是否合理。它不應取代所有傳統測試，而是補足程式難以精確判斷的部分。

4. 評估結果，不要綁死唯一執行路徑

Agent 可能先查地址再查天氣，也可能先確認城市再做地理編碼。只要最後答案正確、必要工具有使用，而且沒有違反規則，就不必要求每一步完全相同。

若測試只接受一條固定路徑，衡量到的可能是 Agent 有沒有照抄舊流程，而不是任務有沒有完成。只有具備先後順序風險的步驟，例如付款前必須取得確認，才適合檢查工具呼叫順序。

5. 不穩定案例不是雜訊，而是線索

同一個案例重跑後分數忽高忽低，可能代表 Agent 輸出不穩定，也可能是評審模型本身不穩定。直接刪掉案例，只會讓報表變漂亮，不會讓問題消失。

團隊應固定其他條件後重跑數次，觀察變動來自受測 Agent 還是評審。若是關鍵業務流程，即使平均分數不差，波動過大也不適合直接放大流量。

6. 不要讓提出修正的人移動及格線

分數可以用三種錯誤方式變高：降低門檻、修改預期答案，或刪除失敗案例。這些動作都沒有真正改善 Agent。

因此，團隊需要保留測試集（held-out set）。它是一批不參與 Prompt 修改、也不讓優化流程看到的案例，用來確認新版是否真的能處理沒背過的情境。若訓練用案例提高、保留案例沒有進步，通常代表系統只是在迎合測試。

7. 自動 Prompt 優化留到最後做一次

Prompt 優化只能解決指令措辭問題，無法補上缺少的工具、錯誤的資料來源或不合理的產品流程。如果每個失敗都立刻啟動昂貴的自動調整，可能只是反覆改寫句子。

先根據具體失敗原因修正工具、流程與規則，等問題收斂後，再做一次整體 Prompt 優化，成本與可控性都比較合理。

從開發測試走到正式環境監控

評估（eval）是在開發階段確認 Agent 品質的測試；可觀測性（observability）則是在上線後記錄並理解系統行為。兩者可以共用同一套品質定義，只是資料來源不同。

在開發階段，指標檢查團隊寫好的測試案例。進入正式環境後，則可抽樣檢查真實對話。Google Cloud 的 BigQuery agent analytics 能將請求、回覆、工具呼叫與錯誤記錄到 BigQuery，再進行規則型或語意型評估、重建執行軌跡，並追蹤行為漂移。Google Cloud BigQuery agent analytics

當正式環境出現新問題，團隊可以把該情境匿名化後加入回歸測試。回歸測試是每次修改後重新執行的舊案例，用來避免修好 A 卻弄壞 B。

這個閉環比一次性的公開基準測試（Benchmark）更有商業價值，因為它累積的是公司自己的退款政策、法遵限制、品牌語氣與客戶情境。不過正式對話可能含有個資與敏感內容，保存執行紀錄前仍要處理資料最小化、遮罩、保存期限與存取權限。

這套方法適合哪些團隊？

如果 Agent 已有穩定使用場景、會重複處理相似任務，而且錯誤能轉成明確案例，導入評估迴圈很值得。常見情境包括：

• 客服 Agent：退款、取消、升級與申訴規則可以逐項驗證。
• 內部流程 Agent：簽核順序、必填欄位與權限邊界可以用程式檢查。
• 研究或內容 Agent：來源完整性、日期、格式與引用規則可以形成回歸測試。
• Coding Agent：修改後必須通過功能測試、程式格式與常見錯誤檢查，以及安全檢查。

相反地，如果產品還在找需求、每次任務都不同，或團隊連「正確結果」都沒有共識，先做全自動優化並不划算。這時更需要的是人工檢視失敗案例與補齊規格，而不是加速迴圈。

我的取捨是：把 agents-cli 視為評估與工程流程工具，而不是自動變強按鈕。從一個關鍵行為開始，先證明評分真的對應使用者需求，再逐步擴大案例與自動化程度。

FAQ

agents-cli 可以搭配 Codex 或 Claude Code 嗎？

可以。Google 官方將 agents-cli 定位為可搭配 Antigravity CLI、Claude Code、Codex 與其他 Coding Agent 的工具。它提供 Agent 開發與評估指令，實際閱讀需求、修改檔案與執行流程的仍是 Coding Agent。

agents-cli 只能在 Google Cloud 使用嗎？

本機建立、執行與評估可使用 Google AI Studio API key，不一定需要 Google Cloud。若要部署 Agent 或使用 BigQuery 等雲端功能，就需要 Google Cloud 專案與相應費用。

自我改進 Agent 會修改自己的程式碼嗎？

不一定。Google 分享的核心流程是由 Coding Agent 根據失敗原因修改 Agent 的 Prompt 或指令，再重新評估。是否允許修改程式碼、工具或正式環境，應由團隊另外設定權限與審核流程。

評審一定要使用另一個 AI 模型嗎？

不用。可精確判斷的項目應優先用程式，例如欄位是否存在、工具呼叫順序與數值範圍。只有語氣、完整性或解釋品質等較難寫成固定規則的項目，才適合使用 LLM-as-a-judge。

分數提高，怎麼確認不是只背熟測試？

保留一批不參與修改的測試案例，並確認新版在這批案例也有改善。若只有反覆使用的案例分數上升，保留案例沒有進步，就可能是過度配合測試，而不是真正泛化到新情境。

結語：AI 可以負責迭代，人必須守住品質定義

agents-cli 把自我改進 AI Agent 從概念變成可以執行的工程流程：產生軌跡、依指標評分、修改指令，再比較前後結果。這能減少重複的人工調整，也讓每次失敗逐步累積成產品資產。

但自動化的上限，正是品質標準的品質。若指標只追求表面分數，迴圈只會更快把 Agent 推向錯誤方向；若團隊能把使用者需求、業務規則與風險邊界寫成可驗證標準，AI 才有機會在不失控的前提下持續改進。

最實際的起點不是建立完整平台，而是選一個 Agent 絕對不能做錯的行為，寫成一個能回傳通過／失敗與原因的指標，再放入一個已知失敗案例。先完成這個小迴圈，再決定下一步要不要擴大。

資料來源

• Google Cloud Tech：7 rules for self-improving agent loops every AI engineer should know
• Google agents-cli GitHub repository
• agents-cli CLI Reference
• Google Cloud：Use BigQuery agent analytics