上一篇文章结尾，我写了一句话：

马已经跑起来了，鞍袋还在缝。

文章发出去以后，好几个同事来找我聊 AI：

"你天天说 SKILL、插件、MCP，这几个东西到底有什么区别？听起来都挺玄的。"

我刚想张口解释，忽然发现，这个问题还真没那么容易回答。

这些词，我现在几乎天天接触，平时跟技术人员交流也觉得没什么。可真要给身边不做软件的同事讲明白，就不能只是把网上的定义搬过来。

MCP 是什么协议，插件是什么组件，SKILL 又是什么配置——这些话技术上可能没错，但听完以后，大多数人还是不知道它们究竟能干什么。

我想了两天，决定把自己的"家什房"打开。

不讲太多术语，也不画那些看着很高级、看完仍然一头雾水的架构图。就按照我现在的理解，把这些东西一样一样摆到桌上：

它是干什么的，企业什么时候需要它，又有哪些事情不能指望它。

01 MCP：给 AI 准备一套能对接的插口

MCP这个词的全称是 Model Context Protocol，翻译过来叫"模型上下文协议"。名字有点长，第一次听确实容易把人吓住。但它要解决的问题，并不陌生。

我刚入行的时候，车间里的气管、电缆和设备接口，经常各有各的规格。A 厂家的管子接不上 B 厂家的设备，换一台机器，接头也要跟着换。维修师傅的工具箱里，常年放着一堆大大小小的转接头。后来，越来越多的接口有了统一标准。管子插进去，锁紧，检查一下，气路就通了。至于设备是哪家生产的，反而没那么重要。

MCP 做的事情和这个有点像。企业里的 ERP、PLM、CRM、售后系统以及各种知识库，都有自己的数据和功能。AI 即使再聪明，如果不知道这些系统里有什么，也没有经过授权的调用方式，就只能在外面说话，进不了真正的业务现场。

MCP 提供了一种相对统一的连接方式。按这个方式把工具和数据能力提供出来，AI 应用就更容易知道：这里能查什么，那里能执行什么；调用时要传哪些信息，最后会返回什么结果。

所以，我更愿意把 MCP 理解成一套为 AI 准备的标准插口。当然，插口统一，不代表插上以后什么都能干。企业仍然要做系统对接、身份认证、权限控制和数据治理。有些老系统接口都没有，还得先改造。MCP 解决的是"如何让 AI 更标准地发现和调用能力"，不是替企业把所有系统自动打通。

我们现在先从知识库检索做起。以后如果要让 AI 查询设备维修记录、读取项目状态，甚至按权限发起某些业务动作，就需要继续把这些能力安全地接出来。

这时候，MCP 才真正开始有用。

02 企业底座：先把入口和规矩统一起来

讲完接口，还得说一个更基础的东西：企业 AI 底座。我简单了解了一下各部门使用 AI 的情况。

销售在用一个工具，技术部门在试另一个，财务有自己的账号，还有人把资料放在个人账号里处理。大家都在用 AI，可真要问一句"公司到底在用哪些模型、哪些数据传到了哪里、出了问题谁负责"，一时还真说不清楚。

这种情况，我以前在车间里见过。早些年，各个区域自己搭料棚。材料放在哪里、谁领走了、剩多少，每个棚都有一套办法。平时看着都能运转，到了盘点的时候，就得一个棚一个棚地查。

AI 如果长期这样用，也会遇到类似的问题。账号各管各的，知识各存各的，部门之间不能共享；同一份资料被重复上传，哪些内容能传、哪些不能传，也没有统一边界。

所以，企业要逐步形成一个共同的使用入口。这里说的"底座"，不一定非要一开始就建成一个庞大的技术平台。对很多企业来说，先把几件基础工作统一起来，就已经很有价值：

员工从哪里进入，使用什么账号；可以使用哪些模型和工具；

公司知识从哪里来，更新后由谁负责；哪些行为需要记录，出了问题能不能追溯；不同部门、不同岗位能看到什么。我喜欢把它比作马厩。

不是因为这个词高级，恰恰是因为它很朴素：马不能一直散养。马多了以后，总得知道哪匹马属于谁，吃的是什么，驮过什么东西，又跑过哪些地方。底座也不是一次建完的。

先把入口统一，再把知识库接进来；先解决一两个真实场景，再逐步增加系统和能力。对制造企业来说，这通常比一上来就规划一个无所不能的大平台更稳妥。

03 安全：不是堵住门，而是把钥匙配清楚

底座有了，还有一件事必须同时做。安全。

做 AI 应用的人，想得最多的是怎样让它更好用、跑得更快；做安全的人，首先想到的则是数据会不会出去、权限会不会失控、出了问题能不能找到原因。

两边看问题的角度不同，但缺一边都不行。企业数据不是放在一个筐里的。

公开产品资料、内部制度、客户报价、员工薪资、设备图纸、工艺参数、经营数据，它们的敏感程度完全不同。

哪些资料可以进入企业知识库，哪些只能在内部环境使用，哪些需要脱敏，哪些岗位可以查看原文，哪些答案不能直接对外输出，都需要提前定规则。

我愿意把安全部门看成拿着一串钥匙的管家。谁能进哪扇门，先说清楚；哪把钥匙发给了谁，登记清楚；什么时候开过门、从里面拿走了什么，最好也能查得到。

钥匙配得清楚，大家反而更敢用。最麻烦的不是规矩多，而是边界不清楚。员工不知道什么能传、什么不能传，又担心出了问题由自己承担，最后最稳妥的做法就是什么都不用。

所以安全不应该等系统上线以后再来检查。准备接入数据时，安全、业务和技术就应该坐在一张桌子上，把数据分级、访问权限、使用日志和责任边界一起定下来。

院墙不是出了事以后再补的，钥匙也不能等人进了屋才想起来配。

04 插件：拿来就能用的现成能力

接下来讲插件。插件比较容易理解。它通常是别人已经做好的功能或服务，装上、授权或者连接以后，就可以直接使用。

查网页、管日程、发邮件、读云盘文件、生成图表、连接协作平台，都可能通过插件来完成。它最大的价值就是快。

别人已经开发、测试并维护过一套能力，企业不需要每件事都从头建设。先选一个相对成熟的工具，在明确范围内试用，很快就能知道它能不能解决问题。

但插件也有两个地方需要注意。

第一，它不一定完全适合你的业务。

通用的日程、搜索、邮件功能比较容易直接使用；涉及项目管理、设备服务、工艺判断时，通用插件往往只能完成一部分工作。

第二，插件接触了什么数据、拿到了哪些权限，必须看清楚。

不能因为装起来方便，就一路点"同意"。企业正式使用之前，至少要弄清楚它能读什么、能写什么、数据存在哪里，以及停用以后如何收回权限。

所以，我对插件的态度一直很实际：

有成熟的先试，适合的就用；不适合的及时停。真正涉及企业核心流程的部分，再考虑自己开发或者深度改造。

能买到合适的扳手，就没必要从炼钢开始。

05 SKILL：把企业自己的做事方法教给 AI

最后说 SKILL。

这是我最近最愿意花时间琢磨的东西。在我的理解里，SKILL 不是给 AI 增加一个新接口，也不只是安装一个外部功能。它更像是把一项工作的步骤、规则、资料和验收要求整理清楚，形成一套可以反复使用的做事方法。

比如，做一份项目风险检查，不是简单地对 AI 说一句"帮我分析一下"。真正有用的 SKILL，要告诉它：

先读取哪些资料；按照什么维度检查；遇到哪些情况必须提醒；哪些结论需要回到原文核实；最后按什么格式输出；什么情况下不能自行判断，必须交给人确认。

市面上当然也有别人做好的通用 SKILL，可以拿来参考，甚至直接使用。但是，真正涉及企业核心业务的那一部分，很难照搬。

同样是设备验收，不同企业的标准不一样；同样是项目评审，每家公司对风险、成本和交期的判断方式也不同。这些差别，不在模型里，而在企业多年积累下来的经验里。

老师傅听到一个异常声音，会先去检查什么；项目经理看到进度表里的哪几个变化，会觉得事情不对；销售听到客户说哪句话，就知道项目还没有真正立项——这些才是企业自己的章法。

SKILL 的价值，就是把这些原来藏在人脑子里的做法，尽量整理成团队和 AI 都能执行、检查和改进的东西。接口可以采用标准，通用工具可以买，但企业自己的判断标准，最终还是要由自己梳理。

06 这几样东西，到底是什么关系

说到这里，可以把它们重新放到一起看。企业 AI 底座，解决的是统一入口、统一账号和统一管理的问题，让 AI 有一个可以长期运行的环境。

安全体系解决的是边界问题：谁可以使用什么能力，哪些数据可以被调用，整个过程能不能追溯。

MCP 解决的是连接问题，让 AI 应用能够以相对统一的方式发现和调用外部工具与数据。

插件提供的是现成能力，让企业不用什么都从头开发。

SKILL 解决的是做事方法，让 AI 知道这项工作应该按什么步骤完成，做到什么程度才算合格。

它们不是五个互相竞争的产品，也不是买了其中一个，其他几个就可以不要。

更实际的关系是：

底座提供运行环境，安全划清边界，MCP 打通工具和数据，插件补充通用能力，SKILL 则把企业自己的业务经验组织起来。

有时候，一个插件内部也可能通过 MCP 连接系统；一个 SKILL 执行任务时，也可能调用多个插件和工具。

企业没必要纠结每个名词的边界到底画在哪里。

真正应该问的是：这个场景解决了什么问题？它需要读取哪些数据？要调用哪些系统？按什么规则完成？谁来检查结果？出了问题能不能追溯？

这几个问题答清楚，比记住一堆技术名词更重要。

07 企业落地，先别铺得太大

如果现在让我重新走一遍，我不会一开始就连接十个系统，也不会组织所有部门同时开发几十个 SKILL。

我会先选一个高频、刚需、风险相对可控的场景。

比如查售后记录，或者查历史项目资料。

先把这个场景需要的数据整理好，把权限分清楚，再接通一个系统，做出一项真正有人使用的能力。

一线员工用它找回了一份过去半天都找不到的资料，或者少走了一次已经有人踩过的弯路，价值就出现了。

有了第一个真实结果，后面的工作才容易推动。

第二件事，是核心章法不能完全交给外面的人。

技术公司可以帮我们搭平台、做接口、写程序，也可以协助整理 SKILL。但哪些判断是对的，哪些风险不能接受，什么结果才算合格，必须由真正懂业务的人确认。

因为这些东西，最后会变成企业新的知识资产。

第三件事，是让安全部门尽早参与。

不是把方案做完以后，请他们来签个字，而是在确定数据来源和连接方式的时候，就让他们一起讨论。早一天把边界说清楚，后面就少一层顾虑。

企业做 AI，不怕慢一点。

最怕的是场面铺得很大，账号开了一堆，工具买了一堆，半年以后再问大家到底解决了什么问题，会议室里没人回答。

写在最后

写到这里，我那间家什房算是简单收拾了一遍。

MCP 是连接工具和数据的一种标准方式，插件是可以直接使用的现成能力，SKILL 是我们教给 AI 的做事方法。

在它们下面，还需要一个能统一管理的企业底座；在它们旁边，安全和权限必须始终跟着。

这些名词听起来很新，背后的道理其实不新。

先把地方收拾好，把规矩定下来；能用现成工具解决的，就先拿来用；真正属于自己的手艺，再慢慢整理、反复打磨。

我们现在已经把知识库检索跑了起来。

下一步，我想试着接入售后系统。

以后查一台设备过去换过什么零件、出过哪些故障、哪位工程师处理过，不必再到处打电话、翻文件夹。输入设备编号，经过权限确认，相关记录就能被找出来，并且标明来源。

听上去不是什么惊天动地的大事。但一家制造企业的效率，很多时候就是从这种小事里一点点长出来的。

慢一点没关系。接头一个一个通，规矩一条一条定，家什一件一件磨。只要解决的是真问题，这条路就没有白走。

我是 laserdog。现在还在学习怎样把老手艺交给新工具的老技术狗。

马还在跑，鞍袋还在缝。

家什房，也开始有点样子了。

这条路，我们一起走。