通用方法 · 深入
给 AI 加的那一层，赚回了什么？
不是「要不要加」，是「加完测不测得出来」
围绕模型的这套外挂系统（harness）现在被拆成了可单独测量的部件：规划 · 工具面 · 上下文管理。问题在于，绝大多数人加层靠的是惯例和别人的经验，而不是「我这一层到底买到了什么」。这一页给你一套先点名、再单测、最后才留的取舍流程 —— 一次 176 组配对实验给出的是量化答案：上下文管理的收益几乎全部来自「防溢出」（窗口宽裕时几乎不影响结果），而且先做确定性规则裁剪、再做摘要这条最朴素的组合最有效；那个看起来很聪明的「让删掉的内容可回取」，模型很少用，也没换来精度。规划这一层则分人：弱模型靠它提精度，强模型加它主要只是省钱，还会小幅拉低成功率。⇒ 结论不是「都别加」，而是每一层都要有自己的验收点。
方法 · 一图看懂
1
点名这一层解决哪个故障 — 加层之前先写一句「它在防哪一种具体的坏结果」（溢出 · 跑偏 · 成本失控 · 交接断裂），写不出来就别加
2
造一个只变这一层的对照 — 同一个任务、同一个模型、同一套工具，只在「有这层 / 没这层」之间切换，别一次换两处
3
量三样数 — 成功率 · 总成本（token × 单价）· 以及它买到的到底是「更准」还是「没崩」—— 这两件事不是一回事
4
按上下文预算定投入 — 窗口越紧，上下文管理越值钱；窗口宽裕时把力气挪到别处
5
过了就留，没过就删 — 新模型来了要重测一次：上一代需要的脚手架，这一代可能就是纯开销
实测里最反直觉的三条
① 上下文管理主要买的是「别溢出」，不是「更聪明」 —— 研究给出的解释是它拉长了执行轨迹而不改变行为：跑不下去的现在能跑下去，但每一步做得对不对没变。② 「先规则裁剪、再模型摘要」胜过更复杂的机制：先把明显陈旧的内容按确定性规则削掉，再交给模型摘要。③ 让被删内容可以回取这条扩展听着漂亮，模型很少去取，精度也没涨 ⇒ 想省事就别造它。
规划与工具面：按模型强弱分档
同一个部件在强模型和弱模型身上的作用方向不同：规划对弱模型是精度脚手架（直接抬成功率），对强模型主要变成成本杠杆（省 token，但成功率可能略降）。工具面同理 —— 给一组预定义工具能帮「命令不太熟」的模型，而对本来就擅长的模型，只用命令行界面反而更便宜也更好，差距在命令行型任务上最大。官方 2026 年的 harness 工作把这条推到了操作层：逐层测，然后把不再产生价值的层删掉；一个直接证据是最新模型世代上，内置的任务跟踪工具被默认关掉了。
什么时候该怀疑「测不出来」
如果一层加上去之后，你只能说出「感觉顺了」，却拿不出成功率 / 成本 / 失败类型三样里的任何一个变化，那这一层就是不可验收的。还有一种情况更要注意：基准分数是整台车的圈速，不是发动机的功率 —— 同一批模型换不同外壳，成功率只动几个点，成本却能差到数倍。所以说「我们换了壳以后分数涨了」之前，先问清楚涨的是哪一项、付了多少。
原理 · 为什么有效
为什么「先测再留」比「先加再说」划算：加层同时带来三笔支出 —— 直接的 token 与延迟成本 · 每一层自己出错的概率 · 以及一层层叠上去之后没人说得清是哪层坏了的排查成本。而外挂系统的收益是按模型强弱和上下文预算变化的：同一个部件在上一个模型世代是必需品，在这一代可能正好是纯开销。⇒ 唯一稳定的做法是把它当成一次可复现的小对照，而不是一次性的架构决定。
适用场景
适用：你在给一个已经能跑的任务加结构（加规划步骤 / 加工具集 / 加压缩与摘要 / 加子代理），或者反过来，想删掉那些不知道还在不在起作用的层。
也适用：你要评估两个现成的外壳（同一批模型接进不同产品）—— 拿你自己的任务比成功率与成本，而不是看厂商幻灯片上的一个分数。
不适用：单次一问一答的轻任务（没有「层」可言），以及还没跑通第一个版本的时候 —— 先让它跑起来，再谈取舍。
自测 · 5 问
⭐ 我能用一句话说出这一层在防哪一种具体的坏结果（不是「更稳」这种空话）
⭐ 我的对照只变了一处（有这层 / 没这层），模型、工具、任务都没换
⭐ 我手里有三个数里的至少两个：成功率 · 总成本 · 失败类型的变化
⭐ 我知道它买到的是「更准」还是「没崩」—— 这两件事我分得开
⭐ 我知道下次模型换代时，哪几层要重测（而不是默认它们继续有用）
怎么上手 · 验证步骤
本周挑一层你早就想加或想删的部件：先写那一句「它在防什么」，再造一次只变这一处的对照，把三样数记一行。数不好看就直接删掉 —— 删掉一层也是这一页的合格结果。
对照跑完之后问自己一句：「如果我不告诉你我加了这层，你能从结果里看出来吗？」看不出来 ⇒ 这一层目前不值得留；看得出来但只在成本上 ⇒ 把它当省钱手段留着、别指望它提精度；看得出来在成功率上 ⇒ 留下，并写下它的验收点。