MCP与Skill：AI Agent能力扩展的核心机制与实战指南

很多接触 AI Agent 的人，都是从“聊天机器人”开始的。最初你可能只是让大模型回答几个问题，后来你开始用 Function Calling 让它帮忙查天气、订闹钟。再往后你会发现：当任务一复杂，Agent 的能力立刻露馅——它不知道你的数据库结构，调不了你们的内部 API，也无法把一个多步骤的业务流程完整跑完。

这时候，MCP 和 Skill 这两个词开始高频出现。打开技术社区，“AI Agent 进阶必学 MCP”“Skill 是 Agent 能力的核心”之类的说法铺天盖地。但很多人看完仍然是一头雾水：

• MCP 到底是个协议，还是一种工具？
• Skill 是提示词模板，还是一个可执行的代码包？
• MCP Server 怎么搭建，怎么让 Agent 真正调用起来？
• MCP 和 Skill 到底是什么关系，先学哪个？

这篇文章会把这些问题完整讲清楚。我会从真实开发场景出发，先讲清 MCP 与 Skill 的核心原理，再带你动手搭建一个 MCP Server、设计一个 Skill，最后把两者组合成一个完整的 Agent 能力扩展方案。读完你不仅知道“是什么”，还能照着做出一套可用的能力扩展流程。

1. 这篇文章真正要解决的问题

先给一个明确判断：AI Agent 的能力上限，不取决于模型参数，而取决于它周围连接了多少工具、封装了多少可复用的工作流。MCP 和 Skill 就是当前 Agent 能力扩展最主流的两种载体——前者解决“Agent 如何接入外部工具和数据”，后者解决“Agent 如何复用复杂任务流程”。

很多人在 Agent 开发中遇到的问题是：

第一，工具调用难以标准化。每个外部服务都有自己的 API、鉴权方式和返回格式，Agent 每次对接新服务都要写大量定制代码。今天对接一个天气 API，明天对接一个数据库，后天对接一个设计工具，每个都要重新适配。

第二，复杂任务的流程经验难以沉淀。你花了一周时间调通一套“数据提取—清洗—汇总—生成报告”的流程，然后呢？下次换一个数据源，又要重新来一遍。这套流程本身没有被封装成可复用的能力。

第三，Agent 的“感知边界”很窄。默认情况下，大模型只能看到你喂给它的文本。它读不了你的数据库，操作不了你的设计稿，也不知道当前项目的文件结构。如果想让 Agent 真正像“员工”一样工作，必须给它接上“手”和“眼”。

MCP（Model Context Protocol）解决的是感知和执行边界的问题。它定义了一套标准化协议，让 Agent 可以通过 MCP Server 连接任意外部工具和数据源。Skill（技能）解决的是流程复用的问题。它把一组指令、上下文和操作步骤封装成一个可调用的技能包，让 Agent 面对某类任务时能“按套路出牌”。

这篇文章适合这几类读者：

• 已经在用 AI 编程工具，想让 Agent 能操作更多外部系统的开发者。
• 正在做 Agent 应用，但工具接入方式混乱、流程不可复用的技术负责人。
• 对 MCP 和 Skill 有初步了解，但还搞不清两者关系，想找一个系统答案的学习者。

2. 核心概念：MCP 是什么，Skill 是什么

在动手之前，必须先把两个概念彻底理清。很多人的困惑恰恰来自这里。

2.1 MCP：Agent 连接外部世界的标准化协议

MCP 全称 Model Context Protocol，是由 Anthropic 提出的开放协议。它要解决的核心问题是：如何让 AI 模型以标准化的方式访问外部数据和工具。

在没有 MCP 之前，Agent 接入一个外部服务通常是这样：

Agent → 你写的 Function Calling 函数 → 你的后端接口 → 外部服务

每接入一个新服务，你都要写一遍“Agent 怎么理解用户的请求并决定调用哪个函数”的逻辑，还要处理不同服务的认证、参数格式、返回值格式。这些代码和服务强绑定，换一个服务基本要重写。

有了 MCP 之后，模型和工具之间多了一层标准协议：

Agent（MCP Client） ↔ MCP Server ↔ 外部服务 / 数据源

MCP Server 是一个独立运行的进程或服务，它负责把外部能力“翻译”成标准的 MCP 接口。Agent 通过 MCP Client 连接 Server，动态发现工具列表、调用工具、读取资源。新增一种能力时，只需要新增一个 MCP Server，Agent 侧无需大量定制开发。

从架构上看，MCP 有三个核心概念：

简单说，MCP 是一个“插座标准”。Agent 是插座，MCP Server 是插头，任何服务只要按照标准做一个“插头”，就能被 Agent 使用。

2.2 Skill：可复用的任务执行能力包

Skill 的概念比 MCP 更抽象，不同产品对它的实现方式也有差异，但核心思想是一致的：把完成一类任务所需的指令、上下文、示例和操作流程封装成一个整体，让 Agent 可以按需加载和调用。

如果 MCP 解决的是“Agent 能碰到什么”，Skill 解决的就是“Agent 知道怎么干”。

举个例子。你在项目中总结出一套“数据库巡检”的方法：先检查表空间，再查看慢查询日志，然后分析连接数，最后生成一份巡检报告。这套方法包含步骤顺序、判断标准、SQL 语句、报告格式。如果你把它写成一个 Skill，以后每次让 Agent 做巡检，它就能直接调用这个 Skill，而不是每次都从零思考该怎么做。

Skill 和提示词模板的区别在于，Skill 通常是一个更完整的封装。它可能包含：

• 任务描述和触发条件
• 执行步骤和决策规则
• 参考示例（比如 few-shot 示例）
• 可能需要的工具或脚本
• 输出格式约束

Skill 关注的不是“调用什么工具”，而是“如何完成一件事”。

2.3 MCP 与 Skill 的关系：工具能力与流程能力

讲了这么多，MCP 和 Skill 到底什么关系？我的判断是：

MCP 是 Agent 的“手”和“眼”，Skill 是 Agent 的“操作手册”。两者不是替代关系，而是配合关系。

实际工作中，MCP Server 提供了“查询数据库”的工具，Skill 则定义了“如何完成一次数据库巡检”的流程。流程里会用到查询数据库这个工具，但流程本身需要在更高层面被设计和封装。

如果这个对比还不够直观，可以用一个更生活化的例子：

你请了一个新助理。MCP 是给助理配的工具箱：里面有电脑、电话、打印机。Skill 是给助理的《工作手册》：接电话时先说什么、遇到投诉怎么处理、日报按什么格式写。工具决定了他能做什么，手册决定了他做得专不专业。

所以，回答一个常见问题：“先学 MCP 还是先学 Skill？”

我的建议是：先从 MCP 入手。因为 MCP 的生态和工具链更成熟，概念也更明确，你先能把 Agent 的外部能力打通。Skill 更像是对经验的抽象和封装，你至少要了解 Agent 的工作方式之后再做 Skill，才知道该封装哪些内容。

3. 为什么 AI Agent 必须做能力扩展

理解了概念，我们再从工程视角看：为什么 AI Agent 必须做能力扩展？

3.1 只靠大模型，Agent 的能力天花板很低

大模型本质上是一个“文本生成器”。你给它一段输入，它给你一段输出。它内部没有“真实世界”的概念——不知道当前时间是几点，不知道你数据库里的表结构，更不知道点击哪个按钮可以完成一次下单操作。

没有外部能力，Agent 就只能做“言之有理”但“无法落地”的事。它能告诉你应该查数据库，但它查不了；它能写出 SQL 语句，但它执行不了。这对真实业务来说几乎没有价值。

3.2 工具接入的标准化是规模化前提

当一个 Agent 要接入 5 个工具时，你可以用 Function Calling 硬编码全部逻辑，代码量还能接受。但当工具数量变成 50 个、100 个呢？每个工具都要管认证、管参数、管错误处理，工程复杂度是指数级上升的。

MCP 的价值在于，它把这套复杂度从 Agent 主程序里抽离出去。每个 MCP Server 自己处理认证、解析和适配，Agent 只需要了解标准的 MCP 接口如何调用。这个抽象的工程意义非常大。

3.3 流程经验的复用决定了团队效率

对一个团队来说，最大的浪费是“重复造轮子”。团队成员 A 花了一周总结出一套用 AI 做数据分析的最佳实践，但如果不封装成 Skill，团队 B 下个月还要从零摸索。Skill 把个人经验变成了团队资产，这才是它最值得被重视的地方。

所以，MCP 和 Skill 不仅是“给 Agent 加功能”，更是在工程层面上解决了 Agent 从“能用”到“好用”的关键问题。

4. 环境准备与前置条件

下面进入实操环节。我会以 Python 语言为例，演示如何搭建一个 MCP Server，以及如何设计一个 Skill。需要说明的是，MCP 目前提供了 Python 和 TypeScript 的官方 SDK，版本更新较快，以下代码以常见 API 为基础，具体版本请以官方文档为准。

4.1 运行环境

建议准备以下环境：

• Python 3.9 及以上版本
• pip 包管理工具
• 一个支持 Python 开发的 IDE（VS Code、PyCharm 均可）
• 一个 MCP Client 运行时环境

4.2 安装 MCP SDK

MCP 官方提供了 Python SDK，包名为mcp。安装命令：

pip install mcp

如果网络环境使用代理较慢，可以配置国内镜像源，例如：

pip install mcp -i https://pypi.tuna.tsinghua.edu.cn/simple

安装完成后，可以用下面命令验证 SDK 版本：

pip show mcp

4.3 目录结构规划

我们用一个最小项目来串联 MCP 和 Skill。建议按以下结构组织：

agent-skills-demo/ ├── server/ │ └── mcp_server.py # MCP Server 实现 ├── skills/ │ └── data_analysis/ │ ├── SKILL.md # Skill 的描述和触发条件 │ ├── steps.md # 执行步骤 │ └── examples.md # 示例 └── client/ └── client.py # MCP Client 测试入口

这个结构把 MCP Server 和 Skill 分开管理，后续扩展新的能力时不会互相干扰。

5. 第一个 MCP Server：为 Agent 提供数据库查询能力

先写一个最小可用的 MCP Server，给 Agent 提供“查询用户表”的工具。这个示例足够小，能让你看清 MCP 的工作原理。

5.1 创建 MCP Server

进入server目录，创建mcp_server.py：

# 文件路径：server/mcp_server.py import sqlite3 from mcp.server import Server from mcp.server.stdio import stdio_server from mcp.types import Tool, TextContent app = Server("demo-server") def query_db(sql: str): """执行 SQL 查询并返回结果。仅用于演示，生产环境务必做 SQL 安全校验。""" conn = sqlite3.connect("demo.db") try: cursor = conn.cursor() cursor.execute(sql) columns = [desc[0] for desc in cursor.description] rows = cursor.fetchall() return {"columns": columns, "rows": rows} finally: conn.close() @app.list_tools() async def list_tools(): return [ Tool( name="query_users", description="查询用户表中的数据，支持传入完整的 SELECT 查询条件", inputSchema={ "type": "object", "properties": { "condition": { "type": "string", "description": "SQL WHERE 条件，例如 'age > 18'，不需要写 WHERE" } } } ) ] @app.call_tool() async def call_tool(name: str, arguments: dict): if name == "query_users": condition = arguments.get("condition", "1=1") sql = f"SELECT id, name, age, city FROM users WHERE {condition}" result = query_db(sql) return [TextContent(type="text", text=str(result))] raise ValueError(f"未知工具: {name}") async def main(): async with stdio_server() as (read_stream, write_stream): await app.run(read_stream, write_stream, app.create_initialization_options()) if __name__ == "__main__": import asyncio asyncio.run(main())

注意，这段代码为了演示做了简化。实际项目中需要对 SQL 注入做严格防护，比如使用参数化查询，或者对传入条件做白名单校验。

5.2 准备测试数据库

为了让 MCP Server 能查到数据，我们需要先准备一个 SQLite 数据库：

mkdir -p server cd server python

在 Python 交互环境中执行：

import sqlite3 conn = sqlite3.connect("demo.db") cursor = conn.cursor() cursor.execute("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, age INTEGER, city TEXT)") cursor.execute("INSERT INTO users (name, age, city) VALUES ('张三', 25, '北京')") cursor.execute("INSERT INTO users (name, age, city) VALUES ('李四', 30, '上海')") cursor.execute("INSERT INTO users (name, age, city) VALUES ('王五', 22, '广州')") conn.commit() conn.close() print("数据库初始化完成")

这个命令会创建一个包含三条用户记录的 SQLite 数据库，供 MCP Server 查询。

5.3 MCP Server 的关键代码说明

这段代码虽然短，但值得拆解几个关键点：

@app.list_tools()是工具发现入口。正常情况下，MCP Client 连接 Server 后，会先调用这个接口获取工具列表。Agent 看到你有query_users工具，才会在需要查询用户时决定调用它。

@app.call_tool()是工具调用入口。当 Agent 决定调用某个工具时，会把工具名和参数传给这个函数。函数内部要做参数解析、业务执行和结果返回。

stdio_server()是当前最常用的传输方式。它让 MCP Server 通过标准输入输出来通信，非常适合本地开发场景。生产环境还可以用 SSE 或 Streamable HTTP 等方式，但原理是一致的。

如果你拿真实项目来对比，会发现这段代码的核心其实就是“注册工具”和“调用工具”两边的事。理解了这两个方法，你就能看懂任何 MCP Server 的骨架。

5.4 用 MCP Client 验证 Server

写完 Server 之后，需要一个 Client 来验证工具能不能被正确发现和调用。标准的做法是用官方 CLI 工具，这里我们写一个简单的 Python Client：

# 文件路径：client/client.py import asyncio from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client async def main(): server_params = StdioServerParameters( command="python", args=["server/mcp_server.py"], cwd="." ) async with stdio_client(server_params) as (read_stream, write_stream): async with ClientSession(read_stream, write_stream) as session: await session.initialize() tools = await session.list_tools() print(f"发现 {len(tools.tools)} 个工具:") for tool in tools.tools: print(f" - {tool.name}: {tool.description}") result = await session.call_tool("query_users", {"condition": "age > 20"}) print("\n调用结果:") for content in result.content: print(content.text) if __name__ == "__main__": asyncio.run(main())

运行命令：

python client/client.py

预期输出会包含query_users工具的信息，以及查询年龄大于 20 的用户结果：

发现 1 个工具: - query_users: 查询用户表中的数据，支持传入完整的 SELECT 查询条件 调用结果: {'columns': ['id', 'name', 'age', 'city'], 'rows': [[1, '张三', 25, '北京'], [2, '李四', 30, '上海'], [3, '王五', 22, '广州']]}

到这里，你已经拥有一个可以被 Agent 调用的 MCP Server 了。接下来把它接入真正的 Agent 软件，或者在自己开发的 Agent 里以 Client 方式连接它，就能让 Agent 具备查数据库的能力。

6. 设计一个 Skill：将数据分析流程沉淀为能力包

现在来看 Skill。Skill 没有像 MCP 那样严格的协议标准，不同产品实现有差异。我这里给你一套通用可用的设计思路——用 Markdown 文档组织 Skill 内容，让 Agent 在触发时读取并执行。

6.1 Skill 的组织形式

一个标准的 Skill 包可以包含以下文件和内容：

skills/data_analysis/ ├── SKILL.md # 技能元信息：名称、描述、触发条件 ├── steps.md # 执行步骤：做什么、按什么顺序做 ├── examples.md # 示例：输入输出对，引导 Agent 参考 └── resources/ # 可选的辅助资源文件

6.2 编写 SKILL.md 元信息

# 技能名称：数据分析报告生成 ## 描述 当用户需要分析一组数据（Excel、CSV 或数据库表），并生成结构化分析报告时使用。 包括数据概览、分布分析、异常检测和建议总结。 ## 触发条件 - 用户提到“分析数据”“生成报告”“数据洞察”等关键词 - 用户上传了数据文件或提供了可查询的数据源 ## 适用数据源 - SQLite / MySQL / PostgreSQL - CSV / Excel 文件 - 通过 MCP Server 暴露的其他数据服务

SKILL.md的作用是让 Agent 知道“什么时候该用这个技能”。它相当于技能包的入口索引。

6.3 编写 steps.md 执行步骤

# 执行步骤 1. 数据接入 - 优先通过 MCP Server 查询数据库获取数据。 - 如果是文件数据，先读取文件并解析为表格结构。 2. 数据概览 - 查看数据总行数、列数。 - 列出每一列的名称、数据类型、空值数量。 3. 分布分析 - 对数值型字段计算均值、中位数、最大值、最小值。 - 对类别型字段统计出现次数，找出 top 10 类别。 4. 异常检测 - 使用标准差或 IQR 方法，识别数值型字段的离群点。 - 对离群点给出业务解释，说明为什么需要关注。 5. 报告生成 - 按 Markdown 格式输出报告，包含章节标题。 - 每段分析必须有数据支撑，不得凭空结论。

steps.md是 Skill 的核心。它定义了完成任务的操作路径。多步任务的稳定输出，依赖于每一步都有明确标准和判断依据。

6.4 编写 examples.md 示例

# 示例 ## 示例 1：分析用户年龄分布 输入： "分析用户数据中的年龄分布" 输出（报告片段）： ## 用户年龄分布分析 数据源：users 表，共 3 条记录。 ### 数据概览 - 总行数：3 - 字段：id, name, age, city - 缺失值：0 ### 年龄分布 - 平均年龄：25.7 - 中位数：25 - 最小年龄：22 - 最大年龄：30 ### 异常检测 - 未发现明显离群点。 ### 建议 - 样本量较小，建议扩大数据范围后再做进一步分析。

示例的作用是给 Agent 一个“目标样子”。大模型对不确定的任务容易发挥不稳定，但有了示例，它就知道最终报告应该长这样。

6.5 Skill 如何被 Agent 使用

在支持 Skill 的 Agent 系统中，通常会有这样一个流程：

1. 收到用户消息后，Agent 先分析任务类型。
2. 在已安装的 Skill 列表中匹配描述，判断是否需要加载某个 Skill。
3. 加载 Skill 内容（SKILL.md、steps.md、examples.md）。
4. Agent 按照 steps.md 的步骤执行任务，期间可以调用 MCP Server 提供的工具。
5. 输出符合要求的报告。

你可以把这个过程理解为：Skill 是“菜谱”，MCP 工具是“厨具”。厨师做菜时先查菜谱决定步骤，再拿起对应的厨具执行。

7. 实践案例：MCP 与 Skill 联合完成数据分析任务

概念讲完了，两个组件也分别跑通了。现在把它们组合起来，模拟一个真实的完整场景：Agent 收到“分析用户表并按城市统计人数”的任务，自动调用 MCP Server 读取数据库，再按 Skill 的流程生成报告。

7.1 任务拆解

这个任务如果用传统方式，你需要自己写 SQL、自己组织报告格式、自己处理异常。有了 MCP + Skill 之后，预期流程是：

用户指令 → Agent 识别任务类型 → Agent 加载 data_analysis Skill → Agent 通过 MCP Server 暴露的 query_users 工具查询数据 → Agent 按 Skill 步骤生成报告 → 返回给用户

7.2 扩展 MCP Server 工具

为了让 Agent 能按城市统计，我们需要在 MCP Server 中增加一个聚合查询工具。在mcp_server.py中添加：

@app.call_tool() async def call_tool(name: str, arguments: dict): if name == "query_users": condition = arguments.get("condition", "1=1") sql = f"SELECT id, name, age, city FROM users WHERE {condition}" result = query_db(sql) return [TextContent(type="text", text=str(result))] if name == "count_users_by_city": sql = "SELECT city, COUNT(*) as cnt FROM users GROUP BY city ORDER BY cnt DESC" result = query_db(sql) return [TextContent(type="text", text=str(result))] raise ValueError(f"未知工具: {name}")

同时更新list_tools，把新工具注册进去：

Tool( name="count_users_by_city", description="按城市统计用户人数，返回城市和对应人数，结果按人数降序排列", inputSchema={"type": "object", "properties": {}} )

这样 Agent 就有了“按城市统计”这个能力。

7.3 手动模拟 Agent 执行流程

这里我们不用复杂的 Agent 框架，而是用一个 Python 脚本模拟 Agent 的决策过程，展示 Skill 加载和 MCP 调用如何配合：

# 文件路径：client/run_agent_demo.py import asyncio from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client async def main(): # 1. 连接 MCP Server server_params = StdioServerParameters( command="python", args=["server/mcp_server.py"], cwd="." ) async with stdio_client(server_params) as (read_stream, write_stream): async with ClientSession(read_stream, write_stream) as session: await session.initialize() # 2. Agent 决策：加载 data_analysis Skill 的步骤 print("Agent 已加载 Skill: data_analysis") print("步骤1: 数据接入 -> 通过 MCP 查询用户表") print("步骤2: 数据概览 -> 查询总行数") print("步骤3: 分布分析 -> 按城市统计用户数量") print() # 3. 调用 MCP 工具获取数据 overview_result = await session.call_tool( "count_users_by_city", {} ) print("MCP 查询结果（按城市统计）：") for content in overview_result.content: print(content.text) # 4. 按 Skill 输出报告 print() print("===== 分析报告 =====") print("数据源：users 表") print("分析维度：城市分布") print("结论：北京、上海、广州各 1 人，分布较为均匀。") print("建议：样本量有限，建议扩大数据范围后进一步分析城市间差异。") if __name__ == "__main__": asyncio.run(main())

运行：

python client/run_agent_demo.py

这个示例虽然用脚本手动模拟了“加载 Skill → 调用 MCP → 生成报告”的流程，但它清楚展示了真实 Agent 的执行逻辑。在实际的 Agent 框架里，Skill 的决策和 MCP 工具的选择由模型自主完成，但底层机制完全一致。

8. 常见问题与排查思路

在实际操作中，你会碰到不少问题。我整理了一份排查清单：

8.1 关于 SQL 注入的严肃提醒

上面的示例为了演示简单，直接拼接了 SQL。这是非常危险的写法。如果你在 SQL 中拼入用户输入，攻击者可以通过构造条件参数执行任意 SQL。在生产项目中，请务必使用参数化查询，或者对输入条件做严格的格式校验和字段白名单限制。

更稳妥的方案是：MCP Server 只暴露预定义的查询方法，而不是把灵活的 SQL 条件直接交给 Agent。比如定义get_user_by_id、count_users_by_city这类有固定入参的工具，既安全又清晰。

8.2 MCP 版本兼容问题

MCP SDK 的版本迭代比较快，不同版本的 API 可能有差异。如果按本文代码运行时遇到“AttributeError”或“DeprecationWarning”，优先查阅当前版本的官方文档或 SDK 源码，调整对应方法名和参数即可。

9. 最佳实践与工程建议

前面把最小流程跑通了。但项目一旦进入生产环境，以下几条建议值得你认真考虑。

9.1 最小权限原则

MCP Server 暴露的工具，权限域应该明确且最小。一个查询用户表的 Server，不应该有删除表的权限；一个读取文件的服务，不应该能写入任意路径。在连接数据库时，建议为 MCP Server 创建独立的只读账号，而不是使用最高权限的管理员账号。这一点对任何 Agent 能力扩展方案都适用。

9.2 工具命名与描述规范

Agent 是否调用某个工具，取决于工具的描述信息。描述写得越清楚，Agent 的判断就越准。建议按“动词 + 对象 + 限制条件”的格式写描述：

弱描述：一个查询函数 强描述：按城市统计用户人数，返回城市和对应人数，结果按人数降序排列

强描述能让 Agent 快速判断“这个工具是否适合当前任务”。

9.3 Skill 的粒度控制

Skill 不是越大越好，也不是越小越好。粒度太大，Agent 加载后难以精准执行；粒度太小，管理成本又高。我的建议是：一个 Skill 对应一个完整的业务产出物，比如“数据分析报告”“代码审查结果”“数据库巡检报告”。内部的步骤可以拆成多个函数或小流程，但 Skill 的对外入口要保持清晰。

9.4 日志与可观测性

Agent 调用了哪个工具、Skill 执行到哪一步、返回了什么结果——这些信息必须记录日志。没有日志，Agent 出错时你只能靠猜。建议在 MCP Server 的工具调用入口打点，在 Skill 的每个步骤末尾记录状态。

一个简单可行的做法是使用 Python 的 logging 模块：

import logging logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s") # 在工具调用入口 logging.info("tool %s called with args: %s", tool_name, arguments)

9.5 灰度发布与回滚

当你的 Agent 在环境里稳定运行后，新增能力时不要一次性全量替换。可以先将新的 MCP Server 部署在与旧版本不同的端口或服务名下面，用一小部分流量验证，确认无问题后再切换。如果 MCP Server 内部报错，Agent 应该能优雅降级，而不是整个流程中断。

9.6 注意 Skill 与 Prompt 的区别执行边界

Skill 不是“把一段长 Prompt 塞给 Agent”就完事。如果只是一个 Prompt，Agent 执行时的自由度太高，输出质量不稳定。更可靠的做法是把 Skill 拆成可执行的结构：哪些是静态指令、哪些需要调用工具、哪些步骤需要模型推理决策，边界要清楚。这也是 Skill 设计和 Prompt 设计最大的区别：Skill 要围绕任务交付物来做流程约束。

10. 总结与后续学习方向

回到开头的判断：AI Agent 的能力上限，取决于它的工具连接能力和流程复用能力。MCP 和 Skill 分别在这两个维度上给出了实际解决方案。这篇文章做了三件具体的事：

第一，讲清了 MCP 和 Skill 的概念边界与关系。MCP 解决工具接入标准化，Skill 解决任务流程复用，两者配合才能让 Agent 拥有真正的业务能力。

第二，从零搭建了一个可运行的 MCP Server，提供了一个可复用的 Skill 结构，并用一个完整示例展示了“Agent 加载 Skill → 调用 MCP 工具 → 生成报告”的组合流程。这套流程虽小，但压缩了 Agent 能力扩展的核心机制。

第三，补充了生产环境中必备的最佳实践：最小权限、命名规范、日志监控、灰度发布、安全防护。这些细节决定了你的 Agent 能否从 demo 走向稳定服务。

下一步，建议你从三个方向继续深入：

• 把你工作中最常用、最重复的一套流程抽象成第一个真正属于自己的 Skill。
• 选一个内部系统（比如内部知识库、运维平台）写一个 MCP Server，把能力开放给 Agent。
• 去读 MCP 协议的最新官方文档，重点关注 Streamable HTTP、OAuth 鉴权等生产级特性。

如果你的 Agent 现在只能“聊天”，那么这篇文章就是把它变成“能干活的员工”的第一块跳板。建议收藏备用，动手时照着一步步做。