波仔
🐎 第7章 无为而治：Headless 模式与 CI／CD 集成
📄 一句话概括

多阶段流水线绕不开一个问题：第二步要不要知道第一步干了什么。每步新开、还是一路续下去？ 实测三步：全续要四千八，每步新开三千六。 续下去更贵，而且步数越多差越远——它买的是「不用重新交代」。

📝 本章和前面几章的关系

上一节讲怎么看进度，这一节讲怎么把上下文带到下一步。 这一节的结论有点反直觉：续会话不是省 token 的办法，它是买准确性的办法。

一、两种做法的成本形状

每步新开：每一步都重新注入项目背景，但历史是干净的。成本是线性的，每步一样贵。 一路续下去：背景一样要在，而且历史会一直累积——第几步就多背几份工作量。 演示三步：新开三千六，续下去四千八。五步：新开六千，续下去一万。

差距随步数拉大：因为历史是线性累积的，而每一步都要把历史重付一次，合计接近平方。

二、续会话买的是什么

买的是「不用重新交代」。第三步要改第一步看过的那个文件，新开就得重新找一遍。 重新找一遍的成本，往往比多带一段历史更贵——尤其是要找的东西散在十几个文件里。 所以判据不是「省不省 token」，是「后面要不要依赖前面的结论」。

各步互相独立（lint、测试、打包），每步新开；后一步要看前一步的产出，才续。

三、三个实操点

会话标识要显式存下来。流水线里没有「上一次」这个概念，只有你传下去的 id。 续的时候要能选「带哪一段」。全带会越来越贵，只带结论最省。 会话文件是状态，要有地方存。CI 里通常靠缓存目录或者上一步的产物。

第三条最容易被忘：本地跑的时候会话文件就在磁盘上，CI 里每一步都是新的机器。

四、一条更省的做法

把「结论」当会话之间的传递物，而不是「历史」。 第一步跑完，让它输出一段结构化摘要：改了什么、结论是什么、下一步该看哪里。 第二步从这个摘要开始。这相当于人为做了一次压缩：扔掉过程，只留结论。

它比续会话便宜，也比新开准确——而且摘要本身可以进日志，事后能查。

五、什么时候必须续

第一种：后一步要基于前一步的精确上下文，压缩会丢信息（比如调试一个跨文件的类型错误）。 第二种：步骤之间来回反复，中间产物本身就是对话的一部分。 这时候别为了省 token 硬拆——拆错了会多花几倍的时间去重新探查。

一句话：省 token 的优先级永远低于「结论对不对」。顺序反了，省下来的钱会以返工的形式花掉。

六、动手 Demo：三步流水线，每步新开会话还是一路续下去

多阶段流水线有个绕不开的问题：第二步要不要知道第一步干了什么。 这里真跑两种做法：每步新开一个会话，或者一路续下去，各算总上下文量。

BG, WORK = 800, 400                # 背景，单步工作量

hist = sum(m["n"] for m in s["msgs"])
ctx = BG + hist + WORK             # 每次调用都要带背景加历史

实跑输出：

--------------------------------------------------------------------
三步流水线，每步新开会话还是一路续下去
--------------------------------------------------------------------

  多阶段流水线有个绕不开的问题：第二步要不要知道第一步干了什么。
  两种做法：每步新开一个会话，或者一路 --resume 续下去。

  ① 两种做法的成本形状
  --------------------------------------------------------------------
  新开：每步都要重新注入项目背景（这里算八百 token），但历史是干净的。
  续下去：背景一样要在（每次调用都得带上），而且历史还会一直累积——第几步就多背几份工作量。
| 步数 | 每步新开 | 一路续下去 | 续的代价 |
|---|:---:|:---:|:---:|
| 3 步 | 3600 | 4800 | +1200 |
| 5 步 | 6000 | 10000 | +4000 |

  续下去反而更贵，而且步数越多差得越远。因为它每一步都要把前面的历史重读一遍。
  这就是上下文成本的形状：历史是线性累积的，但每一步都要重新付一次，合计接近平方。

  ② 那续会话买的是什么
  --------------------------------------------------------------------
  买的是「不用重新交代」。第三步要改第一步看过的那个文件，新开会话就得重新找一遍。
  重新找一遍的成本，往往比多带一段历史更贵——尤其是要找的东西散在十几个文件里。
  所以判据不是「省不省 token」，是「后面要不要依赖前面的结论」。
| 情况 | 该用哪种 | 理由 |
|---|---|---|
| 各步互相独立（lint、测试、打包） | 每步新开 | 历史没用，纯属多付 |
| 后一步要看前一步的产出 | 续下去 | 省掉重新探查的成本 |
| 步骤超过五步 | 拆分或换做法 | 历史会压垮窗口 |


  ③ 续会话的三个实操点
  --------------------------------------------------------------------
  - 会话标识要显式存下来。流水线里没有「上一次」这个概念，只有你传下去的 id。
  - 续的时候要能选「带哪一段」。全带会越来越贵，只带结论最省。
  - 会话文件是状态，要有地方存。CI 里通常靠缓存目录或者上一步的产物。

  ④ 一条更省的做法
  --------------------------------------------------------------------
  把「结论」当会话之间的传递物，而不是「历史」。
  第一步跑完，让它输出一段结构化摘要（改了什么、结论是什么），第二步从这个摘要开始。
  这相当于人为做了一次压缩：扔掉过程，只留结论。它比续会话便宜，也比新开准确。
  ! 这里的会话模型是简化版：只算上下文长度，不算真实的缓存命中与压缩策略。

①每步新开是线性的：每步都要重新注入背景，成本一样贵。 续下去是平方的：历史线性累积，而每一步都要把历史重付一次。 ②实测三步新开三千六、续下去四千八；五步新开六千、续下去一万。续下去更贵，步数越多差越远。 ③所以判据不是「省不省 token」，是「后面要不要依赖前面的结论」。 各步独立就新开，后一步要看前一步的产出才续。 ④更省的做法是传结论不传历史：第一步输出一段结构化摘要，第二步从摘要开始。 相当于人为压缩一次，比续会话便宜，也比新开准确。

30 秒实验

  1. 把背景从八百改成两千，重跑一遍。续下去还是更贵吗？差距变大了还是变小了？
  2. 把单步工作量从四百改成两千（每步都在读一大堆文件），重跑一遍。这时候续会话还划算吗？
  3. 给「传结论」的做法估一个压缩率（比如结论只占工作量的一成），重算一次。它和续会话的差距有多大？

常见误区

  1. 以为续会话一定更省。历史会累积，每一步都要重付一次，合计接近平方。
  2. 各步完全独立也硬要续。历史全用不上，纯属多付。
  3. 在 CI 里靠「上一次的会话」自动续。每一步都是新机器，没有「上一次」。
  4. 为了省 token 把该续的拆开。重新探查的成本通常比多带历史更贵。
  5. 只传历史不传结论。日志越来越长，可读性越来越差，最后谁也不知道它为什么那么做。
自测三问（点开对答案） 1. 续会话为什么反而更贵？ —— 因为历史会一直累积，而每一步调用都要把累积的历史重付一次。 历史线性增长、重付次数也线性增长，合计接近平方。 2. 该不该续的判据是什么？ —— 后面要不要依赖前面的结论。依赖就续（或传结论），不依赖就每步新开。 3. 比续会话更省的做法是什么？ —— 传结论不传历史：让上一步输出结构化摘要，下一步从摘要开始。相当于人为压缩一次。

上下文的问题解决了，下一节把「在 CI 里要配什么」列成一张清单。

相关笔记