载荷中的策略：为AI智能体架构做好准备

AI智能体正在改变应用与基础设施的交互方式。与传统系统不同，智能体在每个请求中都包含自身的目标、上下文和决策逻辑，包括要执行什么操作、如何恢复，以及如何判断是否成功。这一转变打破了长期以来对流量管理的固有认知，促使企业重新思考基础设施。在每个请求都具备自主性的环境中，静态路由、资源池和集中式策略已无法满足需求。

智能体架构要求基础设施从被动执行转向实时解读请求中嵌入的意图。认识到这一转变的企业无需放弃现有投资，而是可以通过调整现有基础设施做好准备。

简介

AI智能体并非只是智能应用，而是代表着应用运行、决策和适应方式的结构性转变。与传统系统不同，智能体不仅会响应流量策略，还会自带策略。它们发送的每个请求不仅包含数据，还包含内嵌逻辑：应执行什么操作、回退机制应如何运行，以及怎样才算成功。

这一转变将决策过程从静态控制平面移至运行时本身，打破了控制平面与数据平面之间长期存在的界限，促使负载均衡器、网关和代理等流量基础设施从预配置路由的被动执行者转变为逐请求策略的解析者。

本文探讨了智能体架构如何打破流量工程中的关键假设，涉及健康检查、回退逻辑、可观测性和安全策略执行等方面。本文阐释了在逐请求意图驱动的环境中，静态池和基于平均值的健康指标等传统机制为何已无法满足需求，并指出第7层基础设施必须演进，否则可能沦为商品化的基础管道：虽然可靠，却在战略层面难以发挥作用。为适应这一变化，组织必须重新思考其流量技术栈，使其可在运行时编程、具备上下文感知能力，并与模型上下文协议（MCP）等智能体原生协议保持一致。这包括重构回退逻辑、采用语义可观测性，以及支持执行由智能体发起的策略。实时数据标注等新兴工具可为这一转变提供关键支持。

简而言之，未来的流量管理不只是传送数据包，更要实现请求意图。

智能体架构：主要特征

智能体架构引入了一种新的运营模式。在这种模式下，由生成式AI驱动的自主组件（称为智能体）执行目标导向型任务、实时做出决策，并携带必要的上下文，以便动态调整执行方式。这些智能体的运作方式与当前的服务链类似，但不依赖预配置的工作流。相反，它们会在运行时根据目标、环境状态和观测结果确定适当的执行流程。

这一转变意味着，系统将从采用预定工作流的传统集中式编排模式，转向能够实时构建执行路径的分散式动态模式。由实时数据和意图驱动的灵活响应式决策，将取代静态微服务链的可预测性。

基于智能体的系统具有以下特征：

目标驱动的执行：智能体根据提示或任务采取行动，而不是遵循静态工作流。它们会根据目标的实现情况选择API、修改参数并调整执行路径。示例：处理“解决客户投诉”任务的智能体可能会根据之前的结果，以不同方式调用计费、账户和消息传递API。
可移植上下文：智能体携带自身的记忆、状态和策略，并通过模型上下文协议（MCP）或结构化元数据将这些上下文嵌入每个请求中。
运行时自适应：智能体无需等待基础设施做出决策，而是动态调整，实时重试、重新路由、升级处理或调整执行路径。
内置可观测性：每项操作都包含自描述信息。智能体可以报告选择某条路径的原因、评估了哪些内容，以及是否达成目标。这是一种融入行为的可观测性，而不只是日志和指标。

这些因素共同推动应用格局从可预测走向自适应和持续演进。

对传统流量管理的影响

当前的流量管理系统以明确的边界为基础：

The 控制平面定义意图：哪些端点有效、优先选择哪些路径，以及应用哪些策略。
The 数据平面执行决策：路由请求、应用安全策略并进行负载均衡。

数十年来，这一模型一直运行良好，尤其适用于面向服务的架构和微服务环境。该模型假设可以预先对流量进行建模，并且工作负载遵循可预测的模式。

示例：

负载均衡器将/api/login路由到一个池，并将/api/images路由到另一个池。
运行状况检查会将节点标记为可用或宕机。
静态阈值决定故障转移条件。

这些系统依赖于：

策略和配置与静态资源紧密耦合，例如特定的池和成员
静态构造，例如池和成员
确定性路由，基于路径、标头或协议
集中式编排，用于服务发现、运行状况检查和回退逻辑

但基于智能体的系统具有动态性、自主性和自导式逻辑，使这些假设不再成立。

在智能体架构中，控制平面与数据平面之间的传统界限开始模糊。智能体不只是执行请求，还会嵌入相关逻辑，用于定义请求内容、触发回退的条件、衡量成功的方式，甚至首选路由。传统上，这些都属于控制平面关注的问题，但智能体会将相关逻辑编码到标头、令牌或元数据中，使其随请求本身通过数据平面传输。

这种融合意味着，数据平面不能再只是被动执行集中式决策，而必须动态、主动地解读策略。请求不再只是一个数据包，而是策略的载体。因此，负载均衡器、网关和路由层必须从被动响应的组件演变为实时解读智能体所携带意图的组件。

这一转变动摇了控制平面静态且集中这一核心架构假设。决策逻辑不再如此，而是变得分布式、可移植且个性化，随每个请求流转并在运行时执行。这不仅是部署方式的变化，也改变了决策的位置和方式。

这实际上完成了Kubernetes在抽象底层基础设施时开启的变革。网络、存储，甚至L4流量路由，都成为声明式控制界面背后的“管道”。Kubernetes并未消除这些层，而是降低了它们的重要性。它们变得不可见、自动化，并从属于新的意图驱动型系统。

智能体架构也采用同样的方式，但作用于整个技术栈，而不仅仅是基础设施。

流量管理面临的重大颠覆

为通过实际示例具体说明这些中断，请考虑以下本地应用交付场景：

示例：某区域性电子商务网站使用ADC管理内部API流量。一个AI智能体负责优化订单履约速度。该智能体发现，某个特定API端点（例如/api/inventory/check）因请求复杂度增加和后端数据库资源争用而出现性能下降。传统负载均衡算法（包括“最快响应”算法）无法准确反映这种性能下降的具体情况，因为这些算法以给定池成员的所有响应为基础计算总体平均性能，而不是按任务或调用分别计算。

为满足SLA要求，该智能体会将这些库存检查请求重新路由到针对事务查询优化的备用节点组。具体做法是为每个请求添加上下文标头，例如X-Task-Profile: inventory-sensitive。负载均衡器经过适当配置后，可以解析该标头并据此引导流量。但是，由于这些节点并未预先分配到与/api/inventory关联的静态池中，流量引导服务必须能够遵循智能体携带的指令，并在不依赖静态结构的情况下动态解析路由。

此场景凸显了池等静态结构的局限性，以及对可感知上下文、支持动态编程的流量执行机制的需求。

基于智能体的系统打破了流量工程中的若干基本假设：

控制平面与数据平面融合：过去，路由决策由静态规则决定；如今，路由决策来自请求本身。这使传统的策略执行逻辑失效。

基于意图的路由：智能体根据目标而非仅根据端点来路由流量。单个端点（如/api/process）可能会根据智能体指令处理数百种不同的任务流。

静态资源池逐渐失去作用：传统资源池以固定角色为前提。但智能体可能前一刻需要访问GPU，下一刻又需要针对CPU进行优化，因此固定的资源池成员关系过于僵化。

回退和故障转移更具策略性：过去，故障转移意味着“尝试下一台服务器”。如今，智能体会评估实时性能和历史结果，并有策略地决定后续操作。

流量模式动态形成，而非简单重复：智能体按需创建工作流。无法预先定义所有路径，这些路径会根据需求动态形成。

这些颠覆性变化要求负载均衡器、网关和可观测性技术栈能够响应动态变化的实时流量逻辑。

重新审视运行状况和性能指标

运行状况和性能指标一直是流量管理的基础。负载均衡决策需要了解服务器是否可用、响应速度以及负载程度。但在智能体驱动的系统中，运行状况并非简单的二元状态，性能也不能按宽泛类别取平均值。指标必须反映目标是否适合执行特定任务，而不能只反映目标是否正常运行。

重要性：运行状况指标会直接影响流量导向、故障转移决策和性能优化。在智能体原生环境中，每个请求的意图各不相同，可能需要不同的路径或响应保证。传统方法无法满足这一需求，原因如下：

它们依赖粗粒度的汇总指标（例如平均响应时间），因而掩盖了特定任务的差异。
它们仅从服务器视角评估运行状况，无法洞察智能体层面的成功情况或满意度。
它们假设流量具有同质性，但当请求由运行时决策决定时，这一假设并不成立。

示例：根据运行状况检查，一组API服务器可能全部处于“健康”状态，但其中一台始终无法在100 ms内响应X-Task-Profile: inventory-sensitive查询。即使基础设施显示一切正常，预期达到这一延迟水平的智能体仍会判定为失败。

所需条件：

实时的逐请求遥测数据，可反映意图和观测到的结果。
针对特定任务的运行状况评分，可识别节点在哪些部分任务中性能下降，即使该节点在其他任务中运行正常。
将智能体报告的成功或失败结果纳入路由和优先级排序逻辑的反馈循环。

数据标注工具可以在此发挥关键作用，对传输中的流量进行标注，并捕获性能及其与上下文的一致性。这样，系统不仅可以推断发生了什么，还可以判断结果是否达到了发起方的目标。

智能体架构中的回退、熔断和重试能力

在传统基础设施中，重试、重定向到备用节点或触发断路器等回退行为均在基础设施层实现。负载均衡器、代理和网关使用预定义阈值（例如超时、错误率）来确定何时停止将流量路由到目标，并尝试使用替代目标。

智能体架构则颠覆了这一逻辑。

智能体自带回退策略。请求本身包含重试策略、升级逻辑和以目标为中心的优先级。这会增加复杂性，并可能与基础设施级故障转移机制发生冲突。

重要性：

基础设施可能会将某个故障判定为可恢复，而智能体却认为该故障不可接受（反之亦然）。
代理和基础设施可能会同时尝试回退，从而导致重复重试、延迟增加或流量循环。
针对常规流量设计的熔断器可能会阻止访问智能体仍认为合适的服务。

主要风险：

双重回退：Agent和基础设施都会重试，从而产生不必要的负载。
竞态条件：系统原本可在几毫秒内解决问题，但Agent却升级为成本更高或安全性更低的选项。
确定性故障转移失效：静态策略无法适应智能体的细微差异。
损坏：智能体元数据格式错误、缺失或无法读取。

适配指南：

基础设施应逐步演进，以识别代理指定的回退优先级（例如，通过X-Fallback-Order、X-Timeout-Preference）。
必须使断路器能够感知意图，以支持按任务或按智能体应用逻辑，而不是采用全局阈值。
考虑引入可感知协商过程的故障转移逻辑，由智能体提出首选策略，网关根据系统运行状况、负载和策略进行裁决。
当代理元数据缺失、不完整或未通过架构验证时，流量系统必须支持默认执行逻辑，以确保平稳降级。
基础设施必须检测并阻止递归委派或相互冲突的代理重试，以免在系统降级期间触发循环或导致流量激增。

示例：负责实时欺诈检查的智能体要求在50 ms内获得响应。其回退逻辑会优先选择缓存的部分结果，而不是速度较慢的完整查询。不了解这一点的基础设施仍可能将请求路由到提供完整服务的后端，造成用户可感知的延迟。协作性更强的模型会遵循智能体的回退优先级，提供速度更快的降级响应。

随着决策向技术栈上层转移，回退策略也必须随之调整。断路器和重试逻辑不能一成不变或缺乏透明度；它们必须适应智能体表达的偏好，同时保障系统整体的安全性和公平性。

高可用性和故障转移仍然至关重要

尽管智能体架构将决策和协调转移到请求层，但底层基础设施仍负责确保核心系统的可靠性。因此，基础设施层的高可用性（HA）和故障转移机制仍不可或缺。事实上，随着系统的行为日益动态化和自主化，这些机制变得更加关键。

代理可以根据目标和上下文引导流量，但在发生故障时，仍需依靠网络来确保服务可访问并保持韧性。无论代理采用何种回退策略，负载均衡器都必须检测无法访问的节点、出现故障的服务或性能下降的环境，并实时重新路由流量。

始终不变的核心职责：

监控池成员和后端服务的运行状况
检测网络分区或路由故障
根据存活状态、可用性或系统级性能下降情况重定向流量
在需要时保持有状态服务或会话的高可用性

代理可能包含用于确定“下一步该做什么”的逻辑，但“节点宕机后能多快恢复”仍由负载均衡器负责。

自适应、可感知智能体的路由逻辑绝不能以牺牲运行稳定性为代价。具备完善监测能力的基础设施必须保留以下能力：

节点不可用时即时故障转移并重新平衡流量
可保护代理和服务免受上游故障影响的弹性高可用性拓扑
快速自动恢复，可与代理回退逻辑协同工作，而不会发生冲突

简而言之，智能体驱动的架构并未消除故障转移的必要性，反而使其变得更加关键。基础设施必须更快地响应，更敏锐地感知上下文，同时不能成为自主行为的瓶颈。

对企业流量管理的影响

向基于智能体的架构转型，从根本上改变了负载均衡器和网关等流量系统的运行方式。传统流量系统根据预配置的策略做出决策，而这些策略通常位于请求之外；智能体驱动的系统则将策略嵌入请求本身。这正是模型上下文协议（MCP）所实现功能的基础：针对每个请求执行嵌入式策略。

我们将这种模型称为“有效载荷中的策略”。代理无需由集中式系统解析每种边缘情况，而是将相关策略决策（例如回退策略、节点偏好、容错能力或隐私要求）编码到每个请求中。随后，基础设施必须实时读取、解释并执行这些策略指令。

这种新的执行模型改变了流量管理组件的角色：

从决策者转变为执行者：基础设施不再决定流量去向，而是执行代理所携带的决策。示例：负载均衡器读取到X-Route-Preference: gpu-optimized后，必须据此转发流量，即使该节点不在原始池中。
运行时可编程：iRules和策略必须评估以下标头：X-Intent、X-Context或X-Goal。这会将逻辑从预配置路径转变为动态的内联解析。
上下文感知路由：ADC及类似服务需要根据身份、意图和上下文进行路由，而不能仅依据主机或路径。
语义可观测性：日志不仅应显示发生了什么，还应说明原因：“智能体因延迟超过阈值而重新路由”比仅显示“已路由至池B。”更有用