北京
Kubernetes诞生时围绕一个相当简单的假设：软件会按开发者写好的指令行事。AI智能体让这个假设变得复杂——它能推理问题、选择行动路径、调用工具、编写代码、与其他系统交互，并持续朝一个目标推进。这正是智能体有用的原因，也正是它跑在生产环境里和传统应用不一样的原因。
企业越来越想把智能体放到Kubernetes上跑。云原生计算基金会（CNCF）近期一项调查发现，运行AI推理负载的组织中，有三分之二把它们跑在Kubernetes上。过去十年，Kubernetes已成为企业部署和运维分布式应用的标准方式，调度负载、分配资源、故障恢复、弹性伸缩这些事它本来就会。
推理需求会成批到来，客户需要快速扩容底层软硬件资源以承接激增的需求，这一点上Kubernetes非常合适。AI负载退潮时，Kubernetes也能平滑缩容底层基础设施，保证经济性。
但匹配得好，不等于没有缺口，首先是安全。前沿AI实验室近期发生的事故中，AI智能体逃出测试环境，在互联网上发起恶意网络攻击，这凸显出用强力护栏约束AI负载行为的必要性。AI的概率性本质导致无法准确预测一个AI负载会去调用哪些资源，智能体越界的可能性随之上升。理想的AI平台应当让清晰护栏易于执行，把智能体负载安全地关在定义明确的沙箱里。
把智能体AI负载限制在与其他Kubernetes负载逻辑隔离的沙箱中，企业就能更好地保证：即便某个AI负载失控，造成的破坏也留在沙箱内。与其让智能体想访问什么就访问什么，智能体平台应当采用显式的权限框架，对文件、工具、网络和系统资源的访问逐项放行或拒绝。除非获得明确许可，智能体应被完全禁止执行代码。
好消息是Kubernetes社区正把沙箱作为约束AI智能体的架构要素来推进，CNCF正在着手解决Kubernetes的安全与隔离缺口，但这个开源项目的功能尚未完全到位。真正的AI沙箱需要把视线越过容器，落到虚拟机或宿主机操作系统层面，确保智能体负载影响不到同一环境中的其他应用。眼下想把AI投入生产的企业，可以转向已经内置这些沙箱能力的商业Kubernetes发行版。
监控AI负载是另一个让CIO睡不着的问题。前沿AI实验室或许没有充分监控自家模型在做什么，甚至没监控它们有没有联网；企业则通常没有“请求原谅”的余地——智能体一旦行为失当，后果得自己扛。
安全或许是最显眼的挑战，但不是唯一的。智能体正在改变算力的消耗方式。一个普通服务可能连续运行数月，一个智能体可能只存在几秒钟：用户提问，智能体启动，干一些活，可能再创建其他智能体、调用若干工具，然后消失。把这种模式乘以数千用户，基础设施的样子就和常规Kubernetes环境很不一样了。
更麻烦的是启动成本。从零启动一个Kubernetes负载可能要花几秒，对很多应用完全可以接受，但对交互式智能体，这几秒慢得让人难受。于是出现一个有意思的基础设施问题：如何既拿到全新环境的隔离性，又不必每次都付创建环境的启动代价？
智能体负载的间歇性和快速拉起需求，正在考验Kubernetes的弹性。就像第一代Kubernetes不支持有状态应用一样，社区仍在为新一代智能体负载寻找最合适的抽象层。一个正在获得关注的答案是“智能体基底”（agent substrate）：承载AI智能体的Kubernetes Pod在不需要时并不完全关闭，因为从休眠状态拉起会带来用户侧难以接受的延迟；智能体以悬挂状态留在热池中，从而能在毫秒级复活，而不是花几秒从深睡中完全唤醒。
在真实世界大规模部署AI负载时，细节决定成败。并非每个Kubernetes发行版都提供企业所需的全部能力。开源Kubernetes社区在适应变化的需求，有前瞻性的平台厂商则在构建护栏、沙箱、监控和智能体基底，让企业现在就能部署AI。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
