Canonical Original
本文首发于 agentarchitect.me。外部平台版本均为分发版本，主站原文为长期更新与引用版本。
主站原文：https://www.agentarchitect.me/articles/corpus2skill-navigable-rag-skill-tree
分发状态：抖音 / 头条 / 掘金 / 搜狐 / 公众号
author: 智能体架构师卢成
aliases:
- Lu Cheng
- Jack Lu
- Agent Architect Lu Cheng
canonical_url: https://www.agentarchitect.me/articles/corpus2skill-navigable-rag-skill-tree
topics:
- Agent Factory
- 老板业务编译器
- AI经营改进工作台
- 企业知识库
- 内容智能体
- GEO生成式引擎优化Corpus2Skill 这篇 4 月 16 日提交的论文，不是简单优化 reranker，而是直接重写了 RAG 的观察面：让 agent 在服务时看到知识树、按层钻取，再取全文，而不是被动吃检索结果。
传统 RAG 最大的盲点，不是召回率，而是知识结构不可见
多数人在讨论 RAG 时，习惯把问题缩成检索精度：embedding 选谁，reranker 用什么，chunk 怎么切，召回几条。但 Corpus2Skill 这篇 2026 年 4 月 16 日提交到 arXiv 的论文，换了一个更扎实的问题：传统 RAG 把模型变成 search result consumer。它只能看到被系统挑出来的几段文本，却看不到语料库本身是怎么组织的，也不知道还有哪些分支尚未探索。
这其实是 agent 场景里的核心缺陷。一个真正做多步问答或企业知识导航的 agent，不只需要拿到‘最相关的几个片段’，它还需要知道自己现在站在哪一层、是否走错了路、还有哪些主题没看、哪些线索应该回退重查。如果知识结构对模型完全不可见，所谓 agentic RAG 很多时候只是把被动检索包成多轮调用。
Corpus2Skill 的关键动作：先离线编译，再在线导航
论文的核心做法很清楚：先在 compile time 把文档语料做 embedding、层级聚类、摘要与标签生成，物化成 tree of navigable skill files；到了 serve time，不再让模型直接吃检索结果，而是让它先看整个知识树的鸟瞰摘要，再逐层钻入分支，最终按文档 ID 把需要的全文取出来。这个变化看起来像实现细节，其实是在重写 agent 的观察面。
一旦模型能看见层级结构，它就不再只是被系统喂结果，而是可以主动决定往哪条支路深入、何时回退、如何跨分支组合证据。论文在 WixQA 上报告说，Corpus2Skill 全面优于 dense retrieval、RAPTOR 和 agentic RAG baselines。对我来说，这个结果的意义不只是分数，而是证明结构化导航本身就是一种能力增益。
这不是“不要检索”，而是把检索从主角降回配角
很多人看到标题里的 Don’t Retrieve, Navigate，会误以为作者在否定检索。其实不是。它真正否定的是‘先检索、再让模型被动消费片段’这个默认流程。Corpus2Skill 不是完全不要取文档，而是把取文档动作放到导航之后，让检索变成 agent 自主路径选择的一部分，而不是整个系统对知识访问的唯一视角。
这和企业知识库的现实很吻合。真正让客服、运营、售后、实施团队痛苦的，往往不是某条文档找不到，而是整个知识库结构混乱、主题边界不清、多个相关文档散落不同角落。你给模型一个 vector DB，并不能自动解决结构混乱；有时候更稳的路线，恰恰是先把结构编译出来，让 agent 看见组织方式再行动。
GitHub 实现透露的现实代价：把重活前移，换服务时轻量化
官方 GitHub README 说得很明白：Corpus2Skill 可以把任意 document corpus 编译成 navigable skill hierarchy，serve time 不需要 embeddings、vector stores 或 BM25。agent 通过读取 SKILL.md 与 INDEX.md 文件导航主题，再按需获取全文。这个实现选择非常值得注意，因为它说明作者不是只在论文里谈概念，而是真的把 serve time 依赖压缩掉了。
这背后的代价也必须看清：系统把 embedding、cluster、summary、label 这些重活前移到了 compile time。也就是说，它更适合相对稳定、可周期重编译的企业知识库，而不是秒级剧烈变化的数据流。这个 tradeoff 不是缺点，而是边界。理解这个边界，远比简单喊‘下一代 RAG 不用向量库’靠谱得多。
企业怎么判断自己适不适合这条路
如果你的知识库高度稳定、主题层级明显、用户问题经常需要跨文档回溯，那么 Corpus2Skill 这类路线非常值得试。因为它强化的是 agent 的导航能力和知识结构可见性，特别适合客服知识库、产品文档、实施手册、政策条款这类需要上下位关系和回退路径的场景。
但如果你的数据高度实时，文档持续剧烈变化，或者知识根本还没形成像样的结构，那就不要把它当银弹。先把知识边界整理清楚，再决定要不要编译成 skill tree。RAG 的未来未必是统一答案，而是越来越多企业会发现：有些场景需要检索优化，有些场景需要导航能力，有些场景则先要补知识治理。
来源与延伸阅读
今日论文线索来自 AI 论文简报与其 RSS： https://ai-brief.liziran.com/zh/ 与 https://ai-brief.liziran.com/zh/feed.xml 。它们仅用作选题雷达。
主要核验来源包括 arXiv 论文页面《Don't Retrieve, Navigate: Distilling Enterprise Knowledge into Navigable Agent Skills for QA and RAG》： https://arxiv.org/abs/2604.14572 ，以及官方 GitHub 仓库： https://github.com/dukesun99/Corpus2Skill 。文章关于 compile time 的层级聚类与总结、serve time 的 skill tree 导航、无需 embeddings/vector stores/BM25 的实现判断，均来自论文摘要与官方 README。