P4：Skill 与 Agent 知识管理

Easy Data x AI 课程 · 道篇 · 第四期

Skill 碎片化不是工程问题——它和知识库分散是同一类数据问题。

开场：程序记忆的另一面

上一期我们讲了 Agent 的记忆系统。在三种长期记忆中，程序记忆可能是最容易被忽略、但最有实践意义的一种。

回忆一下：语义记忆存的是“什么是什么”——关于用户的事实；情景记忆存的是“发生了什么”——过去的交互经验；而程序记忆存的是“遇到这种情况该怎么做”——行为规则和工作流程。

我们在 P3 结尾埋了一个伏笔：程序记忆是三种记忆中唯一一种 Agent 可以自我修改的。如果用户多次表达“回答太长了”，Agent 可以给自己加一条“回答要简洁”的规则。这种自我修改能力让程序记忆特别有意思——它不只是被动存储信息，它直接塑造了 Agent 的行为方式。

但 P3 讲的是程序记忆的“内在”形态——Agent 内部的一组规则。

今天我们要讲的是程序记忆的“外在”形态——Skill。

你可以这么理解：如果程序记忆是一个人“脑子里”知道该怎么做事的那套经验，那 Skill 就是他把这套经验写成了一份操作手册，放到了书架上，让任何人都可以拿来用。

Skill 是当下 Agent 生态中最热门、但被系统性讨论得最少的概念之一。每个用 AI 编程工具的人都在写 Skill，每个 Agent 平台都有自己的 Skill 机制，但几乎没人退后一步想过：这些 Skill 的管理方式，本身就是一个数据问题。

今天我们来拆解这件事。

第一部分：什么是 Skill

从程序记忆到 Skill

在 P3 中，我们举过程序记忆的例子：

• “用户问代码问题时，先给解释再给示例”
• “回答前先确认用户的技术背景”
• “当遇到多步骤任务时，先列出步骤大纲再逐步执行”

这些规则存在于 Agent 的“脑子里”——通常以 System Prompt 或者模型内化的行为模式呈现。它们发挥作用，但有一个局限：它们是隐式的、通用的、和特定 Agent 绑定的。

Skill 做的事情，是把这类“怎么做”的知识显式化、结构化、独立化。

举个更具体的例子。假设你是一个产品经理，团队里有一个非常优秀的运营同事，他写用户增长方案特别有套路：先做竞品数据分析、再拆解用户分层、然后针对每一层制定差异化策略、最后给出可量化的 KPI。每次他出的方案质量都很高。

这套“套路”存在他的脑子里，这就是他的“程序记忆”。

现在想象他把这套方法论写成了一份详细的文档：“第一步，收集竞品近三个月的核心增长指标；第二步，按行为特征将用户分为以下几个层级……”——写清楚了每一步的操作要点、判断标准、常见陷阱。

这份文档就是一个 Skill。

Skill = 把操作流程、领域规则、成功经验，变成 Agent 可以调用的结构化文档。

有了 Skill，Agent 不再只依赖通用训练知识来回答问题，它可以调用特定领域的专业经验。就像一个刚入职的新员工，如果公司有一套完善的 SOP 手册，他不需要从零摸索，按照手册就能做到八十分的水准。Skill 对于 Agent 的意义也是一样的——它把“怎么做”的经验数据交给了 Agent，让 Agent 在特定领域的表现从“通用水平”跃升到“专家水平”。

Skill 的典型形态

在当前的 Agent 生态中，广义上的 Skill 以各种形式存在：

• Cursor Rules：在 Cursor IDE 中，你可以写 .cursor/rules/ 下的规则文件，告诉 AI 助手“在这个项目中，React 组件用函数式写法，不用类组件”“所有 API 调用都要有错误处理”“测试文件命名用 xxx.test.ts 格式”。
• Claude Code 的 CLAUDE.md：Claude Code 会读取项目根目录的 CLAUDE.md 文件，里面写着项目的技术栈、代码风格、常用命令等信息。
• SKILL.md 文件：一些 Agent 框架允许用户编写独立的 Skill 文档，描述一个特定能力——比如“如何发布一个 npm 包”“如何进行代码审查”“如何生成符合公司规范的 API 文档”。
• System Prompt 模板：很多团队积累了大量经过验证的 Prompt 模板，本质上也是 Skill——“在做翻译任务时，按照这个 Prompt 模板来操作”。

名字不一样，格式不一样，平台不一样——但它们做的是同一件事：把“该怎么做”的经验知识，以文档的形式提供给 Agent。

理解了这一点，你就明白了 Skill 和 P3 讲的程序记忆之间的关系：Skill 是被外部化、结构化了的程序记忆。程序记忆是 Agent“内化”的行为规则，Skill 是把这些规则“外化”成了可以管理、可以共享、可以检索的文档资产。

这个区别很重要。因为一旦经验变成了文档，它就不再是某个人或某个 Agent 专属的——它变成了可以被管理的数据。而一旦涉及数据管理，我们在前几期课程中讨论过的那些问题，就全都出现了。

第二部分：碎片化困境——当前 Skill 管理的真实现状

了解了 Skill 是什么之后，让我们看看它在实际使用中面临的最大问题。

一个熟悉的场景

你可能有这样的经历：

你在 Cursor 里花了不少时间，给一个项目写了一套完善的 Rules。这些规则涵盖了项目的技术栈约定、代码风格、目录结构、常见的坑和最佳实践。有了这套 Rules，AI 助手在这个项目里写出来的代码质量明显提高了——它知道用哪个组件库、知道错误处理的标准模式、知道测试应该怎么写。

然后你换了一个新项目。

一切归零。

你在新项目里开一个新窗口，AI 助手又变回了那个“什么都不知道”的状态。你之前积累的那些规则、那些经验、那些踩坑总结——全都留在了上一个项目的 .cursor/rules/ 目录里。你想用？手动复制粘贴。

更头疼的是，你不只用一个 AI 工具。你在 Cursor 里有一套规则，在 Claude Code 里有一份 CLAUDE.md，可能还在 ChatGPT 里保存了几个自定义 GPT 的 Prompt。这些经验散落在三个完全不同的平台上，格式不兼容，互相看不见。

你的 Cursor Rules 没法在 Claude Code 里用。你的 CLAUDE.md 没法在 Cursor 里用。你在 ChatGPT 里验证过的有效 Prompt，想用到其他工具里只能靠手动复制。

这不是你一个人的问题

你以为这只是个人用户的烦恼？企业里的情况更严重。

想象一个产品团队。前端工程师 A 在自己的 Cursor 里写了一套前端开发 Rules，涵盖了组件规范、状态管理方案、性能优化技巧。后端工程师 B 在自己的 Claude Code 里积累了后端 API 设计的最佳实践。测试工程师 C 有一份自己整理的测试策略 Prompt 模板。产品经理 D 有一套用来做竞品分析的 GPT 自定义指令。

每个人的经验都很有价值。但它们分别存在四个人的电脑里、四个不同的工具里、四种不同的格式中。

这就像一家公司里，每个部门的操作流程都写在各自负责人的私人笔记本上，没有共享的 wiki、没有统一的知识库。 新人入职，没有任何地方可以系统地了解“我们部门的最佳实践是什么”。某个老员工离职了，他笔记本里十年积累的经验就跟着他走了。想跨部门协作？先花半天互相说明各自的做事方式。

这个类比你可能觉得很熟悉——因为这是很多公司在“没有知识管理”时代经历过的痛。而现在，同样的痛正在 AI 工具的 Skill 管理上重演。

碎片化的三个层面

让我们把这个问题拆得更清楚。Skill 碎片化发生在三个层面：

第一层：项目隔离。 同一个人、同一个工具，但不同项目之间的 Skill 无法自动共享。你在项目 A 积累的规则，开新项目 B 的时候需要手动搬运。有些通用规则（比如“代码要有类型注解”“错误信息用中英双语”）在每个项目里都有用，但你每次都要重新配置一遍。

第二层：工具隔离。 不同 AI 工具之间的 Skill 格式不兼容。Cursor 的 Rules 是 .mdc 文件存在 .cursor/rules/ 里；Claude Code 读的是项目根目录的 CLAUDE.md；ChatGPT 的自定义指令是一段纯文本。即使描述的是同一条规则，你也得用三种不同的方式写三遍。

第三层：人员隔离。 团队成员之间的 Skill 无法便捷共享。你写了一条特别好的规则，想分享给同事，怎么办？发个消息，把文件内容贴过去。同事收到后，手动粘贴到自己的工具里。如果这条规则后来需要更新呢？再发一次消息。一个团队十个人，每个人的规则都在自己的机器上各自演化，半年后可能已经分叉成了十个版本。

三个层面加在一起，结果就是：团队积累的 AI 使用经验，变成了一堆散落在不同地方的碎片，无法被系统性地检索、共享和复用。

第三部分：Skill 的发现与检索——当 Skill 多了以后

碎片化是一个“管理”层面的问题。现在让我们看另一个紧密相关的问题：当 Agent 有几十个甚至上百个可用的 Skill 时，它怎么知道在当前场景下应该用哪一个？

一个朴素的方法

最简单的做法是全部加载——把所有 Skill 文档一股脑塞进 Agent 的上下文窗口里，让 Agent 自己判断哪个相关。

这个方法在 Skill 很少的时候确实管用。你有三五条规则，每条几百字，全部放进 System Prompt 里，Agent 读一遍就知道该遵循什么。

但当 Skill 数量增长到几十个、内容总量达到几万字甚至更多的时候，问题就来了：

第一，上下文窗口有限。F1 里讲过，大模型的上下文窗口就是一张工作台，空间有限。把几十份 Skill 文档全摊在工作台上，留给用户实际问题的空间就不够了。

第二，注意力被稀释。即使上下文窗口够大，研究也表明，当输入文本过长时，模型对“中间部分”的信息关注度会下降。你最需要的那条 Skill 如果恰好被淹没在一大堆不相关的规则中间，Agent 很可能会忽略它。

第三，不相关的 Skill 可能造成干扰。如果你在问一个前端组件的问题，Agent 的上下文里却塞着一堆后端数据库操作的规则，这些不相关的规则不仅占空间，还可能让 Agent 的回答偏离方向。

本质上是一个检索问题

怎么解决？答案你可能已经猜到了——这是一个检索问题。

Agent 面对一个用户请求时，需要从可用的 Skill 库中，找到与当前请求最相关的那几个 Skill，把它们加载到上下文中，而不是把所有 Skill 都加载。

这个过程，和 P2 讲的 RAG 是一模一样的机制。

P2 里，RAG 做的事情是：用户提了一个问题 → 从知识库中检索最相关的文档片段 → 把这些片段交给模型来生成回答。

Skill 检索做的事情是：用户提了一个请求 → 从 Skill 库中检索最相关的 Skill 文档 → 把这些 Skill 交给 Agent 来指导行为。

区别只是检索的对象不同——RAG 检索的是“知识文档”，Skill 检索的是“技能文档”。但底层的检索机制完全相同：都是基于语义相似度，从一个文档库中召回最相关的内容。

甚至 P2 里讨论过的那些检索策略问题，在 Skill 场景中也一样存在。比如：

• 混合检索的必要性：如果用户说“帮我发布一个 npm 包”，纯语义搜索可能会返回“帮我发布一个 Python 包”的 Skill——因为在语义空间中，它们都是“发布包”这个主题。但你需要的是精确匹配“npm”这个关键词的 Skill。P2 讲过，混合检索（语义 + 关键词）可以解决这个问题。
• Agentic 检索决策：有时候 Agent 需要判断“这个请求需不需要调用 Skill”。一个简单的闲聊不需要任何 Skill；但一个“帮我按照公司规范写一份 API 文档”的请求，就需要去检索“API 文档写作规范”这个 Skill。P2 里讨论的 Agentic RAG 的“要不要搜”“搜哪里”“搜到的结果够不够好”的决策逻辑，在 Skill 检索中同样适用。

P2 的搜索策略讨论，在这里完全复用。 这不是巧合——这正是我们这门课一直在强调的核心判断：Agent 的各种能力，拆到底都是数据的存储与检索。RAG 是知识数据的检索，记忆是用户数据的检索，Skill 是经验数据的检索。底层机制相通，只是数据类型不同。

第四部分：回到数据视角——Skill 碎片化的根因

现在让我们退后一步，用数据的视角来审视 Skill 碎片化这个问题。

在 P2 中，我们讨论过一个核心判断：知识库分散、内容残缺、格式混乱——这些数据层的问题，是 RAG 效果不好的首要原因。 大多数“AI 答得不好”的情况，不是模型不行，而是模型根本没拿到正确的数据。

现在，把这个判断中的“知识库”替换成“Skill”，你会发现一模一样的逻辑成立：

Skill 分散在不同的文件系统、不同的项目目录、不同的平台配置中——无法被统一检索、无法被团队共享、无法被跨 Agent 复用。这不是一个工程问题，这是一个数据管理问题。

具体来说：

• 知识库数据分散 → RAG 检索不到正确内容 → AI 回答质量差
• Skill 数据分散 → Agent 找不到最佳技能 → Agent 行为不够专业

同一类问题，同一个根因——经验数据没有被结构化地管理。

P2 里那个经典的案例：一家公司的 Agent 回答不好，不是模型不够聪明，而是知识库里缺了一半的内容，另一半是半年前的旧版本。问题出在数据层。

Skill 面临的是相同处境。你的团队可能已经积累了大量高质量的 Skill——有效的编程规则、验证过的 Prompt 模板、特定领域的操作流程。但这些经验数据散落在每个人的电脑上、每个项目的配置目录里、每个 AI 工具的专属格式中。

数据存在，但不可检索、不可共享、不可复用——和“知识库里有内容但 Agent 检索不到”是一回事。

这个认识很重要，因为它改变了我们思考解决方案的方向。如果你把 Skill 碎片化当成一个“工程问题”，你会想着去写同步脚本、做格式转换器、建文件监听服务——每次某个工具出了新格式你就要适配一次，永远在追赶。

但如果你把它当成一个“数据管理问题”，解题思路就清晰了：把 Skill 当作一种需要被统一存储、索引、检索的数据资产来管理——就像你管理知识库一样管理技能库。

我们的思考

我们观察到一个越来越明显的趋势：开发者正在同时使用多个 AI 编程助手。

这不是什么预测——这已经是现实了。很多开发者日常工作中会交替使用 Cursor、Claude Code、Windsurf，甚至还有 GitHub Copilot、各种终端 AI 工具。每个工具有各自的优势：有的更擅长代码补全，有的更擅长复杂推理，有的在特定语言或框架上表现更好。但这带来了一个非常现实的问题：每个助手的 Skill 和记忆都是完全孤立的。

你在 Cursor 里花了两周教会了它你的项目规范——React 用函数组件、状态管理用 Zustand、API 层用 tRPC。然后你切到 Claude Code 去做一个复杂的重构任务。Claude Code 对这一切一无所知。你得重新告诉它所有这些约定。等你在 Claude Code 里积累了新的经验（比如重构过程中发现了一些需要注意的模式），这些经验又回不到 Cursor 里。

每一个 AI 助手都在各自的孤岛上积累经验，孤岛之间没有桥梁。

这让我们开始思考一个方向：如果 Skill 文档不是存在各个工具的本地配置里，而是存在一个统一的、可检索的数据层中——会怎样？

设想一下这样的场景：

你的所有 Skill——无论是编程规范、Prompt 模板、操作流程、领域知识——都存储在一个统一的技能知识库中。当你在 Cursor 里工作时，Cursor 可以从这个知识库中语义检索到与当前任务最相关的 Skill，自动加载到上下文中。当你切到 Claude Code 时，Claude Code 也从同一个知识库检索。当你的同事开了一个新项目时，他也能检索到团队共享的最佳实践。

Skill 不再绑定于特定的工具、特定的项目、特定的人——它变成了团队级别的可检索知识资产。

这就像从“每个人把操作流程写在自己的笔记本上”进化到“公司有一个统一的知识管理平台”。当年企业知识管理领域走过的路——从分散的个人文档到 Confluence、Notion 这样的统一平台——Agent 的 Skill 管理也需要走一遍。

坦率地说，这个方向目前还没有成熟的解决方案。行业还处在很早期的阶段——大多数人甚至还没有意识到 Skill 碎片化是一个需要系统性解决的问题，大家还在手动复制粘贴文件，觉得“这就是现在的用法”。

但路径是清晰的：

1. Skill 需要被当作数据资产来管理，而不是散落在文件系统里的配置文件
2. Skill 检索需要语义理解——Agent 应该能根据当前任务的语义，动态匹配最佳的 Skill，而不是预先指定
3. Skill 需要跨工具、跨项目、跨团队共享——一个统一的检索层，让不同的 Agent 都能访问

本质上，我们在讨论的是：给 Agent 的技能建一个“可检索的知识库”。

这和 P2 讲的给 Agent 建知识库、P3 讲的给 Agent 建记忆系统，是完全一致的思路。知识库管理的是“事实数据”，记忆系统管理的是“用户数据”，Skill 知识库管理的是“经验数据”。底层的数据管理逻辑是相通的——存储、索引、检索、更新、权限控制——只是数据的类型不同。

这正是我们团队在探索的方向。如果 seekdb 能成为 Agent 的通用数据层——不仅存知识、存记忆，还能存 Skill——那 Agent 生态中的数据碎片化问题就有了一个统一的解法。我们还在路上，但每走一步都更确信：Agent 基础设施的下一个重要问题，在数据层。

回到程序记忆

让我们把 P3 和 P4 串起来。

P3 讲的是 Agent 的记忆系统——Agent 需要记住关于用户的事实（语义记忆）、过去的经验（情景记忆）、以及行为规则（程序记忆）。

P4 讲的是 Skill——Agent 需要调用的结构化经验知识。

程序记忆和 Skill，是同一件事的两面。 程序记忆是 Agent “内化”的行为规则——它通过和用户的交互逐渐学到“该怎么做”。Skill 是“外化”的行为规则——由人类显式地编写，提供给 Agent 调用。

一个完整的 Agent 行为系统，需要两者兼备：

• 程序记忆负责个性化的、从交互中学到的行为适应——“这个用户喜欢简洁回答”“这个项目的测试习惯是先写 happy path 再写 edge case”
• Skill负责通用的、从专业知识中提炼的行为指导——“发布 npm 包的标准流程”“写 API 文档的最佳实践”“处理用户投诉的话术模板”

程序记忆让 Agent 越来越“懂你”，Skill 让 Agent 越来越“专业”。两者共同决定了 Agent 在特定领域的表现水平。

课后行动

盘点你的团队当前使用的 AI 工具，完成以下练习：

1. 列出所有 AI 工具的 Skill/规则/指令：你的团队在用哪些 AI 工具？每个工具里有没有自定义的 Rules、Instructions、Prompt 模板？它们分别存在哪里？

2. 统计碎片化程度：

   • 这些 Skill 分散在多少个不同的地方？（多少个工具、多少台机器、多少个项目目录）
   • 有没有不同的人分别维护着功能重叠但内容不同的 Skill？
   • 团队新成员加入时，有没有一个统一的地方可以获取所有已有的最佳实践？

3. 思考两个问题：

   • 如果某个同事的 Skill 特别好用，现在要分享给整个团队，最快的方式是什么？这个方式的痛点是什么？
   • 如果要建一个“团队 Skill 知识库”，让所有 AI 工具都能检索和调用，你认为最大的障碍是什么？

把你的盘点结果带到下一期。P5 我们将进入综合案例与度量——用一个完整的场景把 P1 到 P4 的内容串在一起，看看数据视角如何贯穿 Agent 产品的全生命周期。

延伸阅读

如果你对本期提到的概念想做进一步了解，以下是一些推荐资源：

• CoALA 论文中的程序记忆：Cognitive Architectures for Language Agents，论文中对程序记忆（Procedural Memory）的定义和分析，是理解 Skill 概念的理论基础
• Cursor Rules 文档：Cursor IDE 的 Rules 机制是当前最广泛使用的 Skill 实践之一，了解它的设计可以帮你理解 Skill 在实际产品中的形态
• Anthropic 的 Claude Code 最佳实践：Claude Code 的 CLAUDE.md 和 Memory 机制展示了另一种 Skill 管理思路
• 企业知识管理的演进历史：从个人文档到 SharePoint 到 Confluence 到 Notion，企业知识管理走过的路径，对理解 Skill 管理的未来方向有很好的参照价值

下一期预告：P5 · 综合案例与度量——我们用一个完整的 Agent 产品案例，把 P1 到 P4 的所有概念串在一起：场景判断、知识库设计、记忆系统、Skill 管理。你会看到，从产品经理的视角，数据层的决策如何贯穿 Agent 产品的每一个环节。

---

欢迎各位老师在 https://github.com/datawhalechina/easy-data-x-ai 参与课程共建。

也欢迎各位老师加入 Data x AI 交流群~