GPT-5.6 降价了，但别急着换模型。真正的成本陷阱在于让模型做了太多不该做的事。本文拆解 Agent 任务四分类法，指出产品经理应先优化工作流而非盲目升级模型，并给出从上下文管理到模型路由的实战建议。

OpenAI 最近发布了 GPT-5.6 的构建者指南。里面有一组很容易让人兴奋的数据：在 OpenAI 的示例里，GPT-5.6 Luna 在 BrowseComp 上的得分接近 GPT-5.5，但成本从 33.27 美元降到 1.33 美元。

模型更强，也更便宜。很多企业接下来的动作大概率很一致：把原来的模型换掉。

我看完的第一反应却是：先别急着换。

因为很多 Agent 贵，根本不只是模型贵。它贵在你让模型做了太多本不该由模型做的事情。

筛选一万条数据、按规则去重、把表格转成固定格式、判断某个字段是否为空，这些工作并不需要一个昂贵的推理模型。可不少 Agent 的实现方式是，把所有原始材料塞进上下文，再让模型读一遍、想一遍、写一遍。

模型降价以后，这种流程当然也会便宜一点。

但它本质上还是低效。

一、模型变便宜，不等于 Agent 自动变好用

OpenAI 在这份指南里谈了推理持久化、压缩、程序化工具调用和提示词缓存。它想表达的其实不是“新模型更划算”这么简单，而是 Agent 的成本和效果，已经越来越取决于系统怎么组织任务。

同样一个任务，模型每次都从头读上下文，和它能够复用已有状态、把确定性步骤交给程序处理，成本不会是一个数量级。

这也是很多团队容易忽略的地方。

大家经常把 Agent 的成本理解成 token 单价：输入多少、输出多少、模型贵不贵。可真正落到生产环境，成本还包括重复调用、失败重试、上下文膨胀、人工返工和工具执行。

如果一个 Agent 做一次任务，要反复读取同一份资料，调用五六个工具以后还要把所有返回结果重新塞回模型，上一个更便宜的模型，未必能解决问题。

你只是把原来的浪费打了个折。

二、产品经理该先拆任务，再谈模型选型

我更倾向于把一个 Agent 任务拆成四类。

第一类是规则非常明确的工作。

比如数据校验、字段筛选、去重、格式转换、权限判断。这些工作应该尽量交给代码、数据库或规则引擎。它们便宜、可预测，也更方便排错。

第二类是轻量的语义工作。

比如摘要、分类、信息抽取、固定格式的改写。这里可以先用轻量模型，并给出少量清晰样例。不要因为“用了 Agent”，就默认每一步都要上最强模型。

第三类才是复杂判断。

跨文档推理、模糊需求澄清、方案比较、长链路决策，这些任务才值得调用能力更强的模型。强模型应该用在真正影响结果的环节，而不是负责搬运信息。

还有一类最容易被忽略：高风险动作。

涉及付款、删除、修改生产数据、发给客户、提交代码或调用外部系统时，问题已经不只是模型能不能做，而是出了问题谁来接手。

我的判断是，当前阶段的低风险任务可以自动化；高风险任务必须分级授权，并保留人工介入。

模型能力以后可能会继续提高，甚至在某些场景里比人处理得更稳。但在产品设计上，不能先假设它永远不会错。权限、日志、审批和回滚，应该在放权之前就设计好。

三、先改上下文，往往比换模型更省钱

我用 Claude Code、Codex 和国产的 WorkBuddy 时，有一个很直观的感受：同一个模型，给它的上下文不同，结果会差很多。

上下文不是把历史记录越塞越多。

一个做得比较好的 Agent，至少要知道哪些信息是长期有效的，哪些只对当前任务有效，哪些结果已经验证过，可以直接复用。否则每次启动，它都像一个刚入职的新人，又要从头翻材料。

OpenAI 在指南中提到的推理保留、压缩和缓存，提供的是技术能力。产品经理真正要做的，是决定哪些信息值得保留，保留多久，谁能读取，以及状态失效后怎么清理。

这里有个常见误区：把更多上下文当成更聪明。

上下文太多，模型不一定更准。它可能抓不住重点，也可能把旧任务里的结论带进新任务。对于企业产品来说，错误复用有时比重新推理更危险。

所以应该先画出任务的状态图：输入从哪里来，中间结论存在哪里，什么条件下可以复用，什么条件下必须重新计算。模型只是其中一个节点。

四、工具调用不是“会用工具”就够了

很多 Agent 的演示很漂亮：模型自己搜资料、读文档、写代码、执行命令，最后给出答案。

但产品真正上线以后，最先暴露问题的通常不是回答质量，而是工具调用。

工具返回的数据可靠吗？接口超时怎么处理？模型连续调用失败时，何时停止？它拿到的权限是不是超过了任务需要？结果错了，团队能不能定位到是模型判断错了、工具错了，还是数据源错了？

这些问题不够“酷”，但决定 Agent 能不能进入真实流程。

Cursor 最近发布的 Builds 也说明了这一点。它把仓库和依赖预先构建成云端环境，并保留构建日志、提交 SHA 和失败恢复机制。官方称，这能改善云端 Agent 的启动速度和稳定性。

对产品经理来说，这个案例的价值不在于记住速度提升了多少，而在于认识到：运行环境、状态管理和失败恢复，已经是 Agent 产品的一部分。

用户不会因为你的模型很强，就愿意接受一次失败后所有工作丢失。

五、模型路由，才是下一阶段更现实的产品能力

以后企业大概率不会只用一个模型。

复杂任务用最强模型，日常的小任务用低成本模型；敏感数据根据业务情况选择本地部署或满足要求的云服务；明确规则优先由程序执行。这种组合才更接近企业实际需要的方案。

但“模型路由”不能只理解成按价格切换模型。

它至少要回答几个问题：什么任务可以降级，什么任务必须升级；模型输出不确定时怎么复核；业务高峰时是否要排队；敏感数据能不能离开本地；轻量模型出错后，交给强模型还是直接交给人。

这本质上是产品策略，不是采购问题。

模型厂商会持续把价格和能力往前推，产品经理不能只跟着发布节奏换模型。你需要把真实业务拆成一张任务表：任务目标、数据范围、风险等级、成功标准、人工接管条件和单位任务成本。

没有这张表，所谓模型选型，大多数时候只是跟风。

六、最后说一句不好听的真话

Agent 变便宜之后，产品经理不会更轻松。

以前你可以把问题归结为“模型还不够强”。以后模型更强、更便宜，这个借口会越来越站不住。

真正拉开差距的，不是谁最早接入新模型，而是谁先把工作流重做了一遍。

把该交给程序的交给程序，把需要判断的交给模型，把不能出错的地方留给人。然后用日志、评测和回滚机制，把每一次自动化的边界盯住。

工作流不变，企业只是把低效变便宜了。

这可能才是 GPT-5.6 给产品经理最实际的提醒。

资料说明

本文涉及的 GPT-5.6 功能、评测示例及成本数据，来自 OpenAI 于 2026 年 8 月 13 日发布的《The builder’s guide to GPT-5.6》；Cursor Builds 的产品行为与性能数据，来自 Cursor 于 2026 年 8 月 13 日发布的官方博客。文中关于任务拆分、模型分层与人工接管的内容，为作者个人观点。

参考链接：

– OpenAI: https://openai.com/index/builders-guide-to-gpt-5-6

– Cursor: https://www.cursor.com/blog/builds