别让最强模型搬数据：GPT-5.6 之后，Agent 降本靠工作流分层

发表于
GPT-5.6 的生产数据说明，真正有效的 Agent 降本不是统一换便宜模型，而是把数据处理、模型判断、并行任务与长期上下文放到不同执行层。

假设一个研究 Agent 要读取 100 份公司公告，筛出最近三个月的交易，去重、计算金额，再判断哪几笔值得进一步调查。

很多系统会让同一个最强模型完成全部过程：模型读完一份，决定下一步，再读一份，然后过滤、计算、比较。最终答案也许很好，但最昂贵的推理能力，大量消耗在日期过滤、字段拼接和数字相加上。

我的判断是：GPT-5.6 真正释放的信号，不只是模型变便宜了，而是 Agent 的工作流必须开始分层。代码负责确定性的数据搬运，小模型承担高频、低风险的语义步骤，强模型只处理复杂判断；推理保留、上下文压缩和缓存，则负责避免系统反复忘记和重做。

Agent 降本正在从“选哪个模型”，变成“哪一步应该由什么执行”。

最强模型不该成为所有步骤的默认工人

OpenAI 在 8 月 13 日发布的 GPT-5.6 Builder’s Guide 中列出了一组很有代表性的数据。

在 Harness 保持不变的 Agents’ Last Exam 测试中，GPT-5.6 Sol 使用 low reasoning，已经超过 GPT-5.5 使用 high reasoning 的结果。OpenAI 还披露，GPT-5.6 Luna 在 BrowseComp 上得到 84.04%，总成本 1.33 美元；三个月前，GPT-5.5 Extra High 的成绩是 84.36%，成本 33.27 美元。

同一篇文章里的早期客户案例更加直观：

场景 官方文章披露的结果 应该怎样理解
文档抽取 Luna 保留 GPT-5.5 约 98% 的准确率，成本约为十八分之一 高频抽取不一定需要旗舰模型
106 个高难浏览器任务 Luna 完成 78%，约 14 美元；对照模型完成 80%，约 235 美元 接近的成功率可能对应完全不同的单位经济性
代码检索与决策建模 成本下降 64%，响应时间下降 90%，F1 增加 5 个点 小模型不只是省钱，也可能更适合高频步骤

这些数字来自 OpenAI 及参与早期测试的客户，不是独立、跨行业的普遍保证。任务集、提示词、工具、失败重试和计费口径改变，结果也会改变。

但它们足以推翻一个旧默认：不应该再先给整个 Agent 选择一个模型，然后让这个模型包办一切。 更合理的问题是，每一步究竟需要语言判断、确定性计算、并行探索，还是只需要记住之前已经做过什么。

这正好延续了我在 Agent ROI 文章 中的判断：模型已经是一种需要按任务分配的工程资源。只是这一次，分配粒度要从“一个任务”继续下降到“任务里的每个阶段”。

第一层：让代码接管确定性的数据搬运

Agent 工作流通常同时包含两种事情：需要判断的工作，以及移动、过滤和组合数据的工作。

如果模型检索 100 份文件，每次都把完整结果送回上下文，再逐条判断日期、去重和求和，成本不仅来自最终推理，还来自大量中间结果不断进入上下文。上下文越长，延迟越高，也越容易被无关细节干扰。

Programmatic Tool Calling 官方文档给出了一条很清楚的边界：当一个阶段有可预测的控制流，而且代码可以把大量结果压缩成更小的结构化输出时，适合使用程序化工具调用；如果每个结果都会改变下一步的语义判断，或者动作涉及审批和外部写入，则应该保留直接工具调用。

可以把常见步骤这样分类：

工作形状 更合适的执行方式 原因
过滤日期、去重、排序、聚合、格式校验 代码或 Programmatic Tool Calling 规则确定，结果可以压缩
根据新证据不断调整检索方向 模型直接调用工具 每一步都需要新的语义判断
修改数据库、发送消息、部署服务 直接调用加审批 需要保留清楚的授权边界
最终引用、原始文档和制品核验 直接读取原生结果 避免中间处理丢失证据

OpenAI 披露的一个金融研究案例中，程序化工具调用在保持评分质量的同时，减少了 21% 的输入 Token。更重要的不是这一个百分比，而是它改变了上下文的用途：模型不再阅读每条机械中间结果，而是只接收代码整理后的证据，再负责判断。

这有点像数据库查询。我们不会把整张表下载到应用层，再让最昂贵的业务逻辑逐行判断；会先用确定性条件筛选、聚合，只把需要决策的数据交给上层。Agent 的上下文窗口也应该被当作昂贵的计算空间，而不是临时垃圾场。

不过，程序化工具调用不是绕过安全检查的后门。官方文档仍要求应用验证每次调用的参数和权限，高影响动作需要应用层审批，重试还应尽可能幂等。代码可以接管数据搬运，不能接管授权责任。

第二层：按风险路由模型，而不是统一降级

把所有步骤从旗舰模型换成便宜模型，也不是正确答案。

抽取字段、判断文档类型、检索候选代码，通常量大、结构相对稳定，可以先用 Luna 或 Terra 等低成本模型，并通过内部评测确认成功率。跨文件架构修改、模糊需求澄清、安全边界判断和最终综合，则更适合保留给能力更强的模型。

一个实用的四层结构是：

层次 典型职责 优化目标
确定性数据层 过滤、聚合、校验、格式转换 减少进入模型的中间数据
高频语义层 分类、抽取、检索和候选排序 用内部评测选择够用的低成本模型
判断控制层 规划、冲突处理、审批建议和最终综合 为真正困难的决定保留强推理
状态记忆层 推理连续性、上下文压缩、缓存 避免重复理解同一背景

模型路由的关键不是预先猜测“这个任务看起来难不难”，而是定义升级条件。例如：低成本模型返回置信度不足、结构化校验失败、涉及高风险文件，或者连续两次尝试仍未通过测试时，再把任务升级给强模型。

团队还必须记录每一层的成功率、Token、延迟、重试和人工接管。否则，“模型路由”很容易变成一串无法验证的提示词分支：账单下降了，却不知道失败是不是被推给了后面的人工审查。

第三层：别让 Agent 每一轮都重新认识世界

成本浪费不只发生在模型选错时，也发生在 Agent 不断忘记自己已经做过什么时。

OpenAI 在 ARC-AGI-3 Harness 实验 中比较了同一个 GPT-5.6 Sol 的两套运行方式。官方 Harness 会在每次行动后丢弃私有推理，并用滚动截断删除较早的历史；Responses API Harness 则保留推理，并在上下文过长时执行 compaction。

结果是：公开任务集上的成绩从 13.3% 提高到 38.3%，输出 Token 约减少六倍。模型没有更换，变化来自它能否记住过去的判断，以及长对话如何被压缩。

这个案例不能直接外推到所有业务任务。ARC-AGI-3 是需要从连续行动中学习规则的二维游戏，天然依赖长期状态。但它非常清楚地证明了一件事：Agent 评测测到的从来不只是模型，也包括状态保存和上下文管理。

Compaction 文档允许系统在上下文超过阈值时生成压缩项、裁剪历史并继续推理。它比简单删除最早消息更合理，因为目标不是保留最多文字，而是保留下一轮仍然需要的计划、发现和约束。

这也呼应了 DeepSeek Harness 文章 讨论的 Harness 层：模型能力要变成长期可用的 Agent，必须有状态、工具、权限和恢复机制。只比较模型名字，会把真正决定成功率的系统设计藏起来。

多 Agent 解决等待时间，不会自动降低成本

当一个任务可以分成几个相互独立的部分，多 Agent 能用更多并行计算换取更短的完成时间。例如同时探索几个代码模块、比较多套方案、分别编写独立测试，最后由主 Agent 汇总。

但“并行”不等于“更省”。OpenAI Multi-agent 文档明确提醒，增加子 Agent 会增加 Token 使用；如果任务依赖单一顺序推理、频繁写同一个可变状态，或者瓶颈本来就是一个很慢的外部操作，多 Agent 未必有收益。

因此，启用子 Agent 前应该回答三个问题：

  1. 子任务是否真的相互独立，而不是每一步都等待上一步结论？
  2. 子 Agent 是否能在各自的有界上下文里工作，最后只返回压缩结果？
  3. 节省的墙钟时间，是否值得额外的 Token、协调和冲突处理成本？

多 Agent 更像给项目增加并行施工队。地基、材料和工作面都能分开时，工期会缩短；如果几队人只能轮流使用同一扇门，增加人数只会增加沟通。

所以，多 Agent 的主要价值应先按延迟和覆盖面验收，而不是默认算作降本手段。

缓存不是一个开关，而是一笔需要复用率的投资

GPT-5.6 还把 Prompt Cache 的默认有效期延长到至少 30 分钟，并支持明确的 cache breakpoint。这对包含长系统提示词、工具定义和工作区说明的 Agent 很有用：相同前缀不需要在短时间内反复按完整价格处理。

但 Prompt Caching 文档给出的价格边界很重要：GPT-5.6 家族的缓存读取按未缓存输入价格的 0.1 倍计费，写入则是 1.25 倍。

按这个费率做一个简化计算：一段稳定前缀只写入一次、没有复用，对这部分 Token 而言反而多花 25%；如果写入后完整复用一次，总计是 1.35 倍，而两次都不缓存是 2 倍。缓存是否划算，取决于相同前缀能否真正复用，而不是配置里有没有打开缓存。

因此需要同时监控 cache_write_tokens 和 cached_tokens。如果前者持续很高、后者很低，通常意味着时间戳、用户输入、工具顺序或其他变化内容被放在了断点之前，系统在不断写新缓存，却没有读到旧缓存。

缓存适合稳定且会重复的背景，不适合给每次都不同的上下文披上一层“优化”外衣。

从一张模型表，升级成一张工作流账单

如果团队准备优化一个已经运行的 Agent，我不会先讨论要不要统一切换 GPT-5.6 Luna、Terra 或 Sol，而会先把一次任务的轨迹拆开。

可以按下面的顺序执行：

  1. 标记工作类型：把每个阶段标成确定性处理、语义判断、外部动作或长期状态；
  2. 先压缩数据：能由代码过滤、聚合、校验的结果，不把完整中间过程送进模型；
  3. 建立模型路由：用真实任务评测低成本模型，并定义升级到强模型的明确条件；
  4. 保留授权边界：外部写入、高风险操作和最终制品核验使用直接调用与人工审批；
  5. 只并行独立工作：按墙钟时间、Token 和冲突率同时评估多 Agent；
  6. 用复用率决定缓存：记录读写 Token，不把缓存命中当作理所当然；
  7. 分别记录结果和过程：除了最终成功率，还记录每一层的成本、延迟、重试与人工接管。

这张账单会告诉团队，钱究竟花在理解问题、搬运数据、重复上下文，还是失败重试上。只有成本能归因到具体阶段，优化才不会退化成“换个便宜模型试试”。

GPT-5.6 让低成本模型更有能力，也提供了推理保留、Compaction、程序化工具调用和原生多 Agent 等新工具。但这些能力不会自动组成一个经济的系统。

真正的变化是，Agent 架构正在从“一颗大脑包办所有工作”，转向一个分层的执行系统：代码处理确定性，便宜模型处理规模，强模型处理判断，状态层负责不再重来。

别让最强模型搬数据。把它留给真正值得思考的事情。

资料与口径