标签：AI Agent｜Token｜上下文工程｜DSH｜工程效率
DSH（DeepSeek Harness）是 DeepSeek 的 Agent 运行框架，下文所有配置与数字都在它上面实测。 数据来自 DSH（DeepSeek Harness）本地会话日志与工具实测：17 个主会话（治理前 8 + 治理后 9）、2,514 步、1.96 亿输入 token，取原始
usage字段，无估算。已脱敏。 统一口径：只统计主工作区（AI_TEST）的主会话，子代理会话与其他工作区不计；分界点 10-31 17:55（治理配置生效），统计截止 2026-11-04 15:15（进行中的 1 个会话不计入）。全文与配图共用这一口径。
一、怎么才能省点钱
手上这个项目的文档攒到了 61 万字——规则、资产、接口说明、历史结论全在里面。Agent 每开一轮对话，要么把这些整本背进去，要么满世界 grep 一遍。两条路都贵，而且越往后越贵：它读进来的东西，会被后面每一步重复付一次钱。步数定不了，能压的就是这段重复上传的上下文。
这里有两种方式：
第一：给 Agent 一张文档地图。
不再整本塞进上下文，而是编成索引：先查目录，命中哪节读哪节。相当于进门先看平面图，不是把整栋楼搬着走。
第二：给上下文设置一个上限。
涨到 10.5 万就压缩（治理后样本内 20 次，没有一次越过 11 万），前面换成摘要，只留最近一段原文。
看到这，你大概会问：这张地图怎么建、上限设在哪、代价多大、到底省了多少。
下面用实际跑的 17 个对话、2,514 步、1.96 亿输入 token 的实测日志逐个回答。先看三个数：
| 调整前 | 调整后 | |
|---|---|---|
| 和 Agent 对话时，常驻规则 | 36,211 字符 | 19,180 字符（−47%） |
| 单次调用里最高的 token | 242,934 | 105,106（−57%） |
| 每次调用的平均 token | 89.0k | 72.0k（−19%） |
同期资产正文还涨了 9.5%，压缩代价 0.7%，长尾比（会话尾段每步均值为头段的几倍，越接近 1 越平）3.19 → 1.12。步数没动——只有压缩本身带来的 +3~5%。
这里有个坑：能单独引用的口径只有三个——撞顶会话反事实合计 −45%、实测均价 −19%、调用载荷 −57%。"总 token 降了一半"这种话不能单拎出来，里面混着任务大小，小任务本来就花得少，长任务本来就花得多。
二、省多少钱
先算一笔最简单的账。假设 token 单价 0.1 元/百万（数字凑整，只为看清公式）：
同一个任务要调模型 100 次，每次上传 10 万 token，合计 1,000 万 token，1 元。 要是每次只上传 5 万，合计 500 万 token，0.5 元。
同样的活，每次少带一半，账单就少一半。所以能压的只有两个乘数：每次带多少，跑多少次。
但"每次带多少"不是想省就能省。第 1 次只带系统提示和工具定义，一万 token 就够；到第 100 次，前面 99 次说过的话全都要重新带上，同一件事的单次成本从一万爬到二十多万。跑得越久，一次比一次贵——这是最容易被忽略的地方：读进上下文的每个字，后面每一步都要再付一次钱。
压小当然可以，但不能乱压：
- 完全不压：跑到后面单次能到 24 万，而且一次比一次贵。
- 压到 10.5 万封顶：单次在 5 万到 10.5 万之间来回走，账单砍掉一截。
- 压得太狠（比如两万封顶）：账面更便宜，但摘要装不下细节，模型开始反复重读、重新摸索——实测压缩后平均要 4 步才回到正题，省下的钱又还回去一部分，回答质量还跟着掉。
所以不是越小越好，是压到刚好不丢关键信息。这个点拍脑袋定不了，只能测：这次跑了一周、多轮对照，才定到"10.5 万触发、保留最近 2.4 万"——这两个数只对这套项目成立，换项目得重测。真实样本里，单步均价从 8.9 万降到 7.2 万（−19%），峰值从 17 万–24 万压到 10.5 万封顶。
上面是凑整的估算，换成真价钱再看一遍。deepseek-flash 按量计费（元 / 百万 token）：输入缓存命中 0.02、未命中 1.00、输出 4.00；高峰时段翻倍（分别为 0.04 / 2.00 / 8.00）；按哪档计费，看请求完成的时间。
取空闲时段、缓存命中率按样本实测的 98%，拿一个 305 步的长任务算（同任务口径，输入 63.3M → 23.10M）：
| 一个 305 步任务 | 调整前 | 调整后 |
|---|---|---|
| 输入 · 缓存命中 | 62.0M × 0.02 = 1.24 元 | 22.6M × 0.02 = 0.45 元 |
| 输入 · 缓存未命中 | 1.26M × 1.00 = 1.26 元 | 0.47M × 1.00 = 0.47 元 |
| 合计（只算输入） | 2.5 元 | 0.9 元 |
省 1.6 元，六成四。赶上工作日高峰，单价翻倍，就是 5.0 元 → 1.8 元。输出那一栏没有列：两版的输出量差不多，省不到它身上，也不影响省了几成的比例。
看这两行有个反常识的地方：命中部分单价便宜 50 倍，可它的量也大了 50 倍，两边几乎打平——这张账单里，"命中但量大"和"未命中但占比小"各贡献一半。所以省钱得同时盯两件事：把总量压下来，别让命中率掉下去。压得太狠会动到前缀，命中率一掉，省下的那点立刻被未命中吃回去。
把这笔账拆开，就是三个变量：
总量 = 步数 × 单步成本
单步成本 = 地板（每次都要付的起步价） + 历史增量（越跑越多）
| 旋钮 | 决定什么 | 由哪一招管 | 实测值 | 是否管住 |
|---|---|---|---|---|
| 地板 | 第 1 步就要付的固定成本 | 文档地图（第一招） | 10,070 – 12,700 | ✅ |
| 上限 | 历史最多能堆到多高 | 上下文上限（第二招） | 105,106 | ✅ |
| 步数 | 干这活要多少轮往返 | 没有一招管得住 | 537 步 | ❌ |
三行对应三件事。前两件各管一个变量，第三件谁也没管住——步数定不了。
三、给 Agent 一张文档地图能节约查询的费用
项目知识进模型有两条路：全塞进系统提示，每轮背一遍；或者让它自己 grep、自己找。第一条路的账好算——塞进去多少字，跑 300 步就付 300 次。第二条看着省钱，实际把成本换成了"找的那一下 × 剩下的步数"，会话越长越难看。
还有第三条：编一张地图，先查目录，命中哪节读哪节。这张地图不是向量检索，是脚本扫一遍资产标题生成的目录加索引卡，资产改完跑一次刷新就有。做图之前，先把"资产很大"这个模糊感受量化出来：
| 对象 | 治理前体量 | 问题 |
|---|---|---|
| 常驻规则（5 个 always-apply） | 36,211 字符 | 每轮全量注入，重复付费 |
| 全部资产正文 | 557,375 字符 | 任何上下文窗口都装不下 |
| 单篇最大资产 | 77,074 字符 | 全文读一次 ≈ 5 万 token |
| 资产登记表 | 45,288 字符 | 被当"索引"读，它自己就很贵 |
由此得出一个关键判断：不是资产太大，是供给方式错了——"常驻一堆 + 任务中全文读"。
于是改成三层，每轮真正要付钱的只有最上面那层：
L1 常驻层（每轮）：AGENTS 薄壳 + 约束类规则 → 预算 ≤ 2 万字符
↓ 命中场景（description 触发 / 规则地图）
L2 索引层（命中才载入）：资产卡片 / 紧凑索引 / 精确查询
↓ 命中条目
L3 取证层（只读那一节）：章节锚点定向读 / 精确查询 / 子代理回执
翻译一下：每轮只带一张薄壳（该找谁、找什么）；命中哪个场景，才把对应那张索引卡翻开；在卡上定位到条目，才去读那一节原文。三层里只有第一层是"每次都付"，后两层都是"用到才付"。
那到底省了多少？ 一周后复测：
| 指标 | 治理前 | 现在 | 变化 |
|---|---|---|---|
| 常驻规则 | 36,211 字符 | 19,180 字符 | −47%（预算 2 万，用掉 96%，PASS） |
| 资产正文 | 557,375 字符 | 610,121 字符 | +9.5%（继续长） |
| 卡片层 | — | 18,424 字符 = 正文的 3.0% | 单次查询只回约 400 token |
| 登记表 | 45,288 字符 | 52,993 字符 | 不再全文读，改用紧凑索引（134 条）+ lookup |
最关键的一行是第二行：资产涨了 9.5%，常驻没跟着涨。索引层的作用不是"省一次"，而是把资产增长和上下文增长解耦。
到了 DSH 这一代更彻底：规则正文的常驻量是 0。每轮只注入 AGENTS 薄壳（3,891 字符）+ 10 个技能的 description，正文命中才加载。实测地板 12,790 token——其中 system + 工具定义就占了绝大部分，规则只剩薄壳那一层。
**而且它带门禁。**索引做完了不能靠感觉验收，得能回归：
| 门禁 | 判据 | 基线 |
|---|---|---|
| 20 个真实会话查询词 | 全空 = 0，平均输出 ≤ 12 条 | 全空 0，平均 7.0 条，文档层命中 15/20 |
| 45 条口语化提问 | 全空 = 0 | 全空 0，文档层命中 29/45（64%） |
反例也留了一个：曾经想做"中文页面名 → 组件名"的自动映射，评估后决定不做——推断层 2/3 不可信，多个子页共用一个组件，"据此查接口会张冠李戴"。文档里的结论是：自动生成会得到约 2/3 不可信的映射，比"查不到"更危险，因为它让人以为查到了。
如果退回"裸文件让 Agent 自己找"
这是索引层真正的价值所在，可以算。但先说清楚：这不是实测对照。 索引整理完成于 10-26，DSH 的第一个会话在 10-31 —— 也就是说所有 DSH 会话都已经带着索引层， "裸文件"这个状态在 DSH 里从未出现过。下面是把已知字符数代进去的推演，不是测量结果。
| 场景 | 计算 | 代价 |
|---|---|---|
| 14 个规则全部常驻 | 71,853 字符，按项目自用的 4 字符/token = +18k/步 | 305 步 +5.5M（+24%） |
| 同上，按中文实际 1.6–2 字符/token | +36k ~ 45k/步 | 305 步 +11.0M ~ 13.7M（+48%~59%） |
| 发现式读取：读一次 73,360 字符的大资产 | 18.3k token，落在 200 步会话第 10 步 → ×190 步重放 | 单次 3.5M |
| 发现式读取：全文读登记表一次 | 13.2k token，落在 150 步会话中段 | 约 1.3M |
记住这条公式就够了：加进上下文的每一个 token，都要被后续每一步重放一次。
一次 10KB 的全文读 ≈ 2.5k token
放在 200 步会话的开头 → 2.5k × 200 = 50 万 token
这就是"让 Agent 自己去 grep、自己找"最贵的地方：每步固定支出 × 剩余步数，会话越长越难看。这也解释了索引文档里那句最狠的话：索引查不到的成本最高——智能体判成"没有资产"，转去全盘搜索，token 反而翻倍。
四、每次调用模型时传入的上下文可以节约单价
地图管的是"进门带多少"，管不了"跑起来越堆越高"。会话一长，每一步都要把前面的历史重放一遍，这笔钱没有任何上限。要给它设上限，只改一处配置——压缩是运行时自带的，摘要由模型在压缩那一刻生成，不用自己写：
- id: compaction-basic
config:
thresholdRatio: 0.1 # 触发线 = min(0.1 × 窗口, 窗口 − 输出 − headroom) = 104,857
retainTokens: 24000 # 压缩后保留最近原文的下限
maxTokens: 8192 # 摘要输出上限
机制不复杂：上下文涨到阈值就压缩，把前面的历史换成摘要，只保留最近一段原文。
这两个数不是通用值。 104,857 是这套配置在模型窗口下算出来的触发线；24,000 是这套项目的资产量和任务长度分布上试出来的平衡点——资产更大、任务普遍更长，就得往上抬；反过来就往下压。同一个数搬到别人的项目上，可能压得太松白花钱，也可能压得太紧掉质量。别照抄数字，照抄顺序：先让自己跑出几十个会话，看清自己的地板和峰值长什么样，再一边调阈值、一边看账单和回答质量。
一个容易踩错的细节：retainTokens 是下限不是精确值。源码是从会话末尾向前累计 token，够数就停，且不会拆断"工具调用 / 工具结果"这一对。所以配置 24,000、实测保留区约 33,000。
结果是锯齿：每涨 56k 被压回约 48k，单步永远在 48k–105k 之间走。
治理前后各挑重会话对比（治理后取 11-02 全部 ≥100 步的会话）：
| 会话 | 日期 | 步数 | 总输入 | 单步均值 | 峰值 | 压缩 | 缓存命中 |
|---|---|---|---|---|---|---|---|
| A 资产地图规则调整 | 10-31 | 162 | 19.05M | 117,593 | 242,934 | 1 | 89% |
| B 问题复现与工单 | 10-31 | 138 | 16.51M | 119,638 | 195,552 | 0 | 99% |
| C 计划落盘 | 10-31 | 138 | 14.76M | 106,957 | 170,330 | 0 | 99% |
| D 治理验收（治理中） | 10-31 | 109 | 8.68M | 79,633 | 104,818 | 3 | 96% |
| E 页面逐页验证（85 页） | 11-02 | 305 | 23.10M | 75,738 | 104,912 | 4 | 98% |
| F 处方笺打印排查 | 11-02 | 160 | 11.66M | 72,875 | 104,869 | 2 | 97% |
| G 问题复核 | 11-02 | 114 | 8.19M | 71,842 | 104,531 | 1 | 98% |
三个治理后会话，步数 114 → 305，峰值全部落在 104,531–104,912 之间，间距不到 400 token。
E 的步数是 A 的 1.88 倍，峰值只有 A 的 43%。
会话更长、峰值更低——这是配置生效最强的证据，"越跑越贵"的斜率被打断了。
而且不是一天的特例。11-02 下午 15:55–16:56，一小时内连着跑完两个会话（F、G），一个 160 步、一个 114 步，峰值 104,869 / 104,531。同一道天花板，误差 0.3%。这就是把门槛写进运行时的意思：它不依赖当天的任务类型，也不依赖模型状态。
同类任务的纵向对比更干净：
| 同类任务 | 日期 | 步数 | 单步均值 | 峰值 |
|---|---|---|---|---|
| 计划与执行 | 10-31 | 66 | 105,847 | 159,444 |
| 计划与执行 | 11-02 | 57 | 43,972 | 57,679 |
| 逐页验证 | 11-02 | 305 | 75,738 | 104,912 |
单步均价 105,847 → 43,972，降 58%。
这一对要打折看：前段一路涨到峰值 159k，后段从头到尾只有 40k–58k——后段的活本身就轻 （57 步新增的上下文约 2.7 万，前段 66 步新增约 10 万）。所以 −58% 里混着任务密度差异， 不能全部记在治理头上。
控制实验更能说明问题：不撞天花板的会话，治理前后几乎一样。
| 短会话（峰值 ~58k，全程未触发压缩） | 日期 | 步数 | 总输入 | 单步均价 | 峰值 |
|---|---|---|---|---|---|
| 药品说明书查询频率限制边界 | 10-31 | 58 | 2.30M | 39,653 | 58,651 |
| 测试指引落盘执行 | 10-31 | 54 | 2.31M | 42,732 | 58,216 |
总量 2.30M → 2.31M，等于没变（+0.4%）。
结论很清楚：它管的是天花板。地板那块，一分钱也没省。 任务本来就在天花板 下面跑的，省不到钱；只有会撞顶的长任务才受益——受益方式是"不再线性膨胀"， 不是"每步都更便宜"。
把账单拆成三个乘数（为什么跨任务比总量没意义）
跨任务比总量是没意义的，步数差一倍什么都看不出来。把每个会话拆开，账单只有三个因子：
总 token = 步数 N × 地板 F₀ × 放大倍数 k
↑ ↑
每一步固定支出 历史堆到多高
- 地板 F₀（首步 prompt）：统一口径的 17 个主会话落在 11,287–13,917（中位 12,700）。 另做过一次对照实验：新开一个空工作区跑 17 个会话，地板落在 9,542–11,688（中位 10,070）。 同一台机器、同一个模型，只换工作区就差 2,630 token（−21%）——量级正好等于主工作区那份 3,891 字符的 AGENTS.md 加常驻规则链。 地板是工作区属性，不是模型常数，也不是估出来的：改一个文件就能测出来。
- 放大倍数 k（单步均价 ÷ 地板）：治理前 3.3 → 8.3 → 8.6 → 10.4，
几乎等于
k ≈ 0.065N，步数越多越贵；治理后无论多少步都收敛到 4.8。 - 步数 N：唯一在朝反方向走的因子。
说人话：k 就是"第 N 步比第 1 步贵了多少倍"。治理前它跟着步数一起长，总账于是接近平方级往上蹿；治理后不管跑多少步，都卡在 4.8。
顺带一个不太舒服的事实：k 的倒数就是地板占比。治理前重会话地板只占 10%–12%， 治理后 19%–21%——任何时候，接近八成的 token 都在重放已经说过的话。 所以改地板（索引层）的杠杆天生就小，改天花板（运行时）才是大头。
由此得到一个临界点：0.065N − 0.77 = 4.8 → N ≈ 85 步。
85 步以下的任务，治理对它几乎无感（它的 k 本来就没涨上去）；85–170 步降 10%–45%；
300 步量级能降一半以上。
同一个任务口径下的总量（同 N、同增速、只是没有天花板）：−45%。
这个数字会随样本里的长任务增多而往上走——长任务本来就落在收益区里，样本里长任务越多，加权出来的降幅越大。
降幅随样本变长而增大：长任务落在收益区里
统一口径截至 11-04 15:15，治理后共 9 个会话，其中 537 步、374 步、305 步三个超长会话。按步数档重算：
| 步数档 | 会话 | 合计 token | 占治理后总量 | 撞顶 |
|---|---|---|---|---|
| < 50 步 | 3 | 4.6M | 3.9% | 0 |
| 50–99 步 | 1 | 3.6M | 3.0% | 0 |
| 100–199 步 | 2 | 19.9M | 16.7% | 2 |
| ≥ 200 步 | 3 | 90.8M | 76.4% | 3 |
治理后 9 个会话里，4 个（44%）从头到尾就没碰到过 10.5 万。 它们省 0，也确实没什么可省的。 省下来的量全在那 5 个撞过顶的会话上：
| 口径 | 会话 | 实测 | 同 N 同增速、但没有天花板 | 降幅 |
|---|---|---|---|---|
| 撞过顶 | 5 | 110.6M | 200.6M | −45% |
| 从未撞顶 | 4 | 8.2M | 8.2M | 0% |
| 合计 | 9 | 118.9M | 208.9M | −43% |
降幅随步数增长：样本里长任务越多，合计降幅越大。样本越长，落在抛物线最陡那一段的量越多。
还有一个数字比降幅更值得看：治理前最长会话 162 步，治理后 537 步。
同样是 537 步、同样的增速，没有天花板要 85.6M，有天花板实测 40.29M。
把这条会话"跑得完"和"跑得省"拆开算——前者是能力，后者是账单，而能力这一项，
在"平均每会话省多少"这种指标里是彻底看不见的。
顺带把模型的可靠性也验了：锯齿模型外推到 537 步误差 −4.2%，374 步 −3.3%，305 步 −6.9%， 误差不随步数发散。一个只在 100–300 步上拟合出来的结构模型，能外推到近 3 倍长度还不垮， 说明它抓到的是机制，不是曲线。
为什么步数动不了
这是全文最容易搞错的一处。成本 = 步数 × 单价，这两招只动了单价，步数几乎没动，也基本动不了：
| 步数的来源 | 影响 | 能否治理 |
|---|---|---|
| 任务形态（交互拓扑） | 决定九成 | 否 |
| 压缩后重新摸索 | +4 步/次 × 20 次 ≈ +5% | 只能缩短 |
| 索引层（找不到 → 全盘搜） | 方向为负，量级淹没在任务构成里 | 部分 |
| 行为规则（并行、批处理） | 0，并行度 14.7% → 12.4%（剔除不可并行的长会话） | 理论可行，未落地 |
第一行是硬约束，拿个具体例子讲清楚。这批会话里有一类是逐页验证界面：每点一步都要看结果再决定下一步，是"识别 → 操作 → 确认 → 识别"的串行回路（实测 1.07 次工具/步）。每一步的输入都是上一步的输出，没有可并行的独立动作。一个 85 页的这类会话里，264 条命令只有 1 条是重复的——全是各不相同的真实交互，3.1 次调用/页。想压这个数，只能提前把页面行为写成操作脚本，那等于把被测的东西换成脚本，测试也就不成立了。所以"减少步数"这条路卡在任务形状上，不在配置上。
用"总 token 降了多少"来证明治理效果，是不成立的——那里面混着任务构成的变化。把步数当分母、单价当分子，结论成立且更明确：N 压不下来的任务，单步降价的收益最大。 4 个短会话省 0，3 个 200 步以上的会话吃掉 76% 的量、省 49%。
五、天花板合上之后，长尾没了
先解释这一节唯一的指标。"长尾比"= 后 25% 步的单步均值 ÷ 前 25% 步的单步均值。它衡量"会话跑久了，每一步要多扛多少历史"。
| 会话 | 前 25% | 后 25% | 长尾比 | 末尾 40 步占总账单 |
|---|---|---|---|---|
| A | 67,262 | 124,168 | 1.85 | 26.3% |
| B | 55,459 | 177,021 | 3.19 | 42.2% |
| C | 54,691 | 156,106 | 2.85 | 41.4% |
| E（305 步） | 71,613 | 80,135 | 1.12 | 12.0% |
治理前，跑到最后每一步相当于开局时的 2.9–3.2 倍，末尾 40 步吃掉 41–42% 的账单。
治理后是 1.12 倍，末尾 40 步只占 12.0%。（步数较短的 F、G 长尾比 1.76 / 1.00，因会话本身短，参考意义弱。）
注意这不是模型变自律了，是锯齿结构保证的：上下文永远在 48k–105k 之间回摆，不存在"扛着全部历史跑步"的状态。把门槛做进运行时，比写十条"要收口"有用。
六、代价：只要 0.7%
压缩会不会把 prompt 缓存打烂，反而更贵？实测不会。
| 项 | 实测 |
|---|---|
| 缓存命中率 | 98%（治理前同量级 89–99%） |
| 压缩次数 | 4 次 / 305 步（约 76 步一次） |
| 每次压缩的缓存重建 | 约 42k token |
| 4 次合计 | ≈168k，占 23.10M 的 0.7% |
| 摘要体积 | 1,934 token（从约 55k 原文压到 2k，28:1） |
| 压缩后下沿 | 50,926 / 47,690 / 47,884 / 43,738（稳定，无抖动） |
为了砍掉 57% 的峰值，付出 0.7% 的重建成本。 这笔账划算。
一个常见的怀疑是"后台任务等待 240 秒会把缓存等过期"。实测等 243 秒后下一步仍命中 98%。真正破坏缓存的不是时间，是改写历史。
七、边界：两招各有各的坑
任何一招都有副作用，这一节把它们写清。
压缩的代价（都不大，但要知道）：
- 压缩后容易"重新摸索"：跨压缩段的重读占全部
read的 25%（71/287），某个探针脚本在两个压缩段里被读了 8 次。压缩后平均要 4 步才回到产出动作。这是压缩的固有代价。 - 摘要密度升高：被压部分从约 58k 变 71k，同一份 2k 摘要要装更多东西，细节更易丢。
- 一次边界踩踏：某次裁剪削掉 9,051 token，把上下文从 104k 拉到 95k，掉回阈值以下，压缩被推迟 4 步，额外付了一次 71k 的重建。
- prune（主动裁剪上下文）和压缩在打架——三个会话里演了四次：裁剪把上下文削到阈值以下，但缓存前缀被改写，下一步命中率掉到 24%–57%，一次要重算 42k–74k。可 4–10 步后，压缩照样触发。裁剪省的是"9k × 剩余步数"（36k–81k），压缩就在眼前时，这笔账是亏的。
规律很清楚：prune 的收益随"距下次压缩的步数"线性缩水。削得越接近阈值，越容易变成"白付一次重算，还给压缩多制造一次缓存失效"。
索引的失效模式（比压缩更隐蔽）：
- 查不到 → 判"没有资产" → 转去全盘搜索 → token 翻倍。
- 检索命中率不是 100%：口语化提问命中 64%，剩下 36% 会走到上面那条路径。
- 索引本身会腐坏：资产改名、章节移动，索引不同步就等于没索引——所以要挂在"收尾一键刷新"里，每次改完资产必跑。
八、能直接抄的清单
- 先量再改：解析会话日志，算清"步数 × 单步成本"，别凭感觉省 token。
- 地板和上限要分开量。地板是每步固定支出，上限是历史堆积——两个数不是一个问题。
- 资产增长要和上下文增长解耦：索引的目的不是省一次，是让资产继续长、常驻不跟着长。
- 给运行时设硬门槛：阈值压缩比写规则有效一个数量级。但阈值和保留量得自己试——先攒够几十个会话，一边调一边看账单与回答质量，别照搬 10.5 万 / 2.4 万这两个数。
- 锯齿是常态。压到底再长回来，只要峰值有界就行。
- 索引必须带门禁：全空 = 0、平均命中数、"查不到→全盘搜"的比例，都要能回归。
- 索引也要敢说"不做"：构建成本高、准确率只有 1/3 的索引，比没有更危险。
- 重放公式记一条：加进上下文的 1 个 token，得乘上剩余步数。
九、写在最后
两招的排序：改运行时 > 改索引——翻成人话就是，钉天花板 > 编地图。
- 运行时管“模型想浪费也浪费不了”；索引更彻底——“模型根本不用看见”。
- 两个都不靠自觉，靠的是结构。结构写进运行时，模型绕不过去。
但结构也有天花板：这两招把单步成本从 10.7–12 万压到 7.5 万（−30%~−37%），把峰值从 24 万压到 10.5 万（−57%），对步数却一点办法都没有。
于是只剩一个问题：这 537 步里，有多少步本来就不该发生？
能搬进脚本的只有确定性循环；"先看清、再决定下一步"这类判断，只能一步步做。把长任务在里程碑处强制分段、把"试一下才知道"的探查合并成一次，动的都是分母；彼此独立的任务并行开多个会话，摊薄的则是固定成本。分母还没被撬动。
