编程式工具调用（Programmatic Tool Calling, PTC）代表了大型语言模型（LLM）与外部工具交互范式的重大转变。在传统的工具调用工作流中，每次调用工具都需要与模型进行完整的回合交互：模型调用工具，接收结果，进行推理，再调用下一个工具。对于涉及多个工具调用的复杂工作流，这会导致延迟和 Token 消耗呈指数级增加，因为每一个中间结果都必须通过模型的上下文窗口进行传递和解析。
PTC 采用了一种全然不同的方法。模型不再一次只编排一个工具调用，而是直接编写代码（通常是 Python），在沙盒执行环境中以编程方式一次性调用多个工具。该代码可以包含循环、条件判断、过滤和聚合逻辑。模型只需采样一次以生成代码，执行环境在后台处理所有的工具调用，最后仅将处理完毕的最终结果返回给模型的上下文。这极大地降低了多工具工作流的延迟和 Token 使用量。PTC 在大规模数据处理、精确数值计算、多步骤流程编排以及敏感隐私数据不应进入模型上下文的场景中尤为有效。
虽然 PTC 最初作为特定厂商的独占特性出现，但其底层模式——模型生成代码、沙盒执行、仅返回最终输出——是模型无关的。在本文中，我们展示了在 Amazon Bedrock 上实现 PTC 的三种方式：第一，基于 ECS 自托管 Docker 沙盒，以获得最大安全控制权；第二，使用 Amazon Bedrock AgentCore 代码解释器（Code Interpreter）的托管解决方案；第三，针对偏好特定开发体验的团队，通过代理实现兼容 Anthropic SDK 的调用路径。
为了直观理解，我们可以对比传统工具调用的瓶颈。假设这样一个查询：“哪些工程团队成员超出了第三季度的差旅预算？”在传统的工具调用中，模型必须经历以下繁琐步骤：首先调用工具获取 20 名团队成员名单；接着为每个人调用工具获取报销记录（共 20 次独立调用，每次返回 50-100 行数据）；然后再调用工具检索预算阈值；最终将超过 2000 条报销记录加载到其上下文窗口中，并在自然语言中对完整数据集进行过滤、对比和总结。每次调用都意味着一次完整的推理周期，20 次顺序调用就会产生 20 次往返，导致极高的 Token 消耗和不可接受的网络延迟。
【AgentUpdate 深度解析】 编程式工具调用（PTC）的兴起，标志着 AI Agent 架构从“反应式编排”向“主动式规划”的跃迁。传统的 ReAct 模式（Reason-Act）受限于大模型本身的序列生成特性，本质上是将 LLM 当作单步状态机，在高并发、多步骤的数据密集型任务中表现极差。而 PTC 通过引入“代码即控制流（Code-as-Control-Flow）”，将复杂的逻辑判断与循环下沉到沙箱执行层，不仅在物理上解决了 Token 膨胀与网络延迟的顽疾，更在逻辑上实现了大模型与传统高效率计算资源的解耦。横向对比来看，这与 OpenAI Code Interpreter 以及 Assistant API 的运行逻辑不谋而合。未来，AI Agent 生态的演进将更加依赖这类“端到端生成、隔离执行”的沙箱基础设施。Amazon Bedrock 提供的三种灵活实现路径，降低了企业落地该技术的门槛，预示着高可靠性、低延迟的企业级 Agent 将进入爆发期。
