还在无脑堆最贵模型？OpenAI 这篇实战指南拆穿了智能体开发的“伪努力”
在过去很长一段时间里，构建长程 AI Agent（智能体）有一条心照不宣的“万能公式”：只要任务一复杂、步骤一变长，开发者就会毫不犹豫地换上当前参数最大、单价最贵的旗舰模型，并把推理力度（Reasoning Effort）直接拉满。如果任务还是失败了，大家往往会归咎于“大模型现在的智力上限还不够”。
但 OpenAI 最近发布的《The builder’s guide to GPT‑5.6》（GPT-5.6 开发者实战指南），用一系列来自真实生产环境的硬核数据，直接打破了这种惯性思维。
在这份由 OpenAI API 平台团队与多家一线创业公司联合总结的指南中，出现了一组极其反直觉的对照： 在长程网络检索基准 BrowseComp 上，三个月前用 GPT-5.5 旗舰模型跑一次评测需要花费 $33.27，得分 84.36%；而如今换用轻量级的 GPT-5.6 Luna 模型，在相同评测中跑出了 84.04% 的同等表现，成本却暴降到了 $1.33——降幅超过 96%。 更惊人的是在考验通用适应能力的 ARC-AGI-3 基准测试中，GPT-5.6 Sol 在标准通用脚手架下只拿到了 13.3% 的及格边缘分数；但在完全不改动模型权重、仅仅在 API 层面开启“持久化推理”（Retained Reasoning）和“原生压实”（Compaction）两项配置后，得分直接跃升近 3 倍达到 38.3%，同时消耗的输出 Token 减少了整整 6 倍。
这篇指南向所有智能体开发者释放了一个极为明确的信号：构建实用 Agent 的真正瓶颈，往往不是模型的基础智力，而是我们对待算力、状态与工具调用的工程架构。
别再把“加钱上顶配”当成架构解法：模型分层的经济学算盘
Section titled “别再把“加钱上顶配”当成架构解法：模型分层的经济学算盘”在真实的工业级业务中，任何脱离单任务商业价值（Unit Economics）去谈 Agent 落地都是不切实际的。很多团队在原型阶段能跑通 Demo，一旦进入高并发生产环境，API 账单就会迅速失控，最终被迫下线功能。
指南指出，GPT-5.6 家族明确划分为三级梯队：主打超复杂逻辑与代码架构的旗舰 Sol、承接日常主力业务的平衡型 Terra，以及专为高吞吐、低延迟和子任务并行设计的轻量级 Luna。
从官方公布的 API 成本与综合能力得分散点数据中，我们可以清晰地看到算力分层的威力： 以往大家普遍认为轻量模型只能做简单分类，无法处理复杂的工具调用与长上下文。但在引入更充分的测试时计算（Test-Time Compute）后，轻量模型展现出了惊人的性价比跨越。
例如开源浏览器自动化项目 Browser Use 在评测 106 个高难度浏览器任务时发现，使用 Luna 仅耗费了大约 $14 就完成了 78% 的任务；而当时行业内顶尖的 SOTA 旗舰模型虽然达到了 80% 的完成率，花费却高达 $235。二者完成率相差无几，成本却相差近 17 倍。
类似的情况也发生在文档智能创业公司 Hypha。他们在处理非结构化文档提取时，用 Luna 替代了前代主力模型，以仅 1/18 的成本保留了 98% 的提取准确率。而在代码检索与决策建模工具 PlayerZero 的实际工作流中，切换到 Luna 让整体推理成本直降 64%，响应时间缩短了 90%，F1 分数反而提升了 5 个百分点。
这给我们的首要启示是：不要让昂贵的旗舰模型去干数据搬运和基础清洗的体力活。 在多步骤的工作流中，先用轻量模型做海量初筛和步骤拆解，只在最关键的收敛节点引入旗舰模型，才是保证系统具备长期商业生命力的底层基础。
彻底告别“乒乓球循环”：Programmatic Tool Calling 如何解放大模型？
Section titled “彻底告别“乒乓球循环”：Programmatic Tool Calling 如何解放大模型？”如果说模型分层解决的是“买哪种算力”的问题，那么 Programmatic Tool Calling（程序化工具调用） 解决的就是“算力如何高效工作”的根本矛盾。
在传统的 Function Calling 模式下，智能体与环境的交互本质上是一场漫长的“乒乓球循环”（Ping-Pong Loop）： 模型在第一轮输出工具调用参数 -> 客户端捕获后执行本地工具 -> 客户端把执行结果序列化后塞进 Prompt 再次请求 -> 模型读取上一轮结果，思考后再决定是否发起下一次工具调用……
当任务需要拉取 100 份财报、按日期筛选关键指标并做跨表汇总时，这种机制会带来灾难性的后果：
- 上下文严重污染（Context Rot）：上百次网络往返返回的庞大中间数据，全部被迫挤在大模型的上下文窗口里，模型很容易在海量无关信息中迷失重点。
- 极高的网络延迟与 Token 浪费：每一次中间来回都在重复消耗输入 Token，导致整体耗时成倍增加。
OpenAI 在 Responses API 中给出的解法极其干脆：允许大模型直接编写 JavaScript 代码，在云端隔离的沙箱（V8 Runtime）中批量调度工具。
在这个新架构下，大模型不再亲自处理每一个工具的中间返回值。它可以写一个简单的循环或使用 Promise.all 并发拉取 100 份文件，用代码完成数据过滤、排序和格式转换，最后仅仅把提炼好的结构化结果回传给模型上下文。
金融智能分析平台 Rogo 在实测后表示，使用 Programmatic Tool Calling 的 GPT-5.6 在保持相同分析质量的前提下，直接减少了 21% 的输入 Token。这就是“只能聊金融的聊天机器人”与“真正能在生产环境中跑研报的实用 Agent”之间的本质区别。
从计算机体系结构的角度来看，这就像早期的计算机 CPU 必须亲自处理每一次外设 I/O 读写，后来演进出了 DMA（Direct Memory Access，直接内存访问） 机制——CPU 只负责下达搬运指令，数据传输由专用控制器在后台搞定，完成后发送中断信号即可。Programmatic Tool Calling 正是智能体领域的 DMA：让代码负责搬运与清洗，让模型专心负责推理与裁判。
ARC-AGI-3 分数翻三倍的秘密：不是模型变聪明了，是脚手架终于不删记忆了
Section titled “ARC-AGI-3 分数翻三倍的秘密：不是模型变聪明了，是脚手架终于不删记忆了”在探讨模型能力时，我们常常陷入对基准跑分的盲目崇拜。但 OpenAI 在 ARC-AGI-3 上的实验，给整个评测圈敲了一记警钟。
ARC-AGI-3 是一个旨在测试 AI 探索陌生环境、归纳底层规则的 2D 解谜基准。在此前公开发布的测试中，GPT-5.6 Sol 的得分只有 13.3%，而 GPT-5.5 甚至只有 0.4%。当时很多人下结论：大模型根本不具备人类级别的空间归纳与自主学习能力。
但深入排查后，OpenAI 发现了两处致命的评测脚手架设计缺陷： 第一，官方 Harness 在模型每次做出动作后，都会把模型刚才的私有思考过程（Private Reasoning Tokens）全部抹去，只留下一条简略的动作记录； 第二，官方 Harness 采用了粗暴的滑动窗口截断（Rolling Truncation），当历史记录超过 17.5 万字符时，最前面的所有记忆会被直接扔掉。
这意味着模型在每一次行动时，都面临着“记忆被瞬间重置”的残酷处境：它既看不到自己之前为什么要做这个决策，也丢掉了最开始探索到的底层物理规则，每一步都必须强行从零重新理解世界。
当 OpenAI 将 Harness 切换为 Responses API 原生支持的两项功能后，奇迹发生了：
- Retained Reasoning（持久化推理）：通过传递
previous_response_id，模型上一轮的私有思考状态得以完整保留，模型不再需要每轮重新做一遍全盘推演； - Native Compaction（原生上下文压实）：在上下文接近阈值时，由系统进行语义级的浓缩提炼，而不是直接切掉旧记录。
结果是，GPT-5.6 Sol 的得分瞬间从 13.3% 暴涨至 38.3%（人类平均测试者水平约为 48%），且消耗的输出 Token 降低了整整 6 倍。
正如我们在之前的文章《Not the Model, You’re the Harness》中所探讨的：很多时候不是模型不行，而是你的 Harness（脚手架）强行把模型废掉了。 与 Anthropic 在长程智能体研究中强调的上下文交接制度一样（参见《Anthropic 这篇长跑 Agent harness 文章，讲透了交接制度》），如何在长周期任务中保证状态的连续传递与记忆压实，已经成为衡量一个 Agent 系统是否合格的核心指标。
生产级智能体的三项自查：从 Chat 玩具走向工业化系统
Section titled “生产级智能体的三项自查：从 Chat 玩具走向工业化系统”读完这份指南，任何正在开发生产级 AI 应用的工程团队，都应该停下来反思自己的架构设计。如果你的智能体还在频繁出现延迟过高、账单爆表或长任务中途跑偏，建议立刻进行以下三项“架构排毒”自查：
- 清查你的工具调用链路：是否还在用客户端不断循环调用单次 API？如果有高频的数据抓取、列表过滤和汇总计算，应尽早改造为沙箱内的程序化执行（如 Programmatic Tool Calling 或本地容器批量脚本），坚决把中间垃圾数据挡在模型上下文之外。
- 清查你的模型选型配比：是否整个系统从前到后只配了一个昂贵的旗舰模型？尝试将初期的信息提取、多源搜索和格式清洗剥离出来，交给 Luna 或 Terra 级别的轻量模型；旗舰模型只用于顶层规划与最终结果核验。
- 清查你的长程状态管理：在多轮交互中，你是在机械地拼接
messages数组，还是建立了完善的状态压实与思考流保持机制？对于长程探索任务，粗暴的滑动截断只会让你的智能体在执行到后半段时彻底沦为“无头苍蝇”。
智能体开发的下半场，已经不再是比拼谁能写出更华丽的 Prompt，而是比拼谁能用精密的系统工程，将每一分算力发挥到极致。
{你目前的智能体开发中，是否也遇到过上下文膨胀或推理账单失控的问题？你又是如何做模型分层与状态治理的？欢迎在评论区分享你的实战经验。}
- The builder’s guide to GPT‑5.6
- Advancing the price-performance frontier with GPT-5.6
- How enabling two settings tripled our scores on the ARC-AGI-3 benchmark
- Responses API Announcement & Architecture
- Programmatic Tool Calling Guide — OpenAI Developers
- Responses Multi-Agent Documentation — OpenAI Developers