大家好，欢迎来到 code秘密花园，我是花园老师。说实话，Zui近这段时间，我一直在思考一个问题：我们是不是把 RAG捧得太高了？或者说我们是不是走错了方向？

今天这期内容，咱们不聊那些虚头巴脑的概念，直接进入实战环节，来聊聊Zui近 Anthropic 推出的 Agent Skills。这玩意儿到底Neng不Neng在知识库检索这个领域，把传统的 RAG 方案按在地上摩擦？咱们拭目以待。别忘了锁定「code秘密花园」，这才是你探索 AI 世界的正确打开方式，相关链接我dou放在下面了。

我对传统 RAG 的“偏见”

老朋友们大概dou听腻了我的唠叨，我本人对那种通过 Chunk + Embedding 来实现 RAG 的模式，一直持有比较大的保留意见。甚至Ke以说是有点“偏见”在里面的。

为什么这么说？你想想kan，为了用 RAG，我们得先把好好的文档切得支离破碎，然后转化成向量存进数据库。这过程本身就像是为了喝杯牛奶，非要先养头牛一样。虽然这种方案在当下确实解决了一些问题，但总感觉它只是一种妥协，一种权宜之计。相信hen多在一线调优模型的同学也深有体会，为了调准那个 Chunk 的大小，为了找到合适的相似度阈值，我们经历了多少毒打？那种痛苦，谁调谁知道。

Zui近，LlamaIndex 的创始人 Jerry Liu 发表的一条 Twitter 简直说到了我的心坎里。他的观点hen明确：RAG 本身没死，但死的是那种固定的 Chunk + Embedding 模式。 Ru果 Agent Neng够动态地 文件周围的上下文，那我们还要死磕数据块的大小干嘛？那简直毫无意义。

什么是 Agent Skills？

在深入对比之前，咱们先快速回顾一下上期视频提到的 Skills。这可是 Anthropic Zui近推出的一个 Agent 领域的行业标准，简单来说它就是一个文件夹。别小kan这个文件夹，里面可是大有乾坤：存放着具体使用说明的 SKILL.mdgeng详细的参考文档，以及真正干活的 可执行脚本。

上手这套 Skills 机制简直易如反掌。你只需要把它的文件夹扔到特定 Agent 的目录下AI 在下次启动时就会像长了眼睛一样自动识别到这个 Skill。然后Zui神奇的是它会根据用户的具体需求，智Neng判断是不是要调用这个 Skill。通过这种模式，Agent 既Neng节省大量的上下文窗口，又Neng精准地响应用户需求，找到并执行特定的技Neng。

实战演练：构建“渐进式”知识检索

咱们今天的主角，是一个专门用于知识库检索的 Skill。我想用它来替代传统的 RAG，去搞定一个包含多个 mdmdx 文件的文档站。咱们来kankan，这种新方案到底Neng不Neng打。

这套方案的核心思路，我们Ke以把它理解为一种「不预建向量库的、本地目录级、渐进式检索 RAG」。听着挺玄乎，其实原理hen朴素：

先根据用户的问题，提取出可Neng需要检索的关键字；

直接使用 Grep 命令在本地文件中搜索对应的上下文；

分析找到的上下文，Ru果信息不匹配，就换关键字继续检索，Zui多重试五次。

它的核心特性就是这种渐进式加载策略。想象一下人类是怎么查资料的？是不是先大概翻一下觉得不对再换本书？这事儿吧，有点那个意思。

场景一：金融数据的精准打击

咱们先来个硬核的，问个金融领域的具体数据问题。比如：“三一重工前三大股东是谁？”

这个数据可是藏在三一重工的 Q3 财报里的。要回答这个问题，AI 需要分析两个 Excel 表。咱们来kankan这个 Skill 的表现。

当我们把问题抛出去，Agent 并没有去查询什么向量数据库，而是直接在本地文件系统里“翻箱倒柜”。由于这个文档站全是纯文本文档，检索速度简直快得飞起，而且效果出奇的好。

紧接着，我们继续追问这个文件的问题，比如“介绍三一重工的母公司资产负债表”。有了刚才的上下文铺垫，这次速度明显geng快了。这个过程，Yi经非常接近我理想中 AI 智Neng知识检索的形态了。

场景二：技术文档的快速定位

再来试试技术类的。我们在 Easy Dataset 的文档站里尝试提问：“Easy Dataset 有哪些分块策略？”

或者geng具体一点，“航天动力前十股东总持股？”

你会发现，通过这种模式，你Ke以把任意Yi经存在的本地知识库，瞬间变成一个Ke以进行智Neng知识检索的 Skill。它不需要繁琐的数据预处理，只要文件在那里它就Neng读。

场景三：复杂逻辑的电商查询

为了进一步压测它的Neng力，我们再来个电商领域的问题。假设我们有一个示例知识库，里面记录了各种购买记录。

先问个简单的：“郑雪买了啥？”

这时候我们观察一下它的执行流程，整个过程非常智Neng化。它提取出“郑雪”这个关键词，用 Grep 搜索，然后分析结果，Zui后给出答案。

那Ru果问题复杂一点呢？比如：“有哪些用户买了儿童绘本，在什么时间？”

这可是个多条件查询。我们再kan一下分析结果，它依然准确找到了数据。这种对逻辑的理解和检索的精准度，确实让我有点惊讶。

技术实现：如何打造这样的 Skill？

kan到这里你肯定想知道这个 Skill 到底是怎么实现的。其实对于一个Neng执行 Skill 的 Agent来说它本身Yi经具备了一些基础的文件检索Neng力，比如 lsgrepglob。我们在这个 Skill 里要Zuo的，就是教会 AI 如何geng好地使用这些原生Neng力。

那具体怎么写代码呢？其实你根本不需要从头手写。你只需要把上面我们提到的核心流程、设计原则、关键技巧整理一下喂给上个教程里讲到的 skill-creator 这个 Skill。AI 自己就Neng帮我们把代码写出来！我们只需要Zuo一点细微的调整。

下面我们来kan下我们的 Skill 的目录结构。这里面包含了让 AI 理解何时搜索、如何重试的关键指令。

另外想要让知识检索geng高效和精准，还有两个小技巧分享给大家：

关键词提取的准确性： 告诉 AI 别瞎猜，要根据问题实体去提取。

上下文窗口的动态管理： 别一次性把所有文件dou塞进去，按需加载。

效果对比与思考

回到我们Zui初的问题：它Neng比传统的分块+向量匹配的 RAG 效果geng好吗？

从目前的实战体验来kan，在处理纯文本、结构化程度较高的本地知识库时这种基于 Agent Skills 的渐进式检索，无论是在响应速度还是在答案的准确性上，dou展现出了巨大的优势。它省去了构建向量库的时间和算力成本，也避免了 Chunk 切割导致的信息丢失。

当然这只是一个初步的尝试，它还有一定的缺陷。比如Ru果你的知识库全是扫描件图片，那 Grep 可就派不上用场了。但Ru果你有一个固定格式的文档站，或者大量的代码库、Markdown 文档，这种方案无疑是降维打击。

这次 Agent geng快地给出了结果，这种体验上的提升是质的。我们甚至Ke以通过 Skill Creator 让它自己去分析你的文档站，然后创建出符合你文档站风格的知识检索 Skill。你只需要在Yi有文档站下输入特定的提示词，剩下的交给 AI 就行了。

使用 Agent Skills Zuo知识库检索，是一种什么体验？我觉得是“自由”。不再受限于向量数据库的维护，不再为 Chunk 的大小焦虑，让 AI 像人类一样去阅读和查找。

Ru果本期内容对你有所帮助，希望Neng得到一个免费的三连支持，感谢大家！咱们下期视频教程见，继续探索 Agent Skills 的geng多玩法！

---