我最近看到不少文章标题为Anthropic killed Tool calling又或是告别JSON 发布Tool Calling 2.0，看起来就相当唬人，仔细一看才知道，这些文章都是围绕 Anthropic 的 Programmatic Tool Calling（PTC）（大家口中的 Tool Calling 2.0）来讲的，但是大多数文章（至少我目前看到的）都没有进行科学的分析和对比，因此我将在本文章阐述PTC的真正情况和解决大家对其的误解。
ps：而且这个其实原本叫 CodeAct，2024 年在论文 Executable Code Actions Elicit Better LLM Agents 中被提出
先把两个版本说清楚：它们的核心逻辑有什么区别
1.0：传统 tool loop（ReAct 风格最典型）
最常见的 1.0 工具调用，是这样的节奏：
- 模型思考：我需要用哪个工具、参数是什么
- 模型输出一个
tool_use（通常是 JSON 参数） - 你的系统执行工具
- 把结果作为
tool_result回给模型 - 模型再根据结果继续（可能再次调用工具）
它的优势是：模型“看见”每一步观察（Observe），再决定下一步行动（Act）。 这就是经典的 ReAct：Reason → Act → Observe → Reason → …
2.0：PTC（Programmatic Tool Calling）
PTC 把节奏改成：
- 模型不再每一步都输出“下一次 JSON 调什么工具”，而是先写一段 Python 编排脚本
- 脚本在一个 code execution 沙箱容器里运行
- 工具在脚本里像函数一样被调用（循环、条件、并发都在代码里完成）
- 中间过程通常留在容器里处理（过滤、聚合、抽样、去重），最后只把“关键结果”输出给模型
| 维度 | TC 1.0（传统 tool loop） | TC 2.0（PTC） |
|---|---|---|
| 控制流（循环/条件/并发） | 主要靠模型多轮推理“逐步编排” | 主要写进脚本，由容器执行 |
| 中间结果可见性 | 中间 tool_result 往往进入上下文，模型能“看见”每一步 | 默认不把中间大结果塞进上下文；可选择性输出摘要 |
| Token 主要消耗 | 多轮往返 + 大结果进入上下文 | 通过“容器内处理→只回传关键输出”降低上下文成本 |
| 延迟主要来源 | 多次“模型推理 ↔ 工具执行”往返 | 往返减少（尤其多步/批处理/并发），整体更快的潜力更大 |
| 可解释/可审计 | 天生更强（每一步都在消息历史里） | 需要你在脚本输出里设计“审计摘要/检查点” |
| 调试方式 | 更像“对话式调参/复盘每步 tool_result” | 更像“调脚本/日志/容器输出”，工程味更重 |
| 适用场景 | 少量步骤、探索式推理、强解释 | 多步骤、多调用、批处理、并发、结果大但只要摘要 |
总结
-
传统 tool loop：模型 = 编排者 + 推理者。每一步往往靠模型读结果再决定下一步，结果多了就吃上下文/token。
-
PTC：模型 = 先写“编排脚本”的推理者；脚本/容器 = 执行与数据处理的编排者。模型只需要看你选择输出的关键结果。
PTC主要的局限性
-
可见性下降（observability / 可解释性）
传统 tool loop 里，中间 tool_result 往往被塞进上下文，模型能“看见”每一步发生了什么；PTC 里这些中间结果往往留在容器里处理，不自动进入模型上下文。
➡️ 结果：模型可能更难做“逐步审计式”的判断与解释（比如：为什么筛掉了某些条目）。
-
对“工具是否靠谱/是否出错”的判断信息变少
如果你把工具输出强力压缩成一个最终数字或 Top-K，模型就更少机会发现异常模式（例如某一批数据格式突变、某个接口返回空但不该空、边界条件被误处理）。这不是 PTC 的“必然错误”，而是信息被你（或脚本）提前丢掉后的典型风险。
-
调试更依赖工程手段而非“让模型读全量”
PTC 强调把编排写进代码（循环/条件/转换），减少每次工具调用都要完整推理一轮的开销；但相应地，出问题时你更多是在调脚本与日志，而不是让模型在上下文里复盘每一步。
-
截止2026.3.2 迁移/落地时最关键的差异点和明确限制
- PTC 不支持 strict 工具
- 容器会过期
- 安全与注入
- 等待PTC时，你回传的那条消息必须只包含 tool_result blocks不能夹带文字解释
- ZDR（Zero Data Retention）不覆盖该功能
怎么缓解这些局限（PTC 最常见的“补可见性”做法）
PTC 并不是“模型永远看不到中间结果”，而是默认不把中间大块数据塞进上下文；你完全可以在脚本里“选择性暴露”关键中间信息：
-
分层返回：
把 最终答案 + 关键中间摘要 一起输出（例如：每个工具调用的成功/失败计数、样本行、过滤条件命中数、异常值 Top-10、接口耗时分布）。这样模型仍能做合理性检查，但不会吃掉几十万 token。
-
断点/检查点（checkpoints）：
在脚本里每完成一个阶段就输出简短结构化摘要（或仅在检测到异常时输出更详细的上下文）。这能让模型在“关键节点”做判断。
-
抽样而不是全量：
对大结果做随机/分层抽样，把少量原始记录带回给模型用于 sanity check。
-
混合模式：
对“需要强判断/强解释”的步骤，保留传统 tool loop；对“纯批处理/聚合/检索”的部分用 PTC。官方也把 PTC定位为解决多工具工作流的推理往返与上下文成本问题，而不是替代所有 tool use。
由此我们可以提出以下相对科学的选择方案：
- 1 次调用 + 返回不大 → 传统 tool calling
- 1 次调用 + 返回巨大 + 需要重处理 → 可考虑 PTC
- 3+ 次调用 / 批处理 / 并发 / 循环条件逻辑 → PTC 通常更合适
如果这篇文章对你有帮助，欢迎分享给更多人！
部分信息可能已经过时