程序化工具调用（Programmatic Tool Calling, PTC）是大语言模型（LLM）与外部工具交互方式的一次范式转移。在传统的工具调用工作流中，每次工具调用都需要与模型进行一次完整的往返：模型调用工具、接收结果、进行推理、再调用下一个工具，如此循环。对于涉及多次调用的复杂工作流，这会导致延迟堆叠和 Token 消耗剧增，因为每个中间结果都必须经过模型的上下文窗口。
PTC 采取了完全不同的路径。模型不再逐个编排工具调用，而是编写代码（通常是 Python），在沙盒执行环境中以程序化方式调用多个工具。这段代码可以包含循环、条件判断、过滤和聚合逻辑。模型只需进行一次采样生成代码，随后由执行环境处理工具调用，最后仅将处理后的最终结果返回给模型。这种方式极大降低了多工具工作流的延迟和成本。PTC 特别适用于大规模数据处理、精确数值计算、多步骤流程编排以及对隐私敏感的场景（即原始数据不应进入模型上下文的情况）。
虽然 PTC 最初作为特定供应商的功能出现，但其底层模式（模型生成代码、沙盒执行、仅返回最终结果）是跨模型的。在 Amazon Bedrock 上，开发者可以通过三种方式实现 PTC：在 ECS 上部署自托管 Docker 沙盒以获得最大控制权、使用 Amazon Bedrock AgentCore 代码解释器托管方案，或者通过代理层实现与 Anthropic SDK 兼容的路径，以满足不同开发团队的需求。
为了理解传统工具调用的瓶颈，我们可以看一个典型案例：“哪些工程团队成员的 Q3 差旅支出超标了？”
在传统模式下（假设不支持并行函数调用），模型必须：首先调用工具获取 20 名团队成员名单；接着为每位成员调用工具获取报销记录（共 20 次独立调用，每份记录可能包含 50-100 条明细）；随后还要调用工具检索预算阈值。最终，模型上下文窗口需要接收超过 2,000 条报销记录，并在自然语言层面进行过滤、比较和总结。每一次调用都意味着一次完整的模型推理循环，20 次顺序调用意味着 20 次往返，这不仅导致 Token 消耗巨大，更因推理循环的叠加产生了极高的延迟。
