流式响应
服务端在生成内容的同时逐步向客户端推送数据的传输方式，常见实现包括SSE和HTTP chunked transfer encoding，核心约束是响应头发送后无法再修改状态码
时间轴 (近 90 天)
升级 AI SDK 相关依赖后，建议重点测试流式响应和工具调用场景，因为这类功能横跨核心包与框架适配层。
流式响应中不应持久化分块边界，因为分块只是传输层产物，提供商可能改变切分方式；应只存储组装后的文本和结束原因，回放时按固定chunk_size重新切分。
处理流式响应时把引用事件塞进普通文本缓冲区会导致前端只能靠脆弱的正则表达式反向解析来源。
若客户端提前断开、请求被中止或网络中断，携带用量信息的终止事件可能永远不会到达，此时无法获得精确的账单级 Token 数字。
流式响应中若缺少流内错误编码约定，供应商超时或限流会表现为流被提前关闭，客户端收到半截回答却仍收到200状态码，从而绕过基于状态码的告警机制。
流式响应通过逐步推送 token 降低首字延迟，但连接生命周期更长，更易受网络抖动或提供商临时错误影响，一旦连接断开已生成的部分内容可能无法继续拼接。
对于流式响应，首 token 时间（TTFT）比总时长更能区分不同排障方向，例如 350 毫秒返回首 token 与 8 秒后才返回首 token 的体验和问题根源完全不同。
流式响应是大模型交互的典型模式，模型逐token返回结果而非等待完整生成；AI网关必须支持SSE或WebSocket等协议来透传流式数据。
流式响应可以被缓存：未命中时流式推送同时收集分片，流结束后拼接存储；命中时可切片重放流式效果
流式状态管理涉及异步时序，是最容易因底层依赖变动而受影响的部分
还有 1 条时间轴事件
全部知识事实 (11)
升级 AI SDK 相关依赖后，建议重点测试流式响应和工具调用场景，因为这类功能横跨核心包与框架适配层。
50%待验证流式响应中不应持久化分块边界，因为分块只是传输层产物，提供商可能改变切分方式；应只存储组装后的文本和结束原因，回放时按固定chunk_size重新切分。
50%待验证处理流式响应时把引用事件塞进普通文本缓冲区会导致前端只能靠脆弱的正则表达式反向解析来源。
50%待验证若客户端提前断开、请求被中止或网络中断，携带用量信息的终止事件可能永远不会到达，此时无法获得精确的账单级 Token 数字。
50%待验证流式响应中若缺少流内错误编码约定，供应商超时或限流会表现为流被提前关闭，客户端收到半截回答却仍收到200状态码，从而绕过基于状态码的告警机制。
50%待验证流式响应通过逐步推送 token 降低首字延迟，但连接生命周期更长，更易受网络抖动或提供商临时错误影响，一旦连接断开已生成的部分内容可能无法继续拼接。
50%待验证对于流式响应，首 token 时间（TTFT）比总时长更能区分不同排障方向，例如 350 毫秒返回首 token 与 8 秒后才返回首 token 的体验和问题根源完全不同。
50%待验证流式响应是大模型交互的典型模式，模型逐token返回结果而非等待完整生成；AI网关必须支持SSE或WebSocket等协议来透传流式数据。
50%待验证流式响应可以被缓存：未命中时流式推送同时收集分片，流结束后拼接存储；命中时可切片重放流式效果
50%待验证流式状态管理涉及异步时序，是最容易因底层依赖变动而受影响的部分
50%待验证流式传输允许服务端在生成过程中将 token 逐步推送至客户端，实现打字机般逐字出现效果，从而降低感知等待时间
50%