HN 跟进｜Ploy 迁移 GPT-5.6 后自报用时缩短约 54%

Ploy 这篇文章值得进入早报头条，不是因为它证明 GPT-5.6 一定全面领先，而是因为它把“换模型”拆成了一个可检查的生产迁移账本。

已确认事实很窄：Ploy 在 2026-07-09 发布工程博客，称其生产 Agent 已默认运行在 GPT-5.6 Sol 上；HN 在 2026-07-12 收录并开始讨论。Ploy 自报的核心数字是完成用时缩短约 54%、速度约为 2.2 倍，成本下降 27%。

不确定部分同样要前置。用时缩短约 54%、速度约为 2.2 倍和 成本下降 27%不是第三方 benchmark，也不是公开可复现实验。它们来自 Ploy 团队自己的任务集、评测器、计费口径和生产 traces。

对读者的影响在于方法。开发者应关注 Ploy 公开的迁移步骤，而不是只记住标题数字；企业买方应把这类文章当成询价和技术尽调清单，而不是把它当成模型采购结论。

这次迁移到底发生了什么

Ploy 的产品场景是营销网站 Agent。原文说，这个 Agent 会规划页面、读取代码库、写组件、生成图片、截图自检，并决定何时完成。也就是说，它不是一次聊天问答，而是一个长链路、多工具、带视觉目标的工作流。

Ploy 称，在四个月里 Claude Opus 一直是默认模型，先是 Opus 4.7，后是 Opus 4.8。GPT-5.6 Sol 是第一个在其内部评估中超过默认模型的候选。这个说法只能按 Ploy 自报处理，因为外部看不到完整模型池和所有失败样本。

文章中最有信息量的部分，是 Ploy 承认第一轮 eval 并不干净。其工具调用预算按 Opus 的顺序执行风格设置，GPT-5.6 更常并行展开调用，导致一些正确解决任务的 case 被预算打断。评测执行器也没有支持 batched file reads，而 GPT-5.6 常用这种读法。

Ploy 的结论是：先修 harness，再看模型分数。原文称首轮跨模型 raw failures 里，大约三分之一来自评测假设，而不是模型行为。这个数字仍是 Ploy 自报，但它指出了一个真实问题：生产 Agent 的评测器会继承默认模型的行为风格。

迁移账本：Ploy 自报数字怎么读

Ploy 给出的核心表格来自 redesign suite。任务是让 Agent 依据参考设计重建品牌主页。Ploy 说，清理 harness 后，GPT-5.6 在完成页面的样本里更快、更便宜，视觉分也略高。

这个表格能证明 Ploy 在自己的生产近似环境里看到了改进。它不能证明 GPT-5.6 在所有营销网站、所有品牌风格、所有用户偏好上都更好。

HN 的讨论正好补上了这层 caveat。有评论者认可文章里 pipeline 设计的实用经验，也有人追问“用户更喜欢哪一个版本”“营销结果是否带来更高转化”。这些问题不会推翻 Ploy 的 trace 数字，但会限制这些数字的商业解释。

还有一个细节值得注意。Ploy 原文说 GPT-5.6 生成的设计干净、现代、网格感强，但容易趋向统一风格，早期 harness 下会忽略既有设计系统。换句话说，更快的完成页不等于更好的品牌贴合。

第一处坑：工具 schema 不是中性接口

Ploy 最具体的工程问题出现在 tool calls。其 code tool 有 25 个顶层参数，只有 action 必填，其余可选。Ploy 称 Claude 通常只发送正在使用的两三个参数，而 GPT-5.6 每次都发送全部 25 个参数，并为未使用字段填入看似合理的值。

问题不在“啰嗦”，而在假值会被工具当成真值。Ploy 举例说，offset: 0、timeout: 120000、伪造的 siteId 会进入工具实现。其结果是 GPT-5.6 的文件读取有 52% 到 64% 返回空内容，但工具仍返回 success: true。

Ploy 的修复方式是 provider boundary 上的 schema transform。对 OpenAI-family models，它把可选属性改写成“必填但可为 null”，让模型可以显式表达“这个字段不用”。随后在工具调用进入真实实现前剥掉 null。

这个做法和 OpenAI function calling 文档的关系要说清。OpenAI 文档能说明模型通过工具定义和 schema 生成函数调用，也能解释 strict schema 这类约束机制。它不能证明 Ploy 观察到的 100%全字段发送行为是 GPT-5.6 的通用规律。

工程含义是，Agent 的工具层不能假设“可选字段被填了就是模型有意图”。当 provider 的 tool-call 风格改变，原先在一个模型上安全的默认值，可能在另一个模型上变成静默错误。

第二处坑：缓存决定成本，不只是模型价格

Ploy 文章里最值得企业买方关注的是 prompt caching。原文称，其 Agent prompt 开头有约 29K tokens 的静态前缀，包括工具 schema 和核心 system prompt。这个前缀如果缓存命中，成本和延迟都会明显变化。

Ploy 的说法是，Claude 侧通过 cache_control 标记断点，静态前缀能在组织层面共享，命中率约 92% 到 96%。迁到 GPT-5.6 后，如果继续依赖早期 GPT 模型的隐式 partial prefix matching，新 conversation 共享同一静态前缀时可能 0%命中。

OpenAI prompt caching 文档给了对应机制背景。文档说明，GPT-5.6 及后续模型上，cache writes 按 uncached input token rate 的 1.25 倍计费；使用更可靠匹配时，需要关注 prompt_cache_key；每个 key 的总流量建议约 15 requests per minute。

Ploy 最后采用 workspace-scoped key，把缓存 key 按客户 workspace 切分。其解释是：conversation 级 key 会让新 conversation 无法命中共享前缀；全局 key 会让流量超过单 key 承载，导致请求打到冷缓存节点；workspace 级 key 在共享和分流之间更平衡。

Ploy 自报的结果是 first-call cache hits 从约 0%到 83.7%，uncached input tokens 下降 28%。这些数字仍不能外推，但它们提示了一个采购问题：如果供应商只给“模型单价”而不给缓存命中率，成本对比可能没有意义。

第三处坑：reasoning replay 也会影响可复现性

Ploy 还提到一个较短但真实的故障：GPT-5.6 的 Responses API 默认会把 prior-turn reasoning 作为 server-side item references 重放。Ploy 说，其生产对话一度间歇性报 Item 'rs_...' not found。

其修复是设置 store: false，让 SDK 请求 encrypted reasoning content，并以自包含 blob 的形式重放，而不是依赖服务端状态指针。OpenAI reasoning 文档能解释 reasoning 内容和请求状态的相关机制，但不能验证 Ploy 具体报错的频率。

这件事的实际含义是，Agent 迁移不只关乎最终回答质量。长对话和多回合任务会依赖历史 reasoning、工具轨迹和服务端状态。只要其中一层不是自包含的，开发者就很难做到稳定回放。

这也解释了为什么 Ploy 明明使用了 Vercel AI SDK，仍然需要做 provider-specific 修复。Vercel AI SDK 文档说它标准化了多 provider 的模型接入，并让开发者聚焦应用本身。但 Ploy 的案例说明，统一 SDK 只能减少接入差异，不能消除每个 provider 的运行时语义。

信源质量：这不是独立 benchmark

本条的 source quality 应按“团队自报 + HN 讨论”理解。Ploy 是一手来源，但它同时是利益相关方。HN 是新鲜讨论锚点和反方问题来源，但不是复现实验。

更谨慎的说法是：Ploy 披露了一个有细节的生产迁移案例。它有具体样本表、trace 归因、schema 修复、缓存设计和 reasoning replay 处理。它比普通营销稿更有工程价值。

但它仍缺几项关键材料。第一，完整 eval suite 未公开，外部无法知道失败任务和边界任务占比。第二，视觉 judge 的十个 yes/no 检查只给了示例，不能判断它是否偏向某种现代网页风格。第三，成本表未完整拆分缓存冷启动、重试、图片生成和人工处理。

HN 讨论里的转化率问题尤其重要。Ploy 的 Agent 面向营销网页，最终价值不只在页面是否完成，也在用户是否更愿意点击、注册或购买。如果 GPT-5.6 更快生成一个“干净但统一”的页面，转化结果仍可能不如更慢但品牌贴合的版本。

因此，本文使用 medium confidence。可确认的是 Ploy 发文、HN 收录、Ploy 自报数字和文档机制背景；中置信的是 Ploy 对迁移收益的归因；低置信的是这些收益在其他 Agent 任务上的泛化。

复现清单：哪些证据还缺口最大

如果要把这篇案例升级成高置信经验，外部复现至少需要四类证据。第一是任务集。Ploy 说 eval suite 覆盖从“从零搭 homepage”到“clone request 是否安全执行”等 hundreds of cases，但公开文章只展示了少量 redesign 样本。复现者需要知道任务难度分布、每类任务占比、失败样本是否被排除，以及同一个 reference design 是否在两个模型之间完全一致。

第二是评分器。Ploy 说 build case 用视觉 judge 做十个 yes/no 检查，还包括内容检查、tool trajectory 检查和文件断言。这个设计比单纯人工主观评分更可审计，但外部仍看不到完整题目、权重、阈值和人工复核流程。尤其是 minScore 默认值导致的误判，说明评测器本身也可能制造模型差异。

第三是成本表。Ploy 公开了每个 completed build 的平均成本，但没有把缓存冷启动、cache write、重试、图片生成、失败后回滚、人工编辑和未完成任务拆成独立行。对于企业买方，完成任务的平均成本只是一部分，真实账单还要看失败率和长期维护。

第四是业务指标。营销页面 Agent 的质量最终应接近用户行为数据。视觉分可以衡量“像不像 reference”，但不能替代点击率、注册率、转化率、品牌一致性人工评分和客户接受率。HN 评论追问“用户更喜欢哪一个版本”，正是这类生产场景最难绕开的验证问题。

按这个标准看，Ploy 文章已经提供了有用的工程入口，却还没有完成外部可复现闭环。它最适合作为团队内部迁移 checklist：先修评测器，再查工具参数，再重建缓存，再保证 reasoning replay 可回放，最后才比较模型输出质量和业务结果。

接下来看什么

第一，看 Ploy 是否补充失败样本。优秀迁移文章不只展示成功 case，还应展示 GPT-5.6 何时输给 Opus、何时生成泛化设计、何时因工具轨迹出错。失败样本比胜利样本更能帮助外部判断可迁移性。

第二，看成本口径是否进一步拆开。当前 Ploy 表格里有 per completed build 成本，但企业需要知道冷缓存、cache write、重试、图片生成、人工回滚和无效任务是否都被计入。

第三，看其他 Agent 场景是否出现类似迁移报告。编码 Agent、数据分析 Agent、客服 Agent 和设计 Agent 的工具层不同。Ploy 的 schema transform 和 workspace cache key 可能有普遍价值，但仍要靠更多场景验证。

第四，看 OpenAI 生态是否把这些 provider 行为封装得更稳定。Vercel AI SDK 这类抽象层已经降低了接入难度，但 Ploy 证明运行时差异仍会穿透 SDK。未来 SDK 的价值可能转向“迁移诊断”和“provider behavior guardrails”。

第五，看 HN 追问是否变成产品指标。营销 Agent 的最终裁判不是视觉分，而是用户行为。若 Ploy 能把模型迁移后的转化率、编辑回滚率、人工接受率和品牌一致性公开，今天的中置信案例才有机会升级为高置信经验。