為什么現有的 Agent Infra 無法支撐生產級應用？

作者 | 戴冠蘭

編輯 | 李忠良

我們正在經歷從“對話式 AI ”向“ Agentic AI ”的躍遷，2026 年的核心命題已經不是模型夠不夠聰明，而是 AI 能不能真正接管生產環境里的工作流。

想象一個幫客戶做跨云遷移的 Agent。前兩小時它完美地在 AWS 和 GCP 之間配置了 VPC，拉起了實例，并在第 12 步刪改了舊數據庫。然后在第 13 步，它因為一個罕見的 API 限流崩潰了。

你該怎么辦？重試？它會再修改一遍數據庫；重啟？它不知道哪些實例已經拉起。沒有有效狀態恢復，現在你的整個云環境就是一團亂麻。

這是一個貼近現實的場景，任何在生產中跑過超過 10 步的 Agent 都會遇到類似的問題，只是程度不同。這篇文章試圖解釋為什么這個問題是結構性的，為什么現有的 Infra 沒有解決它，以及解決它可能需要什么。

Agent 的執行特征

大多數團隊把 Agent 當成大模型的 wrapper，給它掛上幾個 tool call ，加一些簡單的 Harness 就上線部署了。但當你賦予 Agent 真實的系統權限，讓它長時間自主運行，才會發現其執行特征跟我們熟悉的任何軟件形態都不太一樣。

它同時具備五個屬性：長程運行、敵意輸入、真實權限、不確定決策、真實副作用。

長程運行意味著崩潰是很大概率發生的。敵意輸入并不是說用戶故意攻擊你，而是跟瀏覽器里跑客戶端 JavaScript 同一個意思：Agent 處理的輸入（郵件內容、網頁文本、API 返回值）隨時可能包含注入指令，你必須在架構層面假設輸入不可信。真實權限意味著 Agent 持有 API key、數據庫憑證、云平臺 token。不確定決策來自 LLM 本身：同樣的 prompt，不同時間點會產生不同的輸出。真實副作用意味著每一步操作都可能改變外部世界的狀態：發了的郵件收不回來，刪改了的數據庫恢復不了。

最近出圈的龍蝦 OpenClaw 把這個問題推到了前臺。賦予模型真實系統權限能帶來能力躍遷，但也把安全風險從理論變成了現實。

這五個屬性單獨拿出來都不新鮮。數據庫有事務語義來處理副作用，瀏覽器有沙箱模型來處理敵意輸入，分布式系統有 checkpoint 來處理長程運行。Agent 的難點在于它把這五個屬性同時綁在了同一條執行鏈上，而且沒有任何現成的系統是為這個組合設計的。即便權限收緊、動作都可審批，長程運行 + 不確定決策也讓可恢復語義成為硬需求。

兩個錯位的假設

現有的 Agent Infra 建立在兩個過時的假設上。

第一個是威脅模型的假設。整個?業在?服務器代碼的安全假設運?客戶端代碼。除了用戶輸入之外，服務器假設全部可信、執?環境受控、API surface 由你定義。而 Agent 讀取的內容是敵意的，持有真實密鑰，在你控制不了的環境?執?。它的威脅模型是瀏覽器，而不是服務器。

第二個是執行模型的假設。現有的執行 Infra 為確定性、短時、無狀態的任務設計：一個請求進來，處理完，返回結果。Agent 的執行是概率性的、長程的、帶狀態的。它的決策路徑不可復現，副作用不可撤銷，而且運行時間長到崩潰是統計必然。把這樣的執行塞進為以請求 / 進程為容錯單位的 Infra 里，問題不會在 demo 階段暴露，會在生產規模暴露。

這兩個假設的具體后果是三個缺失：沒有副作用日志，出了事無法回答到底發生了什么；沒有可恢復的執行狀態，中斷后無法從任意點恢復上下文與環境；沒有隔離邊界，權限與數據暴露給不可控輸入。

三條缺失的原語

從上面兩個錯位出發，我認為正確的 Agent Infra 需要補上三條原語。這三個原語有嚴格的構建順序：副作用必須先被封存，能力邊界才能被正確執行，恢復才能是安全的。

Effect Log

這是另外兩個原語的地基。生產恢復以語義正確為先，調試回放以可復現為先。核心思路是把外部世界的副作用做成一套 write-ahead log。

有副作用的調用在執行前先寫 intent record，記錄冪等鍵、預期影響范圍、審批級別。執行后寫 completion record，記錄請求、響應、etag，以及是否已發生不可逆變化。恢復時，只讀調用可以直接重放；有副作用的調用默認返回 completion record 中封存的結果，不再觸碰外部世界。

Effect Log 的關鍵是把 tool call 按可恢復語義做最小分類并規定恢復策略：

• 純讀調用可以重放，若要可復現調試則直接返回封存響應而不是重打外部請求；

• 冪等寫調用帶冪等鍵，恢復時允許重放，必要時由中介層用 effect log 去重補齊冪等；

• 不可逆寫調用一律禁止重放，恢復時直接返回 completion record 中封存的結果，把它當作已發生的事實；

• 讀寫混合調用最危險，必須把讀到的響應 / 版本指紋先寫入 intent record 并在 completion record 里一并封存，恢復時禁止重新讀取，只能基于封存的讀快照繼續推進，避免外部狀態漂移導致邏輯分叉。

這些分類是 tool 的開發者在注冊 tool 時主動聲明的接口契約，就像 HTTP method 的語義約定一樣，GET 是安全的、PUT 是冪等的，這些并非服務器推斷出來的，而是 API 設計者承諾的。現實中會有模糊地帶：一個 Stripe refund 調用帶有 idempotency key 但結果不可撤回，它同時符合冪等寫和不可逆寫。裁決原則是按最保守的分類處理——如果一個調用的任何維度是不可逆的，恢復時就按不可逆寫對待，返回封存結果而不是重放。錯誤地把不可逆操作重放一次的代價，遠高于錯誤地跳過一次冪等重試。“接口契約”在生態初期有可能會面臨集成摩擦，所以智能語義標注也是值得探索的方向。

回到開頭的場景：Effect Log 在第 12 步刪改庫發生的瞬間就寫下了 completion record。崩潰恢復時，Infra 讀到這條記錄，直接返回已封存的結果，重改的問題從根本上被排除。這些分類是接口契約，必須由 Capability Gateway（能力控制網關）強制執行。

能力隔離

有了 Effect Log 做地基，下一步是畫出能力邊界。

不把真實憑證直接交給 Agent 進程，而是通過一個 Capability Gateway 中介所有外部訪問。Agent 拿到的是有時間限制、有范圍限制、可即時撤銷的臨時令牌。權限邊界在 Infra 層強制執行，不依賴模型的自覺。

這跟瀏覽器的安全模型是同一個思路：Tab 頁拿不到 OS 的直接訪問權，不是因為 JavaScript 代碼承諾不越界，而是因為瀏覽器在架構上就不給它這個能力。

你給 Agent 的權限范圍就是它的爆炸半徑。這個 tradeoff 永遠存在：權限越大，Agent 越有用，但出事時的損害也越大。關鍵是要有意識地做這個選擇，而不是把所有權限 yolo 一股腦塞給 Agent。

崩潰觸發后，scoped token 即刻失效。即便崩潰是因為注入了惡意指令，Agent 也已經沒有憑證可以繼續操作，我們開源的 ClawShell（

https://github.com/clawshell/

分叉恢復

有了封存的副作用事實和獨立的能力邊界，分叉才是安全的。

Agent 的執行本質上是搜索：它在一個巨大的決策空間里探索路徑。這個搜索并非一條線，而是一張圖。每個分支需要獨立的 checkpoint，這是一份語義閉包：模型輸出、tool 輸出，以及 effect log 的游標位置。恢復時能精確回到某個節點繼續推進，而不必從頭來過。

分叉恢復不只是性能優化。它是讓 Agent 系統能夠調試的前提條件。沒有它，出了問題你只能盲猜。可追蹤性從第一天起就必須內建在 Infra 里，事后補不了。

回到開頭的場景：你看到的不再是一個死掉的任務，而是執行圖上的一個精確斷點。你可以從第 12 步之后的狀態直接續跑，帶著完整的上下文，避免從頭來一遍。

從 Uptime（保活） 到
Resumability（可恢復性）

在 SaaS 時代，Infra 的核心指標是 Uptime。我們用多副本、自愈、冗余來確保 SLA。

但對于 Agent，Uptime 是代理指標。你無法保證一個運行 48 小時的 Agent 永遠不遇到網絡抖動或硬件故障。我在 Cloudflare 做 Edge Infra 的時候學到一個原則：設計目標不應該是保證機器不掛，而是在故障發生時保住執行語義的正確性。

正確的指標是 Resumability：能不能在任意時間點重新進入執行，完整恢復狀態、上下文和環境？

這是一個從保證不死到允許隨時死掉并滿血復活的范式轉變。一個可以被中斷然后被正確恢復的 Agent，比一個理論上永遠不停但遇到硬件故障就沒有退路的 Agent 更可靠。

這個轉變還有一個不直覺的推論：對 Agent 來說，擴容往往不是加更多的副本，而是垂直給同一個 Agent 更大的機器。垂直擴容在實踐中通常意味著 checkpoint 然后 restart，這讓 Resumability 從異常路徑變成了常態操作。如果你的 Infra 沒有把恢復當作一等公民來設計，擴容本身就會變成風險源。

現有 Infra 的抽象層錯位

我想強調一點：下面提到的這些系統在各自的抽象層上都是正確的。問題是 Agent 的需求恰好落在它們的抽象層之外。

Kubernetes 解決的是資源與進程隔離。 它能把容器關起來，但看不見 tool call 語義。一個被注入惡意指令的 Agent，所有危險行為都發生在合法渠道里：真實 API key、正常 HTTP 請求。對容器來說，一個 Agent 在正常調 API 和一個 Agent 在執行注入指令是完全一樣的流量。

Firecracker 和 gVisor 提供了更細粒度的工作負載隔離。 Firecracker 的 microVM 結合了 VM 的隔離與容器的速度，gVisor 在用戶空間提供了 Linux-like 的應用內核。它們都在隔離層上做了有價值的工作，但隔離層和語義層是兩回事。它們能告訴你一個進程不應該訪問另一個進程的內存，但不能告訴你一個 Agent 不應該用它持有的 API key 去執行一個由注入指令觸發的操作。

Modal 和 E2B 在代碼執行沙箱層做了有價值的工作。 Modal 的 Python-native 執行環境降低了部署摩擦，E2B 明確把自己定位成讓 Agent 安全執行代碼的隔離沙箱。但代碼隔離和能力隔離是不同的問題。Agent 拿到一個干凈的沙箱后，仍然可以用持有的真實 API key 調任意外部服務。崩潰恢復、副作用記錄、冪等重放，還是得在應用層自己實現。

WASM 和 unikernels 有前景，但成熟度不夠。Python 的 C-bindings 在 WASM 里幾乎無解，unikernels 雖然縮小了攻擊面，但不保證完整的 Linux 語義——而調用 bash 恰好是 Agent 目前最強的能力之一。

這些系統的共同特點是：它們做到了 execution isolation（把代碼關起來），但沒有提供 semantic isolation（把能力與副作用關起來）。這個區分在傳統場景里不重要，因為傳統軟件的邏輯是確定性的、可信的，Agent 打破了這個前提。

編排層為什么補不上這個缺口

有人會說，Temporal 或者 Netflix Conductor 不是已經解決了 durable execution 的問題嗎？它們確實解決了，但解決的是不同前提下的問題。

Temporal 和 Conductor 提供了持久化 workflow 歷史、斷點恢復、冪等重試。這些能力在微服務編排場景里非常有價值。但它們都有一個核心前提：workflow 的代碼邏輯是確定性的、可信的。Temporal 官方明確要求 workflow code 必須 deterministic，改動可能引入 non-determinism 時需要用 Worker Versioning 或 patching APIs 來保護運行中的 workflows。

LLM 從根本上打破了這個前提，具體來說有兩個問題。

• 第一，Temporal 的容錯依賴 replay 機制，前提是代碼是確定性的。LLM 崩潰后重放，會走不同的決策路徑。你必須把每次 LLM 調用的結果全部緩存，replay 時直接返回緩存結果。這時候你實際上是在 Temporal 之上自己實現了一套狀態機，Temporal 的 replay 機制反而變成了額外的約束成本。

• 第二，Temporal 的最根本的基礎假設，是代碼邏輯本身是可信的，只是 Infra 會出錯，比如網絡抖動、進程崩潰、機器故障等。但 Agent 的問題是 LLM 輸出本身不可信，Temporal 會忠實地執行一個 prompt injection 攻擊，因為從它的視角看，這就是 workflow 的正常邏輯。這意味著需要在 Temporal 的執行模型之外，獨立構建類似 Capability Gateway 的能力隔離層 ，但 Temporal 沒有這層預留集成點，它的 activity 邊界是執行邊界，不是信任邊界。你需要自己在兩套系統的接縫處維護一致性，而這個接縫處恰好是攻擊面最大的地方。

所以 Temporal 和 Conductor 可以作為上層編排。但能力隔離與副作用語義必須在它們外部先成立，編排可以在其上組織流程，但不能替代語義地基。

一個隱含的賭注

這篇文章有一個隱含假設：Agent 的主流形態會收斂到長程、高權限、帶真實副作用的自主執行。

這并非是唯一可能的路徑。另一種演化方向是 Agent 保持短程、低權限、每一步都需要人類審批的模式。如果那個路徑成立，上面說的三個原語的優先級會發生變化：能力隔離仍然重要，但 effect log 和分叉恢復的緊迫性會低很多，因為人類審批本身就是一種斷點。

我選擇押注長程自主執行這個方向，原因有兩個。第一，模型能力在快速提升，每一步都要求人類審批的模式在體驗上會越來越不可接受，就像你不會愿意每點一個鏈接都彈一次安全確認框。第二，Agent 的價值本質上來自自主性——能獨立完成一段復雜的、跨系統的工作流。如果每一步都需要人盯著，那它就只是一個更花哨的自動補全。

即使在人類審批模式下，審批的粒度也會隨著信任積累而逐漸粗化。一個團隊第一次讓 Agent 刪庫刪表會要求人工確認，但第 10 次成功執行之后，這個審批就會被取消或者自動通過。這意味著長程自主執行是一個必然的演化方向。審批會被疲勞打敗：系統一旦跑順，人會取消審批；如果審批過多，流程壓力也會逼著你跳過。

Infra 的真正使命是做熵減

LLM 帶來的不確定性不會消失，model 能力的提升不會讓這個問題自動解決。更強的模型意味著更多的自主權，更多的自主權意味著更大的爆炸半徑。

LLM 本身的任務就是不停在做熵增，而 Infra 的真正使命是做熵減。

Agent loop 決定行為。

Infra 決定邊界。

回到開頭的場景：沒有針對 Agent 設計的 Infra，開發者面對的是一片廢墟：數據庫已經沒了，實例處于未知狀態，客戶可能已經跑路，甚至要求索賠。如果有了對 Agent 設計的正確的基礎原語，Agent 在第 13 步失敗，開發者收到通知，打開 effect log，看到第 12 步的數據庫刪改已經完成并被封存，然后點擊恢復。執行從故障的精確斷點 fork 出來，攜帶完整上下文，不存在重復執行已完成操作的風險，絲滑地從崩潰里面恢復了。

Infra 不應該追求模型永遠正確，而是讓模型的錯誤變得可預測、可隔離、可挽回。在模型的不可預測性周圍畫出確定性的邊界，用系統的確定性收斂模型的不確定性。

SaaS 時代的 Infra 解決的是算力如何被高效分配。在 Agent 的時代，Infra 要解決的是不確定性如何被安全收斂。

現有的 Infra 還遠遠不夠，當 Agent 的自主權從分鐘級任務擴展到天級甚至周級，當 Agent 的容錯單位從進程變成語義執行，我們的 Infra 棧應該從執行層開始重建。

嘉賓介紹：

戴冠蘭，Runta 的創始人兼 CEO。Runta 正在構建面向 AI Agent 的運行時基礎設施，解決 Agent 在真實環境中安全、高效執行的核心難題。在創立 Runta 之前，作為 Cloudflare 的早期工程師，參與構建了服務全球的邊緣基礎設施；之后加入 Kong 創始團隊，從零組建中國研發中心并帶領團隊成長至 70 余人，主導網關核心系統研發。從邊緣計算到 API 網關再到 Agent 運行時，一直在做同一件事：讓關鍵基礎設施在大規模、高復雜度的環境下可靠運行。