2026 年最让 AI 创业者困惑的问题之一:Skills 和 Tools 到底有什么区别?看完这篇,你不仅会分清,还会知道怎么在自己的 Agent 里落地。
前言
如果你在 2026 年做 AI Agent 开发,大概率遇到过这样的困惑:
- Cursor 的 Agent 能读文件,Claude Code 的 Agent 能跑命令,但它们"不认识"彼此的 MCP Server
- 你写了一个 MCP Tool 给 Agent 用,但 Agent 不会"正确地"用它——顺序错了、参数漏了、该先查哪个不知道
- 团队里有 30 个 MCP 工具,但 Agent 面对复杂任务时还是在"瞎猜"步骤
这些问题的根源其实是一个:你把"工具"和"技能"搞混了。
工具(Tool/MCP)解决的是"能不能做",技能(Skill)解决的是"怎么做才对"。
一位工程师在 Medium 上写道:"Agent Skills 和 MCP 不是二选一的竞争品——它们是 AI 智能体的黄金搭档。"这句话精准地戳破了 2026 年 AI 圈最大的认知混淆。
今天这篇文章,就用最直白的语言、最落地的代码示例,把这件事一次性讲清楚。
一、Function Call:给模型装上"标准化插口"
1.1 它是什么?
Function Call 的本质,是让大模型以工程化的方式调用某个具体工具或函数。
在 Function Call 出现之前,模型想调用外部能力只能"口头表达"——比如它输出:"请帮我查询北京天气"。对人类来说这是明确的请求,但对机器来说,它不知道这是普通文本还是真正的调用指令。
Function Call 改变了这一点。开发者提前告诉模型:
模型就不会再输出"请帮我查天气",而是输出结构化调用意图:
1.2 它解决什么问题?
三个核心问题:
- 模型如何准确发起一次工具调用——明确告诉系统:调哪个函数、传哪些参数
- 模型输出如何变成机器可执行的动作——结构化调用方便程序处理、校验、重试、记日志
- 减少非结构化输出带来的歧义——参数格式统一了,系统更稳定
1.3 典型特征
| 维度 | 特征 |
|---|---|
| 粒度 | 小,通常代表一个具体动作(搜网页、读文件、查天气、写数据库) |
| 接口 | 清晰,强调参数 schema、字段类型、必填项、返回值结构 |
| 层级 | 偏执行层,关注的是"怎么把动作调出来" |
说白了,Function Call 是给模型装上的标准化插口——模型通过这个插口去调用外部世界的具体能力。
二、MCP:把"插口"变成"万能充电口"
2.1 从 Function Call 到 MCP
Function Call 定义了"一次调用长什么样",但它没解决另一个核心问题:工具怎么被发现、怎么被管理、怎么跨平台复用。
这就是 MCP(Model Context Protocol)做的事。
MCP 本质是 Anthropic 在 2024 年底发布的一个开放协议,它定义了 AI 模型与外部工具/数据源之间的标准化通信方式。
类比一下:
- Function Call ≈ USB 接口的物理规格(针脚排列、电压)
- MCP ≈ USB 协议栈(设备枚举、数据传输、热插拔)
有了 MCP,一个工具写好一次,就能被 Claude Desktop、Cursor、Claude Code、以及任何支持 MCP 的 Agent 框架使用——不需要为每个平台重写。
2.2 MCP Server 实战示例
一个最简单的 MCP Server(Python)长这样:
配置到 Claude Code 的 claude_desktop_config.json 中:
Agent 就能直接调用 search_company 了。
三、Skills:给模型装上"经验层"
3.1 它是什么?
如果说 Function Call 解决的是"怎么调用一个工具",那 Skills 解决的是:
- 什么时候该接这个活
- 接到活之后先干什么、再干什么
- 哪些步骤不能省
- 哪些坑不要踩
- 最终产出应该长什么样
Skills 本质上是一个可复用的经验包——它把"老手的做法"打包成模型可以直接套用的说明书。
3.2 Skills 典型特征
| 维度 | 特征 |
|---|---|
| 粒度 | 大,通常对应一类任务,而不是单个动作 |
| 内容 | 包含方法论:步骤、质量标准、注意事项 |
| 层级 | 偏策略层,关注的是"这类任务怎么做更稳" |
3.3 Skills 的实战结构
以 Hermes Agent 中的 Skill 为例,一个典型 Skill 目录结构:
skill.md 是核心——它用 Markdown 告诉模型:
有了这个 Skill,Agent 面对故障时不再是"临场发挥"——它有一套经过验证的诊断章法。
四、核心区别:一张表看懂
▲ Skills vs MCP Tools 核心区别对比:粒度、关注点、表现形式全方位对照
| 维度 | Function Call / MCP Tool | Agent Skill |
|---|---|---|
| 粒度 | 原子动作(查天气、读文件) | 复合任务(诊断故障、写周报) |
| 关注点 | 调哪个函数、参数是否合法 | 步骤怎么组织、经验怎么沉淀 |
| 表现形式 | JSON Schema / 接口定义 | Markdown 文档 + 执行脚本 |
| 复用方式 | MCP 协议跨平台复用 | 领域经验跨场景复用 |
| 设计者 | 工程师(定义接口) | 领域专家(沉淀流程) |
| 解决的问题 | "能不能做到" | "怎么做才对" |
五、实战:Skill + MCP Tool 协同工作的完整示例
▲ Agent能力分层架构:Skills策略层编排流程,MCP Tools执行层提供原子能力
理论讲完了,来看一个真实场景——用 Hermes Agent 搭建一个"AI 内参内容工厂"的生产者 Agent。
场景描述
我们要做一个 Agent,每天自动:
- 搜索最新 AI 新闻
- 判断哪些值得写成文章
- 生成草稿
- 提交到微信公众号草稿箱
架构设计
三个 Skill 各自定义"怎么做":
Skill 1:热点扫描(ai-neican-hotspot)
Skill 2:内容写作(ai-neican-content-pipeline)
Skill 3:发布
每个 Skill 在执行过程中,会调用底层的 MCP Tools:
关键设计原则
- Skill 管流程,Tool 管执行——Skill 里不要写"用什么 HTTP 库调 API",那是 Tool 的事
- 一个 Skill 对应一个完整的业务场景——不是"读文件"这种动作级的事
- Skill 可以调用多个 Tool——Skill 是编排者,Tool 是执行者
- Skill 之间可以串联——热点扫描的输出,直接喂给内容写作的输入
六、三大主流框架的 Skill/Tool 实现对比
▲ 三大主流AI Agent框架的Skill/Tool实现对比:Claude Code、Hermes Agent、OpenClaw
6.1 Claude Code
Claude Code 的 Skill 系统通过 CLAUDE.md 和自定义 Slash Commands 实现:
MCP 工具通过 claude_desktop_config.json 配置,Skill 通过 .md 文件定义——泾渭分明。
6.2 Hermes Agent
Hermes Agent 的 Skill 系统更规范:
- 每个 Skill 一个目录,包含
skill.md(标准格式) - Skill 可注册 triggers(关键词触发)
- 支持子 Agent 委托(delegate_task)
6.3 OpenClaw
OpenClaw 的 Skill 市场是 2026 年的一大亮点——已有超过 200 个社区贡献的 Skill,涵盖:
- 编码类:代码审查、重构建议、测试生成
- 运营类:公众号排版、数据分析、周报生成
- 商业类:竞品分析、市场调研、财务建模
下载即用,Skill 和底层的 Playwright/API MCP Tool 无缝配合。
七、踩坑清单:我们在生产环境遇到的 5 个实际问题
坑 1:把 Skill 写成"超长 Tool 描述"
症状:在一个 MCP Tool 的 description 里写了 500 字的"使用指南",结果 Agent 根本看不完。
根因:Tool 的 description 应该简洁告诉模型"这个工具能干什么、需要什么参数"。至于"什么时候用、按什么顺序用",那是 Skill 的事。
修复:精简 Tool description 到 50 字以内,把使用指南移到 Skill.md。
坑 2:Skill 之间互相不知道对方存在
症状:热点扫描 Skill 生成了选题,但内容写作 Skill 不知道——每次都要重新搜索。
根因:Skill 之间没有显式的数据传递约定。
修复:在 Skill.md 中明确定义输出格式,下一个 Skill 直接读取上一个 Skill 的输出文件:
坑 3:MCP Tool 的返回结果没有结构化
症状:Agent 调用了 Tool,拿到了结果,但不知道结果的哪个字段代表什么——反复重试。
修复:Tool 返回明确的 JSON 结构,并在 description 中说明:
坑 4:Skill 里写了太多技术细节
症状:Skill.md 里出现了 subprocess.run(["curl", "-s", ...]) 这种执行细节。
修复:Skill 只说"调用 WeChat API 提交草稿",具体怎么调——那是发布脚本的事。Skill 是给 Agent 看的"任务说明书",不是给开发者看的"实现文档"。
正确写法:
坑 5:没有为 Skill 设置"不适用"的边界条件
症状:Agent 拿着"代码审查"Skill 去审查一篇 Markdown 文章——明显不适用,但 Skill 没有明确说"只适用于代码文件"。
修复:Skill.md 开头加边界声明:
八、总结:你该怎么落地?
如果你现在就要在自己的 AI Agent 里落地这套架构,三步走:
第一步:盘点现有工具 列出你的 Agent 现在能调用的所有 Tool/MCP Server。问自己:这些是原子能力吗?如果不是(比如一个 Tool 做了太多事),拆开。
第二步:识别高频任务场景 过去一周,你的 Agent 被要求做的最多的 3-5 类任务是什么?把它们沉淀为 Skill。
第三步:迭代 Skill 内容 前 10 次让 Skill 执行任务时,记录 Agent 的"翻车"点——跳过了什么步骤、参数填错了什么、顺序搞反了什么——然后更新 Skill.md 把这些教训写进去。
一句话记住:Tool 是锤子,Skill 是木工手册。锤子能敲钉子,但手册告诉你先量尺寸、再画线、最后才敲——而且敲的时候锤子要垂直。
#AI创业 #Agent工坊 #MCP #Skills #一人公司
本文由AI辅助创作,经人工审核编辑发布
