我们训练了一个代码语义高亮模型SWE-Pruner并开源了配套的Agentic接入框架，在真实的Coding Agent多轮任务（SWE-bench, SWE-QA）上，在保持性能不变甚至提升的情况下提供多轮场景下30%甚至更多的token开销减少。该模型基于语义理解，自动识别并高亮检索到的文档中语义相关的句子。而框架作为agentic的接入层，可以轻松接入claude code，openhands等SOTA agent系统
在本文中，我们将分享我们的技术方案。
在先前的RAG工作中，上下文的粗粒度膨胀已经是一个很严重的问题 https://huggingface.co/blog/zilliz/zilliz-semantic-highlight-model
在生产环境中的 RAG 系统中，一个典型的查询会检索 10 个文档，每个文档包含数千个词元，每次查询消耗数万个词元。问题在于： 只有几十个句子真正包含相关信息 ，其余的都是噪声，这会增加成本并降低答案质量。
然而，对于真实环境下的软件工程任务，问题甚至更加严重：一个典型的查询可能涉及上百个代码文件，而一些大型项目中，巨型文件的代码token包含的远不止数千个，现代的编程agent却仍然在广泛使用关键词匹配的方法，即grep，来对大型代码仓库进行探索，匹配项的过分庞大使得现代agent中都配备了相当多的上下文硬截断逻辑
在人工智能代理场景中，这个问题会变得更加严重，因为查询是经过推理和分解后的复杂指令。传统的高亮显示方式只是机械地标记匹配的词语，却会遗漏真正有价值的分析结论。
这就迫切需要一种有针对性的高亮模型，该模型仅保留上下文相关的代码，并高亮显示它们，同时剪掉所有无关的噪声内容——这种技术也被广泛称为上下文剪枝。类似的纯文本任务也被Provence为代表的一系列工作较为完善地解决，但对于究竟如何在代码任务上引入语义高亮模型，社区尚未给出一个答案。
我们调研了现有的解决方案，但发现它们并不完全符合我们的需求。