拆解 AI 工具的體感延遲：一套找出真正瓶頸的觀測方法論

當我們開發或使用 AI 工具時，體感上的「卡頓」往往令人挫折，直覺會將矛頭指向大型語言模型的 API 延遲。然而，系統性的定量分析經常揭示一個反直覺的事實：絕大多數的延遲並非來自模型本身，而是源於工具鏈內部不透明的排程、等待與邏輯錯誤。要打造反應迅速、體驗流暢的 AI 應用，關鍵不在於盲目更換模型，而在於建立一套完整的觀測性（Observability）方法，精準拆解延遲預算（latency budget），找出真正的效能瓶頸。

表象之下的真相：從 Claude Code 卡頓事件談起

最近一篇由開發者 Yuki Fujisawa 進行的定量分析，為這個觀點提供了極佳的佐證。許多使用 Claude Code（特別是在 Opus 4.8 版本）的開發者都曾遇過一種惱人的情況：工具在執行過程中，會無預警地「靜默」長達數分鐘，彷彿當機一般。面對這種情況，最直接的猜測自然是 Anthropic 的 API 伺服器回應過慢，或是模型生成速度出了問題。

然而，透過對 session log 的實際測量，真相令人意外。在分析了 376 次超過 60 秒的停滯事件後，數據顯示，真正由 API 呼叫本身造成的延遲佔比極低，甚至不到 1%。絕大多數的時間，都消耗在工具內部的機制上，例如等待 subagent 或 hooks 的回應。換言之，使用者感受到的漫長等待，並非模型在「思考」，而是工具自身的程式邏輯或資源調度陷入了瓶頸。這個案例清楚地告訴我們，若缺乏對整個系統的端到端觀測，我們很可能把精力耗在錯誤的地方，試圖優化一個根本不是問題的環節。

如何系統性地拆解延遲來源？

要避免見樹不見林的盲目優化，我們需要引入「延遲預算」的觀念，這與軟體可靠性工程（SRE）中的錯誤預算（Error Budget）概念相似。我們必須將一次使用者互動的總時間，視為一筆固定預算，並清楚盤點每一分毫秒花在了哪裡。一個典型的 AI Agent 任務流程，其延遲可能由以下幾個部分組成：

• 輸入處理與前置作業： 包含解析使用者指令、驗證參數、從向量資料庫進行 RAG 檢索等。
• 提示詞工程（Prompt Engineering）： 動態組合提示詞模板、注入上下文與範例。
• 模型 API 呼叫： 這才是真正與 LLM 伺服器通訊的時間，包含網路延遲、等待首個 token 的時間（TTFT）、以及 token-by-token 的生成時間。
• 工具鏈內部排程與等待： 這是最容易被忽略的黑盒子。例如，一個主 Agent 呼叫多個子 Agent，它可能需要等待所有子任務完成才能繼續。如果這個等待機制是同步阻塞的，就會產生巨大延遲。
• 輸出處理與後續作業： 解析模型回傳的 JSON 或結構化資料、執行後續的程式碼、將結果串流回使用者介面。

只有當我們為每個環節都埋設了計時器，並將數據視覺化後，才能真正看清延遲的分佈。否則，所有的效能調校都只是憑感覺猜測。

使用者感受到的延遲，是整個系統所有環節延遲的總和。只優化最明顯的 API 呼叫，就像修理一條漏水的管線時，只換掉最響的那個水龍頭一樣，治標不治本。

為什麼內部邏輯是效能陷阱？

AI Agent 的複雜性，使其內部邏輯特別容易成為效能陷阱。現代的自主 Agent 框架經常採用多步驟、有依賴性的執行鏈（chain-of-thought），一個任務可能被拆解成數個甚至數十個子任務，由不同的模組或模型實例接力完成。這種架構雖然強大，但也引入了大量的內部通訊與等待節點。

例如，一個 Agent 可能需要先呼叫搜尋工具、再呼叫程式碼生成工具、最後呼叫程式碼解釋工具。如果這些工具之間的調度邏輯設計不當——例如，使用了同步 I/O，或是在不必要的地方設置了過長的等待超時——延遲就會層層疊加，最終形成使用者眼中的「卡頓」。Claude Code 的案例正是如此，問題並非出在 Anthropic 的模型效能，而是其工具生態系內部元件的互動方式不夠高效。

AI 工具觀測性，該從何開始建立？

要有效管理 AI 工具的效能，建立一套完整的觀測性系統至關重要。這不僅是事後除錯的工具，更是事前設計與持續改善的基礎。以下是幾個實務的起點：

1. 全面的日誌與追蹤（Logging & Tracing）： 不要只記錄 API 的請求時間。在任務流程的每一個關鍵節點（如 RAG 檢索開始/結束、提示詞生成完畢、Agent 排程開始/結束）都留下帶有時間戳的結構化日誌。對於更複雜的微服務架構，應導入像 OpenTelemetry 這樣的標準，實現分散式追蹤，將一次請求的完整生命週期串連起來。
2. 關注長尾延遲（Tail Latency）： 平均延遲往往會掩蓋少數使用者的極端不良體驗。你應該監控 P95 或 P99 延遲，因為這些指標更能反映系統的穩定性與最壞情況下的表現。一次長達 1 分鐘的卡頓，足以摧毀使用者對產品的所有信任。
3. 定義明確的服務等級目標（SLO）： 為你的 AI 功能設定具體的效能目標，例如「95% 的 RAG 檢索應在 500ms 內完成」或「99% 的聊天回應應在 3 秒內開始串流」。有了明確的 SLO，你才能客觀地判斷系統效能是否達標，並在偏離軌道時觸發警報。

總結來說，當面對 AI 工具的效能問題時，我們需要抵抗那種將一切歸咎於模型 API 的誘惑。真正的瓶頸，往往隱藏在我們自己打造的系統內部。唯有透過系統化、數據驅動的觀測方法，我們才能剝開層層抽象，找到問題的根源，進而打造出真正可靠、高效且值得信賴的 AI 應用。

延伸閱讀

• SRE fundamentals: SLIs, SLOs and error budgets (Google Cloud Blog)
• Optimizing RAG: A Guide to Retrieval and Generation (Pinecone)
• OpenTelemetry Documentation (OpenTelemetry)
• A Survey on Large Language Model based Autonomous Agents (arXiv)

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。