GPT-6 Astra 编程工具调用：何时及为何使用它

传统函数调用会暂停模型，向应用返回工具请求，等待结果后再继续执行。这种循环清晰可控，但当任务需要大量依赖调用、本地过滤或聚合时，效率会变得低下。GPT-6 Astra 程序化工具调用（PTC）允许模型编写一个程序，在单一执行流程中调用符合条件的工具。

变更内容

启用托管的 programmatic_tool_calling 工具，然后使用 allowed_callers 标记符合条件的工具。

const tools = [
  { type: "programmatic_tool_calling" }
  {
    type: "function",
    name: "获取销售数据",
    description: "返回一个区域和一个月的销售记录。",
    allowed_callers: ["程序化的"],
    strict: true,
    parameters: {
      type: "object",
      properties: {
        region: { type: "string" },
        month: { type: "string" }
      },
      必填： ["区域", "月"],
      additionalProperties: false
    }
  }
];

如果allowed_callers被省略或设置为["直接"]，该工具可直接调用。["程序化的"] 将其限制为生成的代码，而 ["直接", "程序化的"]允许两者。这是一个执行策略控制，因此应像审查权限一样审查它，而不是提示措辞。

PTC 支持文档化的工具类，包括函数和自定义工具、MCP、应用补丁、本地或托管 shell 以及代码解释器。支持并不意味着每个工具都应该被暴露。

何时PTC是更优的模式

当模型需要时使用它：

• 获取多个独立记录并进行聚合；
• 根据先前结果调用一个工具；
• 在将大量结果返回给推理上下文之前，先对其进行过滤；
• 比较不同来源的结构化输出；
• 运行一个有界的数据处理循环。

例如，季度分析可能需要调用十二次地区-月份数据，随后进行汇总和异常检测。通过一个程序执行这些调用并返回简洁的摘要，而无需强制进行十二次模型往返。

对于一两个简单操作、高风险写入、每一步都需要明确应用决策的工作流，或必须保持确定性图结构的任务，建议优先使用直接函数调用。PTC 并非自动更便宜：边界设置不当的程序可能会产生过多调用。

结构化输出能改进程序

对于可预测的函数，定义一个 output_schema。实际的 function_call_output.output 仍然是一个 JSON 字符串，但该模式为生成的代码提供了可靠的形状。稳定的类型减少了防御性解析和意外假设。

返回紧凑的数据，例如ID、类型化指标和明确的错误对象。在代码需要数字的地方避免使用文字描述。使分页、最大行数和截断在结果中可见，这样程序就不会将部分数据集误认为是完整的数据集。

工具搜索与延迟加载

工具搜索仍是一项顶级能力。官方指南警告称，延迟加载的工具必须在程序启动前加载完毕，因为运行中的程序无法调用工具搜索。先规划发现，再执行操作。如果目录是动态的，让模型先加载所需的小部分子集，然后再开始PTC。

安全控制

为每个程序设置墙钟时间、调用次数、输出字节数、网络目标地址和成本限制。将工具限制为最小权限，并将机密保存在执行环境中，而不是生成的代码中。

MCP 审批可以暂停程序。在呈现有意义的审批预览时，保留程序状态。对于写入操作，使用幂等键和服务器端授权。即使模型根据可信指令生成了代码，生成的代码也是不可信的。

记录程序哈希或脱敏后的源代码、工具序列、清理后的参数、审批信息、结果、令牌使用情况以及持续时间。避免存储凭据或原始敏感数据。

生产决策框架

提出四个问题：

1. 是否有足够的调用或依赖关系来证明嵌入式程序的合理性？
2. 每个工具都能安全地绑定和类型化吗？
3. 应用程序是否适合委托中间控制？
4. 审批或部分失败后，工作流能否恢复？

如果任何答案为“否”，则将编排保留在应用程序代码中。对于固定管道，您拥有的确定性代码通常是正确的选择。

成本与正确性实验

将PTC与使用相同任务的传统循环进行基准测试。包括一个单次调用的小型案例、一个依赖五次调用的案例，以及一个大型聚合案例。测量总令牌数、工具调用次数、墙钟时间、失败率以及计算结果的正確性。一个更快但静默丢弃分页记录的答案并不是改进。

强制部分失败：一个区域超时，一个结果违反其输出模式，一个MCP操作请求批准，一个数据集为空。生成的程序应保留哪些输入成功，避免将缺失视为零，并返回足够详细的信息，以便模型解释限制。

在基础设施限制之下设置硬性限制，以便程序可预测地失败。清晰的 CALL_BUDGET_EXCEEDED 结果比容器被终止更容易恢复。对于分析型工作负载，在确定性代码中独立重新计算输出样本。对于任何财务或合规结果，优先选择经过验证的计算，而不是盲目信任生成的聚合结果。

这个实验往往揭示了一种混合设计：使用PTC进行重度读取探索，而将最终写入或受控计算交由应用自有代码处理。混合编排是一种优势，而非未能全面采用最新功能的表现。

常见问题解答

PTC 与多智能体相同吗？

不。PTC执行一个工具调用程序。多智能体将有限的工作委托给拥有各自上下文的子智能体。

PTC 能否调用需要审批的 MCP 工具？

是的。审批可以暂停程序。您的应用程序必须保持状态并安全继续。

PTC 会移除函数模式吗？

不。强输入和输出契约变得更加重要，因为生成的代码会使用它们。

每个工具是否都应支持两种调用者模式？

不。仅允许工作流所需的模式，特别是针对敏感工具。

结论

当工具编排本身成为瓶颈时（涉及大量调用、依赖关系、过滤和聚合），程序化工具调用便具有重要价值。应选择性使用，在执行前延迟加载工具，定义结构化输出，并严格执行资源和权限限制。对于简短或高风险的工作流，传统的应用控制循环仍更易于审计。