裁剪的代价通常被算错了
长交互的智能体系统有一个共同的成本结构：历史越长，上下文越大，每一步推理都更贵。于是裁剪成了标配动作——按时间丢旧的，按相关性丢无关的，或者干脆把前几百轮压缩成一段摘要。
这些做法都能把 token 账单压下来。问题在于，账单上的数字是其中被量化得最充分的一项，而它并不是全部的约束。9 月 15 日提交的一篇预印本把衡量的维度补齐了：任务成功率、协议遵从率、有效工具调用、token 节省、延迟下降、级联失败率，以及一个叫「关键上下文阈值」的量。
作者 Harish Gaggar 的做法是把五种策略放在同一套设置下跑，覆盖不同的保留上下文水平与工作流复杂度类别。
五种策略的结果
结果按策略分成三组，差别比预期大。
常规策略——按时间、按相关性与摘要式压缩——平均能省下约 60% 的 token，看起来是很有吸引力的数字。但同一组设置下，任务成功率落在 66.6% 到 77.3% 之间，协议遵从率落在 85.5% 到 88.6% 之间。
也就是说，这类策略大约每三到五次任务里就有一次没能完成，每六到七次里就有一次违背了流程约定。
协议保持型裁剪把任务成功率提到了 92.2%。它的做法不是换一种打分方式，而是先划出一个不可删除的集合：把协议关键状态保护起来，只对剩下的部分做相关性裁剪。
自适应预算护栏再进一步：任务成功率 96.0%，协议遵从率 96.3%，级联失败率 1.0%，平均 token 节省 56.0%。注意最后一个数字——它比常规策略省得少。这是整篇论文最值得记住的一处交换：把成功率从大约七成拉到九成六，代价是少省四个百分点的 token。
有一点需要说明：这三组数据来自同一篇论文的同一套评测设置，是纵向对比，不是跨系统的横向基准。
保留预算有一条红线
论文里另一个结论更适合直接写进工程规范。
把保留的上下文预算压到 25% 或更低时，失败几率相对保留 50% 及以上的情形高 10.92 倍，显著性水平低于 0.001。这是一个跨越了数量级的差距。
在激进预算下，协议保持型裁剪显示出 5.24 倍的成功几率优势，而自适应护栏相对固定阈值的协议保持型裁剪，再把成功几率提高 2.11 倍。
还有一条容易被忽略的发现：关键上下文阈值本身随工作流复杂度上升。也就是说，同一个保留比例，在简单任务里可能刚好够用，在复杂任务里覆盖到的关键状态就明显不足。这直接否定了「全站统一设一个保留比例」的做法。
为什么「保协议」比「多删 token」更重要
要理解这个结论，得先想清楚长交互历史里到底存了什么。
它存的不只是信息，还有四类结构性内容：指令、工具状态、中间决策，以及未解决的依赖。裁剪如果按「看起来相关不相关」来删，丢掉的最可能不是某个事实，而是某条决定后续合法性的状态——比如某个工具调用的前置条件、某个还没关闭的依赖、某次审批的结果。
这类内容的特点是当下不显眼。它就是一行状态记录，与当前正在处理的问题看起来没有直接关系。但一旦被删掉，后续步骤会以「条件已经满足」为前提继续推进，而实际上前提已经丢了。这正是协议遵从率下降的机制，也是级联失败的来源。
协议感知裁剪把这一类内容显式列成不可删集合，所以它的收益不是来自更聪明的相关性判断，而是来自承认「有些东西不该由相关性判断来决定去留」。
自适应护栏的代价
自适应做法在高复杂度类别上收益最大，这一点不难理解：复杂度越高，需要的保留预算越大，固定阈值越容易不够用。但它也有代价，而且这些代价在论文的指标表里不那么显眼。
其一是调参成本。一个随任务复杂度调整预算的控制环，本身需要参数，而参数需要数据来定。对任务种类有限、量级稳定的团队，这个成本可控；对任务分布经常变化的团队，它可能变成一个新的维护负担。
其二是可预测性下降。预算是运行时变化的，这意味着同一类任务的支出会浮动。对按用量结算、需要提前估算额度的团队，这一点需要提前考虑。
其三是它没有消除对领域知识的需求。什么算「协议关键状态」仍然要由人来定义——工具的前置条件、审批的状态、未关闭的依赖，这些概念在不同的系统里对应不同的字段。论文提供的是方法框架，不是可以直接抄的配置。
工程上可以怎么落
其一，先测量再优化。把自己的协议遵从率与级联失败率测出来，再谈节省了多少 token。没有这两个数，token 节省百分比没有太多意义。
其二，把不可裁剪清单显式写出来，并且写进代码而不是文档。工具调用的前置条件、未关闭的依赖、审批状态、会话级的授权范围，这四类是最常见的候选。
其三，给保留预算设一个下限，不要低于保留上下文的四分之一。这条线的依据是那 10.92 倍的相对几率，它在统计上很显著。
其四，按任务复杂度分档，而不是全站一个比例。既然关键上下文阈值随复杂度上升，那么复杂度低的任务可以裁得更狠，复杂的任务要留得更多——一刀切的做法在两端的表现都会不理想。
怎么在自家系统里把这两个数量出来
论文给的是方法框架，落到自己的系统上还有一段距离。有两个数字建议先量出来，因为后面所有取舍都建立在它们之上。
一个是协议遵从率。它的定义需要自己下：在一次多步任务里，有多少比例的步骤是严格按预设流程走的，包括该调的工具调了、该等的确认等了、该记的状态记了。这个指标不能靠事后看日志人工判断，否则没法持续跟踪——比较现实的做法是在流程引擎里给每个关键节点打点，按「节点被正确执行」计数。
另一个是级联失败率。它衡量的是单点错误扩散成了多大的面：一次工具调用失败之后，有多大概率导致后续若干步跟着失败。这个数字通常被低估，因为多数监控只看任务整体成功与否，不区分「一次失败」与「一次失败引发的连锁」。观测方式是把失败步骤在时间轴上的相邻关系记录下来，看失败是否成簇出现。
量出这两个数之后，判断会变得具体。如果协议遵从率本身已经在九成以下，那么无论裁剪策略多保守，收益都有限——问题不在上下文，而在流程本身没有被稳定执行。反过来，如果遵从率很高但级联失败率也高，那就说明当前的失败模式是扩散型的，裁剪下限要设得更保守。
还有一个常被忽略的检查：把裁剪策略的日志与失败样本对齐看一遍。如果失败样本里反复出现同一类被删掉的内容——比如某个反复被删又反复被需要的工具前置条件——那说明不可裁剪清单漏了一项，补上比调参数有效得多。
需要标注的边界
其一，这是单一作者的预印本，尚未见到同行评议或独立复现。
其二，评测是在受控的复杂度类别里做的，真实生产任务的分布可能不同。96.0% 是这一类设置下的最好结果，不能当作跨系统的行业基准。
其三，论文没有给出跨模型的复现结果。上下文管理的效果与具体模型的注意力行为有关，换一个模型，同一套策略的收益可能明显变化。
其四，五种策略的实现在论文中由同一作者完成，不同实现的工程成熟度可能影响结果。这一点在任何策略对比研究里都存在，读的时候需要留一份余量。
尽管有这些边界，有一条结论的方向是清楚的：在长程智能体的上下文管理上，把「省 token」当目标会把系统带偏，把「保住协议关键状态」当目标才更接近可用。这两者的排序一旦确定，具体策略的选择空间其实不大。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。