Agent 应用时代将至，传统基础设施面临挑战，openYuanrong 等系统或成破局关键

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。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 也是业界不多的同样具备成熟的任务级动态分布式调度能力的系统因此可以匹配 Agent 运行中动态拉起子任务等需求。同时 Ray 的 Actor 也是有状态的可以满足 Agent 长时有状态运行的要求。但 Ray 此前更多用在离线分布式计算场景支持在线服务类应用时可能需要在请求接入等方面多做一些工作。此外在安全隔离、多租、弹性等方面相对来说还存在较多的能力欠缺这使其当前仍难以很好解决 Agent 在安全性和资源高效利用上的问题因此可能还不适合直接支持企业级大规模 Agent 在线应用。Anthropic Managed Agents在构思本篇文章的过程中作者也关注到了 Anthropic 最新的一篇关于 Managed Agents 的文章。这篇文章中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。