技术 · 深入
上下文一长就变笨，到底该砍到多少？
不是砍不砍的问题，是砍到哪一格才划算
「上下文越长越聪明」是一条被实测推翻的直觉 —— 大窗口不等于等量可用的推理容量。真正的工程量在「留多少」这个数上：留太少丢信息，留太多反而降准确率。这一页把这件事变成一个可以照着设的数：先量出你的任务在几档留法下的表现，再按「最近几次工具调用 + 摘要」这条甜点线配置压缩，最后用工具装载单与子 agent 隔离两把刀把窗口的占用压下去。关键动作只有一个：把「压缩在什么时候触发」从「感觉满了」改成一条写死的阈值。
方法 · 一图看懂
1
先量再砍 — 同一批任务跑三档留法，看完成率与 token 各落在哪
2
定甜点线 — 最近几次工具调用 + 摘要，把「留多少」写成一个数
3
设触发阈值 — 按窗口占用比例触发，而不是等报错或等感觉
4
裁工具装载单 — 按任务给工具，不是把全部工具都挂上
5
隔离子 agent — 每个子任务一个干净窗口，只带它需要的
三档实测：留多少，差在哪儿
这篇 2026 年的实测把「上下文留多少」变成一个可复现的对照表（同一批任务 · 四档留法）：
① 不给用户模型的基线 —— 完成率 8.0%（模型压根不知道要干嘛）；
② 把上下文塞满 —— 完成率升到 71.0%，但代价是 1,480,996 token 与 14.56 小时；
③ 裁到最近 5 次工具调用 —— 完成率 79.0%，只要 535,274 token 与 5.39 小时；
④ 在裁到最近 5 次的基础上再加摘要 —— 完成率 91.6%，553,374 token 与 5.79 小时。
差别最刺眼的是②到③：丢掉九成以上的上下文，完成率反而涨了 8 个点、时间砍掉六成半。而③到④只多花约 1.8 万 token，又换来 12.6 个点的提升 —— 这两步才是值得花力气的地方，②那一步是纯浪费。另外一条要记住的曲线：中段信息的召回准确率会掉 30% 以上（所谓 U 形曲线，开头结尾活得好、埋在中间的先丢），所以「重要的东西放开头或结尾」不是玄学，是针对这条曲线的对策。
三把刀：阈值、装载单、子 agent
第一把 · 把触发阈值写成一个数。别等报错、也别等「感觉卡了」——按窗口占用比例触发（业界常见做法是到 85% 触发压缩与摘要），并且让全量与紧凑两态并存：活跃窗口里放紧凑版，完整版留在持久存储里供回溯与审计。
第二把 · 裁工具装载单。把全部工具都挂在 agent 上是常见做法，也是纯亏 —— 受控测试里，按任务给一份裁剪过的工具装载单，表现提升 44%。做法是给每类任务定义一个小工具集（比如「只读调研」不给写文件与执行命令），而不是让模型在几十个工具里自己挑。
第三把 · 子 agent 隔离。长流程里让每个子任务开一个干净窗口、只带它需要的那几样（目标 + 相关文件 + 必要工具），主窗口只收它的结论。这既是省 token，也是防污染 —— 子任务的中间试错不该继续占着主窗口的注意力。
两条工程纪律（比技巧更值钱）
① 确定性状态别放在提示词里。任务进度、审批状态、已完成步骤这类「不能靠模型记」的东西，要落到外部存储（生产上用关系库是主流做法，能同时装嵌套状态、事件日志与向量检索）。判据很直白：它必须能被查、能回放、能被机器校验。放到上下文里，一次压缩就可能把它弄丢，而丢了没人报错 —— 这正是下面这条的成因。
② 压缩要有「显式允许清单」。会话早期立下的安全约束、工具限制、生效中的审批、未完成的承诺，在例行压缩中会静默消失（这种失效有个名字：governance decay）—— 没有报错、没有日志，从输出上也看不出来，直到某个本该被拦住的动作为时已晚。所以压缩步骤要有一份「这几类必须存活」的白名单，而不是靠通用相关性摘要来决定留什么。
沉淀到哪里：常驻清单的写法与长度
跨会话不丢的东西应该沉淀在仓库级清单里（`AGENTS.md` / `CLAUDE.md`），但它自己也受上下文预算约束 —— 实践给的纪律是三条：① 保持在 200 行以内（超过这个量级就属于「过约束」）；② 每一条都能追溯到一个真实失败（写不出「哪次栽在这上面」的条目，多半是在写愿望）；③ 末尾加一个显式的「绝不做什么」段。
更细的领域知识不该塞进主清单，而应放进按需加载的技能包（用到才进窗口，用不到零成本）；工具与数据连接走 MCP（清单只写「什么时候用它」，不写它的接口细节）。判据一句话：常驻清单只放「每个会话都需要」的东西，其余的按需递送。
原理 · 为什么有效
上下文管理的失败，多半不是因为砍得不够，而是因为没有「留多少」的判据。量先于砍：不先跑一遍对照，你无法知道自己是浪费在「塞满」还是浪费在「留太少」—— 实测里最贵的那一档正是「全量」。阈值先于感觉：按比例触发是可复现的，「感觉满了」不是。确定性状态先于记忆：能被机器查证的东西不该交给模型记。按需递送先于常驻：一个存储是「记忆」还是「参考文档」，由它怎么被递送决定，不由存了什么决定 —— 常驻的东西越少，单次注意力越集中。
适用场景
适用：长跑 agent 与编码助手用到几十万 token · 上下文一长就答非所问 · 每隔一阵就要重开会话的人；以及正在把「上下文压缩」从手写中间件搬到托管运行时的团队。
⛔ 不适用：单轮问答与小脚本类的一次性任务 —— 那些任务本来就装不满窗口，优化它没有收益。
⚠️ 前提：你手上有一批可重复跑的任务（同一批输入 · 可判定对错），否则量不出三档差别；没有的话先攒十个，再谈调参。
自测 · 6 问
能说出你的主力任务在「全量 / 裁到最近几次工具调用 / 再加摘要」三档下的完成率与 token 差
压缩触发有一条写死的阈值（按窗口占用比例），不是靠感觉或等报错
工具装载单按任务分了几档，且每档都能说出「为什么不需要那几个工具」
子 agent 拿到的是干净窗口（目标 + 相关文件 + 必要工具），不是主窗口的全文复制
安全约束 / 生效中的审批 / 未完成承诺有一份「必须存活」的白名单，压缩后能逐条核对
常驻清单（`AGENTS.md`）在 200 行以内，且每条能追到一次真实失败
怎么上手 · 验证步骤
先只做一件事：拿你手上最常跑的那件事，量一次「留多少」 —— 同一批输入跑三档（全量 / 只留最近 5 次工具调用 / 最近 5 次 + 摘要），各记两列：完成率与总 token。三行数出来，你就知道自己现在浪费在哪一档。第二步只改一处：把压缩触发改成按窗口比例的一条阈值（例如 85%），再跑同一批任务对比。
自检动作：把改动前后各记一张表，写出「完成率变化多少 / token 变化多少 / 时间变化多少」三列。说不清这三列，就说明还没量，只是在凭感觉调。另一个旁证：改动后你的常驻清单行数应该是变少的 —— 如果它变长了，方向多半反了。