一个正在发生的剧变：RAG 还没搞明白，Skill 又来了；MCP 刚接完，A2A 又出了。但冷静想想——如果每个业务接口都能被 AI 理解和调用，我们还需要"知识库"吗？大模型 + Skill + OpenClaw，能不能一句话搞定以前的所有操作？本文试图回答这个问题，并对三条技术路线做一次系统性的比较、归类和未来判断。
一、先搞清楚：Skill 到底是什么？
1.1 从一个场景说起
你在 Cursor 里写代码，说了一句："帮我把这个 React 组件改成 Vue 3 的 Composition API 风格"。
AI 做到了。但它为什么做得到？不是因为它"什么都会"，而是因为它在运行时加载了一份 SKILL.md——一个教它"这件事该怎么做"的标准化指令文件。
这就是 Skill。
1.2 Skill 的标准化定义
Agent Skills 是一个开放标准，由 Anthropic 发起，2026 年已被 OpenAI Codex、GitHub Copilot、Cursor、Gemini CLI、VS Code 等 27+ 主流 AI 工具采纳。它的核心产物是一个文件夹：
my-skill/
├── SKILL.md # 必需：元数据 + 指令（给 AI 看的"操作手册"）
├── scripts/ # 可选：可执行脚本
├── references/ # 可选：参考文档
├── assets/ # 可选：模板、资源文件
└── ...
一个最小的 SKILL.md 长这样：
---
name: vue3-migration
description: >
将 React 组件迁移为 Vue 3 Composition API 风格。
在用户请求 React 到 Vue 迁移时激活。
compatibility: cursor, claude-code, codex
---
## 步骤
1. 分析 React 组件的 props、state、effects
2. 映射为 Vue 3 的 defineProps、ref/reactive、onMounted
3. 将 JSX 转换为 template 语法
4. 保留原有的类型定义（TypeScript）
## 约束
- 不要使用 Options API
- 保持组件文件名不变
- ...
本质上，Skill 是给 AI Agent 的标准化"操作手册"——人类可读、机器可解析、平台可移植。
1.3 Skill 的三层加载机制
这是 Skill 区别于"把所有指令塞进 System Prompt"的核心设计：
┌─────────────────────────────────────────────────────┐
│ Layer 1: 发现（Discovery） ~100 tokens │
│ AI 只读 name + description，判断是否需要激活 │
├─────────────────────────────────────────────────────┤
│ Layer 2: 激活（Activation） <5000 tokens │
│ 加载完整 SKILL.md 内容，理解操作步骤和约束 │
├─────────────────────────────────────────────────────┤
│ Layer 3: 执行（Execution） 0 额外 token │
│ 运行 scripts/ 中的代码，消耗的是计算而非上下文 │
└─────────────────────────────────────────────────────┘
这个渐进式披露（Progressive Disclosure） 设计极其关键——它让 Agent 能同时"认识"上千个 Skill，但只在需要时才真正加载，解决了上下文窗口的稀缺性问题。
1.4 Skill 的本质：过程性知识的封装
| 知识类型 | 含义 | 典型例子 | 最佳载体 |
|---|---|---|---|
| 陈述性知识（Know-What） | 事实、数据、规则 | "公司差旅报销标准是 800 元/天" | RAG / 知识库 |
| 过程性知识（Know-How） | 操作步骤、工作流 | "如何从零部署一个 K8s 集群" | Skill |
| 连接性知识（Know-Where） | 系统在哪、API 怎么调 | "ERP 系统订单接口是 /api/v2/orders" | MCP |
Skill 封装的是"怎么做"，不是"是什么"。 这是它与 RAG 的根本分界线。
二、Skill vs RAG：不是替代，是分工
2.1 先说结论
Skill + MCP 不会消灭 RAG，但会让 RAG 的领地大幅缩小。
这话怎么理解？看这张图：
AI 处理一个用户请求的决策树
"帮我查一下上季度华东区销售额，
然后按客户分级做个分析报告"
│
┌───────────────┼───────────────┐
▼ ▼ ▼
需要什么？ 需要什么？ 需要什么？
数据（事实） 工具（能力） 流程（方法）
│ │ │
▼ ▼ ▼
RAG MCP/API Skill
查知识库 调用 CRM 接口 "销售分析报告"
获取背景信息 拿到原始数据 的标准操作流程
│ │ │
└───────────────┼───────────────┘
▼
综合生成最终报告
2.2 六维对比
| 维度 | RAG | Skill | 谁更适合 |
|---|---|---|---|
| 解决的问题 | AI 不知道的"事实" | AI 不会的"操作" | 不同问题 |
| 知识类型 | 陈述性（What） | 过程性（How） | 互补 |
| 基础设施 | 向量数据库 + Embedding + Retriever + Reranker | 一个文件夹 + Markdown | Skill 极简 |
| 运维成本 | 高（需持续更新索引、优化检索） | 低（改文件即生效） | Skill 胜 |
| 实时性 | 取决于索引更新频率 | 即时（改了就生效） | Skill 胜 |
| 可靠性 | 检索可能"漏掉"或"找错" | 步骤是确定性的 | Skill 胜 |
| 适用范围 | 海量非结构化文档 | 标准化的操作流程 | 各有擅长 |
| Token 消耗 | 检索结果注入上下文（大） | 渐进式加载（小） | Skill 胜 |
2.3 RAG 不会死，但会"退居二线"
2026 年 3 月，一个有趣的现象正在发生：
上下文窗口从 4K → 128K → 1M → 10M，很多人以为 RAG 会被长上下文替代。但实际情况是：
- "大海捞针"问题没解决：模型对窗口中段信息的遗忘率高达 30-40%，10M tokens 的干草堆里找针更难
- 成本天差地别：RAG 检索 Top-5 段落注入上下文 ~2K tokens；全文塞入可能 500K tokens——成本差 250 倍
- 延迟不可接受：100K tokens 输入的推理延迟 30-60 秒；RAG 检索 + 生成约 1-3 秒
所以 RAG 的核心价值——精准检索、成本控制、低延迟——在可预见的未来不会被替代。但它的"地盘"正在被 Skill 和 MCP 蚕食：
2023 年：你有问题 → RAG 知识库 → 找答案 → 返回
2026 年：你有问题 → Skill 判断操作流程
→ MCP 调用业务接口获取真实数据
→ RAG 只在需要"背景知识补充"时才介入
→ Agent 综合执行并返回结果
RAG 从"主角"变成了"配角"。不是不需要它，而是它不再是唯一手段。
三、OpenClaw：当 Skill 遇上一个自治 Agent
3.1 OpenClaw 是什么
OpenClaw 是 2025-2026 年最火的开源 AI Agent 框架之一（GitHub 325K+ stars），它做了一件很纯粹的事：
把 LLM 从"对话框"里解放出来，让它直接操作你的电脑、你的文件、你的所有通信平台。
- 本地运行，数据完全私有
- 对接 50+ 通信平台（微信、钉钉、Slack、Telegram、Email……）
- 通过 Heartbeat 机制 每 30 分钟自动检查任务——真正的自治 Agent
- 模型无关：OpenAI、Claude、本地 Ollama 随便切
3.2 OpenClaw 的 Skill 生态：ClawHub
ClawHub 是 OpenClaw 的 Skill 市场，类似 npm / VS Code Extensions 的定位：
| 维度 | 数据 |
|---|---|
| 上架 Skill 数量 | 5,700+ |
| 活跃开发者 | 800+ |
| 日均安装量 | 15,000+ |
| 覆盖类别 | 生产力、开发工具、浏览器控制、邮件、日历、企业集成 |
一个 OpenClaw Skill 的结构：
my-skill/
├── claw.json # 清单文件（名称、描述、权限声明）
├── instructions.md # AI 指令
├── handlers/ # 消息处理逻辑
└── tools/ # 工具函数
安装一个 Skill：openclaw skills install daily-report-generator
从此，你对 OpenClaw 说一句 "帮我生成今天的日报"，它就能自动汇总你的 Git 提交、日历事件、消息记录，生成一份结构化的日报。
3.3 回答那个核心问题
如果所有业务接口都做成 Skill，加上 OpenClaw，是不是就不需要知识库了？
答案是："几乎"可以，但有一个前提和两个例外。
前提：你的业务接口能覆盖所有需要的"事实查询"——即 Skill 调接口拿到真实数据，而非从文档里"检索"数据。
传统方式：用户问"上季度销售额" → RAG 检索季报文档 → 找到数字 → 返回
Skill 方式：用户问"上季度销售额" → Skill 调用 CRM API → 拿到实时数据 → 返回
当数据有 API 可查时，Skill + API 调用天然比 RAG"猜"文档更准确、更实时。
例外一：非结构化的"经验知识"——公司文化、历史决策背景、技术选型原因、那些只存在于 Wiki/Confluence 里的知识——这些东西没有 API，Skill 够不着，RAG 仍然不可替代。
例外二：海量文档的"模糊搜索"——"找一下去年关于数据安全的所有讨论"，这种需要在大量非结构化文本中做语义匹配的场景，是 RAG 的主场。
所以更准确的表述是：
Skill + MCP 消灭的不是 RAG，而是那些"本不该用 RAG 做、用 API 调用才对"的伪 RAG 场景。
四、三条路线的深度比较：Skill vs MCP vs RAG
4.1 一张图说清三者关系
┌──────────────────────────────────────────────────────────────┐
│ AI Agent 运行时 │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌──────────────────────┐ │
│ │ Skill │ │ MCP │ │ RAG │ │
│ │ ───── │ │ ───── │ │ ───── │ │
│ │ "大脑" │ │ "双手" │ │ "记忆" │ │
│ │ 教AI怎么想 │ │ 让AI能做到 │ │ 帮AI想起来 │ │
│ │ │ │ │ │ │ │
│ │ 过程性知识 │ │ 工具连接 │ │ 陈述性知识 │ │
│ │ 操作流程 │ │ API调用 │ │ 文档检索 │ │
│ │ 最佳实践 │ │ 系统交互 │ │ 事实补充 │ │
│ │ │ │ │ │ │ │
│ │ Markdown驱动│ │ JSON-RPC协议│ │ Embedding+向量检索 │ │
│ └──────┬──────┘ └──────┬──────┘ └──────────┬───────────┘ │
│ │ │ │ │
│ └────────────────┼─────────────────────┘ │
│ ▼ │
│ LLM 综合决策 + 行动 │
└──────────────────────────────────────────────────────────────┘
4.2 技术维度全面对比
| 维度 | Skill（Agent Skills） | MCP（Model Context Protocol） | RAG |
|---|---|---|---|
| 发起者 | Anthropic → 开放标准 | Anthropic → Linux Foundation | 学术界 → 工业界 |
| 本质 | Prompt 扩展（结构化指令） | 通信协议（JSON-RPC 2.0） | 检索管道（Retrieve+Generate） |
| 解决什么 | AI 不知道"怎么做" | AI 够不着"外部系统" | AI 不知道"是什么" |
| 开发成本 | 极低（写 Markdown） | 中（开发 MCP Server） | 高（向量库+Embedding+检索链） |
| 运行时成本 | 低（渐进式加载 <5K tokens） | 低（按需调用） | 中-高（检索+注入 2-10K tokens） |
| 实时性 | 即时（改文件生效） | 实时（调 API 拿数据） | 滞后（取决于索引更新） |
| 确定性 | 高（步骤明确） | 高（API 调用确定） | 低（检索可能不准） |
| 标准化程度 | 高（agentskills.io 规范） | 高（开放协议） | 低（各家实现不同） |
| 生态规模（2026.03） | 27+ Agent 工具支持 | 97M+ 月下载，5800+ Server | 碎片化生态 |
| 上手门槛 | 会写 Markdown 就行 | 需要后端开发能力 | 需要 ML/检索工程能力 |
4.3 Skill vs MCP：不是竞争，是共生
这两者的关系，用一个比喻最清楚：
Skill 是菜谱，MCP 是厨具。
菜谱告诉你"先热锅、再下油、然后爆蒜"（操作流程）；厨具让你"能切、能炒、能装盘"（执行能力）。没有菜谱，有厨具也不知道做什么菜；没有厨具，看着菜谱也做不出来。
在代码层面：
用户：帮我把这个客户订单状态改为"已发货"，然后通知客户
Skill 提供： MCP 提供：
┌────────────────────────┐ ┌────────────────────────┐
│ 1. 验证订单是否可发货 │ ──调用──▶ │ CRM MCP Server │
│ 2. 更新订单状态 │ ──调用──▶ │ → PATCH /orders/{id} │
│ 3. 生成发货通知内容 │ │ │
│ 4. 通过客户偏好渠道发送 │ ──调用──▶ │ Notification MCP Server│
│ 5. 记录操作日志 │ ──调用──▶ │ → POST /notify │
└────────────────────────┘ │ Log MCP Server │
教AI"怎么做" │ → POST /audit-log │
└────────────────────────┘
让AI"做得到"
4.4 Function Calling 在这张图里的位置
Function Calling 是 LLM 层面的原子能力——模型输出结构化 JSON 来调用一个函数。它是 MCP 和 Skill 的底层基座：
抽象层级
▲
│ ┌─────────────┐
高 │ │ Agent Skills │ "做这件事的标准流程是什么"
│ │ (编排层) │
│ ├─────────────┤
│ │ MCP │ "要用的工具在哪、怎么调"
│ │ (连接层) │
│ ├─────────────┤
│ │ Function Call │ "模型输出JSON，调用一个函数"
低 │ │ (原子层) │
│ └─────────────┘
│
2026 年的一个重要演进：JSON Function Calling 正在被 Programmatic Tool Calling 取代——模型不再输出 JSON 参数，而是直接生成可执行代码来调用工具，减少延迟和 Token 消耗。Anthropic 的 Claude 4.6 Sonnet 已经支持这种模式。
4.5 A2A（Agent-to-Agent）：更上一层
如果说 Function Calling 解决单步调用、MCP 解决工具连接、Skill 解决操作流程，那 A2A 解决的是：
"这件事不该我做，该交给另一个更专业的 Agent。"
协议栈全景
┌──────────────────────────────────────┐
│ A2A (Agent-to-Agent) │
│ Agent 发现 · 任务委派 · 协作 │
│ "谁来做" │
├──────────────────────────────────────┤
│ Agent Skills │
│ 操作流程 · 最佳实践 · SOP │
│ "怎么做" │
├──────────────────────────────────────┤
│ MCP (Model Context Protocol) │
│ 工具发现 · API连接 · 数据访问 │
│ "用什么做" │
├──────────────────────────────────────┤
│ Function / Tool Calling │
│ 单步调用 · 结构化输出 │
│ "伸手做一下" │
└──────────────────────────────────────┘
这四层不是替代关系，而是自底向上的递进关系。企业 AI 中台需要全部支持。
五、Skill 化：存量软件世界的 AI 接入方案
5.1 一个残酷的事实
全球企业软件市场的存量是惊人的：
- 全球企业 IT 支出中，70%+ 用于维护存量系统
- 平均一家中型企业使用 100-200 个 SaaS/内部系统
- 大量核心系统（ERP、CRM、MES、OA）建设于 5-15 年前
这些系统都有 API（或者可以包一层 API），但它们之间的协同、自动化、智能化程度极低。
AI 的真正战场不是从零建新系统，而是让这些存量系统"活"起来。
5.2 三步走：API → MCP → Skill
Step 1: API化（如果还没有的话）
┌──────────┐ ┌──────────┐
│ 传统系统 │ ──▶ │ REST API │
│ (内部系统) │ │ 接口层 │
└──────────┘ └──────────┘
很多企业已经在这一步
Step 2: MCP化（让 AI 能"够得着"）
┌──────────┐ ┌──────────┐ ┌──────────┐
│ REST API │ ──▶ │ MCP │ ──▶ │ AI Agent │
│ 接口层 │ │ Server │ │ 可以调用 │
└──────────┘ └──────────┘ └──────────┘
接口标准化，AI 工具可发现、可调用
Step 3: Skill化（让 AI "知道怎么用"）
┌──────────┐ ┌──────────┐ ┌──────────┐
│ MCP │ │ Skill │ │ AI Agent │
│ Server │ ◀── │ (流程编排) │ ◀── │ 理解业务 │
│ 提供能力 │ │ 知道何时 │ │ 语义 │
└──────────┘ │ 调用什么 │ └──────────┘
└──────────┘
AI 不仅能调，而且知道什么时候该调、怎么组合调
5.3 以一个真实场景举例：员工入职流程
传统方式：HR 登录 5 个系统，手动操作 20+ 步骤，耗时 2-3 天。
Skill + MCP + OpenClaw 方式：
# SKILL.md — 员工入职自动化
---
name: employee-onboarding
description: >
处理新员工入职的全流程自动化。当收到"新员工入职"相关指令时激活。
---
## 流程
1. 确认员工基本信息（姓名、部门、职级、入职日期）
2. 调用 HR 系统创建员工档案 → [MCP: hr-system]
3. 调用 IT 系统开通邮箱账号 → [MCP: it-service]
4. 调用 OA 系统分配审批权限 → [MCP: oa-system]
5. 调用门禁系统录入权限 → [MCP: access-control]
6. 生成入职 Welcome Package → [本地模板]
7. 通过企微/钉钉发送入职通知 → [MCP: messaging]
8. 将入职记录归档 → [MCP: document-mgmt]
## 异常处理
- 任何系统调用失败 → 记录失败步骤 → 通知 HR 手动处理
- 员工信息不完整 → 向提交人确认缺失字段
HR 只需对 OpenClaw 说："张三，后端开发，P6，3 月 25 号入职，前端组"
一句话，全流程自动完成。
这里：
- Skill 定义了"入职该做哪些事、什么顺序"（过程知识）
- MCP Server 连接了 HR、IT、OA 等 5 个存量系统（工具连接）
- OpenClaw 作为 Agent 运行时，理解自然语言、调度执行（执行引擎）
- RAG？这个场景里根本不需要。
5.4 "API → MCP → Skill" 的企业级实施框架
┌──────────────────────────────────────────────────────────┐
│ AI 赋能存量系统架构 │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Agent 层（OpenClaw / 自建） │ │
│ │ 自然语言理解 → Skill 匹配 → 执行编排 → 结果返回 │ │
│ └───────────────────────┬─────────────────────────────┘ │
│ │ │
│ ┌───────────────────────▼─────────────────────────────┐ │
│ │ Skill 层（操作手册库） │ │
│ │ 员工入职 请假审批 订单处理 报表生成 巡检流程 ... │ │
│ └───────────────────────┬─────────────────────────────┘ │
│ │ │
│ ┌───────────────────────▼─────────────────────────────┐ │
│ │ MCP 层（工具连接） │ │
│ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌──────┐ │ │
│ │ │ ERP │ │ CRM │ │ OA │ │ HR │ │ MES │ │ 邮件 │ │ │
│ │ │ MCP │ │ MCP │ │ MCP │ │ MCP │ │ MCP │ │ MCP │ │ │
│ │ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ └──┬───┘ │ │
│ └─────┼───────┼───────┼───────┼───────┼───────┼──────┘ │
│ ▼ ▼ ▼ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 存量系统层（已有 API） │ │
│ │ SAP Salesforce 泛微OA 北森HR WMS Exchange │ │
│ └─────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘
5.5 MuleSoft MCP Bridge：大厂在干什么
2026 年 3 月，Salesforce 旗下的 MuleSoft 发布了 MCP Bridge——一个将现有 API 自动暴露为 MCP Server 的网关层。这意味着：
企业已有的数千个 MuleSoft API，不改一行代码，就能被 AI Agent 直接调用。
这不是概念验证，这是生产级产品。它验证了一个趋势：存量 API 的 MCP 化正在成为企业 AI 落地的标准路径。
类似的还有 MCPify（60 秒将遗留系统包装为 MCP Server）、AgentRetrofit 等项目。
六、终局判断：AI 接管存量软件的三种姿态
6.1 三种路线的适用场景
| 场景 | 最优路线 | 为什么 |
|---|---|---|
| 操作型任务 | Skill + MCP | "帮我请个假" → Skill 知道流程，MCP 调 OA 接口 |
| 查询型任务 | MCP（数据有 API 时） / RAG（只有文档时） | "上季度销售额" → API 直接查更准 |
| 知识型任务 | RAG | "公司数据安全策略是什么" → 只存在于文档中 |
| 分析型任务 | Skill + MCP + RAG | "分析客户流失原因" → 需要 API 数据 + 文档背景 + 分析方法 |
| 跨系统编排 | Skill + MCP + A2A | "入职流程" → 调用多个系统、遵循固定流程 |
| 模糊探索 | RAG + LLM 长上下文 | "找找去年关于微服务拆分的讨论" → 语义搜索 |
6.2 未来 2-3 年的演进预判
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2024 2025 2026 2027 2028
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Function MCP 发布 MCP 成为 Skill+MCP "无代码"
Calling Skill 标准 事实标准 成为企业 Agent
为主 化起步 A2A 起步 AI标配 无处不在
RAG 是 RAG 主流 RAG 地盘 RAG 退守 RAG 成为
唯一手段 但开始被质疑 开始缩小 知识检索专用 底层组件
API 手动 API 开始 API→MCP MCP 覆盖 所有API
对接 MCP 化 大规模推进 80%+系统 自动MCP化
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6.3 一个大胆的预测
到 2028 年，"企业知识库"这个产品形态会被重新定义。
不再是今天这种"上传文档 → 切片 → 向量化 → 检索"的 RAG 管线，而是：
┌─────────────────────────────────────────────────┐
│ 未来的"企业知识系统" │
│ │
│ 结构化知识（能查到 API 的） │
│ ────────────────────────── │
│ → 全部 MCP 化，Agent 直接调用拿数据 │
│ → 不再经过"检索"，而是"精确查询" │
│ │
│ 过程性知识（怎么做的） │
│ ────────────────────── │
│ → 全部 Skill 化，Agent 按流程执行 │
│ → 不再"理解"文档，而是"遵循"手册 │
│ │
│ 非结构化知识（经验、讨论、历史） │
│ ───────────────────────────── │
│ → RAG 保留，但作为底层组件而非独立产品 │
│ → 与 Skill/MCP 融合，成为 Agent 的"记忆模块" │
└─────────────────────────────────────────────────┘
七、给工程团队的行动建议
7.1 现在就该做的事
| 优先级 | 行动 | 理由 |
|---|---|---|
| P0 | 盘点现有 API 资产 | 你有多少 API？哪些可以 MCP 化？ |
| P0 | 学习 SKILL.md 规范 | 30 分钟学会，受益无穷 |
| P1 | 试点 1-2 个业务流程的 Skill 化 | 从简单流程开始验证 |
| P1 | 搭建内部 MCP Server | 从最常用的 3-5 个系统开始 |
| P2 | 评估 OpenClaw / 自建 Agent 框架 | 选一个 Agent 运行时 |
| P2 | 重新审视现有 RAG 项目 | 哪些场景其实用 Skill+MCP 更合适？ |
7.2 Skill 化的实施路径
Phase 1: 摸底（2周）
├── 梳理高频业务操作 Top 20
├── 标记哪些有 API、哪些是纯文档
└── 产出《Skill 化可行性评估报告》
Phase 2: 试点（1个月）
├── 选 3 个流程编写 Skill（从简到难）
├── 为涉及的系统搭建 MCP Server
├── 用 OpenClaw / Claude Code 验证端到端
└── 产出效果对比数据
Phase 3: 推广（持续）
├── 建立内部 Skill 库（类似 ClawHub）
├── 制定 Skill 编写规范和质量标准
├── 培训业务团队自行编写 Skill（门槛极低）
└── 逐步替代/补充现有 RAG 方案
7.3 技术选型决策树
你的场景是什么？
│
├── AI 需要"做事"（操作、审批、流程）
│ │
│ ├── 涉及外部系统？ → MCP Server + Skill
│ └── 纯本地操作？ → Skill 即可
│
├── AI 需要"查数据"（报表、指标、状态）
│ │
│ ├── 数据有 API？ → MCP Server（精确查询）
│ └── 只有文档？ → RAG（语义检索）
│
├── AI 需要"找知识"（政策、经验、讨论）
│ │
│ └── → RAG（这仍然是 RAG 的主场）
│
└── AI 需要"编排多个 Agent"
│
└── → A2A + Skill + MCP（全家桶）
八、结语：存量软件的第二次生命
回到开头的问题：
AI 最终会以什么方式赋能已经存在的巨大存量软件市场？
答案正在变得清晰：
不是推倒重来，不是再建一套"AI 原生系统"，而是给每个旧系统装上一个 MCP 翻译器，给每个业务流程写一份 Skill 手册，然后让一个足够聪明的 Agent 把它们串起来。
旧世界：人 → 登录系统 A → 操作 → 登录系统 B → 操作 → ... → 完成
新世界：人 → 说一句话 → Agent × Skill × MCP → 自动完成
技术架构不再是 "一个大系统替代另一个大系统" 的革命，而是 "一层薄薄的 AI 胶水粘合所有旧系统" 的进化。
这层"胶水"由三样东西组成：
- Skill — 告诉 AI 怎么做（大脑）
- MCP — 让 AI 够得着（双手）
- RAG — 帮 AI 想起来（记忆）
三者缺一不可，但权重正在变化。Skill 和 MCP 的戏份在上升，RAG 在回归它本该有的位置——不是万能钥匙，而是记忆模块。
对于工程团队来说，现在最重要的不是在三者之间选边站，而是理解它们的分工、掌握它们的用法，然后在自己的业务场景中找到最优组合。
Skill 不是门槛，是钥匙。它的门槛之低，低到任何一个会写 Markdown 的人都能入场。
而这，才是它真正颠覆性的地方。
本文系技术探索性文章，欢迎探讨交流。
最后更新：2026 年 3 月
