应用交付的分类与演进

让我们从熟悉的开始。 以第4层（L4）路由为基础的传统流量管理模型，依然支撑着互联网的大部分。 这种方式依赖于以下基本参数：

• 四层路由： 基于传输层信息，如IP地址和端口号，做出路由决策。
• 基于路径的路由： 通常在应用层（第7层）对URL路径进行有限检查。
• 同质池： 将后端服务器视为完全相同，无需根据专门功能进行区分。
• 负载均衡： 均匀分配连接，避免服务器过载。

问题何在？ 该模型几乎没有理解请求的意义。 它把流量当作同质的数据包处理，却忽略了不同任务各自的需求。 在生成式人工智能、嵌入式大型语言模型（LLM）和基于代理的框架盛行的当下，这种无视差异的做法成了隐患，因为流量已不再均等。

考虑两次 HTTP POST 请求：

• 可能是简单的 CRUD（创建、读取、更新、删除）操作，比如更新用户资料。
• 另一个案例可以启动复杂的多智能体工作流，比如一个由 AI 驱动的推理循环，调用五次下游工具，写入数据库，并开始一个长时运行的文本摘要任务。

如果您的基础设施对这些请求一视同仁，采用相同的路由规则、超时时间和后端服务器，就可能埋下隐患。 把资源密集型的 AI 任务当作轻量级数据库查询处理，会造成瓶颈、故障或性能下降。 现代流量需要更智能的管理。

我们已经从事L7路由多年。 通过匹配路径、检查负载、查看头信息，判断将流量发送到哪个池。 这就是内容路由。 它确实很有用。 但它只告诉你请求包含什么，却无法告诉你请求存在的原因。

我们需要以基于上下文的分类推动前进。

• 运行于 L7+ 层，功能不仅限于负载检查。
• 我们根据意图、复杂度和成本对流量进行分类。
  • 这是摘要任务还是用户登录？
  • 它是递归的、由人工智能生成的，还是对延迟要求高？
• 资源池区分于能力，而不仅仅是容量。
• 我们在做路由决策时，会考虑目的而不仅仅是格式。

这就是我们如何实现从将流量视为“待提供的内容”到“待处理的任务”的转变。 它使你能够实时决定请求应发送到何处、如何排定优先顺序，以及根据请求的实际目的应用何种策略。 你可以称之为意图驱动。 你可以称之为情境感知。 称呼并不重要，关键是转变真实存在：请求不再只是简单的交易。 它们正在变成调用。 触发点。 用HTTP承载的目标。

所有这些都直接对应于应用交付十大优先事项中的第4项（流量控制）、第5项（流量引导）和第6项（延迟管理）。 因为你无法管理、引导或优化无法理解的内容。

随着自主系统和递归规划器融入生产环境，我们正迈向新的方向。 我们不再仅仅提供内容。 我们开始管理目标。 这将彻底改变现状。

在这种模型下，单个请求不会总是对应单一响应。 相反，它可能触发一系列更小的任务。 其中一些任务会并行执行。 另一些则需要等待其他任务完成后才进行。 您不仅是在路由流量，更是在协调整个工作流程。

请将其视为一种工作流程，而非简单的管道。 您会管理一系列步骤清单，每一步都推动最终结果。 部分步骤可以立即执行，其他则需按顺序进行等待。 我们会根据能力、策略和当前负载，协调、监控并调整整个流程。

到那时，传统路由逻辑就开始失效了。 当每个请求都可能发展成多步骤、多角色的流程时，静态路径和统一策略无济于事。 你需要一个能理解任务内容、需求，以及最适合处理对象的系统，而不只是简单地知道数据包该发往哪里。

关键在这里：没有分类，你无法完成任何操作。 如果你的基础设施不了解请求的目的，就无法智能地进行路由。 这不是遥远的未来，而是一种正在形成的现实。 分类是我们实现从请求路由到真正协调的桥梁。