以包裹破损的客服工单为例。产品目标是分析工单、读取订单信息、路由工单并起草回复。原型先从更简单的方案开始，只需要一次往返：
后端验证客户身份，把工单文本发给模型，收到建议回复后返回。第一个版本可以正常工作。它还不需要读取应用数据或执行副作用。对于短请求，这是合理的设计：容易理解、调试和运维。如果功能只需要这样，直接调用 Provider API 可能已经足够。
当模型需要应用拥有的信息时，模型调用才会变成更大的问题。下面会逐步演进这个客服工单流程。这是一个说明性场景，并非某个客户部署的真实案例。
阶段一：模型需要应用数据
模型可以阅读工单，但它不知道订单是否存在、何时发货，也不知道应该采用哪条支持政策。这些信息属于应用。后端需要读取数据，只把相关上下文提供给模型：
模型不应该变成应用的数据层。直接给它不受限制的数据库凭据，会让生成结果与高权限访问耦合，也会失去判断它能读取谁的记录的可靠边界。
后端验证请求，检查客户可以访问哪个账户和工单，只读取相关字段，再把范围受限的上下文交给模型。授权、应用状态、业务规则、数据访问和结果校验仍由后端负责。模型可以理解证据，但不能决定这些证据是否可以读取。
工程问题是：怎样让 AI 参与应用的数据流，却不让它变成应用的数据层？Prompt 可以包含工单、发货状态，以及后端选出的相关政策摘录，不需要附上整个客户档案。
阶段二：模型需要触发操作
假设模型把工单归类为紧急，并建议将它转到“商品损坏”队列。现在产品需要修改工单，而不只是展示一段生成文本。
模型可以返回一个结构化提议：
模型的判断： 这张工单似乎紧急，可能应该转到“商品损坏”队列。
应用的权限： 后端检查队列是否存在、客户和工作流是否有权更新这张工单，以及当前状态是否允许这项变更。然后通过应用自己的领域代码执行更新并记录结果。
模型的提议可能错误、过期或包含不允许的字段。后端负责校验提议并执行副作用。如果超时后重试，更新不能重复执行。模型可以建议做什么；应用代码决定是否允许，并负责执行。
此时，请求跨过了模型判断与应用权限之间的边界。
阶段三：一个请求变成多个步骤
客服团队希望最终回复能包含已经核实的工单状态和下一步安排。此时一个合理流程是：模型先分类，后端检查订单并更新工单，然后由第二个模型工作流根据已核实的结果起草回复。
每个阶段都需要前序阶段提供正确输入。第二个模型应该收到后端核实过的发货状态和已成功执行的工单操作，而不是第一个模型的假设。这些就是中间状态：工作在系统之间流转时仍需保留的事实与结果。
一次用户操作产生多次模型和后端交互时，系统必须知道每个事件属于哪个原始请求。ModelRiver 的 channel_id 标识异步请求，Pipeline Webhook 还包含步骤索引，指明当前处理的配置步骤。标识符用于关联事件，但不代表事件只会执行一次。
这时，步骤顺序和部分失败也很重要。假设 Webhook handler 已更新工单，但 ModelRiver 没有收到它的 HTTP 确认。投递可能重试，因此应用需要先做幂等检查，再次执行相同操作前确认是否处理过。callback 边界有另一层保护：ModelRiver 会检查 callback 步骤顺序，并将已完成 callback 的重复提交按幂等方式处理。Provider 重试又是另一回事：故障转移可能选用另一个已配置模型并增加延迟，Provider 时间线会记录尝试。Webhook 投递也有自己的重试策略。每个边界都需要明确的错误路径，说明哪一步失败以及工作流能否继续。
模型选择也成为工作流的一部分。分类可能需要快速且受约束的输出；起草回复则可能使用另一模型或配置。日志应让工程师能定位失败步骤，并查看该步骤的 Provider 尝试和中间结果。ModelRiver 的多步 Pipeline按顺序执行后端事件，可选地运行关联 AI 工作流，并在步骤间传递数据。关键在于明确每次交接，而不是每个功能都要使用 Agent 框架。
阶段四：浏览器还在等待
多步流程可能需要几秒甚至更久。如果使用 POST → 等待 → 响应，浏览器必须一直等到整个 Pipeline 结束。连接中断时，客户可能不知道工单是否已经更新。系统需要把启动请求与交付结果分开：
后端和 AI 继续处理时，客户端仍需要一条接收结果的通道。
异步请求把启动工作和接收结果分开。应用后端调用 ModelRiver 的 POST /v1/ai/async，立即获得一个包含 channel_id、一次性 ws_token 和 WebSocket 连接信息的待处理响应。后端可以把请求句柄返回给浏览器，同时避免暴露 ModelRiver API 密钥。浏览器随后连接 /socket，加入对应请求频道：
令牌用于授权 Socket 连接；项目和 channel_id 标识对应主题。ModelRiver 会在该频道广播请求更新和最终响应。异步流式工作流还可以发送 stream_start、stream_delta、stream_done 和 stream_error。Token 增量与 Pipeline 进度不同：即使没有流式输出 Token，后端 callback 也可以标记某一步已就绪或完成。
如果浏览器在请求仍待处理时断开，任务可以继续运行。客户端可通过自己的后端获取新的单次令牌，再重新连接待处理请求。应用仍负责用户侧状态：判断结果是否属于当前打开的工单、客户是否有权查看，以及工单期间发生变化时该如何处理。
并非每次 AI 交互都需要 WebSocket。短请求使用普通 HTTP 响应更简单。同步请求中的 Token 流式输出，ModelRiver 也支持通过 SSE 传输。当工作需要持续超过初始请求，或者客户端需要在等待期间收到更新时，异步 WebSocket 路径才更有用。具体连接方式可参考异步 API、React 客户端 SDK和流式输出指南。
阶段五：应用后端仍然拥有应用
ModelRiver 不拥有客服产品的终端用户身份、领域规则、记录或敏感操作。应用后端仍负责：
- 验证用户身份，并授权其访问工单和账户。
- 通过自己的数据层读取和修改记录。
- 执行支持政策，并根据领域规则校验模型输出。
- 执行敏感操作并记录应用状态的变化。
- 决定用户允许看到什么结果。
在 ModelRiver 后端 Pipeline 中，配置好的工作流会把初始结果发送到应用的 Webhook 端点。签名 Webhook 包含 channel_id、生成数据和 callback_url。后端按照文档中的签名验证流程验证请求，执行自己的规则和操作，再调用 callback URL。ModelRiver 可以继续执行关联 AI 步骤或下一个后端事件；配置的 Pipeline 完成后，它会在该请求的 WebSocket 频道广播最终响应。
这体现的是职责分工，而不是应用所有权的转移。ModelRiver 协调配置好的 AI 工作及其通信；应用后端仍然是应用数据和操作的权威。后端 Pipeline 指南介绍了 Webhook、callback、投递和错误处理。
阶段六：连接工作逐渐成为系统本身
回头看看这个客服工单功能。模型调用只是其中一环；请求周边的生命周期才构成整个系统：
这些环节单独看都不复杂。维护负担在于可靠地连接它们。如果由应用代码自行搭建完整生命周期，团队可能需要维护 Provider 集成、路由和故障转移、工作流协调、请求关联、Webhook 验证与重试、callback、WebSocket 投递、客户端重连，以及请求级错误可见性。问题不在于功能数量，而在于应用团队要连接并维护多少边界。
团队需要追踪初始模型调用、Provider 故障转移、Webhook 投递、后端 callback、关联模型步骤，以及客户端最终收到的结果。请求时间线可以把这些运维事件串联起来。否则，模型响应成功可能掩盖工单更新失败，后端正常工作也可能因为浏览器没有收到最终响应而看起来像是出了问题。
这就是 Gateway、框架和 ModelRiver 之间的架构区别：
不同基础设施层简化的是同一应用中的不同边界。
AI Gateway主要解决应用与 Provider 之间可靠连接、路由和 Gateway 运维。LLM 框架帮助构建 AI 逻辑、工具、工作流状态和编排。ModelRiver 包含重要的 Gateway 能力，包括 Provider 连接、路由和故障转移；它的异步 Pipeline 也将配置好的 AI 工作与后端 Webhook、callback 和 WebSocket 交付连接起来。这些层可以组合使用。ModelRiver 不取代客服后端，也不要求更换其 AI 框架。
当问题从模型调用转为完整生命周期，基础设施边界也随之变化。关键在于应用团队希望自行运维请求路径中的哪些部分。
简单架构已经足够时
如果功能只需要 后端 → 模型 → 响应，就保持这样的架构。直接调用 Provider API 通常更容易理解，组件和运维依赖也更少。当多个 Provider、路由或故障转移变得重要时，Gateway 仍可能有用；但使用它并不要求应用采用异步 Pipeline。
当请求需要应用数据、后端操作、多次 AI 交互、异步处理、外部服务或实时客户端更新时，更完整的生命周期才值得付出额外成本。即便如此，也只引入功能需要的部分。一个短暂的同步分类功能，不需要因为另一个功能用了 WebSocket 就跟着采用它。
我们得到的经验
模型不应该拥有你的应用。 模型可以理解证据并提出操作建议。权限、业务规则、数据、校验和副作用仍应由后端负责。
模型调用不总是请求生命周期。 一次用户操作可能跨越多次模型尝试、后端步骤和回调。状态与关联信息让整个流程可以理解。
交付也属于设计的一部分。 如果工作是异步执行或逐步流式返回，把结果送到正确的客户端就是架构的一环，而不是事后补充。
基础设施边界解决的是不同问题。 Gateway、框架、应用后端和客户端传输层会有交集，但各自的主要职责不同。
连接环节可能成为最昂贵的维护部分。 团队通常有充分理由保留自己的后端和 AI 逻辑，真正棘手的是让两者能在一个可靠请求中协同工作的周边基础设施。
最初的架构仍然有用：
当请求需要数据、操作或异步交付时，系统会变成：
生产级 AI 的难点往往不是让模型给出答案，而是让答案能够安全、可靠地参与应用的其余部分。ModelRiver 是这个基础设施边界上的一种选择：它将 Gateway 能力与配置好的后端 callback 和客户端交付结合起来。具体的异步流程可参阅后端 Pipeline 指南。