上周我拜访了前老板，他们应该是国内做 AI 应用最深的一批公司，相应着整个团队对 AI 的应用及理解都很到位，于是乎我问了他一个问题：
老板你觉得什么是 AI 原生团队/应用，对应着团队的组织结构会有什么变化吗？
说实话，因为打招呼做得太倡促，这并不是一个好问题，因为问的太大了(无论是与模型对话，还是与高端人士对话，问对问题都很关键)，挺不好切入的…
然后对话在艰难的推进，过程中老板嫌无聊，还用 Codex 搓了个彩虹贪吃蛇，在跟我边玩边聊，最后总结下来他大概的回答是：
能用 AI 就用 AI，并且一号位要先用，这里的逻辑是对 AI 的能力边界要有清晰的判断
不可避免，这里就会涉及个问题：工作都被 AI 做了，那员工做什么呢？是不是又会引起裁员？
我本来还想小声点，担心引起不必要的麻烦，哪知道老板毫不在意，并反问了一句：
你为什么要站在员工角度去思考问题呢？为什么不站在公司角度，更进一步站在要解决的问题去思考问题呢？
事后回想起来，这里有两个核心：
-
首先，人最重要的作用其实是起心动念，也就是去许愿，思考想要解决的问题，这个是 AI 不具备的； -
其次，当前 AI 还有很多缺陷，员工/人 需要补足 AI 的能力缺陷，帮他跟世界接触，并做一部分兜底；
然后话题就进入今日的重点了，我们在员工会不会蒸馏、如何被蒸馏、蒸馏有没有用的问题上讨论了很久，大概的后续是：
我们认为，现在自媒体们或者不懂的同学在瞎扯淡，蒸馏这件事在技术上还没突破，但长久来说确实会发生
所以，我们今天的话题重点就是：蒸馏.skill。
同事.skill
虽然 OpenClaw 这阵小龙虾热潮已经褪去，但是他却大大的推动了 Agent 的整体进展，于是最近一些看不懂的行为又开始了，比如在各个群经常出现的同事 skill：
以及一些稀奇古怪的 skill：
关于 Skills 我们之前做过深入探讨，他的本质是 Workflow 的迁移，也就是 Skills 里面装的是我们的工作流，比如我们敬爱的陈果.skill：
……
于是这里问题就来了，我们在聊蒸馏.skill 的时候：
-
到底是在聊一个人的动作； -
还是一个人的工作流/思考方式/思考习惯； -
或者是承载一个人的知识，再基于知识的判断；
因为如果我们真的去拆，你会发现：
很多所谓的蒸馏同事，蒸馏出来的往往并不是一个人的完整能力，而只是他工作中最容易被整理、最容易被复用、也最容易被自动化的那部分内容。
这部分内容，通常不叫人格，不叫灵魂，也不叫组织魅力，它更接近一个词：Workflow
这也是为什么我们更多的对于蒸馏这个词嗤之以鼻了，因为你真的去了解下模型蒸馏，你会发现他们最核心蒸馏的是数据，因为：
Workflow 不是全部，SOP 也不是能力本身
没有数据的流程，也只是形式主义罢了，并不解决问题，举个例子：你是真的相信法外狂徒张三.skill 给你的建议吗？
当然，这并不是 Skills 里面完全不涉及知识，只不过他做得实在太粗了，比如陈果.skill 就额外加了一句：
你靠这个就想把果总的知识调取出来，我只能说太天真了！大家要记住：
skill 只能教 AI 怎么做，却不一定能让 AI 知道为什么这么做
而一旦问题走到这里，今天真正的主角就出来了：RAG。
RAG
在 AI 时代，RAG 是当前应用最为成功技术，而因为最近有很多新粉，我们今天再系统性的介绍下 RAG，以及为什么我们需要 RAG？
回答这个问题，我们首先要理解大模型的的特征，它是基于已有的公开知识，提前预训练好的模型，根据用户的输入来预测下一个可能出现的Token是什么。
因此，大模型有如下几个缺陷：
-
它只能回答训练时提供的知识，未参与训练的知识它是不知道的。 -
训练的知识具有时效性，截止于模型训练完成的那一刻，但是外部世界一直在发生变化，新知识模型是不知道的。 -
对于不清楚的知识，模型很容易产生幻觉，所谓幻觉就是一本正经的胡说八道 -
缺乏可解释性，在某些严肃场景（比如法律、医疗、金融），不仅需要答案，还需要追溯答案的来源。大模型无法提供其回答所依据的证据链，难以满足对可信度和可追溯性的要求。
所以，我们才说：就算你有个法外狂徒张三.skill，你也不敢信，就是这个原因。
为了解决这些问题，我们把私有知识作为提示词输入给大模型，让大模型根据私有知识来回答问题。
# 任务
按照提供的知识内容，回答用户提出的问题。
# 知识
{{ 全量知识 }}
# 要求
1. 严格依据提供的知识进行回答，确保内容客观、真实，不得编造或添加知识以外的信息。
2. 如果所提供的知识不足以回答用户问题，请直接回复“不知道”，不得尝试推测或自行补充。
这种方式确实可行，但是存在明显的问题，当我们知识非常多的时候，就有如下问题：
-
可能超出大模型的上下文限制 -
模型响应时间很长 -
Token消耗量大，成本遭不住 -
大量知识跟用户当前的问题无关，干扰信息太多，反而容易诱发模型产生幻觉
因此，更好的做法是，只把与用户问题最相关的知识作为提示词，再让大模型回答。
# 任务
按照提供的知识内容，回答用户提出的问题。
# 知识
{{ 相关知识 }}
# 要求
省略。。。。
至此大家就看出来 蒸馏.skill的缺陷所在了，他们属于一股脑将知识全部晒给模型的做法
接下来我们继续介绍 RAG 的工作原理，再说蒸馏.skill 要怎么进化：
RAG 工作原理
我用过的很多知识库或 Agent 产品，比如面向个人知识管理的 IMA、NotebookLM，面向企业知识管理的飞书知识库、钉钉知识库，甚至是我们写代码的AI编辑器Cursor、Trae、Qoder等，这些产品内部都使用了RAG技术。
除此之外，RAG还有更广泛的应用场景，比如智能客服、法律文书辅助、医疗临床辅助、金融投研分析、在线教育辅导等。
可以看到，RAG已经成为大模型连接外部知识的桥梁，从这里也可以反思市面上的各种蒸馏.skill，你就会发现他们很天真了，真这么屌国外明星 AI 公司 OpenEvidence 与 Harvey 早被干死了！
进一步，RAG内部的工作流程是怎么样的呢？我们先看整体的流程图：
从图中可以看到，整体流程分为两个大的部分，其一是知识入库，其二才是检索生成，下面我们对这两部分详细分解：
一、知识入库
知识入库我们也称之为构建索引。
拿到知识之后，首先需要对其进行数据清洗，主要是清洗知识中没有使用价值的内容，减少干扰信息，避免垃圾进垃圾出。
比如我的知识是一份带有广告和水印的 PDF 文件，我读取到的 PDF 内容是包含了所有的内容，清洗这一步就需要把广告、水印以及页头、页眉、页脚都去掉。
除此之外，我们还需要对知识中存在的一些敏感信息进行脱敏处理，比如有的企业知识库中包含了人员的姓名、电话、邮箱、身份证和密钥等信息。
PS：现阶段大家在做蒸馏.skill 的时候是有点鸡贼的，因为公众号的格式是比较好处理的
在数据清理完成后，我们需要对整个内容进行分块处理，把一份大的知识文档分解为若干个小的知识片段，这些小的知识片段将作为后面检索的最小返回单位。
分块是非常重要的，直接影响到后面的检索效果，这里也有很多分块的策略，稍后讲解。
分块完成后，就把知识片段存入到传统数据库中（MySQL、PostgreSQL、MongoDB、Elasticsearch），具体选择哪种数据库，取决于业务场景以及选择的检索策略。
然后采用异步事件，分批次把文档片段使用向量模型转化为向量。所谓向量，本质上是一组数字，用来表示文本的语义信息。语义相似的文本，在向量空间中的距离也更接近。
向量模型的作用，就是把人类语言映射到这种可计算的语义空间中，从而支持后续的语义检索。
得到向量后，在把向量和对应的文档片段在传统数据库中的ID存入到向量数据库中。
这里存储的原则是文档片段和向量分开存储，向量存在向量数据库中，文档片段存在传统数据库中，它们之间通过文档ID进行关联，这样耦合度更低，后期更换向量数据库也更加方便。
上面就是整个知识入库的全部过程，这个过程通常是离线环境进行的。
在整个流程中，有一个关键因素会直接影响最终的检索效果：分块策略。下面对这一部分做进一步展开。
分块策略
分块的核心目标是在语义完整和检索精度之间取得平衡。
如果分块太大，会引入过多无关信息，影响模型理解，向量表达变得模糊，检索精度下降。如果分块太小，语义又不完整，检索结果太碎片化。
下面是一些常见的分块策略：
| 分块策略 | 解释 | 特征 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在这些策略中，我们最为常用的是滑动窗口分块，因为实际项目中，我们拿到的原始知识文档大多数是杂乱的文档，并没有经过结构化处理，而滑动窗口这种分块方式在实现成本和效果之间相对其它方式更加平衡。
二、知识检索生成
知识检索分为多种方式，包括向量检索、全文检索、知识图谱检索、结构化数据查询等，每种检索方式的实现路径完全不同，各有优劣，不存在最优解，在生产实践中常常是组合检索方案使用。
下面是向量检索的流程：
-
使用向量模型对用户的问题进行向量化，得到文本向量 -
然后去向量数据中执行相似度搜索，召回TopK个向量节点，同时得到每个节点的相似度得分 -
拿到召回的向量节点后，根据向量节点的文档ID，去文档数据库中查询该文档ID对应的原始文档内容
通过知识检索，拿到召回的知识片段后，就可以让大模型基于这些知识片段回答用户的问题了。
这就是整个RAG从索引构建、知识检索、答案生成的全部过程，这个范式也叫做朴素RAG（Naive RAG），只不过现阶段是有很多变化的，我们也展开聊聊：
RAG范式演进
除了朴素RAG的范式，还有很多其它的RAG范式，而这些范式都是从朴素RAG演进出来的，下面我们看看RAG范式的演进逻辑：
朴素RAG
首先，朴素RAG是直接把用户的问题进行向量化，然后语义检索，在基于检索结果生成答案。但这里存在明显的问题：
第一，用户的问题往往是很宽泛的或者跟上下文语境相关，即使用了语义检索，也很难召回正确的知识片段。
第二，通过向量检索，也就是语义检索回来的内容只能说跟问题很相似，但不一定相关，因此召回的知识质量难以保证。
Advanced RAG
因此，衍生出了Advanced RAG范式，这个范式在Naive RAG范式的基础上增加了两个优化环节：
-
检索前对问题进行改写，以提升检索命中率； -
在检索后对问题进行重排和过滤，以提升召回内容的相关性和质量，从而整体增强问答效果。
Modular RAG
Modular RAG 又在 Advanced RAG 的基础上更进了一步，把整个流程节点拆分成独立的模块，比如：构建索引、检索前处理、检索过程、检索后处理、生成等模块。
通过模块化设计，我们可以根据具体业务需求灵活组合和编排 RAG 流程，从而提升系统的扩展性与可维护性。
Agentic RAG
前面这几种范式都有一个共同的特点，即按照预定义流程执行检索和生成。
而 Agentic RAG 则是把大语言模型的自主规划和推理能力与前面的RAG范式相结合，能够自主判断是否需要检索、什么时候检索以及检索什么内容，而不是按照固定的流程检索问答。
这种方式更加灵活，但是目前并没有看到很好的生产实践，如果非要说，其实最适合蒸馏.skill的技术范式就是 Agentic RAG 了。
可以看出，无论是Advanced RAG、Modular RAG还是很火热的Agentic RAG，其实整个核心原理并没有本质变化，唯一变化的只是工程范式。
下面我们更进一步，看看优化RAG效果的一些常见策略，再回归到 RAG 如何增强 Skills 的问题：
RAG优化实践
下面我们更进一步，看看优化RAG效果的一些常见策略：
查询改写
在实际场景中，如果直接拿用户原始问题去做向量检索，效果毋庸置疑一定是很差的。
原因是用户问题通常是口语化表达、上下文不完整或语义模糊、包含多种意图，这些都会直接影响检索命中率。
因此，在检索前需要进行查询改写，主要包括：消除指代词，把省略的信息补齐；把口语表达转为标准化表达；引入更利于检索的关键词；把复杂问题拆解为多个单一问题。
例如，用户先说了一句：Memo这个功能听起来很不错，然后接着又问了一个问题：它怎么使用？
这种问题无法直接检索，如果改写为“怎么使用Memo？”之后，检索效果会明显提升。
在工程实现上，查询改写一般通过大模型完成，在检索前增加一次模型调用，对问题做预处理。进一步可以采用多路查询，即针对同一问题生成多个改写版本，分别检索后合并结果，这种方式可以提升召回率。
混合检索
单一的检索方式很难在所有场景下都表现良好，因此在生产环境中，通常不会只使用向量检索或全文检索，而是采用多种检索方式组合的混合检索方案。
向量检索的优势在于能够理解语义，即使表达方式不同，也可以找到相似内容，但它的问题是对关键词不敏感，容易召回看起来相关但实际上不相关的内容。
而全文检索则刚好相反，它对关键词非常敏感，可以做到精准匹配，但缺乏语义理解能力，容易漏掉一些表达不同但语义相同的内容。
混合检索的思路是就是把这两种能力结合起来，用全文检索保证准确性，用向量检索提升召回率。
常见实现方式是并行召回，即同时执行向量检索和关键词检索，采用RRF进行融合并去重后返回TopK；也可以对不同结果进行加权排序。
工程实践中，常见的方案是使用Elasticsearch做全文检索，同时配合向量数据库做语义检索，这种方式属于最佳实践，在Coze知识库、Dify知识库、FastGPT知识库中都属于默认检索策略。
结果重排
检索得到的是一批候选知识片段，但排序不一定合理，也不一定真正相关，因此需要借助重排模型进行结果重排。
重排的目标是从看起来相似的结果中，筛选出最相关并能回答用户问题的内容，并按照相关性得分重新排序。前面的检索过程属于海选，目的是尽可能多的从知识库中召回相似的内容，而重排相当于是精选，仅保留对回答问题有价值的内容。
这里的重排模型也是一个预训练好的模型，我们输入问题和多个候选知识片段给重排模型，它会计算每个知识片段与问题的相关性得分，然后按得分排序。它相比向量检索、全文检索，计算成本更高，但精度更高。
经过重排处理后，筛选出最相关的内容再交给大模型生成答案，可以提升效果并减少幻觉。
RAG 方案选型
通过前面的介绍，我们对于RAG有了一个基本的认识，如果我们现在需要实现一个基于RAG的知识问答助手，有哪些实现方案？
1. 开发平台
知识库基本上是智能体开发平台的必备功能，比如Coze、Dify、FastGPT，RAGFlow等，这些平台把整个流程进行了产品化封装，极大的降低了使用门槛。这里以Coze为例子：
第一步：创建知识库
知识入库环节，我们只需要上传知识文档到平台，设置好分段的策略，剩下的事情平台会自动处理。
第二步：流程编排
知识入库完成后，我们进入工作流编排，平台提供了知识库检索节点，将其添加到画布中来，把这个节点的知识库来源配置为刚刚创建的知识库，然后可以设置检索策略、最大召回数量、最小匹配度、查询改写、结果重排等配置，这部分配置一般采用平台提供的默认值。
知识检索完成后，下一步，添加一个大模型节点，让大模型根据检索回来的知识回答用户的问题。
流程编排就这么简单，关键就是检索节点、大模型回答节点。
第三步：接入系统
前面两步完成后，已经具备知识问答能力了，平台也支持一键发布功能，发布完成后，用平台提供的独立的链接地址来使用这个功能，但是这里界面都是平台提供的。
如果我们需要自定义界面或者自定义一些业务逻辑，我们也可以把前面的流程以API的方式接入到我们业务系统中，相当于把这部分流程作为独立的服务。
其它的平台的使用流程也是类似，且都支持本地化部署，但是在知识库检索能力上有些差异：RAGFlow > FastGPT > Dify > Coze。
其中RAGFlow最专业，从其命名也可以看出，更偏向底层RAG引擎，上手门槛最高，适合工程化团队使用。而Coze、Dify、FastGPT更偏向Agent应用开发平台，知识库只是其能力之一。
如果没有技术背景，想快速验证想法，推荐直接使用Coze。
2. 工程化方案
这里的工程化方案是指完全通过代码来实现，在没有AI Coding之前，完全从零到一来编码实现还是很难的，但是现在有AI Coding的加持，这件事情变得也很简单。
我要实现一个基于RAG的知识问答助手，先帮我初始化项目，确保前后端项目都能正常启动，暂不实现任何具体功能
技术栈要求：
1. 后端技术栈：uv + Python + FastAPI + PostgreSQL + pgvector
2. 前端技术栈： pnpm + vite + ts + react + tailwindcss + zustand + axios
依赖三方服务：
1. 大模型：DeepSeek API
2. 重排模型：qwen3-rerank
3. 向量模型：text-embedding-v4
通过上面的提示词，我们就能完成项目的初始化搭建，后续的功能只需要按照前面讲解的流程一步步实现即可。
我们唯一需要做的是技术栈、分块策略、向量模型、重排模型、大语言模型、检索方案、向量数据库、文档存储数据库的选型。
后端语言推荐使用python，生态成熟，对于AI非常友好。
向量数据库
其次，向量数据库选型非常关键，核心是看规模、性能要求和检索策略。
如果只是学习用途，可以用轻量的组合，比如 FAISS + SQLite，这种方案部署简单、成本低，但不太适合生产使用。
如果希望快速落地、降低系统复杂度，可以直接用 PostgreSQL + pgvector。这种方式可以把向量数据和业务数据放在一起，通过 SQL 就能完成混合检索，FastGPT默认也采用的这种方案实现。
如果数据量很大，或者对检索速度要求很高（比如亿级向量、低延迟），可以把向量数据拆出去，用专用向量数据库，比如 Milvus、Weaviate、Pinecone，或者底层库 FAISS，这样可以获得更好的检索速度和扩展能力。
对于混合检索（关键词 + 向量）要求较强的场景，可以引入 Elasticsearch，使用ES + 向量库组合架构，来获得更成熟的全文检索与排序能力。
向量模型
至于向量模型，主要看向量维度和语言友好度，如果是中文场景，推荐使用国内大模型厂商的向量模型，比如阿里的text-embedding-v4，维度选择一般推荐1024维，因为1024 维度是性能与成本的最佳平衡点，适用于绝大多数语义检索任务。
对于高精度要求领域，可选择 1536 或 2048 维度。这会带来一定的精度提升，但存储和计算开销会显著增加。在对成本非常敏感的场景下，可选择 768 及以下维度。这能显著降低资源消耗，但会损失部分语义信息。
好了，至此，我们算是对 RAG 进行了简单的介绍，也只有到现在，各位才会知道，如果抛开 RAG 去聊蒸馏.skill 是一件多么天真的事情。
这里我们进入今天最后的课题：RAG 应该如何增强 蒸馏.skill？
Skills + RAG
说到这里，大家应该就非常清晰了：如果抛开 RAG 去聊蒸馏.skill，那大概率就是在搞形式主义。
所以，我们现在的任务是：
用 Skills 去承载流程，用 RAG 去承载知识，再让大模型去完成理解、衔接、生成与局部判断
进一步拆解，也就是说：
-
skill 负责定义怎么做 -
RAG 负责提供做这件事时所需的知识 -
模型负责基于流程和知识，把事情串起来
PS：这个流程是非常复杂的，所以我们这里只做简单实现
我们再回归一个“同事”完整点的流程：
-
知道什么时候该走什么流程 -
知道流程里面哪些地方需要查资料 -
知道该去哪里查 -
知道查回来的信息哪些能信、哪些不能信 -
知道最终应该如何基于这些信息给出一个相对靠谱的结论
前两步属于 skill，后面三步就开始进入 RAG 的地盘了，所以我们可以把这个事情说得再直接一点：
skill 只能教 AI 怎么做，却不一定能让 AI 知道为什么这么做；而 RAG 的价值，就是给这个为什么提供动态知识支撑
再进一步：RAG 是负责给予模型 CoT 的存在
这里特别解释一句：很多同学对 RAG 的理解，还停留在检索点资料给模型看看这个层面；
但RAG 真正的价值，不只是把资料塞给模型，而是让模型在做理解、推理、判断的时候，有机会基于外部知识展开，而不是只依赖参数记忆。
这就涉及到深水区了，也属于我们课件中最有价值的存在，但是这里只能简单说下，现实工作里，很多判断并不是靠天赋做出来的，而是靠：
-
当前任务的上下文 -
相关规则与制度 -
历史案例与先例 -
专业资料与背景知识 -
多个信息源之间的相互印证
进一步说，AI 的每一次对话，是需要有自己完善的底层逻辑的。
从这个角度你再看蒸馏.skill，很多事情就清楚了。蒸馏一个同事，最容易蒸馏出来的是：
-
他的常用操作顺序 -
他的标准 SOP -
他的固定模板
但真正难蒸馏的，是下面这些东西：
-
他为什么优先看这个文档，而不是另一个 -
他为什么知道这个客户问题要参考上个月那次事故复盘 -
他为什么会判断这个需求表面是 A，实际是 B -
他为什么知道这里不能照常规流程走
而这些东西，恰恰都和数据有关。所以：
没有 RAG 的 skill，更像是在模仿一个人的动作
有了 RAG 之后，skill 才开始有机会模仿一个人做判断时的信息组织方式
这时候，Skills + RAG 的组合才算真正开始接近工作能力这个词。
只是，需要说明的是，单独的 RAG 我们应用得已经很深了、单独的 Skills 也毫无难度，只不过这两个合起来该怎么用，我们暂时也只有简单案例，复杂的还在各种测试：
很可能答案都不是用 skill 了，skill 还有很多要升级的东西
我想的那个复杂场景，估计要 workflow 套 Agent 再套 workflow 的架构，类似于复杂的AI客服，这里不做展开
但如果不把这个问题讲得太复杂，一个 Skills + RAG 的最小闭环，大概可以这么设计：
第一步：用 skill 定义骨架流程
比如你要做一个“客服同事.skill”，skill 里面先不要上来就灌大量知识，而是先把骨架流程定义清楚：
-
识别用户问题类型 -
判断是否需要查询知识库 -
如果需要查询，则构造检索问题 -
从指定知识库中召回相关资料 -
对召回结果进行过滤与重排 -
基于结果回答用户 -
如果知识不足，则明确说不知道，或者进入人工兜底
与我们之前叙述的逻辑一致：skill 负责的是任务编排。
第二步：在关键节点接入 RAG
接下来，凡是涉及需要依据资料做判断的地方，都不要把知识写死进 prompt，而是通过 RAG 去动态取。
比如一个退款问题，看起来只是客服话术，其实后面可能要查：
-
最新退款政策 -
活动期特殊规则 -
特定渠道订单的补充说明 -
历史 FAQ -
风险案例
这些内容不可能全部塞进 skill 里，因为一旦政策更新，你整个 skill 就要跟着重写，维护成本极高。所以更合理的方式是：
-
skill 负责决定什么时候查、查什么 -
RAG 负责把相关知识拿回来 -
模型负责基于这些知识输出答案
第三步：让模型对检索结果做局部推理
多数同学做到第二步将知识丢给模型就到头了，但经过测试RAG 检索回来的东西，并不天然就能直接用。因为它可能会碰到很多问题：
-
检索回来的内容彼此冲突 -
有些资料已经过期 -
有些资料虽然相关，但并不能回答当前问题（这个最烦） -
有些资料只是辅助信息，不应该当成最终依据 -
…
所以，模型这里是要做一轮基于上下文的局部推理，这一步通常包括：
-
判断哪些资料与当前问题最相关 -
判断多个资料之间是否冲突 -
最终基于可信的资料，形成一个相对稳妥的回答 -
…
从这里再次显示了 AI 项目一个特点：更多的智能，必定带来更多的 Token…
为了回答效果，RAG 在给模型的推理链条提供外部知识支撑。
Skills + RAG 简单实践
聊完理论，我们直接上实操，一个真正能用的同事.skill，内部到底该怎么把 RAG 接进去？
这里先来个反面案例：
name: 法外狂徒张三.skill
description: 精通刑法、刑诉法，擅长辩护策略
knowledge: |
刑法第XX条：...
刑诉法第XX条：。。。
经典案例：张某某故意伤害案..
辩护策略模板：...
接下来，我们以企业客服场景为例，设计一个能处理退换货、投诉、政策咨询的客服 skill，它的内部结构大致如下：
name: 客服同事.skill
description: 处理退换货、投诉、政策咨询，支持多轮对话
rag_config:
knowledge_base: "company_kb" # 关联的知识库ID
retrieval:
top_k: 5
min_score: 0.7
rerank_model: "qwen3-rerank"
query_rewrite: true # 是否自动改写用户问题
workflow:
- step: classify_intent
prompt: |
判断用户意图，输出类别：退换货/投诉/政策咨询/其他。
如果是其他，直接进入人工兜底。
- step: retrieve_info
condition: "intent != 其他"
action: rag_search
params:
query: "{rewritten_query}" # 使用改写后的问题
filters: # 可选过滤条件
doc_type: ["policy", "faq", "case"]
- step: filter_and_reason
prompt: |
你收到了以下召回的知识片段：
{retrieved_chunks}
请完成以下任务：
1. 标记哪些片段已过期或与问题无关
2. 找出多个片段之间是否存在冲突
3. 基于最可信的1-2个片段，给出回答草稿
4. 如果信息不足，明确说“需要人工确认”
- step: generate_response
prompt: |
基于上一步的推理结果，生成最终回复。
要求：语气礼貌、信息准确、必要时提供政策链接或工单编号。
这个骨架里，skill 干了四件事：
-
分类意图 -
决定什么时候查、查什么 -
对查回来的知识做局部推理 -
生成最终回答
RAG 负责的，是第二步里那个 rag_search 动作，它背后是一整套索引、检索、重排的流水线。
关键细节：skill如何调用RAG
现阶段，skill 是声明式的，它告诉系统我需要检索，系统在运行时去执行 RAG：
- step: retrieve_info
action: rag_search
params:
query: "{user_query}"
knowledge_base: "company_kb"
top_k: 5
min_relevance: 0.75
# 高级参数
hybrid_search: true # 混合检索（向量+关键词）
rerank: true
fallback: "如果召回结果都不相关，则标记为need_human"
系统在执行这个 step 时，会：
-
对 {user_query} 做查询改写（如果配置了） -
同时执行向量检索和关键词检索 -
合并结果后用重排模型打分 -
过滤掉低于 min_relevance 的片段 -
将最终 TopK 结果以结构化数据（比如 JSON）注入到 prompt 的 {retrieved_chunks} 变量中
这样，skill 的作者并不关心 RAG 的底层实践，对 RAG 的使用跟调用一个 MCP 的服务，并没有本质的差异。
skill与多路召回
复杂的任务，同事不会只查一个知识库，比如一个产品经理.skill，可能需要同时查：
-
需求文档库 -
竞品分析库 -
用户反馈库 -
历史决策记录库 -
…
这时 skill 里可以这样写：
- step: multi_source_retrieve
action: parallel_rag
params:
sources:
- kb: "prd_kb"
query: "{user_query} 相关需求"
top_k: 3
- kb: "competitor_kb"
query: "{user_query} 竞品做法"
top_k: 2
- kb: "feedback_kb"
query: "{user_query} 用户投诉"
top_k: 5
fusion: "rrf" # 合并策略：Reciprocal Rank Fusion
系统会并行发起多次检索，然后把结果合并、去重、重排，最终交给模型。这已经接近 Modular RAG 的思路了。
基于证据的推理
然后就是最后的部分了，RAG 召回的知识片段，不能直接塞给模型就完事，类似的思路在 Hermes Agent 里其实已经能看到一些影子了，比如检索后的 summarization、memory recall 里的 reflect/synthesis：
Hermes并不只是查到就塞提示词，而是已经开始往检索后整理、综合、再利用的方向走；只不过，真正显式的证据评估与反思闭环，目前还更像一个正在补强的能力。
这里感兴趣同学请移步：《Hermes的架构解析》
好，话题回归，模型需要做局部推理，这个推理过程，其实就是在模拟一个人拿到一堆资料后的思考方式，可以把这一步单独拆成一个推理模板，嵌入 skill：
- step: evidence_based_reasoning
prompt: |
你是一个严谨的客服专员。现在有以下信息：
【用户问题】
{user_query}
【召回的知识片段】
{retrieved_chunks}
【你的任务】
1. 逐一评估每个片段：是否直接相关？是否有明确的有效期？是否与其它片段矛盾？
2. 如果存在矛盾，判断哪个片段更可信（依据：来源权威性、更新时间、与问题匹配度）
3. 基于最可信的片段，给出一个**可操作**的回答方案。如果所有片段都不足以回答问题，输出“信息不足，建议转人工”。
【输出格式】
评估结果：[片段A] 相关且有效；[片段B] 已过期；[片段C] 与A矛盾。。。
最终判断：[具体回答或转人工建议]
……
因为我们整体篇幅很长，但实操这里细节太多，就不完全展开了，大家有这个感受就好，我们最后总结下：
结语
我突然想着上周老板玩那个傻逼的彩虹贪吃蛇，为什么另外印象深刻l，为什么另外印象深刻：因为一个 CEO，去学 Coding 这件事情 ROI 很低，但他依旧在做。这件事的背后是：
能用 AI 就用 AI，并且一号位要先用，这里的逻辑是对 AI 的能力边界要有清晰的判断
这个能力边界就是：
-
AI 擅长按流程做事（skill）； -
也擅长基于给定资料做推理（RAG）；
但它不擅长凭空创造知识和自主判断该查什么资料，这需要人先起心动念，把业务逻辑拆解成 skill 和知识库的协作关系。
所以，下次再有人跟你吹我蒸馏了某某大牛.skill，你可以很客气地问他一句：
请问这个 skill 里的知识是静态写死的，还是通过 RAG 动态检索的？如果知识更新了，你的 skill 会自动同步吗？
大概率，对方会愣住，然后你就可以给他发这篇文章了。