Agentic 系統的回應可以從幾秒到幾分鐘不等，這是傳統 SaaS 的 UX 設計完全沒有準備好的延遲範圍。用戶不知道系統在做什麼、做了多久、還要多久——這種資訊真空是最快失去信任的方式。這篇拆解目前有工程佐證的幾個 UX 模式，以及在哪些環節必須讓人類介入。
SSE Streaming：讓輸出即時可見
**SSE（Server-Sent Events）**是最常見的 token-by-token 串流方式：LLM 生成的每個 token 立刻發送給 client，用戶看到文字「打出來」的效果，而不是等整個回應生成完才顯示。
技術層面：server 保持 HTTP 連接開啟，持續推送 data: 事件；client 用 EventSource API 或手動解析 ReadableStream 接收。Anthropic 和 OpenAI 的 API 都原生支援 streaming response。
2025 年的重要變動：MCP（Model Context Protocol）在 2025-11-25 的規格更新中，把傳輸層從 HTTP+SSE 改為 Streamable HTTP，讓 MCP server 可以用單一 HTTP endpoint 同時支援 POST（client→server）和選用的 GET SSE（server→client 推送）。這個改動對自建 MCP server 的團隊需要注意。
進度揭示：讓不確定性可見
對於多步驟的 agent 任務，只串流最終輸出文字不夠——用戶看不到系統在哪個步驟、用了哪些工具。Agentic Design Patterns 整理出幾個有工程實踐支持的模式：
Step disclosure（步驟揭示） 把 agent 的每個行動（思考、工具調用、工具結果）以折疊卡片顯示，用戶可以展開看細節。Perplexity 的「Sources」展開、Claude.ai 的工具調用展示都是這個模式的實例。好處是透明度高；缺點是步驟太多時 UI 會很複雜，需要設計「摘要行」讓用戶知道大致在做什麼，不必逐一展開。
Agent card（能力說明卡） 在任務開始前，清楚說明 AI 能做什麼、不能做什麼，以及它將會存取哪些外部服務或資料。減少用戶的期待落差；也是「信任建立」的一部分。
Planned presentation and approval（計劃→審核） 對於有副作用的操作（發 email、寫入資料庫、呼叫第三方 API），在執行前呈現計劃讓用戶確認。「我打算做以下三件事：[步驟列表]。確認後我會開始執行」。這是 human-in-the-loop 的具體 UI 型態，下面會更詳細討論。
「Slow AI」設計模式
當任務需要幾分鐘到幾小時時，「聊天視窗裡的 spinner」設計模式完全失效。這個情境有個名字：「Slow AI」設計模式，對應的 UX 思路是把它當作非同步任務：
- 提交後顯示任務 ID 和預估完成時間（如果可以估的話）
- Email 或 push notification 在完成時通知用戶
- 用戶可以離開頁面，回來後從
/jobs/{id}繼續查看進度 - 可中斷：提供「取消任務」的按鈕，並且能真正地中止 agent loop（不只是在 UI 上隱藏）
「Slow AI」是 UX Magazine 等設計媒體在 2025 年開始廣泛討論的設計問題，但目前業界的工程實作還非常分散，沒有確立的標準。
Human-in-the-Loop：何時、怎麼問
不是每個步驟都要人類確認——那會打敗 automation 的目的。但有些決策確實需要人類判斷，特別是：
- 不可逆操作：刪除資料、發送對外通訊、完成金融交易
- 高信心門檻操作：當 LLM 對某個判斷的信心低（例如抽取出的欄位有多個可能值），讓人類選擇
- 超出授權範圍：agent 被要求做一件超出預設工具範圍的事，應該停下來詢問而不是嘗試繞過
工程上，human-in-the-loop 通常實作為「任務暫停等待 approval」：agent loop 在到達某個 checkpoint 時，把當前狀態存入資料庫，觸發一個 notification（email、Slack、UI badge），等用戶透過 API endpoint 回傳 approve/reject，再繼續。這需要 orchestration 框架支援 checkpoint persistence（LangGraph 有這個功能）。
confirmation bias 的風險：研究顯示，當系統呈現一個計劃請求確認時，用戶傾向於同意而不仔細看內容（automation bias）。設計上要讓審核介面強制用戶看到關鍵資訊，而不只是「確認/取消」按鈕。這是 HCI 研究有記錄的現象，但在 AI 代理場景的具體影響程度還沒有廣泛的生產數據。
錯誤狀態的設計
Agentic 系統的錯誤比傳統 SaaS 更難設計，因為：
- 部分完成（完成了步驟 1-3，在步驟 4 失敗）
- 失敗原因可能不確定（LLM 幻覺？工具 API timeout？網絡問題？）
- 重試可能有副作用（步驟 1-3 的操作已發生）
最低要求：顯示「任務在第幾步失敗」「原因是什麼（如果能判斷）」「可以重試還是需要人工介入」。對於部分完成的任務，明確標示哪些步驟已成功完成，避免重試造成重複操作。
延伸
- Agent loop 的技術基礎 → Orchestration 與 Agent Loop
- 結構化輸出失敗時的 UX 處理 → 結構化輸出與 LLM 可靠性
- 延遲問題的根本來源 → 限制、取捨與 Demo 不等於 Production
- 全景與閱讀路徑 → AI Agentic SaaS 專欄首頁