我們信任那些每天都出包的 AI 代理——專訪 Temporal 的 Shy Ruparel

Temporal 的開發者倡導者 Shy Ruparel 主張，從「用得上 AI 代理」到「能穩定上線」，中間的落差是狀態管理問題，不是模型問題，而持久化執行（durable execution）正是補上這個落差的方法。他引用 Temporal 第二屆年度開發狀態調查、共 554 位工程師與工程主管的回覆，逐一拆解四個落差——使用與上線之間、信任與現實之間、原型與企業部署之間、看得見與救得回之間——接著示範一套九階段的撥款流程，在刻意讓 worker 崩潰的情況下仍能走完，且不會重複消耗 LLM 的 Token。這場演講的主體是調查資料加一場即時崩潰復原示範；標題裡的「信任」只是四項發現之一，並不是整場的主軸。

Ruparel 是站在廠商的位置說話，調查數字與示範都是 Temporal 自家的，讀者理應據此打折看待。但撇開這層利益關係，留下來的內容很具體：工程師點名的具體障礙（狀態追蹤、除錯、崩潰導致的重工）、大小公司在部署速度上的落差，以及一個可運作的例項，說明如何把代理框在一個掌握金流與狀態的確定性工作流程裡。

每天使用代理的人當中，有一半沒把代理跑在正式環境

調查前一年，每天使用代理的比例大約翻了一倍，但正式環境的採用並沒有跟上，兩者之間留下約 30 個百分點的落差。Ruparel 的說法是「在通往正式環境的路上，似乎總有東西會壞掉」。

受訪者組成本身是專業族群，不是業餘玩家：48.4% 有 11 年以上業界經驗，另有三分之一有六到十年經驗。組成涵蓋工程師、AI 工程師、資料工程師、平臺團隊與 IT 主管；三分之二位於美國，三分之一來自英國與 EMEA。Ruparel 也引用 KPMG 一份代理式 AI 報告，預估 2025 年企業生產力可增加 3 兆美元，其中金融服務業領跑——94% 的金融科技公司稱 AI 是其營運核心，但這些團隊中有 62% 因可靠性問題損失可觀的時間或營收。

85.5% 的團隊信任代理產出，同時 41.1% 每天遇到故障

信任與故障同時處於高檔，Ruparel 的解讀是：可靠性必須靠工程設計出來，而不是靠訓練消除。四分之一受訪者幾乎完全信任代理產出，多數人某種程度上信任，幾乎沒有人不信任——至少某種程度信任者達 85.5%。但另一面，41.1% 每天或更頻繁地遇到代理問題，16.4% 每小時就遇到。

反直覺的是，自認成功的團隊回報持續性問題的機率高出 1.7 倍。Ruparel 表示代理數量與問題頻率並無相關，並推測成功團隊只是更用力去找問題——這個假設他明白標記出來，留待明年調查驗證。他也坦言，換成他自己，不會用同樣的方式回答那道信任題。

「我們的目標不是零故障，對吧，當我們在正式環境使用代理時。重點是怎麼讓這些故障不造成任何代價？」

他也提到，40% 的團隊把安全性列為匯入自主代理的障礙，並把這個題目交給 Temporal 的 Mason 與 Keycard 的 Kim 在前一天的另一場工作坊處理。

大企業要花幾個月，但有一半團隊幾小時就上線

從原型到正式環境的速度，依公司規模出現明顯分岔，Ruparel 把慢車道歸因於可稽核性要求，而不是單純的官僚作業。

他點名銀行、保險公司與支付公司是慢車道背後的高監管工作：它們需要核准、稽核軌跡，以及不會弄丟一筆付款的系統。他的解讀是，那幾個月花在建立信任與可稽核性上，不過他也承認，調查並沒有把時間依原因拆解。

狀態追蹤與除錯，比模型本身更阻礙生產力

被問到什麼限制了生產力，受訪者點名的是營運管線，不是模型品質。跨服務追蹤狀態是最大障礙，佔 35.7%；其次是隔離與除錯問題，佔 30.9%；另有 22.2%——大約每五人一人——因為崩潰與重啟而丟失進度、重做工作。前一次調查中有 27% 稱自己的狀態管理很脆弱；兩次調查與題目不同，不能當成趨勢線，但 Ruparel 說故事是一致的：代理越貼近真實場景，狀態就越重要。

最引人注目的答案是：代理壞掉時，大家去哪裡求助——YouTube 排第一。Ruparel 的解讀是，當系統說不清楚發生了什麼事，除錯就會長成這個樣子。只有 13% 非常有信心能在規模化下觀測與除錯 AI 工作流程；而「看得見」與「救得回」之間的落差，用他的話說，就是「一個人凌晨兩點盯著 trace 看，然後手動修自己的狀態」。

崩潰的 worker 從事件歷史接續，不必重跑 LLM

示範是一套九階段的撥款流程——比正式環境會有的短——在筆電上跑真正的 Temporal 工作流程與真正的本地 LLM（Qwen 9B，曾一度口誤說成「36B, 9B」）。一位合成客戶要匯 2,500 美元給新收款人，金額不尋常，紀錄上還有一筆未解決的帳戶警示，因而觸發代理式詐欺調查：查詢客戶資料與撥款紀錄，並草擬一份簡報供人工核准。

flowchart TD
    A["驗證請求"] --> B["在銀行系統保留資金"]
    B --> C["外匯報價檢查"]
    C --> D["代理調查交易"]
    D --> E["代理草擬簡報供核准人審閱"]
    E --> F["人工核准或駁回（signal）"]
    F --> G["提交至銀行"]
    G --> H["撥款完成"]

Ruparel 在流程進行中殺掉 worker，接著在零個 worker 執行的情況下核准這筆交易。核准以 signal 的形式記錄在 Temporal 的事件歷史中。新 worker 啟動後，從最後一個成功事件重放，並接上這個 signal。他在等待銀行回應時第二次讓 worker 崩潰，重啟後工作流程完成。從頭到尾讀事件歷史：每個 AI activity 都只執行一次，核准 signal 在沒有 worker 執行時送達，銀行提交落在新的 worker 上，沒有任何東西從頭重跑。

架構上的重點是：工作流程掌握金流與狀態，AI 只獲得一次有界的嘗試機會去貢獻。就算模型失敗，撥款也會在沒有簡報的情況下繼續走；模型故障不會拖垮這筆交易。人工核准的計時器就算設成一年，程式碼也一樣。Ruparel 沒有寫任何一行崩潰復原的程式碼。

同一份事件歷史，既是除錯工具也是復原機制

Ruparel 把示範對回撥查中的障礙，聲稱一個工作流程就解決了其中七項：狀態、除錯、成本、重試、核准、長時間執行的工作，以及崩潰復原。

• 狀態： 在工作流程裡，狀態就是普通變數——不需要開發者自己搭資料庫或快取——崩潰後重放會精確重建。
• 成本： 因為代理狀態被保留，LLM 呼叫只跑一次。八成受訪者表示成本限制了他們使用代理的方式，而每次崩潰後重跑代理就是在燒 Token。
• 重試： 在設定中以政策宣告一次，套用到每次呼叫，程式碼裡不需要重試迴圈。
• 除錯： 在 UI 裡檢視的歷史，就是 worker 重放所用的同一份歷史，可觀測性與復原不再是兩份會逐漸脫節的紀錄。

他也提到 AI 工程師的工作流程：寫提示、跑一次、丟掉爛輸出、讓 Temporal 重試——模型輸出不佳就只是一次 activity 失敗，套用同一套重試政策。

Codex 與 Replit 的代理早已跑在持久化執行上

Ruparel 點名正式環境的使用者，證明示範不是玩具：OpenAI 的 Codex 跑在 Temporal 上，Replit 的代理也是。他引用 Replit 工程團隊的說法：代理任務做到很後面才撞上災難性錯誤，是很糟的使用者體驗——正是這場示範要防的故障。他請讀者參閱 Temporal 的開發狀態報告，演講中每個數字都出自該報告，並提到 Temporal 同仁會在攤位現場跑這個示範。

未解的張力在於：調查中最受信任的產出與最頻繁的故障，來自同一批受訪者，而 Ruparel 的解釋——成功團隊找得更用力——只是一個猜測，他自己也明確留待明年。另一條懸而未決的線是安全性：40% 稱之為自主化的障礙，而這場演講是繞過它，不是穿過它。廠商立場也意味著這裡最強的證據是結構性的，而非統計性的——事件歷史示篋展示了持久化執行能做什麼，調查則呈現實務工作者說哪裡痛，而兩者都由販售解方的那家公司端出。