# 我們如何透過保持快取完整無損，將瀏覽器代理程式的成本降低 76 倍，並使其速度提升 5 倍 > How Asana cut a browser agent’s cost 76x and made it 5x faster — by caching the full conversation history and pruning screenshots in batches instead of one at a time. Source: https://asana.com/inside-asana/cut-browsers-agent-cost ## 我們如何透過保持快取完整無損，將瀏覽器代理程式的成本降低 76 倍，並使其速度提升 5 倍 _一項在 Codex 中使用 GPT-6 Astra 的研究，涵蓋四種模型，從調查程式碼到評估結果。_ ## **為什麼我們要研究** Asana 正透過[StackAI](https://www.stackai.com/)將代理程式工作流程自動化引入其平台，而在 Asana 的規模下，小小的效率低下問題會累積起來。 我們的目標是讓一個瀏覽器代理程式更便宜、更快，同時不降低答案品質。 _「這就是人類和代理程式團隊在實務上的運作方式。 工程師確定方向，代理程式執行實驗，結果透過 Command 進入生產階段。 這展示了 Asana 如何將人與代理程式的團隊化為現實。」-_ **Asana 產品長 Arnab Bose** ## **有哪些地方出了問題？** 瀏覽器代理程式會在每次呼叫時重新傳送其工具、系統提示以及不斷增加的頁面文字和螢幕截圖歷史記錄。 提示快取可降低重複輸入的成本：在我們測試的模型中，快取讀取的成本是標準輸入價格的 0.05 倍至 0.1 倍。 但快取只會重複使用請求中最長且未變更的前綴。 我們的代理程式將其工具和系統提示快取起來，但沒有快取其歷史紀錄，而單獨快取歷史紀錄並無幫助：代理程式在每個步驟中都會移除先前的螢幕截圖，並修剪較舊的文字以符合歷史紀錄的預算。 每次編輯都會變更請求的前面部分，因此幾乎每次呼叫都會導致重複使用失敗。 ## **解決方法** 首先，也要快取歷史紀錄，並在最新的工具結果上加上快取標記。 其次，停止在每次通話中編輯它。 批次修剪會保留螢幕截圖，並以批次方式將其移除：在 20:1 的情況下，代理程式會保留最多 20 個螢幕截圖，然後再減少至 1 個，因此大約有 19 次連續呼叫會重複使用快取歷史紀錄。 我們還將歷程紀錄的預算從 12 萬個字元增加到 48 萬個字元，因此舊的文字不再被截斷。 ## **我們如何執行** 在 Codex 中運作的 GPT-6 Astra 完成了大部分的工作：它稽核程式碼、對每個請求進行插樁、執行快速測試以識別重要的變數、重構程式碼以併行執行工作流程、啟動執行並分析追蹤。 人類設定目標和標準，並審查結論。[Asana](https://asana.com/product/command)的軟體交付平台 Command 是紀錄系統：每個工作階段的請求、追蹤和結果都會記錄在其中，因此我們之後可以分析整個研究，而這些發現則成為了聯絡單、提取請求和已審核的變更。 **我從來沒有想過要手動完成，因為這可能需要花上我好幾個月的時間。 使用 Codex 大約花了一週的時間：我會在睡前設定一個 /目標，然後在早上查看結果。** **現在，每當我們的代理程式沒有在運作時，都感覺像是浪費了一個晚上。** 我們在 GPT-6.1 Sol 和其他三個尖端模型 (模型 A、B 和 C，見下表) 上，以兩種預算測試了六種快取和歷史記錄政策，每個條件執行三次：共 144 次執行，外加 12 次後續執行。 我們根據每個提供者的權杖計數器計算成本，並根據獨立準備的參考資料對每個答案進行評分。 **模型** **這是什麼** **價格** **模型 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 的模型 參照 ## **結果** 在模型 B 上，最佳條件使每次執行的成本降低了 29 倍，且執行速度比原始生產設定快了 4 倍。 在 GPT-6.1 Sol 上，同一代理程式的成本降低了 76 倍，執行速度提高了 5 倍，並從快取中讀取了 89% 的輸入內容。 在每個模型上，每個最佳條件的執行成本都低於每個基準的執行成本，並遇到了所有 192 個事實。 ## **經驗** - **預算必須符合模型**。 較新的模型更快用完較少的預算：模型 C 在第 10 次呼叫時首次縮減其歷史紀錄，模型 A 則是在第 64 次呼叫時。 在 12 萬個字元的情況下，模型 C 在 18 次執行中均未回答，而 Sol 在 3 次執行中回答，大多數都達到步驟上限；在 48 萬個字元的情況下，兩者在每次執行中均有回答。 - **單靠快取是不夠的**。 若沒有批次修剪，在較大預算下快取歷史記錄的成本，比在四個模型中的三個模型上不快取歷史記錄的成本更高：快取不斷被覆寫，且很少被讀取。 ### **您是否真的需要進行修剪？** 每次呼叫的資料顯示，在此處可能不需要進行修剪，因此後續追蹤保留了每個螢幕擷取畫面。 每次呼叫的成本比模型 B 和 Sol 的最佳條件低 1.2 倍，比模型 C 低約 5%。對於長時間任務、較小的上下文視窗和成本較高的快取讀取，修剪仍然很重要。 每個條件執行三到四次，且每次執行的呼叫次數各不相同，本研究顯示出整體模式，而非區分僅相差幾個百分點的條件。 ### **防護機制仍然重要** 沒有任何執行達到 480,000 個字元的預算，因此沒有對這些執行造成限制。 限制仍然很重要：偏離的代理程式會朝著情境限制的方向發展，如果快取中斷，每次呼叫都要支付全額費用。 步驟、權杖和每次執行的成本上限可限制不良執行的成本。 壓縮是另一個選項，但不在本研究的範疇內。 ## **從調查結果到生產** 當其他代理程式審查記錄到 Command 的每個追蹤時，後來出現了一些發現。 這在單一工作階段中很難做到，因為您無法確定所有資料都已儲存。 將所有內容都保存在 Command 中（我們的代理程式透過 MCP 存取），這意味著我們從來不需要重複實驗來恢復遺失的資料，從而加快了工作進度。 發現結果成為人類與程式碼撰寫代理程式的聯絡單，在此審查了提取請求，並將變更交付給 StackAI。 自研究結束以來，我們也使用 Codex 執行了相同的任務，將其方法與 StackAI 代理程式的方法進行比較，並建議進行第二輪的改進，現在這些改進已成為 Command 中的支援單。 ## **我們的收穫** - 快取不斷增加的歷史紀錄，而不僅僅是系統提示。 - 讓歷史紀錄僅限附加；當需要修剪時，請以大批次進行修剪。 - 設定歷史紀錄預算以適應模型。 - 使用提供者自己的計數器測量每次呼叫的快取讀取次數。 - 保留每個工作階段的完整記錄，以便分析和後續工作使用相同的記錄。 Asana 正在建置工具，讓這類實驗成為常規。 [完整的研究](https://assets.asana.biz/asset/fb86cc8e-6611-4404-b7c6-172692a724bb/How-Asana-used-Codex-to-optimize-browser-agent-costs-and-runtime.pdf)涵蓋方法、結果和限制。 **出貨速度不再是瓶頸；人類的注意力才是。 我認為我們正接近一個每個工程師都是產品經理，領導著一群代理程式的世界。** - [系統管理主控台中的微型架構](/zh-tw/inside-asana/microframeworks-admin-console) 工程 每個 Asana 部署都有一個系統管理主控台。 IT 系統管理員可以在此處設定公司使用 Asana 的方式，例如調整密碼要求、角色和權限、是否可以從 Dropbox 附加檔案，以及在預設情況下誰可以看見新專案。隨著 Asana 的發展，系統管理主控台累積了多年的自訂邏輯和臨時拼湊的解決方案，導致建立和維護管理控制項的成本越來越高。 以其中一項管理設定為例： ... - [以規格為導向的開發：優點以及我們在三個月後學到的內容](/zh-tw/inside-asana/spec-driven-development) 工程 #### 主任軟體工程師 三個月後，我們更清楚地瞭解了新增的架構在何時有幫助，以及在何時成為阻礙。我們的一位工程師正在準備資料遷移，並決定使用規格導向開發 (SDD) 來規劃工作。 SDD 的用意是幫助他們及早發現疏漏，使方法更易於審查，並為客服人員提供明確的方向。 最終的計劃非常詳細，從紙面上看來相當合理。 它將工作組織如下：問題 → 研究 → 規格 → 審查 → 實施 → 驗證 ... - [我們在 2 週內完成了 Enzyme 遷移。這本應花費五年的時間。](/zh-tw/inside-asana/migrating-off-enzyme-2-weeks) 工程 我們最近使用 AI，在大約一次衝刺中完成了多年的工程工作。 以下是其方法，以及為什麼它改變了我們對可能性的看法。五年問題早在 2022 年，我們就著手將 Asana 的前端測試套件從我們老舊的測試庫 Enzyme 移轉至 React Testing Library (RTL)。 Enzyme 已經失去社群支援，無法與較新版本的 React 正常搭配，並且鼓 ... - [打破致命三重奏：Asana 如何看待代理式 AI 安全性](/zh-tw/inside-asana/how-asana-thinks-about-agentic-ai-security) 工程 #### 主任安全工程師 代理式 AI 帶來了一類業界尚未解決的安全風險。 以下是 Asana 對此的看法，以及我們在所有 AI 功能中保持的安全性不變項。問題代理式 AI 系統不僅僅是回答問題。 它們會閱讀文件、採取行動以及跨工具進行協調。 它們能做的事情越多，可能受攻擊的範圍就越大。與傳統代碼不同，LLM 有一個特性，使這一點從根本上變得困難：它們無法可靠地區分指令和資料。 提 ... - [Asana 如何使用 Astra、Codex 和 Command 來降低瀏覽器代理程式成本](/zh-tw/inside-asana/cut-browsers-agent-cost) 工程 人工智慧 (AI) - [StackAI 的技術長](/author/frank-hidalgo) 一項在 Codex 中使用 GPT-6 Astra 的研究，涵蓋四種模型，從調查程式碼到評估結果。為什麼我們要研究Asana 正透過 StackAI 將代理程式工作流程自動化引入其平台，而在 Asana 的規模下，小小的效率低下問題會累積起來。 我們的目標是讓一個瀏覽器代理程式更便宜、更快，同時不降低答案品質。「這就是人類和代理程式團隊在實務上的運作方式。 ... - [工程](/inside-asana/engineering-spotlight)