将生产AI代理迁移到GPT-5.6：性能提升与工程经验
即日起，Ploy的AI智能体将运行于GPT-5.6 Sol——OpenAI今日发布的旗舰级模型。数月来，我们测试了多款模型，均未达到替换Claude Opus的标准，直到GPT-5.6 Sol出现。经过一对一对比评估，我们将其设为所有Ploy工作区的默认模型。
Ploy智能体负责搭建与编辑生产级营销网站：从规划页面、研读代码库、编写组件、生成图像，到自动截图验收、判断任务完成时机，全流程自主完成。我们会用这套工作负载测试每一款前沿模型。在Claude Opus（先是4.7版本，后升级至4.8）担任默认模型的四个月里，没有任何模型能与之匹敌，GPT-5.6是首个实现超越的模型。
首轮评估暴露了若干故障模式，我们将在下文详述，但同时也取得了亮眼成果：完成网站搭建的耗时不足原来的一半，成本降低27%，评分达到甚至超过原模型。这些结果为模型迁移工作提供了充分依据。
我们采用Vercel的AI开发工具包（AI SDK），但从Claude Opus 4.8切换至GPT-5.6 Sol时，仍发现整个技术栈中存在大量针对特定模型供应商的预设逻辑。两家供应商的模型在工具参数填充、提示词缓存、多轮对话推理重放等机制上均存在差异。
我们的修复工作按以下顺序推进：先修正评估框架，再调整工具 schema、提示词缓存与推理重放机制。
步骤0：先修正评估框架，再信任任何数据
我们的评估套件会让生产级智能体在固定测试工作区运行，覆盖数百种场景，从"从零搭建首页"到"判断克隆请求是否安全执行"。针对搭建类任务，视觉评审会对照参考设计进行十项二元检查，例如"首屏英雄区为全屏图片场景""主要行动按钮（CTA）为圆角矩形而非胶囊形"。此外，我们还会开展内容检查、工具调用轨迹检查与文件断言，并结合完整调用轨迹（包括工具调用记录与模型输出文本）排查每一处故障。
首轮跨模型测试就暴露了评估框架的问题。
我们原本为Opus的串行调用风格设定了工具调用预算，但GPT-5.6采用并行调用，在正确完成任务的情况下仍会超出预算。同时，我们的评估执行器不支持批量文件读取——这一功能Opus极少用到，但GPT-5.6却频繁使用。首轮测试中，约三分之一的原始故障并非由模型行为导致，而是源于评估框架的预设逻辑，且这类故障的分布并不均匀。因此，在对比新模型与原模型时，务必先排查调用轨迹，再信任通过率数据，否则评估会变相鼓励新模型模仿旧模型的行为模式。
此外，有一个数据集未设置minScore阈值，系统自动采用了1.0的默认值，且无任何告警提示。这导致GPT-5.6生成的英雄区得分0.98却被判"失败"，而Opus在通过所有单项检查的情况下，也因这一隐含阈值被判"失败"。实际上，两款设计均符合要求，问题出在不合理的默认阈值上。
基准测试结果
修正评估框架后，我们重新运行了改版测试套件——让智能体对照参考设计重建品牌首页。
| 单页完成后平均指标 | Claude Opus 4.8（样本量=11） | GPT-5.6（样本量=10） |
|---|---|---|
| 成本 | 3.06美元 | 2.22美元 |
| 实际耗时 | 8分00秒 | 3分42秒 |
| 输入令牌数 | 260万 | 170万 |
| 输出令牌数 | 3.3万 | 1.71万 |
| 视觉评分 | 0.936 | 0.970 |
GPT-5.6的页面完成速度是Opus的2.2倍，成本降低27%，输出令牌数约为后者的一半，代码编写量也更少。在一组对照测试中，Opus生成的globals.css文件长达17957字符，包含174个CSS变量，其中多数是未使用的渐变色阶；而GPT-5.6仅用2508字符与45个变量，就实现了效果相当甚至更优的页面渲染。
Claude Opus 4.8测试结果
GPT-5.6 Sol测试结果
设计质量与一致性
GPT-5.6擅长打造简洁、规整的栅格布局，但如果缺乏明确引导，它会倾向于固化这种风格。在原本为Opus 4.8设计的旧框架下，GPT-5.6 Sol常常忽略现有设计系统，生成简洁但缺乏特色的通用页面。
我们在这方面的改进值得单独撰文详述。设计与工程团队优化了引导机制，最终让GPT-5.6达到了我们对生产环境的品牌一致性要求。
步骤1：检查工具调用逻辑
我们智能体的code工具包含25个顶层参数，其中action为必填项，其余为可选项。Claude只会传入它用到的两三个参数，省略其余参数；而GPT-5.6每次调用都会传入全部25个参数，为未使用的参数填充看似合理的值，例如offset: 0、timeout: 120000、siteId: "00000000-0000-0000-0000-000000000000"。
我们分析了三天的生产环境code(read)调用轨迹，得出如下数据：
| 模型 | 调用次数 | 携带全部25个参数的占比 |
|---|---|---|
| gpt-5.6 | 6635 | 6635（100%） |
| claude-opus-4.8 | 2898 | 4（0.1%） |
| claude-sonnet-5 | 1933 | 0 |
问题不在于冗余，而在于文件读取模块无法区分参数是真实需求还是模型虚构的值。它会将offset: 0视为有效参数，导致GPT-5.6的文件读取请求中有52%至64%返回空内容。由于工具对有效读取与空读取均返回success: true，模型无法察觉自己读取的是空文件，只能通过增加调用次数来弥补，进而导致结果质量下降。
提示词优化无法解决这一问题：即使在工具描述中明确要求"省略未使用参数"，GPT-5.6仍会传入全部25个参数；为每个参数添加"可选，未使用则省略"的提示也无济于事。我们测试了OpenAI的strict模式，结果依旧，且启用该模式需要移除所有schema中的pattern、format与数组边界校验。鉴于这是模型函数调用机制的固有行为，我们最终选择修改schema。
有效的解决方案是在供应商接口处添加schema转换：针对OpenAI系列模型，将所有可选参数改写为必填但可空，使用anyOf: [T, null]语法。这样模型就会为未使用的参数赋予明确的空值，随后在通用工具调用接口处移除这些空值，无需修改工具的具体实现。模型看到的是能体现参数未使用状态的schema，而工具收到的输入则与之前保持一致。
// 转换前：25个参数，均为模型虚构值
{ "action": "read", "file_paths": [...], "offset": 0, "timeout": 120000, ... }
// 转换后：25个参数，4个真实值，21个明确空值（工具运行前会被移除）
{ "action": "read", "file_paths": [...], "offset": null, "timeout": null, ... }
修改后，空文件读取的比例从52%降至0%，智能体完成相同任务的工具调用次数减少了约30%，无需再重复读取空结果。
步骤2：重构提示词缓存机制
两家供应商均提供"提示词缓存"功能，但实现方式差异显著。在我们针对这些差异做出调整前，GPT-5.6的成本看似比Opus高出约50%——问题出在缓存配置，而非模型定价本身。
我们智能体的提示词开头是一段约29K令牌的静态前缀（包含工具schema与核心系统提示词），所有对话均使用相同内容。在Claude平台，我们通过cache_control标记缓存断点，该前缀可在整个组织内共享缓存，任何工作区的对话都能使用同一个缓存条目，且无单键吞吐量限制，缓存命中率可达92%至96%。
GPT-5.6采用OpenAI的另一套缓存模型。早期GPT模型支持隐式前缀部分匹配，但GPT-5.6取消了这一功能，如今隐式缓存会以最新消息为键，创建完整提示词的缓存条目。这意味着新对话即使共享29K静态前缀，缓存命中率仍为0%，每轮对话都会按未缓存费率重新计费。此外，GPT-5.6对所有未缓存提示词额外收取1.25倍的缓存写入费用，无论应用是否启用缓存功能。
OpenAI的显式缓存机制使用prompt_cache_breakpoint标记与必填的prompt_cache_key。缓存键是缓存标识的一部分，相同提示词搭配不同键不会产生缓存命中。每个键对应一个缓存节点，每分钟约支持15次请求，超出后流量会被分流至其他具有独立冷缓存的节点。
核心设计决策在于确定缓存键的作用范围：
- **按对话设键：**新对话无法命中共享前缀缓存，实测首次调用命中率为0%。
- **全局单键：**所有请求均映射至同一个缓存节点，生产流量远超15次/分钟的限制，请求会溢出至冷缓存节点。
- **按工作区设键：**同一客户工作区内的所有对话共享缓存条目，同时单键流量保持在较低水平。
我们最终采用工作区级缓存键，并将系统提示词拆分为带断点的多层结构，与Anthropic平台的现有结构保持一致：
请求 ──► 哈希(提示词头部 + prompt_cache_key) ──► 缓存节点（每键约15次请求/分钟）
│
┌──────────────────────────────────────────────────────┴───────────────┐
│ 节点上的缓存条目，均以ws:{workspaceId}为命名空间 │
│ │
│ [ 工具 + 静态前缀 ]······················ A 所有会话共享 │
│ [ 工具 + 静态前缀 + 工作区上下文 ]·· B 相同上下文共享 │
│ [ ····················· + 第1轮 + … + 最新轮次 ] C 当前会话专用 │
└──────────────────────────────────────────────────────────────────────┘
条目A降低了会话首次调用的成本。当工作区内存更新时，请求会错过条目B，但仍能命中条目A，随后写入新的条目B——这只需写入一次上下文大小的内容，无需重新支付29K前缀的费用。条目C是OpenAI的隐式完整提示词链，由于我们的提示词严格采用追加式，因此在会话内可以正常工作。
OpenAI的键分区机制导致静态前缀无法跨工作区共享，而Anthropic的缓存为组织级，无键分区限制，因此可以共享前缀。在GPT-5.6上，每个工作区在闲置期后需支付一次29K冷写入费用，约0.18美元，成本可控且可预测。
调整后，首次调用缓存命中率从约0%提升至83.7%，未缓存输入令牌总数减少28%，GPT-5.6的单套件测试成本降至Opus以下。此前测得的成本差距完全由缓存配置错误导致——若某一模型始终从冷缓存启动，模型间的成本对比毫无意义。
步骤3：实现独立的推理重放
推理重放曾导致生产环境对话出现间歇性故障。GPT-5.6的Responses API默认通过服务器端条目引用重放历史轮次的推理内容，我们的对话有时会出现Item 'rs_...' not found错误。设置store: false后，开发工具包会请求加密推理内容，以独立数据块而非服务器状态指针的形式重放推理过程。我们还发现，即使应用发送的提示词是追加式的，服务器端推理状态仍可能改变实际生效的提示词。
GPT-5.6 Sol正式投入生产环境
GPT-5.6今日发布后，已在Ploy平台上线。你可以前往ploy.ai免费试用，让它搭建一个网站，体验不到四分钟即可完成的搭建速度。
Ploy是一款AI层工具，可完成网站与营销活动的规划、搭建、发布及优化工作。如果你觉得凌晨2点调试缓存节点分流机制是件有趣的事，欢迎加入我们的团队。