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 先進行快速測試，確認哪些變數會影響結果。由於原有程式碼並非為對照實驗而設計，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(在新視窗中開啟) 中將研究結果轉為工單，再轉為 pull request，最後將變更部署至正式運作環境。
「如果親自動手處理，這件事得花我一到兩個月。使用 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(在新視窗中開啟) 部落格查閱。
