從同步回應到非同步執行：Agent 的下一步是學會「等待」

當前主流的 AI Agent 架構，其核心互動模式仍是同步的「請求－回應」（Request-Response）。這意味著 Agent 在接收指令後，必須在單一執行緒內完成所有工作並立即回覆，否則就會逾時或中斷。我認為，這種模式限制了 Agent 處理真實世界複雜任務的能力。真正的自主系統不該只是個聰明的計算機，而應是一個能感知時間流逝、追蹤外部狀態、並在適當時機重新介入的執行核心。將輪詢（Polling）、等待與重試等非同步（Asynchronous）邏輯寫進 Agent 的 Skills 中，正是將 AI 從一次性對話工具，升級為能夠處理現實時間性的 Agent Runtime 的關鍵一步。

為什麼多數 AI Agent 仍停留在「一次性對話」？

目前許多 Agent 的實作，無論是基於 Microsoft Semantic Kernel 或是 LangChain，其工具使用（Tool Use）本質上都是同步的函式呼叫。Agent 接收一個任務，拆解成數個步驟，依序呼叫對應的 Skills 或 Tools，然後彙整結果回傳。整個過程發生在一個短暫的生命週期內，就像一次網頁請求。這種「觸發後遺忘」（fire-and-forget）的模式，對於查詢資料、生成文本等短時任務非常有效，但面對需要數分鐘、數小時甚至數天的長時程任務時，就顯得無能為力。

現實世界的任務充滿了等待：等待 CI/CD 管線完成部署、等待遠端伺服器批次處理數據、等待人類同事審批文件。一個只會同步回應的 Agent，在面對這些情境時只有兩種選擇：要嘛讓整個系統停滯空轉，直到任務完成（這在實務上不可行，通常會因逾時而失敗）；要嘛就是直接回報「任務已啟動」，然後將後續的追蹤責任丟還給使用者。這顯然不是我們對「自主 Agent」的期待。它缺乏對任務生命週期的管理能力，更像是一個指令轉發器，而非任務執行者。

如何讓 Agent 學會「等待」？從輪詢（Polling）開始

要打破這個僵局，我們需要賦予 Agent 在時間維度上運作的能力。一個直接且有效的方法，是將狀態監控與輪詢機制整合進 Agent 的 Skills 設計中。日本軟體公司エクスプラザ（explaza）的開發者 Shin 在一篇技術文章中，便展示了一個清晰的實作範例。

其核心概念是設計一個特殊的 Skill，這個 Skill 的職責不是完成某個動作，而是「監控」某個外部狀態。具體作法如下：

1. 啟動任務：Agent 呼叫一個 Skill 來啟動一個長時程任務（例如：開始一段影片渲染）。這個 Skill 不會等待任務完成，而是立即回傳一個任務 ID，並在某個共享位置（如 S3、資料庫或一個簡單的 JSON 檔案）建立一個狀態標記，初始值為 pending。
2. 輪詢狀態：Agent 接著觸發一個「狀態監控 Skill」。這個 Skill 會以固定的時間間隔（例如每 30 秒）去讀取那個狀態標記。
3. 條件觸發：這個 Skill 內部包含條件判斷邏輯。如果狀態依然是 pending，它會選擇「等待」並在下個週期再次檢查。如果狀態變為 completed，它則呼叫下一個處理結果的 Skill。如果狀態變為 requires_correction 或 error，它則能觸發修正或告警流程。

透過這種方式，等待與重試的邏輯被封裝在 Agent 的能力（Skills）之內，而不是由外部的排程系統或使用者來管理人力介入。Agent 因此獲得了初步的時間感知與任務追蹤能力。

將非同步機制內化為 Agent 的核心能力，是從「工具使用者」（Tool User）轉變為「任務生命週期管理者」（Task Lifecycle Manager）的思維躍遷。

將等待寫進 Skills，等於打造一個 Agent Runtime

這種基於輪詢的狀態管理，看似只是一個小技巧，但我認為它觸及了 Agent 架構的核心演進方向。當我們把時間性、狀態追蹤與條件觸發等能力，從外部基礎設施（如 AWS Step Functions 或 Cron jobs）移入 Agent 自身的決策迴圈時，Agent 本身就開始從一個無狀態的對話模型，演變成一個有狀態、持久運行的「執行系統」（Runtime）。

一個成熟的 Agent Runtime，其能力應遠超單純的 LLM 推理。它更像是一個輕量級的操作系統，能夠：

• 管理長時程任務：不僅啟動任務，更能持續追蹤其進展，直到終結狀態。
• 處理外部事件：能夠被動等待外部訊號（如 Webhook 或訊息佇列），而非只能主動查詢。
• 具備容錯與重試機制：在遇到暫時性失敗時，能根據預設策略（如指數退避）自主重試。
• 平行執行與協調：同時管理多個非同步任務，並在它們之間建立依賴關係。

從這個角度看，輪詢 Skill 只是實現非同步能力的第一步。更進階的架構可能會整合事件驅動（Event-driven）的設計，讓 Agent 訂閱特定事件，在狀態變化時由外部系統「喚醒」，而非不斷主動查詢，這在能源與運算效率上更具優勢。如 "Cognitive Architectures for Language Agents" 等研究中所探討的，一個強大的 Agent 需要的不僅是推理能力，更是一套完整的感知-決策-行動循環（Perception-Action Cycle），而這個循環必須能在時間的維度上持續運作。

總結來說，讓 AI Agent 學會「等待」，不僅僅是為了解決長時程任務的技術問題。它更深層的意義在於，我們正在將 AI 從一個被動的、同步的回應者，轉變為一個主動的、能在真實世界時間流中規劃與執行任務的參與者。這一步，是通往真正自主、可靠且實用的 AI 系統的必經之路。

延伸閱讀

• Agent Skillsを使って、手軽にポーリングで状態を監視して作業させる方法 (原始技術範例)
• LLM-powered Autonomous Agents (Lilian Weng 對 AI Agent 架構的經典分析)
• The Landscape of Emerging AI Agent Architectures for Reasoning, Planning, and Tool Calling (一篇關於 AI Agent 架構的近期綜述論文)

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。