负载中的策略： 为 AI 代理架构做好准备

AI代理不仅是智能应用。 它们代表了应用操作、决策和适应方式的根本转变。 与传统系统不同，代理不仅被动响应流量策略，更自主制定策略。 它们每次发送的请求，不仅携带数据，还包含嵌入式逻辑：该做什么，回退如何执行，以及成功的标准。

这种转变让我们将决策权从静态的控制平面直接移到了运行时环境。 它打破了控制平面和数据平面长期以来的界限，促使负载均衡器、网关和代理等流量基础设施，成为逐请求策略的主动执行者，而非预设路由的被动工具。

本文探讨代理架构如何打破流量工程的核心假设，从健康检查和回退逻辑到可观察性与安全执行。 我们说明静态池和基于平均值的健康指标等传统构件为何无法满足基于每次请求意图的新时代需求。 本文强调，第7层基础设施必须进化，否则将沦为可靠却缺乏战略价值的标准管道。 为了适应变化，您需要重新设计流量架构：使其具备运行时可编程性、上下文感知，并兼容代理本地协议如模型上下文协议（MCP）。 这意味着调整回退逻辑、采纳语义级可观察性，并支持执行由代理发起的策略。 实时数据标记等新兴工具为这一转型提供了关键支撑。

简而言之，流量管理的未来不仅是传输数据包，更是实现目标。

代理架构引入了全新的运营模式。我们设计的自治式生成型人工智能组件——代理，能执行面向目标的任务，实时做出决策，并具备动态调整执行所需的上下文。 这些代理的运作类似于现有的服务链，但不再依赖预置的工作流程。 它们会根据目标、环境状态和观察到的结果，在运行时确定最佳执行路径。

这一转变标志着我们从传统的集中式、预设流程体系，迈向能够实时构建执行路径的去中心化动态系统。 系统不再依赖静态微服务链的可预见性，而是借助实时数据和意图作出灵活且响应迅速的决策。

基于代理的系统具有以下特点：

• 以目标为导向的执行： 代理根据提示或任务行动，而非固定流程。 它们会根据目标完成情况选择 API、调整参数并重新调整路径。

  示例： 处理“解决客户投诉”的代理可能会根据之前的结果，采用不同方式调用账单、帐户和消息 API。

• 可携带的上下文： 代理拥有自己的记忆、状态和策略。 它们通过模型上下文协议（MCP）或结构化元数据，将这些上下文嵌入每个请求中。
• 运行时自适应： 代理无需等待基础设施决策，能够实时调整，执行重试、改道、升级或动态调整执行路径。
• 内嵌可观察性： 每个操作都会自我说明。 代理能够报告为何选择特定路径、评估了哪些因素及目标是否达成。 这是作为行为的可观察性，而不仅仅是日志和指标。

这些变化让应用格局从单一可预见，转变为灵活自适且持续演进。

目前的流量管理系统基于明确的边界构建：

• 控制平面确定意图：哪些端点有效，应优先选择哪些路径，适用哪些策略。
• 数据平面负责执行决策：进行请求路由、实施安全策略、平衡负载。

几十年来，特别是在面向服务的架构和微服务环境中，我们采用的这种模型一直表现出色。 我们基于假设：流量可以提前规划，且工作负载呈现出可预测的模式。

Examples:

• 负载均衡器将/api/login引导至一个服务池，将/api/images引导至另一个服务池。
• 健康检查用以判断节点的可用性。
• 我们利用静态阈值来判定故障切换的条件。

这些系统依赖于：

• 策略和配置工具与静态资源（如特定池和成员）紧密绑定
• 静态结构如池和成员
• 基于路径、报文头或协议的确定性路由
• 集中编排，实现服务发现、健康检查和故障切换

但基于代理的系统带来了更大的灵活性、自主性和自驱逻辑，打破了这些固有假设。

在代理架构中，控制平面与数据平面之间的传统界限正在消失。 代理不仅执行请求，还内嵌了定义请求内容、设置回退条件、衡量成功标准以及确定首选路由的逻辑。 这些通常属于控制平面职责，但代理将它们编码在随请求通过数据平面传递的标头、令牌或元数据中。

这种融合意味着数据路径不再能被动执行集中决策。 它必须能够即时主动地解析策略。 请求不再只是一个数据包，而是策略的具体表现。 因此，负载均衡器、网关和路由层需要从被动响应转变为实时解读代理传递意图的组件。

这种转变颠覆了控制平面静态且集中的核心架构假设。 决策逻辑变得分布式、便携化且个性化，随着每个请求动态传递并在运行时执行。 这不仅是部署方式的转变，更改变了决策的地点和方式。

这有效延续了 Kubernetes 的使命，将底层基础设施——网络、存储，甚至 L4 流量路由——抽象为背后的“管道”，并通过声明式的控制界面管理。 它没有消除这些层，而是将它们降级。 这些层变得隐形、自动化，并服务于一个全新的意图驱动系统。

代理架构作用相同，但覆盖的是整个堆栈，而不仅仅是基础设施。

为了让您更好地理解这些变化，举一个本地应用交付的实际案例：

示例： 一家区域性电商网站利用 ADC 管理内部 API 流量。 我们指派了一名 AI 代理优化订单履行速度。 它发现某个特定 API 端点，例如/api/inventory/check，因请求复杂度增加和后端数据库争用导致性能下降。 传统负载均衡算法，包括“最快响应”，未能精准反映这一性能下降，因为它们仅以整体平均响应计算性能，而非针对每个任务或调用进行评估。

为了达到 SLA，代理会将这些库存核查请求重定向到专为事务查询优化的备用节点组。 它通过为每个请求添加上下文标头来实现，例如 X-Task-Profile: inventory-sensitive。 配置正确的负载均衡器能够识别这一标头，并据此引导流量。 但由于这些节点未预先分配到与 /api/inventory 关联的静态池内，流量控制服务必须能够响应代理传递的指令，动态确定路由，而不是依赖静态配置。

此场景展示了静态结构如池的局限性，以及需要具备上下文感知和动态编程能力的流量执行。

基于代理的系统突破了网络流量管理的几个基本假设：

控制与数据平面融合： 过去依赖静态规则做出路由决策，现在由请求本身驱动。 这意味着传统的执行逻辑被重新定义。

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

静态池已不再适用： 传统池往往承担固定职责。 但代理可能时而需要 GPU 访问，时而需 CPU 优化，使得池成员身份过于死板。

回退和故障转移成为关键策略： 过去，故障转移只是“切换到下一台服务器”。 如今，代理会综合实时表现和历史数据，制定最优方案。

流量模式是自然产生的，而非重复出现的： 代理按需创建工作流程。 您无法预设所有路径，它们会根据实际需求形成。

这些中断促使负载均衡器、网关和可观测性堆栈迅速响应不断变化的实时流量逻辑。

健康和性能指标向来是流量管理的核心。 负载均衡决策依赖于了解服务器是否可用、响应速度快慢以及负载情况。 但在代理驱动的系统中，健康状态不是简单的“有”或“无”，性能也不能用大范围的平均值来衡量。 指标必须反映目标是否适合执行具体任务，而不仅仅是是否在线。

重要原因： 健康指标直接影响您对流量的引导、故障切换过程以及性能提升。 在代理原生环境中，每个请求都带着不同意图，可能需要不同的数据路径或响应保障。 传统方法无法满足这些需求，因为：

• 它们依赖浅层聚合指标（例如平均响应时间），这些指标掩盖了任务特有的差异。
• 他们只从服务器视角评估健康状态，却无法了解代理层面的成功与满意度。
• 它们假设流量趋于同质，但请求由运行时决策驱动时，这一假设不再成立。

示例： 一组API服务器可能在健康检查中都显示正常，但其中一台服务器始终未能在100毫秒内响应X-Task-Profile：inventory-sensitive查询。 即使基础设施显示正常，期望该延迟表现的代理依然会判定为失败。

需求如下：

• 实时采集每个请求的遥测数据，准确反映意图与实际结果。
• 特定于任务的健康评分，可以识别某个节点在某些任务中是否降级，即使对于其他任务而言是健康的。
• 我们将代理反馈的成功或失败信息融入请求路由和优先级决策中。

数据标记工具可以发挥关键作用，标记移动中的流量，并捕捉性能与上下文的匹配情况。 这样系统不仅能判断发生了什么，还能评估是否达到了发起者的目标。

在传统基础设施中，我们通常会在基础设施层实现回退操作，如重试、重定向到备份节点或触发断路器。 负载均衡器、代理和网关会根据预设阈值（例如超时和错误率），判断何时停止将流量路由到某个目标，并切换到备用方案。

代理架构改变了这一思路。

代理会带来自有的备用策略。 它们在请求中包含重试规则、升级逻辑及以目标为导向的优先级。 这增加了系统复杂度，且可能与基础设施级的故障切换机制相冲突。

重要原因：

• 基础设施可能认为故障可以恢复，但代理认为不可接受，反之亦然。
• 代理和基础设施可能会同时实施回退，导致重复重试、延迟加剧或流量循环。
• 为平均流量设计的熔断器可能会阻断代理仍然认为最佳的服务访问。

关键风险：

• 双重回退： 代理和基础设施同时重试，增加了不必要的负担。
• 竞态条件： 代理当系统本可在几毫秒内解决问题时，却升级为更昂贵或安全性更低的方案。
• 确定性故障切换失败： 静态策略无法适应代理的细微变化。
• 损坏： 代理元数据格式不正确、丢失或无法读取。

调整指导：

• 我们应该让基础设施支持识别代理设置的回退优先级（例如通过X-Fallback-Order、X-Timeout-Preference）。
• 我们需要让断路器具备意图感知能力，以支持基于每个任务或代理的逻辑，而非仅依赖全局阈值。
• 考虑采用协商式故障转移机制，让代理提出优选策略，网关则根据系统状态、负载和策略进行决策。
• 当代理元数据缺失、不完整或未通过架构验证时，流量系统必须启用默认执行逻辑，确保系统平稳降级。
• 基础设施必须能够检测并阻止递归授权或冲突的代理重试，这些行为可能在系统降级时引发循环或导致流量放大。

示例： 负责实时欺诈检测的代理要求在50毫秒内回复。 它的回退策略会优先选择缓存的部分结果，而非缓慢的完整查询结果。 不知情的基础设施可能仍会将请求路由到完整服务的后端，导致用户感受到延迟。 更协调的模型将遵循代理的回退优先级，提供更快的降级响应。

随着决策层级提升，回退策略也需同步升级。 我们不能让熔断器和重试逻辑保持静态或不透明；它们必须灵活应对代理的偏好，同时确保系统的安全性和公平性。

虽然代理架构将决策和协调转移到请求层，但我们依然依靠底层基础设施来确保核心系统的可靠运行。 因此，基础设施层的高可用性（HA）和故障切换机制依然不可或缺。 随着系统愈发动态且自主，这些机制的重要性也随之增强。

代理可以根据目标和上下文引导流量，但我们依然需要依赖网络，确保出现故障时服务依然可达且具备弹性。 负载均衡器必须实时检测不可访问的节点、故障服务或恶化环境，及时重定向流量，无论代理采用何种回退策略。

始终不变的核心职责：

• 监控池成员及后端服务的运行状态
• 识别网络分区或路由故障
• 基于活跃度、可用性或系统降级情况重定向流量
• 在必要时确保有状态服务或会话的高可用性

代理可能包含决定“下一步该做什么”的逻辑，但负载均衡器仍然负责“节点宕机时我们多快能恢复”。

我们必须确保感知代理的自适应路由逻辑不会损害运营稳定性。 一个完善的基础设施需要具备：

• 节点出现故障时立即切换并重新分配流量
• 强健的高可用拓扑，保障代理和服务免受上游故障影响
• 快速、自动化的恢复，与代理回退逻辑相辅相成，而非相互冲突

简言之，代理驱动架构不会消除故障转移的必要，反而提高了要求。 基础设施必须更快响应，具备更强的情境判断力，同时不成为自主操作的瓶颈。

向基于代理的架构转变，彻底改变了负载均衡器和网关等流量系统的工作方式。 传统流量系统依赖预先配置的策略——通常是在请求之外——做出决策，而代理驱动的系统将策略嵌入到请求本身。 这正是模型上下文协议（MCP）的核心所在：在每个请求中执行嵌入式策略。

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

这种新的执行模型重新定义了流量管理组件的角色：

• 从决策者转向执行者： 网络基础设施不再主导流量走向；它根据代理传达的决策来执行。

  示例： 读取 X-Route-Preference: gpu-optimized 的负载均衡器必须按此转发流量，即便该节点不在原始池内。

• 运行时可编程： iRules 和策略需要动态解析X-Intent、X-Context或X-Goal等头信息。 这把逻辑从预设路径转向实时的内联解析。
• 上下文感知路由： 我们需要基于身份、意图和上下文来路由 ADC 等服务，而不仅仅依赖主机或路径。
• 语义可观测性： 日志应不仅记录发生了什么，更要说明原因： “代理因延迟阈值超标而重新路由”比简简单单“路由到Pool B”更有价值。

数据标注技术及类似工具能通过标记和分类实时请求上下文，帮助您实现语义请求路由和可观察性的有效管理。

AI 代理不会单独行动。 它们会与传统系统协同工作，调用传统 API，操作企业数据库中的业务逻辑，并调用托管在单片后端和微服务上的函数。 对于企业来说，这意味着你不能重新开始，而必须逐步演进。

企业应用架构融合了以下内容：

• 金融领域仍在使用数十年的SOAP接口
• Web 应用背后的 RESTful 服务
• 用于异步库存系统的消息队列
• 云原生微服务
• 具有限速和复杂身份验证的 SaaS API
• 大型语言模型和微调代理

代理必须学会在所有环境中协同工作。 您的基础设施必须实时介入，利用情境感知的策略实施来协调互动。

客服人员不需要多个端点，他们需要实现一个明确目标。 通过抽象层或 API 组合向客服人员提供业务功能（如“查询订单状态”），并通过单一语义入口点调用。

准备步骤： 通过 API 网关或服务网格，将面向任务的端点整合为清晰的输入输出协议。

传统日志记录只关注方法、路径和响应时间。 但代理更关注：

• 任务内容
• 尝试了哪些备用方案
• 是否实现目标

准备步骤： 我们采用语义可观察性工具，通过X-Intent、X-Task-Type和X-Agent-Outcome等标签为网络流量打标签。

代理会在请求中传递回退指令、超时偏好和安全需求。 现有基础设施通常会忽略这些信息。

准备步骤： 扩展流量策略，解析并处理代理的元数据（例如，X-Route-Preference、X-Fallback-Order、X-Data-Class）。 从 iRules 或类似的运行时脚本开始入手。

代理具有自主性。 您需要了解：

• 代理人代表谁行动
• 它能够访问哪些工具
• 允许访问哪些数据范围

准备步骤： 将基于身份的访问和基于属性的策略控制（ABAC）整合进来，而不仅限于 IP 白名单或静态 RBAC。

基础设施和代理无法彼此竞速恢复。 让它们分别负责运行时目标和系统性保障。

准备步骤： 明确区分代理回退的控制范围与您管理的基础设施故障转移范围。 设定协商规则及覆盖条件。