Agent时代需要怎样的分布式基础设施

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本体隔离开来，从而完全避免风险。 然而这就要求基础设施除