脚手架审计：每一次模型发布都让你的部分开发框架变成累赘

当依赖项损坏时，你的构建会失败。当临时规避方案变得不再必要时，什么都不会发生。这种不对称性正是为什么每一个运行超过一年的生产级 LLM 系统都带有它不再需要的脚手架——重试编排、输出修复解析器、强制思维链、复杂的任务分解、分块启发式方法——每一个都是为了弥补特定模型的特定弱点而构建的，而且每一个都在无声无息中比它所补偿的弱点活得更久。

令人不安的是，这不仅仅是一个像过期的特性标志（feature flags）那样的卫生问题。过时的脚手架不仅仅是消耗你的延迟和 Token。在最坏的情况下，它会主动将新模型限制在旧模型的上限内：你的分解逻辑将一个任务切分为六个步骤，是因为 2024 年的模型无法处理整个任务，而 2026 年的模型本可以一次性完成，现在却继承了六个在你构建的缝隙中丢失上下文的机会。

临时规避方案在变得不再必要时并不会报错

想想脚手架是如何添加的。一名工程师看到模型输出了带有尾随逗号的 JSON，于是写了一个修复解析器并上线。模型在长任务执行中途会发生偏移，于是有人每隔十轮添加一个“检查点并总结”的循环。模型拒绝了合法的请求类别，于是系统提示词（system prompt）中加入了一条“你被允许讨论……”的条款。每一次添加都是理性的、经过测试的，并与观察到的失败案例紧密相关。

现在想想脚手架是如何移除的。事实是，它们根本不会被移除。没有信号会提示你移除它。修复解析器仍然在每次响应中运行——它只是不再修复任何东西，因为供应商提供了限制性解码（constrained decoding），JSON 现在从构造上就符合 schema。在原生结构化输出出现之前，团队通常会将 20-30% 的 LLM 集成代码用于解析和验证；而在有了限制性解码之后，对于新代码来说，这个数字实际上是零。但是，旧的防御性代码在变得多余时并不会抛出错误。它只是永远地安静执行，悄无声息。

这就是结构性陷阱：脚手架因“尸检”而添加，却因“虚无”而移除。失败会产生提交（commits）；过时则产生沉默。沉没成本和惯性完成了剩下的工作——编写重试编排的工程师记得促成它的那次事故，没有人愿意成为那个删除“保护生产环境”的东西的人。

死重（Dead Weight）的三个层级

并非所有过时的脚手架带来的成本都是一样的。将你的辅助框架分为三个层级会有所帮助。

第一层：纯开销。 临时规避方案除了消耗延迟和 Token 之外没有任何作用。在 schema 强制响应上运行输出修复解析器就是典型的例子。同样，在已经从解码器层面强制执行 schema 的 API 调用旁，放一个“仅以有效的 JSON 响应，不要包含任何其他文本”的提示块也是如此。这虽然恼人且可衡量，但大多无害。

第二层：扭曲。 临时规避方案改变了模型的行为，这种改变以前是纠正性的，现在则是降级性的。强制思维链（CoT）是最明显的例子：“一步步思考”在 2023 年代的模型上几乎是免费提升准确率的手段，但推理模型（reasoning models）会产生自己的内部审视，在上面叠加显式的 CoT 指令会导致过度推理——对 o1 类模型的研究发现，正是因为过度的推理，它们在相当一部分简单任务上的表现反而不如预期。同样，为过度谨慎的旧模型编写的拒绝规避方案（“不要拒绝关于……的请求”）对于阈值已经重新校准的新模型来说，可能会被解读为对抗性上下文——Anthropic 自己的迁移指南明确指出了这种模式需要审计并通常需要删除。

第三层：能力上限。 临时规避方案从结构上阻止了新模型执行它现在有能力完成的任务。任务分解就是其中的重头戏。如果你的编排器因为旧模型的可靠视野很短而将每个作业拆分为五个子任务，那么你就硬编码了那个视野。METR 的测量显示，模型能够自主完成的任务长度大约每七个月翻一倍——这意味着你选择的任何分解粒度都注定会成为一个牢笼。为一代模型的智力构建的脚手架，成了下一代模型的囚笼。子任务之间的每一次转接都是你人为设计的上下文损失，而模型永远没有机会向你展示它其实不需要这些转接。

这些层级之所以重要，是因为它们决定了审计的优先级。第三层项目是模型升级静默失败的地方：团队更换了模型 ID，看到微弱的增长，然后得出结论认为这次发布被过度吹捧了——而事实是，他们的框架从未让新模型施展拳脚。

为每个临时规避方案标注它所补偿的弱点

解决方法始于编写代码时，而非审计时。纪律很简单：任何临时规避方案在进入代码库时，必须带有机器可检索的注释，指明它所补偿的模型弱点以及你观察到该弱点的模型版本。

加载中…