Asana 借 GPT-6.1 Sol 把瀏覽器智慧體成本壓低 76 倍

Asana 把一件很具體的工程問題做成了一個很有分量的案例。它旗下的 StackAI 平臺讓客戶不用寫程式碼，就能搭建會瀏覽網站、填寫表單、收集資訊的工作流。在 Asana 的規模下，這類瀏覽器智慧體每一處小小的低效都會被成倍放大。StackAI 的 CTO Frank Hidalgo 博士想讓它更快、更便宜，於是他讓 Codex 裡的 GPT-6 Astra 去調查這個智慧體、測試改進方案並對比結果。Asana 公佈的資料是：最佳化後的 GPT-6.1 Sol 工作流，平均估算模型成本為 0.47 美元，單次執行約四分鐘，比原來跑在模型 B 上的生產配置便宜 76 倍、快 5 倍。他估計，這些工作靠人手要一到兩個月，實際只用了大約一週。

問題出在上下文的構造方式上。GPT-6 Astra 先幫他梳理程式碼庫，解釋智慧體如何為每次模型請求拼裝內容。它發現智慧體只快取了固定的指令和工具定義，卻沒有快取不斷增長的瀏覽歷史，也就是它一路收集的頁面文字和截圖。結果是每一次請求都要按全價把整段歷史重新傳送一遍。更麻煩的是，智慧體幾乎每一步都會丟掉較早的截圖並裁剪文字。每一次編輯都會改動歷史，快取是按字首匹配的，歷史前面一變，後面全部失效。所以只給歷史加快取並沒有用。再者，丟失這些資訊還可能迫使智慧體回頭重讀已經看過的頁面，反而多花成本。這裡的要點是，單點最佳化會互相抵消，必須把快取、保留量和清理節奏當成一個整體來設計。

Hidalgo 審閱了 GPT-6 Astra 提出的修復方案，挑出三項來測試：把快取擴展到智慧體的瀏覽歷史；提高可保留的文字量；改為成批移除截圖，而不是每一步都移除。Astra 先做了快速試驗，弄清哪些變數真正起作用。由於原有程式碼並不是為受控實驗設計的，它又重構了程式碼，讓同一套前端和後端可以並行支援多種工作流，每種工作流有自己的設定。隨後它完成了完整研究：歷史預算取 12 萬和 48 萬字元兩檔，搭配六種快取與截圖策略，每種組合在四個模型上各跑三次，總共 144 次執行。表現最好的策略是讓截圖累積到 20 張，再一次性收縮到只留最近一張。這樣兩次清理之間，較早的歷史保持不變的時間更長，快取命中也就更穩定。它與更大的歷史預算結合，就成了最終的最佳化工作流。

實驗設計本身也值得留意。每種配置執行同一項任務：從公開的演示目錄中，為 32 本書各收集六個欄位，這與部分 Asana 客戶在 StackAI 上的實際用法接近。對照的四個模型是 GPT-6.1 Sol，以及另一家前沿實驗室的三個模型。模型 A 是 2025 年秋髮布的較小、較便宜的模型，價格是 GPT-6.1 Sol 的一半。模型 B 是原先生產環境使用的模型，2026 年夏釋出，與 GPT-6.1 Sol 同價。模型 C 是模型 B 的更新版，2026 年秋髮布，同樣與 GPT-6.1 Sol 同價。按 0.47 美元和 76 倍推算，原配置單次成本約在 36 美元上下，這是我們根據公佈數字做的推算，並非 Asana 披露的數值。流程上的閉環同樣關鍵。GPT-6 Astra 負責執行工作流，檢查請求、用量記錄和輸出，另有獨立的模型會話複核它的工作。每個會話的請求、資料軌跡和結果，都記錄在 Asana 的軟體交付平臺 Command 中，團隊事後可以完整複查整項研究。隨後，發現被整理成工單，再變成拉取請求，改動最終進入生產。Hidalgo 說，他會在睡前設定一個 /goal，第二天早上檢視結果。Asana 的首席產品官 Arnab Bose 把它概括為人與智慧體協作的實際樣子：工程師定方向，GPT-6 Astra 跑實驗，成果經由 Command 進入生產。

這個案例對行業的啟示有三點。第一，智慧體的成本主要由上下文工程決定，而不是模型單價。四個模型中有三個與 GPT-6.1 Sol 同價或更便宜，真正拉開差距的是快取是否命中。第二，用智慧體去最佳化智慧體，前提是實驗可重複、證據可追溯。Asana 先重構程式碼以支援受控實驗，再把全部軌跡留在 Command 裡，這比結論本身更值得學習。第三，需要謹慎看待數字：這是一項在單一任務、公開演示目錄上的測試，成本是估算值，而非賬單。它說明方法有效，但不能直接外推到所有瀏覽器工作流。對於正在把智慧體推向生產的團隊，更實用的做法是先檢查自己的請求裡哪些部分被快取、哪些每步都在變，再用小規模對照實驗驗證。還有一層含義不應被忽略：這件事改變了工程團隊時間的用法。一到兩個月的手工研究被壓縮到一週，省下的不只是工時，更是試錯的勇氣。過去，團隊往往因為實驗成本太高而不敢重構程式碼、不敢並行比較六種策略，只能憑經驗挑一種上線。當智慧體可以在夜裡跑完實驗、早上交出帶證據的對比，工程師的角色就從親手試錯轉向設定目標和審閱證據。這對審閱能力提出了更高要求：人必須看得懂請求記錄、用量資料和輸出，才能判斷哪項改動值得合入。Asana 讓獨立的模型會話複核，並把全部軌跡存進 Command，正是為了讓這種審閱有據可依。