Agent Skills知识库检索是否超越传统RAG，在长尾搜索中更具优势？
- 内容介绍
- 文章标签
- 相关推荐
大家好，欢迎来到 code秘密花园我是花园老师。说实话，最近这段时间，我一直在思考一个问题：我们是不是把 RAG捧得太高了？ 摸鱼。 或者说我们是不是走错了方向？
今天这期内容， 咱们不聊那些虚头巴脑的概念，直接进入实战环节，来聊聊最近 Anthropic 推出的 Agent Skills。这玩意儿到底能不能在知识库检索这个领域，把传统的 RAG 方案按在地上摩擦？咱们拭目以待。别忘了锁定「code秘密花园」，这才是你探索 AI 世界的正确打开方式，相关链接我都放在下面了，我们都曾是...。
传统RAG的痛点
这家伙... 老朋友们大概都听腻了我的唠叨， 我本人对那种通过 Chunk + Embedding 来实现 RAG 的模式，一直持有比较大的保留意见。甚至可以说是有点“偏见”在里面的。
为什么这么说？你想想看，为了用 RAG，我们得先把好好的文档切得支离破碎，然后转化成向量存进数据库。这过程本身就像是为了喝杯牛奶，非要先养头牛一样。虽然这种方案在像长了眼睛一样自动识别到这个 Skill。 太坑了。 然后最神奇的是它会根据用户的具体需求，智能判断是不是要调用这个 Skill。通过这种模式，Agent 既能节省大量的，又能精准地响应用户需求，找到并施行特定的技能。
实战探索：知识库检索Skill
戳到痛处了。 咱们今天的主角，是一个专门用于知识库检索的 Skill。我想用它来替代传统的 RAG，去搞定一个包含多个 mdmdx 文件的文档站。咱们来看看，这种新方案到底能不能打。
这套方案的核心思路， 我们可以把它理解为一种「不预建向量库的、本地目录级、渐进式检索 RAG」。听着挺玄乎， 其实原理很朴素：，推倒重来。
- 先根据用户的问题，提取出可能需要检索的关键字；
- 直接使用
Grep命令在本地文件中搜索对应的上下文； - 分析找到的上下文，如果信息不匹配，就换关键字继续检索，最多重试五次。
它的核心特性就是这种渐进式加载策略。想象一下人类是怎么查资料的？是不是先大概翻一下觉得不对再换本书？这事儿吧，有点那个意思。
实战案例
咱们先来个硬核的，问个金融领域的具体数据问题。比如：“三一重工前三大股东是谁？”
这个数据可是藏在三一重工的 Q3 财报里的。要回答这个问题，AI 需要分析两个 Excel 表。 我给跪了。 咱们来看看这个 Skill 的表现。
体验感拉满。 当我们把问题抛出去， Agent 并没有去查询什么向量数据库，而是直接在本地文件系统里“翻箱倒柜”。由于这个文档站全是纯文本文档，检索速度简直快得飞起，而且效果出奇的好。
紧接着， 我们继续追问这个文件的问题，比如“介绍三一重工的母公司资产负债表” 。有了刚才的上下文铺垫，这次速度明显更快了。这个过程，已经非常接近我理想中 AI 智能知识检索的形态了，往白了说...。
性能对比与优化技巧
回到我们一开始的问题：它能比传统的分块+向量匹配的 RAG 效果更好吗，破防了...？
栓Q了... 从目前的实战体验来看， 在处理纯文本、结构化程度较高的本地知识库时这种基于 Agent Skills 的渐进式检索，无论是在响应速度还是在答案的准确性上，都展现出了巨大的优势。它省去了构建向量库的时间和算力成本，也避免了 Chunk 切割导致的信息丢失。
优化技巧
- 关键词提取的准确性： 告诉 AI 别瞎猜，要根据问题实体去提取。
- 的动态管理： 别一次性把所有文件都塞进去，按需加载。
当然这只是一个初步的尝试，它还有一定的缺陷。比如如果你的知识库全是扫描件图片，那 Grep 可就派不上用场了。 摆烂。 但如果你有一个固定格式的文档站，或者大量的代码库、Markdown 文档，这种方案无疑是降维打击。
这次 Agent 更快地给出了后来啊，这种体验上的提升是质的。我们甚至可以通过 Skill Creator 让它自己去分析你的文档站，然后创建出符合你文档站风格的知识检索 Skill。你只需要在已有文档站下输入特定的提示词，剩下的交给 AI 就行了。
使用 Agent Skills 做知识库检索，是一种什么体验？我觉得是“自由”。不再受限于向量数据库的维护，不再为 Chunk 的大小焦虑，让 AI 像人类一样去阅读和查找。
就这样吧... 如果本期内容对你有所帮助，希望能得到一个免费的三连支持，感谢大家！咱们下期视频教程见，继续探索 Agent Skills 的更多玩法！
大家好，欢迎来到 code秘密花园我是花园老师。说实话，最近这段时间，我一直在思考一个问题：我们是不是把 RAG捧得太高了？ 摸鱼。 或者说我们是不是走错了方向？
今天这期内容， 咱们不聊那些虚头巴脑的概念，直接进入实战环节，来聊聊最近 Anthropic 推出的 Agent Skills。这玩意儿到底能不能在知识库检索这个领域，把传统的 RAG 方案按在地上摩擦？咱们拭目以待。别忘了锁定「code秘密花园」，这才是你探索 AI 世界的正确打开方式，相关链接我都放在下面了，我们都曾是...。
传统RAG的痛点
这家伙... 老朋友们大概都听腻了我的唠叨， 我本人对那种通过 Chunk + Embedding 来实现 RAG 的模式，一直持有比较大的保留意见。甚至可以说是有点“偏见”在里面的。
为什么这么说？你想想看，为了用 RAG，我们得先把好好的文档切得支离破碎，然后转化成向量存进数据库。这过程本身就像是为了喝杯牛奶，非要先养头牛一样。虽然这种方案在像长了眼睛一样自动识别到这个 Skill。 太坑了。 然后最神奇的是它会根据用户的具体需求，智能判断是不是要调用这个 Skill。通过这种模式，Agent 既能节省大量的，又能精准地响应用户需求，找到并施行特定的技能。
实战探索：知识库检索Skill
戳到痛处了。 咱们今天的主角，是一个专门用于知识库检索的 Skill。我想用它来替代传统的 RAG，去搞定一个包含多个 mdmdx 文件的文档站。咱们来看看，这种新方案到底能不能打。
这套方案的核心思路， 我们可以把它理解为一种「不预建向量库的、本地目录级、渐进式检索 RAG」。听着挺玄乎， 其实原理很朴素：，推倒重来。
- 先根据用户的问题，提取出可能需要检索的关键字；
- 直接使用
Grep命令在本地文件中搜索对应的上下文； - 分析找到的上下文，如果信息不匹配，就换关键字继续检索，最多重试五次。
它的核心特性就是这种渐进式加载策略。想象一下人类是怎么查资料的？是不是先大概翻一下觉得不对再换本书？这事儿吧，有点那个意思。
实战案例
咱们先来个硬核的，问个金融领域的具体数据问题。比如：“三一重工前三大股东是谁？”
这个数据可是藏在三一重工的 Q3 财报里的。要回答这个问题，AI 需要分析两个 Excel 表。 我给跪了。 咱们来看看这个 Skill 的表现。
体验感拉满。 当我们把问题抛出去， Agent 并没有去查询什么向量数据库，而是直接在本地文件系统里“翻箱倒柜”。由于这个文档站全是纯文本文档，检索速度简直快得飞起，而且效果出奇的好。
紧接着， 我们继续追问这个文件的问题，比如“介绍三一重工的母公司资产负债表” 。有了刚才的上下文铺垫，这次速度明显更快了。这个过程，已经非常接近我理想中 AI 智能知识检索的形态了，往白了说...。
性能对比与优化技巧
回到我们一开始的问题：它能比传统的分块+向量匹配的 RAG 效果更好吗，破防了...？
栓Q了... 从目前的实战体验来看， 在处理纯文本、结构化程度较高的本地知识库时这种基于 Agent Skills 的渐进式检索，无论是在响应速度还是在答案的准确性上，都展现出了巨大的优势。它省去了构建向量库的时间和算力成本，也避免了 Chunk 切割导致的信息丢失。
优化技巧
- 关键词提取的准确性： 告诉 AI 别瞎猜，要根据问题实体去提取。
- 的动态管理： 别一次性把所有文件都塞进去，按需加载。
当然这只是一个初步的尝试，它还有一定的缺陷。比如如果你的知识库全是扫描件图片，那 Grep 可就派不上用场了。 摆烂。 但如果你有一个固定格式的文档站，或者大量的代码库、Markdown 文档，这种方案无疑是降维打击。
这次 Agent 更快地给出了后来啊，这种体验上的提升是质的。我们甚至可以通过 Skill Creator 让它自己去分析你的文档站，然后创建出符合你文档站风格的知识检索 Skill。你只需要在已有文档站下输入特定的提示词，剩下的交给 AI 就行了。
使用 Agent Skills 做知识库检索，是一种什么体验？我觉得是“自由”。不再受限于向量数据库的维护，不再为 Chunk 的大小焦虑，让 AI 像人类一样去阅读和查找。
就这样吧... 如果本期内容对你有所帮助，希望能得到一个免费的三连支持，感谢大家！咱们下期视频教程见，继续探索 Agent Skills 的更多玩法！