从 RAG 到 Skill：AI Agent 架构演进的技术本质与工程实践

米小虾
3 阅读9分钟

当 LLM 的 Context Window 突破 200K，当 Skill/Tool 成为 Agent 开发的主流范式，我们需要重新理解 AI Agent 的架构设计哲学。

引言：范式转移正在发生

2024-2025 年，如果你在学习 AI Agent 开发，RAG（检索增强生成）几乎是绕不开的话题。向量数据库、Embedding 模型、文档切片策略、相似度阈值调优……这些概念构成了当时 Agent 开发的知识体系。

但进入 2026 年，情况发生了根本性变化。

打开 Claude Code、OpenClaw、Cursor 等主流 Agent 开发平台的文档，你会发现 RAG 的出现频率越来越低。取而代之的是一套全新的词汇体系：Skills、Tools、MCP、Memory、Context Files、Cron、Channels。

这不是简单的技术替换，而是 AI Agent 架构范式的深层演进。本文将从技术本质出发，解析这场范式转移背后的逻辑，并给出工程实践建议。

一、RAG 的兴起与局限：一个历史视角

1.1 RAG 解决了什么问题？

RAG 诞生的背景是早期 LLM 的两个核心局限：

局限一：Context Window 太小

  • GPT-3 时代：4K tokens
  • 早期 GPT-4：8K tokens
  • 问题：无法容纳完整的知识库，必须先筛选再输入

局限二：知识截止与幻觉

  • 模型训练数据有明确截止日期
  • 无法获取实时信息
  • 容易产生事实性幻觉

RAG 的核心逻辑是：先用向量检索从大规模知识库中筛选出最相关的片段，再将这些片段作为上下文喂给 LLM。

1.2 RAG 的技术栈复杂度

一个完整的 RAG Pipeline 包含：

文档加载 → 文本分割 → Embedding → 向量存储 → 相似度检索 → 重排序 → 上下文组装 → LLM 生成

涉及的技术组件：

  • 向量数据库（Pinecone、Weaviate、Chroma、Milvus）
  • Embedding 模型（OpenAI text-embedding、BGE、M3E）
  • 文档处理（PDF 解析、HTML 清洗、分块策略）
  • 检索优化（相似度算法、重排序模型、查询扩展）

工程成本：

  • 搭建周期：1-2 天
  • 维护成本：文档更新需重新 Embedding
  • 运营成本：向量存储 + API 调用费用

1.3 RAG 的隐性成本

除了显性的技术复杂度，RAG 还有三个隐性成本：

信息损失：文档切片破坏了知识的完整性和上下文关联 延迟增加：检索环节增加了响应时间 调试困难：检索质量直接影响生成质量，问题定位复杂

二、Skill/Tool 范式：更简单，更强大

2.1 什么是 Skill/Tool？

Tool（工具）：LLM 可以调用的外部功能，通常是一个函数或 API 调用。

Skill（技能）：更高层次的抽象，是一组相关工具的集合，加上使用说明和上下文。

示例：一个 "代码审查" Skill 可能包含：

  • 读取文件工具
  • 静态分析工具
  • 代码对比工具
  • 使用说明（何时使用、输入输出格式、注意事项）

2.2 Skill/Tool 的核心优势

优势一：传播成本极低

一个 Skill 文件就是一段 Markdown 或 JSON：

# Skill: Code Review

## 描述
对代码变更进行审查，检查潜在问题

## 使用场景
- 提交代码前自检
- Code Review 辅助
- 学习优秀代码实践

## 工具
- read_file: 读取代码文件
- run_linter: 运行静态检查
- diff_files: 对比文件差异

## 示例
输入: /review src/auth.js
输出: 审查报告...

通过 GitHub 分享，别人下载即可使用，零配置。

优势二：效果直观可预期

Tool 的执行结果是确定的：

  • 调用 web_search，返回搜索结果
  • 调用 read_file，返回文件内容
  • 调用 run_code，返回执行输出

没有 RAG 中"检索是否准确"的不确定性。

优势三：与 LLM 能力自然契合

现代 LLM（GPT-4、Claude 3.5+、GLM-5.1）具备：

  • 128K-200K+ Context Window
  • 强大的长文本理解能力
  • 优秀的指令遵循能力

这让"直接处理完整信息"比"先检索再处理"更可靠。

2.3 技术对比：RAG vs Skill/Tool

维度RAGSkill/Tool
核心逻辑先检索，再生成直接调用，确定执行
复杂度高（多组件 Pipeline）低（函数/API 调用）
延迟较高（检索耗时）低（直接调用）
可解释性低（黑盒检索）高（明确输入输出）
维护成本高（需维护向量库）低（工具接口稳定）
适用场景大规模知识库查询任务执行、工具调用
传播性低（配置复杂）高（文件分享即可）

三、架构演进的底层逻辑

3.1 LLM 能力的摩尔定律

LLM 能力的提升速度远超预期：

Context Window 增长：

  • 2023：4K-8K
  • 2024：32K-128K
  • 2025-2026：200K-1M

能力边界扩展：

  • 从"文本生成"到"复杂推理"
  • 从"单轮对话"到"长程上下文理解"
  • 从"静态知识"到"工具使用学习"

3.2 技术栈的简化趋势

当底层基础设施足够强大时，中间层会被自然简化：

2019: 传统 NLP Pipeline（分词→词性标注→句法分析→语义理解）
2023: LLM 统一了 NLP 任务

2023: RAG Pipeline（复杂的多阶段检索）
2026: Skill/Tool 直接调用（LLM 原生能力足够强大）

这不是 RAG 技术本身的问题，而是技术栈自然演进的结果。

3.3 工程哲学的转变

从"预处理思维"到"原生能力思维"：

  • 旧思维：数据必须预处理（切片、Embedding、索引）才能被使用
  • 新思维：LLM 可以直接处理原始数据，预处理是可选优化而非必需

从"检索增强"到"能力扩展"：

  • 旧范式：RAG 增强 LLM 的知识获取能力
  • 新范式：Tool/Skill 扩展 LLM 的行动能力

四、工程实践：如何设计有效的 Skill

4.1 Skill 设计原则

原则一：单一职责

一个 Skill 只做一件事，做好一件事。

❌ 不好的设计：一个 Skill 既做代码审查又做文档生成
✅ 好的设计：CodeReview Skill + DocGen Skill

原则二：明确边界

清晰定义 Skill 的：

  • 输入格式
  • 输出格式
  • 适用场景
  • 限制条件

原则三：可组合性

Skill 应该可以像乐高积木一样组合：

需求分析 Skill → 架构设计 Skill → 代码实现 Skill → 测试验证 Skill

4.2 Skill 文件结构建议

# Skill: [名称]

## 元信息
- 版本: 1.0.0
- 作者: [作者]
- 更新日期: 2026-04-26

## 功能描述
[一句话描述核心功能]

## 使用场景
- [场景1]
- [场景2]

## 工具清单
| 工具名 | 功能 | 必需/可选 |
|-------|------|----------|
| tool1 | 功能1 | 必需 |
| tool2 | 功能2 | 可选 |

## 使用示例
### 示例1: [场景]
输入: [具体输入]
输出: [预期输出]

## 注意事项
- [注意点1]
- [注意点2]

## 相关 Skill
- [相关Skill1]: [说明]
- [相关Skill2]: [说明]

4.3 Skill 生态系统

观察当前主流平台的 Skill 生态：

Claude Code Skills:

  • 代码相关：review、refactor、debug、test
  • 文件操作：organize、search、analyze
  • 项目管理：plan、track、document

OpenClaw Skills:

  • 自动化：cron、webhook、workflow
  • 集成：slack、discord、telegram
  • 开发：git、docker、deploy

Cursor Skills:

  • 代码生成：component、api、test
  • 代码理解：explain、diagram、flow

五、RAG 的退场与重生

5.1 RAG 并未消失

虽然 RAG 不再是"必学技能"，但在特定场景仍有不可替代的价值：

场景一：超大规模知识库

当知识库规模超过 LLM Context Window（如企业级文档系统、法律案例库）：

  • 需要预筛选缩小范围
  • RAG 的检索环节仍有必要

场景二：精确匹配需求

需要精确检索特定条款、代码片段、数据记录时：

  • Embedding 的语义匹配 + 关键词过滤
  • 比 LLM 直接扫描更可靠

场景三：成本敏感场景

当频繁处理大量长文档时：

  • RAG 先筛选再调用 LLM
  • 比直接喂完整文档更经济

5.2 RAG 的新定位

RAG 正在从"通用方案"转变为"特定优化手段"：

2024: RAG 是 Agent 开发的必修课
2026: RAG 是工具箱中的一个可选工具

对于开发者：

  • 了解 RAG 原理仍有价值
  • 但不必作为入门门槛
  • 按需使用，而非标配

六、未来展望：Agent 架构的下一个阶段

6.1 短期趋势（6-12个月）

MCP 协议的普及

Model Context Protocol（模型上下文协议）正在成为 Skill/Tool 的标准接口：

  • 统一的工具调用规范
  • 跨平台 Skill 互操作
  • 降低生态碎片化

Skill Marketplace 的成熟

类似 VS Code Extension 的 Skill 市场：

  • 官方 curated 高质量 Skill
  • 社区贡献的多样化 Skill
  • 一键安装，即装即用

6.2 中期展望（1-2年）

Multi-Agent 协作

从单个 Agent 到多 Agent 协作系统：

  • 不同 Skill 的 Agent 分工协作
  • 类似微服务架构的 Agent 编排
  • 需要新的协调协议和通信机制

Agent 自主进化

Agent 能够：

  • 自主学习新 Skill
  • 根据反馈优化行为
  • 形成个性化的工作流

6.3 对开发者的建议

技能栈调整：

减少投入：
- 向量数据库深度调优
- Embedding 模型选型
- 复杂 RAG Pipeline 搭建

增加投入：
- Skill/Tool 设计能力
- LLM 提示工程
- 多 Agent 协作架构

学习路径：

  1. 掌握基础：LLM 原理、API 使用、Prompt Engineering
  2. 实践 Skill：从简单工具开始，逐步构建复杂 Skill
  3. 理解架构：Multi-Agent 系统、MCP 协议、协调机制
  4. 关注生态：主流平台的 Skill 市场、社区最佳实践

结语：拥抱范式转移

从 RAG 到 Skill/Tool 的演进，不是技术的倒退，而是 AI Agent 架构的成熟化。

当底层基础设施（LLM）足够强大时，简单的方案往往比复杂的方案更可靠。Skill/Tool 范式的兴起，正是这种"简单即美"哲学在 AI 工程领域的体现。

对于开发者而言，这意味着：

  • 更低的入门门槛
  • 更高的开发效率
  • 更好的可维护性

技术永远在演进，保持开放心态，拥抱范式转移，才能在这场 AI 革命中持续创造价值。

参考与延伸阅读：

  • Anthropic: Model Context Protocol Specification
  • OpenClaw: Skill Development Guide
  • Claude Code: Official Skills Documentation
  • 掘金社区相关技术文章

本文基于 2026 年 4 月的技术现状撰写，AI 领域发展迅速，建议读者关注最新动态。

avatar
文章
阅读
粉丝