Agent工坊

【Agent工坊】Agent Skills vs MCP Tools:别再混淆了——AI Agent 能力架构的终极指南

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 改变了这一点。开发者提前告诉模型:

{

  "name": "get_weather",

  "description": "查询指定城市的天气",

  "parameters": {

    "type": "object",

    "properties": {

      "city": {"type": "string", "description": "城市名称"}

    },

    "required": ["city"]

  }

}

模型就不会再输出"请帮我查天气",而是输出结构化调用意图:

{"name": "get_weather", "arguments": {"city": "Beijing"}}

1.2 它解决什么问题?

三个核心问题:

  1. 模型如何准确发起一次工具调用——明确告诉系统:调哪个函数、传哪些参数
  2. 模型输出如何变成机器可执行的动作——结构化调用方便程序处理、校验、重试、记日志
  3. 减少非结构化输出带来的歧义——参数格式统一了,系统更稳定

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)长这样:

# server.py - 一个查询公司信息的 MCP Server

from mcp.server import Server, NotificationOptions

from mcp.server.models import InitializationCapabilities

import mcp.server.stdio

import mcp.types as types

server = Server("company-lookup")

@server.list_tools()

async def handle_list_tools() -> list[types.Tool]:

    return [

        types.Tool(

            name="search_company",

            description="通过公司名称搜索工商信息",

            inputSchema={

                "type": "object",

                "properties": {

                    "name": {"type": "string", "description": "公司全称或关键字"}

                },

                "required": ["name"]

            }

        )

    ]

@server.call_tool()

async def handle_call_tool(

    name: str, arguments: dict

) -> list[types.TextContent]:

    if name == "search_company":

        company_name = arguments["name"]

        # 实际查询逻辑

        result = query_database(company_name)

        return [types.TextContent(type="text", text=str(result))]

    raise ValueError(f"未知工具: {name}")

async def run():

    async with mcp.server.stdio.stdio_server() as (read, write):

        await server.run(read, write, ...)

if __name__ == "__main__":

    import asyncio

    asyncio.run(run())

配置到 Claude Code 的 claude_desktop_config.json 中:

{

  "mcpServers": {

    "company-lookup": {

      "command": "python3",

      "args": ["/path/to/server.py"]

    }

  }

}

Agent 就能直接调用 search_company 了。

三、Skills:给模型装上"经验层"

3.1 它是什么?

如果说 Function Call 解决的是"怎么调用一个工具",那 Skills 解决的是:

  • 什么时候该接这个活
  • 接到活之后先干什么、再干什么
  • 哪些步骤不能省
  • 哪些坑不要踩
  • 最终产出应该长什么样

Skills 本质上是一个可复用的经验包——它把"老手的做法"打包成模型可以直接套用的说明书。

3.2 Skills 典型特征

维度特征
粒度大,通常对应一类任务,而不是单个动作
内容包含方法论:步骤、质量标准、注意事项
层级策略层,关注的是"这类任务怎么做更稳"

3.3 Skills 的实战结构

以 Hermes Agent 中的 Skill 为例,一个典型 Skill 目录结构:

my-skill/

├── skill.md # 描述 & 触发条件 & 执行流程

├── scripts/

│ └── handler.py # 执行逻辑

└── requirements.txt # 依赖(可选)

skill.md 是核心——它用 Markdown 告诉模型:

<hr>

name: incident-diagnosis

description: 线上故障快速诊断与止损

triggers:

  - 用户报告服务异常

  - 监控告警触发

<hr>

# 线上故障诊断 Skill

## 核心流程

### 第一步:确认故障范围

1. 检查受影响的服务列表

2. 确认是单机/单服务还是整条链路

3. 查看最近 30 分钟内的发布记录

### 第二步:优先排查高概率路径

按以下优先级:

1. 最近是否有发布?→ 检查变更日志

2. 依赖服务是否超时?→ 检查下游 RT

3. 流量是否突增?→ 检查 QPS 曲线

4. 资源是否打满?→ 检查 CPU/内存/连接数

### 第三步:交叉验证

- 将监控数据、日志、变更记录多维交叉比对

- 不要只看单一指标下结论

### 第四步:输出诊断报告

格式:

- 故障时间范围

- 根因分析(证据链)

- 影响范围

- 建议止损动作

有了这个 Skill,Agent 面对故障时不再是"临场发挥"——它有一套经过验证的诊断章法。

四、核心区别:一张表看懂

Skills vs MCP对比

▲ Skills vs MCP Tools 核心区别对比:粒度、关注点、表现形式全方位对照

维度Function Call / MCP ToolAgent Skill
粒度原子动作(查天气、读文件)复合任务(诊断故障、写周报)
关注点调哪个函数、参数是否合法步骤怎么组织、经验怎么沉淀
表现形式JSON Schema / 接口定义Markdown 文档 + 执行脚本
复用方式MCP 协议跨平台复用领域经验跨场景复用
设计者工程师(定义接口)领域专家(沉淀流程)
解决的问题"能不能做到""怎么做才对"

五、实战:Skill + MCP Tool 协同工作的完整示例

Agent能力分层架构

▲ Agent能力分层架构:Skills策略层编排流程,MCP Tools执行层提供原子能力

理论讲完了,来看一个真实场景——用 Hermes Agent 搭建一个"AI 内参内容工厂"的生产者 Agent。

场景描述

我们要做一个 Agent,每天自动:

  1. 搜索最新 AI 新闻
  2. 判断哪些值得写成文章
  3. 生成草稿
  4. 提交到微信公众号草稿箱

架构设计

┌─────────────────────────────────────────┐

│ Agent 主控 │

│ │

│ ┌──────────┐ ┌──────────┐ ┌────────┐ │

│ │ Skill: │ │ Skill: │ │ Skill: │ │

│ │ 热点扫描 │ │ 内容写作 │ │ 发布 │ │

│ └────┬─────┘ └────┬─────┘ └───┬────┘ │

│ │ │ │ │

│ ▼ ▼ ▼ │

│ ┌─────────────────────────────────────┐ │

│ │ MCP Tool 层 │ │

│ │ web_search read_file write_file │ │

│ │ terminal web_extract patch │ │

│ └─────────────────────────────────────┘ │

└─────────────────────────────────────────┘

三个 Skill 各自定义"怎么做":

Skill 1:热点扫描(ai-neican-hotspot)

## 执行流程

1. 用 web_search 搜索 5 个关键词

2. 交叉比对结果,去重

3. 按 HN 热榜分数 + 赛道相关性打分

4. Points > 50 且与 AI 创业相关的,进入候选列表

5. 输出:候选选题表(标题 + URL + 热度分数)

Skill 2:内容写作(ai-neican-content-pipeline)

## 执行流程

1. 接收选题,用 web_extract 提取原文核心信息

2. 按三根支柱框架组织内容(工具 + 新闻 + 挣钱方法论)

3. 字数 ≥ 1500,必须含数据、案例、可操作建议

4. 保存到 content/draft-YYYYMMDD-HHMM-关键词.md

Skill 3:发布

## 执行流程

1. 调用 build_article_html.py 生成 HTML

2. 调用 make_cover.py 生成封面

3. 调用 gen_image.py 生成 3 张配图

4. 通过 WeChat API 提交到草稿箱

5. 验证草稿箱中文章存在

每个 Skill 在执行过程中,会调用底层的 MCP Tools:

热点扫描 Skill

  → web_search("Hermes Agent 2026 release")

  → web_search("Claude Code new feature")

  → web_search("MCP tool AI agent")

  → 汇总结果 → 打分 → 输出选题表

内容写作 Skill

  → web_extract(url) 提取原文

  → read_file("content/template.md") 读模板

  → write_file("draft-xxx.md", content) 保存草稿

发布 Skill

  → terminal("python3 build_article_html.py") 排版

  → terminal("python3 make_cover.py") 封面

  → terminal("curl WeChat API") 提交

关键设计原则

  1. Skill 管流程,Tool 管执行——Skill 里不要写"用什么 HTTP 库调 API",那是 Tool 的事
  2. 一个 Skill 对应一个完整的业务场景——不是"读文件"这种动作级的事
  3. Skill 可以调用多个 Tool——Skill 是编排者,Tool 是执行者
  4. Skill 之间可以串联——热点扫描的输出,直接喂给内容写作的输入

六、三大主流框架的 Skill/Tool 实现对比

三大框架对比

▲ 三大主流AI Agent框架的Skill/Tool实现对比:Claude Code、Hermes Agent、OpenClaw

6.1 Claude Code

Claude Code 的 Skill 系统通过 CLAUDE.md 和自定义 Slash Commands 实现:

<!-- CLAUDE.md - 项目级 Skill 配置 -->

# 项目规范

## 代码审查 Skill

当用户请求代码审查时:

1. 先运行 `npm run lint` 检查格式

2. 再运行 `npm run test` 检查功能

3. 逐文件审查:命名规范 → 类型安全 → 错误处理 → 性能

4. 输出审查报告:严重/一般/建议 三级分类

MCP 工具通过 claude_desktop_config.json 配置,Skill 通过 .md 文件定义——泾渭分明。

6.2 Hermes Agent

Hermes Agent 的 Skill 系统更规范:

  • 每个 Skill 一个目录,包含 skill.md(标准格式)
  • Skill 可注册 triggers(关键词触发)
  • 支持子 Agent 委托(delegate_task)

# skill.md 的 YAML front matter

<hr>

name: code-review

triggers:

  - review code

  - check PR

  - 代码审查

<hr>

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 的输出文件:

# 热点扫描 Skill 输出

输出文件:/tmp/hot_topics.json

格式:[{"title": "...", "url": "...", "score": 85}, ...]

# 内容写作 Skill 输入

读取 /tmp/hot_topics.json,按 score 降序处理

坑 3:MCP Tool 的返回结果没有结构化

症状:Agent 调用了 Tool,拿到了结果,但不知道结果的哪个字段代表什么——反复重试。

修复:Tool 返回明确的 JSON 结构,并在 description 中说明:

@server.call_tool()

async def search_news(query: str) -> list[types.TextContent]:

    result = {

        "status": "ok",

        "count": 5,

        "articles": [

            {"title": "...", "url": "...", "summary": "..."},

        ]

    }

    return [types.TextContent(type="text", text=json.dumps(result, ensure_ascii=False))]

坑 4:Skill 里写了太多技术细节

症状:Skill.md 里出现了 subprocess.run(["curl", "-s", ...]) 这种执行细节。

修复:Skill 只说"调用 WeChat API 提交草稿",具体怎么调——那是发布脚本的事。Skill 是给 Agent 看的"任务说明书",不是给开发者看的"实现文档"。

正确写法

### 步骤 6:提交草稿

调用发布脚本完成提交

坑 5:没有为 Skill 设置"不适用"的边界条件

症状:Agent 拿着"代码审查"Skill 去审查一篇 Markdown 文章——明显不适用,但 Skill 没有明确说"只适用于代码文件"。

修复:Skill.md 开头加边界声明:

## 适用范围

- ✅ 适用:TypeScript/Python/Go 源代码文件

- ❌ 不适用:Markdown 文档、配置文件、JSON 数据

八、总结:你该怎么落地?

如果你现在就要在自己的 AI Agent 里落地这套架构,三步走:

第一步:盘点现有工具 列出你的 Agent 现在能调用的所有 Tool/MCP Server。问自己:这些是原子能力吗?如果不是(比如一个 Tool 做了太多事),拆开。

第二步:识别高频任务场景 过去一周,你的 Agent 被要求做的最多的 3-5 类任务是什么?把它们沉淀为 Skill。

第三步:迭代 Skill 内容 前 10 次让 Skill 执行任务时,记录 Agent 的"翻车"点——跳过了什么步骤、参数填错了什么、顺序搞反了什么——然后更新 Skill.md 把这些教训写进去。


一句话记住:Tool 是锤子,Skill 是木工手册。锤子能敲钉子,但手册告诉你先量尺寸、再画线、最后才敲——而且敲的时候锤子要垂直。


#AI创业 #Agent工坊 #MCP #Skills #一人公司

本文由AI辅助创作,经人工审核编辑发布