對於開發 AI Agent 的工程師來說，經常會陷入一個兩難的困境：生產環境需要「極高的穩定性」，而開發過程需要「極快的迭代速度」。
在生產環境中，一個複雜的 AI 工作流（AI Workflow）可能需要運行數十分鐘，涉及多次 LLM 調用與外部工具操作。如果過程中發生 Pod 重啟或網路閃斷，你絕對不希望從頭開始。因此，你需要一個具備「耐用執行」（Durable Execution）能力的重量級運行時（Runtime）。
然而，當你在調整 Prompt 或優化邏輯時，你需要的是一個能每小時運行數百次、秒級回饋的輕量級評估循環（Eval Loop）。如果你強行將 Eval 跑在重量級的生產運行時上，會被其持久化機制、任務隊列和分佈式開銷拖慢速度；反之，如果生產環境直接用 Eval 的輕量化實作，則完全失去了容錯能力。
本文將詳細分析 Brex 團隊如何透過 Runtime-Agnostic（運行時不可知） 的設計模式來解決這個矛盾。
核心矛盾：生產耐用性 vs. 快速評估
首先，我們需要定義兩個截然不同的需求場景：
生產環境的耐用執行 (Production Durability) 為了確保長時運行的 Agent 能夠生存，系統必須在每一步執行完畢後將結果持久化。這樣當進程崩潰或重新部署時，引擎可以透過「回放歷史」（Replay History）從最後一個完成的步驟恢復。這種機制雖然沉重，但對於運行 60 分鐘的深度研究 Agent 來說至關重要。
離線評估的快速迭代 (Fast Offline Evals) 在 Eval 階段，工程師會針對標記數據集（Labeled Dataset）運行數百次工作流，以評分 LLM 的輸出品質。這個過程應該是： 本地化且臨時的（Ephemeral）： 不需要持久化，不需要分佈式隊列。 可模擬的（Mockable）： 為了隔離變數，除了 LLM 之外的所有依賴（如 API 調用）都應使用固定數據（Fixtures）。
問題在於： 大多數 Agent 框架（如 LangGraph 或 Mastra）將「編排邏輯」（Orchestration Logic）與「運行時」（Runtime）緊密耦合。你的控制流被定義在框架的 SDK 或 DSL 中，導致你想跑 Eval 時必須啟動整個框架引擎，這造成了嚴重的性能開銷。
解決方案：Runtime-Agnostic 編排模式
為了打破這種耦合，Brex 採取的核心策略是：不再為特定的運行時編寫編排邏輯，而是針對一個「介面（Interface）」編寫邏輯，再由運行時去實現該介面。
核心架構：可移植的核心與適配器 這種模式將代碼分為三個層級： Agent 定義（Agents）： 僅包含純粹的業務邏輯函數與步驟介面（Steps Interface）。這裡不允許 import 任何運行時相關的庫（如 Temporal 或 Node.js 內建模組）。 平台層（Platform）： 定義基礎原語（Primitives）以及將邏輯對接到不同運行時的「適配器」（Adapters）。 入口點（Bin）： 分為生產環境 Worker 和 Eval 執行腳本。
技術實作細節 以一個「企業分類 Agent」（ClassifyBusinessAgent）為例，其編排邏輯被寫成一個簡單的異步函數：
typescript // 1. 定義介面：編排邏輯僅依賴此介面，不關心具體實作 export interface ClassifyBusinessSteps
// 2. 編排邏輯：純粹的業務流程，無運行時依賴 export const classifyBusinessAgent = defineAgentHandle() => , });
在這種設計下，enrichWithWebData 在生產環境中可能是一個分佈式任務，而在 Eval 環境中則是一個直接返回 Mock 數據的函數。
兩種適配器的運作機制
生產適配器：Temporal Temporal 是一個強大的耐用執行引擎，它要求工作流代碼必須是確定性的（Deterministic）（例如不能直接調用 Date.now() 或進行 I/O）。
對應關係： 適配器將 Steps 介面中的每個方法映射為 Temporal 的 Activity。 執行流程： 當編排邏輯調用 steps.foo() 時，適配器透過 Proxy 攔截請求，將其轉換為一個帶有 Agent 前綴的 Activity 名稱（如 classify_business_foo），並由 Temporal Worker 執行。 結果： 即使 Worker 崩潰，Temporal 也能根據歷史記錄恢復到最後一個 Activity，確保長時運行的穩定性。
評估適配器：In-Process Eval Eval 適配器極其簡單，它不需要沙箱、不需要隊列。
執行流程： 它直接實例化 Steps 的具體實現類，但注入的是 Mock 插件（例如 MockWebScraper）。 LLM 處理： 唯獨 LLM 調用保持真實，因為 LLM 的輸出品質正是 Eval 要測試的核心。 結果： 整個流程在單個進程中運行，速度極快，且能輕鬆集成到 Braintrust 或 Laminar 等評估平台中。
實務上的限制與工程判斷
這種解耦並非沒有代價，工程師在實作時必須注意以下限制：
強制性的編排限制 為了保證可移植性，必須嚴格遵守兩條規則，否則會導致「生產與評估不一致」： 禁止隱藏的非確定性： 編排邏輯中不能出現隨機數、時間戳或直接的 I/O 操作。所有非確定性行為必須封裝在 Steps 方法中。 禁止運行時特定 API： 不能在編排層 import Node.js 特有模組（如 fs 或 http）。
工程建議： 不要依賴開發者的自律，應透過建構時（Build-time）檢查來強制執行。例如，如果編排代碼意外依賴了 Node 模組，該 Bundle 應該直接編譯失敗。
權衡（Trade-offs） 失去原生功能： 編排邏輯無法直接調用 Temporal 的高級功能（如 Signals, Queries 或 Timers），因為這些功能在 Eval 運行時中不存在。若要使用，必須將其抽象化到 Steps 介面中。 開發成本增加： 每增加一個新功能，都需要在介面定義、生產適配器和 Eval 適配器中同步實作。 失去視覺化工具： 由於不再使用框架原生的圖形定義（如 LangGraph 的節點邊），無法直接使用框架內建的視覺化調試器。
總結與影響
透過將運行時視為「插件」，Brex 取得了顯著的工程成效： 消除 Eval-Prod Skew： 確保評估時測試的邏輯與上線時執行的邏輯在字節級別上完全一致。 提升可靠性： 長時運行 Agent 的成功率從 96% 提升至 99.9%，大幅降低了因基礎設施故障導致的任務失敗。 降低進入門檻： 新加入的工程師只需學習 TypeScript 介面，而不需要深入研究 Temporal 的確定性規則或複雜的 Eval SDK。
最終工程判斷： 如果你的項目只有一兩個簡單的 Workflow，這種架構過於沉重。但如果你擁有一個 Agent 陣列，且面臨嚴格的生產可靠性要求與高頻率的 LLM 評估需求，那麼將編排邏輯與運行時解耦是唯一能讓「穩定性」與「速度」停止內耗的方案。