作者：林岚

据建站 Agent 公司 Ploy 披露，它已把生产环境默认模型从 Claude Opus 4.8 切换到 OpenAI GPT-5.6 Sol。公司称，在自己的网页构建任务中，新模型完成时间不到原来一半，成本低 27%，最终作品评分达到或超过旧模型。

一句话结论： 这不是 GPT-5.6 在所有场景都胜过 Claude Opus 的证明，而是一份很有价值的迁移报告：换模型最危险的部分，往往是评测器、工具参数和缓存策略早已偷偷适配了旧模型。

Ploy 的 Agent 不是只生成一段 HTML。它要读代码、规划页面、写组件、生成图片、截图检查，再决定什么时候结束。团队过去四个月一直使用 Opus 4.7 和 4.8，因为其他模型达不到视觉质量门槛。GPT-5.6 Sol 首次让他们愿意真正迁移。

第一轮评测却出了很多“假失败”。Opus 倾向顺序调用工具，Ploy 原有的调用预算就是按这种节奏设计的；GPT-5.6 喜欢并行读文件，很快撞上上限。评测执行器甚至不支持批量读取。团队检查轨迹后发现，最初约三分之一失败来自测试框架的旧假设，而不是模型不会做。

工具 schema 也会暴露供应商差异。某些 OpenAI 工具调用会把可选参数填成 null，旧代码却把 null 当成真实值传下去。缓存差异更贵：Ploy 最初为每段对话生成独立缓存 key，导致新会话首轮命中率几乎为零；改成按客户工作区分组后，首轮命中率升到约 83.7%，未缓存输入 Token 下降 28%，成本才真正低于 Opus。

这里有一个很实用的问题：既然用了所谓“通用”AI SDK，为什么还这么难换？SDK 能统一调用形式，却无法抹平模型行为。不同供应商怎样补工具参数、怎样保存推理状态、怎样识别缓存前缀，仍会穿透抽象层。Ploy 还遇到服务器端推理引用失效，最终通过关闭服务端存储，让每轮回放携带自包含的加密推理内容。

林岚认为，27% 是最适合传播的数字，却不是这篇文章最值得带走的部分。真正的经验是：评测集也会过拟合 incumbent。一个新模型如果不像旧模型那样调用工具，可能被系统误判为差；同样，迁移后的成本高，也可能只是缓存 key 设计错误。生产 Agent 的竞争已经不只是模型智商，而是模型与整套运行时能否配合。

关键事实

• Ploy 的结论仅针对其营销网站构建 Agent。
• 迁移目标是 GPT-5.6 Sol，原默认模型为 Claude Opus 4.8。
• 初始失败约三分之一被归因于评测框架对旧模型的假设。
• 调整缓存后，首轮命中率约 83.7%，未缓存输入下降 28%。

OC 判断

企业不应把“模型对比”做成一次静态榜单。公平迁移需要检查工具轨迹、缓存、并发和终止条件，否则测到的很可能是旧系统对新模型的排异反应。

为什么重要

• 对开发者：通用 SDK 统一了接口，没有统一模型行为，迁移测试必须覆盖边界值。
• 对企业：供应商切换能力是一种架构资产，可避免被单一模型锁死。
• 对用户：某产品换模型后变快或变差，原因可能在运行时，不只在模型本身。

参考来源

• Ploy：Migrating a production AI agent to GPT-5.6
• OpenAI：GPT-5.6 发布说明
• GPT-5.6 Sol API 模型页