Asana 以 GPT‑6.1 Sol 將瀏覽器測試的模型成本降至 1/76
Asana 利用 Codex 中的 GPT‑6 Astra，在測試中將瀏覽器智能代理的成本降至 1/76，速度提升至 5 倍，從而為客戶提供能力更強的模型。
76 倍
採用優化後的 GPT-6.1 Sol 工作流程，估計模型成本降低
5 倍
採用優化後的 GPT-6.1 Sol 工作流程，瀏覽器執行速度提升至
0.47 美元
採用優化後的 GPT-6.1 Sol 工作流程，平均估計模型成本為
Asana 利用 Codex 中的 GPT‑6 Astra 進行實驗，優化了瀏覽器智能代理在 GPT‑6.1 Sol 上的工作流程，將執行成本降至原來的 1/76，速度提升至 5 倍。
Asana 透過其收購（在新視窗中開啟）的 StackAI（在新視窗中開啟） 平台，協助客戶將跨業務應用程式的工作自動化。透過 StackAI，客戶無需編寫程式碼，就能建立可瀏覽網站、填寫表格及收集資料的工作流程。以 Asana 的營運規模而言，這些工作流程中細微的效率損耗，累積起來也不容小覷。
Asana 旗下 StackAI 的技術總監 Frank Hidalgo 博士着手提升瀏覽器智能代理的執行速度，並降低成本。他指示 Codex 中的 GPT‑6 Astra 分析智能代理、測試改進方案，並比較結果。他估計，這項工作若由人手完成需要一至兩個月，如今只花了約一星期。
Asana 的研究共執行了 144 次測試（在新視窗中開啟），涵蓋 GPT‑6.1 Sol 及另外三個前沿模型，本文稱之為模型 A、B 和 C。最終在 GPT‑6.1 Sol 上得出的優化工作流程，每次執行的估計模型成本平均為 0.47 美元，耗時約四分鐘；相比模型 B 原有的正式環境設定，成本降至 1/76，速度提升至 5 倍。
「這正是人與智能代理組成團隊的實際運作方式。工程師訂立方向，GPT-6 Astra 進行實驗，成果再經 Command 部署至正式環境。這展示了 Asana 如何讓人與智能代理的團隊協作成為現實。」
為加快進度，Hidalgo 首先利用 Codex 中的 GPT‑6 Astra 梳理程式碼庫，並解釋智能代理如何構建每個模型請求。GPT‑6 Astra 發現，智能代理會快取固定指示及工具定義，卻不會快取持續累積的網頁文字與螢幕截圖記錄，因此每次請求都會重新傳送這些記錄，並按全額收費。
智能代理亦幾乎在每個步驟都會刪除較舊的螢幕截圖，並裁減文字。每次修改都會改變歷史記錄，因此單靠快取記錄也無濟於事；而資料流失，更可能令智能代理需要再次瀏覽已讀取過的網頁。
Hidalgo 審視了 GPT‑6 Astra 提出的修正方案，並選出三項進行測試：
將快取範圍擴展至智能代理的瀏覽記錄
增加可保留的文字量
分批移除螢幕截圖，而非在每個步驟都移除
GPT‑6 Astra 先進行快速測試，確定哪些變數會影響結果。由於原有程式碼並非為對照實驗而設計，它隨後重構程式碼，讓一組前端和後端能同時支援多個工作流程，各自採用不同設定。
Astra 進行了完整研究：採用 120,000 及 480,000 個字元兩種歷史記錄容量上限，以及六種快取與螢幕截圖策略；每種組合均在四個模型上各測試三次（見下表）。表現最佳的策略是讓螢幕截圖累積至 20 張，再刪減至只保留最新的一張。這樣便能延長兩次移除之間的時間，讓較早的歷史記錄保持不變更久。這項策略配合較大的歷史記錄容量上限，便構成了優化後的工作流程。每種設定都執行相同任務：從公開的示範目錄中，為 32 本書各收集六個欄位的資料，藉此模擬部分 Asana 客戶在 StackAI 中執行的工作。
模型 | 說明 | 價格 |
|---|---|---|
模型 A | 另一間前沿 AI 實驗室於 2025 年秋季推出的模型，規模較小、價格較低 | GPT‑6.1 Sol 價格的一半 |
模型 B | 原本用於正式環境的模型，與模型 A 出自同一間實驗室，於 2026 年夏季推出 | 與 GPT‑6.1 Sol 價格相同 |
模型 C | 模型 B 的更新版本，於 2026 年秋季推出 | 與 GPT‑6.1 Sol 價格相同 |
GPT‑6.1 Sol | OpenAI 的模型 |
GPT‑6 Astra 執行工作流程，檢查請求、用量記錄及輸出，並由獨立的模型工作階段審核成果。每個工作階段的請求、資料追蹤記錄及結果，都記錄在 Asana 的軟件交付平台 Command（在新視窗中開啟） 中，方便團隊事後檢視整項研究。研究結果在 Command 中轉化為工作單，再轉化為提取請求，相關改動隨後部署至正式環境。
「如果由我親手完成，這項工作需要一至兩個月。利用 Codex 中的 GPT-6 Astra，只花了約一星期：我會在睡前設定一個 /goal，早上再檢視結果。」
對模型 B 而言，優化將每次執行的估計模型成本，由至少 36.21 美元降至 1.24 美元，即原來的 1/29（部分原有設定的執行在完成前已達步數上限）。GPT‑6.1 Sol 上的優化工作流程成本更低，僅為上述成本的 1/2.6，即 0.47 美元。優化工作流程的每次執行都完成了任務，並傳回正確答案。
3 次執行的平均值。≥：基準包含已達上限的執行，因此其平均值為下限。
右側兩個倍數均以優化後的模型 B 作比較。模型 B 在研究第 1 階段執行；模型 C 和 Sol 6.1 則在同一研究的第 2 階段執行（以虛線分隔）。
單看 GPT‑6.1 Sol，在較大的歷史記錄容量上限下，新的快取與螢幕截圖策略將每次執行成本由 1.97 美元降至 0.47 美元，約為原來的四分之一。每次呼叫的成本降至約三分之一，因為 89% 的輸入來自快取，而快取輸入的價格僅為未快取輸入的 5%。執行速度亦有所提升：模型 B 原有設定至少需要 22.5 分鐘，而 GPT‑6.1 Sol 的優化工作流程只需約四分鐘。
3 次執行的平均值，誤差線表示標準差。≥：平均值包含已達上限或未完成的執行，因此實際數值至少達到此水平。
長條採用藍色主題。請以 48 萬字元較大容量上限的長條為基準，比較快取效果。
執行標記及標準差誤差線均根據原始圖片近似重建；未能取得各次執行的原始數值及標準差。
3 次執行的平均值，誤差線表示標準差。≥：平均值包含已達上限或未完成的執行，因此實際數值至少達到此水平。
長條採用藍色主題。請以 48 萬字元較大容量上限的長條為基準，比較快取效果。
執行標記及標準差誤差線均根據原始圖片近似重建；未能取得各次執行的原始數值及標準差。
研究亦顯示，歷史記錄的管理方式會影響智能代理能否產生答案。增加 GPT‑6.1 Sol 可用於保留瀏覽記錄的容量後，能產生答案的執行次數由較小容量上限時的 18 次中僅 3 次，增至較大容量上限時的全部 18 次，而且每次答案都正確。對 Hidalgo 而言，其商業價值在於讓客戶用上更快、能力更強的模型，同時將營運成本維持在可持續的水平。
「過去，成本限制了我們能為客戶提供哪些模型來處理這類工作。提升智能代理的效率後，我們既能為客戶提供更好、更快的模型，也能降低營運成本。」
Asana 已在 StackAI 推出瀏覽器導覽功能的相關更新，並正開發工具，讓類似實驗更容易重複進行。團隊計劃逐步將這類測試納入平台評估，讓客戶和內部團隊在設定智能代理時，可比較成本、執行時間及答案質素。
「交付速度已不再是瓶頸，人的注意力才是。每位工程師都像產品經理一樣，帶領一支智能代理團隊——這樣的未來已近在眼前。」
Asana 現正利用 Codex 中的 GPT‑6 Astra，在產品功能推出前進行測試：Astra 會瀏覽平台、嘗試不同輸入，並向負責品質保證的人員報告錯誤，供他們審核。Hidalgo 視此為新一代軟件開發生命週期的基礎，讓大量雲端智能代理工作階段同時測試各項功能。
完整研究可於 Asana（在新視窗中開啟） 及 StackAI（在新視窗中開啟） 網誌閱覽。
