名字容易误导。PTC不是「Performance Tuning Configuration」之类的加速开关，它是工具的呈现方式：官方类型就叫 ToolPresentationMode，三个取值 native / ptc / both。
| 取值 | 发给模型的是什么 |
|---|---|
| native（默认） | 每个可见工具的完整schema，模型按需逐个调用 |
| ptc | 只发 run_code 加上一份生成的SDK提示；模型写一段程序，在程序里调各个工具 |
| both | 两种形式都发 |
官方描述里那句关键的话：「五轮往返的序列变成一轮」。省的不是token本身，是「每多一次工具调用就多一次完整模型往返」这个结构。
代价：硬依赖代码运行时
官方文档写得很明确：PTC模式需要一个 ctx.codeRuntime，而且它的language必须有注册的SDK渲染器（TypeScript或Python）。缺了或者在语言没有渲染器时，prompt组装直接失败。不是悄悄退回native，是失败。
另一个细节：在ptc模式下，
toolOrder 里的native工具名是无效的——因为模型根本看不到那些名字，它只看到run_code和SDK。所以为native模式写的工具顺序配置，切到PTC之后会失效。什么时候它真的省
- 省：多步操作可以写成一段程序，且有明确的先后依赖（读A → 按A的结果读B → 汇总）。
- 不省：只有一两步、或者每步都要人看着决定下一步。这种场景PTC只多一层抽象。
- 可能更贵：生成的SDK提示本身占上下文，工具少、调用也少的时候，这份提示是净开销。
自己测，别信结论
社区里对「PTC到底省不省」有相反的说法，这很正常——它取决于任务形状。要判断自己的任务，唯一办法是同一个任务各跑三次，只比两个数：工具调用次数、模型往返轮次。
# 记录模板（不要只记总耗时） 模式 | 运行 | 工具调用次数 | 往返轮次 | token | 产物是否一致 native | 1/2/3 | | | | ptc | 1/2/3 | | | |
墙钟耗时受网络和服务端波动影响太大，单次对比没有意义。要么跑三次取区间，要么干脆不比时间只比往返次数——后者才是PTC真正改变的量。