Agent做减法：显著性剪枝让脚手架更聪明

一、概念定义：它是什么

要理解“Harness剪枝”，先要理解“Harness”。

在典型的智能体（Agent）系统中，大语言模型本身只负责接收上下文、进行推理并生成输出；真正让它能“持续干活”的，是包裹在模型之外的一层协调系统。这层系统负责组织系统提示词、注册与调度工具、管理对话历史与上下文窗口、控制执行循环与终止条件、执行各类校验与兜底逻辑。业界通常把这层外层系统称为 Agent Harness，可以理解为智能体的“脚手架”或“执行框架”。

Harness剪枝，就是把神经网络剪枝（Neural Network Pruning）的思想迁移到这层脚手架上：不再以“参数权重”为剪枝对象，而是以脚手架中的功能模块——一段提示词、一个工具、一套技能、一个历史摘要器、一个执行检查器——为剪枝单位。它通过实测每个模块“在场/离场”对任务成功率与Token开销的影响，即模块的“显著性”，来决定哪些模块保留、哪些模块删除，从而在任务表现不下降（甚至提升）的前提下，降低系统复杂度和运行成本。

可以从三个视角理解这一定义：

• 技术视角：它是一种面向Agent系统的模块级结构化剪枝方法，评估粒度是“功能模块”而不是“参数”；
• 工程视角：它是一套可操作的脚手架治理流程，回答的是工程师最头疼的问题——几十个模块里，哪些该留、哪些该删；
• 成本视角：它是一种Token开销优化手段，因为脚手架中的每个模块描述、每条防错提示词，都会随每次模型调用被反复计入上下文。

二、背景与价值：脚手架为什么会膨胀

在实际工程中，修改脚手架远比重新训练模型方便，这也埋下了膨胀的种子。典型的打补丁循环是：Agent搜索失败了，就加一条防错提示词；工具调用出错了，就补一套检查规则；任务完成得不好，就再接入一个新工具或一套技能；担心上下文过长，就再挂一个历史摘要模块。新功能只进不出，旧模块极少被下线，脚手架于是越堆越厚。

膨胀的代价至少体现在四个方面：

1. Token开销持续上涨。每个工具的使用说明、每条补充提示词，都会在每一轮对话中被重复携带。模块越多，单次调用的固定成本越高。
2. 模块之间可能互相干扰。为防止某个错误而加的检查模块，可能让Agent陷入不必要的确认循环；过长的提示词也可能稀释关键指令的权重，干扰模型原本正确的执行路径。
3. 调试与维护成本升高。出错时难以定位是哪个模块引入的问题，回归测试的组合数量也随模块增加而迅速扩大。
4. 大量模块在多数任务上是“死重”。为长尾场景加的防御性模块，可能在绝大多数常规任务里从未发挥作用，却持续消耗预算。

Harness剪枝的价值在于：用可测量的数据回答“这个模块到底有没有用”，把脚手架治理从“凭直觉打补丁”转变为“凭显著性做减法”。

三、核心难点：为什么不能照搬神经网络剪枝

神经网络领域的剪枝方法已经相当成熟：通过权重大小、梯度等指标判断哪些参数不重要，移除后即可降低模型冗余。但把同样的思路搬到Agent脚手架上，会遇到两个本质差异。

第一，模块的影响是非局部、行为级的。一个权重的重要性可以用梯度局部地估计，而一个“任务完成判停工具”是否重要，取决于它对整个执行循环行为的影响，无法靠静态指标算出来，只能通过实际运行来测量。

第二，删掉模块，Token消耗反而可能更多，即存在“非单调性”。两个典型例子：

• 判停模块。Agent原本有专门判断任务是否完成的工具，完成后即停止运行。如果把它删掉，Agent可能已经找到了正确答案，却仍然不断搜索、反复调用工具，Token不降反升。
• 历史摘要模块。它本身每轮都消耗Token，但能压缩后续对话的上下文长度。如果删掉，短期内看不出坏处，长任务中每次调用模型都要携带完整历史，累积开销可能远超摘要模块自身的成本。

这两个例子说明：模块的贡献可能是“预防性”的——它的价值恰恰体现在“它在场时没有发生的坏事”上。这正是剪枝必须做双向评估、而不能只做单向移除测试的原因。

四、工作原理：双向显著性怎样定位该留的核心模块

先做形式化描述：一套脚手架可以看作模块集合 H = {m1, m2, …, mn}。剪枝的目标，是在指数级的模块子集中找到一个更小的子集，使得任务成功率不降、Token开销显著下降。朴素做法是测试所有 2^n 种组合，显然不可行；显著性方法的思路，是用对单个模块的“边际影响估计”来排序，以远小于全组合的评测预算逼近更优的子集。

其工作流程可以概括为三步：

第一步，构造探针任务集。选取一组能代表真实工作负载的评测任务，固定同一底层模型与解码配置，保证不同模块配置之间的测量结果可比。

第二步，双向测量每个模块的显著性。

• 正向（移除侧）探针：在完整脚手架上临时禁用某个模块，运行探针任务，记录成功率与Token开销的变化。若移除后表现几乎不变而开销下降，说明该模块大概率冗余；若移除后Token反而上升或成功率下滑，说明它承担着隐性职责。
• 反向（加入侧）探针：在已经精简过的脚手架上逐个加回模块，测量其“增量贡献”。这可以发现那些“单独看不重要、但在精简环境中能补齐能力”的条件性模块。

第三步，综合排序并迭代剪枝。将两个方向的测量结果合成为每个模块的显著性分数（同时考虑成功率变化与Token变化），按分数从低到高逐步移除；每移除一批就做一轮小规模回归验证，一旦关键指标明显劣化即停止，必要时把被误删的模块加回。

用示意性伪代码表达单轮迭代：

# 概念性伪代码：双向显著性评估
for m in all_modules:
    succ_rm[m], cost_rm[m] = evaluate(H_without(m))   # 正向：移除后表现
for m in kept_modules:
    succ_ad[m], cost_ad[m] = evaluate(H_min_with(m))  # 反向：加回后增量
saliency[m] = w1 * Δsucc[m] + w2 * Δcost[m]           # 合成显著性分数
next_H = 保留 saliency[m] >= 阈值 的模块

需要强调，以上是概念层面的流程示意，具体实现会因系统而异，但核心思想是统一的：不猜、不凭经验，用受控实验测量每个模块在两个方向上的真实影响，再据此做减法。

五、与神经网络剪枝及相关概念的区别

• 与神经网络剪枝的区别：剪枝对象从连续权重变为离散功能模块；影响评估从“梯度、幅值等局部代理指标”变为“实测行为影响”；评价指标从单一损失或精度变为“成功率 + Token开销 + 执行步数”等多目标。最重要的一点是，神经网络剪枝删掉参数不会“更耗算力”，而Harness剪枝存在删掉模块反而更费Token的非单调现象。
• 与提示词压缩、上下文裁剪的区别：后两者是在“文本层”做压缩，例如缩短提示词、摘要历史；Harness剪枝是在“结构层”做减法，直接移除功能模块本身。两者互补，通常先做结构层剪枝，再做文本层压缩。
• 与随意下线模块的区别：剪枝以系统性显著性评估为依据，附带回归验证与回滚机制，而不是“看起来没用就删”。

六、实证效果：减掉九成模块，表现反而更好

来自高校与工业研究机构的团队对多套业内常见的Agent脚手架做了系统性验证：在统一使用同一款大参数量语言模型、覆盖五个代表性评测任务场景的条件下，这些脚手架都能通过显著性剪枝，在任务表现基本持平的同时，将Token开销降低至少10%。

更引人注目的个案是：其中一套被测脚手架在某个综合性智能体评测基准上，把27个模块裁剪到仅保留3个，任务成功率不降反升——从约29.4%提升到35.0%，同时Token消耗下降约27.4%。

这组结果的工程含义比数字本身更重要：

1. 主流脚手架中存在大量冗余甚至有害的模块，真正支撑任务完成的核心执行回路远比想象中小；
2. “加模块就能提升表现”在很多情况下是一种错觉，收益可能来自偶发任务，而在统计意义上属于负贡献；
3. 成本与效果并非总是此消彼长，做对减法可以同时改善两者。

七、典型应用场景

• 多技能企业助手的定期治理：当助手的技能、工具与提示词条目达到数十个量级时，可按周期做一轮显著性审计，剔除长期低显著性的模块；
• 高并发、成本敏感的线上服务：客服机器人、数据处理流水线、自动化办公等场景中，Token是主要可变成本，剪枝可直接转化为账单收益；
• 表现调优与“提示词减负”：当Agent出现怪异行为时，优先排查模块间干扰，删除互相打架的检查与防错模块；
• 云上智能体应用治理：在基于百度智能云等云平台的智能体编排服务中，插件、工具与知识检索配置同样会随迭代越挂越多，同样的显著性评估思路可以直接迁移，用于裁剪编排配置；
• 版本管理与回归测试：把“模块清单 + 显著性分数”纳入版本管理，使脚手架演进像代码一样可审计、可回滚。

八、使用注意事项

1. 显著性不等于重要性。安全合规、权限校验类模块即使统计显著性很低，也可能在低频高危场景中不可或缺，应设白名单强制保留。
2. 探针任务必须有代表性。显著性估计强烈依赖任务分布，若探针集偏向简单任务，会系统性低估摘要、长程规划类模块的价值。
3. 注意模块依赖。有些模块成对工作，例如“检索工具 + 结果校验器”，单看边际影响会误判，需对小规模组合做联合验证。
4. 评估窗口要足够长。判停、摘要类模块的价值在长任务中才显现，探针任务应覆盖长短两类负载。
5. 灰度与回滚。剪枝结果应先在小流量上灰度验证，并保留原配置一键回退的能力。
6. 多指标监控。同时观测成功率、Token消耗、执行步数、超时率与用户反馈，避免只盯单一指标造成误剪。

九、总结

回到定义本身：基于显著性的Harness剪枝，是一种把剪枝思想从神经网络迁移到Agent系统层面的方法——以功能模块为剪枝单位，以“实测模块在场/离场对任务成功率与Token开销的影响”为依据，通过双向显著性评估，在不遍历全部模块组合的前提下定位该保留的核心模块。它的核心价值，是把Agent脚手架的治理从经验驱动变成数据驱动，让“做减法”成为一种可靠、可复现的工程手段。适用边界也很清楚：它适合模块数量多、负载可复现、有评测预算的系统；对模块本就精简或任务分布剧烈变化的场景，投入产出比有限。对于维护着复杂脚手架的团队而言，它提供的最大启示或许是：让Agent更聪明的路径，不总是加法，也可以是经过验证的减法。