Asana 是一家協助企業跨多種業務應用自動化工作的公司。它透過收購而來的 StackAI 平台，讓客戶以不需撰寫程式碼的方式建立工作流程，這些流程會瀏覽網站、填寫表單並蒐集資訊。當這類流程在 Asana 的規模下大量運行，任何一點效率損失都會被放大，尤其是瀏覽器代理每一次呼叫模型都得付出成本。StackAI 的技術長 Frank Hidalgo 因此著手讓瀏覽器代理跑得更快也更便宜。他讓 Codex 中的 GPT-6 Astra 調查這個代理、測試各種改進並比較結果。他估計若靠人力完成，這件事要花一到兩個月，實際約一週就完成。
背景：瀏覽器代理的成本壓力
瀏覽器代理的運作方式，是讓模型反覆讀取頁面內容與畫面截圖，再決定下一步要點擊什麼、輸入什麼，直到任務完成。這代表一次任務往往包含多次模型呼叫，而每次呼叫都會把先前累積的上下文一起送進模型。當任務牽涉大量頁面或欄位時，輸入量會快速膨脹，成本也隨之上升。Asana 的客戶用 StackAI 建立的工作流程，有些正是這類需要長時間瀏覽與蒐集資料的任務，因此最佳化不只是技術問題，也直接影響公司能提供哪些模型給客戶。Hidalgo 的目標很明確：在不犧牲答案正確性的前提下，讓代理更快、更省。
找出問題：快取與歷史管理
為了加快速度，Hidalgo 先用 Codex 中的 GPT-6 Astra 梳理程式碼庫，並解釋代理是如何建構每一次模型請求的。Astra 發現，代理確實有快取固定指令與工具定義，但沒有快取持續成長的頁面文字與截圖歷史，所以每一次請求都以全價重新送出這些歷史。與此同時，代理幾乎每一步都會丟掉較舊的截圖並裁剪文字。每一次編輯都會改變歷史，因此單純把歷史快取起來並沒有幫助；而如果丟掉太多事實，代理可能得回頭重讀已經看過的頁面。
Astra 提出的修正方案中，Hidalgo 挑了三項來測試。第一，把快取範圍擴展到代理的瀏覽歷史。第二，提高代理能保留的文字量。第三，改成批次移除截圖，而不是每一步都移除。由於原始程式碼並非為受控實驗而設計，Astra 接著重構了程式碼，讓同一組前端與後端能平行支援多個工作流程，每個流程各自擁有獨立設定。
144 次執行研究與優化結果
整個研究共執行 144 次，測試 GPT-6.1 Sol 以及另外三個前沿模型，文章中分別稱為 Model A、Model B 與 Model C。Model A 是來自另一家前沿實驗室、較小也較便宜的模型，於 2025 年秋季發布，價格為 GPT-6.1 Sol 的一半。Model B 是原先生產環境使用的模型，與 Model A 同一實驗室，2026 年夏季發布，價格與 GPT-6.1 Sol 相同。Model C 則是 Model B 的更新版，2026 年秋季發布，價格同樣與 GPT-6.1 Sol 相同。
實驗變數包括 120,000 與 480,000 字元兩種歷史預算，以及六種快取與截圖策略，每一種設定在四個模型上各測三次。所有設定執行的都是同一個任務：從一個公開示範目錄中，為 32 本書各蒐集六個欄位。這項任務被視為部分 Asana 客戶在 StackAI 上實際運行工作流程的代表。
表現最好的策略，是讓截圖累積到 20 張之後，才一次裁回最近的一張。這樣一來，較早的歷史能在移除之間維持更長時間不變，搭配較大的歷史預算後，就成為最終的優化工作流程。Astra 負責執行工作流程並檢視請求、用量紀錄與輸出，另有獨立的模型工作階段審查這些工作。每一次工作階段的請求、資料軌跡與結果都記錄在 Command 中；Command 是 Asana 的軟體交付平台，讓團隊事後能檢視完整研究。從 Command 產出的發現會被轉成票據，再變成 pull request，最後進入生產環境。
結果顯示，優化後在 GPT-6.1 Sol 上平均每次執行的估計模型成本為 0.47 美元，約需四分鐘，比原本以 Model B 為基礎的生產設定便宜 76 倍、快 5 倍。以 Model B 而言，優化把估計成本從至少 36.21 美元降到每次 1.24 美元，降幅約 29 倍；原本部分執行會在意義上達到步數上限而未能完成，因此 36.21 美元是下限。優化後的 GPT-6.1 Sol 又比優化後的 Model B 再便宜 2.6 倍。若只看 GPT-6.1 Sol，在較大歷史預算下，新的快取與截圖策略把成本從每次 1.97 美元降到 0.47 美元，等於降為四分之一。每一次呼叫約便宜三倍，原因是 89% 的輸入來自快取，而快取價格僅為未快取價格的 5%。執行時間也同步改善，原本在 Model B 上至少需 22.5 分鐘，優化後在 GPT-6.1 Sol 上約四分鐘。
歷史管理不只影響成本，也影響代理是否真的產出答案。研究顯示，在較小的歷史預算下，GPT-6.1 Sol 18 次執行中只有三次產生答案；換成較大預算後，18 次全部產生答案，而且答案都正確。
技術解讀與限制
這項案例的核心，在於理解模型呼叫的計價方式與代理的上下文成長特性。固定指令與工具定義不變，適合快取；但頁面文字與截圖會隨步驟增加，而且代理若每一步都改動歷史，快取就難以命中。把快取延伸到瀏覽歷史，同時拉長歷史被改動的間隔，才能讓大部分輸入落在快取價格上。批次移除截圖與提高文字保留量，則是在減少輸入量與保住足夠事實之間取得平衡，避免代理因為失去線索而重讀頁面，反而拉高成本與時間。
解讀這些數字時仍需注意限制。研究每個設定只執行三次，樣本數有限；部分基線包含達到步數上限或未完成的執行，因此其平均值只是下限，真實成本可能更高。此外，原始執行值與標準差並未提供，圖表上的執行標記與標準差誤差線是根據來源圖片近似重建，並非完整原始數據。成本數字也都是估計值，並非最終帳單金額。
後續發展與影響
Asana 已在 StackAI 發布瀏覽導航相關變更，並正在開發工具，讓類似的實驗更容易重複進行。團隊也計畫把這類測試納入平台評估機制，讓客戶與內部團隊在設定代理時，能同時比較成本、執行時間與答案品質。對 Hidalgo 而言，商業價值在於讓客戶用得到更快、更強的模型，同時把營運成本控制在可持續的範圍。他指出，成本以往限制了公司能為這類工作負載提供哪些模型；把代理變得更有效率之後，就能提供更好、更快的模型，同時降低自身營運成本。
Asana 也開始用 Codex 中的 GPT-6 Astra 在發布前測試產品功能：Astra 會操作平台、嘗試不同輸入，並把錯誤回報給人工 QA 審查者。Hidalgo 把這視為新軟體開發生命週期的基礎，未來可讓多個雲端代理工作階段平行測試功能。Asana 產品長 Arnab Bose 則形容，這展現了人類與代理團隊在實務中的樣貌：工程師設定方向，GPT-6 Astra 執行實驗，結果再經由 Command 進入生產。當出貨速度不再是瓶頸，人類注意力才是，Hidalgo 認為團隊正接近一個每位工程師都像產品經理、帶領一群代理工作的世界。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。