诚实说明：这一条还没有成组的实测数据。下面给的是**可执行的实验设计**和从结构推出的预期，不是结论。等两组各跑三次之后再把数字补进来。
为什么这两种场景会走向相反，从结构上可以推出来：
| 任务形状 | native模式 | ptc模式 | 预期 |
|---|---|---|---|
| 批量重复（同一动作 × 50个文件） | 50次工具调用 → 50次完整往返 | 写一个循环，1次run_code → 1次往返 | PTC明显省 |
| 少文件小任务（读2个文件汇总） | 2次调用 → 2次往返 | 仍要生成SDK提示，再写程序 → 往返省1次，提示成本固定 | 基本持平，可能略贵 |
| 每步依赖上一步的判断 | 每次调用后模型看着结果决定下一步 | 程序里得预先写好分支，判断力被削弱 | PTC不划算 |
| 操作可并行、互不依赖 | 串行调用 | 程序里可以并发（官方有maxParallelSubCalls，默认10） | PTC可能更快 |
实验怎么设计
- 批量组：50个结构相同的文件，同一个动作（例如各取前100字）。native跑3次，ptc跑3次。
- 小组：2个文件，做一份汇总。同样各3次。
- 每次只记：工具调用次数、往返轮次、输入/输出token、产物是否逐字一致。
- 时间记但不当主指标——网络波动会盖掉真实差异。
# 批量组（50 份） 读取 files/ 下全部 50 个 md，各取前 100 字，汇总成 table.md # 小组（2 份） 读取 a.md 与 b.md，合成一份 summary.md
一个容易被忽略的变量
PTC模式下有一个 maxParallelSubCalls 配置，默认10，控制一段run_code程序里并发子调用的上限。官方注释说它遵循native的调度契约：只有被判定为并发安全的工具才会重叠，独占调用会形成屏障；设成1等于严格串行。
这意味着PTC的对比不是「一个模式vs另一个模式」，而是「一个模式vs一个可调参数的模式」。写实测记录时必须说清maxParallelSubCalls取了多少，否则数字没法复现。