从云原生到AI原生：上下文密度的重要作用

正如技术领域的其他方面一样，人工智能——特别是智能体AI——成为云原生计算基金会最新旗舰活动KubeCon + CloudNativeCon Europe 2026讨论的主导话题。

实际上，AI如此普及，以至于云原生计算正在让位于AI原生计算：将云原生原则应用于AI工作负载，特别是智能体AI。

在这个以软件基础设施为重点的会议上，AI原生故事有两个方面：当组织利用Kubernetes将智能体AI投入运营时，他们希望实现用于大规模运行智能体工作流程的基础设施，同时他们利用AI智能体来促进灵活、动态基础设施的整体部署。

然而，剥离AI原生抽象的各个层次，你会发现智能体AI故事两个方面的核心是一个单一概念：上下文。上下文是智能体行为的核心促进因素。

理解我们所说的上下文含义、它与始终是云原生计算核心的元数据的关系，以及如何利用上下文构建成功的智能体应用程序，这些是架构师、运维人员和开发人员在从云原生向AI原生计算时代转变过程中的新要务。

从元数据到上下文

Kubernetes成功的关键之一是其声明式性质：元数据驱动其组件的行为。

为了配置和部署Kubernetes及其上运行的应用程序，运维人员创建和管理各种形式的元数据。Helm图表、清单、基础设施即代码或IaC脚本、遥测以及各种形式的配置信息都是元数据。

所有这些元数据都有可能成为AI智能体的上下文。为智能体提供上下文元数据来提示它、配置它、治理它并评估其行为。

据Tessl AI Ltd.开发者关系负责人兼AI原生开发者社区顾问Patrick Debois称，"上下文是新的代码"。软件交付生命周期SDLC变成了CDLC——上下文交付生命周期。

云原生世界可能充满了元数据，但并非所有元数据都能构成良好的上下文。向智能体提供糟糕、模糊的上下文，它们很可能会表现异常。

因此，理解什么构成良好上下文并部署创建和管理此类上下文的工具成为关键的AI原生优先事项。

理解上下文密度

什么构成"良好"上下文取决于是人类还是智能体在使用它。要理解这种区别，首先理解语义密度很重要。

语义密度——一个人或系统能在给定数量的单词中塞入多少意思——是智能体AI时代的一个基本考虑因素。

实际上，在2026年2月27日的文章中，John Furrier提出了一个重要观点："在（智能体）编排时代，软件的可防御性不再关乎UI润色或工作流程检查清单。它关乎语义密度。"

人类能很好地处理高语义密度——少数几个词可以传达多层意思。AI——特别是AI智能体——在处理高语义密度时困难重重，特别是在处理上下文时——换句话说，上下文密度。

虽然语义密度衡量消息内部意义的复杂性，但上下文密度衡量消息周围的有意义内容。

为了正常运行，智能体需要精确、简洁的上下文——换句话说，具有低上下文密度的元数据。另一方面，人类在高上下文密度的交流中表现最佳——这是人类相对于AI的一个基本且可防御的优势，正如我在最近一篇文章中解释的。

通过上下文密度的视角理解AI原生基础设施

当我在KubeCon展厅采访供应商时，我寻找他们如何处理云原生计算必需的元数据——以及他们的工具在多大程度上支持低上下文密度的元数据。

在前AI云原生时代，上下文密度并不是一个重要考虑因素，因为人类会处理元数据具有高上下文密度的情况。然而，现在我们将如此多的任务委托给AI智能体，确保智能体拥有低密度上下文变得至关重要。

然而，这一要求在KubeCon的供应商中从未明确表达。尽管上下文密度对从云原生向AI原生计算转型很重要，但它还不是讨论的焦点。

因此，我必须仔细观察才能发现我清单上的供应商在处理上下文问题方面的表现。

以下是我的看法：

将元数据视为上下文

在Kubernetes世界中有各种形式的元数据，其中任何一种都可能作为AI智能体的上下文。

遥测就是一个例子。云原生世界在通过OpenTelemetry（OTel）标准规范遥测格式方面取得了巨大进展——但即使是OTel格式的遥测也可能存在限制AI智能体利用它作为上下文能力的问题。

许多组织没有意识到他们的遥测存在问题，即使那些认识到此类问题存在的运维人员也不知道如何找到它们。

为了解决这个问题，OllyGarden Inc.实时修复OTel格式的遥测。

OllyGarden自动解决OTel遥测问题，包括过量或冗余遥测、包括标签不一致在内的来源问题，以及查找和掩盖敏感数据。所有这些修复都有助于使遥测适用于为智能体工作流程提供上下文。

IaC脚本（通常采用Terraform）也代表重要的配置元数据，可以驱动智能体行为，只要它具有低上下文密度。

我与两家解决IaC代码问题的供应商进行了交谈。以Firefly名义经营的Infralight Ltd.利用AI智能体通过生成Terraform代码来自动化云配置，使运维人员能够在停机和网络攻击期间以最小的停机时间立即重建环境。

Firefly聚合跨云提供商的配置元数据，创建跨环境提供单一事实来源的配置清单。然后使用此清单生成简洁、精确的Terraform代码——换句话说，具有低语义密度的IaC代码。

Terramate GmbH也通过抽象Terraform代码来处理IaC，以在规模上提供更大的IaC配置基础设施的可重用性和管理。本质上，Terramate将IaC左移，提供经过策划、审查的IaC代码，支持在明确护栏内的智能体控制。

扩展有状态智能体工作流程

AI智能体可以执行单个任务，但智能体AI的真正力量在于智能体协同实现工作流程。

工作流程本质上是有状态的，这意味着参与工作流程的智能体必须跟踪工作流程内发生的一切。

相比之下，Kubernetes最适合无状态应用程序。此类应用程序的水平可扩展性相对简单，但跟踪工作流程更难扩展——特别是当AI智能体的行为是非确定性时。

我与三家处理这一可扩展性问题的供应商进行了交谈。来自Loophole Labs Inc.的Architect为Kubernetes基础设施提供可扩展性，支持长期运行和有状态应用程序，包括智能体应用程序。Architect还支持智能体工作流程相比Kubernetes专门处理的无状态应用程序所需的更高可靠性要求。

Diagrid Inc.为弹性智能体工作流程提供平台，保证此类工作流程将运行至完成。该平台为模型上下文协议或MCP服务器以及服务器和端点之间的MCP通信提供安全性和弹性，从而实现智能体、大语言模型和人类之间低密度上下文的通信。

Kedify Inc.为Kubernetes集群提供自动扩展，包括在图形处理单元上运行的集群。Kedify不是利用内存和CPU/GPU容量指标来启动自动扩展（这可能太晚而无法避免故障），而是利用其他信号，包括流量指标、数据库写入和指示需要自动扩展事件的其他信号。

由于智能体工作流程是有状态的，将提示和其他基于上下文的交互路由到适当的副本实例很重要。Kedify自动处理副本之间上下文元数据的移动以维护智能体工作流程状态。

大规模控制AI原生基础设施

Kubernetes声明式、元数据驱动方法最重要的优势之一是它如何通过控制平面支持集中控制。

当我们从云原生世界转向AI原生世界时，控制平面同样重要——只是现在用于AI智能体和智能体工作流程更复杂、非确定性的行为。

Upbound Inc.为云原生和AI原生基础设施提供控制平面。该控制平面处理非确定性操作场景，比如当Upbound的AI智能体基于遥测输入做出运维决策时。控制平面还促进基于AI工作负载的基础设施管理。

Cue Labs AG为Kubernetes提供以配置为中心的控制平面。Kubernetes本身提供基本配置控制，但Cue Labs处理复杂配置，包括多集群、多云和混合配置场景。

Cue Labs使运维人员能够主动控制配置以避免与配置相关的停机时间，并帮助他们将策略与配置对齐——即使管理策略的人员不与负责配置的运维人员沟通。该公司为配置元数据提供简洁格式，既更具人类可读性，也提供智能体所需的低上下文密度，为运维人员提供对非确定性智能体应用程序最复杂部署所需的控制。

上下文是新的石油

有些人可能会争辩说上下文只是元数据的另一个词——我们处理元数据已经有很多年了。那么这里真正的新意是什么？

答案当然是智能体AI，以及上下文在其中和生成式AI中普遍发挥的作用。

毕竟，提示本身要么主要是上下文，要么完全是上下文——其余部分由数据本身组成。例如，你放入提示中的任何指令都是上下文。

当然，人类也可能提示AI智能体，但这里更重要的故事是智能体如何表现——通过请求数据、与API交互或与其他智能体通信。

所有此类行为都需要精确、简洁的上下文，以便智能体正常运行并完成我们为它们设定的任务。

因此，随着企业构建其AI原生基础设施，利用支持智能体以及AI整体低密度上下文要求的工具和平台变得越来越重要。

Q&A

Q1：什么是上下文密度？它与语义密度有什么区别？

A：上下文密度衡量消息周围的有意义内容，而语义密度衡量一个人或系统能在给定数量的单词中塞入多少意思。智能体需要低上下文密度的精确、简洁上下文才能正常运行，而人类在高上下文密度的交流中表现最佳。

Q2：为什么AI智能体需要低上下文密度的元数据？

A：AI智能体在处理高语义密度时困难重重，特别是在处理上下文时。为了正常运行，智能体需要精确、简洁的上下文。如果向智能体提供糟糕、模糊的上下文，它们很可能会表现异常，无法完成我们为它们设定的任务。

Q3：云原生计算如何向AI原生计算转变？

A：AI原生计算是将云原生原则应用于AI工作负载，特别是智能体AI。这种转变体现在两个方面：组织利用Kubernetes将智能体AI投入运营，实现用于大规模运行智能体工作流程的基础设施；同时利用AI智能体来促进灵活、动态基础设施的整体部署。