7 月 9 日，OpenAI 正式发布了 GPT-5.6 系列。同一天，AI 建站工具 Ploy 的工程师 Lorenzo Gentile 发了一篇博客，宣布他们已经在生产环境中把默认模型从 Claude Opus 4.8 切换到了 GPT-5.6 Sol。这不是一个”我们也来试试新模型”的评测贴——Ploy 的 Agent 负责从零构建和编辑真实的营销网站，涉及代码生成、图片生成、页面截图、自我验收等完整链路。哪个模型跑在这个位置上，直接决定了用户体验和 API 成本。
在 Opus 统治默认槽位的四个月里（从 4.7 到 4.8），Ploy 测试过的每一个前沿模型都打不过它。GPT-5.6 是第一个。最终的数据是：平均构建时间从 8 分钟降到 3 分 42 秒（2.2 倍提速），单次构建成本从 $3.06 降到 $2.22（27% 降幅），视觉评分反而从 0.936 提升到了 0.970。
但这些数字不是换一个 API endpoint 就自动冒出来的。Ploy 的迁移过程踩了四个坑——每一个都指向同一个事实：你以为你在切换模型，其实你在切换一个完整的技术栈。
第一步：先修评测框架，再信任何数字
Ploy 的 eval 套件用真实 fixture 工作区跑完整的 Agent 流程，数百个测试用例覆盖”从零建站”到”克隆请求安全性检查”。构建类用例由视觉评判器打分——十道二选一问题，比如「hero 区域是全幅摄影场景」还是「主 CTA 是圆角矩形而非胶囊形」。
换到 GPT-5.6 的第一轮评测结果让团队意外，但意外不在模型表现上——在评测框架本身。
你的评测框架是围绕现任模型生长出来的。 Ploy 的工具调用预算按 Opus 的串行风格设计；GPT-5.6 大量使用并行调用，在正确完成的情况下也会”烧穿”预算上限。批量文件读取是 Opus 极少用的操作，却是 GPT-5.6 的默认行为——而评测执行器根本不支持。第一轮跨模型测试中，约三分之一的原始失败追溯到评测框架的假设，不是模型的行为差异。
还有一个更隐蔽的问题：minScore 阈值。一个测试数据集漏掉了这个字段，系统默默继承了默认值 1.0。于是 GPT-5.6 在一个 hero 区域拿了 0.98 分却被标记为失败，Opus 也有一个用例所有单项检查通过却被判为失败。两种设计方向没有对错，但一个隐形的阈值同时伤害了两边的公平性。
Gentile 的建议很直接——在对比两个模型之前，把失败的 trace 全部翻一遍。否则你评估的只是新模型模仿旧模型的精确度，不是它本身的能力。
数据说话：2.2 倍快、27% 便宜，但不止于此
修完评测框架后，Ploy 在 redesign 套件（Agent 对照参考设计重建品牌首页）上得到了一组扎实的对比数据：
| 指标 | Claude Opus 4.8 (n=11) | GPT-5.6 (n=10) |
|---|---|---|
| 成本 | $3.06 | $2.22 |
| 耗时 | 8 分 00 秒 | 3 分 42 秒 |
| 输入 token | 2.60M | 1.70M |
| 输出 token | 33.0K | 17.1K |
| 视觉评分 | 0.936 | 0.970 |
GPT-5.6 写的代码更精炼。在一组配对样本中，Opus 产出了一个 17957 字符的 globals.css，包含 174 个 CSS 变量（完整的颜色渐变，大部分没用到）；GPT-5.6 写了 2508 个字符和 45 个变量，渲染效果相当，部分场景更好。
不过，GPT-5.6 的设计输出有一个倾向：它的布局通常干净、现代、网格紧密，但也容易趋向统一化的视觉风格，如果不加引导会忽略品牌已有的设计系统。Ploy 的解法是通过设计和工程团队的协作加以校准——这部分细节足够单独写一篇文章。
第二步：工具调用里的幻觉参数
这是迁移过程中最隐蔽的问题，在 Ploy 发现之前已经悄悄影响了数千次生产调用。
Ploy Agent 的代码工具有 25 个顶层参数，一个是必填的 action，其余全是可选的。Claude 的做法是只发送实际使用的两三个参数，其余的省略。GPT-5.6 的做法是每次发送全部 25 个参数，给不需要的字段编造合理值——offset: 0、timeout: 120000、siteId: "00000000-0000-0000-0000-000000000000"。
三天生产日志的数据：
| 模型 | 调用次数 | 携带全部 25 个属性的次数 |
|---|---|---|
| gpt-5.6 | 6635 | 6635（100%） |
| claude-opus-4.8 | 2898 | 4（0.1%） |
| claude-sonnet-5 | 1933 | 0 |
问题不是啰嗦。是编造的值和真实的值长得一模一样。offset: 0 看起来就是个正经参数，Ploy 的文件读取实现照单全收——结果 52% 到 64% 的 GPT-5.6 文件读取返回了空内容。工具返回 success: true 两种情况都有，模型根本不知道自己在读空白文件。它只是用更多调用做出更差的结果。
提示词改不了这个行为。在工具描述中标注”忽略未使用的参数”：无效。在每个属性上加 OPTIONAL, omit if unused：无效。启用 OpenAI 的 strict 模式：行为完全一致（Ploy 实测过），而且启用 strict 还会强制移除所有 schema 中的 pattern、format 和数组边界校验。
Ploy 的解法是在 provider 边界层做一个 schema 转换：针对 OpenAI 系列模型，把每个可选属性重写为 required 但 nullable，用 anyOf: [T, null] 给模型一个明确的”我不需要这个”的表达方式。然后在工具调用的统一入口处把 null 剥离，工具实现层完全无感知。效果立竿见影：空文件读取从 52% 降到 0%，Agent 完成同样工作需要大约 30% 更少的工具调用。
第三步：缓存不是”开”和”关”的区别
这个坑让 GPT-5.6 在迁移初期看起来比 Opus 贵了约 50%。实际不是模型定价的问题——是缓存配置。
Ploy Agent 的 prompt 以大约 29K token 的静态前缀开头（工具 schema 加核心系统提示），每次对话完全一致。在 Claude 上，用 cache_control 标记断点，这个前缀在整个组织的所有对话间共享缓存，命中率 92% 到 96%，事情自然运转，不需要多操心。
GPT-5.6 改了 OpenAI 的缓存模型。旧版 GPT 系列靠隐式的部分前缀匹配实现缓存，命中率不差且免费。GPT-5.6 去掉了部分前缀匹配：隐式缓存只对整条 prompt 做条目化，以最新消息为 key。新的对话共享 29K 静态前缀的结果是——缓存命中 0%。每次新对话都按未缓存的价格重新计费，而且 GPT-5.6 的每一次未缓存 prompt 还要额外支付 1.25 倍的缓存写入附加费，不管你用不用缓存。
OpenAI 的预设路径是显式缓存：prompt_cache_breakpoint 标记加上必填的 prompt_cache_key。关键在 key 的设计——同样的 prompt 内容配上不同的 key，缓存命中也是 0。每个 key 映射到一个缓存节点，大约支撑每分钟 15 次请求，超过后 OpenAI 会把流量扇出到其他节点，那些节点的缓存是冷的。
这意味着缓存策略变成了架构决策。Ploy 测试了三种方案：
- 按对话分 key：新对话首次调用的前缀缓存命中 0%。这是实测过的昂贵错误。
- 全局单一 key：所有请求哈希到同一个缓存节点，生产流量轻松压穿 15 rpm 预算，请求溢出到冷节点。
- 按工作区分 key（最终方案）：同一客户 workspace 内的所有对话共享缓存条目，单 key 流量保持在安全水位。
最终效果：首次调用缓存命中从接近 0% 提升到 83.7%，未缓存输入 token 总量下降 28%，GPT-5.6 的单套件成本降到了 Opus 以下。一个结构性的代价无法规避——跨 workspace 共享静态前缀在 OpenAI 架构上不可行，每个 workspace 在空闲窗口过期后需要支付一次约 $0.18 的冷写入。可控，不致命。
第四步：推理重放需要自包含
这个问题篇幅最短，但能直接中断生产对话。GPT-5.6 的 Responses API 默认把前一轮推理内容以服务端 item 引用的方式重放；Ploy 的 Agent 在对话中途间歇性地收到 Item 'rs_...' not found 错误。修复方式是设 store: false，让 SDK 请求加密的推理内容并以自包含 blob 的方式重放，而不是指针。
一个值得注意的连带效应：当服务端推理状态在循环中时，即便你发送的字节数是纯追加的，上游的等效 prompt 也可能发生变化。这让调试成本翻倍。
不是换个模型，是重构一个适配层
Ploy 这次迁移花了四步：修评测框架、改工具 schema、重建缓存策略、修复推理重放。每一步都指向同一件事：两个 provider 做同一件事的方式根本不同。工具参数填充、缓存 key 的命名空间、推理状态的生命周期——这些被统称为”模型行为”的东西，实际上是紧密耦合到 provider 实现细节的。
这也解释了为什么”模型路由”或”自动 failover”在 Agent 场景下很难真正落地。Ploy 用 Vercel AI SDK（一个通用 LLM SDK）仍然需要在一个个 eval 失败中逐一发现并处理这些 provider 特定的差异。
HN 讨论中有一条评论概括得很准：“任何在生产环境做 serious agentic 工作的团队都会发现，对模型的依赖远不止 API 调用的那一行代码。即使另一个模型跑起来不出错，性能和效率也是天差地别。”
参考链接：
- Ploy 官方博客：把生产 AI Agent 从 Claude Opus 迁移到 GPT-5.6
- Hacker News 讨论帖
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。