Agent 的延遲問題跟傳統應用不一樣

傳統應用的延遲優化，多半是找出最慢的那個資料庫查詢或 API 呼叫。Agent 系統多了一個維度：有時候問題不是「某一步太慢」，而是「走了太多步」——同樣的問題，如果 Agent 繞了五輪才解決，即使每一輪都不慢，整體體驗依然很差。

三種典型的延遲模式

模式一：單一步驟過慢。 Span 樹裡某一個 execute_tool 明顯佔掉大部分時間，這是最單純的情況，優化方向就是那個工具本身（快取、非同步、換實作）。

模式二：步驟太多。 每一步都不慢，但總步數過多。這通常不是效能問題，是 Agent 設計問題——可能是 Prompt 引導不夠明確、可能是工具設計顆粒度太細（需要呼叫五個工具才能完成一件事，其實可以合併成一個）。

模式三：LLM 呼叫佔比過高。 chat span 加總起來佔了整體時間的大部分。這時候可以考慮的方向包括：是不是每一步都真的需要呼叫 LLM（有些判斷可以用規則處理）、能不能用較小的模型處理簡單判斷、能不能平行化。

用 Trace 資料做分析

Trace Explorer 提供的是單次執行的視覺化，但要找出模式需要看聚合資料。實務做法是把 Trace 資料匯出到 BigQuery（呼應 Day 7 提過的 Sink 設計），用 SQL 做聚合分析，例如：

• 各類任務的平均步數分布，找出哪類任務最容易「繞路」
• execute_tool span 依工具名稱分組的延遲分布，找出最慢的工具
• chat span 佔整體時間的比例趨勢，判斷是否有惡化

一個容易被忽略的指標：P95／P99

平均延遲會掩蓋問題。Agent 系統的延遲分布通常是長尾的——大部分請求很快，少部分特別慢。應該看 P95 或 P99 而非平均值，因為那些特別慢的執行，往往正是使用者體驗最差、也最需要處理的案例。Week 4 設計告警時，這點會再提到。

這篇的檢查清單

• [ ] 延遲分析是否有區分「單步過慢」與「步數過多」兩種不同問題？
• [ ] 是否已把 Trace 資料匯出做聚合分析，而非只看單次執行？
• [ ] 是否關注 P95／P99 而非只看平均延遲？