Agent 如何积累能力：RAG、Memory 与 Skills
一个 Agent 想把事情做得越来越好，至少要回答三个问题：当前缺的信息去哪里找？上一次做过什么要不要记住？一套反复使用的做法如何沉淀下来？
在整理 Code Agent 的中控系统 和长程任务时，我发现 RAG、Memory 和 Skills 很容易被放进同一条“能力升级”时间线。我最初也沿着这个思路理解它们：先检索知识，再保存经验，最后把经验压缩成技能。重新对照它们在系统里的读写路径后，我更倾向于把三者看成并列、互补的能力层。
RAG、Memory 和 Skills 分别对应这三个问题。它们经常被描述成一条从 RAG 到 Memory、再到 Skill 的演进路线，但这种说法容易造成误解：三者并不是前后替代关系，而是 Agent 系统里的不同层。
| 能力层 | 解决的问题 | 典型内容 | 主要风险 |
|---|---|---|---|
| RAG | 当前任务缺什么外部信息 | 文档、数据库、网页、代码 | 检索错误、来源过时 |
| Memory | 哪些历史状态和经验值得保留 | 用户偏好、任务摘要、失败经验 | 记错、过期、隐私泄露 |
| Skills | 一类任务应该按什么流程完成 | 指令、脚本、模板、参考资料 | 错误流程被稳定复用 |
| Tools / MCP | Agent 如何对外执行动作 | API、文件系统、数据库、应用 | 权限过大、调用副作用 |
我更愿意把它们理解为四种不同的上下文来源：RAG 提供“现在需要知道的事实”，Memory 提供“过去发生过什么”，Skill 提供“应该怎么做”，Tool 则负责“真正去做”。
RAG：让 Agent 主动找信息
传统 RAG 通常是一条固定流水线：收到问题、查询向量数据库、把结果塞进 Prompt、生成回答。Agentic RAG 的变化在于，检索本身也成了 Agent 可以规划和反复执行的动作。1
例如，一个企业分析任务可能需要先查内部文档，再根据文档里的客户编号查询 SQL，最后到网页验证最新公告。Agent 需要决定：
- 该查哪个数据源；
- 当前证据是否足够；
- 检索结果互相冲突时相信谁；
- 查询失败后是改写问题，还是换一个工具。
调用工具"] retrieve --> judge{"证据
够不够"} judge -->|不够| rewrite["改写查询
或换数据源"] rewrite --> retrieve judge -->|足够| answer["生成答案
并标注来源"]
这里不一定需要多 Agent。很多任务用一个 Agent 加几个清晰的检索工具就够了。只有当数据源权限、上下文或执行周期明显不同，多 Agent 分工才可能抵消额外的调度成本。
RAG 的边界也很明确：它可以重新找到过去的记录，却不会自动判断哪些历史信息值得长期保存；它能检索一份操作手册，却不会保证 Agent 每次都按手册执行。前者是 Memory 的问题，后者更接近 Skill。
Memory：保存状态，而不是囤积对话
Memory 不是“把所有聊天记录放进向量库”。一个可用的记忆系统至少需要写入、整理、读取和遗忘四个环节。近期综述也把 Agent Memory 描述为一个与感知和行动耦合的 write–manage–read 循环。2
工程上可以先按用途分成三类：
| 记忆类型 | 例子 | 生命周期 |
|---|---|---|
| 工作记忆 | 当前计划、已读文件、待验证假设 | 单次任务 |
| 事实记忆 | 用户偏好、项目约束、环境状态 | 跨任务，但需要更新 |
| 经验记忆 | 某类失败的原因、有效的调试路径 | 跨任务，需要归纳和验证 |
真正困难的是写入路径。任务中的很多信息只在当时有用：旧报错、临时文件路径、一次失败的猜测。如果不加筛选地保存，Memory 很快会从帮助变成噪声。
一个较稳妥的写入流程是：
- 从轨迹中提取候选事实或经验；
- 区分观察到的事实和模型自己的推断；
- 检查是否与已有记忆冲突；
- 给记忆附上来源、时间和适用范围；
- 只有在未来任务中确实可复用时才长期保存。
读取同样不能只靠向量相似度。系统还需要考虑新旧程度、来源可靠性、项目范围和当前上下文预算。一次相似但过期的经验，可能比完全没有记忆更危险。
所以 Memory 的价值不是“记得多”，而是能够维护一份可信、可更新的状态。
Skills：把过程知识变成可加载模块
Skill 适合保存“如何完成一类任务”。它通常不只是 Prompt，也不只是一个函数，而是由说明、脚本、模板和参考资料组成的目录。Anthropic 将 Agent Skills 定义为可以被动态发现和加载的能力包，并把渐进式披露作为核心设计原则。3
三者的区别可以简单理解为：
| 组件 | 主要回答 | 例子 |
|---|---|---|
| Prompt | 这一次要做什么 | “检查这个 PR 的兼容性问题” |
| Tool | 用什么动作完成 | 读取 diff、运行测试、写评论 |
| Skill | 这类任务通常怎么做 | 检查顺序、风险清单、验证脚本、输出格式 |
Skill 的工程价值在于按需加载。Agent 启动时只需要知道 Skill 的名称和描述；判断相关后再读取 SKILL.md；更长的参考资料和脚本只在具体步骤需要时加载。
是否匹配"} trigger -->|否| skip["不加载"] trigger -->|是| instructions["读取
SKILL.md"] instructions --> need{"是否
需要细节"} need -->|是| resources["读取 references
或运行 scripts"] need -->|否| execute["执行任务"] resources --> execute
这种设计解决的是上下文成本，而不是让能力变得“无限”。目录里可以放很多材料，但每次加载多少、模型能否找到正确文件、脚本有没有权限，仍然需要设计和测试。
Skills 与 MCP 怎么配合
MCP 和 Skill 经常一起出现，但它们解决的不是同一个问题。
- MCP 负责提供连接和动作，例如读取 Google Drive、查询数据库或操作 GitHub；
- Skill 负责描述完成业务目标的步骤，例如“如何从设计稿生成开发交接文档”；
- 代码执行环境负责把多个调用组合起来，并承担过滤、循环和格式转换；
- 权限系统负责限制这些动作可以影响什么。
当工具很多时，把所有 schema 永久放进上下文会带来明显开销。Anthropic 的实践建议让 Agent 按需发现工具，或者通过代码把多步调用封装成更高层操作。4 但代码执行也扩大了风险面，需要沙箱、资源限制和审计。
一个生产级 Skill 不应该只写“依次调用 A、B、C”。它还需要说明：
- 调用前检查什么；
- 哪些输入来自用户，哪些来自可信系统；
- 失败后能否重试，重试几次；
- 哪些动作需要确认；
- 怎样判断任务真正完成。
怎样写一个可维护的 Skill
结合 Anthropic 的公开说明和实际工程经验，我会把 Skill 开发压缩成五个步骤。
- 从真实失败开始
先运行一组代表性任务，观察 Agent 缺的是知识、工具还是流程。只有当问题会重复出现，而且可以总结为稳定做法时，才值得做成 Skill。不要先写一份宏大手册，再去找使用场景。
- 让描述承担路由职责
name 和 description 是 Agent 决定是否加载 Skill 的入口。描述既要说明做什么，也要说明什么时候使用。太宽泛会过度触发，太窄又会漏掉用户的自然表达。
- 主文件只保留主路径
SKILL.md 应该让 Agent 快速理解目标、步骤和关键约束。罕见分支、长文档和示例放到 references/，可重复且需要确定性的操作放到 scripts/。
- 用代码保证硬约束
格式校验、文件检查、数值计算和批量转换更适合交给脚本。自然语言擅长解释和判断，不适合稳定执行机械规则。
- 同时测试触发和结果
Skill 评估至少包含两部分：它是否在正确的问题上被加载，以及加载后是否提高了任务质量。一个每次都触发、但没有改善结果的 Skill，只是在消耗上下文。
我现在怎么理解这三层
RAG、Memory 和 Skills 不是 Agent “越来越聪明”的三个阶段，而是三种需要分别治理的状态：外部事实、历史经验和过程知识。
这一区分会直接影响系统设计：
- 会变化的外部事实留在数据源里，通过 RAG 获取；
- 与用户或任务连续性有关的状态进入 Memory，并带上时间和来源；
- 稳定、可复用的做法封装成 Skill；
- 真正产生副作用的动作交给 Tool，并受权限系统约束。
未来值得关注的不是 Agent 能否自动生成更多 Skills，而是它能否验证一段经验真的可复用、识别旧 Skill 已经过期，并在执行前理解它会获得什么权限。相关研究也开始把 Skill 的获取、组合与安全治理放在同一个框架下讨论。5 能力沉淀只有和遗忘、版本与安全一起设计，才会变成资产，而不是另一种上下文债务。
参考资料
Aditi Singh et al., Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG, 2025。 ↩︎
Pengfei Du, Memory for Autonomous LLM Agents: Mechanisms, Evaluation, and Emerging Frontiers, 2026。 ↩︎
Anthropic, Equipping Agents for the Real World with Agent Skills, 2025。 ↩︎
Anthropic, Code Execution with MCP: Building More Efficient AI Agents, 2025。 ↩︎
Renjun Xu and Yang Yan, Agent Skills for Large Language Models: Architecture, Acquisition, Security, and the Path Forward, 2026。 ↩︎
