GPT-5.6 的 Agent 循环:模型路由和成本控制合并了吗?Chapters1×0:08开场与事件1:43技术背景:循环里最贵的不是一次调用4:13工程意义:模型选择变成反馈控制6:10落地建议:先做三道闸门0:008:160:08主播早上好,这里是 AI Loop Engineering。先交代本期的时间范围:过去二十四小时内,没有出现一条能够独立支撑完整技术拆解的新动态,所以今天回看七月二十九日和三十日,OpenAI 连续发布的两篇 GPT-5.6 文章。它们值得放进 Agent Loop Engineering 里,不是因为又多了一个模型名字,而是因为模型路由、工具循环和成本反馈,开始被放在同一个系统问题里讨论。0:42主播事件先说结论。七月三十日的产品文章宣布,GPT-5.6 Luna 的价格下调百分之八十,Terra 下调百分之二十;Sol 在 API 里增加 Fast mode,速度最高是 Standard 的二点五倍,价格是两倍。OpenAI 给出的工作流例子是:让 Sol 处理不确定性,先定计划;让 Luna 执行已经说清楚的改动、写测试、跑测试,再检查结果。模型不再是整条 Agent 链路里从头用到尾的固定零件。1:15主播同一篇文章还给了 API 价格作为参照:Terra 是每百万输入 token 两美元、输出 token 十二美元;Luna 是输入零点二美元、输出一点二美元。这个价格只说明厂商的定价,不等于你的任务成本。Agent 一次任务会反复进入模型、调用工具、接收结果,再做下一次决定。真正要算的,是每一步在循环里被支付了多少次。1:43主播七月二十九日的工程文章,把这件事说得更具体。OpenAI 描述了一个用 Rust 写的 Agent harness,也就是连接模型、工具和用户环境的编排层。它服务于 Codex 和 ChatGPT Work。一个用户回合可能先读代码,再查部署记录,读取事故报告,改文件,跑测试,最后解释结果。假设这一回合需要三十次模型请求,那么每次请求多花一秒,整条链路就多出半分钟。2:14主播所以,优化 Agent 不能只盯着单次模型的首 token 延迟。要先问三个问题。第一,循环每一步真的需要同样强的模型吗?第二,前面已经看过的上下文,后面是不是又被重复传输和计算?第三,工具返回的内容有没有把模型的注意力和缓存一起挤掉?这三个问题,分别对应模型路由、上下文管理和工具边界。2:43主播OpenAI 公开的第一个做法是延迟发现。工具、MCP 集成、技能和插件,不是全部提前塞进上下文,而是在需要的时候才变得可发现。单个工具的输出默认限制在一万 token,模型可以主动要求别的上限。这个限制不是为了让模型少知道信息,而是让工具输出先经过边界管理,避免一次异常响应把后面几十步都拖贵。3:10主播第二个做法是把模型能看到的历史当成只追加的序列。新消息、工具结果和环境变化只放在末尾,工具也按确定顺序呈现。这样做牺牲了一些随意重排的自由,却保住了前缀的一致性,让提示缓存可以重复利用已经处理过的部分。对 Agent 来说,缓存不是一个打开开关就结束的服务;你的消息结构、工具排序和运行时设置,都在决定缓存能不能命中。3:42主播第三个做法是把模型路由放回任务结构里。Sol、Terra 和 Luna 的分工,不是简单的「大模型处理重要任务,小模型处理不重要任务」。更可执行的划分是:不确定性高、需要规划的步骤,先给更强的模型;目标、接口和验收条件都明确后,把执行、测试和重复性检查交给更便宜、更快的模型。每一步的出口,都要由测试、结构化结果或者下一步的状态检查来定义。4:13主播这几篇文章最值得带走的地方,是 OpenAI 把推理优化称作持续反馈循环:测量生产行为,找到最大的缺口,实施改动,再验证整个系统有没有变好,而不是只看一个局部基准。文章还说,GPT-5.6 Sol 在 Codex 里参与了生产 kernel 的重写和优化,让端到端服务成本下降百分之二十;它设计并运行了数百次实验,改进 draft model,让 token 生成效率提升超过百分之十五。4:47主播这里要把事实和判断分开。百分之二十和百分之十五,都是 OpenAI 在官方工程文章里的自报结果,文章没有给出一套由第三方复现的、跨工作负载的对照实验。因此,我们可以确认它展示了怎样的反馈回路,不能据此确认所有团队换成 GPT-5.6 都会得到同样的收益。循环的形状可以借鉴,收益数字必须回到自己的生产数据里验证。5:15主播这会改变团队的评估对象。以前大家常问:哪个模型在基准上分数最高?Agent 系统更应该问:在一个完整任务里,哪种模型分配能用更少的 token、更少的工具往返和更低的失败重试,达到同一个验收标准?如果只优化单步速度,模型可能更快地走错;如果只追求单步质量,整条链路可能贵到不能上线。5:42主播还有一个容易被忽略的前提:成本和质量的反馈必须落到同一条任务记录上。至少要记录任务类型、每一步使用的模型、输入输出 token、工具调用次数、缓存命中情况、等待时间、重试原因,以及最终是否通过验收。没有这组数据,所谓动态路由通常只是凭感觉换模型,无法知道它是在省钱,还是把成本转移到了失败后的重跑。6:10主播如果今天要把这个思路放进一个真实 Agent,我会先做三道闸门。第一道是路由闸门。把任务按不确定性、错误代价和可验证程度分成几类,明确哪些步骤允许用便宜模型,哪些步骤必须升级到更强模型。不要先写一个复杂路由器,先用固定规则跑出基线。6:34主播第二道是循环闸门。给每一个工具调用设输入大小、输出大小、超时、重试和停止条件。对上下文做按需发现,对消息和工具排序保持稳定。尤其要单独监控缓存命中率,因为 append-only 的历史设计虽然有利于缓存,但上下文会持续增长,最终仍然需要压缩、分段或者重新开始会话。6:59主播第三道是验收闸门。每次调整模型分工,都要在固定回归集和真实采样上同时比较:任务成功率、错误类型、总成本和端到端延迟。模型路由可以逐步灰度,失败时退回上一版规则。涉及写代码、改数据或调用外部系统的 Agent,还要把审批和权限放在模型之外;一个模型更便宜、更快,不会自动获得更大的操作权限。7:26主播本期覆盖的是七月二十九日至三十日的两篇官方文章,适合回答「GPT-5.6 的 Agent 循环设计公开了什么」;它不能替你回答「你的业务换模型后一定省多少钱」,也不能替代对自己任务集、工具失败和权限边界的测试。最后留一个问题:你的 Agent 现在优化的是某一次模型调用,还是一条完整任务从开始到验收的总成本?如果答案只有前者,下一步可能不是换模型,而是先把循环里的重复工作量测出来。这里是 AI Loop Engineering,我们明天见。