给 Claude 一台电脑：详解可编程工具调用 (PTC)
快速阅读
Lance Martin 最近分享了关于 Claude Opus/Sonnet 4.6 中的可编程工具调用 (PTC) 的深度见解。PTC 改变了传统工具每次调用都要经过上下文窗口往返的模式，允许 Claude 编写代码并在执行容器内直接编排和串联多个工具调用。只有最终结果会返回到 Claude 的上下文中。这种“代码组合性”与“工具控制面”的结合，大幅减少了 Token 消耗、降低了延迟，并显著提升了多步复杂任务（如搜索、过滤）的性能。
最近，Lance Martin 在 X（原 Twitter）上分享了一篇关于为 Claude 赋予“计算机能力”的深度文章。其核心在于 Claude Opus 和 Sonnet 4.6 版本中引入的一项激动人心的新功能——可编程工具调用（Programmatic Tool Calling, 简称 PTC）。
什么是 PTC？
简而言之，PTC 改变了传统工具调用的交互方式。以前，Claude 每调用一次工具，都需要通过上下文窗口进行一次往返（round-trip）。而现在，Claude 可以直接编写代码，在一个执行容器内部去编排和串联多个工具的调用。
中间的工具执行结果会直接返回给这段代码，而不再塞进 Claude 的上下文窗口中。这种方式极大地减少了 Token 的消耗，并显著提升了在搜索等多步复杂任务上的表现。实际上，最近搭载了 PTC 功能的 Opus 4.6 在 LMArena 的搜索基准测试中拔得头筹。
为什么需要把工具变成代码编排？
赋予 Claude 一个 bash 工具相当于打开了一个广阔的操作空间，这常常引发一个问题：“是不是只有 bash 就够了？我们如何决定该赋予智能体哪些其他工具？”
工具是 Claude 与世界交互的声明式方式。但传统的工具调用面临一个核心问题：控制力与组合性的权衡。 在传统的模式下，假设有三个连续的操作，每个操作的结果都要返回给 Claude。每一次往返都会增加延迟，将工具结果序列化到上下文中（哪怕下一步只需要其中五个数据，它也可能把数千行数据塞进去），并增加了一步推理过程。这种“组合税”会随着操作数量的增加而累积。
PTC 如何解决这个问题？
PTC 将代码的“组合性”与工具的“控制面”完美结合在一起：
- 你依然像以前一样定义工具。
- 但 Claude 不再单独调用它们，而是将它们组合成函数，并在代码执行容器中运行。
- 每个函数的输出直接返回给容器，由代码处理（例如调用另一个工具、过滤数据、累加结果）。
- 只有最终的结果才会到达 Claude 的上下文窗口。
当代码调用一个工具（例如 await web_search(query)）时，容器会暂停。该调用作为跨越沙盒边界的类型化工具使用事件，像往常一样被执行（比如通过 MCP 服务器等处理）。但其结果直接给到运行中的代码。
性能提升与实际收益
在非编码类的评估（例如用于网络搜索的 BrowseComp 和 DeepsearchQA）中，Opus 4.6 凭借 PTC 实现了 Token 效率和性能的双丰收。
举个例子：以前需要把 50 个原始搜索结果全部拉进上下文让 Claude 进行推理；现在，代码可以自动解析、过滤并交叉引用这些结果，只保留相关的部分并丢弃其余部分（动态过滤）。 通过这种方式，在 BrowseComp 和 DeepsearchQA 测试中，准确率平均提高了 11%，同时输入 Token 的使用量减少了 24%。
结语
PTC 是一种在保留工具控制面（工具的具体实现依然运行在你的系统这边，可以被拦截、记录、审查或排队等待人类批准）的同时，享受代码执行红利（如高度组合性）的绝佳方式。它让 Claude 能够通过代码极其流畅地编排现实世界的各种操作。