波仔
🐳 第七章 从Tool Call到Agent Runtime
📄 一句话概括

PTC 省的是往返，不是判断——步骤很少、每步要看上一步结果、需要人逐步审阅，这三种情况用 Native 更划算。

📝 本节和前面几节的关系

7.3 的最后一块：把 PTC 的适用边界说清。会用它不算本事，知道什么时候不用它才算。

一、划算的那一类

一句话：步骤多、依赖确定。

二、不划算的这三类

三、怎么算这笔账

第一步，数步骤：N 大不大？ 第二步，看依赖：下一步只依赖上一步的输出格式（确定），还是依赖输出内容的含义（不确定）？

两步都偏确定，才选 PTC；只要第二步是【要理解】，就别绕。

四、一句口诀

判断少、步骤多的活交给 PTC；判断多的活别绕。

这也是 7.3.2 那句【压缩控制流、不压缩判断】的直接推论——同一件事，正着说一遍、反着说一遍。

五、动手 Demo：PTC 什么时候反而不划算

判据只看两条：依赖有多确定、每步要多少判断。

cases = [("步骤固定、判据确定", "PTC"), ("步骤很少 1~2 步", "Native"),
         ("每步看结果再决定", "Native"), ("需要人逐步审阅", "Native"),
         ("批量重复套模板", "PTC")]
for c, pick in cases:
    print("  %-18s -> %s" % (c, pick))
print()
print("  口诀: PTC 省的是往返, 不是判断")

实跑输出：

--------------------------------------------------------------------
PTC 什么时候反而不划算
--------------------------------------------------------------------
  判据只看两条：步骤之间**依赖有多确定**、每步要多少判断。

  情形                             更适合     为什么
  -----------------------------------------------------------------------
  步骤固定、判据是字符串或数值     PTC        控制流确定，程序一次写完
  步骤很少（1~2 步）               Native     写程序的固定开销不值
  每步要看上一步结果再决定         Native     判断本身就是模型的活
  需要人逐步审阅中间过程           Native     程序的中间态不在上下文里
  批量重复（同一模板套 N 次）      PTC        循环是最典型的确定性控制流
  -----------------------------------------------------------------------

  一句话：**PTC 省的是往返，不是判断**。
  判断少、步骤多的活交给 PTC；判断多的活别绕。

四类里三类留给 Native——PTC 不是越用越好。 写程序的固定开销是真实的：1~2 步的活包成程序反而更贵。 判据只有两条，不用记案例，记判据。

30 秒实验

  1. 把自己的一个任务按两条判据过一遍，决定用哪条路。
  2. 举一个【步骤多但每步都要判断】的例子，说明为什么它不适合 PTC。
  3. 想想【需要人逐步审阅】为什么是 Native 的加分项。

常见误区

  1. 错误：PTC 是更先进的写法，应该尽量用。——纠正：它只在特定形状的任务上划算——步骤多、依赖确定。
  2. 错误：步骤越少越该用 PTC。——纠正：写程序的固定开销反而更大——1~2 步的活交给 Native。
  3. 错误：PTC 能省掉模型的判断。——纠正：判断挪不走——每步要看结果再决定的活，就得让模型看。
自测三问（点开对答案） 1. PTC 划算的两类情形？ —— **步骤固定、判据确定**与**批量重复套模板**。 2. 不划算的三类情形？ —— 步骤很少（1~2 步）、每步要看上一步结果、需要人逐步审阅中间过程。 3. 判断用不用 PTC 的两条判据？ —— 数步骤（N 大不大）、看依赖（只依赖输出格式，还是依赖内容的含义）。

相关笔记