skill、tool、MCP之前的区别和联系
一、三者的介绍
这三者的区别可以这样理解：Tool 是模型的一只手，MCP 是连接手的标准化接口，而 Skill 则是一套包含步骤、逻辑和手一起协同工作的完整流程。
| 对比维度 | Tool (工具) | MCP (模型上下文协议) | Skill (技能) |
|---|---|---|---|
| 一句话定义 | 模型可以调用的单个功能/函数 | 连接模型与外部系统的标准化通信协议 | 封装复杂业务逻辑的可复用能力单元 |
| 核心角色 | 执行者 做具体的、确定的事，如查天气、算算术 |
连接标准 定义模型和外部的工具、数据如何"对话" |
编排者 组合多个Tool并包含判断、循环等逻辑来完成一个完整任务 |
| 技术架构 | 轻量级，通常是一个带参数和描述的函数定义 | C/S架构，包含Host（宿主）、Client（客户端）、Server（服务器） | 模块化架构，将Prompt、Tool、状态管理、错误处理等打包 |
| 复杂度 | 低 开发简单，即插即用 |
中/高 需要理解和实现协议规范，涉及进程/网络通信 |
高 需要设计状态机、逻辑分支和整体架构 |
Tool：模型能用的"手指"
Tool是最基本、最原子化的能力单元。
-
核心目的：赋予大模型一个具体的、可执行的动作，突破其仅能生成文本的限制。
-
表现形式：通常是一个带有清晰名称、描述和输入参数Schema的函数定义。
-
工作方式：模型在收到你的问题后，会查看可用的Tool列表及其描述，然后自主决定是否需要调用某个Tool，并从问题中提取参数来执行它。
-
典型示例：
-
get_weather(city) -> 天气信息 -
calculate(expression) -> 计算结果
-
MCP：连接一切的"USB-C接口"
MCP是一套由Anthropic提出的开放标准，旨在解决AI模型与外部世界连接的碎片化问题。
-
核心目的：为AI应用和外部数据源/工具之间建立统一、标准化的通信方式。你可以把它想象成AI世界的"USB-C接口"，只要符合协议，任何设备（MCP Server）都可以即插即用地接入任何主机（MCP Host）。
-
核心角色：
-
MCP Host：你正在使用的AI应用，如 Claude Desktop、Cursor 或 Cherry Studio。
-
MCP Client：内置于Host中，负责与Server通信的客户端。
-
MCP Server：轻量级的程序，通过MCP协议向外暴露特定的功能（Tools）或数据（Resources）。
-
-
使用方式：你需要在MCP Host（比如Cursor的设置里）配置好MCP Server的启动命令或地址。配置完成后，Host会自动连接Server并加载其提供的所有Tools。
Skill：完成复杂任务的"机械臂"
Skill是更高层次的抽象，它本身不是一个技术协议，而是一种设计模式和工程实践。
-
核心目的：将完成一个复杂业务场景所需要的知识、多个Tool调用逻辑、状态管理和错误处理等，封装成一个独立、可复用的模块。
-
核心价值：
-
能力封装：把"如何完成一个任务"的流程固定下来，而不仅仅是单个动作。
-
上下文管理：Skill可以管理自己的执行状态，在多轮对话中保持记忆，处理复杂的交互流程。
-
提升可靠性：通过预设的逻辑、验证和回退策略，让模型在完成复杂任务时更稳定，而不是完全依赖模型的随机"推理"。
-
-
典型示例：一个"订单处理技能"，内部可能包含检查库存、计算价格、生成工单、发送确认邮件等多个步骤，并处理"库存不足"等异常情况。
如何选择？
| 你的需求是... | 推荐方案 |
|---|---|
| 为模型增加一个简单的、确定性的功能，比如数学计算、查百科、发个通知。 | Tool |
| 希望将模型的能力开放给整个系统，或接入各种外部服务，并且希望这个接入方式是标准化的。 | MCP |
| 需要用一个AI工作流来完成一个复杂的业务，比如自动处理客户订单、撰写一份包含数据分析和图表的研究报告。 | Skill |
在实践中，这三者往往会结合使用：你可能会开发一个Skill来处理舆情分析，这个Skill内部会通过MCP协议去调用新闻检索、情感分析和邮件发送这三个Tool。
二、架构层面的深度对比
1. Tool：无状态的原子函数
用户提问 → 模型推理 → 选择Tool → 执行 → 返回结果 → 模型生成最终回答
架构特征：
-
无状态：每次调用独立，不记忆历史调用
-
同步执行：调用后等待结果返回
-
单次往返：一次提问最多一次Tool调用（虽然有function calling可以多步，但本质是顺序的）
-
模型驱动：是否调用、调用哪个Tool，完全由模型判断
局限性：
-
无法处理需要多轮协商的复杂任务
-
模型必须"猜"对Tool和参数
-
没有错误恢复机制（如果Tool失败，模型可能不知所措）
2. MCP：标准化的双向通信架构
┌─────────────┐ stdio/SSE ┌─────────────┐
│ MCP Host │ ◄────────────────► │ MCP Server │
│ (Claude等) │ MCP Protocol │ (工具提供方)│
└─────────────┘ └─────────────┘
│ │
│ 加载 │ 暴露
▼ ▼
用户界面 Tools/Resources
架构特征：
-
客户端-服务器模式：Host和Server独立运行
-
多种传输方式：stdio（本地进程）、SSE（HTTP流）、WebSocket等
-
能力发现：Host启动时自动发现Server提供的所有Tools/Resources
-
双向通信：Server可以主动向Host发送消息（如进度更新、日志）
-
会话管理：支持多轮对话上下文
-
资源抽象：除了Tools，还能提供Resources（只读数据）、Prompts（模板）
MCP独有的能力：
-
Resources：像文件系统一样暴露数据资源（如
file:///docs/report.md） -
Prompts：预定义的提示词模板，用户可以选择使用
-
采样：Server可以反过来请求Host调用模型（如Agent间协作）
3. Skill：状态机驱动的完整工作流
┌─────────────────────────────────────────┐ │ Skill 内部结构 │ ├─────────────────────────────────────────┤ │ • 提示词模板（任务理解） │ │ • 状态机（流程控制） │ │ ├─ 状态1: 收集信息 │ │ ├─ 状态2: 分析数据 │ │ ├─ 状态3: 生成报告 │ │ └─ 状态4: 人工审核（可选） │ │ • Tool 调用编排 │ │ • 错误处理与重试 │ │ • 上下文管理（多轮记忆） │ └─────────────────────────────────────────┘
架构特征：
-
有状态工作流：可以记住执行到哪一步，支持暂停/恢复
-
分支逻辑：根据中间结果决定下一步（if-else, loop）
-
人机协同：可以在关键节点暂停并等待人工输入
-
组合能力：内部可以使用Tool、MCP、甚至其他Skill
-
可观测性：每一步的执行可追踪、可调试
Skill vs Tool 本质区别：
-
Tool是做什么（what to do）
-
Skill是怎么做（how to do），包含判断、顺序、异常处理
三、数据流的深入对比
一个具体的例子：查询某公司股票并分析
使用纯Tool：
用户: "查一下苹果公司今天的股价，然后简单分析"
模型调用: get_stock_price("AAPL")
返回: 175.23
模型调用: analyze_price(175.23) // 但这里出问题了——模型可能会编造
最终: "苹果股价175.23美元，相比昨天..." // 模型可能不知道昨天是多少
问题：模型不知道历史数据，无法真正"分析"。
使用MCP：
配置了MCP Server暴露三个Resources: • stock://AAPL/price -> 实时价格 • stock://AAPL/history -> 历史K线 • stock://AAPL/news -> 相关新闻 用户: "分析苹果公司" 模型可以直接访问这些Resources，就像访问本地文件一样： 1. 读取 stock://AAPL/price 2. 读取 stock://AAPL/history（过去30天） 3. 读取 stock://AAPL/news（今天的重要新闻） 4. 基于完整信息生成分析
优势：数据获取标准化，模型不需要"调用函数"，而是"访问资源"。
使用Skill：
Skill名称: "股票深度分析师" 内部流程： Step 1 (状态: 获取数据) ├─ 调用 get_stock_price ├─ 调用 get_historical_data (过去90天) ├─ 调用 get_financial_ratios (PE, PB, ROE等) └─ 如果失败 → 重试3次 → 仍失败 → 进入错误状态 Step 2 (状态: 技术分析) ├─ 计算移动平均线 (内部逻辑) ├─ 判断趋势 (内部逻辑) └─ 如果异常波动 → 标记需要人工复核 Step 3 (状态: 基本面分析) ├─ 对比行业平均值 └─ 生成估值结论 Step 4 (状态: 生成报告) ├─ 使用报告模板 ├─ 填充数据 └─ 输出结构化分析 错误处理: 每个状态都有独立的错误恢复策略
四、生态定位：什么时候用什么？
纯Tool适用场景
-
简单的原子操作：计算、转换、单次查询
-
无状态RPC：发送通知、创建工单
-
模型能准确理解的功能：如"帮我定个10点的闹钟"
MCP的独特价值
-
标准化的数据接入：你想让AI访问数据库、文件系统、API，MCP提供统一方式
-
跨应用复用：一个MCP Server写好后，Claude、Cursor、Continue、所有支持MCP的工具都能用
-
安全边界：Host可以精细控制Server的权限（只能读某个目录，不能写）
-
动态能力发现：Server启动后自动告诉Host自己能做什么
MCP vs OpenAPI：
-
OpenAPI是给开发者看的文档规范
-
MCP是给AI程序直接执行的可发现协议
Skill的核心价值
-
复杂的业务流程：客户服务SOP、研究分析流程、内容审核工作流
-
需要人工介入：审批、修改、确认（如"生成PPT草稿→人工修改→生成最终版"）
-
高可靠性要求：金融交易、医疗诊断建议（每一步都有校验和回退）
-
企业知识沉淀：把资深员工的工作方法固化下来
五、它们的典型组合模式
模式1：Skill 调用 Tool
舆情监控Skill
├─ Tool: fetch_weibo_hotsearch()
├─ Tool: analyze_sentiment(text)
├─ Tool: generate_alert_report()
└─ (Skill内部编排调用顺序和条件)
模式2：MCP Server 包装 Tool
Database MCP Server
├─ 内部实现: execute_sql() 函数
└─ 对外暴露: resources db://query/...
MCP Server内部就是用Tool实现的，只是外面包了一层协议。
模式3：Skill 使用 MCP 获取数据
财报分析Skill
├─ 通过 MCP Client 连接财报MCP Server
├─ 读取 resources financial://AAPL/10-K
├─ 读取 resources market://AAPL/peer_comparison
└─ (Skill自己完成分析逻辑，数据来源是MCP)
完整的三层架构示例
用户层: "写一份关于新能源车行业的投资报告"
↓
Skill层: "行业研究报告Skill"
├─ 状态1: 确定研究框架
├─ 状态2: 收集数据 (调用MCP)
├─ 状态3: 数据分析 (内部逻辑)
├─ 状态4: 草稿撰写 (调用LLM)
└─ 状态5: 格式输出
↓
MCP层: 多个MCP Server
├─ 新闻MCP Server → Tool: search_news()
├─ 股票MCP Server → Resources: stock://TSLA/financials
├─ 数据库MCP Server → Tool: query_sales_data()
↓
Tool层: 底层的原子操作
├─ http_request(url)
├─ parse_json(data)
├─ write_file(path, content)
六、未来趋势展望
-
Tool会越来越"隐藏"：开发者和用户不会直接接触Tool，它们会被封装在MCP Server或Skill里。
-
MCP会成为AI应用的基础设施：就像HTTP之于Web，MCP会成为AI与外部世界交互的标准。现在已经有很多开源MCP Server（文件系统、数据库、Slack、GitHub...）。
-
Skill框架会越来越多：随着AI Agent变复杂，需要工程化方案来管理状态、错误、人机协同。LangChain、AutoGen、CrewAI都是这个方向的尝试。
-
这三者的边界会模糊：
-
复杂的Tool可能自带状态，变成轻量Skill
-
MCP 2.0可能会内建状态机支持
-
简单Skill可以直接定义为Tool
-
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
0
0- 0
已为社区贡献2条内容
所有评论(0)