跳到主要內容
研究與觀察AI 趨勢與技術研究
AI ENGINEERING / ARTICLE 01
AI 工程研究 · 正式發表

如何有效節省 AI Token?Coding Agent 的成本優化實務

用 Coding Agent 修復自動化測試時,重複載入上下文、龐大工具輸出和無進展重試都可能推高 Token 成本。本文用 Selenium 除錯案例說明如何保留證據、設定停損條件,以及衡量每個成功任務的費用。

讓 Coding Agent 修正一支失敗的自動化測試,成本可能從第一輪開始一路累積。模型讀過的程式碼、工具定義、測試紀錄和前一次失敗分析,很容易在後續回合繼續佔用上下文。假如每輪都重新讀取同一批大型 log,換成便宜模型未必能解決問題。

本文建議先檢查整段任務的資料流向,再決定如何調整提示詞或模型。這個次序也能避免刪除必要證據,反而讓 Agent 反覆重查。

Agent 會在多輪執行中持續消耗輸入 Token

聊天和 Agent 都可能包含多輪請求;工具互動與歷史沿用方式會影響每輪輸入。Coding Agent 會搜尋程式碼、呼叫工具、執行測試、閱讀錯誤,再根據新證據繼續處理。一旦進入失敗重試,消耗量就要按完整任務來看。

Bai 等人的研究以 OpenHands 執行 SWE-bench Verified,涵蓋八個模型,每題各跑四次,並在後續回合沿用完整對話歷史。2026 年 10 月 2 日更新的 arXiv v3 顯示,相同模型處理相同任務時,Token 用量仍會隨執行軌跡變動;較高用量也未穩定對應較高成功率。這是特定框架與基準測試的觀察,不能直接當成 Codex、Claude Code 或其他工作流的節費幅度。Token 用量與帳單金額也須分開比較,後者受到模型費率、快取與工具費用影響。

對工程工作流而言,比較有用的衡量單位是「完成一個通過驗收的任務,總共花了多少」。單看每百萬 Token 牌價,容易漏掉重試、上下文與工具互動造成的費用。

研究來源:Bai 等人 — How Do AI Agents Spend Your Money?(arXiv v3,第 2、3 節)

精準讀取可以減少後續回合的無關輸入

假設一支 Selenium 測試在等待元素時逾時。Agent 可能需要檢查 locator、等待條件、當下頁面狀態與關鍵錯誤訊息。這時候,把完整專案和上萬行測試紀錄一次交給模型,通常會讓問題更難聚焦。

較合適的順序是先以檔名、錯誤關鍵字或測試案例名稱定位,再擷取相關函式及錯誤前後文。對研究工作也一樣:先搜尋候選資料,再讀有用的段落。大批無關文字留在上下文裡,後續回合仍可能重複負擔。

Anthropic 的上下文工程指南主張保留足以支援任務的高訊號資訊,同時管理工具輸出與歷史狀態。這項原則比單純追求最短 Prompt 更適合長時間 Agent 工作流。

來源:Anthropic — Effective context engineering for AI agents

工具可以先整理需要分析的證據

以自動化測試為例,可以先由 Python 將測試結果整理成一份小型證據摘要:

  • 失敗案例與最後執行階段;
  • assertion 或 timeout 類型及必要 stack trace;
  • 對應的 locator、頁面狀態與相關錯誤片段;
  • 已嘗試的修正及驗證結果。

這是建議的輸入格式,並非已完成量測的內部工具成果。實務導入時還要先過濾憑證、個資與機敏內容,不能只因為縮短 log 就忽略資料安全。摘要也應保留原始失敗的時間、測試案例識別碼與可追溯的原始紀錄位置;若發現事件順序或多重錯誤相互關聯,需按需回查完整證據,避免裁切造成誤判。

同樣的方法也適合大型 JSON、SQL 查詢結果與 CI log。程式負責確定性篩選,模型再對精簡證據判斷原因。Anthropic 的進階工具使用文章提供了程式化工具呼叫及減少上下文往返的實作方向。

來源:Anthropic — Introducing advanced tool use

除錯迴圈需要預算與停止條件

除錯迴圈(Debug Loop)若連續幾輪沒有新的可驗證證據,單純繼續重跑可能只會擴大歷史上下文。這時可保留目前已知事實、排除過的假設、修改項目與下一個可驗證動作,交給新的上下文繼續處理,或交回人工決策。交接資訊應包含失敗紀錄索引、已執行的命令、未通過的驗證與尚未解決的風險;摘要不應把猜測寫成已確認的根因。

我建議為每次任務定義成功條件、最大重試次數、成本上限,以及停止時需要保存的交接資訊。這些數值須依測試環境、任務風險和實際使用資料調整;「三輪」只是可考慮的起點,並沒有普遍適用的最佳門檻。更有意義的停止訊號是連續重試沒有增加可驗證的新證據、觸及費用或時間上限,以及修改的風險超出預先授權範圍。若每輪仍取得新證據,也要遵守預先設定的硬性預算;停止執行時可以標示為待續分析,不能把停損當成根因已確認。

局部測試需要可重現的資料與前置狀態。牽涉登入、跨階段資料或共用元件時,仍須驗證相關整合流程;局部通過不能直接當成整體驗收成功。驗證是否成功,應盡可能交由 pytest、Selenium assertion 等確定性工具處理,減少不必要的模型回合。

Prompt caching 能降低重複輸入的費用

提示快取(Prompt caching)適合穩定、反覆使用的內容,例如固定系統規則、工具定義與參考資料。把經常改變的任務資訊留在後段,通常更有利於重用共同前綴。

快取命中取決於供應商支援的模型、最短快取前綴、內容一致性及快取有效期限;使用者不能假定每次重送文字都會命中。快取主要降低符合條件的重複輸入計費或處理負擔,不能當作降低實際送入 Token 總數的證據。過時的測試紀錄仍可能佔用上下文、干擾後續判斷。要處理這種情況,還是得清理歷史、裁切工具輸出,或在任務交接時做摘要與壓縮。前綴須精確符合可重用條件;首次寫入、後續讀取及未命中的費用應一起計算。裁切或摘要可能改變前綴、降低快取命中,須比較調整後整段任務的費用與品質。快取規則、計價與可用模型會變動,導入前應以服務供應商當時的文件為準。

這些是 API 層級的原則。使用訂閱制 Coding Agent 時,能否調整快取、取得詳細用量及如何扣抵額度,要依產品實際提供的功能確認,不能將 API 折扣直接換成訂閱費節省。

來源:OpenAI — Prompt caching

選模型時應把重試與成功率算進去

輕量的分類、抽取與格式整理,可以先評估成本較低的模型;跨檔案根因分析或高風險修改,則需要另看推理能力與失敗成本。兩種情況都要實測。

建議每次任務至少留下模型、輸入與輸出 Token、快取用量、工具呼叫數、重試次數、執行時間,以及最終驗證結果。當資料累積到一定數量,才有辦法比較:

每個成功任務的平均直接費用 = 同一批任務的全部模型與工具費用 ÷ 通過驗收的任務數。

分子包含失敗、重試、摘要及交接後續跑的費用;分母只計入相同驗收標準下成功的任務。若成功數為零,應記錄為無成功交付,這個比值無法計算。人工介入時間與基礎設施成本另列,才不會把直接費用誤稱為完整人力成本。推理 Token 若已計入供應商的輸出費用,也不可重複加總。

這是本文建議的工程管理指標。若只看低價模型的單次費率,可能漏掉失敗後的額外工作。OpenAI 的成本指南也把減少請求、減少 Token 與模型選擇列為主要的成本槓桿。

來源:OpenAI — Cost optimization

用一個 Selenium 逾時案例建立可追溯的成本比較

假設登入後的 Selenium 測試在等待訂單列表出現時逾時。這是示範性的工程情境,沒有使用任何真實客戶、院所或公司專案的測試紀錄,也沒有對節省比例提出實測主張。

第一輪先讓工具回傳測試名稱、失敗步驟、例外類型、相關 locator、等待條件、關鍵畫面狀態及原始紀錄索引;模型根據這份證據提出可以驗證的假設。第二輪針對假設執行局部測試,並記錄是否出現新證據。若只得到相同的 timeout,應先調整取證方法,而不是自動擴大重試次數。必要時可回查完整 log,以免忽略時間序列或跨系統錯誤。

以下是待實測的記錄格式,不是既有系統量測成果:

欄位應記錄內容
任務與版本測試案例、程式版本、執行環境、模型及設定
輸入成本每次請求的輸入 Token、已快取 Token,以及平台提供的快取寫入用量
輸出成本輸出 Token、可取得的推理用量、工具或執行服務費用
重試與時間每次請求和測試的次數、總耗時、人工介入時間
驗證與安全局部驗證、完整回歸測試、敏感資料遮罩及失敗證據位置
最終結果通過驗收、未解決或交回人工;不得把局部測試成功等同完整交付

比較改善前後的方式,是在相近難度與相同驗收規則下,記錄多個任務的成功率、成本分布和總處理時間。若成功率下降或人工接手成本增加,即使平均 Token 變少,也不應直接宣稱流程改善。模型單價及快取折扣應按實際執行日期與服務商用量紀錄計算。

這套記錄方法的價值,在於能分辨究竟是哪個環節消耗過多:重複載入歷史、原始工具輸出過大,或是反覆測試卻沒有新的診斷線索。

現有 Coding Agent 可以先改幾個使用習慣

不用等待完整的 Agent 平台重構,日常使用時就能開始:

  1. 每項獨立任務使用清楚的上下文邊界,長任務則定期整理交接。
  2. 先用搜尋定位函式與失敗點,再讀取必要區段。
  3. 讓工具先篩選 log、JSON 與測試結果,再交給模型。
  4. 局部測試通過後,才按需要擴大驗證範圍。
  5. 為反覆失敗的循環設定停止條件,避免無證據重試。
  6. 把穩定規則放在可重用的提示前綴,檢查實際快取命中情況。
  7. 以成功任務總成本及品質比較模型,保留導入前後的基準。

建議從最昂貴的幾個任務著手量測。每週回顧一次重複讀取的資料、無進展的重試,以及是否有多餘的模型呼叫,比平均縮短每個 Prompt 更容易找到需要調整的地方。

資料來源與適用限制

本文的測試情境與流程設計為說明性範例;沒有對某個特定組織或專案宣稱已量測節省比例。