Programmatic Tool Calling（程序化工具调用）

Programmatic Tool Calling（程序化工具调用） 是 Responses API（响应 API）的托管工具能力：模型生成 JavaScript 程序来编排当前请求中允许的工具调用。程序可以并行调用工具、使用循环和条件，并在托管运行时保留中间结果，最后只把压缩后的结果交还模型；它解决的是工具密集型工作中“每一项中间结果都回灌到模型上下文”的成本与延迟问题。

它不是让模型获得任意代码执行权限。每段程序运行在全新、隔离的 V8 runtime 中，支持 JavaScript 和顶层 await，但没有 Node.js、安装包、直接网络、通用文件系统、子进程或跨程序的持久状态；对外只能使用本次请求显式开放的工具。客户端自有函数仍由应用执行，应用不运行模型生成的 JavaScript。

适用边界

适合交给程序的阶段有明确数据流：并行查询后过滤、关联、去重、排序、聚合或校验；或后续调用的参数可由前一调用的结构化结果确定。此时程序先缩减结果，再让模型做最终解释，可少占上下文、少一次或多次模型往返。

不应把它当作默认的工具调用方式。单次查询、每个观察都需要模型重新作语义判断的搜索、需要审批的写入动作、以及依赖原生引用或工件逐项核验的任务，默认仍应使用直接工具调用。这个边界把“确定性数据处理”留给程序，把“判断、授权、最终验证”留在模型与 Agent Guardrails（Agent 护栏）可见的主流程。

“调用很多次”“可以并行”或“前后调用有依赖”本身都不足以选择 PTC。真正的判据是：中间阶段能否被限定成确定性的记录缩减，并用紧凑 schema 交还主流程。给模型的规则应明确该阶段、允许调用的只读工具、输出 schema、重试上限、停止条件，以及何时交还直接模型判断；若一个工作流混用两种路由，还要设置唯一交接点，避免切换后重复已经完成的工作。

配置与可观测性

请求需要加入 type: "programmatic_tool_calling"，再通过各工具的 allowed_callers 决定只能直接调用、只能由程序调用，或两者均可。支持的可编排工具包括 function、custom、MCP、apply patch、local/hosted shell 与 code interpreter；MCP 的 require_approval 仍可暂停程序，审批边界不会因此消失。

响应仍是标准 Responses object：program 记录生成的 JavaScript，嵌套的 function_call 带有对所属 program 的引用，program_output 给出最终结果及 completed / incomplete 状态。harness 应保留这些输出项及调用关系，才能追踪、重放并审计一次程序化编排。

program_output 与最终 assistant message 是两份不同输出。程序可能已经返回正确记录，但最终消息遗漏字段、引用或 caveat，因此评估不能只检查程序结果。应在同一批代表性任务上比较直接调用与 PTC，先确认最终回答仍通过既有 Evals（评估），再比较总 token、延迟、费用、调用次数、turn 和重试；质量没有保持时，资源下降不算优化成功。

该能力可支持 Zero Data Retention工作流，而无需持久代码执行容器；但组织或项目必须已开通 ZDR，store: false 本身不等于启用 ZDR，且最终资格仍取决于所选模型、工具和第三方服务。

与 GPT-5.6 的关系

GPT-5.6的发布将 Programmatic Tool Calling 作为减少工具密集任务 token 与模型轮次的能力之一；该系列也可在 Responses API 的 multi-agent beta 中并行运行 subagent。两者可以组合，但分工不同：前者在一个可预测阶段内由程序编排工具，后者在需要独立推理与结果汇总时并行多个 Subagent（子智能体）。

Programmatic Tool Calling（程序化工具调用）

适用边界

配置与可观测性

与 GPT-5.6 的关系

相关概念