大语言模型驱动的 Agent 正在变得司空见惯，但一个容易被忽略的瓶颈在于：当技能库膨胀到几百个条目时，Agent 到底应该如何决定加载哪些技能、按什么顺序执行？把所有技能一股脑塞进上下文，不仅开销巨大，也无法提供任何执行顺序上的结构。最近 arXiv 上的一篇论文（编号 2608.06196）直接对比了两种主流检索方案，结论颇为反直觉：精心构造的知识图谱，并没有打败一个朴素的混合排序器。
两种路线的正面交锋
论文在包含 690 个技能的语料上评估了两套系统。第一套是 混合排序器，将词法匹配与稠密向量检索结合，做稀疏的按需加载。第二套是 类型化知识图谱，把前置条件、数据流、先后顺序等工作流关系编码成带类型的边，并让 LLM 生成这些边。研究者用了 117 个现实且非回显的查询——所谓非回显，是指查询不是直白地抄技能名，而是以自然语言描述一个具体任务，这显然更贴近实际使用场景。
结果显示，混合排序器把正确技能排进前五的比例是 73.5%±8.0，意味着大约四分之一的查询没有被覆盖。而如果按照设计意图，把图谱邻居作为额外结果替换进排序器的输出（保持 token 预算一致），图谱的表现反而显著变差，差距达到 11.2 个百分点（p=0.0007）。换句话说，在同样成本下，图谱不但没有带来增益，还拖了后腿。
为什么图谱没有想象中管用
论文给出了一个很机制化的解释：图谱的候选边其实是从排序器已经搜索过的嵌入邻域里抽出来的。统计显示，98.6% 的类型化边连接的都是排序器早已同时召回的技能。也就是说，图谱能做的只是重新描述排序器已经发现的关系，并没有把检索的边界向外推哪怕一步。LLM 生成的边缘层也没能带来增量，其贡献比不过直接用本地嵌入得到的邻居。
更值得警惕的是评估方法带来的幻觉。研究者发现，如果用作者自己编写的查询来测，hit@5 会被高估最多 44 个点——这个差异足以掩盖一个方案的完全无效，让看似合理的结论变得毫无说服力。论文认为，他们的核心贡献是提供了一个机制性的说明：为什么把结构加到强排序器上并不能提升召回，以及在什么条件下结构依赖才会真正有益。
理解“为什么没用”有时候比“什么有用”更有价值。这篇论文的严谨之处在于，它把图谱的局限归结为预过滤拓扑边界，并公开了所有对比数据。
对 Agent 开发者的三个落点
- 先打磨排序器：在技能检索这件事上，一个训练良好的混合排序器可能已经拿到了大部分收益，投入图谱之前先确认检索基线的上限。
- 别让图谱变成回音壁：只有当图谱的边能引入排序器接触不到的外部信息（比如跨技能的经验规则）时，结构才值得付出额外成本。
- 用真实查询做评估：随手写几个查询来验证方案，很容易得出高估的结论。尽量收集真实使用中产生的请求，或者使用非回显的自然语言任务。
这篇文章没有推翻任何已有系统，但它给出了一个非常实用的基线数据：在大规模技能库场景下，一个不错的混合检索器可能已经解决了绝大部分问题，额外的结构化知识需要拿出更有说服力的收益来证明自己。对于正在为 Agent 设计技能层或记忆机制的团队，这是一篇值得精读的实证参考——至少可以帮你省下几个月的弯路。
评论
暂无评论
成为第一个评论的人