最近有个感受：AI 领域的新名词，更新得比手机型号还快。前天大家都在聊「函数调用（Function Calling）」是怎么回事，昨天还在看「MCP」，今天又冒出来一个「Skills」。之前还会追踪最新的AI发展方向。可渐渐地发现，自己永远跟不上AI发展的脚步。每次看到这些新词，第一反应都是：是不是我又落伍了？

当初「MCP」出来的时候，也去学习和调研MCP，但也没有真正用到和落地的场景。最近比较火的「Skills」，本来也是这种心态---【看不上】。但是呢，在X的大牛们都在推荐，不行，我得学习一下了，要不然就不是【看不上】，而是【看不懂】【跟不上】了

名词去魅-Skills

你可以把 Skills 理解成一份“操作手册”。

就像你新招了一个实习生，不想每次都从头教他怎么做代码审查、怎么写 commit message、测试要跑哪些，于是把这些经验整理成文档，放在一旁。下次再遇到类似任务，他自己翻一翻，就知道该怎么做。

Skills 也是这样：它是一组用 Markdown 写下来的流程和规则，告诉 AI 在某一类任务下可以按什么套路来。最特别的地方在于，它不是靠你手动指定的——当你描述一个任务时，AI 会先判断：**“这个情况我是不是已经有现成的操作手册？”**如果有，就会自动加载并使用。

而 Agents，更像是一个“会自己干活的实习生”。你只需要给它一个目标，比如“把这个 PR 审完”，它会自己决定先看哪些文件、用什么标准、要不要查资料，并一步步完成任务。

所以两者的分工其实很清晰： Skills 负责沉淀“怎么做”的经验，是被动的； Agents 负责判断“做什么、什么时候做”，是主动的。

也正因为 Agent 有这种自主性，Skills 才不再是死规则，而是能在执行中被不断修正和复用的经验集合。

为什么会出现Skills

Skills 并不是凭空出现的概念，而是 AI 能力在工程实践中，一步一步“被逼”出来的结果。

Function Calling

2023 年前后，一个叫「函数调用」（Function Calling）的概念火了起来。你可以把它理解成：给那个「只会聊天的 AI」配了一部电话和一本通讯录。以前的 AI，你问它「今天北京天气怎么样」，它要么从训练数据里瞎猜一个，要么老老实实说「我不知道」。因为它没有「手脚」，不能真的去查天气。 有了函数调用之后，情况变了。开发者事先告诉 AI：「这是一本通讯录，里面有个叫 get_weather 的函数，你想查天气就打这个电话。

AI 收到「今天北京天气怎么样」的问题后，它会自己判断：「哦，这个问题我得打电话给 get_weather 才能回答。」然后它生成一段标准格式的「便签」（叫 JSON），上面写着：

{
  "function": "get_weather",
  "arguments": {
  "city": "北京"
  }
}

这段便签被外部程序接收、解析、执行。真正打电话给气象台的，是外部程序，不是 AI 自己。执行完后，结果返回给 AI，AI 再用人话告诉你：「北京今天晴，15 度。」

传统函数是「确定性」的——程序员在代码里写了 getWeather()，100% 会执行。但 LLM 的函数调用是「概率性」的——AI 看到「今天天气怎么样」，它要自己判断该不该调用天气函数。这个判断是基于理解，不是基于规则。有小概率它会判断错误，比如把「天气」理解成某个人名。所以说，函数调用的本质是：让 AI 能「打电话」，但打不打、打给谁，它自己决定。

这是一个巨大的进步 ——模型终于不只是聊天，还能真去调接口、查数据、改状态。AI 不再只是「知识库」，它开始变成「行动者」。
但很快就发现一个问题——它太“一次性”，“零散”了。

  1. 每个函数调用，都是当场想、当场拼；逻辑稍微复杂一点，prompt 就开始堆条件、塞示例，改一次要通篇重写，完全不可维护。

  2. AI 配了十几个函数，它每次只能选一个打电话。如果一个任务需要连续调用五六个函数、中间还有逻辑判断、还需要参考一些文档，函数调用就不够用了。

后来有人觉得不对劲：“是不是该把工具、上下文、能力统一管起来？”于是就有了 MCP。

MCP：AI 世界的 USB 协议

正如上面所说，在 Function Calling 时代，每个函数都是一次性的：函数怎么描述、参数怎么写、什么时候能用，完全依赖 prompt 当场拼装。一旦函数数量变多，就会出现几个典型问题：工具定义散落在各处，难以统一维护；模型只能“临时看到”当前 prompt 里的函数，对整体工具空间没有概念；跨工具协作几乎不可能，每一步都要人来兜底。

MCP 的目标，正是补上这一层结构。2024 年 11 月，Anthropic 开源了 MCP（Model Context Protocol，模型上下文协议）。它做的事情，和 USB-C 统一充电接口很像：定义一套标准协议，让 AI 和工具之间的连接不再“各玩各的”。
MCP把工具的名称、能力描述、参数定义、示例用法统一成标准格式，并通过 MCP Server 提供给模型。模型不再是“临时知道我能调哪个函数”，而是在一个完整、稳定的工具上下文里工作。

从这个角度看，MCP 确实解决了 Function Calling 的核心短板：它让工具不再是 prompt 里的零散补丁，而是一个可管理、可扩展的能力集合。Function Calling 解决的是“能不能调用”，而 MCP 解决的是“调用这件事怎么长期维护”。

只是，新的问题也随之出现了。

MCP 的致命问题：上下文爆炸

MCP 有一个严重的副作用：吃掉你的上下文窗口。

每个 MCP Server 连接到 AI 时，必须把所有工具的定义（名称、描述、参数、示例）一次性塞进上下文。一个工具的定义大概 500-800 tokens，一个 MCP Server 通常有 10-20 个工具。

  • GitHub MCP Server：27 个工具，消耗约 18,000 tokens

  • Playwright MCP Server：21 个工具，消耗约 13,600 tokens

  • mcp-omnisearch：20 个工具，消耗约 14,200 tokens

这意味着什么？你问 AI"2+2 等于几"，它回答"4"只需要 5 个 token，但工具定义已经消耗了 15,000 tokens。简单问题的成本被放大了 3000 倍。

更糟糕的是，当上下文被工具定义挤占后，AI 选错工具、传错参数的概率会显著上升。实践中，连接 2-3 个以上的 MCP Server，工具使用准确性就会明显下降。

Claude Code 的解法：Tool Search

Anthropic 意识到了这个问题。2025 年 1 月，Claude Code 推出了 Tool Search 功能：

  • MCP 工具不再预加载，而是按需发现

  • 当工具定义超过上下文的 10% 时自动启用

  • AI 需要用某个工具时，先搜索再加载

效果立竿见影：从 77,000 tokens 降到 8,700 tokens，减少 85%。

但这只是在给 MCP 打补丁。问题的根源在于：MCP 的设计假设是"把所有工具摆出来让 AI 挑"，这在工具数量少的时候没问题，工具多了就撑不住。

Skills

Skills 的两大杀手锏——渐进式披露和脚本执行——让它能独立完成大量任务，不依赖 MCP。

渐进式披露解决了"知识太多"的问题：AI 不需要一次性加载所有信息，用到什么加载什么。

脚本执行解决了"交互太多"的问题：复杂流程封装成脚本，AI 只需要一次调用，中间过程不占用上下文。

渐进式披露

Skills 从一开始就采用了不同的设计哲学：渐进式披露（Progressive Disclosure）。

怎么理解呢？

想象你招了个新员工。传统做法是入职第一天把公司所有流程文档、规章制度、操作手册全部打印出来堆在他桌上，这就是 MCP 的做法。而 Skills 的做法是：先给一份简短的岗位说明，等他遇到具体问题时，再告诉他去翻哪本手册的哪一页。

技术上，Skills 是这样实现的：

第一层：元数据（启动时加载）

  • 只有名称和简短描述

  • 每个 Skill 约 100 tokens

  • 装 100 个 Skill 也只占 10,000 tokens

第二层：完整指令（相关时加载）

  • 当 AI 判断某个 Skill 与任务相关时，才读取完整的 SKILL.md

  • 建议控制在 5,000 tokens 以内

第三层：参考资料（需要时加载）

  • 详细的技术文档、API 说明、示例代码

  • 按需读取，用多少加载多少

  • 理论上可以包含无限内容

这意味着：一个 Skill 可以打包整套 API 文档、完整的数据字典、几百页的参考手册，但只要任务不需要，这些内容就永远不会占用上下文。

自带脚本

Skills 还有一个很多人忽略的能力：它可以自带可执行脚本。

一个典型的 Skill 文件夹结构是这样的：

Skills =「员工手册」+「工具箱」的组合。

员工手册告诉 AI：「当你遇到某类任务时，应该怎么做，分几步，每一步用什么工具。」工具箱里装着它需要用的脚本和参考资料。具体来说，一个 Skill 就是一个文件夹，里面有三样东西：

第一，

SKILL.md 文件。这是「指令」，用自然语言写的。告诉 AI：这个 Skill 是干什么的，什么情况下该用，怎么用，有什么注意事项。

第二，脚本。可以是 Python、JavaScript 或者其他语言写的代码。当 AI 需要「动手」的时候，就执行这些脚本。

第三，资源文件。比如参考文档、模板、配置文件。AI 在执行任务的时候可以查阅这些资料。

关键来了：当 AI 运行 scripts/validate.py 时，脚本代码本身不会加载到上下文，只有执行结果会返回。

这是什么概念？

假设你有一个 500 行的 Python 脚本，用来处理 PDF 表单。用传统方式，AI 要么自己写代码（消耗大量 tokens 生成），要么读取你的脚本再执行（脚本内容占用上下文）。而用 Skills，AI 直接运行预写好的脚本，整个过程可能只消耗 50 tokens 的输出结果。

脚本执行 = 零上下文成本 + 确定性结果

更重要的是：这些脚本通过 Agent 内置的 bash 工具执行，不需要 MCP。

Skills 支持的脚本语言包括 Python、Bash、JavaScript 等，基本上你系统能跑的都能用。这意味着：

  • 文件读写？Skill 脚本搞定

  • 数据处理？Skill 脚本搞定

  • 格式转换？Skill 脚本搞定

  • 本地 API 调用？Skill 脚本搞定

Skills VS MCP

对于喜欢 Skills 的人可能会想：我写个脚本自己用，干嘛搞那么复杂？我就是要编码一下我的工作流程，让 AI 能理解我们团队的做事方式，Skills 写起来简单，放个文件就行，何必折腾 MCP Server？

喜欢 MCP 的人则会认为：我要做一个服务，让所有人都能用，不只是我自己，不只是我团队。我要让用户输入一个 URL 就能用，甚至未来什么都不用装，直接问 AI"帮我订机票"就行。

仔细看其实这两拨人的需求完全不一样。不是功能差异，是分发方式的差异。Skills 是给自己人用的，MCP 是给全世界用的。

思考和总结

是否真正需要MCP

这是一个正在发生的趋势。但MCP 没死。Skills 也很有用。它们解决的是不同问题。

MCP 是 USB 协议，定义了 AI 与外部世界的连接标准；Skills 是应用程序，把专业知识和工作流程打包成 AI 能理解的操作手册。

需要 MCP 的场景：

  • 连接远程 CRM 系统获取客户数据

  • 调用第三方 SaaS API（Slack、Notion、Jira）

  • 查询云端数据库

  • 访问需要认证的外部服务

  • 做一个服务让外部用户都能用

不需要 MCP 的场景：

  • 读写本地文件 → bash + Skill 脚本

  • 处理 PDF/Word/Excel → Skill 脚本

  • 运行代码分析 → Skill 脚本

  • 执行 Git 操作 → Skill 脚本

  • 生成图表和可视化 → Skill 脚本

  • 优化自己或团队的工作流

到底怎么选

问自己三个问题：

最佳实践

最佳实践是两者配合使用：用 Skills 编码你的领域知识，用 MCP 连接外部服务。

未来的格局可能是这样的：

  • 少数通用 MCP Server 处理远程连接（数据库、云 API、SaaS 集成）

  • 大量 Skills 编码专业知识和本地工作流

  • 两者在必要时协作，但 Skills 会承担绝大部分"教 AI 怎么做事"的工作

比如你们公司有一套特定的工作流程，先查这个系统，再查那个系统，按某个顺序处理。这种领域知识用 Skills 写出来，让 AI 理解。但具体连接那些系统的能力，靠 MCP 提供。两层配合，各司其职。

随着 Skills 生态成熟，MCP 的角色会收窄到"远程连接"这个核心场景——需要实时访问外部 API、需要认证的 SaaS 服务、需要跨网络的数据库连接。而本地文件操作、浏览器自动化、数据处理这些任务，Skills + 内置工具就能搞定，而且效率更高。

对于开发者：优先用 Skills 封装工作流程，复杂逻辑用脚本而非让 AI 一步步操作，只在必须连接远程系统时才用 MCP。

Skills 和 MCP 不是竞争关系，而是不同层次的能力。但如果你只能选一个先学，选 Skills。它更轻量、更高效、更容易上手，能解决日常遇到的大部分问题。

资料

知识学习

https://x.com/servasyy_ai/status/2012770711551570074?s=20

https://x.com/0xyuker/status/2013094122656334136?s=12

https://x.com/wshuyi/status/2013940553281683588?s=46

https://x.com/dotey/status/2014025984895258934

实践教程

https://x.com/vista8/status/2009671866613649691?s=46

https://x.com/op7418/status/2013920609038893233?s=46

https://x.com/rionaifantasy/status/2013147408629408098?s=46

https://x.com/vista8/status/2010540934359097689

https://x.com/chengfeng240928/status/2011613934114030008?s=46

配图：https://github.com/JimLiu/baoyu-skills

claude

https://aibusiness.com/foundation-models/anthropic-launches-skills-open-standard-claude

# 人工智能
Logo
龙虾开发者社区

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用

更多推荐

学生党福音：OpenClaw+nanobot搭建学习监督助手

本文介绍了如何在星图GPU平台上自动化部署🐈 nanobot：超轻量级OpenClaw镜像，构建智能学习监督助手。该方案利用轻量级模型实现网课进度跟踪、自动生成练习题和错题整理功能，特别适合学生群体通过QQ机器人实现移动端学习管理，显著提升学习效率。

avatar 龙虾开发者社区

OpenClaw+GLM-4.7-Flash语音交互：对接Whisper实现语音控制

本文介绍了如何在星图GPU平台上自动化部署【ollama】GLM-4.7-Flash镜像，构建语音交互系统。该系统结合Whisper语音识别与GLM-4.7-Flash的指令理解能力，实现智能家居控制等场景的语音操作，提升日常任务执行效率。

avatar 龙虾开发者社区

OpenClaw创意工坊：用nanobot镜像生成技术海报文案

本文介绍了如何在星图GPU平台上自动化部署🐈 nanobot：超轻量级OpenClaw镜像，快速生成技术海报文案。该镜像基于Qwen3-4B模型，能将复杂技术术语转化为通俗表达，适用于技术活动宣传、社交媒体推广等场景，显著提升内容创作效率。

avatar 龙虾开发者社区