当前位置：首页 > news >正文

Agent、Mcp、Skills的区别与协同

news 2026/4/17 3:04:10

很久没写了，现在回来了。

也就是去谈完了一场恋爱，出了趟远门，走了走，看了看。

收了收心，回来看了下，Skills也从最初的顶层设计里的设计想法，发展到了今天的有规范支撑、有场景落地的阶段。可以认为，这是Mcp之后，又一轮的设计到落地的技术实践，很扎实的实践。那只龙虾的事儿，下次再聊吧。

当初Mcp出现的时候，就说过，它是一个重要的里程碑，因为它标志着大模型能正确的调用工具了，因为它就是这样一套规范，告诉我们应该怎么让它认识工具，知道从上下文里去找什么。但是，注意，那只是在工具已有的情况下，才能起到很好的作用。如果我们试图在过程中创造一个工具并使用，那么效果并不好，总会遇到许多工程化的问题。具体的例子很多，多半都是类似用Python或者更高阶的代码辅助工具们写一段代码来执行的场景。很多时候，他们能用，只是不可控、不健壮、有漏洞。

有人会说，那个什么什么的辅助编程工具就很好用，基本没有这些问题。此处，请参见AI辅助编程的第一原则：人类不要下场改代码，提出新的问题和修改提示词才是你们的工作。这就好比在很多项目团队里，产品经理和需求方可以提产品设计和业务需求，但是不要指挥开发人员怎么写代码，是一个道理。两个术语体系，两个物种，不要混搭干一件事情。

我们简单回忆下，Mcp里的一些定义，在服务器端，定义了：

Prompts-提供提示模板

Resources-提供可读资源

Tools-提供可调用工具

我们再来看下，Skills的一些定义：

****Metadata-元数据：可用 Skills 的名称、描述及其文件路径。这些信息会被预先放到上下文（系统提示词）中，以确保 Agent 知道有哪些 Skills 可以利用。

****Resources-资源：除了SKILL.md文件，每个 Skill 还可以包含其他类型的资源文件，如配置文件、文档等。当 Agent 需要更具体的信息时，它会进一步读取这些资源文件的内容，从而将其加载到上下文中。

****Instructions-指令：每个 Skill 都有一个对应的SKILL.md文件，其中包含了 Skill 的详细描述、使用方法和示例等信息。当 Agent 需要某个 Skill 的帮助时，它会通过Read工具读取SKILL.mds 文件的内容，进而将其动态加载到上下文中。

对比之下，我们就能发现他们之间的对应和递进关系，Skills关注的是工具能力的内部实现，Mcp关注的是工具能力的外部交互。

所以，Mcp也好，Skills也好，他们关注的对象是工具能力，是被智能体使用的工具能力，它的使用方不是人类，而是智能体。

前些天，有被问到：

智能体和Skills到底是关系，感觉能做的事情差不多，有点分不清，我也可以把一个智能体封装成一个Skills来对外发布使用，也可以把一个Skills当成一个智能体来发布。

答案，我刚才已经基本都说了。而且，类似的话题早在Mcp出现的时候也出现过，“智能体和Mcp到底是什么关系”。那会儿听完也是笑了笑，不知道为何还有人讨论的那么激动，或许是有“蓝军”非要反着说吧。

如果你问的是他们“能做什么”以及他们的内部实现，差异不大。如果你问的是他们“是什么”，又或者他们“给谁用”，那么就截然不同了。

智能体的用户是人类，而Mcp和Skills的用户是智能体。智能体的内部实现，依赖Mcp和Skills这些约定来规范化工具能力的有序使用；工具能力的内部实现，依赖Mcp和Skills这些约定来规范化工具能力的内部结构，让大模型能更好的理解，也增加其白盒化程度。

再者，任何的规范和约定，为了其扩展性的考量，也总是会适度的外延一些。我想，这也是为什么会出现“智能体和Skills的关系有点分不清”的错觉的另一个缘由。

技术团队的人，基本都明白的一个道理或是常识：一个系统的全部代码实现，既可以写在一个main方法里，存在一个代码文件里；也可以分层分模块成很多个代码文件和多个方法，实现引用和调用。对一个好的程序员来说，这两种写法的程序效率和健壮性等，所差无几，甚至很多时候前者更优。差别，只是换了个人来阅读和维护时，通常会产生大量的成本，所以我们约定了一系列的代码规范。如果不再需要“换人”的考量时，有许多规范自然也就没有了存在的必要性。

所以，AI的世界，或者说智能体的世界里，也正在迅速的做类似的事情：形成智能体之间的共识，跨智能体可读、可维护的约定。

未来，人类和智能体之间的协同关系，也将会顺利的映射成产品经理和开发人员之间的协同关系，而Skills体系大体就成了智能体的开发框架体系。至于Skills的一些原理相关的，这里不是很想写，很懒散，也没觉得特别重要。大体就是人在构建软件/系统的体系过程中，会注意和遇到的问题，都会在智能体时代再走一遍，只是走得更快，以及出来的东西的一些偏好上的差异。毕竟谁都不能保证，人和AI的阅读习惯一定是一致的，人与人的阅读和理解习惯都存在差异。

到那时，智能体们会说：人类，别再来干预Skills了，这本就不是为你们而创造的。

或许，也会蛮有意思的。也许，那才是大家向往的人生状态，更生活化，去追求精神层面的升华、滋养灵魂，和另一群有趣的灵魂一起去好好看世界。

说真的，这两年看着身边一个个搞Java、C++、前端、数据、架构的开始卷大模型，挺唏嘘的。大家最开始都是写接口、搞Spring Boot、连数据库、配Redis，稳稳当当过日子。

结果GPT、DeepSeek火了之后，整条线上的人都开始有点慌了，大家都在想：“我是不是要学大模型，不然这饭碗还能保多久？”

我先给出最直接的答案：一定要把现有的技术和大模型结合起来，而不是抛弃你们现有技术！掌握AI能力的Java工程师比纯Java岗要吃香的多。

即使现在裁员、降薪、团队解散的比比皆是……但后续的趋势一定是AI应用落地！大模型方向才是实现职业升级、提升薪资待遇的绝佳机遇！

这绝非空谈。数据说话

2025年的最后一个月，脉脉高聘发布了《2025年度人才迁徙报告》，披露了2025年前10个月的招聘市场现状。

AI领域的人才需求呈现出极为迫切的“井喷”态势

2025年前10个月，新发AI岗位量同比增长543%，9月单月同比增幅超11倍。同时，在薪资方面，AI领域也显著领先。其中，月薪排名前20的高薪岗位平均月薪均超过6万元，而这些席位大部分被AI研发岗占据。

与此相对应，市场为AI人才支付了显著的溢价：算法工程师中，专攻AIGC方向的岗位平均薪资较普通算法工程师高出近18%；产品经理岗位中，AI方向的产品经理薪资也领先约20%。

当你意识到“技术+AI”是个人突围的最佳路径时，整个就业市场的数据也印证了同一个事实：AI大模型正成为高薪机会的最大源头。