5 個適用於長時間運行 AI Agent 的設計模式

開發人員花費數週時間來完善 Prompt Engineering、工具呼叫（Tool calling）以及回應延遲。但當你的 Agent 需要持續運行五天時，這些努力都顯得無關緊要。

在生產環境中真正重要的工作流程（例如處理數千份保險理賠、執行為期一週的銷售序列、跨系統核對財務資料），並非單一對話輪次所能涵蓋。這些任務需要的是數天，而非數秒。

當你嘗試構建這些長時間運行的 Agent 時，你會發現大多數 Agent 架構都是無狀態的。它們在每次互動時都必須從資料庫中重建上下文。這導致它們遺失了推理鏈、細微訊號以及那些讓 Agent 前次決策顯得合理的信心梯度（Confidence gradients）。

在 Cloud Next 26 大會上，我們宣布 Agent Runtime 現在支援可維持狀態長達七天的長時間運行 Agent。在本文中，我們將分享五個使用 Agent Runtime 構建長時間運行 Agent 的關鍵設計模式。

作者：@addyosmani 與 @Saboo_Shubham_

以下是將生產系統與演示（Demo）區分開來的五個設計模式。

模式 1：檢查點與恢復 (Checkpoint-and-Resume)

在多日工作流程中，最常見的失敗模式是上下文遺失。假設一個 Agent 在四小時內處理了 200 份文件，卻在第 201 份文件時發生錯誤。如果沒有檢查點（Checkpointing），你就必須從頭開始。

Agent Runtime 上的長時間運行 Agent 會在安全的雲端沙盒中維護持久的執行狀態。Agent 擁有對 bash 指令與沙盒檔案系統的完整存取權，因此你可以將中間結果寫入磁碟、維護處理日誌，並從失敗中恢復。

請將你的 Agent 視為一個長時間運行的伺服器程序，而不是一個請求處理器。就像你構建處理數百萬筆記錄的資料管道一樣：記錄檢查點進度、處理部分失敗、確保冪等性（Idempotency）。

以下是如何使用 Google Agent Development Kit 構建一個在每個批次後進行檢查點的文件處理 Agent：

from google.adk import Agent, ToolContext

class DocumentProcessor(Agent):
    """使用檢查點與恢復處理大型文件集。"""

    async def process_batch(self, docs: list, ctx: ToolContext):
        checkpoint = self.load_checkpoint()  # 從上次位置恢復
        start_idx = checkpoint.get("last_processed", 0)

        for i, doc in enumerate(docs[start_idx:], start=start_idx):
            result = await self.classify_and_extract(doc)
            self.results.append(result)

            # 每 50 份文件建立一次檢查點
            if (i + 1) % 50 == 0:
                self.save_checkpoint({
                    "last_processed": i + 1,
                    "partial_results": self.results,
                    "timestamp": datetime.now().isoformat()
                })

        return self.compile_final_report()

請注意檢查點的粒度。不要在每份文件後都存檔（太浪費），也不要只在最後才存檔（風險太高）。每批次處理 50 份文件是在耐用性與開銷之間取得的平衡。具體的數字取決於每個工作單元的成本高低。

模式 2：委派核准 (Human-in-the-Loop)

每個框架都宣稱支援 Human-in-the-Loop（人機協作）。

但在實務上，大多數的實作方式是：將狀態序列化為 JSON，發送一個 Webhook，然後祈禱有人去檢查它。問題會迅速堆疊。JSON 序列化會遺失隱含的推理上下文，而通知訊息又會與數十個警報競爭。

當人類在數小時後回應時，Agent 必須進行反序列化、重新建立上下文，並祈禱期間沒有任何變動。

長時間運行的 Agent 處理方式則不同。當 Agent 觸及核准閘門時，它會暫停在當前位置。完整的執行狀態會保持不變：推理鏈、工作記憶、工具呼叫歷史記錄以及待處理的動作。

以下是實際運作的樣子：

關鍵細節在於：第 8 小時到第 32 小時對 Agent 來說是停滯時間，但對人類來說是活躍時間。Agent 在暫停時不消耗任何運算資源。次秒級的冷啟動意味著恢復時不會有任何延遲懲罰。

Mission Control 提供了讓這種規模化管理變得可行的收件匣。通知被分類為「需要你的輸入」、「錯誤」與「已完成」。如果你正在管理二十個長時間運行的 Agent，你不需要在 Slack 頻道中大海撈針來找出哪些需要注意。

模式 3：記憶分層上下文 (Memory-Layered Context)

一個為期七天的 Agent 需要的不僅僅是會話狀態。它需要記住來自先前會話的資訊、幾週前的使用者偏好，以及任何單一對話都無法包含的組織背景資訊。

這就是 Memory Bank 與新的 Memory Profiles 協同工作的地方。

Memory Bank（現已開放給所有人使用）能從對話中動態生成並整理記憶，並按主題分類。Memory Profiles 則增加了對特定、高準確度細節的低延遲存取。你可以將 Memory Bank 視為長期記憶，將 Memory Profiles 視為工作記憶。

但大多數開發人員在進入生產環境前沒預料到的一個問題是：記憶漂移（Memory drift）。你的 Agent 行為不僅由其程式碼與 Prompt 決定，還受到累積經驗的影響。如果一個 Agent 從幾次非典型的互動中「學會」了某種程序捷徑是可行的，它可能會開始廣泛地應用該捷徑。如果多個 Agent 對共享記憶池進行讀寫，不同工作流程之間的資料洩漏就會成為真正的風險。

你不能讓 Agent 在沒有監管的情況下寫入向量資料庫。你需要像管理微服務一樣管理它們。這就是 Agent Identity、Agent Registry 與 Agent Gateway 的作用。它們將標準的基礎設施概念引入了 Agent 的生命週期：

Agent Identity 的運作方式類似於 Agent 的 IAM。正如微服務需要服務帳戶一樣，Agent 也需要一個加密身份，用以精確決定它被授權存取哪些記憶庫與工具。

Agent Registry 的運作方式類似於服務發現（Service discovery）。當你有數十個長時間運行的 Agent 時，你需要一個集中式的方法來追蹤哪些 Agent 是活躍的、它們正在執行哪個版本的 Prompt 與程式碼，以及它們當前的執行狀態是什麼。

Agent Gateway 的運作方式類似於為 LLM 量身打造的 API Gateway。它位於 Agent 與其記憶、工具之間，根據組織政策評估請求。如果 Agent 試圖將 PII（個人識別資訊）提交到其長期 Memory Bank，Gateway 就會封鎖該交易。

請從第一天起就將審計功能構建到你的記憶層中。問題不僅是「我的 Agent 在做什麼？」，而是「我的 Agent 正在記住什麼，以及這如何改變了它們的行為？」

模式 4：環境處理 (Ambient Processing)

並非每個長時間運行的 Agent 都需要與人類互動。有些是環境型的（Ambient）。它們監控事件、處理資料串流，並在背景採取行動，無需任何使用者提示。

批次與事件驅動的 Agent 直接連接到 BigQuery 資料表與 Pub/Sub 串流。

這是一個具體的例子：一個在使用者產生內容時即時處理的內容審核 Agent。

這個 Agent 可以運行數天。它不需要等待有人要求它審核內容。它會在事件到達時進行處理，維護關於趨勢與模式的自身狀態，並且只在必要時才進行升級處理。

這裡重要的架構決策回到了模式 3 中的治理層。

不要將內容政策硬編碼到 Agent 中。請在 Agent Gateway 中定義它們，並由 Agent 在執行時強制執行。當政策變更時，你只需更新一次 Gateway，所有環境型 Agent 就會採用新規則。Agent 的身份（來自 Agent Identity）決定了哪些政策適用於它，而 Registry 則追蹤哪個版本的 Agent 正在針對哪組政策集執行。

這種分離至關重要，因為環境型 Agent 會在無人監督的情況下長時間運行。如果你硬編碼政策，每次政策變更都需要重新部署每個 Agent。如果你透過 Gateway 將政策外部化，你只需更新一次，整個 Agent 艦隊就會自動適應。

模式 5：艦隊編排 (Fleet Orchestration)

最後一個模式是關於將多個長時間運行的 Agent 作為一個協調的艦隊來管理。在生產環境中，你很少會讓單一 Agent 獨自工作。你通常會擁有一個協調者 Agent，將子任務委派給專業 Agent，每個 Agent 根據不同的持續時間獨立運行。

考慮一個銷售開發序列：

每個專業 Agent 都有自己的 Agent Identity（確保它只能存取所需的工具與記憶）、透過 Agent Gateway 進行的政策強制執行（確保 Outreach Agent 無法存取屬於 Scoring Agent 的財務資料），以及在 Agent Registry 中的專屬條目（以便你追蹤整個艦隊的版本與執行狀態）。

協調者維護全域狀態並處理專業 Agent 之間的交接。這與分散式系統中使用了數十年的協調者/工作者模式相同。新的地方在於 ADK 原生支援這種模式，透過以宣告式定義協調邏輯的圖形化工作流程來實現。

將每個專業 Agent 視為獨立單元的操作優勢在於，你也可以獨立更新它們。

如果你的 Scoring Agent 的排名邏輯需要改進，你可以部署新版本，透過 Agent Observability 監控其效能，並僅在結果穩定時才進行推廣。而且由於每個 Agent 都在自己的容器中運行（支援 Bring Your Own Container 以滿足你現有的 CI/CD 與安全需求），一個專業 Agent 的錯誤部署永遠不會連帶影響到其他 Agent。

選擇正確的模式

這些模式是可以組合使用的。一個合規系統可能會使用「檢查點與恢復」來處理文件，使用「委派核准」來設置審核閘門，使用「記憶分層上下文」來處理跨會話知識，並使用「艦隊編排」來協調專業 Agent。

關鍵問題是：你的 Agent 需要執行的最長不間斷工作單元是什麼？如果是幾分鐘，你可能不需要長時間運行的 Agent。如果是數小時或數天，那麼這些模式就是你的起點。

開始使用

長時間運行的 Agent 現已在 Gemini Enterprise Agent Platform 上提供。使用 ADK 構建，部署在 Agent Runtime 上，並透過 Mission Control 進行監控。7 天持久性、人機協作核准以及長期記憶的結合，正是將 Agent 從聊天機器人轉變為自主工作者的關鍵。

從這裡開始：https://cloud.google.com/gemini-enterprise/agents

🚢 將這些模式付諸實踐：Google for Startups AI Agents 挑戰賽

不要只閱讀關於 Agent 架構的內容——動手構建它。我們邀請新創公司參加為期 6 週的全球挑戰賽，在 Gemini Enterprise Agent Platform 上構建、優化或重構 AI Agent。你將獲得 500 美元的雲端額度、完整的平台存取權，以及爭奪 90,000 美元獎金池的機會。

立即註冊，開始構建！