当前的AI市场竞争之激烈，是我所见过的任何领域都难以比拟的。当企业准备部署最新的AI模型或智能体平台时，很多人会跳过成功上线所必需的基础设施建设，这种本能可以理解——团队希望快速推进、交付业务价值、避免在快节奏的市场中落后，但模型和框架只有建立在面向生产而非仅仅面向首次部署的基础之上，才能随着时间推移持续交付价值。随着AI从模型演进到副驾驶，再到越来越自主的智能体，其背后的系统也必须同步演进，以支撑大规模下可靠、协同的行为。

这样的基础设施可能不如发布一个新模型那样令人兴奋，但一旦你在整个组织中广泛部署AI，并允许其访问企业工具和数据，它就变得不可或缺。要负责任地建设和扩展这一基础，我们需要可互操作的框架、共享协议以及安全的、社区驱动的创新。智能体生态系统不可能在孤立的、专有的封闭体系中实现规模化，也无法满足开发者对可靠性、安全性和一致性的需求。

扩展云系统过程中最重要的经验——共享标准和开源社区创新——将直接适用于AI时代。

我正在看到许多与当年构建Kubernetes时相同的模式：一个社区围绕共享接口和运维模式达成共识，使得大规模可靠运行分布式系统成为可能。过去十年，工作负载已从传统的网络应用转向原生AI应用，但底层的运维约束始终未变。

扩展云的经验教训

要理解这在实践中是什么样的，我们可以回顾一下我们是如何学会在云中运维分布式系统的。虽然AI引入了独特的复杂性，但其运维形态是我们熟悉的。在分布式环境中，反馈更慢，故障更复杂且更难诊断，全局更新也难以安全实施，这增加了未被察觉的故障累积为系统性不稳定的可能性，这些约束塑造了云计算，也同样塑造着生产环境中的AI系统。

Kubernetes不仅仅让运行容器成为可能，它还解决了一个更难的问题：如何在不破坏系统的前提下变更正在运行的系统。解决方案不是某一个工具，而是一套运维模式，比如健康检查、可控的滚动发布，以及一种一致的方式来描述、审查和管理变更。此外，"健康"的定义变得更加灵活，允许用户在熟悉的上下文中随时间演进"健康"应用的含义。

另一个重要的经验是：良好的默认设置对健康系统的价值。让每个团队自行定义自己的模式，等于让每个运维人员都成为系统专家，这是无法规模化的。如果每个人都按照自己的方式来，那些细微的选择差异就会让构建能适用于所有人的标准化工具变得不可能。这就是为什么现代AI系统需要提供最佳实践和良好的默认设置，同时仍保留随时间适应的灵活性。

开源社区在塑造标准中的作用

大多数企业把AI当作产品发布来对待：发布一个模型，抽查输出结果，快速迭代。这种做法对很多功能和更新是有效的，但对概率性系统并不适用，因为这类系统的行为可能在悄无声息中发生漂移，且没有明显的故障模式。AI要求我们超越"要么正常运行、要么出了故障"的思维方式，转而建立对输出质量的持续认知。

开源社区通过围绕共享接口和模式达成共识，为云系统解决了这个问题。这种共识催生了工具链和运维实践的生态系统，使分布式系统在大规模下可重复运行，AI系统同样需要这种共识和一致性。

当智能体跨框架、跨云、跨环境运行时，互操作性变得至关重要，这意味着需要为每个团队所交互的层面制定标准：

• 推理和路由的接口

• 质量门槛和系统健康的通用表示方式

• 用于理解系统行为的清晰的遥测和链路追踪

• 可审计的身份和权限，并能在多个系统间流转

• 用于描述潜在操作及其影响的标准定义

当标准就位后，企业就可以统一平台默认设置、逐步推进变更，并保持简单的回滚路径。好消息是，这是对云原生生态中已有模式的延伸，而非对所需构建内容的彻底重思。AI世界站在十年云原生技术的肩膀上，但我们必须将这些技术适配到AI原生应用的世界中。

Kubernetes 能教给我们什么：关于可靠的AI系统及其规模化运维

Kubernetes 之所以成功，是因为它假设在任何应用或服务中，变更都是常态，并通过让变更可观测、可分阶段、可逆转来使其变得可控。

AI系统需要同样的特性，但多了一个维度："健康"现在还包括行为。一个模型可以低延迟地返回响应，但仍然可能在关键方面出错。回归表现为结果质量下降，而不一定是报错，这使得它更难被发现。

正因如此，"先发布再观察"是一种糟糕的策略，尤其是在智能体开始承担更多自主角色的时候，用一两个提示词来测试一个模型已经不够了。你必须运行成千上万次测试，并判断输出是否有所改善。判断一次变更是好是坏，需要在各种各样的输入上进行评估。在实践中，这通常意味着既要用数千个输入进行大规模测试，也要在生产环境中测试，将一定比例的流量路由到新模型，并与现有系统进行对比。

仅靠更好的模型无法构建可靠的系统，但专注于有意识的、有纪律的运维可以，AI系统的成功取决于用户输入和概率性系统的输出结果。虽然概率性系统不像确定性软件那样 易于管理，但我们已经学到：可靠性来自受控的发布流程、与输出质量挂钩的可观测性，以及快速回滚的能力。

同样的经验可以应用于大规模运维AI系统，确保它具有可移植性和持久性，让团队在未来数年内都能在此基础上构建。AI最快的失败方式，就是把它当作一个功能来发布，而不是当作一个系统来运维。当企业从试点走向生产时，标准就从"它能用"转变为"它能安全运行"。

这需要一小套不可妥协的实践：

• 将每一次模型、提示词和数据更新都当作完整的生产发布来对待。如果你无法分阶段、可观测、可回滚，那你就没有掌控权。

• 衡量完整的系统行为，而不仅仅是健康状态，运行时间和延迟无法告诉你输出质量何时在下降。

• 为安全失败而设计，在系统承压之前，就建立好降级方案、防护机制和清晰的升级路径。

• 统一共享层面，通用的接口、遥测和发布模式是运维人员建立肌肉记忆的方式。

• 复用经过验证的模式，糟糕的模式会引发系统故障，可复用的、开放的模式能减少意外。

我们不需要为AI发明一种新的运维理念，我们需要应用Kubernetes和云原生生态已经确立的经验：在关键之处标准化，让变更可控，让系统行为可观测。如果我们尽早应用这些经验，就能避免日后在生产压力下重新学习。AI正以极快的速度前进，我们必须确保自己已为持续的创新做好了准备。

企业网D1net(www.d1net.com)：

国内头部to B IT门户，旗下运营国内头部的甲方CIO专家库和智力输出及社交平台-信众智(www.cioall.com)。旗下运营19个IT行业公众号(微信搜索D1net即可关注)。

版权声明：本文为企业网D1Net编译，转载需在文章开头注明出处为：企业网D1Net，如果不注明出处，企业网D1Net将保留追究其法律责任的权利。