一、从【逐次调用】到【一次程序】

• Native Tool Calling：想一步、调一个、看结果、再想。
• PTC：先写一段程序，程序里按顺序调多个工具。

往返次数是两者最直观的差别：N 步任务，前者 N 次以上，后者 1 次。

二、省下来的是什么

省的是中间结果进上下文的次数——5 个文件的内容不必都塞回上下文。

没省的是判断：哪几个文件要读、要挑什么、汇成什么表，还是模型定。

顺带得到的好处：变量、循环、错误处理都是普通代码，不用模型一趟趟确认。

三、实测：PTC 挂在哪三处

• tool-presentation——它的 config 是 mode: ptc（呈现方式）。
• workflow-ptc——provider: spawn，程序编排这件事本身是一个包。
• ptc-runtime——dsh-ptc-runtime-node，提供代码执行环境。

三件各管一段：呈现、编排、执行。

四、什么时候想起它

• 任务里步骤多、判据确定（批量读、批量改、按条件筛）→ 想起 PTC。
• 任务每步都要看结果再决定 → 老老实实用 Native。

这两句下面 7.3.5 还会展开——会用不算本事，知道什么时候不用才算。

五、动手 Demo：同一个任务，两条走法

同一件事，两条路的往返次数一眼可见：

steps = 5
native = steps + 1        # 每步一次往返, 最后再确认一次
ptc = 1                   # 一段程序一次执行
print("  Native  往返 %d 次, 中间结果全部进上下文" % native)
print("  PTC     往返 %d 次, 中间结果留在程序里" % ptc)

实跑输出：

--------------------------------------------------------------------
同一个任务，两条走法
--------------------------------------------------------------------
  任务：把工作区里 5 个日志文件分别读出来，挑出含 ERROR 的行，
  再按文件汇成一张表。

  走法                    模型每步做什么                      模型往返次数
  -------------------------------------------------------------------------
  Native Tool Calling     看一眼、调一个、再想、再调          5 次以上
  PTC                     写一段程序，把 5 次调用串在里面     1 次
  -------------------------------------------------------------------------

  Native 路：5 个文件的中间结果都要塞回上下文，模型看 5 遍。
  PTC 路：中间结果留在程序里，**上下文只装一次**。

  一句话：**PTC ＝ 让模型用程序编排已有工具**——
  能力没换（还是那几个工具），编排方式换了。

能力还是那几个工具——PTC 换的是编排方式，不是能力清单。 省下的主要是上下文：中间结果不再一趟趟来回搬。 但判断没省——哪些文件算日志、汇成什么表，还是模型说。

30 秒实验

1. 把同一个任务分别按 Native 与 PTC 各写一遍流程，数往返次数。
2. 在配置树里找 tool-presentation、workflow-ptc、ptc-runtime 三处。
3. 想想你最近干的活里，哪一件最适合交给程序编排？

常见误区

1. 错误：PTC 是一种新工具。——纠正：它不增加能力，只改编排方式——还是那几个工具，换了谁来串。
2. 错误：PTC 让模型不用思考了。——纠正：判断一步没省——省的是往返，不是判断。
3. 错误：往返次数少就是更快。——纠正：省的主要是上下文——中间结果不必来回搬，速度未必是主要收益。

• ☐ 下一节（7.2 PTC 不能绕过安全治理）

相关笔记

• PTC：同一批能力，不同的呈现方式 —— 那时只看到呈现方式变了
• PTC 压缩的是确定性控制流，不是依赖语义理解的决策 —— 本节留下的问题，那节回答
• 工作流编排 —— 编排思想在平台上的样子
• 🐳 DeepSeek Harness · 索引