千笔-AIWritePaper · https://www.aiwritepaper.com

搭 Agent 时最容易踩的坑，不是「模型不够强」，而是把几件完全不同的事塞进同一句话：「给模型更多上下文」。IBM Technology 的 Martin Keen 在短片 Skills vs MCP vs RAG vs Memory: What AI Agents Need to Know（约 9 分钟）里把问题拆开了：Agent 要解决真实世界问题，仅靠训练数据不够；Skills、MCP、RAG、Memory 各管一类缺口——跟流程、连系统、取文档、记经验——再按任务组合。

本文不是视频口播复述。下面用同一问题框架，对照公开文档与通行定义，写成可落地的选型说明：先分清四块能力的边界，再谈组合与验收。

图：过程 / 动作 / 事实 / 状态各解一类短板；组合示例可用「500 排查」串起来，而不是互相替代。

目标说明

读完你应能独立完成五件事：

1. 用一句话区分 Skills、MCP、RAG、Memory 各自补的缺口（过程、动作、事实、状态）。
2. 对照官方文档，说清 MCP 的「连接外部系统」定位，以及 Agent Skills 的渐进式披露（metadata → SKILL.md → resources/scripts）。
3. 用标准定义解释 RAG 与 Agent Memory：前者是检索增强生成，后者是跨轮次 / 跨会话状态。
4. 面对具体需求，能填一张决策清单表，判断先上哪一块、后组合哪几块。
5. 给出至少三条可验证点与常见踩坑，避免「全都塞进 system prompt」或「用 RAG 冒充实时状态」。

规格先钉死（均可核对公开材料）：

• MCP：开放协议，把 AI 应用接到外部数据源、工具与工作流；官方比喻为 AI 应用的 USB-C。见 modelcontextprotocol.io。
• Agent Skills：文件系统上的可复用专业能力包；通过渐进式披露按需加载，未触发时几乎只占 name/description。见 Anthropic Agent Skills overview。
• RAG：Retrieval-Augmented Generation，检索相关外部片段再生成，回答「模型训练时没见过、但文档里写过」的事实问题。
• Agent Memory：会话内工作记忆与跨会话长期状态，回答「上次互动学到了什么 / 用户约定是什么」，不是整库全文检索。

适用场景与边界

适合认真拆四层

• 要做多步 Agent：既要查实时状态，又要遵守团队流程，还要引用内部文档。
• system prompt 已经膨胀成「半本手册 + 半份 API 说明」，仍不稳定。
• 团队争论「要不要上 MCP / 要不要上 RAG / Skills 是不是替代工具」——通常说明边界没画清。
• 需要复盘：同样任务有时对、有时飘，想分清是流程没写清、工具没接通、检索没命中，还是状态没记住。

不该指望某一块单独搞定

• 只用 Skills：没有鉴权、会话与连接；它不能替你查生产库或改工单。
• 只用 MCP：有工具不等于会按你们的 SOP 用工具；缺过程时输出会漂。
• 只用 RAG：向量库回答不了「此刻这台机器是否在报错」；实时状态要走工具 / MCP。
• 只用 Memory：经验沉淀补的是「文档未写」的部分；不能替代权威手册与可审计流程。
• 小而稳的文本：硬上向量库可能过重；可读文件 + Skills 引用往往更省。

风险提示

四块能力都会占用上下文预算，只是计费时机不同：MCP 的 tool schema 常较早进入窗口；Skills 以元数据发现、正文触发；RAG 按查询取 top-k；Memory 写入与召回策略决定噪声。混用时要显式设计「谁常驻、谁按需」，而不是默认全开。

还有一层治理风险：Skills 带指令与可执行脚本，应只装可信来源，并审计捆绑文件；MCP 工具等于把权限边界交给 Agent 调用链，需要最小权限与审计日志；RAG 与 Memory 都可能泄露内部材料到提示里，脱敏与访问控制要和「能不能答」一起设计。

机制：四块能力各解什么

1. Skills：程序性知识（怎么按我们的方式做）

Skills 回答的是流程与判断，不是实时事实。Anthropic 文档把它描述为可复用的、基于文件系统的资源：工作流、上下文与最佳实践，把通用 Agent 变成领域专家。关键机制是 progressive disclosure（渐进式披露）：

层级	何时加载	大致代价	内容
Level 1 Metadata	启动时始终在场	约每 Skill ~100 tokens 量级	YAML 的 name + description
Level 2 Instructions	请求匹配 description 后触发	建议控制在较小正文	SKILL.md 流程与约束
Level 3+ Resources	被引用时再读 / 脚本执行	未访问 ≈ 0	references、scripts、assets

description 必须同时写清 做什么 与 何时用；写得太虚，Skill 会「永远不触发」——静默失败。Skills 适合：发布检查清单、事故分级、报告模板、命名规范、何时升级人工。

2. MCP：外部能力通道（怎么连到活系统）

MCP（Model Context Protocol）解决的是能力与接入：让 Agent 以统一方式连接本地文件、数据库、搜索、业务 API 等。官方定位很明确：开发者少写一次性集成；应用侧获得可组合的数据与工具生态。你可以把它想成「工具与资源的标准插座」，而不是又一种 prompt 技巧。

典型用法：读后端日志、查最近部署、打开工单、查询库存。这些都是「世界此刻的状态」，向量检索与静态 Skill 正文都替代不了。代价也清晰：工具定义会进入上下文；工具越多、描述越长，常驻预算越高。应「按任务接服务器」，而不是把所有 MCP 一次性挂满。

3. RAG：事实检索增强（文档里写过什么）

RAG 的标准定义是：在生成前先检索相关外部材料，把片段注入提示，再让模型作答。它补的是「大体量、偏静态、模型权重里没有」的知识——产品手册、政策、历史工单、依赖说明。语料可以很大，因为窗口里通常只有本次 top-k，而不是整库。

RAG 的失败模式常常是「自信地答错」：总有 top-k，即使都不相关。需要相似度门槛、引用片段、人工抽检。它也不该被拿去冒充实时监控。

4. Memory：跨轮次状态（上次学到了什么）

Agent Memory 这里取工程通行含义：短期（当前会话 / 工作记忆，类似上下文窗口内的活跃状态）与 长期（跨会话保留的偏好、约定、已验证结论）。IBM 短片里用「文档外的经验」来对照 RAG：runbook 没写的坑、上次真正根因、用户偏好，适合进 Memory，而不是反复塞进同一份检索语料。

Memory 不是「更大的 RAG」。短事实、否定句、用户级偏好，用向量大海捞针往往脆；更稳的是显式键值 / 记录 + 更新路径。工作记忆有容量上限；长期记忆要治理写入，避免把噪声永久化。

组合：用「500 排查」把四块串起来

Keen 用过的直觉场景很适合做组合样板（此处按工程语言重写，不是口播搬运）：

1. Skills 提供 triage 流程：先看错误率与影响面 → 再核对最近部署 → 再决定是否升级。
2. MCP 去活系统取证据：拉日志、查发布状态、读监控指标。
3. RAG 取依赖图、SOP、历史相似工单中的书面段落。
4. Memory 若上次同症状根因是「错误集群」或「某开关」，优先召回该经验，避免重复踩坑。

组合原则：Skills 编排「顺序与判断」；MCP 提供「动作」；RAG 提供「可引用事实」；Memory 提供「跨次状态」。缺哪补哪，而不是挑一个「最火」的名词覆盖全部。

落地顺序建议：先写最小 Skill（把流程说清）→ 只接本任务需要的 MCP → 对「手册型」材料建 RAG → 最后再为跨会话经验开 Memory。倒过来做，容易先堆工具与索引，却没有稳定的决策骨架。

决策清单表：何时用哪一块

你缺的是什么	优先机制	典型产物	不要用它去……
可重复流程 / 团队规范 / 判断点	Skills	SKILL.md + 可选 scripts	假装能直连生产系统
实时读写外部系统 / 工具调用	MCP	MCP Server（tools/resources）	塞成长篇散文代替 SOP
大体量文档事实 / 可引用段落	RAG	分块索引 + 检索管线	回答「此刻是否宕机」
跨轮次偏好 / 会话外经验	Memory	短/长期状态存储	替代权威手册与审计流程
多步真实任务	组合	Skill 调 MCP，并引用 RAG；Memory 记结论	只扩 system prompt

三问速查：

1. 答案必须反映「此刻世界」吗？→ MCP（或等价工具）。
2. 答案写在大体量、可索引文档里吗？→ RAG。
3. 关键是「我们怎么做」而不是「资料怎么写」吗？→ Skills。
   若还依赖「上次跟这个用户 / 这个服务交互的结论」→ 加 Memory。

可验证点

落地后用下面检查项验收，比自评「感觉更聪明」可靠：

1. 边界可陈述：任意需求能标成 S/M/R/Mem 或其组合；争论落在「缺哪类」而不是「哪个时髦」。
2. Skills 可触发：对目标话术提问，确认会加载对应 SKILL.md；改 description 后触发率可复测。
3. MCP 可观测：能列出已连接 server 与工具名；一次任务只用到声明过的工具子集。
4. RAG 可引用：回答能指向具体片段；人为制造「语料无答案」问题时，系统应拒绝或低置信，而不是编造。
5. Memory 可更新：写入一条偏好 / 根因后，新会话能召回；过期或错误条目有清除路径。
6. 上下文预算可解释：能说清常驻项（如部分 tool schema、Skill 元数据）与按需项（Skill 正文、检索片段、Memory 条目）。

常见踩坑

1. 把四块当成互斥选型：问「MCP 和 RAG 哪个更好」通常问错了；它们回答不同问题。
2. 用 RAG 冒充监控：索引里的昨天日志 ≠ 此刻状态；实时路径走 MCP。
3. Skill 描述过空：「帮助处理问题」永不匹配；写成触发条件 + 用户会说的词。
4. MCP 只加不减：工具 schema 静默吃窗口；定期审计已连接 server。
5. Memory 无治理：什么都存，召回噪声上升；区分工作记忆与长期事实，并设更新/遗忘规则。
6. 全塞 system prompt：短期有效，长期不可维护，也浪费缓存与窗口；能外置的流程、工具、语料、状态，分别外置。

总结

Agent 要的不只是更大的上下文窗口，而是分清四类短板再组合：

• Skills：过程与判断（渐进披露的程序性知识包）
• MCP：动作与接入（连接外部系统的开放协议）
• RAG：事实与引用（检索增强生成）
• Memory：状态与经验（短/长期跨轮次记忆）

先问「缺过程、缺动作、缺文档，还是缺跨次状态」，再决定上哪一层、如何串联。视频提供直觉框架；公开文档提供可核对细节。把边界画清，system prompt 反而可以变短——它只需稳住基础行为，不必再兼任手册、API 网关、向量库和笔记本。

参考

1. Martin Keen / IBM Technology，《Skills vs MCP vs RAG vs Memory: What AI Agents Need to Know》，https://www.youtube.com/watch?v=X4FVEEegCbk
2. Model Context Protocol 官方站点，https://modelcontextprotocol.io/
3. Anthropic，《Agent Skills overview》（progressive disclosure），https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
4. Retrieval-Augmented Generation：检索相关外部材料后再生成的通行模式（行业标准定义，非单一厂商专有协议）
5. Agent Memory：会话内工作记忆 + 跨会话长期状态的工程通行划分