自本轮大模型技术爆发以来，Agent 得到了广泛关注。进入 2026 年后，伴随 OpenClaw 的现象级爆火，Agent 更是彻底破圈，进入了更广阔的大众视野。同时，如果说以往的 Agent 更多用于 Demo 或一些相对定制的场景，那么经过最近一年 Agent Skills 等技术的出现和逐渐成熟，如今的 Agent 已经可以处理更多的实际场景，可以认为 Agent 应用形态的时代可能即将到来。
在 Agent 应用出现前，无论是最早的单机应用，还是如今广泛使用的云原生微服务应用，真正面向应用的计算机程序本质上都是由人面向一些特定应用场景开发的，程序的逻辑因为是开发者人工编写的，有很强的确定性。但到了 Agent 的时代，Agent 运行的具体逻辑已经从由人编程控制换成了由大模型生成，而大模型的输出无论是业务的 Owner 还是应用的开发运维人员、甚至 Agent 框架和大模型自身的研发人员都无法准确预测，因而完全是非确定性的。
然而现有的大量基础设施仍然是面向云原生以及更早时代的确定性应用打造的，并不能很好地满足 Agent 应用的运行要求。这很可能是接下来制约 Agent 真正走向企业级大规模应用的一个巨大障碍，但同时也是基础设施领域研发创新人员在 Agent 时代面临的一个很好的技术创新机会。
传统应用一般是人面向特定业务场景开发的，因而在绝大多数情况下都是静态不变的。应用的开发运维人员只要足够了解程序代码逻辑，基本上就可以准确预判应用可能的执行情况，并且这些程序无论是在何时何地运行，其执行逻辑在本质上可以认为也是相同不变的。以云原生微服务为例，每个微服务实例对每个请求的处理逻辑几乎都是一样的，开发运维人员对此都非常清楚，因此通过将微服务逻辑打包在一个统一的镜像内，即可通过 K8s 部署多个相同规格的容器实例，支持大规模的企业级应用。
然而到了 Agent 时代，情况完全变了。如下图所示，Agent 的执行逻辑是大模型驱动的，面对的是用户千奇百怪的自然语言提问，大模型相应地可能每次给出完全不一样的输出，进而又驱动 Agent 去调用各种各样不同的外部工具，甚至去执行一些由大模型根据本次请求输入动态生成的代码，如此不断循环直至大模型认为用户问题已经得到了解决为止，导致 Agent 实际上对每个请求的处理过程可能都是完全不一样的。
比如，有些简单请求可能很快就执行完，也不需要太多资源。而有些复杂请求则可能需要多轮交互/工具调用/执行 AI 生成代码等等，有些最新的 Agent 技术甚至需要在运行中拉起新的子 Agent，这些都需要更长时间和更多的计算资源。在此情况下，Agent 应用的运维人员事先完全无法预计一个请求的具体执行过程会有多复杂，比如不知道它会有多少次的大模型来回交互才能搞定，也不知道会需要调用哪些外部工具、是否会动态执行某些 AI 生成代码等等。
简言之，以往的应用是简单静态的，而 Agent 应用是复杂动态的。
由此首先带来一个很现实的问题，该如何分配 Agent 应用的资源？以往在容器微服务时代，开发运维人员可以凭借对代码运行逻辑的了解结合一些实际经验，就可以给每个容器微服务配置相同的资源。但到了 Agent 应用时代，光 Agent 需要多少运行资源就成了一个不好估计的问题，给少了可能运行出错或影响服务质量，拍脑袋给每个实例都分配很大的资源规格则显然会带来巨大的资源浪费。
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 时代又需要怎样的分布式基础设施呢？
K8s 等传统分布式基础设施实际上真正擅长的是将集群的资源以容器的方式管理起来并分配给各个应用使用。K8s 对分出去的容器内跑什么样的应用逻辑，容器内的资源是否得到了充分的利用等一无所知也并不关心。这些都是 K8s 的用户需要关心的，同时容器需要分配多少资源这件事 K8s 也丢给了用户，K8s 只负责交付用户指定规格的容器。这在确定性运行的云原生微服务时代并没有什么太大问题，但到了非确定性的 Agent 时代，就自然遇到了前面的各种挑战。
围绕前面讲的 Agent 非确定性引入的高动态、不安全、长会话的特征和挑战，本质上，Agent 时代需要的已不只是把确定性的应用逻辑由人工规划装载到多个一模一样的容器内部署起来各自独立运行，而是需要一个更加灵活强大的分布式系统。它可以让 Agent 在调度拉起之后的长时运行过程中维持自身正确的会话状态，同时还可以根据实际运行需要动态拉起一些新的子任务去单独运行某些可能有风险的代码/子 Agent 等等，并且还支持它们之间共享和传递一些关键的上下文数据。另外 Agent 和它拉起的子任务/子 Agent 等都应该按实际运行的资源需求去高效动态地去利用集群上的资源，而不需要也无法由用户事先指定。
看到这里，有没有觉得这样的运行特征似曾相识？它其实就像我们在单机 OS 上跑程序一样，程序可以进程的方式长时运行不停访问修改内部内存变量，同时可以根据自身执行逻辑的需要去动态拉起新的子进程，通过 RPC 或者共享内存等方式传递数据和协同，所有的进程都按自身实际运行需要去高效使用单机上的资源，而不需要用户来事先指定。
唯一的差别是面向企业级 Agent 应用，我们现在需要将 Agent 运行在集群上。所以本质上我们需要的是一个集群上的分布式系统，具备类似单机 OS 的灵活动态调度、弹性利用资源能力，并支持长时间有状态运行。同时由于分布式系统的特殊性，必须要支持在故障情形的自动恢复且保证恢复后的状态一致。
那当前业界有这样满足 Agent 运行需求的分布式系统吗？
答案是有的，这里简要介绍一些作者认为比较相关的业界工作供读者参考。
从当前我们了解到的情况看，最匹配的开源系统是 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 等负载调度在同一个集群内，实现高效协同，并充分共享利用集群上的各类算力资源。
和 openYuanrong 一样，Ray[2]也是业界不多的同样具备成熟的任务级动态分布式调度能力的系统，因此可以匹配 Agent 运行中动态拉起子任务等需求。同时 Ray 的 Actor 也是有状态的，可以满足 Agent 长时有状态运行的要求。
但 Ray 此前更多用在离线分布式计算场景，支持在线服务类应用时可能需要在请求接入等方面多做一些工作。此外在安全隔离、多租、弹性等方面相对来说还存在较多的能力欠缺，这使其当前仍难以很好解决 Agent 在安全性和资源高效利用上的问题，因此可能还不适合直接支持企业级大规模 Agent 在线应用。
在构思本篇文章的过程中，作者也关注到了 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。
参考资料
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。