摘要GPT-5.6 发布了所有人都在看 benchmark 分数。但真正值得关注的藏在一个 API 参数里——Programmatic Tool Calling。它让模型不再傻乎乎地一次调一个工具而是直接写段代码把所有工具编排好。效果有客户 Token 直接砍掉 63.5%。这篇文章用代码把原理讲透。传统的 Tool Calling 为什么低效如果你用过 GPT 的 Function Calling 或 Claude 的 Tool Use你一定见过这个模式用户: 帮我查一下这 5 只股票今天的价格按涨跌幅排序 模型 → 调用 get_stock_price(AAPL) 你/框架 → 返回 {price: 198.32, change: 1.2%} 模型 → 调用 get_stock_price(GOOGL) 你/框架 → 返回 {price: 152.17, change: -0.8%} 模型 → 调用 get_stock_price(MSFT) 你/框架 → 返回 {price: 431.55, change: 2.1%} ...反复 5 次 模型 → 终于整理好结果回复用户这就是传统 Tool Calling 的乒乓问题每调用一次工具模型就要输出一次思考 一次函数调用每一次工具返回的完整数据都灌回模型哪怕只需要其中 10% 的字段往返次数 工具调用次数线性增长模型看不到全局每次决策只能基于当前这一步的结果用开发者熟悉的类比这就像你写了一个 API 聚合层但没有在后端做 join而是让前端发了 5 个 HTTP 请求然后自己拼数据。能工作但谁都看得出来这不是最优方案。Programmatic Tool Calling 做了什么用一句话概括GPT-5.6 不再一个一个调用工具而是写一段 JavaScript 程序来编排所有工具调用。具体来说当启用 Programmatic Tool Calling 后模型会生成一段轻量级的 JavaScript 代码这段代码在 OpenAI 的隔离 V8 沙箱中运行能够并行调用多个工具而不是串行在沙箱内做数据过滤、去重、聚合、排序——只有精简后的结果返回给模型使用条件分支如果工具 A 返回 X则调 B否则调 C做错误处理和重试不需要模型来感知和决策循环处理分页数据自动合并所有页的结果用同一段伪代码来对比传统方式模型 框架的循环模型: call get_stock_price(AAPL) 框架: return result 模型: call get_stock_price(GOOGL) 框架: return result ...N 次往返 模型: 整理结果Programmatic Tool Calling 方式// 这段代码由 GPT-5.6 自动生成在沙箱中执行constsymbols[AAPL,GOOGL,MSFT,AMZN,META];constresultsawaitPromise.all(symbols.map(stools.get_stock_price(s)));// 只保留需要的字段constfilteredresults.map(r({symbol:r.symbol,price:r.price,change:r.change_pct}));// 按涨跌幅排序filtered.sort((a,b)b.change-a.change);returnfiltered;// 只返回这 5 行精简数据给模型关键区别5 次模型往返变成 1 次。5 份完整工具响应变成 1 份精简结果。它不是 Agent它是工具的指挥程序这里有一个重要的概念澄清避免混淆概念是什么谁在决策代码在哪跑Programmatic Tool Calling模型写一段 JS 程序程序负责决定调哪些工具、怎么处理返回数据模型写程序程序执行确定性逻辑OpenAI 的隔离 V8 沙箱Multi-Agent / Ultra多个模型实例并行工作各自思考和调用工具每个 agent各自推理和决策OpenAI 的推理基础设施传统 Tool Calling模型自己决定每一步调什么人的框架负责执行模型每一步都在决策你的服务器Programmatic Tool Calling 的精妙之处在于它把编排逻辑从模型推理变成了程序执行。编排逻辑调哪个、调几个、怎么合并、去重、排序本质上不需要语言模型来思考——它是确定性的。让模型来执行编排是浪费推理能力。模型只应该在需要判断的地方出现比如用户到底想要什么和最终结果该怎么呈现。这其实是一种reasoning-to-code 的模式模型把对任务的理解转化为一段可执行代码代码承载编排逻辑模型只负责理解和表达。实际效果数据不会说谎OpenAI 官方公布了几组来自预览客户的实测数据不是实验室 benchmark而是生产环境的真实对比客户场景Token 减少其他指标PlayCoUnity 场景构建-63.5%模型往返次数 -50.1%Clio多步骤法律文档分析prompt token-38%质量无损失Rogo金融研究输出 token-24%任务完成速度28%Lovable生产级应用构建—步骤数 -25%工具调用 -35~48%ModelML20 个客户工作流数百份 PPT-39% vs Fable 5输出更精致、图表更准确这些数字的意义在于它不是便宜了一点点而是架构层面的效率跃迁。63.5% 的 token 减少不是在 prompt 上做优化——是模型从根本上不需要那么多往返了。更关键的是减少的是 output token。Output token 的价格通常是 input token 的 3-5 倍GPT-5.6 Sol 的 output token 是 $30/1Minput 是 $5/1M。所以减少 output token 对成本的影响远大于同等比例的 input token 减少。什么时候该用它什么时候不该不是所有场景都适合 Programmatic Tool Calling。根据 OpenAI 的官方指南和实际场景分析✅ 应该用的场景搜索结果需要过滤、去重、排序、合并比如上面股票的例子多个数据源的结果需要组合先查 CRM 再查工单系统合并成一份客户画像分页数据需要全部拉取然后聚合“遍历最近 30 天的所有订单计算各品类的总销售额”工具之间有确定的依赖关系“先查用户 ID再用 ID 查订单再用订单 ID 查物流”——这三个调用是链式的不需要模型在每个环节思考需要在数据层面做大量清洗API 返回了 50 个字段但你只需要 3 个❌ 不该用的场景单次查询/单次操作搜索 X然后直接返回——程序的开销比直接调用还大写操作涉及权限边界——让程序自动执行写操作有审计和安全风险需要保留原生引用/标注如搜索引文的原始链接和格式每一步的结果需要模型理解和判断才能决定下一步这种情况下模型推理是有价值的不是在浪费对开发者的影响短期成本直接下降如果你的应用大量使用 Tool Calling比如 RAG 搜索、多数据源聚合、链式 API 调用迁移到 GPT-5.6 Programmatic Tool Calling 可能让你的 token 成本下降 30-60%。不需要改架构只需要在 Responses API 中切换模式。中期应用架构在变Programmatic Tool Calling 意味着编排逻辑从应用层下沉到模型层。以前你需要自己写后端代码来处理并行调三个 API → 合并去重 → 排序 → 返回这个流程现在你可以让模型生成的程序来干这件事。这会让一些薄的 AI 应用变得更薄——你的后端不再需要那么多编排代码。但也意味着你需要想清楚哪些编排逻辑应该留在你的代码里因为你需要审计、控制、或复用哪些可以安全地交给模型的程序。长期Tool Calling 的范式可能在变如果 Programmatic Tool Calling 成为标准Anthropic 和 Google 大概率会跟进那么“模型调用工具的模式就从对话式变成了编程式”。模型不再是一个使用工具的对话者而是一个写程序来使用工具的开发者。这可能比 GPT-5.6 的 benchmark 分数本身更值得关注。分数会更新价格会变化但范式的改变会影响你接下来怎么写代码、怎么设计系统。总结GPT-5.6 的发布被大多数报道概括为分数更高、价格更低、三档模型。但如果只看到这些你错过了一个可能更重要的事情Programmatic Tool Calling 代表了一种思路转变——让模型用代码而不是对话来编排工具。这解决的不是模型不够聪明的问题而是让聪明的东西不要再干笨活的问题。对于 CSDN 的开发者读者来说这句话可能是这篇文章最值得带走的东西。