在 AI 產品的開發週期中，許多團隊傾向將性能優化的焦點放在推理（Inference）階段，例如追求更快的首字生成速度（Time to First Token）或更高的每秒 Token 輸出量。然而，OpenAI 的 ChatGPT 性能團隊負責人 Martin Spier 指出，隨著 AI 代理（AI Agents）開始深度參與程式碼開發，軟體交付的速度與量能發生了質變，這使得性能工程（Performance Engineering）面臨全新的挑戰。性能問題不再僅僅是 GPU 的運算能力，而是一個涉及基礎設施、開發工作流與用戶感知的系統性問題。
背景：開發速度的指數級成長與隱形成本
傳統的軟體開發中，人類工程師是所有變更的核心，每行程式碼的邏輯通常在開發者心中有清晰的藍圖。但隨著 Codex 等 AI 代理工具的普及，OpenAI 的開發模式轉向了代理化開發（Agentic Development）。這導致了兩個顯著變化：首先是吞吐量的提升，工程師可以同時處理更多並行任務，大幅增加了每週合併的 PR（Pull Request，程式碼合併請求）數量；其次是抽象層級的提高，開發者在委託 AI 代理執行複雜任務時，可能不再完全掌握每一處細節。
這種開發速度的加速帶來了隱形的性能成本。每一次新增的邏輯判斷、額外的網路請求或記憶體數據結構，雖然單次影響微小，但在大規模全球部署的環境下會產生複利效應。當大量微小的性能退化（Regressions）累積，最終會導致系統可用空間（Headroom）縮減，將性能問題轉化為可靠性危機，直接影響用戶留存率與業務營收。
核心內容：超越 GPU 的全路徑性能視角
Martin Spier 強調，維持 ChatGPT 的快速反應，不能只關注推理引擎，而必須監控整個請求路徑。一個典型的聊天請求在到達 GPU 之前，需要經過一系列複雜的 CPU 密集型操作：身分驗證、配額檢查、獲取對話上下文（Context）、處理上傳的 PDF 或圖片、進行 Tokenization（將文本轉換為模型可識別的數值標記）以及處理上下文視窗的截斷或壓縮。
如果這些前置步驟（Pre-inference）或後置的串流儲存（Post-inference）過程緩慢，即便擁有全球最快的推理模型，用戶感受到的依然是產品的遲緩。因此，OpenAI 將性能衡量標準從單一的組件指標，轉向基於用戶意圖（Intent）的感知指標。例如，用戶輸入訊息後期待立即看到反饋（如 loading 狀態），接著是首個可見價值（First Visible Value）的產生，最後才是任務的完整結束。針對不同意圖（如簡單問答 vs. 複雜的代理執行任務），系統會設定不同的性能預期與監控維度。
技術脈絡：構建「永遠在線」的性能優化循環
為了跟上 AI 代理帶來的開發速度，性能工程必須從「反應式」轉向「自動化」。傳統的性能優化循環（發現退化 $\rightarrow$ 獲取 Profiling 數據 $\rightarrow$ 分析根因 $\rightarrow$ 實作優化 $\rightarrow$ 測試驗證）是線性且緩慢的，無法應對高頻率的程式碼變更。
OpenAI 嘗試構建一個「永遠在線」（Always-on）的 AI 代理循環，將性能工程自動化。在反應式循環中，當監控系統發現性能退化時，AI 代理會自動觸發 Profiling（性能剖析，用於分析程式執行時的資源分佈），比較變更前後的火焰圖（Flame Graph），並直接在程式碼庫中尋找對應的 PR 提出修復建議。在主動式循環中，AI 代理則持續在後台尋找優化機會，例如監控 CPU 熱點、分析記憶體分配（Allocations）或檢查前端 Bundle Size（資源包大小），並並行嘗試多種優化方案。
影響與限制：工程成熟度是自動化的前提
將 AI 代理引入性能優化並非沒有風險。要實現 AI 代理自主完成「發現 $\rightarrow$ 修復 $\rightarrow$ 驗證」的完整閉環，需要極高的工程成熟度。首先，必須具備極高覆蓋率的測試集與基準測試（Benchmarks），否則 AI 無法判斷優化是否損壞了功能或是否真正提升了性能。其次，強大的可觀測性（Observability）至關重要，若系統存在監控盲點，AI 代理可能會因缺乏上下文而導向錯誤的優化方向。
此外，安全部署機制（如 Canary Analysis 金絲雀分析或藍綠部署）是最後一道防線，確保 AI 代理提出的優化方案在進入生產環境前經過嚴格驗證。最終的目標是讓人類工程師定義方向與定義「何謂良好性能」，而將繁瑣的數據分析與反覆嘗試交給 AI 代理，以維持在極速開發環境下產品的流暢度。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。