GPT-5.6 API新增Programmatic Tool Calling与Multi-Agent:Agent架构会发生什么变化?
文章摘要
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 = []
for city in cities:
stock = tools.query_stock(city)
results.append({
"city": city,
"stock": stock
})
low_stock = [
item for item in results
if item["stock"] arguments,
ToolExecutionContext context
);
}
这样无论模型如何编排,权限、幂等和审计都由同一个网关执行。
十三、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适合减少串行工具循环和中间Token,Multi-Agent适合拆分可并行的复杂工作。
生产系统仍必须在模型之外建立:
工具白名单
+执行预算
+并发限制
+幂等
+审批
+轨迹审计
+结果验证
Agent越能自主编排,控制面就越不能依赖模型自觉。
延伸阅读
如果你正在关注企业级 AI 应用、Spring AI、RAG、Agent 与 MCP 工程化落地,欢迎访问 智元界:
https://www.zyentor.com/
智元界将持续分享可运行的技术实战、架构设计、问题排查与企业应用案例。