Agent、Skill、MCP 到底什么关系?零基础小白也能看懂的三层拆解
最近我们团队在给公司内部做 AI 提效,天天和 Agent、Skill、MCP 这几个词儿打交道。上礼拜带新来的实习生,小伙子挺上进的,但就是被这些新概念绕晕了。下班后我寻思,干脆写篇文章,把这事一次说明白。哪怕你一行代码都没写过,只要会点外卖、用过手机,我保证你也能看懂这哥仨到底是什么关系。
先说结论:它们仨,其实就是一个人
在开拆之前,先给个最直接的印象。
- Agent —— 一个会动脑子的“数字打工人”
- Skill —— 这个打工人工具箱里的“各种手艺”
- MCP —— 一套能让手艺瞬间被接上的“万能转接头”
一句话串起来:Agent 通过 MCP 这个标准接口,去发现并调用一大堆 Skill,来完成你交给它的活儿。
别急着拍大腿,咱们一层一层剥开,用你身边的事儿套一遍。
第一层:Agent,你到底是个啥?
想象一下,你今天新招了一个行政助理,叫小王。
你对小王说:“帮我订个明天去上海的机票,买一束花送到老婆公司,再把昨晚的会议纪要整理出来发我邮箱。”
小王听完,自己在脑子里规划了一下:先打开携程订票,再在外卖软件上下单鲜花,最后翻开录音转文字工具整理纪要,然后该发邮件发邮件。这中间遇到航班没了,她还会自己换一班,不用再问你。
这个能理解你模糊的目标、自行做计划、拿工具干活、还能根据结果调整动作的“人”,就是 Agent。
在技术圈,Agent 通常由大模型做大脑核心,加上一套能调用工具的框架(比如 ReAct 模式)构成。但它的本质就是一个能自主执行任务的机器人。像大家熟悉的 ChatGPT 里面的 GPTs,或者 Cursor 里面那个能帮你直接改代码的 AI 助手,本质上都是 Agent。
搞清楚了 Agent 是个打工人,那它具体靠什么干活儿?这就引出了第二层。
第二层:Skill,别把“技能”想复杂了
小王之所以能帮你订票、买花、发邮件,是因为她拥有这些技能。这每一个“会做的事”,就是一个 Skill。
在编程的世界里,“查天气”、“发飞书消息”、“创建 Jira 工单”、“读 PDF 文件”、“写数据库”…… 这些可以重复被调用的原子能力,我们把它封装好,就都叫 Skill。
去年年初,我在一个项目里需要做一个数据分析 Agent,它要能连 MySQL 查表,要能调内部 API 生成图表,还要能把结果推到企业微信。当时我的做法很原始:写一段代码,把这三个功能做成三个函数,然后把函数的定义、参数说明硬塞给大模型,让它在合适的时机调用。
那段日子维护起来简直像灾难。比如企业微信的接口升级了,我就得改函数、重新拼装提示词。每一个 Skill 都死死地绑在我的 Agent 代码里,换个 Agent 要用同样的技能?对不起,再复制一遍代码。
于是我就在想:能不能把每一个 Skill 做成一个独立的标准件,任何 Agent 都能随时插拔?这时候,MCP 登场了。
第三层:MCP,这根“吸管”凭什么火遍全场
MCP,全称 Model Context Protocol,是 Anthropic 公司推出的一套开放协议。你先不用管这串英文,你只需要把它理解成 USB-C 接口。
回想一下,早期的手机,充电口有圆头的、有扁口的、有 Micro-USB,乱七八糟。你出门得带一捆线。后来 USB-C 一统天下,甭管你是什么设备,只要接口是 C 口,怼上去就能充电、传数据。
MCP 干的就是这件事。它规定了一套标准的通信格式(基于 JSON-RPC),让所有 Skill 都按照这个标准把自己“包装”好,变成一个 MCP 服务器。然后,任何支持 MCP 协议的 Agent,都能立刻认出它、连上它、使唤它。
这样一来,Skill 和 Agent 被解耦了:
- 提供 Skill 的人,只需要把自己提供的工具、数据资源包装成一个 MCP 服务放出去。比如数据库团队维护一个 “DB 查询 MCP 服务”,里面集成了各种查询 Skill。
- Agent 这边,只要在配置文件里加几行代码,把这个 MCP 服务的“地址”填进去,下一秒,Agent 就自动获得了里面所有的 Skill,知道怎么调用,需要什么参数。
还记得我那个数据分析 Agent 吗?如果用今天的 MCP 来做:
- 数据库小哥扔给我一个 MySQL MCP 服务的地址;
- 图表小组维护了一个 Chart MCP 服务;
- 企业微信那块,早就有现成的 MCP 社区服务。
我要做的,只是在 Agent 的配置里像这样挂上三个 MCP 服务(伪代码示例):
{
"mcpServers": {
"mysql": {
"command": "node",
"args": ["./mysql-mcp-server.js"]
},
"chart": {
"url": "http://localhost:3001/mcp"
},
"wework": {
"command": "python",
"args": ["./wework-server.py"]
}
}
}
Agent 启动时,会自动去发现:“哦,我现在有了‘查订单’、‘画折线图’、‘发企微消息’这三个 Skill。” 你只需要用自然语言下命令:“把昨天的营收前十名查出来,画个柱状图发到群里。” Agent 自己就会管 MCP 要这些 Skill 干活儿。
注意,这里有个常见的误区。 很多人以为 MCP 本身就是 Skill,或者 Skill 必须依赖 MCP 存在。不是的。Skill 是那个实实在在做事的能力,MCP 只是让这个能力能被 Agent 以标准化的方式发现和调用的“招工平台”。没有 MCP 之前,Skill 也可以直接用函数调用,但有了 MCP,Skill 才真正变成了可以跨应用、跨模型、跨团队共享的即插即用模块。
拧在一起看关系,一图胜千言
现在,咱们把这三层合在一起,用“打工人小王”再总结一下:
| 你的角色 | 你请了个 Agent (小王) | 小王会一堆 Skill (订票/买花/发邮件) | 小王通过 MCP 去连外部资源 |
| 你 | 告诉她目标:明天去上海,带花,发纪要 | 这些技能是她的立身之本 | 她用标准化的方式(比如统一的网页端、API接口)去访问航司系统、外卖平台、邮箱服务器 |
| 技术视角 | Agent 是那个接收指令、规划、执行的智能体 | Skill 是完成单一任务的原子能力函数或服务 | MCP 是 Agent 与 Skill 之间沟通的标准协议,让 Skill 可以瞬间被“安装”进 Agent |
可以画个简单的逻辑流:
你(人类) --> [下达任务] --> Agent(大脑)
|
[通过MCP标准协议调用]
|
+-------------+-------------+
| | |
Skill A (查航班) Skill B (买花) Skill C (发邮件)
为什么这套组合拳最近这么火?
说实话,我干了这么多年开发,见过太多闭门造车的协议。但 MCP 这一波确实有点不一样,因为它真的解决了行业里一个很痛的痒点:让大模型的能力能够被安全、统一、无痛地扩展。
过去,我们想让 AI 干点活,光是给它接个“查询天气”的功能,就得写一堆胶水代码,还要专门告诉模型什么时候该用、怎么填参数。换个模型,这套提示词可能还不一样。而现在,只要开源社区有人把一个工具打包成了 MCP 服务,你下载下来一挂,你的 Agent 就原地学会了一个新技能。这种“技能生态”的想象空间非常大。
对于刚入门的同学,我的建议就是:不要被PPT上的概念吓到,从动手配一个 MCP 服务开始。 打开你电脑上的 Claude Desktop 或者 Cursor,找一个最简单的 MCP Server(比如网页抓取或者文件系统),按文档配好,然后对 Agent 说一句“帮我读一下这个网页的内容,总结成三句话”。当你亲眼看到 Agent 自动去连接那个 MCP Server 并调用对应 Skill 完成任务的一瞬间,这三者的关系,你一辈子都忘不了。
还是那句话:Agent 用思考来规划,Skill 用执行来落地,而 MCP,就是打通它们俩任督二脉的那根神经。
希望能帮到正在上路的你,咱们一线见真章。
关于我们
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料,主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容,侧重测试实践、工具应用与工程经验整理。
- 点赞
- 收藏
- 关注作者
评论(0)