AI应用交付十大要点：定制应用需求

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

我们最初的ADC09条目提出了一个务实的观点：并非所有应用都能完全适配标准化交付模式。有些应用需要自定义路由、专门集成或独特的处理方式，这些需求超出了默认的负载均衡和安全模式。结论同样务实：如果强行让每个应用都套用同一种模式，要么会导致应用无法正常运行，要么会增加运维负担。解决之道始终是在交付层实现可编程性，从而无需重写所有内容即可灵活调整。

这一前提仍然成立。

变化在于，AI使具有这种行为的应用数量大幅增加。过去的边缘情况正迅速成为常态。

AI系统并非一成不变。它们采用组合式架构，由上下文驱动，并且在处理请求时日益自主。这意味着，“定制化”不再只是少数应用的特征，而是架构本身的特征。

定制化AI应用需求带来的影响

对可用性的影响

在传统系统中，定制需求通常会在路由和故障转移中引入自定义逻辑，从而增加保障可用性的复杂性。标准模式以行为可预测为前提。当应用的行为偏离这一前提时，就必须相应调整可用性策略。

AI将问题的重点从路由请求转向完成决策。

向AI系统发出请求并非简单的事务。它可能涉及选择模型、检索上下文、应用策略、生成响应，还可能调用其他服务或工具。每个步骤都可能独立成功或失败，并且可能受到不同约束，例如延迟阈值、成本限制或监管要求。

这意味着，可用性不再仅仅取决于端点是否可访问，而是取决于系统能否成功执行完成请求所需的整个决策链。

系统中的每个组件在技术层面都可能运行正常，但应用仍无法生成答案。模型可能可用，但不允许用于特定数据集。检索步骤可能会返回因策略限制而无法使用的数据。智能体可能已启动工作流，却因某项必要操作受阻而无法完成。

这带来了一类不同的可用性挑战。传统故障转移假定可以将请求发送到其他位置。而在AI系统中，通常需要寻找其他方式来完成任务。这要求交付层能够动态决策，而不能仅依赖基础设施冗余。

对可扩展性的影响

原文指出，依赖定制集成的应用难以扩展。每增加一项依赖都会提高复杂性，而扩展通常需要投入额外的开发工作，才能有效管理这些集成。AI本身基于组合构建，因此会进一步放大这一问题。

AI驱动的应用可能依赖多个模型、向量数据库、API和外部数据源。这些要素的组合并非固定不变，而是可能根据请求、用户或上下文发生变化。这种可变性会成为影响可扩展性的主要因素。

扩展能力不再只是每秒处理更多请求，还要应对每个请求中更多样的行为组合。

如果每种变化都必须通过应用程序代码实现，系统很快就会变得难以管理。变更风险随之增加，部署速度减慢，应用程序也会充斥着东拼西凑的条件逻辑。

因此，传统应用所采用的同一解决方案变得更加重要：将这种可变性从应用中移出，转移到交付层。路由决策扩展为编排决策，服务插入转变为动态组合。交付层负责选择适当的组件组合，以满足每个请求。

如果不进行这种转变，复杂性本身就会导致系统无法扩展。

对运营效率的影响

定制需求始终会增加运营开销。每个例外都需要维护，每项定制都会引入新的故障点。久而久之，这些负担不断累积，使系统更难管理，演进速度也更慢。这就是运营债务，而AI会加速其累积。

系统不再只是处理预定义路径，而是会生成路径。不同的提示词可能会触发不同的执行路径。智能体可能会以事先未明确设计的方式将多个操作串联起来。新模型和服务会定期引入，并且各有其特性和约束。

这会持续产生各种变化，运维团队必须将其纳入考量。

如果只能通过修改应用代码或更新静态配置来管理这些变化，系统就会变得脆弱。团队会将时间耗费在应对边缘情况上，而无法从整体上管理系统。不同环境之间会出现不一致，系统行为也会逐渐偏离预期。

因此，运营效率取决于能否集中控制这种可变性。交付层必须发挥稳定作用，消除差异，并在原本动态变化的系统中实施一致的策略。否则，定制化很快就会陷入混乱。

管理定制需求的实用做法

将可编程性作为核心能力

无论是AI、传统应用、现代应用，还是<在此插入下一代技术>，可编程性始终是满足定制需求的关键。无需将逻辑硬编码到应用中，而是在交付路径中引入可编程层，以适应不同需求。

对于AI而言，这一点至关重要，因为AI系统发展迅速。新模型不断推出，策略会发生变化，数据源会转移，交互模式也会不断涌现。设计时无法预见所有这些变化，也不能每次发生变化都重新构建应用。

可编程交付层支持就地调整。您可以检查请求、应用上下文感知路由、修改输入和输出，并根据需要添加或移除服务。更重要的是，这些操作可以在各个应用中一致实施。

此时，应用交付不再只是底层管道，而更像是一个控制平面。它不仅负责传输流量，还会塑造系统的运行方式。

流量引导转变为决策路由

传统应用交付侧重于将流量导向正确的目的地。过去关注的问题一直是“这个请求应该发往哪里？”，而AI让这个问题变得更加细致：“应采用什么方式来处理这个请求？”

有时，这意味着根据延迟、成本或合规要求，从多个模型中进行选择。有时，这意味着先为请求补充更多上下文，再将其发送给模型。有时，这意味着完全绕过AI，将请求路由到确定性服务，以提供更准确或更符合合规要求的答案。

决策不再只关乎位置，更关乎如何执行。

这一转变使路由成为更高层级的功能，负责从一组可用能力中选择请求的处理路径。这也意味着，交付层不仅需要了解网络状况，还需要掌握策略、上下文和预期结果。

这是ADC09一贯主张的自然延伸。当应用有独特需求时，交付层必须相应调整。AI只是让这种调整发生在更高层面。

结论

可编程性这一能力始终基于一个简单的事实：应用并非千篇一律，基础设施必须适应它们之间的差异。这一事实从未改变。

AI使这些差异出现得更频繁，也更加复杂。系统变得更具动态性和可组合性，也更加依赖运行时决策。因此，“标准”应用路径这一概念越来越难以维持。

应对之策一如既往，但现在更为迫切。

交付层需要具备可编程性。您需要集中控制请求的处理、路由和响应方式，还需要能够适应新的要求，而不必每次发生变化时都重写应用。

因为在AI驱动的架构中，定制化已不再是设计时需要规避的例外情况。

它正是您要为之设计的运营模式。

详细了解全球组织面临的十大应用交付挑战。

关于作者

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章