迁移生产AI代理至GPT-5.6：速度快2.2倍，成本降27%

背景

Ploy 是一家构建 AI 代理（agent）的公司，其代理负责创建和编辑真实的市场营销网站——从规划页面、读取代码库、编写组件、生成图像，到截图自己的工作并决定何时完成。这一任务对模型质量提出了极高的要求。过去几个月里，Ploy 的默认模型一直是 Claude Opus（先是 Opus 4.7，后升级到 Opus 4.8），因为没有任何模型能够在质量上挑战它。直到 OpenAI 在当天早上发布了 GPT-5.6 Sol（该模型系列的旗舰层级），Ploy 经过与 Claude Opus 的正面较量后，决定将 GPT-5.6 Sol 设为所有 Ploy 工作区的默认模型。这一切换比表面上看起来要复杂得多——从 Claude Opus 4.8 迁移到 GPT-5.6 Sol 需要发现并解决一系列隐藏在“模型”背后的提供商特定行为，这些行为已经融入到 Ploy 整个技术栈中。

核心内容

迁移前的评估：修复测试框架

Ploy 的评估套件使用真实代理在真实固定工作区上运行，包括数百个案例（从“从头构建首页”到“该克隆请求是否安全”）。构建案例由视觉评判器对照参考设计进行二进制检查（10 个是/否问题），再加上内容检查、工具轨迹检查和文件断言。每个失败案例都会根据完整轨迹（实际工具调用和模型文本，而不仅仅是分数）进行归类。

当 Ploy 在两个模型家族上运行该套件时，发现了意外情况：测试框架本身是针对现有模型（Claude Opus）调优的，但这一事实在迁移前并未被意识到。例如，工具调用预算针对的是 Opus 的顺序调用风格，而 GPT-5.6 会并行分支出调用，导致预算被轻易突破。评估执行器不支持批量文件读取（Opus 很少使用，但 GPT-5.6 频繁使用）。在第一次跨模型运行的原始失败中，大约三分之一可追溯到测试框架的假设，而非模型行为。这些失败在模型间并非均匀分布。如果不对轨迹进行归类就信任通过率，实际上是在用旧模型的模仿能力来评估新模型。

此外，数据集中的 minScore 阈值被遗漏，默认继承为 1.0，导致 GPT-5.6 因得分 0.98 而被判定“失败”，而 Opus 则在通过所有单项检查的情况下因某个阈值问题被判定失败。这是两个合理的评估设计方向，但一个不可见的阈值扭曲了结果。

初步印象：立即展现前景

修复测试框架后，Ploy 在重新设计套件中看到了明显的效果：GPT-5.6 Sol 完成一个页面所需的时间是 Opus 的 2.2 倍快（即更短时间），成本降低 27%，输出 token 数量约为 Opus 的一半。GPT-5.6 编写的代码更精简。在一个匹配案例中，Opus 生成了一份 17,957 字符的 globals.css 文件，包含 174 个 CSS 变量（涵盖完整色调，大部分未使用），而 GPT-5.6 只写了 2,508 字符和 45 个变量，但渲染出的页面效果相当甚至更好。

在设计质量方面，GPT-5.6 擅长干净、现代、紧密网格的布局，但容易趋同于这种风格，除非给予明确的引导。在 Ploy 原先为 Opus 设计的测试框架下，GPT-5.6 倾向于忽略已有的设计系统，产出整洁但缺乏品牌个性的输出。Ploy 的设计和工程团队通过调整提示和参数，最终能够引导模型实现世界级的品牌一致性。

第一步：检查工具调用

在迁移中遇到的一个隐蔽问题：Ploy 代理的 code 工具有 25 个顶层参数，其中只有一个（action）是必需的，其余都是可选的。Claude Opus 只发送它实际使用的两三个参数，忽略其余参数。但 GPT-5.6 每次都会发送全部 25 个参数，并为不需要的参数编造看似合理的值（例如 offset: 0、timeout: 120000、siteId: "00000000-0000-0000-0000-000000000000"）。这导致 52% 到 64% 的文件读取请求因编造的 offset 值而返回空结果，且工具返回 success: true，模型无法感知错误，只能进行更多调用尝试。

提示无法解决这个问题：即使工具描述中写明“省略未使用的参数”，GPT-5.6 仍然发送全部 25 个参数。OpenAI 的 strict 模式行为相同，且采用 strict 模式还会强制从所有 schema 中移除 pattern、format 和数组边界校验。这是模型生成函数调用的固有行为，无法通过指令消除，只能设计绕过方案。

Ploy 的解决方案是在提供商边界进行 schema 转换：针对 OpenAI 家族模型，将每个可选属性改写为必需但可为 null（使用 anyOf: [T, null]），为模型提供显式表达“未使用”的方式。然后在每个工具调用经过的接口处，将 null 值剥离掉再交给验证层，工具实现完全不变。经过这一转换，空文件读取比例从 52% 降至 0%，代理完成相同工作所需的工具调用次数减少了约 30%。

第二步：重建提示缓存

提示缓存的迁移是工程上最具教育意义的差异。Claude 和 OpenAI 都提供了“提示缓存”（prompt caching）功能，但底层设计完全不同。在正确配置之前，GPT-5.6 的成本看起来比 Opus 高出约 50%，这并非模型定价问题，而是缓存配置问题。

Ploy 代理的提示以约 29K token 的静态前缀开头（工具 schema 和核心系统提示），每次对话都相同。在 Claude 上，可以使用 cache_control 标记缓存断点，该前缀在整个组织内共享一个缓存条目（任何对话、任何工作区均共享），无需考虑吞吐量预算，缓存命中率达 92%–96%。而 GPT-5.6 改变了 OpenAI 的缓存模式：之前的 GPT 模型支持隐式部分前缀匹配，免费提供了不错的命中率；GPT-5.6 取消了部分前缀匹配，隐式缓存现在仅基于最新消息创建完整提示条目。这意味着每个新对话都会错过缓存，导致每次都重新计算静态前缀，成本大幅上升。

解决方案是显式使用 OpenAI 的动态前缀缓存 API：在应用层维护一个“会话前缀”缓存，让所有对话共享同一段静态前缀的缓存条目。具体细节未在原文中展开，但指出“如果你要迁移一件事，那就是这个”。

关键要点

• 迁移前必须修复评估框架：评估套件往往隐式针对现有模型调优，跨模型运行时会导致大量假阴性。需要先对失败轨迹进行归类，区分框架假设错误和模型行为错误，否则评估结果不可信。
• 测试数据集存在隐蔽的阈值错误：缺失的 minScore 阈值默认值为 1.0，导致 GPT-5.6 实际得分 0.98 的页面被判定失败。需要确保评估配置对所有模型公平。
• GPT-5.6 Sol 在速度、成本和输出质量上全面超越 Claude Opus 4.8：完成页面速度快 2.2 倍，成本低 27%，输出 token 少约一半，且代码更简洁。
• GPT-5.6 会编造工具调用参数：即使参数为可选，它也会发送全部参数并填入看似合理的虚构值，导致文件读取错误。提示无法修复此行为，需要采用 schema 转换（将可选改为必需+nullable）并在接口处过滤。
• 提示缓存设计差异巨大：Claude 支持跨对话共享的静态前缀缓存，命中率高且无需额外配置；GPT-5.6 取消了隐式前缀缓存，需要主动使用显式缓存 API 才能获得类似效果。不处理这一差异会让成本评估失真。
• GPT-5.6 的设计风格偏向整洁现代但缺乏多样性：在未充分引导时容易忽略品牌设计系统。需要结合设计和工程团队的经验来调整模型行为。
• 迁移工作涉及多个层面的适配：除了工具调用 schema 和缓存，还包括模型推理回放（模型