https://platform.claude.com/cookbook/tool-use-programmatic-tool-calling-ptc 讲讲这个

这篇讲的是：让 Claude 写一段程序来调用工具、处理数据，而不是每拿到一批工具结果，都让模型读一遍、再决定下一步。 PTC 的重点不是“模型会写代码”，而是把工具之间的循环、分支、并发和数据处理，交给代码执行；模型主要负责制定处理逻辑、理解最终结果。 先看文章里的报销案例 用户问：工程团队第三季度，哪些人的差旅支出超过预算？默认预算 5,000 美元，但部分员工有特殊额度。 它提供三个工具： get_team_members：获取团队成员。 get_expenses：获取某个员工的季度费用明细。 get_custom_budget：获取某个员工的特殊预算。 费用明细很啰嗦，除了金额，还有商户信息、收据链接、审批链等。真正需要的却只有：已批准的差旅费用总额，以及适用的预算。 传统 Tool Calling 怎么做 模型先调用成员工具，看到名单，再请求每个人的费用。 所有费用明细回到模型上下文后，模型筛选差旅费用、汇总金额，再为超过 5,000 美元的人查询特殊预算，最后给结论。 问题有两个： 大量不相关字段进入上下文，模型仍然需要处理这些输入。 “汇总后判断是否需要查预算”这种确定性逻辑，也需要模型参与下一轮决策。 文章展示的传统调用日志中，获取费用之后，一轮模型输入就达到 51,744 tokens。这是该示例的记录，不是所有任务的固定开销。 PTC 怎么做 Claude 不再逐步阅读所有账单，而是写一段程序，表达下面的逻辑： 获取工程团队名单。 逐人获取第三季度费用，可以对独立请求做并发。 只保留 status 为 approved、category 为 travel 的记录，求和。 总额超过 5,000 美元，才查询特殊预算。 与实际额度比较。 最后只输出员工姓名、差旅总额、预算、超出金额。 这段程序在 Code Execution 环境里运行，并在执行过程中调用工具。 关键区别是：原始账单可以留在程序的执行过程里，不必逐条进入模型上下文。模型最终读到的是程序筛选、汇总后的结果。 比如，下面是说明逻辑的假设数据，不是文章实测结果： 员工甲：差旅支出 6,200，特殊额度 7,000，未超标。 员工乙：差旅支出 5,800，默认额度 5,000，超出 800。 判断这些结论不需要模型阅读两个人的收据地址和审批链。 它与普通并行工具调用有什么区别 普通 Tool Calling 也可以在一轮里发起多个调用。文章的传统方案就一次请求了八名员工的费用，所以不能把 PTC 简化为“让工具并行”。 真正的区别是控制流在哪里执行。 普通调用：工具返回结果 → 模型读结果 → 模型决定后续调用。 PTC：工具返回结果 → 程序筛选、计算和判断 → 程序继续调用工具 → 把必要结果交给模型。 并行解决的是“多个独立请求能否同时跑”。 PTC 进一步解决的是“请求之间的确定性处理，是否还需要模型介入”。 也别理解成“完全没有工具往返”：外部工具仍然需要被执行和返回结果，减少的是中间步骤对模型推理和上下文的依赖，不是让网络请求消失。 为什么这个设计有价值 第一，降低上下文开销。 不是先把几万 tokens 的账单塞给模型，再让它总结，而是在进入模型上下文之前，就用代码过滤掉无关数据。 第二，减少不必要的模型决策轮次。 “金额超过阈值才查预算”可以直接写成条件分支，不需要模型每次重新判断。 第三，让确定性运算由程序完成。 筛选、求和、排序、关联这些工作，本来就更适合代码。不过模型也可能写错过滤条件，所以“用了程序”不等于结果自动正确。 第四，不必要求第三方 API 为你的问题重新设计接口。 如果接口只能返回大而全的数据，又没有服务端聚合能力，就可以在执行环境里做二次处理。这也是文章特别强调的场景。 适用边界 它适合“工具多次调用＋返回数据大＋中间逻辑明确”的任务，比如批量报销审查、日志统计、跨系统数据汇总。 如果只调用一次工具、结果也很短，引入代码执行未必划算。 如果每一步都需要理解模糊文本、做复杂语义判断，也不能指望用几个循环和条件分支替代模型。 此外，过滤逻辑必须保留必要证据：如果程序只打印“员工乙超标”，却不输出金额、预算和关联标识，后面的模型就很难检查结论。 一句话理解：PTC 把模型从“每一步都亲自看数据、指挥工具”，变成“编写一段可执行的数据处理流程，再阅读关键结果”。它是一种把确定性工作移出模型推理循环的 Agent 设计。