Google 的 Gemini 4 Argon 在一次十一小時的無人值守執行中，對自家 Agent Development Kit（ADK）提出兩項被接受的效能優化：長會話的記憶體內會話準備開銷降低約四成，冷啟動套件匯入時間降低 21%。InfoQ 在 2026 年 10 月 24 日由 Sergio De Simone 報導這項實驗。ADK 是 Google 用來開發代理式應用的工具套件，因此它自身的啟動與執行效率，會直接影響所有建構在其上的代理。這次實驗真正值得注意的，不只是最後的百分比，而是問題被設定在「既有大型程式碼庫」上：ADK 橫跨約八百個檔案、超過二十萬行 Python 程式碼，並包含近一萬七千個單元測試。Google 工程團隊的目標之一，是了解模型如何處理既有程式碼庫，因為這比從空資料夾建立全新應用更困難。
為何既有程式碼庫是更難的測試
在既有系統裡做效能優化，不是打開一個檔案就能找到慢在哪裡。效能問題的症狀可能出現在某一層，但根因在另一層；代理人必須長時間維持對整體程式碼結構的地圖，並沿著呼叫鏈、共享參考與測試依賴跨模組推理。Google 指出，效能工作對模型是硬測試，因為它要求模型「正交地」看向症狀以外的位置，而不是只盯著已經顯示變慢的那一行。專案分析工具（profiler）可以告訴你複製會話與匯入套件很花時間，卻不會替你追蹤四十個檔案中的每個呼叫者、模擬目標與共享參考，也不會確保加速路徑後不會破壞既有應用。這也是為何這次任務不是單純找熱點，而是要在不改動公開 API、不改動模型輸入的前提下，提出可被維護者接受的變更。換句話說，代理不只要找到問題，還要理解修改的連帶影響，並用測試證明自己沒有製造迴歸。
十一小時的執行與提示設計
Google 先做了一次短時間執行，用來找出提示中必須包含什麼，才能讓代理遵循團隊的單元測試與效能基準慣例。接著，他們透過 .agents/skills 檔案提供專案專屬指引，概念上像給新進工程師的入職指南；代理被要求只載入當前任務需要的技能，避免把上下文視窗塞滿。上下文視窗是模型單次能處理的輸入範圍，一旦被無關資訊佔滿，重要線索就容易被擠掉。最後的提示使用 Antigravity 的 /goal 模式，讓目標在上下文壓縮後仍被保留；長時間代理執行往往會經過多次壓縮，若不鎖定目標，代理可能在過程中偏離原始任務。目標是讓 ADK 對任何代理都不增加明顯開銷，包括啟動階段、長會話、多代理與工作流程情境；同時保持模型接收的內容與公開 API 不變，每個變更都要有能捕捉迴歸的測試，並以一個合併請求（pull request）對 main 分支提出，描述中附上修改前後數字，而且不要自行合併。Argon 的日誌顯示，它閱讀了儲存庫指南、建立效能基準、提出優化、審查自己的變更，並在完成前跑完 16,892 個開源單元測試。
兩項被接受的優化與效能複利
最後被接受的兩項優化，一是改進 ADK 對會話歷史的處理：在複製事件之前先過濾，避免不必要的複製；二是導入延遲載入，讓重量級套件在真正需要時才被匯入。這兩項改動分別讓記憶體內會話準備與套件匯入速度提升約 40% 與 21%。單看一次大型語言模型呼叫，人類不會感覺到 28 毫秒或 78 毫秒的差異；但 ADK 支援多工具互動，可能橫跨數十甚至數百次迭代，小型開銷會複合。Google 提到，在 158 次內部工具呼叫互動中，移除這些複製可把完整執行從 65.6 秒降到 56.1 秒，等於省下近十秒的純框架開銷。這兩項優化看似微小，卻位於框架的共同路徑上；任何使用 ADK 的代理在啟動或長會話中都會受到影響。這正是代理式改碼的價值：不是做出驚天動地的單一重構，而是找到會隨規模放大的隱形成本。
意義與限制
這項經驗顯示，AI 代理已能針對既有程式碼庫提出可被接受的修改，但並不代表它能獨立完成整個軟體工程流程。Google 的發現指出，代理效果目前仍受制於寫完程式碼之後的工作，包括合併請求審查、除錯與測試；這些工作需要時間與人力。報導也提到，Argon 產生的修改中有四項在開發者審查時被拒絕，原因是可靠性、可維護性、相容性或可量測效能收益不足。換句話說，代理可以承擔跨模組調查與初步優化，但最終把變更安全地帶進生產環境，仍需要人類判斷、測試策略與維護標準。對實務團隊而言，這次案例更像一個可參考的工作模式：用清楚的專案指引、可驗證的目標與自動化測試，讓代理在受控邊界內處理既有系統的效能債，而不是把代理當成能取代審查與維運的角色。代理的產出必須被視為候選變更，而不是可直接合併的成品；真正的成本往往不在生成程式碼，而在驗證與承接。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。