波仔
🐳 第二章 从零开始运行DSH
📄 一句话概括

同一个任务交给四套预设，比的是轨迹不是答案；往返次数少的真正好处是——中间结果不用一轮轮塞回上下文。

📝 本节和前面几节的关系

2.4.2 比的是【静态的组成】，这一节比【动态的走法】。到这里，第二章的三件动手事（跑起来、选工作区、比轨迹）就齐了。

一、实验怎么设计

书里给的实验设计很讲究：同一句话、同一个模型、同一个工作区， 只换预设，然后记录过程。

三个变量被固定住，只剩一个在动——这是控制变量。 注意它比的是轨迹，不是最终答案。为什么？因为：

调试的时候，后者比前者有用得多。答案错了，你得靠轨迹去找错在哪一步。

二、四套的走法差异

拿一个简单任务看：【列出工作区里所有 .py 文件，统计总行数】。

同一件事，四条路。差别不在【谁聪明】，而在谁手里有趁手的家伙。 PTC 少走几步，不是因为它更会算，是因为它能把【多步】打包成【一段程序】。

三、往返次数不是成绩单

看到 PTC 往返最少，很容易得出【PTC 最好】。这个结论是错的。

往返次数少只说明一件事：中间结果不用一轮轮塞回上下文。 它省的是上下文，不是【步骤】。

反过来，什么时候次数少反而不好？

当下一步高度依赖人的反馈时。比如你说【先看看有哪些文件，再决定改哪个】—— 这种时候每一步都停下来给你看一眼，比一把梭做完要好。

所以选预设要看任务形状，不是看次数排行榜。 步骤固定、数据流清楚的任务适合 PTC；需要边走边看的任务适合 Standard。

四、怎么看轨迹

轨迹里最该看的是模型每一轮看到的内容—— 这正是第 6 章整章要讲的东西。

可以这样理解：轨迹是一份完整记录，记下了【模型这一轮看到了什么、做了什么决定】。 有了这份记录，你才能回答那类最难回答的问题：

没有轨迹的 Agent 只能靠猜，有轨迹的 Agent 可以查。 这也是 DSH 把【可追溯】当成一等公民的原因。

五、动手 Demo：同一句话，四套预设的轨迹不一样

同一个任务在四套预设下的走法对比（往返次数为示意区间）：

traj = [("Standard", "列文件 → 读文件 → 自己加总", "2 ~ 3"),
        ("PTC", "写一段程序 → 一次执行拿结果", "1 ~ 2"),
        ("Minimal", "自己敲命令、读输出、再算", "2 ~ 4"),
        ("Creative", "同 Standard，但能看运行时内部", "2 ~ 3")]
for n, way, r in traj:
    print("  %-9s %-28s 往返 %s" % (n, way, r))
print()
per = 5000
print("每次往返带回的中间结果约 %d token" % per)
print("Standard 走 3 次 = %d token" % (per * 3))
print("PTC 压成 1 次  = %d token + 一小段程序" % per)

实跑输出：

--------------------------------------------------------------------
同一句话，四套预设的轨迹不一样
--------------------------------------------------------------------
  书里给的实验是：把同一个任务分别交给四套预设，
  记录各自的执行轨迹，再比较——注意比较的是轨迹，不是最终答案。

  拿一个简单任务看：【列出工作区里所有 .py 文件，统计总行数】

  预设         大致走法                          往返次数
  --------------------------------------------------------
  Standard     列文件 → 读文件 → 自己加总        2 ~ 3
  PTC          写一段程序 → 一次执行拿结果       1 ~ 2
  Minimal      自己敲命令、读输出、再算          2 ~ 4
  Creative     同 Standard，但能看运行时内部     2 ~ 3
  --------------------------------------------------------

  这里的【往返次数】指的是模型和工具之间来回几次。
  次数少不等于效果好——次数少的真正好处，是中间结果不用一轮轮塞回上下文。

  算一笔账：同样的任务，上下文占用差多少？

    每次往返带回来的中间结果       约 5000 token
    Standard 走 3 次              约 15000 token
    PTC 压成 1 次                 约 5000 token ＋ 一小段程序

  这就是 PTC 那件【多说的一句话】换来的东西：
  把【多轮对话】换成【一段程序】，省下的是上下文，不是时间。

最后两行是这一节的账：PTC 用【一段程序】换掉了【两轮来回】。 省下来的 10000 token 不是抽象数字——它占的是模型本来能用来思考的空间。 上下文里少堆两坨中间结果，模型就多两分余地放在正事上。

30 秒实验

  1. 挑一个短任务，在两套预设里各跑一次，把过程看一遍。
  2. 数一下模型说了几次话、工具被调了几次。
  3. 在轨迹里找找【模型看到的内容】——那正是第 6 章要讲的东西。

常见误区

  1. 错误：往返次数越少越好。——纠正：少只说明中间结果不用塞回上下文；遇到需要人拍板的任务，次数少反而不好。
  2. 错误：四套跑同一个任务，答案应该一模一样。——纠正：工具不同，能做的事就不同，答案自然可能不同。
  3. 错误：轨迹只是日志，没什么用。——纠正：轨迹是调试 Agent 的主要证据来源——先看轨迹，再判断是不是模型的问题。
自测三问（点开对答案） 1. 为什么比轨迹而不是比答案？ —— **轨迹反映的是【过程里发生了什么】**，答案只反映结果；调试时过程更有用。 2. PTC 省下来的到底是什么？ —— 上下文——**中间结果不用一轮轮塞回去，直接在一段程序里消化掉**。 3. 什么时候往返次数少反而不好？ —— 当下一步**高度依赖人的反馈**时；这时每一步都停下来看一眼，比一把梭做完好。

相关笔记