把AI换模型这件事，说得像给火箭换个发动机，其实大部分时候你连螺丝刀都找不对。
GPT-5.6今天刚发布，我们连夜把公司核心AI代理从Claude Opus换到了GPT-5.6 Sol上。整整四个月，Claude Opus 4.7和4.8在我们这稳坐铁王座，中间所有新模型来挑战，全被干趴下了。这次GPT-5.6一跑，数据直接炸了：完成时间从八分钟缩到三分四十秒，成本降了27%，视觉评分还更高了。但这个迁移过程惨不忍睹，我们踩了所有能踩的坑。以下是血泪换来的实战记录，你看完最好别重演。
你那个测试工具本身就是个大陷阱
我们有个正经的测试工具包，跑了几百个真实场景，从“从零搭个首页”到“这个克隆请求安全吗”，全部自动化打分。视觉部分有个裁判系统，对着参考设计问十个是非题，比如“主视觉是不是全屏照片”或者“主要按钮是圆角还是胶囊形”，再加内容检查、操作路径检查、文件正确性检查。每个失败案例都要人工翻完整执行记录，看工具到底调了什么、模型说了什么。
拿着这套东西去跑两个模型家族，结果比任何单项数据都让人傻眼。你的测试工具实际上偷偷偏向你现在用的那个模型，而你根本不知道。我们的工具调用预算一直是按Opus那种串行干活风格定的，GPT-5.6擅长并行发工具请求，唰一下就把预算打爆了，关键是它那些用例其实都做对了。我们的测试执行器还不支持批量读文件，Opus几乎不用这个功能，GPT-5.6翻来覆去地用。第一次跨模型跑出来的原始失败里，大概三分之一根本就是测试工具的预设问题，跟模型表现没关系，而且这些假失败在两个模型身上的分布完全不平均。
如果你拿新模型跟老模型比，调出执行记录检查之前别信那个通过率数字。否则你只是在考新模型模仿老模型的能力有多强，不是它本身有多好。另外检查一下打分阈值，我们有个数据集没写清楚minScore参数，系统默默给设了个默认值1.0。
结果GPT-5.6对一个设计打了0.98分被判失败，Opus每项检查都过但综合却算通过。一个看不见的参数能完全扭曲胜负结果。
第一批测试结果好看得有点吓人
修复完测试工具之后，我们跑了一组品牌首页重建设计案例。数据是这样的：Opus完成一个项目平均花八分钟整，GPT-5.6只用三分四十二秒，快了2.2倍。成本Opus三块零六分，GPT-5.6两块两毛二。输入token Opus吃掉两百六十万，GPT-5.6吃掉一百七十万。输出token Opus三万三，GPT-5.6一万七。视觉评分Opus 0.936，GPT-5.6跑到0.970。这组数字直接决定了我们要换。
GPT-5.6写代码极其精简。同一套设计需求，Opus产出的全局样式文件有一万七千九百五十七个字符，里面定义了一百七十四个CSS变量，完整的色阶表从头铺到尾，大部分根本用不上。GPT-5.6只写了两千五百零八个字符和四十五个变量，渲染出来的页面效果持平甚至在某些细节上更好。这就是那种让人立刻决定投入精力去迁移的信号。
但设计风格上有细微差别。GPT-5.6特别擅长干净、现代、网格对齐严丝合缝的版式，但也特别容易往这个方向收拢，如果你不给足够的引导，它就自动滑向那种所有人都在用的安全风格。用以前给Opus调的参数直接套，GPT-5.6会忽略现有设计系统，输出一个干净、克制、但看着眼熟得让人分不清是谁家的页面。
这个问题我们花了另外一堆精力才调好，是另一个故事了。
工具调用这个坑几乎让我们全盘否定它
这个bug在发现之前一直在悄无声息地破坏结果。我们代理的code工具有二十五个顶层参数，只有一个action是必填的，其他都可选。Claude只发它用到的两三个参数，剩下的一概不发。GPT-5.6每次把二十五个全部发出来，没用的那些它自己编个像真的值填进去，比如offset: 0、timeout: 120000、siteId: "00000000-0000-0000-0000-000000000000"。
翻了三天生产日志，GPT-5.6的code(read)调用六千六百多次，百分之百携带全部二十五个属性。Opus接近两千九百次调用里只有四次这么干，Sonnet两千次调用里零次。问题不是啰嗦，是编出来的值看着跟真的一样。offset: 0看起来就是个正经参数，我们文件读逻辑把它当真了，结果GPT-5.6百分之五十二到六十四的文件读取返回空内容。工具返回的success都是true，模型根本不知道自己在读空白文件。它只是做得更差、调用次数更多。
提示词修不了这个问题。在工具描述里加指令说“没用到的参数别发”，没用，依然二十五个全发。在每个参数旁边写“可选，不用就省略”，还是没用。OpenAI自己的strict模式，我们实测行为完全一致，而且一开这个模式就要被迫从每个schema里删掉pattern、format和数组校验，代价太大。这是模型发函数调用的底层行为决定的，靠提示词根本绕不过去，你得在设计上适应它。
最终管用的方案是在provider边界做schema转换。只针对OpenAI系模型，我们把每个可选属性改成必填但允许为null，用anyOf: [T, null]这种写法，给模型一个明确的方式表示“这个参数我没用”。然后在所有工具调用的唯一入口处，把null值剥掉再送进校验，工具实现一行都不用改。完整流程就是模型看到一个允许说真话的schema，工具看到的输入跟以前一模一样。改了之后空文件读取从百分之五十二直接归零，代理做同样工作需要的工具调用数少了大约百分之三十，因为不用再反复读那些返回空内容的文件了。
缓存机制这俩公司说的根本不是一个东西
这是最具教育意义的工程差异。表面上看两个提供商都支持“提示词缓存”，但这俩字底下藏的是完全不同的设计。如果迁移过程中有一样东西需要你最小心地对待，就是这个。动手之前我们的数据里GPT-5.6比Opus贵了大约百分之五十，根本不是模型定价问题，是我们的缓存配错了。
我们代理的提示词开头有一段大概两万九千token的静态前缀，包含工具schema和核心系统提示，每个对话都一样。在Claude那边我们标记缓存断点，那个前缀在整个组织范围内共享，任何对话、任何工作区都命中同一个缓存条目，没有吞吐量限制需要操心。缓存命中率稳定在百分之九十二到九十六，缓存这事根本不用想。
GPT-5.6把OpenAI的缓存模型整个换了。之前版本的GPT做隐式前缀匹配，不需要额外配置就有不错的命中率。GPT-5.6取消了这个机制，隐式缓存现在只针对整段提示词做匹配，并且键是最后一条消息。一个新对话即使共享我们那两万九千token的静态前缀，缓存命中率是百分之零。每个新对话都按未缓存的价格重新计费整个前缀，而且GPT-5.6每条未缓存的提示词还要额外付一点二五倍的缓存写入附加费，不管你是否真的用缓存。
官方机制现在是显式的：prompt_cache_breakpoint标记加上必填的prompt_cache_key。这个key是设计分歧的核心，因为它是缓存标识的一部分。完全相同的提示词，换了key就是零命中。每个key对应一个缓存节点，这个节点大约只支撑每分钟十五次请求，超过之后OpenAI就把流量分散到其他节点，那些节点都是独立的、冷的缓存。
这就把“启用缓存”变成了一个真正的设计决策：你按什么粒度设置这个key？按对话粒度设，新对话永远不会命中共享前缀，第一次调用命中率零，我们实测了这个错误配置的代价，很贵。设一个全局key，所有请求都哈希到同一个缓存节点，生产流量直接把这十五次每分钟的限额冲垮，请求溢出到冷节点，又回到全miss。按工作区粒度设是甜点区间，同一个客户工作区下的所有对话共享条目，每个key的流量保持在低位。
我们最终用的是工作区范围key，并把系统提示词拆成带断点的分层结构，镜像我们给Anthropic做的结构。这样Entry A让每个会话的第一次调用就便宜，Entry B在工作区记忆变化时miss但依然命中Entry A然后写入新的Entry B，一次上下文的写入成本而不是整段两万九token重新计费。这个方案改完，首次调用缓存命中率从大约百分之零升到百分之八十三点七，未缓存的输入token总量降了百分之二十八，GPT-5.6的整套测试成本直接掉到了Opus下面。
我们之前看到的那个成本差距每个美元都是缓存配置错误，不是模型定价的问题。如果你在比较模型成本而其中一个缓存是冷的，那你比较的是自己的配置，不是模型。
推理记录那个小设置差点让对话全崩
这个很短，但它确实搞崩了真实对话。GPT-5.6的Responses API默认把之前轮次的推理记录存成服务端的引用，我们开始间歇性地在对话中间收到Item 'rs_...' not found的错误。修复办法是设置store: false，让SDK请求加密的推理内容，用自包含的blob而不是指向服务端状态的指针。一个连带后果花掉我们一个下午调试：服务端推理状态掺和进来之后，有效提示词可能在你上游发生变化，即使你发过去的字节是只追加的也会受影响。设成store: false之后一切正常。
换完了但真正的验证是让它直接干活
这套迁移前后折腾了快两周，从测出来数据好看到真正把它推成所有工作区的默认模型，中间全是这种级别的细节。你看到的那些让人心动的速度和成本数字，背后是测试工具重写、schema转换、缓存架构重新设计、推理存储配置调整这一串事。每个单项听起来都不大，但合在一起就是迁移新模型的全部真相。
好消息是GPT-5.6 Sol确实扛得住，而且它今天正式发布了。坏消息是你大概率也会踩一遍这些坑，希望你看到这篇的时候能跳过几个。我们把它上线了，你现在就可以去免费试用，给它一个网站需求，看看四分钟以内做完一个页面是什么体验。网址是ploy.ai。
换模型这件事从来不浪漫，就是把每一层抽象都掀开看看底下到底在干什么。有时代价是钱，有时是时间，最贵的是你以为自己在测模型结果其实在测自己的配置。
/ Ploy工程博客 / 2026年7月9日 / Migrating a production AI agent to GPT-5.6 / Lorenzo Gentile，Ploy AI工程负责人 /