评估框架（Eval Harness）而非提示词，才是你真正的供应商锁定

商业计划书中每一个“如果需要，我们会直接更换供应商”的计划，其预算表中都有提示词改写的支出。但没有一个计划包含评估套件的预算。这就是问题所在。提示词是显性耦合——那是你编写的部分，你可以通过 grep 搜索到的部分，也是一个初级工程师在一个下午就能改写的部分。而评估框架（eval harness）则是隐性耦合，当你真正尝试迁移时，它会吞掉你四分之一的路线图进度。

这种模式在议价能力变得至关重要时就会显现。你的合同到期了。竞争对手发布了一个在你的领域基准测试表现更好的模型。输出 token 的定价发生了变化。你准备让候选模型跑一遍评估套件来做决定，结果不到一天你就发现，你无法信任该框架产生的任何评分，因为框架本身是针对现有供应商编写的。你不是在比较模型，而是在拿一个模型与一个针对另一个模型校准过的测量工具进行比较。

这并非理论上的风险。来自 OpenAI、Anthropic 和 Google 的分词器对于同一段文本会产生 10-20% 的计数差异。一个分词器下 140 个 token 的提示词，在另一个分词器下可能会变成 180 个。工具调用架构（Tool-call schemas）也各不相同——OpenAI 使用 type: "function" 的 tools 数组，不同于 Anthropic 的 input_schema 内容块，而且 OpenAI 的兼容层明确表示不对 Claude 强制执行严格模式（strict mode）。拒绝语（Refusal phrasing）随模型系列而异。推理痕迹（Reasoning trace）格式不同。定价逻辑不同。这些差异中的每一个都作为软假设存在于你的评估套件中，而每一个软假设都是比较失效的隐患。

隐藏在评估框架中的软耦合

梳理一下典型的生产环境评估套件，数一数那些因特定供应商而设的调节参数。你会发现比预想的要多。

分词器感知的长度预算。 你的测试固定数据（fixtures）将输入限制在 8,000 个 token 以“为回复留出空间”。这个上限是针对特定的分词器计算的。将相同的固定数据放入另一个分词器，其中一大部分现在会超出新模型的上下文窗口（而旧模型不会），或者在新模型中绰绰有余但在旧模型中被人工截断。无论哪种情况，测试都不再能衡量它声称要衡量的内容。

固化在测试数据中的工具调用架构假设。 你的标准答案（golden traces）期望工具调用出现在消息的 tool_calls 数组中。Anthropic 则将其作为消息内容数组中的 tool_use 内容块返回。兼容层粉饰了表面，但你的测试数据对解析后的结构进行断言，你的评测器（judges）从特定路径读取工具参数，且你的回放工具期望一个供应商提供而另一个不提供的顺序保证。

拒绝语正则表达式。 在你的安全性评估中，某处有一个正则表达式匹配“我无法提供帮助”或“我不能”或现有模型特定的回避特征。下一个模型的拒绝语表述会有所不同。你的安全性通过率下降了 6 个百分点，你花了两个星期才搞清楚是模型变得不安全了，还是你的检测器失灵了。

针对特定推理轨迹格式编写的评测器提示词。 如果你的“LLM 作为评测器”（LLM-as-judge）期望在判定之前看到思维链，而候选模型以不同的形式输出其推理过程——比如单个标签块、交替草稿纸或带有 reasoning 字段的结构化 JSON——那么对于同样的回答质量，你的评测器会开始给候选模型打更低的分。你并没有衡量候选模型，你衡量的是候选模型在多大程度上迎合了评测器提示词的预期。

硬编码为单一供应商计费单位的定价逻辑。 你的成本回归测试断言“单次调用成本保持在 0.012 美元以下”。这个数字是基于某个供应商的每 token 费率下的输入/输出比例。候选模型有不同的费率，甚至可能是不同的单位（字符 vs token，批处理 vs 单次），并且可能有不同的缓存折扣结构。你的成本门控（cost gate）会因为与候选模型实际经济效益无关的原因而触发或失效。

孤立来看，这些都是只需五行代码就能修复的补丁。破坏性在于它们有几十个，散落在固定数据、评测器、正则表达式、仪表板以及财务合伙人用来批准迁移的电子表格中。在编写时，没有一个是为了可移植性而写的，因为在编写那一刻，可移植性没有具体的负责人，也没有紧迫感。

为什么你不能信任第一次比较

致命之处在于，直到你真正尝试，你才会意识到这一切。评估框架会很顺畅地端到端运行候选模型并产出数据。这些数据看起来很可信。但它们在某些你无法从外部预测的方向上是错误的。某些指标会因为候选模型的分词器处理数据的方式而虚高。另一些指标则会因为你的评测器在按照适应现有模型啰嗦程度的曲线评分而缩水。

诚实的反应应该是：“在重新验证评估框架之前，我无法信任这个对比。”而这种调查本身就是一个长达数月的项目——你必须重建具有供应商中立长度预算的固定数据，标准化工具调用表示，针对两个模型的样本重新校准拒绝检测器，重写评测器提示词以评估可观察到的行为而非格式，并在两种定价方案下重新推导成本计算逻辑。在这些工作完成之前，评估套件产生的每一个分数都是被污染的。

就在这一刻，迁移计划推迟了一个季度。那些以为自己只是在做提示词改写的团队发现，他们正在进行“框架考古”。那位说“因为我们可以切换，所以我们有议价筹码”的高管，在纸面上拥有筹码，但在日历时间上却没有——而日历时间是重新谈判中唯一真正被尊重的筹码。

可移植性纪律

这种解决方案并不光鲜。它是在没有人强迫你的时候，尽早做出的一系列设计选择，而当你第一次真正想要货比三家时，这些选择将为你带来回报。

与供应商无关的评估原语。 你的评估框架应该消费一个归一化的响应对象——包含文本、工具调用、结束原因、Token 计数和延迟——由一个了解供应商特性的适配层生成。评估逻辑本身永远不应该看到供应商特定的字段。如果你的评测（Judge）代码根据 response.tool_calls 是否存在或 response.content[].type === "tool_use" 进行分支判断，那你并没有进行抽象；你发生了抽象泄露。

抽象的分词器（Tokenizer）接口。 测试固件（Fixtures）中的长度预算应该以评估套件可以针对每个供应商解析的单位来表达——例如“占候选模型上下文窗口的 70%”，而不是“8,000 个 Token”。需要精确 Token 控制的测试固件应该声明其需求，并被明确标记为“供应商绑定”，这样它们就不会在跨供应商比较中被误用。

标准化的工具调用表示。 选择一种规范的形态——名称、作为对象的参数、可选 ID、可选排序位置——并在评估套件看到它之前，将每个供应商的响应都转换为这种形态。在调用供应商时再转换回去。测试固件、评测器（Judges）和回放工具都运行在这种规范形态之上。

针对可观察行为而非格式进行打分的评测器。 如果一个评测器判断“响应是否正确识别了用户意图并收集了正确的槽位值”，那么它是可移植的。但如果一个评测器判断“响应是否包含一个 <reasoning> 块，随后是 <answer> 标签中的结论”，那么它就不具备可移植性——它是在对供应商的输出习惯评分，而不是在评估模型的能力。将所有针对格式的断言从评测器中剥离，放入确定性的后处理器中。

成本计算应表达为供应商费率表的函数，而非常量。 你的成本门槛（Cost gates）应该计算“在日期 D，按照供应商 P 的费率，本次运行花费了 X”。门槛所比较的阈值也应该以同样的方式进行货币归一化。这样，对比运行产生的结果将是“在同等质量下，候选模型便宜了 18%”，而不是“候选模型未通过针对现任供应商费率设置的成本门槛”。

其中的每一项单独来看都不难。但这些都是实打实的工程工作，在重新谈判开始之前，没有任何路线图会为此提供奖励。

组织失效模式

还有第二种失效模式，它是结构性的而非技术性的，这也是导致大多数可移植性努力夭折的真正原因。

负责评估的团队并不是负责模型选择的团队。评估通常归属于平台组或应用科学组，他们的路线图被“提高覆盖率”和“减少误报”所占据。模型选择则归属于产品或战略组，他们的路线图主要受限于当前模型的特性交付。两个小组在被问及可移植性时都会承认其重要性，但在下个季度有具体任务到期时，两者都会将其优先级降低。

可移植性工作——抽象、适配层、评测器重写——总是“别人的季度任务”。等到迁移迫在眉睫时，需要评估套件具备可移植性的团队没有时间去实现它，而有精力实现它的团队却没有动力去推动。

解决办法是给可移植性指定一个拥有交付物的负责人。不是“在编写评估时考虑可移植性”，而是一个具体的交付物：到日期 D，评估套件可以在不更改代码的情况下，针对同一组测试固件，为两个指定的供应商生成可比的分数。这样就有人负责了。否则，“如果需要，我们可以随时切换”始终只是一张幻灯片，而不是一种能力。

有回报的税收

可移植性纪律在前期需要投入真实的工程时间，且不会为用户产生可见的产物。你无法演示它，也无法指出它交付了哪个功能。它产生的唯一产物是让你在进入重新谈判时，手中握有一个可靠的替代方案——而这个选项只有在你行使它的那一天才有价值。

这正是那种在任何路线图压力巨大的季度（即每个季度）都会被削减的投资。保持其生命力的方法是正确地界定它。它不是“为评估套件做未来规划”，而是“在你 AI 成本结构中最大的账目项上保留选择权”。把它当成一种对冲，而不是一种清理工作。对冲有年度预算，而清理工作则会被推迟。

在 2025–2026 年的价格重新谈判中幸存下来并保持议价能力的团队，并不是那些拥有最干净 Prompt 的团队。而是那些在候选模型发布后的一周内，就能通过评估套件产生可靠对比结果的团队。Prompt 总是要重写的，而评估套件才是那个具有非对称回报的投入，然而几乎没有人会在需要它之前为其提供资金。

如果你今天的迁移计划仍将预算花在 Prompt 重写上，并假设评估套件“只要在任何模型上运行即可”，那么你正在亲手葬送你声称拥有的议价筹码。锁定你的并不是 Prompt。从来都不是。