OpenAI 在 8 月 13 日发布 GPT-5.6 构建者指南。它没有只讲模型分数，更多篇幅留给了做 Agent 时最烧钱、也最容易返工的几件事：模型怎么分工，长任务的上下文怎么续，工具返回的一堆数据谁来处理。
这对正在把 AI 接进工作流的人更有用。很多团队的默认动作还是“难题全丢给最强模型”，然后看着账单和等待时间一起往上走。模型能力在涨，但流程没有跟着拆，钱就会花在本可以交给代码的步骤上。
先按任务给模型分工
指南建议把高频、延迟敏感或重复的步骤交给成本更低的模型，把真正需要判断的部分留给能力更强的模型。比如先抽取文档字段、筛选候选结果，再让较强模型判断例外和结论。
这件事听起来很工程化，实际是每个 Agent 都绕不开的成本题。一个流程里如果有十步，未必十步都需要同样的推理强度。先把任务拆开，才能知道哪一步是在花钱解决问题，哪一步只是把数据搬来搬去。
长任务别把上下文当一次性消耗品
OpenAI 还把保留推理和上下文压缩放进了 API 的使用建议里。它们要解决的是同一个现场：任务跑得越久，模型越容易重复读取旧信息，或者被堆积的中间结果挤满上下文。
官方在 ARC-AGI-3 的一次测试中给出过一个对比：标准 harness 下，GPT-5.6 Sol 得分为 13.3%；启用保留推理和压缩后为 38.3%，同时输出 token 约少六倍。这个数字不能直接当作自己项目的效果承诺，但它提醒了一件很具体的事：长任务的效果，很大一部分取决于你怎么保存和整理过程，而不只取决于模型名称。
能确定的活，尽量让代码接手
指南提到程序化工具调用：Agent 可以让代码去过滤、聚合和整理工具返回的结果，再把需要判断的部分交回模型。读取一批文件、按日期筛选记录、合并表格，这些步骤如果全塞进模型上下文，既慢，也容易把真正要判断的问题淹掉。
做工作流时可以先问一句：这一步是在判断，还是在搬运？前者适合留给模型，后者通常应该写进代码或工具层。把这条线划清楚，Agent 才不会每次都从头背一遍材料。
今天可以带走什么
挑一个正在运行的 AI 流程，列出它的每一步，再标三个字段：
- 这一步是否真的需要模型判断？
- 它是否反复读取同一批上下文？
- 能否用脚本、筛选规则或工具调用替代？
先把一两步搬出模型上下文，通常比急着换一个更强的模型更值得试。