流式三招，以及 agent 交互为何仍是同步的
Parent: design-principles
流式处理有三招：有界缓冲、背压、降级优先——先降模型成本再丢词。这是输入不停、输出必须跟上时的标准答案。
- 有界缓冲。 采集与模型之间一个小队列，按音频秒数封顶，永不无限长。
- 背压。 度量实时因子与队列年龄；转录落后说话人超过阈值，就别再啃旧账，跳回 live edge。
- 降级优先。 丢东西之前先让模型变便宜：小模型、贪心解码、短上下文——字错得多点但还在出；丢音频是最后手段，不是第一手段。
但今天的 agent 交互一般不是流式的。它也不是批处理：批处理是攒一堆任务一起算、换吞吐。Agent 交互做的是同步处理——用户说完一轮，整轮发上去，整轮处理完，一次返回。
同步胜出的原因：对话里用户一轮说的话很短，一般不超过一个 paragraph。流式在短轮次上省的那点延迟根本感觉不到，而流式那套机器（socket、队列、实时因子度量、降级 ladder）是给长语音准备的。StandMeet 语音就是例证：说一个问题，3 秒停顿就发，整段解码不到一秒——流式只会给没人需要的 partial 加机器。
边界：三招在长语音场景仍然是对的——听写、会议、直播字幕。判断标准不是“新的就是好的”，而是轮次长度与延迟敏感度：短轮次走同步；长而延迟敏感的流才配得上三招。
Transfer：判断一个 agent 交互要不要上流式，先看用户一轮说多长。轮次保持 paragraph 级，同步就更简单、更便宜、更可预测——一直保持到轮次变长（连续对话、长口述），那时流式才赚回它的复杂度。