流式推理中的海勒姆定律：节奏、停顿和中间 Token 是未成文的契约

一个团队从前沿模型升级到了其更快的后继版本。评估套件（eval suite）全绿。最终答案一致。工具调用的 Schema 完全相同。结构化输出通过了与以往一样的 JSON Schema 验证。他们发布了。不到一天，支持票据就堆积如山：“助手感觉太匆忙了”，“它不再真正思考了”，“感觉不对劲”。产品经理调取了遥测数据，发现任务完成率没有变化。工程团队反复检查了评估和 Schema，没发现任何问题。投诉是真实的，但团队定义的契约——就如团队所定义的那样——依然完好无损。

改变的是流的纹理（texture）。旧模型在调用工具前会停顿 800 毫秒，发出一句“让我查一下……”的前导词，并以每秒约 35 个 Token 的速度输出，在子句边界处有自然的节奏。新模型以每秒 90 个 Token 的速度输出，从不停顿，且完全跳过了前导词。这些都没有出现在任何文档记录的契约中。但所有这些都是不可或缺的“承重”部分。

这就是海勒姆定律（Hyrum's Law），而流式传输（streaming）让它的表面积变得巨大。系统的任何可观察行为都会被某人所依赖——而流式 AI 界面暴露的可观察行为远比团队意识到的要多。

流式传输暴露的隐藏表面

海勒姆定律最初是针对传统 API 提出的，在这些 API 中，可观察的行为包括响应字段的排序、错误消息字符串、精确的时间戳格式，以及没人记录的频率限制行为。维护广泛使用库的团队在惨痛教训中明白了一个道理：对非文档行为的一次“无害”修改，就会破坏某些人的生产环境。

流式 AI 系统使这种表面积呈倍数级增长。协议层面的契约——SSE 事件类型、最终结构化输出的 JSON Schema、工具调用签名——是团队会进行版本管理和审查的部分。但逐个 Token 地流式传输响应，会暴露出一层又一层团队从未记录过的行为：

• Token 发射速率。 用户看到的是一种打字机效果，字符出现的速度塑造了他们对“思考”的感知。研究表明，即使总延迟完全相同，用户感知流式界面的速度也比缓冲响应快约 40%，而节奏正是原因之一。
• 停顿模式。 模型在调用工具前停顿 600 毫秒会被解读为在审慎思考。停顿 50 毫秒则会被解读为即时查询。这些停顿的存在、不存在以及长度，成为了用户赖以校准的“感官意义”。
• 结构化输出中字段实例化的顺序。 当模型流式传输一个 JSON 对象时，字段落下的顺序对于任何在完整负载到达前就开始渲染的消费者来说都很重要。如果一个先显示 summary（摘要）然后再显示 details（详情）的前端，在模型改为先发射 details 时，看起来会完全不同。
• 可见的“思考”文本。 暴露思维链（chain-of-thought）推理的模型会发出一个中间流——有时是有标签的，有时是隐喻的——用户会将其解读为模型的处理过程。措辞、推敲以及“等等，让我重新考虑一下”的转折，都是可观察的。
• 中期状态消息。 “正在搜索相关文档……”“正在汇总结果……”这些是面向用户的字符串，下游 UI 会根据这些字符串进行匹配、制作动画，或者仅仅是信任它们代表了原来的意思。

如果有人问起，团队会把其中任何一个都称为“实现细节”。但对于已经产生依赖的下游消费者来说，这些都不是细节。

依赖是如何形成的

发布流式 AI 功能的团队很少会主动去依赖这些行为。这种依赖是通过两种方式悄悄形成的。

第一种是在用户侧，它是通过感知而非代码形成的。每天使用该产品的用户会对“助手正在仔细思考”的样子形成一种直觉——而这种直觉锚定在特定的可观察信号上。当流式传输的感觉发生变化时，直觉就失效了。用户并不知道他们的直觉锚定在什么上面；他们只知道感觉不对。他们将其报告为“质量退化”，因为这是他们拥有的唯一词汇。

第二种是在消费端，它是通过代码形成的。一个前端动画团队将“加载点”的过渡时间设定在用户提交与第一个非空白 Token 之间的间隙。一个开发者工具团队针对中间的“思考”流编写正则表达式，以提取中间工具调用的参数用于调试面板。一个日志流水线解析状态消息，为追踪（trace）中的跨度（span）标记标签。一个 A/B 测试分析工具测量 TTFT（首个 Token 时间）作为“模型交互度”的指标，而某人墙上的仪表盘将其显示为关键绩效指标（KPI）。

这些消费者都没有请求 AI 团队的许可。他们中的大多数人从未告诉过 AI 团队他们的存在。他们只是观察到了一种行为并依赖它——正如海勒姆定律所预测的那样。

将模型切换视为破坏性变更

当 AI 团队更换底层模型时，他们认为自己正在维护的契约（Contract）是结构化输出模式（Schema）和工具调用签名（Tool-call Signatures）。然而，实际存在的契约包含了上述所有内容。如果一次模型切换保留了记录在档的表面特性，却改变了未记录的特性，根据海勒姆定律（Hyrum's Law），这就是一次破坏性变更（Breaking Change）——尽管在任何变更管理框架中，团队都会称其为非破坏性变更。

有趣的是，这种破坏很少会引起巨大的警报。评估测试集（Eval Suite）能够通过，是因为它评分的是最终输出，而不是节奏。集成测试能够通过，是因为它解析的是最终的结构化输出，而不是实时到达的流。错误率仪表盘保持平稳，因为没有发生崩溃。浮出水面的是用户缓慢流出的定性投诉，以及一两个莫名其妙损坏的下游功能，而这些功能的负责人无法立即判断为什么他们的东西停止了工作。

加载中…