Asana 藉助 GPT‑6.1 Sol，在瀏覽器測試中將模型成本降至原本的 1/76
Asana 利用 Codex 中的 GPT‑6 Astra，在測試中將瀏覽器智慧體的成本降至原本的 1/76，速度提升至 5 倍，為客戶提供能力更強的模型。
1/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 | 另一家前沿研究實驗室於 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 的優化工作流程成本更低，僅 0.47 美元，約為上述成本的 1/2.6。優化工作流程的每次執行都完成了任務，並傳回正確答案。
3 次執行的平均值。≥：基準包含達到上限的執行，因此其平均值為下限。
右側兩個倍數均以優化後的模型 B 為比較基準。模型 B 於同一研究的第 1 階段執行，模型 C 與 Sol 6.1 則於第 2 階段執行（以點線區隔）。
單就 GPT‑6.1 Sol 而言，在較大的歷史紀錄容量上限下，新的快取與螢幕擷取畫面策略，將每次執行的成本從 1.97 美元降至 0.47 美元，約為原本的 1/4。每次呼叫的成本約降至原本的 1/3，因為 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(在新視窗中開啟) 部落格查閱。
