打造能從失敗中活下來的 AI Agent

開場:先讓整個房間站起來(約 01:04:39–01:06)

在連聽了好幾場 AI 演講之後,Advolodkin 一上台先請全場站起來,找兩個人擊掌、看著對方的眼睛說「你超棒的」,然後拍了一段全場歡呼的自拍影片(第一次他嫌太冷淡,要大家再來一次、聲量五倍)。自我介紹:Temporal 的 developer advocate、狗爸爸、直排輪玩家,狗叫 Mia。

他說明工作坊的哲學:動手做才會記得住,被動聽留不下東西。原訂四個主題——agentic AI 系統的基礎(並實作一個)、用 agentic framework(OpenAI Agents SDK)蓋、human in the loop、以及 orchestrate micro-agents——他一開始就坦白「大概講不完,但沒關係,結束後我會給你們 GitHub repo」。

主題一:什麼是 agentic loop(約 01:07)

LLM 能對我們給它的 context 進行推理,但它缺的是「資訊不夠時自己去採取行動」的能力。agent loop 提供的就是這個:讓 LLM 能夠在自身之外行動。

流程是:給定 instruction 與目標(他的例子:「你是旅遊助理,幫我找一班去邁阿密的班機,訂票付款前先跟我確認」)→ 把 context 交給 decision maker(也就是 LLM)→ LLM 判斷:我的資訊夠不夠?夠就給最終答案,不夠就呼叫工具。工具由 harness 定義、有時由你定義;你只負責告訴 LLM 這些工具存在,由 LLM 決定什麼時候用。拿到工具輸出後再判斷一次,不夠就繼續這個蒐集資訊的迴圈,直到能安心給出答案。

他也現場做了一輪投票,問大家對 Temporal 的熟悉程度——結果大多數人沒聽過,或聽過但沒用過。他笑說「那這場對很多人會偏進階」,但承諾會盡量帶。

主題二:Temporal 的心智模型(約 01:10:47–01:13)

一句話:Temporal 讓你「寫程式時假裝失敗不存在」。

• 你專注在 agent / 分散式系統的商業邏輯(他強調:agent 就是分散式系統),把它放進一個 workflow——也就是你想執行的一連串步驟。
• 然後把非確定性的步驟——API 呼叫、LLM 呼叫、資料庫查詢——抽出來,放進所謂的 activity。
• 用 SDK 包住這些 activity 之後(Python、TypeScript、Java、Go、Ruby 等主流語言都支援),Temporal 會建立一份到目前為止所有已執行動作的 history。
• 一旦發生任何失敗,它就停在 history 的那個點等待,等失敗被解決——可能是幾秒、幾分鐘,也可以是好幾年。解決之後,它會像失敗從未發生過一樣繼續執行後面的操作。
• 而且這段等待不消耗你的資源,因為狀態全都記在 history 裡。他提到 Temporal 有 six nines 的可靠度。

那什麼會失敗?幾乎所有東西:LLM 呼叫因網路問題失敗(他說當天早上才被 OpenAI 回了一個 429 rate limit)、API 呼叫失敗、rate limit、服務掛掉、AWS 掛掉。把這些包進 activity,Temporal 就能在故障解除後接手。

主題三:動手做——第一個 workflow(約 01:13–01:25)

環境是一個虛擬 lab(免安裝、Docker 容器,開機約 90 秒),分頁包含 worker 終端機、starter 終端機、Temporal UI、一個可以模擬網路故障的 network control panel,以及程式編輯器。學員在 exercise/ 資料夾工作,solution/ 有相同結構的解答。現場有三位 TA 加上後方的 Melanie 支援。

練習內容:在 exercise/tools/workflow.py 裡把 agent 的建構取消註解。用的是 OpenAI Agents SDK 整合——給名字、給 system prompt、選模型(他說這題用 GPT-4o 就夠了)、給工具。工具本身只是幾個 web request(取座標、取 IP 位置資訊、取天氣),但它們是以 activity 的形式傳入,因此自動獲得 Temporal 的 durability。

執行:先啟動 worker(他解釋 worker 是負責輪詢 task queue、決定要執行哪些工作的程序),再跑 starter,送出「What is the weather in Tokyo?」。

成果:到 Temporal UI 重新整理,workflow 已完成。他強調這是他自己最喜歡 Temporal 的地方——可見性:整條 timeline 一目了然(invoke model activity → get coordinates → invoke model activity → get weather → invoke model activity),每一步都能點進去看 header、輸入與輸出。最後答案是東京 79.6°F、微風。

主題四:把它弄壞——durability 的現場證明(約 01:25–01:28)

這是整場最核心的示範。到 network control panel 把 weather API 關掉(他舉的情境:你的網路擋掉了、企業政策不准、API 本身掛了、或 AWS 掛了所以連帶掛了),然後重跑「What is the weather in London?」。

在 Temporal UI 裡:

• workflow 進入 Running 狀態,而且會一直維持 Running 直到問題解決。
• 那個 activity 持續重試。因為他們沒有明確指定 retry policy,用的是預設值,所以會永遠重試下去;而且內建 automatic backoff 與 backoff coefficient。他順帶解釋為什麼需要 backoff:你不會希望 LLM 一直狂打 OpenAI API,那很燒資源;打 10 次失敗就等 10 秒,再失敗就等 30 秒——這就是 exponential backoff,沒有 Temporal 的話這段邏輯得自己寫,而且會寫得很醜。
• 錯誤訊息顯示 503 service unavailable。

接著把 weather API 打開:「想像 AWS 的故障排除了」。幾個瞬間之後 workflow 自動恢復,像失敗從未發生過——不需要動任何程式碼,從失敗發生的那一點精確接續,沒有額外資源被消耗,workflow 正確結束,終端機拿到倫敦的天氣。

主題五:自己寫 loop vs 用 SDK(約 01:28–01:30)

他順帶拆穿了 agentic framework 的神祕感:很多框架把 agentic loop 藏在背後,但它本質上就是一個 while True 迴圈——等待使用者輸入、判斷資訊是否足夠、不夠就呼叫工具或做別的事。

自己寫大概 50 行;用 OpenAI Agents SDK 就是 runner.run 一行,loop 由 SDK 處理。而 activity_as_tool 這類包裝則負責替所有被呼叫的工具提供 durability。

主題六:為什麼要拆成多個 agent(約 01:36–01:38)

中途他讓現場投票決定接下來講 human in the loop 還是 multi-agent orchestration,現場選了 multi-agent,human in the loop 因此跳過(他解釋 human-in-the-loop 就是一個「詢問並等待人類回饋」的工具,可以等核准也可以等資訊——「ChatGPT 本身就是一種 human in the loop,它會等你回應才繼續」)。

拆分的理由是 context 的四種病:context poisoning、distraction、context clash、confusion。小 workflow 還好,但流程愈大、資料愈多、塞進去的東西愈多,LLM 就愈難推理。

主題七:三種呼叫 sub-agent 的方式與 Nexus(約 01:38–01:43)

架構是:personal assistant agent 作為整個流程的入口(他類比為你的 ChatGPT),由它決定要呼叫 weather agent、F1 agent,或兩個都叫。

呼叫 sub-agent 有三種做法:

1. 當成 activity 呼叫。
2. 當成 child workflow 呼叫——主 workflow 啟動一個子 workflow,兩者綁在一起;適合把決策邏輯放進另一個流程。
3. 透過 Nexus——Temporal 的另一項技術,可依團隊領域、地區、安全性考量、程式碼需求做切分,例如你希望某個 agent 用和別的 agent 不同的頻率部署。

他對 Nexus 的解釋是:把它想成一個 API。你決定要向另一個團隊或另一個組織暴露哪些 endpoint,對方只能呼叫那些;呼叫方提供 endpoint 與 service 名稱就能呼叫,背後怎麼實作可以隨時改(升到 v2 之類),而契約不變,呼叫方不必改程式碼。

主題八:多 agent 實作與再次弄壞它(約 01:44–01:52)

Demo 5 的架構:personal assistant workflow 收到「下一場 F1 比賽在哪、那裡現在天氣如何?」→ 透過 Nexus operation 呼叫 F1 agent(跑在不同檔案、不同 task queue,最終呼叫他們自架的 F1 MCP server,再打到 F1 API)→ 資訊回到 personal assistant → 它判斷「還缺天氣」→ 以 child workflow 呼叫 weather agent(內部再呼叫 get coordinates 與 get weather 兩個 activity,就是公開 HTTP 請求)→ 彙整後給出最終答案。

實跑結果:下一場是 8 月 23 日的荷蘭大獎賽,當地 64.7°F。在 Temporal UI 中可以看到兩個 workflow 同時執行,而且 Nexus link 是可以點進去的——點進去就是 F1 expert 那個獨立 workflow 的完整執行紀錄。

然後他又把 weather API 關掉重跑:兩個 workflow 都不會完成,卡點精準落在 weather agent workflow 的 get_coordinates,持續失敗直到問題解決。打開之後兩者都成功結束——他提醒恢復時間取決於 retry policy 與 exponential backoff,等久了可能要多等幾秒才會重試。

主題九:隨堂測驗與收尾(約 01:31–01:36、01:52–01:59)

他穿插了手機搶答測驗與排行榜,前三名送周邊。幾個值得記的答案:

收尾(約 01:58–01:59):時間到被請下台,他只要求兩件事——到 LinkedIn 追蹤他(所有內容會放上去)、以及在 lab 的 feedback 分頁留下可以據以改進的回饋(「你可以說我很爛,沒問題,但請告訴我為什麼很爛」)。測驗前三名是 Anton、Henrik、Ming,周邊在後排領。有問題也可以去 Temporal 的 Slack 社群。