流式 BFF：AI 原生架构下的智能体胶水层

TL；DR：我们必要一个新的框架、胶水层，来资助我们适配生成式 AI 的输出，以及解决流式数据传输的问题。
  在已往几个月里，我们一直在项目上探索：如何计划更好的架构，以将业务流程和开发流程中的各类智能体结合起来，进一步释放生成式 AI 的潜力？诸如于面向 IDE、DevOps、Team AI 等多个不同消费端的智能体。
  

  在这个过程中，浮现了一种新的架构模式：流式 BFF。
     流式 BFF（Streaming Backend for Frontend） 是一种实用于 AI 原生架构的胶水层，旨在解决 HTTP API 与智能体协同过程中的数据流处理和接口不一致等问题。
    引子 0：生成式 AI 时代的架构演进

  在先前的文章里《LLM 优先的软件架构》里，我们先容了四个原则：用户意图导向计划 、上下文感知、原子本领映射、语言 API。而那篇《语言接口：探索大模型优先架构的新一代 API 计划》中，我们先容了 自然语言即 DSL、实时文本流 DSL、本地函数动态署理等模式。这些模式为我们开发 AI 原生应用带来了新的思路。
  在已往构建 AI 辅助研发应用时，除了应用内置的各类编码智能体之外，我们的重点还放在云端智能体的集成上，旨在提拔团体服从和智能化水平。这些智能体包含：
  

• AI 平台智能体。如摆设在类 Dify 平台上的智能体
  
• 三方智能体服务。即提供智能体功能的别的服务
  
• 系统内智能体。即可以通过函数调用的内部智能体
  

  而由于生成式 AI 的输出方式：类似于打字机效果，字符逐字词输出。在这种限制了交互体验的场景下，主流的智能体提供的都是流式输出方式。这种流式传输的实现通常依赖于Server-Sent Events（SSE）技能，它允许服务端主动向客户端推送消息，创建长连接后，服务端可以源源不断地向客户端推送消息， 从而实现流式输出。
  引子 1：低沉 Streaming Hell 带来的影响

  

  当客户端直接调用大模型时，通常只需发出一个简单的请求即可获取完整的相应。然而，当我们在服务端通过流式方式（例如 Server-Sent Events, SSE）处理数据时， 环境变得更加复杂。每当增长一层服务或署理时，流式数据处理的负担都会通报给下一层。这种层层累积的复杂性，我们称之为 Streaming Hell。
  其带来的挑战有：持续连接的开销、多层流式通报的传染效应、资源管理的复杂性、错误传播和恢复等。要解决 Streaming Hell，我们必要采用一些策略：
  

• 流式处理标准化：界说同一的接口和协议，使各层服务能够一致高效地处理流式数据。
  
• 异步与变乱驱动架构：采用异步或变乱驱动架构，减少对同步流式处理的依赖，提高扩展性和相应速率。
  
• 减少层级依赖：尽量减少不须要的服务调用条理，制止每一层服务都直接处理流式数据。
  
• 流式数据聚合：在须要时对流式数据进行聚合和处理，以减少不须要的通报条理，优化系统性能。
  
• 错误处理与重试机制：计划结实的错误处理和重试机制，确保当某一层服务出现错误时能够进行自动恢复或降级。
  

  通过有效的计划，我们可以减少 Streaming Hell 带来的复杂性，并提高系统的可靠性和可维护性。
  引子 2：智能体应用架构面临的新挑战

  

  在业务系统集成这些智能体时，系统的架构必要随之演进，以顺应流式输出的要求。例如，后端服务必要支持流式相应，前端应用则必要能够处理和展示这种渐进式的数据流。
  挑战 1：同一多模型接口，简化数据传输与解析

  在我们构建面向普通用户的开源应用，如 ClickPrompt、AutoDev 和 Shire 时，必要支持不同大语言模型的接口。由于用户大概选择不同的模型供应商， 这就要求我们能够兼容多种模型接口。在 AutoDev 时代，我们重要采用兼容 OpenAI 格式的接口，并且可以支持大量的自界说数据格式， 如采用 JsonPath 从 $.choices[0].message.delta.content 获取文本。
  而在非公开 API 场景下，这种基于 JSON 格式的接口存在一些挑战：
  

• 解析耗时：JSON 格式必要在应用中进行解析，这会消耗额外的处理时间和资源。
  
• 数据传输量大：在某些场景下，我们只必要传输文本内容，而不必要整个 JSON 对象，这导致了不须要的数据传输。
  

  以是在时，我们通常会考虑简化接口、同一接口格式、优化数据传输等方式来提拔系统的性能和用户体验。
  挑战 2：智能体接口不一致

  相似的，当我们有 AI 平台等不同的智能体提供商时，由于不同的智能体通常有各自独特的接口规范，通常会导致接口与处理方式不一致。例如，在 Dify 平台中：
  

• 在 Completion 场景下，输出为 $.answer。
  
• 在 Workflow 场景下，输出为 $.data.outputs，且 outputs 本身也是一个对象。
  

  这种接口的不一致性在多智能体协同工作时增长了前端处理的复杂度。而为了更好的兼容不同的智能体，通用的方式是引入一层映射机制，将不同智能体的输出同一为一致的文本格式。
  挑战 3：与传统 API 服务的不同步

  在 Web 2.0 时代，API 的相应速率至关重要。为了提高相应速率，我们采用了请求缓存、DNS 缓存以及 CDN 缓存等多种优化本领。然而，当前服务端利用的是 SSE（Server-Sent Events）技能，以逐字生成的方式传输数据，这与传统 API 的即时相应模式存在显着差别。
  尽管 SSE 不是长连接，但仍需考虑其对服务器资源的消耗。别的，生成式 AI 本身的相应速率有限，这进一步影响了系统团体的相应时间。同时， 前端在处理流式数据时，必要更高的处理本领和更复杂的逻辑来管理和展示逐步生成的数据流。
  流式 BFF：AI 原生架构下的协同模式

  

  传统的 BFF 模式关注为特定的前端应用定制后端服务，以满足前端的特定需求。在 AI 原生应用中，由于生成式 AI 的特性以及多个智能体必要协同工作， 我们必要对 BFF 进行扩展，支持流式数据和实时处理。
  界说流式 BFF

  模式：流式 BFF（Streaming Backend for Frontend） 是一种实用于 AI 原生架构的胶水层，旨在解决 HTTP API 与智能体协同过程中的数据流处理和接口不一致等问题。
  意图：通过在胶水层，同一智能体接口，处理不同客户端的智能体协同，以简化系统的开发和利用。
  适合场景：当且仅当系统中，存在不同的客户端，并且这些客户端必要与多个智能体协同工作时。
  示例：在构建生成式 AI 辅助研发应用时，存在 IDE、DevOps 平台、IM 应用、团队 AI 入口等多个客户端，多个客户端之间必要部分相同、但是又有所 不同的智能体。
  通常来说，流式 BFF 的焦点特性包括：
  

• 同一接口：封装并标准化不同智能体的接口，提供一致的数据格式，简化前端开发。
  
• 流式处理：支持实时数据流，能够处理生成式 AI 逐步产生的数据，实现边生成边传输，提拔用户体验。
  
• 实时过滤：在数据流中实时检测和过滤敏感信息，保障系统安全和合规性。
  
• 和谐传统 API：与传统的 API 服务高效协同，解决相应速率和数据同步问题。
  

  当然，随着我们对流式 BFF 的进一步探索，我们信赖流式 BFF 另有更多的潜力等待挖掘。
  我们必要怎样的流式 BFF？

  尽管，当前我们开端思考了流式 BFF 的一种大概性，然而如何去构建这样的工具，依旧是一个未知的领域，还必要进一步的沉淀和探索。我们的早先版本是基于 Vercel 的 AI.js SDK 配合 Next.js 来构建的原型，由于 AI.js 提供了非常好的流式接口支持，与此同时，JavaScript/TypeScript 灵活的 any 特性 也使得我们能够快速地构建出一个流式 BFF。
  和谐不一致性

  BFF 的本质在于和谐前端与后端的交互，尤其是在面对复杂服务生态时，BFF 已经很好地解决了与传统 API 的一致性问题。它通过提供一层抽象， 同一了多个后端服务的调用方式。在实时处理场景下，我们更必要关注如何提供外部或第三方服务的接口，而不是构建全新的架构。因此，流式 BFF 的焦点问题应该聚焦于如何在接口层面上实现同一，同时通过流式处理确保实时数据传输的稳固性和高效性。
  内建主流大模型的支持

  得益于 Vercel 的 AI SDK，我们能够轻松地为 BFF 内建对主流大模型的支持。Vercel 的 AI SDK 针对多个大模型（如 OpenAI、Anthropic、LlamaIndex 等） 进行了适配，提供了流式接口，使得我们能够无缝地集成不同的 AI 模型，并通过同一的流式处理机制来相应这些模型的数据。
  一个典型的流式模型处理模式如下：

1. export function toDataStream(
2.   stream: AsyncIterable<EngineResponse>,
3.   callbacks?: AIStreamCallbacksAndOptions,
4. ) {
5.   return toReadableStream(stream)
6.     .pipeThrough(createCallbacksTransformer(callbacks))
7.     .pipeThrough(createStreamDataTransformer());
8. }

复制代码

在这种计划模式下，我们可以轻松处理来自不同模型的流式相应，确保数据传输的连贯性和一致性。
  动态的流式接口转换

  在处理生成式 AI API 的流式数据时，通常我们会接收到以下几类数据：
  

• event，如 ping 等变乱。
  
• data：JSON 数据。
  
• 竣事标志，如 [DONE]、 tts_message_end 或 message_end。
  

  在现实应用中，通过 JSONPath 或类似的工具，流式 BFF 可以根据不同 API 的返回内容动态调整数据处理方式，确保每个流式相应能够快速转换为前端可用的格式。
  我们必要考虑在流式 BFF 中引入这种动态接口转换机制，以应对不同智能体的流式相应。
  总结

  生成式 AI 原生架构要求我们重新审视传统后端模式。流式 BFF 为智能体接口不一致、与传统 API 不同步等问题提供了有效的解决方案。通过同一接口、 流式处理、实时过滤及 API 协同，流式 BFF 能提拔系统的可靠性和相应速率。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。