長時間執行的 AI 代理需要持久通道

OpenAI 的背景模式文件現在描述了一個常見的代理問題：推理任務可能需要數分鐘，開發者可以透過 ID 輪詢回應、取消回應，並從已記錄的序號恢復串流。¹

重點是什麼？

• 長時間執行的代理任務需要一個位址。用戶端必須能重新連回同一份工作，從已知游標接續串流，送出導向命令，取消執行，並檢查證據。
• 單靠輪詢只能提供很薄的契約。輪詢可以回報狀態，但嚴肅的代理工作還需要命令、事件歷史、可恢復串流、成果物、授權與檢查點。
• 持久執行只解決系統的一部分。Temporal 式工作流程能保存執行狀態與事件歷史，但使用者仍需要一個圍繞執行中工作的持久溝通介面。²³
• WebSockets 有幫助，但通訊端不是完整位址。連線中斷不應抹掉使用者回到代理任務的路徑。
• 產品介面很重要。使用者應該看到一個連貫的執行過程，包含證據、決策與下一步，而不是散落各處的紀錄，以及過度樂觀的狀態文字。

長時間執行的 AI 代理不適合舊式的請求－回應模型。一般請求有端點、回應與逾時限制。嚴肅的代理任務則有執行時間、事件歷史、中間成果物、使用者中斷、模型與工具狀態、取消規則，以及一位可能離開又回來的人。

缺少的物件不是另一則聊天訊息。真正缺少的是持久通道：給一段執行中工作使用的穩定位址。

我先前已主張，託管代理正在吸收執行環境基礎設施，而且代理執行追蹤正在成為執行環境契約。持久通道位於這兩個概念之間。追蹤證明發生了什麼。託管執行環境讓工作持續存活。持久通道則讓產品與使用者在工作仍然存活時，能與它溝通。

舊請求模型會在哪裡失效？

舊式 Web 模型假設運算會在一次請求內完成，或移到背景工作。資料庫保存持久狀態。應用程式伺服器維持無狀態。用戶端可以重新整理頁面、連到另一台伺服器，然後讀取同一筆資料庫列。

代理工作從三個方向拉扯這套模型。它可能執行數分鐘或數小時。它帶有無法乾淨化約成單一資料庫紀錄的流程狀態。它需要雙向控制：觀看、中斷、核准、改道、取消與恢復。

Zak Knill 把同樣的壓力命名為路由問題。他在 2026 年 5 月的文章中主張，長時間執行、有狀態、互動式的代理工作，需要一個可路由的基本單位，能定位正在執行工作的程序，而不只是保存輸出結果的資料庫。⁴這個框架最有用的地方在於：即使原本的通訊端、工作程序、分頁或程序已經消失，用戶端仍然想說：「把命令 Y 送到執行 X。」

背景工作仍然適合簡單任務。調整圖片大小、匯出發票或夜間同步，可能只需要排隊中、執行中、成功或失敗。當使用者需要在工作完成前導向它，代理工作就跨過了那條線。

為什麼輪詢不夠？

輪詢讓用戶端可以問：「完成了嗎？」但它沒有提供完整的互動契約。

OpenAI 的背景模式包含輪詢，因為輪詢解決的是逾時問題。文件告訴開發者，當狀態仍為 queued 或 in_progress 時，應擷取背景回應；等它抵達終止狀態後再停止。¹同一頁也提供取消，以及透過 sequence_number 游標恢復串流的能力，這已經超出基本輪詢，指向更完整的執行契約。¹

只停在輪詢的產品，通常會把代理狀態分散到太多地方：

輪詢可以保留為其中一條存取路徑。錯誤在於把輪詢當成產品契約。

持久通道應包含什麼？

持久通道是圍繞一次執行而命名的溝通契約。實作可以使用工作流程引擎、佇列、事件表、WebSocket、SSE 串流、發布／訂閱主題、託管代理會話，或混合這些元件。比起傳輸方式，產品契約更重要。

最小契約有 9 個部分：

每個事件都需要型別、序號、時間戳記、行為者、酬載參照與遮蔽政策。沒有這個結構，事件紀錄就只是另一份聊天逐字稿。

通道也需要品味。當使用者需要的是決策，就不要串流每個 token。不要把工具失敗藏在友善的載入動畫後面。不要把執行中的代理變成通知風暴。好的通道只呈現能幫助使用者信任、導向或停止工作的少數事件。

現有系統如何指向這個模式？

Temporal 為執行面提供了成熟詞彙。一次工作流程執行有事件歷史、重播、確定性的工作流程程式碼，以及用於外部世界工作的活動，例如 API 呼叫、資料庫查詢、LLM 呼叫與檔案 I/O。²Temporal 的 TypeScript 訊息傳遞文件把工作流程描述為可接收查詢、訊號與更新的有狀態服務。用戶端可以透過工作流程 ID 取得工作流程控制代碼、查詢狀態、送出訊號並執行更新。³

這個模型很自然地映射到代理工作。查詢回答「這次執行回報了什麼狀態？」訊號回答「請改變方向。」更新回答「執行一個受追蹤的變更並回傳結果。」事件歷史回答「發生了什麼？」團隊不一定需要 Temporal 才能借鏡這個形狀，但這個形狀給代理產品的詞彙，比「背景工作加聊天」更好。

Cloudflare Durable Objects 指向另一塊：可定位的協調。Cloudflare 將每個 Durable Object 描述為具有儲存空間的全域唯一實例，可用於跨多個用戶端的有狀態協調。⁵它的 WebSocket 文件描述了長時間存在的雙向連線，以及可在物件休眠時維持用戶端連線、並在訊息抵達時喚醒物件的休眠機制。⁶這不代表 Durable Objects 是通用代理執行環境。但它確實說明，為何可定位的協調物件很適合即時代理介面。

Anthropic 關於長時間執行代理的文章，補上了人類工作的那一面。文章指出，代理在跨越多個脈絡視窗時仍然吃力，並描述一種模式：後續會話持續做增量進展，同時留下清楚成果物供下一個會話使用。⁷持久通道應把這些成果物帶進產品介面，而不是埋在私人紀錄裡。

我會先建什麼？

我會先從一個小型執行服務開始，而不是宏大的編排平台。

建立一張 runs 資料表，保存擁有權、狀態、時間戳記與目前摘要。建立一張 run_events 資料表或串流，使用單調遞增的序號。大型酬載與成果物分開儲存，再由事件參照。新增一個可恢復串流端點，以及一個型別化訊號端點。讓取消具備等冪性。把每一次狀態轉換都寫進事件紀錄。

接著約束事件詞彙：

UI 現在可以呈現一個連貫的執行過程。使用者可以離開、回來、審查事件、檢查成果物，並從同一個位址導向工作。代理也能停止在文字裡宣稱成功，改把證據附到狀態轉換上。

團隊應避免什麼？

避免 3 種捷徑。

第一，避免純聊天逐字稿。聊天可以啟動工作並收集澄清事項。但它不應成為長時間任務唯一的執行環境物件。

第二，避免把原始 token 串流當成主要進度介面。Token 串流能幫開發者除錯延遲，但多數使用者需要的是里程碑、阻塞點、成果物與決策。持久通道仍可提供原始事件，供專家檢查。

第三，避免洩漏私人流程。公開產品介面應呈現證據，而不是私人提示詞、掛鉤內容、本機檔案路徑或內部評分機制。使用者需要足夠資訊來信任工作，但不需要知道讓工作得以完成的每個內部技巧。

這條隱私界線也適用於關於代理系統的公開寫作。分享契約。把私人機制留在私底下。

持久通道如何改變評估？

持久通道讓評估少一點表演性。

評估者不必只問最終答案聽起來是否合理，而是可以檢查整次執行：

• 這次執行一開始是否具備正確的擁有者、權限與範圍？
• 代理是否在行動前發出計畫？
• 每個聲稱存在的成果物，是否都來自已記錄事件？
• 失敗是否產生有用的檢查點？
• 使用者訊號是否以預期方式改變了執行？
• 取消是否以單一終止狀態結束？
• 最終報告是否引用事件紀錄中的證據？

這份清單把證據關口變成執行環境可以直接支援的東西。它也連到清理層：許多代理產品會因為能讓混亂的執行變得可理解、可恢復、可審查而勝出。

簡短總結

長時間執行的 AI 代理需要持久通道，因為使用者需要一條穩定路徑回到工作本身。輪詢可以回報狀態，但無法獨自承載完整契約。良好的代理執行需要工作流程 ID、有序事件、可恢復串流、型別化訊號、等冪取消、成果物參照、權限，以及可供人閱讀的檢查點。持久執行讓工作持續存活；持久通道讓使用者與產品能和它互動。

FAQ：長時間執行的 AI 代理與持久通道

長時間執行的 AI 代理需要 Temporal 嗎？

不需要。Temporal 提供團隊強大的工作流程詞彙與成熟執行模型，但持久通道契約可以在更簡單的基礎設施上運作。先從穩定的 run ID、有序事件、可恢復串流、型別化命令與成果物開始。等到重試、重播、計時器與營運規模足以證明其必要性，再移到工作流程引擎。

WebSockets 足以處理代理進度嗎？

不足。WebSockets 提供即時雙向連線。產品仍需要持久位址、事件歷史、重新連線游標、權限與終止狀態。通訊端可以承載通道，但不應定義整個通道。

輪詢一定不好嗎？

不是。輪詢適合簡單狀態檢查，也可以保留為備援路徑。問題出現在輪詢成為觀察、導向或恢復長時間代理執行的唯一方式時。

小團隊應該先建什麼？

建立一個 runs 資源，以及一份只能追加的 run_events 紀錄。事件紀錄有序號後，再新增可恢復串流。型別化訊號只開放給產品能安全履行的命令：核准、暫停、修訂、新增脈絡與取消。

代理執行事件中應包含什麼？

記錄狀態轉換、計畫、工具開始與結束、成果物建立、人類訊號、阻塞點、取消、失敗與完成。不要把敏感酬載放進行內事件文字。私人細節應存放在已遮蔽的參照後方，並加上存取檢查。

參考資料