Gemini 4 Argon 一夜間優化 200,000 行 Python 程式碼庫

2026年10月13日

Bo Yang 軟件工程師 Google Cloud

新模型推出時，大部分示範都會展示從空資料夾開始建立的全新應用程式。這些示範看起來很有趣，但對於模型如何處理現有程式碼庫，對在職軟件工程師幾乎沒有甚麼參考價值。

為了迎接 Gemini 4 Argon 推出，我們想測試它能否在無人看管的情況下通宵處理一項難度高得多的工作：找出並修正 google/adk-python 中跨檔案的效能瓶頸。Agent Development Kit (ADK) 是 Google 用於建立及部署企業級 Agent 的開源框架。

這個 Python 程式碼庫約有 205,000 行程式碼，分佈在近 800 個原始碼檔案中，並有近 17,000 項單元測試作支援。

效能工作是對模型的一項嚴峻考驗，因為你不能只打開一個檔案就找出效能變慢的原因。你必須從症狀出現位置以外的角度檢視問題，並在長時間執行期間掌握整個程式碼庫如何組合運作。

本文會介紹在為時 11 小時的通宵執行中使用的提示詞、.agents/skills 規則檔，以及人工程式碼審查的決策。這次執行令 ADK 在長時間工作階段中的記憶體內工作階段準備時間減少約 40%，並令套件冷啟動時的匯入速度提升 21%。你會看到最終採用的兩項最佳化、審查時否決的四項方案，以及如何在自己的程式碼庫中設定相同的通宵工作流程。

圖 1：ADK 在首次模型請求前的額外開銷，分別在完成 50 和 150 個回合後測量。Argon 的改動在兩個時間點都令開銷減少約 40%，因此工作階段越長，節省的時間就越多。

透過 .agents/skills 和 /goal 模式引導執行

大部分使用程式編碼 Agent 進行的效能工作，至今仍依賴緊密的人手介入循環：工程師執行效能分析工具，指定模型檢查一個效能熱點函式，並説明修正方式。我們想看看，若只告訴 Argon 團隊重視的結果，它會如何處理。

第一輪測試時，我們沒有提供任何自訂的程式碼庫指示。我們給它的提示詞只有以下一段：

^{讓 ADK 不為任何 Agent 帶來明顯額外開銷：
啟動時、長時間工作階段中、多 Agent 及
工作流程設定中。保持模型接收的內容及
公開 API 不變，並為每項改動提供一項可
偵測回歸問題的測試。}

第一輪執行了約兩小時。Argon 在開始 7 分鐘後編寫了一個基準測試指令碼，花了 70 分鐘測量及閲讀程式碼，之後才修改一行 ADK 原始碼，並找出工作階段複製及套件匯入方面的真正瓶頸。第一輪的部分程式碼最終納入了我們推出的最終提交版本。

第一輪的不足之處在於未能遵循維護者的慣例。由於 Argon 不清楚 ADK 團隊如何審查程式碼，它在 ADK 的身份驗證模型中加入自訂掛鈎，無形中改動了公開 JSON 結構描述；自訂複製器未顧及模擬事件的邊界情況；只執行了 216 項周邊單元測試；並且沒有在拉取請求説明中列出基準測試數據。

第一輪證明確實有實際提速空間，因此我們作出兩項調整，展開第二輪。首先，我們把團隊的維護者指引放進儲存庫的 .agents/skills 目錄，作為新工程師的入職指南。每項技能都以簡短的 SKILL.md 索引開頭，按需連結至專門的 references/ 檔案，避免每一輪都把 Agent 的上下文視窗塞滿。Argon 於晚上 9:11 開始執行時（圖 2），在修改任何程式碼前，先讀取 visibility.md 瞭解我們的私有 _-prefixed 模組規則，並讀取 imports.md 瞭解我們的懶載入檢查。

圖 2：Argon 首輪執行兩小時，與它為相同目標通宵執行 11 小時的比較。第一輪自行找到實際提速方法；第二輪則遵循儲存庫慣例、執行全部 16,892 項單元測試，並建立一個可供審核的 pull request。

其次，我們在 Google Antigravity 啟用了 /goal 模式。此模式會在上下文壓縮期間保留目標，讓 Agent 持續執行，直至完成工作。我們也加上兩句指示，要求提交一個尚未合併的 pull request，並列出改動前後的數據：

^{/goal 讓 ADK 不會為任何 Agent 帶來可察覺的額外開銷：無論在啟動時、長時間工作階段中，還是在多 Agent 及工作流程配置下皆然。
保持模型接收的內容及公開 API 不變，並以能偵測回歸問題的測試驗證每項改動。
以 main 為目標建立一個 ADK 維護者會批准的 pull request，並在説明中列出改動前後的數據。不要合併。}

在儲存庫加入 .agents/skills 並啟用 /goal 模式後，Argon 通宵無人看管地執行了 11 小時（圖 3）。

圖 3：Argon 在 Google Antigravity 執行 ADK 的通宵工作。/goal 提示詞固定顯示在視窗頂部和底部；已完成的工作則收摺成摘要區塊，讓原有規則在數小時的編輯、基準測試及測試執行期間一直保持可見。（截圖是在公開版 Antigravity 介面中重現，以移除內部工作區的詳細資料。）

6 項提案經程式碼審查後，最終有 2 項改動正式推出

翌日早上查看通宵工作階段記錄時，有幾點表現立即顯現。修改原始碼前，Argon 閲讀了 12 份指引檔案，並針對四種測試工作負載執行基準測試：套件啟動、200 步對話、20 個子 Agent 互相交派工作的測試應用程式，以及一個 12 節點工作流程；每項測試均執行 30 次。即使距離 11 小時執行結束只剩三分鐘，Argon 仍在審核自己的差異，發現自身多 Agent 快取中的錯誤，並重新執行全部 16,892 項單元測試，之後自行停止。

更重要的是，Argon 完成了分析器無法代勞的跨模組工作。分析器會告訴你複製工作階段及匯入套件需要時間，但它無法跨越 40 個檔案追查每個呼叫端、模擬目標及共用參照，確保加快這些路徑不會破壞現有應用程式。

總括而言，Argon 的 pull request 在 32 個檔案中提出六項最佳化方案。其中兩項妥善解決 ADK 的核心瓶頸，並已投入正式環境：

1. 複製前先篩選記憶體中的工作階段歷史記錄

ADK 每次執行的每個步驟，都會先載入對話記錄。以往，ADK 的記憶體內工作階段服務每次讀取時，都會先深層複製整段已儲存的對話，再篩選出呼叫端要求的事件。即使列出工作階段時不包含事件，也會先複製所有事件。Argon 更新了這項服務，改為先篩選事件再進行複製，並以快速且能安全處理循環引用的複製器，取代 Pydantic 對工作階段和事件採用的一般深層複製方式，同時保留共享狀態字典和測試 mock。

2. 僅在需要時載入大型套件

以往，執行 import google.adk 即使只是執行基本文字 Agent，也會載入即時音訊和影片串流、OpenTelemetry 追蹤，以及網絡伺服器（FastAPI 和 Starlette）所需的模組。在框架中單純刪除頂層匯入，會令下游測試無法直接在模組上 mock 屬性。Argon 在第二輪拉取請求中，從 llm_agent.py 移除了三個內部流程匯入。雖然 16,892 項開源測試全部通過，但 25 個 Google 內部測試目標卻告失敗，因為它們正是對那些屬性進行 patch。最終採用的修正方式是使用惰性模組存取器，讓大型套件只在首次使用時載入，同時確保所有公開屬性仍可在測試預期的位置進行 patch。

Argon 提出的另外四項最佳化如何處理？

我們發現，模型會提出一些我們原本不會想到的創新解決方案。其中一些創意會觸及框架規則，而這些規則不容許破壞性變更。

圖 4：Argon 上午提出的拉取請求中包含六項最佳化，分為我們採納的兩項，以及在程式碼審查中刪除的四項。我們保留了能有效減少實際額外開銷的工作階段複製及惰性匯入變更，並刪除了另外四項，因為它們依賴脆弱的狀態、程式庫的私有內部實作，或只在合成基準測試中帶來效益。

在程式碼審查期間，我們否決了另外四項變更：

多 Agent 事件快取令合成基準測試的速度提升 17%，但它依賴一個較弱的引用；如果 Python 在垃圾回收後重用某個記憶體位址，便可能跨工作階段傳回過時資料。
一項遙測檢查讀取了 OpenTelemetry 追蹤器實作中的私有屬性；程式庫只要進行次要版本升級，就可能在沒有提示的情況下失效。
重寫 ADK 在每次呼叫模型前格式化對話記錄的方式，令核心程式碼路徑更難閲讀，卻沒有改善我們獨立保留基準測試上的端對端延遲。
工作流程事件重播的查找索引增加了狀態追蹤的複雜度，卻只對合成重播測試有幫助，對日常 Agent 執行沒有幫助。

這種分工正是整個流程奏效的原因：Agent 負責探索，維護者負責刪減。我們結合第一、第二輪的最佳部分，完成一項涉及 22 個檔案的變更，並新增 17 個測試函式。在 ADK 團隊審查後，該變更已合併至 main，提交説明為「Argon generated these changes.」

基準測試結果：ADK 中「回合」的定義，以及為何 158 個回合很重要

要理解提交訊息中的數字，首先要知道 ADK 所説的回合是甚麼。

當工程師輸入提示詞並取得最終答案時，ADK 稱之為一次呼叫（invocation）。每當 Agent 執行動作時，底層的一個內部步驟便稱為一個回合，例如呼叫工具、執行一批平行工具呼叫，或查詢 MCP 伺服器。

使用 Agent 框架的原因，在於它能進行多輪工具呼叫；一次執行過程的底層會發生數十甚至數百個內部回合。

在兩輪測試開始前，我們先編寫了一項 Argon 從未見過的獨立留出基準測試（bench_turn.py）。在 bench_turn.py 中，單一工作階段會使用回應即時的模型和工具逐回合延伸，因此計時器上的每一毫秒都是 ADK 本身的框架開銷。每個回合在返回答案前會執行三輪工具呼叫，每輪包含四個平行呼叫；我們分別在先前已有 0、50 和 150 個回合後，各計時 5 個回合。以下每個數字均為 6 至 12 次執行的中位數；每個回合中，模型在變更前後收到的請求都逐位元組完全相同。

我們以五項基準測試比較合併後的提交與上一個版本（圖 5）：

05_figure5_benchmark_results

圖 5：在全部五項留出基準測試中，Argon 變更前後 ADK 框架開銷的中位數。長工作階段的準備時間減少約 40%，套件匯入時間減少 21%；由於延後載入的模組會在首個回合載入，新程序首次請求所需時間則維持不變。

如何解讀這些數字，並應用於自己的 Agent：

google.adk 的匯入速度提升 21%，所有 ADK 用戶都能即時受惠，CLI 指令、本機開發和測試探索也會更快。由於延後載入的模組仍會在 Agent 執行首個回合時載入，從全新程序啟動到發出首個模型請求所需時間維持不變（3.07 s 至 3.09 s）。在正式環境伺服器上，接收實際流量前先發送預熱請求，避免首位用戶的呼叫承擔這次性的匯入成本。
模型呼叫前開銷減少 40% 的改進適用於InMemorySessionService；它為InMemoryRunner、本機評估迴圈、CI 測試套件，以及未設定外部資料庫 URI 時的預設 Cloud Run 或 GKE 部署提供支援。對需時數秒的單次 LLM 呼叫而言，人不會察覺 28 ms 或 78 ms 的差別。然而，在 158 個內部工具呼叫互動回合中，這些複製操作的影響會累積：移除這些操作後，完整的 158 回合執行時間由 65.6 秒縮短至 56.1 秒（近 10 秒純粹是框架開銷）。外部資料庫、SQLite、Gemini platform、Firestore 和 Redis 工作階段儲存區會從儲存裝置反序列化資料，而非在記憶體中進行深層複製，因此在此測試中的讀取時間不會改變。

試用 Gemini 4 Argon

企業開發者和建構者可透過 API 在 Gemini platform使用 Argon（模型 ID 為 gemini-4-argon），亦可在 Google AI Studio和 Google Antigravity使用。

如需完整的技術規格、Token 上限及遷移指示，請參閲模型卡和開發者指南。

試用經最佳化的 ADK

ADK 的 Python 快速入門
請查看已合併的 PR 和基準測試提交；兩者可直接在 google/adk-python中查閲。
如果你想在無人監督的執行開始前，向 Agent 提供儲存庫的架構規則和 CI 檢查，可複製.agents/skills 目錄結構，它位於 google/adk-python 中。