AI 代理人的延遲：為什麼它回應要等 30 秒
請求接收與前置處理
0.2 – 1 秒
身份驗證、額度檢查、內容安全掃描、格式驗證
上下文組裝
0.5 – 3 秒
系統提示、歷史對話、長期記憶檢索、RAG 向量搜尋
規劃與第一輪推理
2 – 8 秒
拆解任務、決定工具、產生思考步驟或計畫
工具呼叫
1 – 15 秒
搜尋引擎、票價 API、地圖服務、程式執行，可能串行執行多次
結果整合與第二輪推理
3 – 10 秒
把工具回傳的雜亂資料整理成可回答的內容
自我檢查與重試
0 – 10 秒
驗證答案是否滿足約束、發現錯誤則重新規劃
輸出生成
0.5 – 3 秒
組織成最終格式，串流或一次性回傳
把最保守的數字加起來，你已經得到將近 8 秒；把中間值加起來，很容易就突破 25 秒；如果中間有任何一步需要重試，30 秒甚至 45 秒都不奇怪。所以那個「30 秒」不是玄學，它是好幾個環節疊加出來的結果。
1-3 延遲是可見的思考，但問題是使用者看不到它
這裡有個關鍵的體驗問題：延遲本身不是問題，看不見的延遲才是問題。
當一個人在等電梯時，如果樓層指示燈會跳，他願意等 30 秒；如果指示燈壞了、電梯也沒聲音，他 10 秒就開始不耐煩。AI 代理人的延遲體驗完全一樣。多數產品把「思考過程」藏在後端，前端只留一顆轉圈圈，使用者的心理時鐘就會被無限放大。
所以第一部分要下的結論是：那 30 秒有它的物理來源，值得被理解；但與此同時，產品也確實有責任讓這段等待「有內容」。這兩件事並不衝突。
二、延遲的六大來源：時間到底花在哪裡
接下來我們把延遲拆成六個主要來源。這六個來源彼此會疊乘，不是相加，這也是為什麼同樣是「一句話的請求」，有時候 3 秒、有時候 30 秒。
2-1 推理鏈的長度：思維鏈、反思與自我修正
第一個、也是最常被低估的來源，是「模型自己想了多久」。
現在的 Agent 普遍採用「先規劃、再執行、後檢查」的模式。它會先產出一串內部推理，決定要做哪幾步；執行完之後，可能還會再跑一輪「這樣對嗎？有沒有漏掉使用者的條件？」這種反思步驟。每一次反思，都是一次完整的模型推論，都要重新吃進上下文、重新產生 token。
問題在於，這些 token 對使用者是不可見的。你看到的是「30 秒後蹦出答案」，但實際上模型可能已經在後台寫了兩三千字的內部思考。以目前主流模型的生成速度來看，每秒幾十個 token 是常態，光是把思考寫完，十幾秒就過去了。
更麻煩的是「重試」。如果 Agent 發現第一次呼叫工具拿到的資料不完整，它會重來一次；如果發現答案違反了你設定的約束（例如超出預算），它也會重來。每一次重試都是新的推理輪次，延遲於是被放大成兩倍、三倍。
2-2 工具呼叫的往返：每一次 API 都是一次賭注
第二個來源是外部工具。Agent 的價值有一大半來自「它會用工具」，但工具也是延遲的主要來源之一。
一次工具呼叫不是「呼叫一次 API」這麼簡單，它包含：模型產生工具名稱與參數、系統解析並驗證參數、發出 HTTP 請求、等待對方伺服器回應、把回應轉成模型看得懂的格式、塞回上下文。這整條鏈路上任何一環慢了，使用者就得多等。
而且 Agent 常常是「串行」呼叫的：先搜尋、再根據搜尋結果決定要不要查票價、查完票價再查天氣。三步串行，每一步各兩秒，光工具就吃掉六秒。如果你的 Agent 還做了「多來源交叉比對」，同一個問題可能呼叫五、六次不同的 API，延遲自然往上疊。
實務觀察：在多数 Agent 系統中，工具呼叫的總耗時往往占整體延遲的 30% 到 50%，而且這部分完全不受「換更快的模型」影響。也就是說，只優化模型是沒有用的。
2-3 檢索與記憶：RAG、向量搜尋與上下文膨脹
第三個來源是「找資料」。為了讓 Agent 記得你是誰、記得上次聊到哪裡、記得公司內部的規章文件，系統通常會在每次請求前做檢索：把使用者的問題轉成向量、到向量資料庫裡比對、取出最相關的幾段內容、塞進提示詞裡。
這一步的延遲常常被忽略，因為它「看起來只是查個資料庫」。但實際上：向量化本身要呼叫嵌入模型、相似度搜尋在資料量大時會變慢、取回的內容還要重新排序（reranking），而 reranking 往往又是另一次模型推論。
更隱形的成本是「上下文膨脹」。當你把檢索到的五段文件、十輪對話歷史、加上工具回傳的原始 JSON 全部塞進提示詞，輸入長度可能從兩千 token 暴漲到三萬 token。模型處理長輸入的前置時間（prefill）會顯著增加，這就是為什麼有些 Agent 明明只回你兩句話，卻還是要等十幾秒。
2-4 模型規模與硬體排隊：參數不是免費的
第四個來源比較直觀：模型越大、越慢。一個千億參數等級的模型，跟一個三十億參數的模型，生成速度可能差上一個數量級。但延遲不只在於「跑得多快」，還在於「排不排得到隊」。
推論服務通常會把多個請求批次處理（batching）以提升 GPU 利用率，這對吞吐量是好事，對單一使用者的延遲卻可能不利——你得多等前面的請求跑完。在尖峰時段，光排隊就可能吃掉好幾秒。這也是為什麼同一個 Agent，早上九點和凌晨三點的體驗可能完全不同。
2-5 網路與串流：TTFT 與 TPOT 的差別
第五個來源是網路與串流機制。這裡有兩個常被混為一談的指標：
對聊天機器人來說，TTFT 幾乎決定了一切體感，因為使用者只要看到字開始跳，就會覺得「它在動」。但對 Agent 來說，麻煩在於它常常不能串流：在還沒呼叫完工具、還沒整合完資料之前，它根本沒有東西可以輸出。於是 TTFT 被拉得很長，而你連「第一個字」都等不到。
這也是為什麼 Agent 的體驗優化，不能照抄聊天機器人的做法。聊天機器人優化 TTFT 就好，Agent 必須另外設計「中間狀態」的回饋。
2-6 安全與權限層：那些你看不見的守門人
第六個來源最容易被忽略，卻在企業場景裡佔比很高：安全檢查。
一次請求進來，系統可能要先做內容安全分類（避免提示詞注入）、做權限檢查（這個使用者能不能存取這份文件）、做輸出過濾（避免洩漏敏感資訊）、做稽核記錄（誰在什麼時候問了什麼）。這些步驟每一個都可能是獨立的小模型或規則引擎，加起來又是一兩秒。
在消費級產品裡，這一層通常比較輕；但在金融、醫療、法律的 Agent 部署裡，這一層往往是最重的。有些合規要求甚至會強制「人工覆核」，那延遲就不是 30 秒，而是 30 分鐘了。
三、30 秒合理嗎？場景決定答案
拆完六個來源之後，我們終於可以回答那個問題：30 秒到底合不合理？答案是——取決於你在等什麼。
3-1 使用者的心理門檻：2 秒、10 秒、30 秒
人對等待的容忍度，大致可以分成幾個區間：
所以 30 秒本身不是罪，問題是「30 秒的空白」才是罪。同樣是 30 秒，有進度提示的等待，體感可能只有 10 秒；沒有提示的等待，體感會膨脹到 60 秒以上。
3-2 四種典型場景的容忍度對照
場景
合理延遲上限
原因
客服即時問答
3 – 5 秒
使用者正在對話流中，等待會中斷節奏
程式碼補全／助理
1 – 2 秒
與編輯器操作同步，延遲直接影響打字體驗
資料研究與報告生成
30 秒 – 3 分鐘
任務本身有價值，使用者預期它「需要時間」
背景批次任務（如每日摘要）
數分鐘到數小時
非同步進行，完成後通知即可
換句話說，如果你的 Agent 是在做「研究型任務」，30 秒不但合理，甚至偏快；但如果你的 Agent 只是要回答「你們的營業時間到幾點」，那 30 秒就是徹底的設計失敗——因為這種問題根本不該動用 Agent，也不該動用大模型。
四、把 30 秒壓到 5 秒：工程實戰清單
理解了來源，就可以對症下藥。以下按照架構層、模型層、體驗層三個方向整理，這也是多數團隊實際會動手的順序。
4-1 架構層：平行化、快取與非同步
第一，能平行就不要串行。很多 Agent 的延遲來自「本來可以同時做的事，卻排隊做」。查天氣和查票價之間沒有依賴關係，就應該同時發出。把一個五步串行流程改成「兩步串行、三步平行」，延遲可能直接砍半。
第二，快取是最便宜的加速。使用者的問題有大量重複性：同一份文件被反覆檢索、同一組工具結果被反覆呼叫。把檢索結果、工具回應、甚至完整的回答做多層快取（語意快取尤其有效），命中率高的時候延遲可以降到幾乎為零。
第三，把「不必現在做」的事移出去。記憶整理、日誌分析、摘要壓縮這些工作，不需要卡在請求路徑上，應該丟到背景佇列。使用者只等他真正需要的那一段。
4-2 模型層：路由、量化與推測解碼
模型路由（routing）是最有效的策略之一：不是每個請求都需要最強的模型。簡單的分類、抽取、格式轉換，交給小模型甚至規則引擎就好；只有真正需要複雜推理的那一步，才叫出大模型。實務上這可以省下 40% 以上的平均延遲。
量化與蒸餾則是從模型本身下手。把模型壓到較低位元精度、或用蒸餾出的小模型替代，生成速度通常會有明顯提升，代價是些許品質損失。對於「中間步驟」（例如決定要不要呼叫工具）來說，這筆交易通常划算。
推測解碼（speculative decoding）則是近年的熱門手法：用一個小模型先「猜」後面的 token，再由大模型一次驗證。在輸出格式相對固定的場景（例如 JSON、表格），加速效果特別明顯。
4-3 體驗層：串流、進度條與漸進式揭露
前面兩層是「真的變快」，這一層是「感覺變快」，但它的投資報酬率往往最高。
第一，把中間狀態顯示出來。「正在搜尋資料……」「已找到 12 個來源，正在比對……」「正在整理成表格……」這幾行字的成本幾乎為零，卻能把 30 秒的空白填滿，使用者不會覺得系統死了。
第二，漸進式揭露（progressive disclosure）。不要等全部完成才輸出。先把「已經確定的部分」丟出來，例如先給行程大綱，再補上票價細節。使用者看到東西在長出来，耐心會顯著提升。
第三，串流要串對地方。Agent 的串流不能只串最終答案，而要串「過程」。工具呼叫的開始與結束、每一輪推理的結論，都可以是串流的一部分。
4-4 不要把延遲藏起來，要把它可視化
這裡想特別強調一個觀念：隱藏延遲比延遲本身更傷信任。
有些產品為了「看起來很快」，會在後端還沒準備好時先吐出一個「好的，我來幫您處理」的假回應，然後又卡住。這種做法短期內降低了 TTFT，長期卻讓使用者覺得「它很會裝，但沒做事」。
比較好的做法是誠實地把時間結構攤開：告訴使用者這個任務預期需要 20 到 40 秒、目前進行到第幾步、哪一步比較慢。使用者對「已知的等待」容忍度，遠高於「未知的等待」。
五、延遲與品質的取捨：慢有時才是對的
講了這麼多優化，最後要談一個反向的觀點：並不是所有延遲都該被消滅。
5-1 值得等待的三種情況
第一，需要交叉驗證的答案。醫療、法律、財務這類場景，Agent 多花 20 秒去比對三個來源、檢查有沒有矛盾，遠比 3 秒給你一個錯誤答案有價值。這裡的延遲不是成本，是保險。
第二，需要規劃的任務。一趟旅行、一份專案計畫、一組行銷方案，這些任務的本質就是「想清楚再動手」。逼它 3 秒交卷，你只會得到一份模板化的廢話。
第三，需要工具串接的流程。如果 Agent 幫你實際訂了票、送了單、跑了程式，那它花的時間是在「真的做事」，而不是在「想要怎麼講話」。這種延遲應該被視為執行時間，而不是回應時間。
5-2 快，但錯得理直氣壯：最糟的體驗
反過來說，有一種體驗比慢更糟：很快，但錯得理所當然。
使用者問了一個需要查資料的問題，Agent 沒有呼叫任何工具，直接根據訓練資料編了一個看起來很合理的答案，兩秒就回你。這種「快」其實是欺騙，而且代價會在後面才顯現——使用者照著做了，出事了，然後再也不信任這個產品。
所以在設計 Agent 的延遲策略時，真正的問題不是「怎麼變快」，而是「哪些步驟絕對不能省」。把不能省的步驟守住，把能省的步驟砍掉，剩下的時間才是合理的。
六、結語：等待的價值，取決於你等到了什麼
回到那個 30 秒。它之所以讓人煩躁，很多時候不是因為它長，而是因為我們不知道它在幹嘛。一旦你知道這 30 秒裡發生了什麼——檢索、規劃、呼叫工具、比對、驗證、重寫——你會發現它其實是一段相當忙碌的時間。
而對開發者來說，這 30 秒是一張體檢表。它告訴你哪一層最重、哪一個環節在拖後腿、哪一個步驟其實可以砍掉。真正的目標從來不是「把 30 秒變成 3 秒」，而是「把不必要的 20 秒拿掉，把必要的 10 秒講清楚」。
對使用者來說，判斷標準也很簡單：如果這 30 秒換來的答案，比你自己花 30 分鐘查到的更好，那它就值得；如果它只是把一句話講得比較長，那它就不值得。延遲本身沒有善惡，內容才有。
下次你在雅寶社區 · 頂客論壇看到有人抱怨「AI 又要等 30 秒」時，不妨先問一句：它在等什麼？是模型在思考、工具在回應，還是產品根本沒告訴你它在做什麼？這三個答案，對應的是完全不同的解法。
而如果你正在打造自己的 Agent，記得一件事：使用者不怕等，怕的是不知道為什麼要等。把等待的內容說清楚，那 30 秒就不再是延遲，而是一段被理解的過程。