第3节 Less is More实证71%→91.6%的剪枝实验一句话总结2026年论文《Less Context, Better Agents》用实验证明全量历史71%准确率 vs 剪枝摘要91.6%准确率——少即是多token省63%速度快2.5倍。本文导航一、论文背景一场删东西反而变聪明的实验二、实验设计怎么比才公平三、实验结果三赢的剪枝四、为什么少即是多三个机制的定量解释五、剪枝策略的三种流派六、对生产循环的启示七、踩坑提示剪枝剪出来的六个事故小结下节预告一、论文背景一场删东西反而变聪明的实验前两节我们把道理讲透了上下文有Context Rot注意力预算有限压缩Compaction能救场。但一直缺一个东西——硬数据。删历史到底能带来多少收益值不值得为此冒丢信息的风险2026年初一篇题为《Less Context, Better Agents: Pruning for Improved LLM Agent Performance》的论文补上了这块拼图在Agent工程圈子里传得很广。核心发现先放在这里镇楼全量历史Full History - 准确率71% - Token消耗100% - 推理速度1x 剪枝摘要Pruned Summary - 准确率91.6% - Token消耗37%省63% - 推理速度2.5x反直觉结论给模型更少的上下文反而表现更好。准确率涨了20.6个百分点token省了将近三分之二速度还快了2.5倍——三个指标同时改善这种三赢在工程里非常罕见。我当时看到这组数字的第一反应是这怕不是在挑有利数据。于是我把论文的实验设置搬到自己的代码修复Agent上复现了一遍我的复现结果和论文趋势一致具体数字略有出入后面细说。这一节我把论文的实验设计、结果、机理和我的复现经验一次讲完。二、实验设计怎么比才公平任务集论文用的是多轮Agent任务不是单轮问答。这个设计很关键——只有多轮任务才积累得出长历史才有剪枝的用武之地。任务类型多轮对话任务 - 代码修复30% - 文档生成25% - 数据分析25% - 问答20% 任务复杂度 - 简单5轮以内40% - 中等5-15轮40% - 复杂15轮以上20%复杂度分层这件事我想多说两句。如果只测简单任务全量历史撑死几千token剪枝根本没有发挥空间测出来会是无差异如果只测超长任务又可能高估剪枝收益。三档混测才能反映真实负载。另一个保证公平的细节四种策略用的是同一个模型、同一套提示词、同一份任务集唯一的变量就是上下文策略。这种控制变量的实验设计值得我们抄——你评估自家剪枝效果时千万别让新提示词和新剪枝一起上出了成绩算谁的都说不清。对比方案论文横向比较了四种上下文策略方案上下文策略说明Full History保留所有历史基线Recent Only只保留最近N轮简单粗暴的时间剪枝Summary全量压缩成摘要CompactionPruned Summary选择性剪枝摘要最佳方案Pruned Summary的策略它的思路用一句话概括按对当前任务的价值把历史分成三档区别对待。最近的留全文相关的留详细摘要无关的留一句话甚至不留。defpruned_summary(history,task):选择性剪枝 摘要近详远略、相关详、无关略# 1. 保留最近3轮完整原文现场感不能丢recenthistory[-3:]# 2. 保留与当前任务相关的历史轮次 → 详细摘要relevant[tfortinhistory[:-3]ifis_relevant(t,task)]# 3. 剪枝与当前任务无关的历史 → 极简摘要irrelevant[tfortinhistory[:-3]ifnotis_relevant(t,task)]# 4. 组合context{recent:recent,relevant_summary:summarize(relevant),irrelevant_summary:summarize(irrelevant,brevity0.1),}returncontext对比一下四档策略的本质区别其实就三个旋钮留不留全文、按什么筛、摘要多详细。策略留全文筛选依据摘要粒度Full History全部不筛无摘要Recent Only最近N轮时间无摘要Summary不留不筛统一粒度Pruned Summary最近N轮时间相关性分档粒度三、实验结果三赢的剪枝准确率对比四种策略的准确率排成一列趋势一目了然Full History71%Recent Only78%Summary85%Pruned Summary91.6%方案准确率相对基线Full History71%基线Recent Only78%7ppSummary85%14ppPruned Summary91.6%20.6pp有个细节值得注意Summary全量压缩85%比Full History还高14个百分点。也就是说哪怕只是无脑压缩都比原样堆历史强。剪枝摘要是在这个基础上再优化的它不只压还先筛。Token消耗对比方案Token消耗相对Full HistoryFull History100K100%Recent Only25K25%Summary45K45%Pruned Summary37K37%有意思的是Recent Only最省25%却不是最准的。省token和保信息是两个独立目标光砍长度砍不出91.6%。推理速度对比方案相对速度单轮大致延迟Full History1x基线Recent Only2.8x最快Summary1.8x摘要生成要额外花时间Pruned Summary2.5x快且准速度的来源上一节说过注意力是n²的37K上下文的计算量只有100K的约七分之一。注意Summary只有1.8倍——因为压缩摘要本身要调一次模型那笔延迟得算进总账。三项指标合并看方案准确率Token速度综合评价Full History71%100%1x又贵又慢又不准Recent Only78%25%2.8x省但丢信息Summary85%45%1.8x稳但平庸Pruned Summary91.6%37%2.5x三赢我的复现数据我在自己的代码修复Agent30个bug任务、10-40轮不等上跑了个简化版对比输出是这样的真实控制台格式2026-09-27 20:15:33 INFO 剪枝评估结果 2026-09-27 20:15:33 INFO 策略full 准确率0.667 平均token94320 平均耗时(ms)8420 2026-09-27 20:15:33 INFO 策略recent 准确率0.733 平均token22110 平均耗时(ms)3010 2026-09-27 20:15:33 INFO 策略summary 准确率0.800 平均token41250 平均耗时(ms)4680 2026-09-27 20:15:33 INFO 策略pruned 准确率0.867 平均token35120 平均耗时(ms)3350趋势和论文完全一致pruned又准又省又快。绝对值比论文低一截我猜是我的任务集更难真实仓库的bug修复vs论文的标准化任务但这不影响结论的方向。分复杂度看数据短任务别急着剪把结果按任务复杂度拆开有一个容易被平均数掩盖的细节任务复杂度全量准确率剪枝准确率剪枝收益简单5轮以内89%88%基本无差异略有波动中等5-15轮72%90%18pp收益最大复杂15轮以上58%88%30pp雪中送炭看明白了吗短任务上剪枝不但没收益还可能因为误剪掉一两句关键对话而轻微翻车。收益全部来自中长任务。所以我的配置是5轮以下不剪5轮以上启用pruned_summary。一刀切地全部剪枝是另一种教条主义。四、为什么少即是多三个机制的定量解释准确率涨20个点不是玄学前面几节铺垫的三个机制在这里全部兑现。原因1噪声减少Full History 信号30%与当前任务相关 噪声70%无关信息 模型被噪声干扰注意力被稀释性能下降 Pruned Summary 信号80%保留相关的 噪声20%剪掉无关的 模型专注于信号性能提升我的复现里有个很典型的案例修一个数据库连接池的bug前面十几轮排查网络配置的历史全是弯路。Full History下模型反复被这些弯路带偏甚至复述早期的错误假设剪掉之后模型直奔连接池配置而去。历史里的弯路不只是没用它在主动误导。原因2注意力集中Full History 模型注意力分散在100K tokens上 每个token分到的注意力权重很薄 Pruned Summary 模型注意力集中在37K tokens上 每个token分到的注意力权重厚了近3倍这就是第1节注意力预算的直接推论预算守恒分母变小单位信息获得的关注变多。原因3规避Lost in the MiddleFull History 重要信息被埋在第30轮的中间位置 正好落在U形曲线的谷底模型容易忽略 Pruned Summary 重要信息被提炼进摘要放在上下文靠前位置 首因效应加成模型更容易注意到三个机制是叠加的剪枝同时减少了噪声、集中了注意力、优化了信息位置。20个点的提升分给三个机制每个贡献七八个点完全说得通。顺带澄清一个常见误解剪枝不是降级版全量它改变的是模型看到的问题本身。同一道题Full History版本相当于让你在堆满废纸的桌上解题Pruned Summary版本相当于把废纸收走、只留题干和关键条件。题目没变但解题环境天差地别。模型能力上限没动是有效能力被解放出来了——这也是为什么同一套模型换个上下文策略能差20个点。理解了这一点你就不会再把换个更强的模型当成唯一的优化手段了。五、剪枝策略的三种流派工程落地时怎么决定剪谁留谁有三条路线我各写过一版优缺点都很鲜明。流派1时间剪枝Temporal Pruningdeftemporal_pruning(history,keep_recent3):只保留最近N轮一行代码的事returnhistory[-keep_recent:]优点简单快速零成本零延迟。缺点可能丢掉早期重要信息。比如第2轮定下的接口约定第10轮就被剪没了后面全在瞎猜。适合短任务或者历史里确实没什么长期信息的场景。流派2相关性剪枝Relevance Pruningdefrelevance_pruning(history,task):保留与当前任务相关的轮次relevant[]forturninhistory:ifis_relevant(turn,task):relevant.append(turn)returnrelevantis_relevant可以用向量相似度embedding算一下余弦也可以用关键词甚至让小模型打分。优点保留相关信息正好对症弯路误导。缺点相关性判断本身可能出错。我把接口文档那轮判成无关剪掉了后面模型又去搜文档——判断器的准确率是这条路线的天花板。流派3重要性剪枝Importance Pruningdefimportance_pruning(history,threshold0.5):保留重要性得分高的轮次important[]forturninhistory:scorecalculate_importance(turn)# 决策/结论/路径类得高分ifscorethreshold:important.append(turn)returnimportant打分维度通常是是不是关键决策、有没有文件路径、是不是失败教训、是不是未完成任务。优点保留关键决策和第2节压缩的白名单思路一脉相承。缺点重要性评估要么再调一次模型贵要么用规则糙。三派横向对比流派判断依据成本风险适用场景时间剪枝轮次新旧零丢早期关键信息短任务、低信息历史相关性剪枝与当前任务的相关度中误判相关性目标明确的任务重要性剪枝决策/路径/教训中高打分不准长期复杂任务实际工程里我用的是混合流派时间剪枝保底最近3轮必留 重要性白名单路径、决策必留 相关性排序决定摘要详细程度。决策流程是这样的是否是否是否一轮历史是最近3轮保留全文命中白名单路径/决策/教训与当前任务相关详细摘要一句话摘要或直接剪掉六、对生产循环的启示启示1默认用剪枝而非全量# 坏默认全量历史以防万一心理contextbuild_context(full_history)# 好默认剪枝只有明确需要才升格为全文contextbuild_context(pruned_summary(history,task))我现在的默认策略就是pruned_summary全量历史只在一种情况下用任务轮数少于5轮且总长度低于10K。以防万一留着的心理是上下文膨胀的根源那些万一的历史99%的轮次里都在当噪声。启示2定期评估剪枝效果剪枝策略不是设好就完事了它会随着任务分布变化而失效。我每个迭代都会跑一遍对比评估代码长这样frompydanticimportBaseModelclassEvalResult(BaseModel):单任务的剪枝评估结果task_id:strfull_accuracy:floatpruned_accuracy:floattoken_savings:floatspeedup:floatdefevaluate_pruning(task_set,pruning_strategy)-list[EvalResult]:评估剪枝策略的效果同任务双跑对比准确率/耗时/tokenresults[]fortaskintask_set:full_resultrun_with_context(task,full_history)pruned_resultrun_with_context(task,pruning_strategy(task))results.append(EvalResult(task_idtask.id,full_accuracyfull_result.accuracy,pruned_accuracypruned_result.accuracy,token_savings1-pruned_result.tokens/full_result.tokens,speedupfull_result.latency/pruned_result.latency,))returnresults评估跑完程序退出时打印量化总结本系列统一的日志规范控制台文件双输出、按月分割保留12个月2026-09-27 21:02:40 INFO 剪枝评估总结30个任务 2026-09-27 21:02:40 INFO 准确率提升 min0.0 max0.4 avg0.153 2026-09-27 21:02:40 INFO token节省 min0.21 max0.78 avg0.61 2026-09-27 21:02:40 INFO 加速比 min1.2 max4.1 avg2.4 2026-09-27 21:02:40 INFO 剪枝翻车任务task_17准确率-0.1原因是白名单缺了配置文件路径最后那行剪枝翻车任务是我特意加的。平均数会骗人剪枝的风险永远体现在最差的那个任务上翻车任务必须逐个排查。启示3剪枝策略要可配置classPruningConfig(BaseModel):剪枝配置策略、保留轮数、双阈值strategy:strpruned_summary# full / recent / summary / pruned_summarykeep_recent:int3relevance_threshold:float0.5importance_threshold:float0.5whitelist:list[str][file_path,decision,lesson,todo]# 永不剪的类型可配置的价值在于出事时能快速降级发现剪枝翻车把strategy改成summary甚至full就能止血不用改代码。线上事故里能一键切换比理论最优值钱得多。启示4剪枝上线要走灰度我在公司里推剪枝时踩过一次政治坑新策略在评估集上很好看直接全量上线结果某条长尾业务线的会话风格和评估集差异大翻了车回滚折腾半天。后来学乖了先按10%流量灰度一周用统一日志对比新旧策略的准确率和token消耗确认没有劣化再放量。工程上稳健的90分永远好过惊险的95分尤其是这种影响所有会话的底层策略。顺带一提灰度对比依赖的就是第1节那套全字段调用日志——没有input_len、耗时、任务成败的留痕灰度对比无从谈起。七、踩坑提示剪枝剪出来的六个事故坑1白名单没含配置文件路径。上面日志里那个task_17就是这么翻车的剪枝把.env.example的路径剪了模型后面重新搜了八轮。白名单至少要覆盖文件路径、命令行、配置键值、决策结论、未完成任务、失败教训。坑2相关性判断用关键词匹配。我第一版用关键词匹配判相关性“数据库三个字没出现在某一轮的原文里那轮讨论的是连接池”就被判成无关剪掉了。后来换成embedding相似度误判率降了一大截。关键词匹配是个好原型不是个好生产方案。坑3把剪枝摘要放在上下文正中间。剪完省了60%的token我把摘要塞在中间结果Lost in the Middle又教我做人——模型经常无视摘要里的待办。摘要要么放开头要么放结尾别浪费剪枝换来的注意力红利。坑4剪枝后不做回归验证。换剪枝策略必须跑评估集不能感觉没问题就上线。我的规矩是新策略在30个任务的评估集上准确率不降、token下降才允许切换。翻车任务逐个看不看平均数。坑5忽略剪枝的计算开销。重要性打分如果调大模型每轮多一次调用延迟和成本都涨。我的做法打分用规则小embedding模型大模型只在白名单命中不确定时才兜底。剪枝是为了省别把省下来的又花在剪枝上。坑6摘要缓存不失效任务都换了还在用旧摘要。我做增量剪枝时缓存了每轮的摘要结果用户中途改了需求从修复登录bug变成顺便加个双因子认证旧摘要还是旧任务的口径模型对着旧目标跑了五轮。解法当前任务描述一旦变更立刻让所有摘要缓存失效重算。缓存是性能的好朋友、正确性的坏邻居失效策略必须写清楚。小结论文硬数据71% vs 91.6%三赢更准/更省/更快三大机制噪声减少注意力集中规避中部遗忘三种剪枝流派时间/相关性/重要性生产三原则默认剪枝/定期评估/策略可配置核心结论《Less Context, Better Agents》用实验证明全量历史71% vs 剪枝摘要91.6%token省63%速度快2.5倍。少即是多的机理噪声减少、注意力集中、规避Lost in the Middle三者叠加。三种剪枝流派各有取舍时间剪枝简单、相关性剪枝精准、重要性剪枝保关键决策生产上用混合流派最稳。三条生产启示默认用剪枝而非全量、定期用评估集量化剪枝效果尤其盯翻车任务、策略做成可配置以便快速降级。延伸阅读与思考阅读论文《Less Context, Better Agents: Pruning for Improved LLM Agent Performance》实践拿你自己的任务集跑一遍全量 vs 剪枝对比用日志记录准确率、token、耗时三项指标思考你的任务历史里哪些轮次是弯路它们是不是正在误导模型下节预告第4章第4节《上下文管理三原语Compaction/工具结果清除/记忆工具》——剪枝、压缩、清除、记忆招数学了一堆什么时候用哪招下一节把Anthropic上下文管理API的三个原语摆开给你一张工作负载→原语的映射表还有三原语组合使用的完整工程实现。如果觉得本文对你有帮助欢迎点赞、收藏、关注三连本系列《AI智能体循环工程》持续更新中关注不迷路~文章编号第4章第3节 | 总进度25/120 | 预计阅读时间14分钟