你发出的流式中止信号，供应商照样收了费：账单中隐藏的 14% 差额
你的停止按钮触发了 AbortController.abort()，但供应商会持续生成直到下一个批处理边界，并对差额部分计费。这种差额是一个可衡量的工程问题，且涉及财务责任。
那些将模型未完成的残缺回答存入数据库的流式 UI
当流在生成中途报错时，乐观写入的内容可能会变成正式记录。本文探讨了为什么聊天 UI 会将残缺回答误认为完整答案，以及修复该问题的“定稿契约”。
那个教会用户永远不要打断智能体的中断 UI
流式智能体的停止按钮可能会诱导用户强忍着看完错误的回答，而不是及时纠偏。解决方法是将“中断”视为对话中的一个轮次，而不是 API 调用的断路器。
流式中止后遗留的计费副作用
点击停止只会关闭连接，并不会撤回 Agent 已经发出的邮件。本文将探讨“部分提交”问题以及用于弥补这一鸿沟的“账本模式”。
你的后端基础设施并非为流式响应而设计
流式传输在传输层赢得了用户的信任，但同时也悄然改写了你的负载均衡器、追踪流水线、自动伸缩器和成本模型原本遵循的契约。
自相矛盾的流式响应
流式 LLM 会显现用户视作最终答案的部分推理过程。本文探讨为何单次响应内的自相矛盾会破坏 UX 和评估，并介绍了四种重新引入提交边界的模式。
在用户说"是"之前就已提交的流式响应
流式 UX 继承了一个工具调用并不遵守的可逆性契约。本文剖析为何停止按钮无法撤回已发送的邮件,以及修复这一问题所需的框架变更。
流式 Token 是无法收回的承诺
当背后的工具调用失败时，原本自信的流式回答就会崩溃。流式传输是一种不可逆的契约 —— 有一些模式可以在不牺牲感知延迟的情况下重新获得选择权。
流式回滚问题：你无法收回已发送的 Token
流式输出在任何护栏检查之前就已触达用户。本文将探讨为什么输出审核与 Token 流式传输在结构上存在冲突，以及如何通过缩短暴露窗口来应对这一问题，而非对其视而不见。
用户过早行动的流式 Token
逐个 Token 的流式传输让助手感觉响应迅速，但它也会将模型未完成的思考作为最终答案展示出来。本文将探讨导致这一问题的竞态条件以及解决该问题的设计模式。
先返回 200 然后失败的流式响应：中途错误如何破坏你的 SLO
流式端点在第一个 token 刷出的瞬间就会确认 200 状态，因此之后发生的每一个失败都会躲过负载均衡器、重试中间件和 SLO 仪表板。本文将介绍如何让响应体承担起 HTTP 头部已无法传达的判定结论。
具有两种延迟的 AI 功能：你衡量的是一种，用户感知的是另一种
流式 AI 功能具有两种分化的延迟 —— 首字时间 (TTFT) 和完成时间 —— 而大多数团队只测量了用户感知最不明显的那一个。本文将介绍如何拆分指标和 SLO。