Agent 時代需要怎樣的分布式基礎設施

作者 ｜ 梁義

策劃 ｜ Kitty

Agent 應用時代已呼之欲出

自本輪大模型技術爆發以來，Agent 得到了廣泛關注。進入 2026 年后，伴隨 OpenClaw 的現象級爆火，Agent 更是徹底破圈，進入了更廣闊的大眾視野。同時，如果說以往的 Agent 更多用于 Demo 或一些相對定制的場景，那么經過最近一年 Agent Skills 等技術的出現和逐漸成熟，如今的 Agent 已經可以處理更多的實際場景，可以認為 Agent 應用形態的時代可能即將到來。

Agent 應用的斷代性
差異——非確定性

在 Agent 應用出現前，無論是最早的單機應用，還是如今廣泛使用的云原生微服務應用，真正面向應用的計算機程序本質上都是由人面向一些特定應用場景開發的，程序的邏輯因為是開發者人工編寫的，有很強的確定性。但到了 Agent 的時代，Agent 運行的具體邏輯已經從由人編程控制換成了由大模型生成，而大模型的輸出無論是業務的 Owner 還是應用的開發運維人員、甚至 Agent 框架和大模型自身的研發人員都無法準確預測，因而完全是非確定性的。

然而現有的大量基礎設施仍然是面向云原生以及更早時代的確定性應用打造的，并不能很好地滿足 Agent 應用的運行要求。這很可能是接下來制約 Agent 真正走向企業級大規模應用的一個巨大障礙，但同時也是基礎設施領域研發創新人員在 Agent 時代面臨的一個很好的技術創新機會。

Agent 的非確定性帶來的
獨特運行特征和挑戰

高動態——Agent 邏輯完全動態不確定無法事先預知

傳統應用一般是人面向特定業務場景開發的，因而在絕大多數情況下都是靜態不變的。應用的開發運維人員只要足夠了解程序代碼邏輯，基本上就可以準確預判應用可能的執行情況，并且這些程序無論是在何時何地運行，其執行邏輯在本質上可以認為也是相同不變的。以云原生微服務為例，每個微服務實例對每個請求的處理邏輯幾乎都是一樣的，開發運維人員對此都非常清楚，因此通過將微服務邏輯打包在一個統一的鏡像內，即可通過 K8s 部署多個相同規格的容器實例，支持大規模的企業級應用。

然而到了 Agent 時代，情況完全變了。如下圖所示，Agent 的執行邏輯是大模型驅動的，面對的是用戶千奇百怪的自然語言提問，大模型相應地可能每次給出完全不一樣的輸出，進而又驅動 Agent 去調用各種各樣不同的外部工具，甚至去執行一些由大模型根據本次請求輸入動態生成的代碼，如此不斷循環直至大模型認為用戶問題已經得到了解決為止，導致 Agent 實際上對每個請求的處理過程可能都是完全不一樣的。

比如，有些簡單請求可能很快就執行完，也不需要太多資源。而有些復雜請求則可能需要多輪交互 / 工具調用 / 執行 AI 生成代碼等等，有些最新的 Agent 技術甚至需要在運行中拉起新的子 Agent，這些都需要更長時間和更多的計算資源。在此情況下，Agent 應用的運維人員事先完全無法預計一個請求的具體執行過程會有多復雜，比如不知道它會有多少次的大模型來回交互才能搞定，也不知道會需要調用哪些外部工具、是否會動態執行某些 AI 生成代碼等等。

簡言之，以往的應用是簡單靜態的，而 Agent 應用是復雜動態的。

由此首先帶來一個很現實的問題，該如何分配 Agent 應用的資源？以往在容器微服務時代，開發運維人員可以憑借對代碼運行邏輯的了解結合一些實際經驗，就可以給每個容器微服務配置相同的資源。但到了 Agent 應用時代，光 Agent 需要多少運行資源就成了一個不好估計的問題，給少了可能運行出錯或影響服務質量，拍腦袋給每個實例都分配很大的資源規格則顯然會帶來巨大的資源浪費。

不安全——工具和 AI 生成代碼不可信

Agent 的另一個特征是執行邏輯可能不安全。Agent 運行中需要執行像大模型生成的代碼或者去調用某些外部工具，這些 AI 生成代碼和工具的執行實際上都可能會帶來安全風險。而傳統容器的隔離性又比較低，一旦運行了一些惡意代碼，就有可能出現容器逃逸等安全問題。

一種容易想到的辦法是用更安全的容器或虛擬機來代替傳統容器，但仍然通過容器接口與 K8s 等傳統的容器調度框架對接，從而讓 Agent 可以運行在現有容器基礎設施上，并提供更高的安全隔離能力。事實上，業界當前很多面向 Agent 提供的安全沙箱確實也是采用的這些技術。

然而即便如此可能仍然不夠，比如下圖的例子，一旦將 Agent 自身邏輯和 AI 生成代碼或其它有風險的工具調用混合在一個安全容器 / 虛擬機內執行，即便安全容器 / 虛擬機隔離了對 Host 的風險攻擊，但仍然存在容器 / 虛擬機內的某些重要隱私信息（比如訪問大模型的憑證）被風險代碼訪問竊取的可能性，并不能在實際 Agent 應用場景下完全杜絕安全風險。

更合理的做法是 Agent 一旦需要執行這些 AI 生成的代碼或者有風險的工具調用，就將其如下圖所示按需動態地調度到另一個干凈的安全容器 / 虛擬機里面運行，徹底與 Agent 本體隔離開來，從而完全避免風險。

然而這就要求基礎設施除了在部署階段簡單支持各個容器應用的靜態部署外，還需要支持應用運行中隨時按需動態調度拉起新的安全容器 / 虛擬機實例并執行某些代碼任務，這種任務級的動態調度執行能力是傳統 K8s 容器微服務技術體系不具備的。

長會話——長時運行如何保證會話狀態一致

云原生微服務以往為了方便運維和水平彈性擴縮實例數，一般提倡無狀態微服務。而很多應用的實際業務邏輯也確實比較簡單，比如很多的業務數據本身就已經在數據庫里保存，請求的處理過程只需要根據請求參數修改數據庫，執行邏輯自身確實是無狀態的。

然而 Agent 天然是要求有狀態的，比如在多輪對話場景下，用戶的前后多次輸入需要能始終交由同一個 Agent 實例處理，以保證上下文的一致性，從而確保 Agent 能接著正確處理。

同時，Agent 一直在往處理更復雜任務的方向演進，使得當前 Agent 對單個請求的執行處理過程變得越來越長，且過程中有大量的外部工具調用。一旦在生產環境中遇到請求處理過程中的實例故障，此時針對該請求可能已執行了幾輪 Agent loop，且部分外部工具調用已經生效。此類故障情形下，類似以往微服務場景下簡單地將實例重新拉起，將請求重新執行，可能會因為 Agent 執行邏輯的不確定性，走入完全不同的執行分支，導致又調用了其它一些不一樣的工具，使得 Agent 出現不該有的多次相互不一致的外部工具調用，最終導致出現業務無法接受的錯誤執行結果，在企業生產應用中引起致命問題。

舉個例子，如上圖所示，假如一個訂票 Agent 在故障前的請求處理過程中已經調用某個工具幫你預定了某個行程的機票，結果還沒等到完全處理完這個請求出現了機器故障，之后 Agent 從故障中恢復過來后再次處理這個請求，結果由于 Agent 的非確定性，實際執行邏輯出現了變化后又幫你新訂了一張同一行程的高鐵票，這樣的故障顯然會造成巨大的業務損失。尤其是我們知道在實際企業級生產環境中，只要運行時間長了，集群中一定是會出現機器故障的。

綜上，Agent 非確定性帶來的高動態、不安全、長會話等特征對現有以 K8s 容器微服務為代表的基礎設施體系構成了巨大挑戰，很難直接基于現有體系實現真正的 Agent 大規模落地，那么 Agent 時代又需要怎樣的分布式基礎設施呢？

Agent 時代需要怎樣的分布式基礎設施

K8s 等傳統分布式基礎設施實際上真正擅長的是將集群的資源以容器的方式管理起來并分配給各個應用使用。K8s 對分出去的容器內跑什么樣的應用邏輯，容器內的資源是否得到了充分的利用等一無所知也并不關心。這些都是 K8s 的用戶需要關心的，同時容器需要分配多少資源這件事 K8s 也丟給了用戶，K8s 只負責交付用戶指定規格的容器。這在確定性運行的云原生微服務時代并沒有什么太大問題，但到了非確定性的 Agent 時代，就自然遇到了前面的各種挑戰。

圍繞前面講的 Agent 非確定性引入的高動態、不安全、長會話的特征和挑戰，本質上，Agent 時代需要的已不只是把確定性的應用邏輯由人工規劃裝載到多個一模一樣的容器內部署起來各自獨立運行，而是需要一個更加靈活強大的分布式系統。它可以讓 Agent 在調度拉起之后的長時運行過程中維持自身正確的會話狀態，同時還可以根據實際運行需要動態拉起一些新的子任務去單獨運行某些可能有風險的代碼 / 子 Agent 等等，并且還支持它們之間共享和傳遞一些關鍵的上下文數據。另外 Agent 和它拉起的子任務 / 子 Agent 等都應該按實際運行的資源需求去高效動態地去利用集群上的資源，而不需要也無法由用戶事先指定。

看到這里，有沒有覺得這樣的運行特征似曾相識？它其實就像我們在單機 OS 上跑程序一樣，程序可以進程的方式長時運行不停訪問修改內部內存變量，同時可以根據自身執行邏輯的需要去動態拉起新的子進程，通過 RPC 或者共享內存等方式傳遞數據和協同，所有的進程都按自身實際運行需要去高效使用單機上的資源，而不需要用戶來事先指定。

唯一的差別是面向企業級 Agent 應用，我們現在需要將 Agent 運行在集群上。所以本質上我們需要的是一個集群上的分布式系統，具備類似單機 OS 的靈活動態調度、彈性利用資源能力，并支持長時間有狀態運行。同時由于分布式系統的特殊性，必須要支持在故障情形的自動恢復且保證恢復后的狀態一致。

那當前業界有這樣滿足 Agent 運行需求的分布式系統嗎？

業界相關工作

答案是有的，這里簡要介紹一些作者認為比較相關的業界工作供讀者參考。

openYuanrong

從當前我們了解到的情況看，最匹配的開源系統是 openYuanrong[1]。

openYuanrong 的核心設計理念正是構建一套類單機 OS 的分布式內核，并通過這套內核統一支持各類可能的分布式應用負載，這非常適合解決前述 Agent 場景的典型問題。

支持 Agent 高動態

通過將 Agent 運行在 openYuanrong 上，可天然支持 Agent 實例的自動彈性，無需運維人員關注如何配置容器資源。openYuanrong 在此采用了典型的 Serverless 自動彈性技術，可以支持根據請求數量動態調整 Agent 實例數目，甚至無請求可以縮容到 0。除了這種水平彈性能力外，openYuanrong 還有獨特的垂直彈性能力，可以按 Agent 實際運行的資源需求動態調整每個實例所在容器規格大小，這樣既可彈性支持應用請求負載波動變化，也可以實現每個實例對資源的動態高效利用，從而完全消除 Agent 應用如何配置資源的困擾。

此外 openYuanrong 還有很重要的動態調度能力，可以支持 Agent 在運行中動態拉起新的子任務 / 子 Agent，甚至可以并發拉起多個子任務 / 子 Agent，實現分布式并行處理，這非常適合像 Agent Swarm 等一些最新的 Agent 場景。

解決 Agent 不安全問題

openYuanrong 支持多租戶和安全隔離，通過與底層 K8s 等配合，可將實例按需調度至各類不同容器中運行。在 Agent 場景下，通過與自身的動態調度能力結合，openYuanrong 可以做到將 AI 生成的代碼等真正有風險的代碼調度至一個獨立的安全容器內運行，與 Agent 本體運行的容器實現徹底的隔離，從而避免因為混用同一個容器導致的大模型訪問憑證等隱私泄露。

支持 Agent 長會話

openYuanrong 支持有狀態實例的調度和長時運行，從而可以滿足 Agent 自身狀態訪問需求。同時在多輪會話場景下，openYuanrong 可以支持會話上下文親和的請求路由，確保多輪會話場景下上下文一致。另外還可通過 openYuanrong 的數據系統支持 Agent 將自身狀態實時分布式備份，從而確保即便遇到故障，在實例恢復后仍然可以保持狀態一致，從而確保語義一致的斷點續執行，實現最終的正確結果輸出。

除了能很好地匹配 Agent 的這些特征之外，openYuanrong 還提供了異構算力支持等能力，可以將 Agent 和大模型推理服務、Agentic RL 等負載調度在同一個集群內，實現高效協同，并充分共享利用集群上的各類算力資源。

Ray

和 openYuanrong 一樣，Ray[2] 也是業界不多的同樣具備成熟的任務級動態分布式調度能力的系統，因此可以匹配 Agent 運行中動態拉起子任務等需求。同時 Ray 的 Actor 也是有狀態的，可以滿足 Agent 長時有狀態運行的要求。

但 Ray 此前更多用在離線分布式計算場景，支持在線服務類應用時可能需要在請求接入等方面多做一些工作。此外在安全隔離、多租、彈性等方面相對來說還存在較多的能力欠缺，這使其當前仍難以很好解決 Agent 在安全性和資源高效利用上的問題，因此可能還不適合直接支持企業級大規模 Agent 在線應用。

Anthropic Managed Agents

在構思本篇文章的過程中，作者也關注到了 Anthropic 最新的一篇關于 Managed Agents 的文章[3]。這篇文章中，Anthropic 在其之前提出的 Harness、Tool 等概念外，還明確提出了 Session、Sandbox 等新的概念，并明確提出將這些概念實現相互解耦，以更好地滿足容錯、安全等考慮。

盡管思考問題的角度略有不同，但關于將 Sandbox 剝離出 Harness、Many Brains、Many Hands 這些想法和本文的觀點非常契合。比如，將 Sandbox 剝離出 Harness 正是為了解決我們前述的隱私泄露等問題，Many Brains 則對應我們前面講的多個 Agent 實例的部署和水平彈性，Many Hands 則是我們前面講的在 Agent 運行過程中可以動態拉起多個工具并行執行。但可惜文章在拋出了這些 Meta-Harness 理念外，并未詳述當前的實現情況以及如何實現。

總結與展望

Agent 是對傳統應用形態的徹底顛覆，帶來了完全不同以往應用的非確定性，其高動態、不安全、長會話的運行特征是傳統 K8s 容器微服務技術體系難以滿足的，對分布式基礎設施領域提出了全新挑戰，要求類似單機 OS 一樣更加靈活強大的分布式系統能力。幸運的是，業界已經有像 openYuanrong 等的開源系統已在此方向積累了很多能力可以很好匹配 Agent 應用的相關訴求。

相比于 Anthropic 等行業先鋒，當前大部分企業可能都還停留在云原生微服務應用時代，還普遍缺乏 Agent 相關的大規模應用落地實踐。但 Agent 應用確實又很可能即將在短時間內迎來爆發，因此相比于 K8s 在云原生時代的普及程度，企業需要面向 Agent 時代盡早儲備相關技術，構建適合自身需要的 Agent 分布式基礎設施。

作者介紹

梁義，華為通用 Serverless 首席專家，華為元戎首席架構師，openYuanrong Maintainer

博士畢業于浙江大學計算機學院，曾任職于 Ask.com、同花順、阿里巴巴、螞蟻集團等公司，長期從事分布式系統方向工作，涵蓋搜索推薦、大數據、實時計算、在線機器學習、分布式計算、 Serverless、AI Infra 等領域，目前專注于構建統一支持包括 AI 在內各類分布式場景的通用 Serverless 分布式計算引擎 openYuanrong。

參考資料

[1] https://docs.openyuanrong.org/

[2] https://www.ray.io/

[3] https://www.anthropic.com/engineering/managed-agents