Asana 用 GPT-6.1 Sol 把瀏覽器智慧體成本壓低 76 倍：一次由 Codex 驅動的工作流最佳化實驗

2026 年 10 月 9 日，OpenAI 在官網釋出了一篇與 Asana 有關的客戶案例。數字很醒目：在一組瀏覽器智慧體測試中，Asana 把估算的模型成本壓到原來的七十六分之一，執行速度提高到五倍。最佳化後的工作流跑在 GPT-6.1 Sol 上，平均每次執行的估算模型成本為 0.47 美元，耗時約四分鐘。對照基線是 Model B 上的原有生產配置。按這兩個數字做簡單換算，原配置每次執行的成本大約在 36 美元上下。先把話說在前面：這是廠商釋出的案例，成本是「估算」，對比來自 Asana 自己設計的 144 次執行研究。它是一個值得認真對待的工程訊號，卻還不是可以直接套用的行業基準。故事的背景是 StackAI。Asana 收購了這個平臺，客戶可以用它在不寫程式碼的情況下搭建工作流，讓智慧體開啟網站、填寫表單、收集資訊。這類工作流單次看不出問題，但在 Asana 的規模下，每一點低效都會被乘上巨大的呼叫量。StackAI 的 CTO Frank Hidalgo 博士因此決定，讓瀏覽器智慧體更快、更便宜。他沒有帶著團隊逐項手工排查，而是指揮 Codex 中的 GPT-6 Astra 去調查這個智慧體、測試改進方案、再比較結果。他估計，這些工作如果由人手完成，需要一到兩個月，而這一次大約一週就做完了。 案例中最有教學價值的是診斷環節。Hidalgo 先讓 GPT-6 Astra 梳理程式碼庫，解釋智慧體是如何拼出每一次模型請求的。它發現，智慧體快取了固定不變的指令和工具定義，卻沒有快取不斷增長的頁面文字與截圖歷史。這個發現值得細想。瀏覽器智慧體每走一步，都要把此前看到的頁面內容連同新的截圖再交給模型。歷史越長，每一步要重新處理的輸入就越多。如果這部分不能命中快取，同樣的內容就會在一次執行裡被反覆按全價計費，也會反覆拖慢首個字元的返回時間。步驟越多，這筆浪費累積得越快，累計輸入量的增長比步數本身更陡。以上是對機制的合理推斷。OpenAI 公開的摘錄沒有列出全部改動的細節，我們不能替它補寫每一項措施。 再看研究設計。Asana 的研究共做了 144 次執行，物件是 GPT-6.1 Sol 加上三個匿名的前沿模型，文中稱為 Model A、B、C。這種設計的價值在於，模型選擇和工作流改造被放進了同一張對比表。不過它也帶來一個必須說清的解釋問題：76 倍是「最佳化後的 Sol 工作流」對「Model B 上的原生產配置」，裡面同時包含了換模型和改流程兩個變數。把 76 倍全部記在模型頭上，會誇大模型的作用。把它全部記在工作流頭上，又忽略了模型本身的價格與速度差異。摘錄裡沒有看到把兩者拆開的對照，這正是讀者應當追問的地方。另外，成本是估算值，會隨各家定價調整而變化，樣本也只有 144 次，結論的穩定性需要更多重複來檢驗。

這件事的第二層意義在於工作方式。Asana 的首席產品官 Arnab Bose 說，這就是人類與智慧體團隊在實踐中的樣子：工程師定方向，GPT-6 Astra 跑實驗，結果經由 Command 進入生產。這句話裡有一條清晰的分工線。方向、取捨和上線的責任仍在人手裡，而最耗時的部分，也就是讀程式碼、提假設、跑對照、整理資料，交給了智慧體。實驗的邊際成本一旦降低，最佳化就不必再等到「有空的時候」，它可以成為常規動作。同時，價值的重心也移向評估本身：有沒有一批可重複的任務，有沒有可比的指標，有沒有人願意認真讀完實驗結果。沒有這些，跑得再快的實驗也只是產生更多噪聲。 換個角度看，這個案例也提醒我們，智慧體的成本並不只由模型單價決定。同樣一次任務，決定賬單的往往是請求如何被組裝：哪些內容放在前面保持穩定，哪些內容每一步都在變，哪些截圖真的有必要反覆送入。當上下文裡既有文字又有影象時，這種結構問題更容易被忽視，因為開發者看到的只是一次次成功的執行，賬單卻在後臺悄悄放大。Hidalgo 讓 Codex 先讀懂請求的構造，再動手改，這個順序是對的：先弄清錢花在哪裡，再談換哪個模型。對正在評估供應商的團隊來說，這意味著不能只比較每百萬詞元的價格，還要在自己的真實任務上，比較每次完成任務的總花費與總耗時。這兩項才是業務真正關心的數字。對業務而言，另一個值得記住的細節是 144 次執行本身。它說明團隊沒有憑感覺宣佈勝利，而是用一批固定的執行去檢驗每一個改動。這種做法成本不高，卻能擋住很多自我感覺良好的結論。

對行業而言，這個案例傳遞了三個訊號。第一，瀏覽器智慧體的競爭正在從「能不能做」轉向「做一次要多少錢、多少分鐘」，單次成本從幾十美元降到不足一美元，才可能支撐每天成千上萬次的企業呼叫。第二，提示快取的命中結構應當成為智慧體架構評審的固定檢查項，尤其是那些會隨步驟不斷變長的上下文。第三，案例的目的之一，是讓 Asana 能向客戶提供更強的模型，也就是用省下的成本換取能力。對讀者來說，最穩妥的做法是借鑑方法而不是搬運數字：先審計自己的請求裡哪一部分沒有被快取，再用同一批任務做受控對比，把換模型和改流程分開測，最後以成功率與成本並列報告。成本降到七十六分之一固然漂亮，但只有在任務仍然做對的前提下，它才有意義。