ARTICLE · 1049023

技能、工具、插件、MCP 到底是不是一回事

发布时间：2026-09-21 09:24:08 最近访问：2026-09-21 09:24:08

大模型只会"想"不会"做"，Skill 是它外挂的那只手；概念上各家都通用，但落地格式互不兼容，MCP 统一了插座、没统一电池。企业选型前先把这层抽象看明白。

一、先说结论：概念是一家，落地不是一家

很多人聊智能体（Agent）时，会混着说"技能（Skill）""工具（Tool）""插件（Plugin）""MCP"，好像它们是同一个东西的不同叫法。严格说：这四者在"抽象含义"上指向同一件事——给 AI 加一个能动手干活的能力模块；但在"具体实现"上，它们是不同平台、不同协议下的不同格式，彼此不能互换。

一句话记住：都是"App"这个概念，但 iOS 的 App 装不到 Android 上。

二、大模型只会"想"，不会"做"——为什么需要这层抽象

要理解 Skill，得先理解大模型的"短板"。一个大语言模型（LLM）本质是"下一个字预测机"：你给它一段文字，它吐出下一段文字。它只会思考和说话，但做不到这些：

·
查今天实时的天气、股价、汇率
·
读取你电脑里的一个 PDF、Excel
·
调用你们公司的 ERP 下单、查库存
·
生成一张 PPT、画一张图、发一条微信

这些"做事"的能力，模型本身没有，必须外挂。于是就有了"能力模块"这一层抽象——你告诉模型："当你需要查天气时，去调那个叫 get_weather 的程序；需要读 PDF 时，去调 read_pdf。"这个被挂载的程序，就是 Skill / Tool / Plugin。

关键认知：没有这层能力模块，智能体只是个高级聊天机器人。 它说得头头是道，但你让它"帮我订明天的会议室"，它只能给你一段建议文字，而不是真的去订。

三、Skill 到底是什么：一个能"动手"的能力单元

剥开各家花哨的命名，一个 Skill（能力单元）通常由三部分组成：

组成部分	作用	举例
触发条件	什么情况下该用它	用户问"天气""下单""查库存"时
执行逻辑	它具体怎么干活	调一个 API、跑一段代码、读一个文件
返回结果	干完活给模型什么	一段 JSON、一张图、一条成功提示

它的"颗粒度"可以很细，也可以很粗：

·
细到一个动作：查北京天气、把这段文本翻译成英文
·
粗到一个业务流：智能投料（你要的是"根据订单和配方算投料比"，背后可能串起查数据库、跑算法、回写结果三步）

你之前做的 153 篇里写到的 Dify、FastGPT、天智数据，本质上都是"把企业的专属能力封装成一个个可拖拽的工具节点"——这就是 Skill 思想在企业场景的落地。

四、Agent = 大脑 + 手，Skill 就是那只手

把角色拆开看就清楚了：

·大模型 LLM = 大脑
：负责理解你的话、做规划、决定"接下来该调哪个工具"
·智能体 Agent = 人
：会多步规划、会自己选工具、干错了会重试
·Skill / Tool = 手和工具箱
：真正去"执行"的部件

一个 Agent 可以挂很多个 Skill，按任务自己挑着用。比如一个"企业客服智能体"可能同时挂着：查订单状态、查产品手册、发起退款、生成工单 四个技能。用户一句话进来，大脑判断该调哪几个、按什么顺序调，手就去执行。

这也是为什么"能不能用好智能体"的关键，往往不在模型多聪明，而在你给它接了多少好用的手、这些手是不是接得稳。

五、各种平台的叫法对照：概念通用，实现不通

几乎每个主流框架都有"工具/插件/技能"这一层抽象，只是叫法不同：

平台 / 框架	这层能力的叫法
OpenAI	tools / function calling / GPTs actions
Anthropic 及开源生态	MCP（Model Context Protocol）
微软	Semantic Kernel plugins / AutoGen
Dify	工具（Tool）节点
FastGPT	插件 / 自定义工具
Coze（扣子）、腾讯元器、百度千帆	插件 / 技能
本工作环境（WorkBuddy）	skill（SKILL.md 格式）

但写法、注册方式、调用协议全都不一样。 你为 Dify 写的一个"查库存"工具节点，不能直接拖到 Coze 里用；为 OpenAI function calling 定义的 JSON Schema，格式和 MCP 的也不完全一致。这就是"概念通、实现不通"。

六、有没有"通用"的解法？——MCP 统一了插座，没统一电池

正因为各家各自为政，2024 年底 Anthropic 提出了 MCP（Model Context Protocol，模型上下文协议），目标很直白：一次编写，处处调用。

它定义了一套统一的"客户端 ↔ Server"通信协议。你写一个"查企业数据库"的 MCP Server，理论上 Claude、VS Code、Cursor、以及任何支持 MCP 的 Agent 都能直接接上用，不用为每个平台重写一遍。

但必须说清它的边界：

·它统一的是"接口（插座）"，不是"能力（电池）"。
能力本身还得一个个写；而且前提是客户端得支持 MCP。
·现状
：MCP 已成事实标准，主流 Agent 框架基本兼容，但各家仍保留自己的私有插件体系——双轨并存。你用 Dify 时，既可以用 Dify 原生工具，也可以挂一个 MCP Server。
·
它解决的是"别重复造轮子接同一套系统"，而不是"让所有能力凭空通用"。

七、给企业选型的三条实操建议

结合你正在做的"铝工智脑"这类企业级智能体项目，给三个落地的判断点：

·看生态是否开放
：平台能不能让你自己写自定义工具？能不能接 MCP？生态封闭的"黑盒平台"后期很难把你的 ERP、MES、知识库接进去。
·看是否被锁定
：优先选支持标准协议（MCP / OpenAPI）的方案，避免企业核心能力被某家私有格式绑死，将来迁移成本极高。
·看"手"的质量
：智能体好不好用，七分看它挂了哪些 Skill、接得稳不稳、返回准不准。模型可以先用通用的，但企业专属的那几只"手"必须自己打磨。

你规划里的排产、相似图形检索、知识库问答、AI 数据大师四智能体，本质就是把铝加工企业的专属技能封装成可调用节点——无论最终用 Dify 的工具节点还是自研 MCP，底层逻辑完全一致：先想清楚"这只手要干啥、怎么干、返回啥"，再谈接哪个平台。

八、一句话收尾

智能体是手机，Skill 是 App，MCP 是统一充电口——充电口标准统一了，但每个 App 还是得各自开发。 选型别被名词绕晕，抓住"手能不能接、接得稳不稳"这个本质就够了。