文章摘要GPT-5.6正式进入OpenAI API后除了Sol、Terra、Luna三档模型还新增两项值得开发者关注的Agent能力Programmatic Tool Calling允许模型在内存中编写并运行程序协调多个工具和处理中间结果Multi-Agent Beta允许一个请求并发运行多个子Agent并汇总结果。这意味着复杂任务不再只能依赖“模型一次选择一个工具”的串行循环。本文分析这两项能力的架构价值、适用场景、Token与延迟变化、安全边界以及现有Spring AI和MCP项目应该如何抽象。一、传统Tool Calling为什么容易变慢普通Agent工具循环用户任务 → 模型判断 → 调用工具A → 结果返回模型 → 模型判断 → 调用工具B → 结果返回模型 → 模型判断 → 调用工具C → 生成答案假设每次模型调用耗时2秒三个工具就可能产生4次模型调用 3次工具调用问题包括中间结果反复进入上下文每一步都消耗输入和输出Token工具多时Prompt越来越长简单的数据整理也要模型逐步参与串行调用限制总体速度失败后很难从中间步骤恢复。二、Programmatic Tool Calling是什么OpenAI对该能力的描述是模型编写并在内存中运行程序 → 协调工具 → 处理中间结果 → 返回最终需要的信息传统方式中模型需要看到每次工具的完整返回并重新推理。Programmatic Tool Calling更接近模型生成控制程序 → 程序批量调用工具 → 程序过滤和聚合结果 → 只把压缩结果交回模型例如对20个城市查询库存并计算缺货率。传统Agent可能调用20次库存工具 每次结果都进入模型上下文 模型最后计算程序化调用可以results[]forcityincities:stocktools.query_stock(city)results.append({city:city,stock:stock})low_stock[itemforiteminresultsifitem[stock]threshold]return{total:len(results),low_stock:low_stock}模型只需要处理最终结构化结果。三、为什么它可能减少Token普通工具循环会把以下内容反复加入上下文工具Schema 工具参数 工具返回 历史决策 中间解释程序化调用将数据处理留在执行环境中原始工具结果 → 内存程序过滤 → 汇总结果 → 返回模型因此可以减少中间结果Token模型轮次重复工具描述大表格和大JSON传输。但它不是天然更便宜。如果模型生成了复杂程序或程序调用大量高成本工具总费用仍可能上升。必须统计模型Token 工具调用次数 程序执行时间 外部API费用 总任务成本四、为什么它仍然需要工具权限控制“程序由模型生成”不意味着程序可以自由调用任何能力。执行环境必须限制可用工具白名单 每个工具调用次数 参数范围 网络访问 文件访问 CPU与内存 执行时间 并发数否则模型可能生成whileTrue:tools.expensive_search(...)或者在一个任务中调用数千次外部API。推荐执行预算{maxToolCalls:30,maxExecutionSeconds:60,maxExternalCost:1.0,allowedTools:[query_order,search_document]}五、Programmatic Tool Calling适合哪些场景1. 批量查询查询多个客户、订单、城市或文件2. 中间结果计算筛选 排序 聚合 统计 去重3. 多步骤数据转换读取CSV → 清洗 → 计算 → 生成图表4. 大量候选结果过滤检索100条 → 程序筛选20条 → 模型分析5条5. 工具组合固定但参数动态例如财务分析、库存分析、日志诊断。六、哪些场景不适合支付、退款和删除每一步都需要人工审批工具带不可逆副作用业务规则必须强一致程序不能接触敏感数据工具调用必须逐条审计和确认。高风险工具仍应模型提出计划 → 业务系统校验 → 人工确认 → 单独执行不要放进自由生成的内存程序。七、Multi-Agent Beta解决什么问题复杂任务可能包含多个相对独立的工作流市场分析 技术分析 财务分析 风险分析传统单Agent串行完成先市场 → 再技术 → 再财务 → 再风险 → 汇总Multi-Agent允许主Agent拆任务 ├─ 子Agent A市场 ├─ 子Agent B技术 ├─ 子Agent C财务 └─ 子Agent D风险 → 并发执行 → 主Agent综合理论上可以降低墙钟时间并让每个子Agent使用更聚焦的上下文和工具。八、并发子Agent不一定更快实际耗时取决于最慢子任务耗时 任务拆分 结果汇总 工具限流如果四个子Agent都访问同一个限流API并发反而会导致429排队重试成本增加结果不一致。需要设置最大子Agent数 每个Agent的Token预算 工具并发信号量 任务超时 失败策略九、如何选择子Agent模型不要让所有子Agent都使用Sol。示例子任务模型信息提取Luna文档摘要Luna或Terra复杂技术判断Sol价格数据整理Luna最终综合Sol或Terra这种模型分层通常比全程旗舰模型更经济。十、Multi-Agent的结果冲突怎么办不同子Agent可能给出冲突结论。主Agent不能简单投票。每个结果应返回{conclusion:建议采用方案A,evidence:[E1,E3],assumptions:[并发不超过500],confidence:0.78,openQuestions:[数据规模未确认]}综合阶段检查证据冲突 假设冲突 时间版本冲突 权限和数据范围十一、如何避免子Agent无限扩张必须限制递归主Agent可以创建4个子Agent 子Agent不能继续创建子Agent或最大深度2 最大Agent总数8同时设置总Token预算总工具预算总执行时间最大并发终止条件。十二、现有Spring AI项目怎样抽象业务层不要直接绑定OpenAI的具体Multi-Agent接口。定义publicinterfaceTaskOrchestrator{TaskResultexecute(ComplexTasktask,ExecutionBudgetbudget);}实现可以是OpenAI Multi-Agent Spring AI自建并发编排 LangGraph 工作流引擎工具层保持统一publicinterfaceGovernedToolGateway{ToolResultinvoke(StringtoolName,MapString,Objectarguments,ToolExecutionContextcontext);}这样无论模型如何编排权限、幂等和审计都由同一个网关执行。十三、MCP工具如何接入可以形成GPT-5.6 Agent → Programmatic Tool Calling → 企业工具网关 → MCP Client → MCP Server关键是程序化调用层不能绕过MCP工具权限。每次调用仍要携带tenantId userId requestId approvalId idempotencyKey十四、Zero Data Retention兼容意味着什么官方表示Responses API中的Programmatic Tool Calling可以兼容ZDR。这主要说明该能力的中间程序执行可以在不要求平台长期保留请求数据的模式下使用。但企业仍要分别确认外部工具是否保存数据自己的日志是否记录全文MCP Server是否落盘第三方API是否用于训练Trace平台是否收集参数。模型平台ZDR不等于整条工具链ZDR。十五、生产评测应该增加什么Programmatic Tool Calling程序生成成功率 工具调用准确率 工具调用总数 中间数据压缩率 执行超时率 总任务成本Multi-Agent任务拆分质量 子Agent成功率 并发峰值 冲突率 汇总准确率 单任务Token 墙钟时间十六、我的判断这两项能力代表Agent架构从模型逐步调用单个工具转向模型生成执行逻辑 并发子Agent协作它会提高复杂任务的效率但也会放大成本失控并发风险权限绕过工具副作用轨迹审计难度。总结Programmatic Tool Calling适合减少串行工具循环和中间TokenMulti-Agent适合拆分可并行的复杂工作。生产系统仍必须在模型之外建立工具白名单 执行预算 并发限制 幂等 审批 轨迹审计 结果验证Agent越能自主编排控制面就越不能依赖模型自觉。