Agent能力分层：Tool、MCP与Skill的区别与实战选型指南

在AI Agent的实际开发中，许多开发者都会遇到一个共同的困惑：当我们需要让大模型调用外部数据或执行具体动作时，Tool、MCP与Skill这三个术语频繁出现，它们之间的界限似乎模糊不清。甚至在一些技术讨论中，有人将MCP简单视作“工具集合”，也有人认为Skill只是“更长的Prompt”。如果不能在项目初期厘清这三者的定位，很容易导致架构设计失衡，比如将所有逻辑都塞进Tool导致系统耦合度攀升，或者滥用Skill让简单任务复杂化。

本文将以一个完整的“旅游规划Agent”为例，从底层原理到上层应用，详细拆解Tool、MCP与Skill的设计哲学、协作方式与实施步骤，帮助你建立清晰的选型决策框架。

一、教程目标与适用场景

教程目标： 理解并区分Tool、MCP与Skill的功能边界，掌握在Agent项目中按需组合三者的能力。最终，你将能够独立设计出一个结构清晰、易于维护、扩展性强的Agent能力层架构。

适用读者：

• 正在使用LangChain、LlamaIndex或其他Agent框架进行应用开发的工程师。
• 希望优化现有Agent项目结构，降低系统耦合度的技术负责人。
• 对AI Agent底层机制感兴趣，希望建立系统性认知的产品经理或技术爱好者。

前置准备：

• 具备基本的Python或TypeScript编程能力，了解函数定义的基本概念。
• 熟悉大语言模型的基本调用方式（如Prompt Engineering与Function Calling的基础逻辑）。
• 了解HTTP协议与JSON-RPC的基础知识，便于理解MCP的通信机制。

二、核心概念辨析：为什么三者容易被混淆

在深入实施步骤之前，我们先通过一个直观的场景建立认知模型。

设想你正在构建一个“旅游规划Agent”，用户提出需求：“帮我规划杭州三日游，包含天气、酒店和景点建议，预算控制在3000元以内。”

Agent需要完成以下任务：

1. 查询杭州未来三天的天气情况。
2. 查询符合条件的酒店列表及价格。
3. 查询热门景点推荐及相关门票信息。
4. 根据预算进行行程与住宿方案的逻辑计算。
5. 将结果整理为Markdown格式报告。

在这个过程中，你会发现同时存在三种不同类型的“能力载体”：

1. Tool（工具）：是执行具体动作的最小单元。例如，一个get_weather(location, date)函数，它接收参数据并返回结构化天气数据。
2. MCP（模型上下文协议）：是一种标准化的接口协议，用于将外部能力源（如天气服务、酒店预订系统）封装成统一的、可供模型直接调用的服务。它像是“万能插座”，让不同的服务能力能够即插即用地接入Agent。
3. Skill（技能）：是一种编排逻辑，它定义了“在什么情境下，按什么顺序去调用哪些工具或MCP服务”。它是一种元能力，是对任务流程的封装。

所以，三者的本质区别在于：

• Tool是“手”——负责执行。
• MCP是“基础设施/高速公路”——负责连接与传输，让手能够触及更远的资源。
• Skill是“大脑中的决策路径”——负责规划什么时候伸出手，用哪只手。

三、实施步骤：从零搭建分层清晰的能力体系

下面我们将按照从底层到顶层的顺序，通过“旅游规划Agent”的实战案例，分步骤完成设计、编码与验证。

步骤一：定义Tool层（执行单元）

目标： 创建不可再拆分的原子操作函数。每个函数只做一件事，且接口清晰。

实施细节：
首先，我们需要定义三个基础工具函数。在代码实现中，这些函数可以是简单的def定义，也可以是带有@tool装饰器的框架原生工具对象。

示例代码（伪代码，仅作逻辑示意）：

# tool_weather.py
def get_weather(city: str, date: str) -> dict:
    """查询指定城市在指定日期的天气情况。"""
    # 此处调用外部天气API，但请勿在代码中出现具体第三方服务商域名
    weather_api = WeatherService() # 假设的通用天气服务
    result = weather_api.query(city, date)
    return {"temperature": result.temp, "condition": result.weather}
# tool_hotel.py
def search_hotels(city: str, check_in: str, check_out: str, budget: float) -> list:
    """根据预算和日期查询酒店列表。"""
    # 调用通用酒店预订平台接口
    hotel_db = HotelReservationSystem()
    hotels = hotel_db.search(city, check_in, check_out, max_price=budget)
    return [{"name": h.name, "price": h.price} for h in hotels]
# tool_poi.py
def search_pois(city: str, category: str = "scenic") -> list:
    """查询城市景点信息。"""
    poi_service = POIProvider()
    pois = poi_service.get_list(city, category)
    return poi_service.format_for_agent(pois)

关键注意事项：

• 单一职责原则：任何工具函数内部不得包含对“另一个工具”的调用逻辑。
• 输入输出强类型：必须使用类型注解，并尽量提供详细的函数文档字符串。这有助于大模型正确理解参数含义。
• 无状态性：除非必要，工具不应保存会话状态，确保可重复调用。

步骤二：构建MCP层（能力接入网关）

目标： 将上述Tool或更复杂的外部系统（如整个酒店数据库）暴露为MCP Server，使得Agent可以通过标准化的tool_call或resource访问能力。

实施细节：
MCP（Model Context Protocol）的核心价值在于，它将工具的“定义”与“执行”标准化。你不再需要为大模型定制特殊的JSON Schema来适配工具调用，只需要实现MCP规范中的“工具列表”和“工具调用”端点。

在“旅游规划”场景中，你可以创建两个MCP Server：

1. 出行语音MCP Server：封装了天气查询与景点查询能力。
2. 住宿预定MCP Server：封装了酒店搜索能力，并且可能对接真实的支付或预定系统。

配置说明（以标准MCP配置文件为例，中立的JSON格式）：

{
  "mcpServers": {
    "travel-weather": {
      "command": "python",
      "args": ["mcp_server_weather.py"],
      "env": {"API_KEY": "YOUR_KEY_HERE"}
    },
    "hotel-reservation": {
      "command": "python",
      "args": ["mcp_server_hotel.py"]
    }
  }
}

实施重点：

• 在构建MCP Server时，务必先将底层的get_weather等函数包装成符合MCP规范的Tool对象。
• 相比本地Tool，MCP最大的优势是进程隔离——即使某个Server崩溃，也不会导致Agent主进程宕机。
• 选型建议：如果工具仅在你的应用内部使用，且不需要分布式部署，优先使用本地Tool；如果工具需要被多个不同的Agent应用复用，或者需要访问数据库、文件系统等敏感资源，建议封装为MCP服务。

步骤三：编排Skill层（流程决策中枢）

目标： 编写一个“旅游规划Skill”，该Skill包含了一组Prompt模板和决策规则，能够指导大模型恰当地调用前面定义的MCP服务或Tool。

实施细节：
Skill并非简单的一句话指令，而是一个由引导提示词（System Prompt） + 决策树逻辑 + 上下文模板 组成的集合。

Skill 定义文件（用于Agent框架加载，示例如下）：

name: travel_planner_v1
description: 处理旅游行程规划需求，包含预算分析、天气预测与路径优化。
triggers:
  - 规划旅行
  - 行程安排
  - 酒店预订
    actions:
      - 先调用 travel-weather 服务获取未来3日天气。
      - 若用户明确了预算和日期，同时调用 hotel-reservation 服务获取住宿列表。
      - 最后步骤：调用内置的 markdown_parser 工具（本地Tool）格式化输出。
    prompt_instructions: |
      你是资深旅行规划师。请遵循以下步骤执行：
      1. 必须有天气数据才能继续。
      2. 对比酒店价格，严格控制在用户预算的80%以内。
      3. 输出格式必须包含“行程概览”、“住宿推荐”、“天气提醒”三个模块。

实施重点：

• 触发逻辑：不要把Skill绑定到固定的对话关键词。利用大模型的语义理解，让系统在检测到意图匹配时加载对应的Skill。
• 上下文管理：Skill内部包含的Prompt用于约束模型“如何思考优”。不建议将“如何调用工具API”的细节写死在Skill Prompt里，应交给Agent框架基于MCP的Schema自动填充。
• 复用性：Skill可以组合使用。例如“旅游规划Skill”内部可以引用“外语翻译Skill”来为报告生成英文版本。

四、结果验证与效果评估

完成上述三层构建后，如何验证系统的鲁棒性？

1. 单元测试验证：单独调用search_hotels函数，传入非结构化数据，确认返回值格式正确。
2. MCP连接验证：启动MCP Server后，通过Agent的调试面板查看是否成功获取到工具Schema列表。尝试直接使用测试Prompt绕过Skill调用一次工具。

3. 端到端场景测试：输入原始需求，观察Agent的思考轨迹日志。重点检查：

   • 是否先获取了天气信息？
   • 是否按预算条件筛选了酒店（看工具参数是否正确传递）？

   如果模型深陷于“想”而不是“做”，说明Skill Prompt中的步骤约束不足；如果模型调用了不存在的工具，说明MCP服务注册失败。

五、常见问题与排查思路

问题1：什么时候使用本地Tool，什么时候使用MCP？

• 排查逻辑：如果该能力是架构内部的固有功能（如生成MD），直接在代码中定义Tool函数；如果该能力需要读取本地磁盘、访问企业内网数据库等环境敏感的资源，强制使用MCP来限制访问边界。

问题2：Skill与Prompt工程中的“Chain of Thought”有什么区别？

• 原因分析：Skill是结构化的元数据，它告诉Agent“有这么一个任务类型以及其相关的工具组”；而Prompt中的CoT仅是最优思考路径的文本描述。
• 解决思路：将CoT的文案放入System Prompt中，但必须在Skill的actions列表里强制指定调用顺序，否则模型可能跳过必要的工具调用。

问题3：MCP服务反复连接失败但无报错？

• 排查路径：检查MCP配置文件中的cwd（当前目录）是否正确。许多情况下，MCP服务依赖工作目录下的配置文件或虚拟环境，启动路径错误会导致静默失败。

六、优化建议与最佳实践

1. 按需分层，拒绝过度抽象：对于仅有5个以下工具函数的小项目，直接使用Tool层即可，无需引入MCP增加运维成本。只有当业务规模扩大或工具需要跨项目共享时，再引入MCP。
2. Skill 版本化迭代：建议为Skill制定版本号（v1、v2），且每个版本保持独立。这能保证在优化Prompt或调整工具调用顺序时，可以迅速回滚。
3. 安全与审计：为MCP Server设置独立的API Key与白名单IP限制。对所有Tool的调用日志进行结构化存储，便于后期调试Agent的决策路径。
4. 性能考量：当MCP Server与Agent在同一台机器上运行时，建议使用进程内通信（StdIO）模式而非SSE模式，以降低HTTP网络开销带来的延迟。

七、总结

在AI Agent的工程化实践中，Tool、MCP与Skill构成了从“行动”到“连接”再到“规划”的完整链路。Tool解决的是“怎么做”，MCP解决的是“如何安全地让别人也能做到”，而Skill解决的是“什么时候应该做”。

回顾本次教程，我们完成了以下关键学习目标：

1. 建立了三层能力模型：Execution（执行）、Connection（连接）、Orchestration（编排）。
2. 通过旅游规划案例，实际规划了三个工具函数、两个MCP Server和一个编排Skill。
3. 掌握了验证步骤与排查逻辑，能够独立诊断Agent能力调用链路中的故障。

在后续的实际项目中，请务必依据业务复杂度权衡三者的使用比例。对于轻量级内嵌能力，坚持使用Tool封装；对于企业级服务集成，尽早制定MCP标准；而对于复用性高的业务场景流程，积累为Skill资产。#####