Coding Agent 跑了 30 分鐘，到底在忙什麼？先看這四層

當你交給 Coding Agent 一項任務，它卻跑了整整 30 分鐘還沒有回應，你的第一個念頭可能是換一個模型，或是直接按下 /clear 重新來過。但其實有更聰明的方法：先拉出完整的 Task Trace（任務追蹤紀錄），從四個關鍵面向檢視 Agent 的運作瓶頸，才能真正對症下藥。第一層看的是模型實際花費的時間。Agent 在推理過程中的每一個 LLM 呼叫都會累積時長，有時候模型本身並沒有卡住，而是工具呼叫的等待時間太長。許多開發者誤以為模型回應慢就代表模型效能不足，但實際上，大型語言模型在生成回答後，往往需要等待外部工具回傳資料，這段「空轉」時間才是真正的瓶頸。

透過 Task Trace 檢視每一輪 LLM 呼叫的耗時，就能釐清究竟是模型推論速度太慢，還是工具回應延宕了整體進度。第二層則要追蹤 Tool 的長尾——哪一個外掛工具或 API 花掉了不成比例的時間？可能是網路延遲、回傳資料量過大，或是工具本身回應緩慢。舉例來說，當 Agent 呼叫一個搜尋引擎 API 或資料庫查詢時，若該端點穩定性不足，或回傳的內容包含大量冗餘資訊，就會大幅拖累整個任務流程。這個階段的診斷重點在於找出「異常耗時工具」，並針對該工具調整超時設定、快取機制，或改用更輕量的替代方案。第三層關注 Context 的成長曲線。

隨著對話輪數增加，Agent 的上下文會不斷膨脹，當歷史訊息超過模型的有效窗口時，不僅運算成本上升，回應品質也會下降。許多模型對上下文長度有硬性限制，一旦超越閾值，可能出現遺忘重要資訊、生成內容偏離主題等現象。透過 Task Trace 記錄每一輪的上下文大小變化，可以觀察到上下文是否以指數級成長，並適時採用摘要壓縮、滑動窗口或選擇性保留關鍵輪次等策略，避免上下文肥大到影響效率。最後一層是Agent 的實際輪數——它到底跑了多少輪對話？過多的來回試錯可能代表指令不夠明確，或是工具回傳的結果不如預期，導致 Agent 陷入重複修正的迴圈。

例如，當 Agent 生成了一個不正確的程式碼片段，它可能自行偵測到錯誤並再次呼叫工具修正，若修正方向仍然偏離目標，就會形成「修正→錯誤→再修正」的無窮循環。觀察輪數不僅能看出決策效率，更能反向回饋到提示工程設計：是否需要在初始指令中加入更詳細的步驟拆分？是否應限定最大重試次數？這四層檢視方法的核心價值在於，它讓開發者不需要急著更換模型或清除歷史，就能精準找出效能瓶頸來自模型本身、工具設定、上下文管理，還是 Agent 的決策邏輯。許多團隊在遭遇 Agent 長時間無回應時，往往先懷疑模型能力不足，而忽略工具層或上下文管理的問題。

但實際上，一個設計良好的 Agent 流程，若工具呼叫回應時間過長，即使換上最快的模型也難以解決根本問題。在實際操作上，取得 Task Trace 的方式因平台而異。部分 Agent 框架會自動輸出詳細的日誌，記錄每一輪 LLM 呼叫的開始時間、結束時間、使用的工具名稱、回傳資料大小以及上下文長度。開發者可以將這些日誌匯入視覺化工具，就能一目瞭然地看到哪個環節的耗時最長。例如，若發現某工具的平均回應時間高達 15 秒，而其他工具僅需 1 秒，那就應該優先優化該工具，而不是盲目調整模型參數。另一個常見的陷阱是上下文管理。

當 Agent 執行複雜任務，例如多步驟程式碼生成或跨 API 資料整合，每次對話都會累積先前的程式碼片段和偵錯資訊。若未設定清理機制，上下文可能在 10 輪內就膨脹到數萬 token，導致模型不僅計算變慢，還會在生成後續內容時偏離主題。此時，引入「摘要化記憶」或「關鍵輪次保留」策略，就能有效控制上下文的成長曲線。至於輪數過多的問題，往往源於任務指令過於模糊。一個好的提示應該明確描述目標、輸出格式、成功標準，甚至可以附上範例。同時，可以為 Agent 設定「失敗重試上限」，例如最多連續 3 次修正，若仍無法達到目標則停止並回報錯誤，避免 Agent 在無窮迴圈中浪費時間。

回到開頭的場景：當你再次看見 Agent 跑了半小時毫無動靜，不妨先靜下心來，打開 Task Trace 一一對照這四層。你會發現，很多時候問題不在於模型本身，而是工具延遲、上下文失控或決策輪數過多。只要針對發現的瓶頸進行微調，下一次任務可能只需要幾分鐘就能完成。這套方法不僅節省了開發者反覆嘗試的精力，更讓 Agent 的效能最佳化變得有跡可循，不再只是靠運氣或直覺除錯。