MCP、Skill 和 Tool 三者有什么区别？

核心回答

三者处在不同层次：Tool 是可执行能力，MCP 是宿主接入外部能力的标准协议，Skill 是处理某类任务的方法与资源包。它们可以组合使用。

例如生成经营分析报告：查询销售数据是工具；如果这项能力通过 MCP Server 暴露，宿主可以按协议发现并调用它；报表分析技能则规定先确认口径，再计算、核对和写报告。Agent 负责根据任务与中间结果组织这些步骤。

因此，新增业务动作看工具，跨宿主接入看协议，反复复用专业流程看技能。Skill 可以直接使用本地工具，不必经过 MCP。

各自负责什么

对象	提供的东西	不自动解决的问题
Tool	名称、参数契约、执行逻辑和结果	当前任务应该先做哪一步
MCP	外部工具、资源等的标准化发现与交互	业务正确性、服务端权限与整体任务规划
Skill	触发说明、步骤、领域规则、可选模板与脚本	真实执行能力、独立权限和运行时保障

MCP 不只是工具列表，也可以提供资源和提示词等能力。Function Calling 则是模型输出结构化调用意图的机制；宿主收到调用后，可以执行本地函数，也可以转交 MCP Client，不需要模型直接实现协议通信。

一次组合调用

用户要求“按本月已支付订单生成销售报告”。宿主先让 Agent 看到报表技能摘要；任务匹配后，Agent 读取 SKILL.md，得知要确认退款口径、查询数据和核对总额。

查询时模型生成工具名称和参数，宿主校验并通过 MCP Client 发起 tools/call，服务端执行受限查询，返回数据和执行状态。Agent 根据结果继续计算或补问，最后使用模板交付报告。技能文件本身不查询数据库，协议本身也不计算销售额。

在实现层面，AgentScope 的技能注册与工具注册是不同入口；技能还需要读文件等工具来读取正文。Deep Agents 的分层加载同样把技能说明与后续执行区分开。这解释了为什么“加载了技能”并不等于“已经完成业务动作”。

追问

有 MCP 后还需要写 Tool 吗？

需要具体能力的实现。可以复用现成服务，也可以自己写服务端工具；协议减少重复接入约定，但不会凭空提供业务逻辑。

Skill 能包装成 Tool 吗？

可以提供一个加载技能的工具，也可以把固定任务封装为业务工具。外层接口可以相同，但前者主要交付方法与上下文，后者执行具体处理，调试和验收要看实际职责。

三个概念都用上，系统就更好吗？

不一定。单一宿主中几个本地函数可能已经够用；只有专业流程需要复用、外部能力需要标准化共享时，新增层次的收益才可能抵过维护成本。

对应教程

参考资料