文章总结： ProgrammaticToolCalling(PTC)是一种重新划分模型、上下文与执行边界的架构范式，解决了传统工具调用在复杂任务中遇到的token成本上升、上下文膨胀和模型行为不稳定等问题。PTC的核心思想是让模型生成可执行程序，而不是在上下文中边想边执行，这样可以有效节省token成本，提高系统的稳定性和可维护性。当系统需要处理复杂工作流、批量操作或重试逻辑时，PTC成为架构必需，而非优化选项。 综合评分： 91 文章分类： AI安全,安全开发,安全工具,安全建设,技术标准

理解真正的Programmatic Tool Calling

原创

rayh4c

先进攻防

2025年12月17日 17:10 北京

理解真正的Programmatic Tool Calling

为什么“模型会用工具”，自动化却依然难以规模化

在过去几年里，随着大语言模型逐步具备稳定的工具调用能力，“智能体（Agent）”开始从概念走向工程现实。模型可以调用搜索引擎、数据库、代码扫描器、CI/CD 系统，甚至直接驱动业务 API，看起来已经具备了端到端自动化的基本条件。

但在真实系统中，很多团队很快遇到同一个问题：模型确实能调用工具，但系统却很难稳定、低成本、可预测地自动运行。

token 成本迅速上升、上下文频繁膨胀、复杂任务下模型行为变得不稳定，甚至简单的分页、重试、条件判断，都需要在 prompt 里反复教模型怎么做。这并不是模型能力不足，而是一个更深层的结构性问题——我们把执行系统的职责，错误地放进了模型上下文里。

Programmatic Tool Calling（PTC）正是在这种背景下出现的。它并不是“更高级的工具调用”，而是一种重新划分模型、上下文与执行边界的架构范式。

一、工具调用的自然演进，以及它不可避免的极限

早期的工具调用机制非常直接：模型输出结构化参数，系统调用对应函数，再把结果返回给模型。这种方式在单步或少量步骤的任务中表现良好，例如一次搜索、一次数据库查询、一次计算。

但随着任务复杂度上升，问题逐渐显现。

当一个任务需要：

• • 多步骤顺序执行
• • 分页或批量处理
• • 条件分支与失败重试
• • 多工具协作

模型就不仅要“决定做什么”，还要在上下文中记住执行到了哪一步。于是 prompt 变长、上下文变乱，模型开始用自然语言模拟循环、变量和状态机。

从工程角度看，这其实是一种隐式编程：逻辑存在，但不是以代码形式存在，而是散落在 prompt 和上下文中，既难调试，也难复用。

PTC 的出现，本质上是对这种隐式执行方式的一次纠偏。

二、执行日志被错误当成上下文

在传统工具调用模式中，上下文承担了两个角色：

• • 模型推理的语义空间
• • 执行过程的状态存储

这两个角色在简单场景下并不冲突，但在复杂任务中会迅速产生张力。

常规 Tool Calling 流程

【用户请求】
      ↓
【模型推理】
  · 决定调用哪个工具
      ↓
【工具调用 A】
      ↓
【工具返回结果 A】
  · 结果写入上下文
      ↓
【模型再次推理】
  · 阅读 A 的结果
  · 决定下一步
      ↓
【工具调用 B】
      ↓
【工具返回结果 B】
  · 再次写入上下文
      ↓
【模型再次推理】
      ↓
【最终输出】

在这个流程中，每一步工具返回的数据都会进入上下文，无论这些数据是否对最终结果有价值。

分页查询时，上下文中堆满分页数据； 日志分析时，大量原始日志直接进入上下文； 多分支决策时，未走的路径也以解释性文本残留。

结果是：上下文逐渐变成一份不断增长的执行日志。

三、显式引入“执行层”

Programmatic Tool Calling 的核心思想非常简单，但影响深远：

让模型写“如何执行”的程序，而不是让模型在上下文中“边想边执行”。

在 PTC 模式下，模型只在两个关键时刻参与：

1. 1. 根据用户目标，生成一段可执行程序（通常是 Python）
2. 2. 读取程序执行完成后返回的最终结果，生成自然语言输出

真正的执行发生在一个受控的程序执行环境Program Context中。

Programmatic Tool Calling 流程

【用户请求】
      ↓
【模型推理】
  · 理解目标
  · 生成执行程序（代码）
      ↓
━━━━━━━━━━━━━━━━━━
【程序执行环境（Program Context）】
  · 循环 / 条件 / 状态
  · 多次调用工具
  · 聚合 / 过滤 / 重试
━━━━━━━━━━━━━━━━━━
      ↓
【程序返回最终结果】
      ↓
【模型生成自然语言输出】

关键变化在于：工具调用的中间结果不再自动进入模型上下文。

上下文从“接口边界”蜕变为“执行载体”。

四、为什么 PTC 能系统性节省 token

在常规工具调用中，token 成本几乎与执行步骤成正比：

• • 每一次工具调用
• • 每一次中间结果返回
• • 每一次模型重新推理

都会产生 token 消耗。

而在 PTC 中，token 成本被重构为：

• • 一次生成和执行程序的成本
• • 一次读取最终结果的成本

无论程序内部执行了多少次循环、调用了多少次工具，这些执行过程都不会体现在上下文中。

上下文对比（理解 token 节省的关键）

传统模式：

上下文内容：
[ 用户请求 ]
[ 工具 A 返回数据 ]
[ 中间判断说明 ]
[ 工具 B 返回数据 ]
[ 分页结果 ]
[ 再次判断说明 ]
...

PTC 模式：

上下文内容：
[ 用户请求 ]
[ 生成工具调用代码 +  程序执行最终返回结果 ]

PTC 的本质，不是模型更聪明，而是给上下文加了一道闸门。

五、工程示例一：分页与批量查询

在分页场景中，PTC 的优势最直观。

传统方式：

• • 模型请求第 1 页 → 读结果
• • 模型请求第 2 页 → 读结果
• • 模型在上下文中维护页码与状态

PTC 方式：

page = 1
results = []

while True:
    res = search_api(query=q, page=page)
    results.extend(res["items"])
    if not res["has_more"]:
        break
    page += 1

return summarize(results)

分页逻辑在模型生成的工具调用代码中完成，模型只看到最终摘要。

六、工程示例二：日志与安全分析

日志分析是工具调用最容易失控的场景之一。

传统方式：

• • 拉取大量日志
• • 日志直接进入上下文
• • 模型在 token 中“做 grep”

PTC 方式：

logs = fetch_logs("service-x", last="24h")
errors = [l for l in logs if "ERROR" in l]
return aggregate(errors)

模型不再处理原始日志，由生成的工具调用程序处理，最终解释已计算的结果。

七、工程示例三：多工具编排与失败重试

在复杂工作流中，失败和重试几乎不可避免。

传统方式：

• • 模型在上下文中描述失败
• • 记录重试次数
• • 决定是否继续

PTC 方式：

for _ in range(3):
    try:
        return tool_a()
    except:
        continue
raise RuntimeError("failed")

天然的，复杂冗余的错误重试逻辑应该是程序行为，而不是语言推理行为。

八、什么时候应该采用 Programmatic Tool Calling

在工程实践中，PTC 的引入往往有清晰信号：

• • prompt 开始像伪程序代码
• • 中间数据远大于最终输出
• • 工作流存在越来越复杂的循环、条件、批量或重试
• • token 成本成为主要调优目标
• • 系统需要可调试、可复现的行为

当这些信号出现时，PTC 不再是优化选项，而是架构必需。

总结：Programmatic Tool Calling 将是智能体未来的架构分水岭

Programmatic Tool Calling 并不是“更复杂的工具调用”，而是一次职责重划：

• • 工具调用：模型在上下文中既思考又执行
• • PTC：模型负责规划与解释，生成程序并负责执行

当智能体系统从原型走向规模化、长期运行，正是这种职责划分，决定了系统是否可控、可扩展、可维护。

如果说工具调用让模型“接触世界”，那么 Programmatic Tool Calling，才真正让模型参与构建系统。

查看原文：《理解真正的Programmatic Tool Calling》