Topic 5｜Ploy 把生产环境 AI 智能体从 Claude Opus 4.8 切到 GPT-5.6 Sol：速度快 2.2 倍，成本低 27%
> 7/9 Ploy 工程团队发布了一份极其详尽的技术博客《Migrating a production AI agent to GPT-5.6》。Ploy 是一个 AI 自动建站平台（”AI 帮你规划、构建、发布、优化网站”），他们的核心 agent 跑了 4 个月的 Claude Opus（先 4.7 后 4.8）——直到 GPT-5.6 Sol 发布。
>
> 在真实营销网站构建测试中，GPT-5.6 Sol 的数据是：完成页面平均耗时 3 分 42 秒（Opus 4.8 是 8 分钟，快 2.2 倍）、每次构建成本 
3.06，降 27%）、输出 token 从 33.0K 降到 17.1K、视觉评分从 0.936 提升到 0.970。
>
> 但更有价值的不是这些数据本身——而是 Ploy 团队记录的完整迁移过程：他们如何发现 Claude 时代的”harness 假设”在 GPT-5.6 上集体失效；如何修 tool schema 的 25 个参数默认值问题；如何重建 prompt caching（GPT-5.6 砍掉了 partial prefix matching）；如何让 reasoning replay 自包含。
>
> 这是一份生产环境跨模型迁移的实战手册，每个遇到类似挑战的工程团队都能直接受益。
—
一、Step 0：先把 harness 修干净，否则你评的不是模型而是你的脚手架
Ploy 的 eval suite 用真实 fixture workspace 跑真实 agent，几百个 case，从”从头建首页”到”判断这个克隆请求是否安全执行”。build case 用一个 visual judge 做 binary checks，10 个 yes/no 问题（如”hero 是全幅 photo scene”或”主 CTA 是圆角矩形不是 pill”）。
他们第一次跨模型跑就发现：
问题 1：tool-call budget 是按 Opus 的 sequential 风格调的 – Opus 倾向串行调用工具，GPT-5.6 倾向并行调用 – 同一个 case，Opus 10 步搞定，GPT-5.6 一次发出 5 个并行调用把 budget 烧光 – 解决：调高 tool-call budget 上限
问题 2：eval executor 不支持 batched file reads – Opus 几乎不用 batched read，GPT-5.6 几乎每个 case 都会用 – executor 直接报错，GPT-5.6 “失败”了但实际任务做对了 – 解决：executor 加上 batched read 支持
问题 3：dataset 的 minScore 阈值缺失 – 某个 dataset 缺了 minScore 字段，静默继承默认值 1.0 – GPT-5.6 hero 拿了 0.98 算”失败”，Opus 拿了 0.99 也”失败” – 解决：所有 dataset 显式设 minScore
核心教训（Ploy 原文引用）： > “Your harness is tuned to your incumbent model, and you don’t know it.”
你正在用 Claude 调好的 eval harness 评 GPT-5.6，本质上是在测 GPT-5.6 有多像 Claude。如果你想认真比较两个模型，必须先验证 eval harness 本身对两个模型都是公平的。
这是 2026 年所有做模型评估的团队最容易踩的坑——HuggingFace Open LLM Leaderboard、LMSYS Chatbot Arena、字节 EdgeBench 都在反复迭代这个问题的答案。
—
二、First Impression：6 个数字告诉你 GPT-5.6 强在哪
修好 harness 后，Ploy 的 redesign suite（agent 用真实品牌资料重建首页）数据：
| 指标 | Claude Opus 4.8 (n=11) | GPT-5.6 Sol (n=10) | 差异 |
|---|---|---|---|
| 成本 |  2.22 | -27% | |
| Wall-clock | 8m 00s | 3m 42s | -54% (2.2x 加速) |
| Input tokens | 2.60M | 1.70M | -35% |
| Output tokens | 33.0K | 17.1K | -48% |
| Visual score | 0.936 | 0.970 | +3.4pp |
视觉评分 0.936 → 0.970 不是简单的”GPT-5.6 强 3.7%”，而是把”接近完美”拉到”真的完美”——0.97 是 Ploy 的视觉评分上限附近。
Ploy 的设计师评价：”GPT-5.6 写的代码非常现代、干净、强网格化，但倾向于收敛到同一种风格，除非你主动引导。” 在面向真实客户（每个品牌都有自己的设计语言）的场景下，这个特性反而是缺点——agent 容易”无视现有设计系统、生成漂亮但通用的输出”。
Ploy 提到这个需要专门的设计和工程团队去 steer 模型才能让品牌一致性达标——这块的工程细节他们说会写单独的博客。
—
三、Step 1：Tool calls——一个被忽视的 GPT-5.6 行为差异
这是 Ploy 第一次跨模型跑就发现的”隐形 bug”——花了三天调试。
Ploy agent 的 code 工具有 25 个顶层参数，1 个 required（action），其余 24 个 optional。Claude 的行为：只用 2-3 个，其余省略。GPT-5.6 的行为：全部 25 个，每次都发，给不需要的参数”发明”合理值。
三天生产 trace 抓的数据：
| 模型 | 调用数 | 携带全部 25 个参数的调用数 | 占比 |
|---|---|---|---|
| gpt-5.6 | 6,635 | 6,635 | 100% |
| claude-opus-4.8 | 2,898 | 4 | 0.1% |
| claude-sonnet-5 | 1,933 | 0 | 0% |
问题不只是”啰嗦”，而是 offset: 0 看起来像一个真实参数。Ploy 的 file read 实现当真处理了，结果 52% 到 64% 的 GPT-5.6 文件读取返回了空内容——因为它默认从偏移 0 读 0 字节。
更糟的是工具返回 success: true，model 完全不知道自己读到了空文件——它继续干活，但效果更差、调用更多。
所有 Ploy 试过的”提示词修复”全部失败：
– 加 “omit unused parameters” 指令 → 25/25
– 加 per-property “OPTIONAL, omit if unused” hints → 25/25
– OpenAI strict mode → 行为一致（且会强制剥除 pattern、format、array-bound validation）
真正有效的修复： 在 provider 边界做 schema transform。把 OpenAI 系模型的所有 optional 字段改写成 required but nullable（用 anyOf: [T, null]），给模型一个”明确说不”的方式。然后在所有 tool invocation 必经的 seam 把 null 剥掉，工具实现完全不用改。
// Before: 25 keys, every one carrying an invented value { “action”: “read”, “file_paths”: […], “offset”: 0, “timeout”: 120000, … }
// After: 25 keys, 4 real values, 21 explicit nulls { “action”: “read”, “file_paths”: […], “offset”: null, “timeout”: null, … }
效果：空文件读取从 52% 降到 0%，agent 少用 30% 的 tool calls 就能完成同样的工作（因为不再重读返回空白的文件）。
这个修复对所有正在用 OpenAI 系模型的工程团队都有直接价值——你的 tool schema 很可能已经踩了这个坑，只是你没发现。
—
四、Step 2：Prompt caching 重建——一个被低估的”50% 成本差距”
Ploy 的 agent prompt 开头有一段 ~29K token 的静态前缀（tool schemas + 核心 system prompt），对每个对话都一样。
Claude 的 cache 模型：
– cache_control 标记 cache breakpoints
– 静态前缀在整个组织范围内共享
– 任意对话、任意 workspace，命中同一份 cache
– 没有 throughput budget 的概念
– Cache hit rate 92-96%
GPT-5.6 改了 OpenAI 的 cache 模型：
– 旧 GPT 模型：partial prefix matching（隐式，free）
– GPT-5.6：砍掉 partial prefix matching，只有完整 prompt 命中且有 prompt_cache_breakpoint 标记才会缓存
– 必须配 prompt_cache_key——这个 key 是 cache identity 的一部分
– 同一个 prompt，不同 key → 0 cache hits
– 每个 key 映射到一个 cache node，每个 node 15 RPM 之后 OpenAI 会 fan-out 到其他有独立冷缓存的节点
这意味着”enable caching”从一个无脑开关变成了真正的设计决策——key 的 scope 怎么定？
| Key 策略 | 行为 | 问题 |
|---|---|---|
| Per-conversation key | 新对话 0% cache 命中 | 每次新对话都要付 29K token 冷读费 |
| One global key | 所有请求哈希到同一个 cache node | 15 RPM 立刻打爆，fan-out 到冷节点 |
| Per-workspace key（推荐） | 同一客户 workspace 的所有对话共享 cache | Key 流量低，冷写代价可控 |
Ploy 选 per-workspace key，配合 breakpoint 分层：
[ tools + static prefix ] ·············· A 每个 session 命中 [ tools + static prefix + workspace context ] ··· B 同 context 命中 [ ····················· + turn 1 + … + latest ] C 本 session 链
Entry A 让首次调用就便宜。Entry B 自愈（context 变了 miss B 但仍 hit A）。Entry C 是 OpenAI 隐式整 prompt 链。
修复后数据： – 首次调用 cache hit：0% → 83.7% – 未缓存的 input tokens 减少 28% – GPT-5.6 的单次成本反过来低于 Opus
Ploy 的总结很尖锐： > “If you’re cost-comparing models and one of them has a cold cache, you are comparing your config, not the models.”
跨模型成本对比的前提是两边都把 cache 配到最优。任何一边有冷缓存，对比结果都是你的 config 问题，不是模型定价问题。
—
五、Step 3：Reasoning replay 必须自包含
GPT-5.6 的 Responses API 默认把上一轮 reasoning 作为服务端 item references 来 replay。这导致 Ploy 的对话中途间歇性失败——Item 'rs_...' not found。
修复：store: false，让 SDK 请求加密的 reasoning content，replay 自包含的 blob 而不是服务端状态的指针。
附带教训（花了一下午 debug 才发现）：当服务端 reasoning state 在循环里，你发出去的 prompt bytes 即使 append-only，有效 prompt 也可能在服务端被上游修改——一个非显然的数据一致性陷阱。
—
六、深度剖析：跨模型迁移的”四个真相”
把 Ploy 的迁移经验抽出来，是 2026 H2 所有做 AI agent 工程的团队都要面对的四个真相：
真相 1：你的 harness 是为你 incumbent 模型调的，你不知道它偏得多深 – 修 harness 不是技术债清理——是评测的前置条件 – 任何严肃的跨模型对比都必须先在两个模型上分别调通 harness，再做对比 – LangSmith、Langfuse、Helicone 在做 LLM 可观测，但跨模型评测 harness 标准化这件事还没有共识
真相 2：tool calling 是模型层差异最大的环节 – OpenAI 默认”为所有 optional 参数填默认值”——这是 OpenAI 系模型的设计哲学，不是 bug – Anthropic 默认”只发用到的参数”——这是 Anthropic 的设计哲学，也不是 bug – 任何想跨模型工作的 agent 必须在 schema 层做抽象，不能假设两边行为一致
真相 3：prompt caching 是成本结构的决定性变量 – 同样的模型、同样的输入，只因为 cache 配置不同，成本可能差 50%+ – 跨模型迁移的成本对比必须先把两边 cache 都调到最优 – 静态前缀缓存是 agent 成本结构的核心——设计 prompt 时要把”哪些 token 真的不变”想清楚
真相 4：reasoning replay 是新的状态管理战场 – Anthropic 和 OpenAI 在 reasoning state 管理上的设计哲学不同 – 多轮对话中的 reasoning replay 必须显式控制（store: false / store: true / encryption） – 这是 OpenAI Responses API 的一个新陷阱，对所有迁移过去的团队都要走一遍
—
七、为什么这是 AI Agent 工业化的关键节点
把 Ploy 的迁移放到 2026 H2 的行业坐标里：
| 事件 | 时间 | 信号 |
|---|---|---|
| Claude Sonnet 5 = Opus 60% 价格 + SWE-bench Pro 63.2% | 6/30 | Anthropic 主力模型换挡 |
| Cognition SWE-1.7（基于 Kimi K2.7）+ Cerebras 1000 TPS | 7/8 | AI coding 成本曲线被改写 |
| OpenAI 三层模型 × 两层推理档位（GPT-5.6 + Sol） | 7/9 | OpenAI 推理领先 + 商业化范式 |
| Ploy 把生产 agent 切到 GPT-5.6 Sol，2.2x 加速、27% 降本 | 7/9 | 第一个公开记录"完整迁移到 OpenAI"的 AI 创业公司 |
Ploy 的这次迁移不是”换供应商”那么简单——它意味着 AI 创业公司开始把”主力模型”从 Anthropic 切到 OpenAI 是公开可行、可量化收益的。这会让更多公司重新评估自己的模型策略。
更关键的是，Ploy 把迁移过程的每一个工程细节都公开了——这是 AI 行业的工程文化正在走向成熟的标志。两年前，跨模型迁移是各家公司不公开的核心工程经验；今天，Ploy 把它写成了 11 分钟的工程博客，免费分享。
—
八、风险与待观察
Ploy 自身的偏差： – Ploy 的业务是营销网站构建——视觉评分、页面结构、组件库的差异对结果影响很大。如果换成 B2B SaaS 后端、数据管道、嵌入式系统，Opus vs GPT-5.6 的对比可能完全不同 – 11 个 build case + 10 个 build case 的样本量太小，统计噪声不小 – Ploy 自己的视觉评分模型可能对 GPT-5.6 的输出有偏（raters 训练数据可能包含大量 GPT-5.6 输出）
OpenAI 模型的反向锁定风险： – Ploy 现在深度依赖 GPT-5.6 的 Responses API、prompt_cache_key 机制、tool schema 行为——这些全是 OpenAI 私有 API – 下次 OpenAI 改 API 行为（如砍掉 partial prefix matching），Ploy 又要花大量工程时间迁移 – 多模型策略的真正成本不是 prompt engineering，是 API 行为差异的迁移成本——这点 Ploy 没说但每个团队都要想清楚
Anthropic 的回应： – Anthropic 会不会出”Sonnet 5.5 / Opus 5.0″重新夺回 Ploy 这类客户？很可能 – Anthropic 会不会在 cache 模型上做调整（比如支持 per-workspace key）？也有可能 – 跨模型迁移的频率会越来越高——2026 H2 可能变成”每 3-6 个月迁移一次”的常态
—
> 原文链接： > – Ploy 工程博客：https://ploy.ai/blog/migrating-a-production-ai-agent-to-gpt-5-6 > – AI SDK（Vercel 跨模型 SDK）：https://ai-sdk.dev/docs/introduction > – OpenAI Responses API 文档：https://developers.openai.com/api/docs/guides/function-calling > – OpenAI Prompt Caching 文档：https://developers.openai.com/api/docs/guides/prompt-caching