讓 agent 撐得久的兩條路

概要

• 後端三十年的預設是無狀態運算Eric 從 1993 年的 CGI 講到 PHP 與 LAMP，說 request 加資料庫就能產生 response 的 shared nothing 架構，成了之後 Rails、Node.js、serverless 都沿用的做法。
• replay 模型把副作用包成 step多步驟的副作用重試時會重複扣款，所以 workflow 與 durable execution 引擎把每個副作用包成會被快取的 step。好處是有執行歷史、能等人類回應；代價是結構僵硬，程式必須寫得具決定性，journal 的版本管理也麻煩。
• replay 套在 agent loop 上會越長越大每次 LLM 呼叫、每次 tool call 都變成一個 step，log 會一直長，可能撞到筆數或單筆大小的上限。Eric 的看法是 agent 像 session 而不像 transaction。
• durable agent 要存兩半一半是 context（訊息、tool call 與結果），用 append-only log 存進資料庫或物件儲存就好；另一半是執行環境（clone 下來的 repo、裝好的套件、跑著的 dev server），沒辦法用 log 還原，要用 snapshot 與 restore。
• Trigger.dev 從 CRIU 換到 Firecracker microVMCRIU 只能 checkpoint 單一 process，也要經過 container registry；改用 Firecracker 後整台機器都能 snapshot，再用壓縮把 snapshot 壓到約 14 megabytes。
• 速度數字Eric 說 snapshot 略低於一秒、restore 約幾百毫秒，benchmark 是每分鐘 15,000 次 VM 啟動；他們把這些包成類似 docker CLI 的 fc run，預計開源。

原話

• “Multi-step workflows are sort of start and end, and sessions keep going for as long as possible.”

  多步驟 workflow 有開始和結束，session 則是盡可能一直持續下去

  ▶ 07:07

• “So this allows us to snapshot the machine, shut it down, save it to disk, and then when the user comes in we restore it”

  所以可以把機器 snapshot、關掉、存進磁碟，使用者進來時再 restore

  ▶ 09:36

• “moral of the story is that snapshots are like slightly under a second and restores are a couple hundred milliseconds.”

  重點是 snapshot 略低於一秒，restore 約幾百毫秒

  ▶ 14:34

• “I think this will lead to a future of you know stateful compute.”

  我認為這會通往 stateful compute 的未來

  ▶ 16:07

延伸

• Eric 拿 1966 年的 IBM 大型主機說明 checkpoint 不是新概念：當年的工作一跑好幾小時，出錯整個重跑太貴，所以在程式裡加 checkpoint。
• Eric 說 snapshot 壓到多小是一個可以調的旋鈕，看要多少效能決定壓多少。