摘要：openYuanrong从当前我们了解到的情况看，最匹配的开源系统是openYuanrong[1]。幸运的是，业界已经有像openYuanrong等的开源系统已在此方向积累了很多能力可以很好匹配Agent应用的相关诉求。作者介绍梁义，华为通用 Serverless 首席专家，华为元戎首席架构师，openYuanrong Maintainer博士毕业于浙江大学计算机学院，曾任职于 Ask.com、同花顺、阿里巴巴、蚂蚁集团等公司，长期从事分布式系统方向工作，涵盖搜索推荐、大数据、实时计算、在线机器学习、分布式计算、 Serverless、AI Infra 等领域，目前专注于构建统一支持包括 AI 在内各类分布式场景的通用 Serverless 分布式计算引擎 openYuanrong。
自本轮大模型技术爆发以来，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。
参考资料
[1] https://docs.openyuanrong.org/"
[2] https://www.ray.io/"
[3] https://www.anthropic.com/engineering/managed-agents"
暂无回复，快来抢沙发吧！
本次需消耗银元：
100
当前账户余额: 0 银元
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"