AI 黑话拆解 01:Prompt、Tool Calling、MCP、Agent、Skill、Plugin 到底什么关系?

他说："你帮我看看，Agent、MCP、Skill、Plugin、Tool Calling、Prompt——这 6 个词到底什么关系？我面试候选人问到这里他们瞎讲，我自己讲也磕巴。"

我盯着屏幕愣了三秒。

不是因为问题难。是因为我意识到，过去一年我自己跟人聊 AI，也经常在这几个词之间反复横跳，假装自己讲清楚了。

讲真，这事儿我憋了很久。今天把它彻底掰开。

下面这 6 个词不是 6 个并列的概念。是 6 层楼——AI 从"会说话"一步步爬到"能干活"的进化阶梯。我用一个餐厅的比喻把它们串起来，你看完不会再混。

第 1 层：Prompt——你跟 AI 说话的方式

最简单的一个。也最容易被低估。

Prompt 就是你输入给大模型的那段文字。就这么简单。

但"写好一段 Prompt"是另一回事。你跟服务员说"来点吃的"和"来一份微辣的宫保鸡丁、鸡丁切大块、米饭加量"，端上桌的东西天差地别。AI 也一样。

写 Prompt 的功夫有个专门名字叫 Prompt Engineering，过去两年被吹得神乎其神。我一开始也信这套话——"用三句神奇咒语让 GPT 给你写出 10 万 + 文章"那种。

最惨的一次我花了两周折腾各种"咒语模板"，最后发现真正起作用的不是咒语，是把任务边界讲清楚。你是谁、做什么、不要做什么、输出长什么样——这四件事说明白，Prompt 自然就好了。其他都是花活。

顺带说一句，System Prompt 和 User Prompt 也别混。前者是给 AI 立人设和定规矩的（开发者写一次），后者是用户每次提的具体问题。

下面是我常用的技术评审模版

你是一名资深 Java 后端架构师，请帮我做一次严格但务实的技术评审。评审对象：【这里粘贴技术方案、接口设计、核心代码、PR diff、数据库设计或改动说明】业务背景：【说明这个需求解决什么问题，核心业务流程是什么，哪些用户/系统会受影响】技术栈：Java 8/11/17，Spring Boot，MyBatis/MyBatis-Plus，MySQL/Oracle/Redis/RocketMQ【按实际项目修改】请从以下维度评审：1. 正确性检查业务逻辑是否完整，边界条件是否遗漏，异常场景是否处理清楚。2. 架构与职责检查分层是否合理，Controller、Service、Mapper、DTO/VO/Entity 的职责是否混乱，是否引入了不必要的复杂度。3. 数据库与事务检查 SQL、索引、分页、批量操作、事务边界、幂等性、并发写入、数据一致性风险。4. 性能检查是否存在 N+1 查询、大对象加载、循环查库、锁粒度过大、远程调用串行阻塞、缓存误用等问题。5. 安全性检查权限校验、数据越权、SQL 注入、敏感字段泄露、日志泄密、接口参数信任过度等问题。6. 可维护性检查命名、重复代码、魔法值、配置化、可读性、扩展点、是否符合当前项目已有风格。7. 可观测性检查关键日志、错误码、链路排查信息、告警指标是否足够。8. 测试建议指出必须补的单元测试、集成测试、回归场景和线上验证点。输出格式：先给结论：- 是否建议通过评审：通过 / 有条件通过 / 不建议通过- 最大风险是什么- 必须修改的问题有哪些然后按优先级列出问题：- P0：会导致线上故障、数据错乱、安全问题- P1：明显影响稳定性、性能、维护成本- P2：可以优化但不阻塞上线每个问题请包含：- 问题描述- 影响范围- 修改建议- 如果可以，请给出代码示例最后给一份上线前检查清单。请不要泛泛而谈，只基于我提供的代码和上下文提出问题。如果信息不足，请明确标注“需要补充的信息”，不要自行假设。

到这一步 AI 还只是个"会聊天的大脑"。知道很多，但什么也干不了。

第 2 层：Tool Calling——让 AI 有手有脚

问题来了。

你问 AI "北京现在多少度"，它训练数据是去年的，根本不知道今天热不热。它只能编。

怎么办？给它装一双手。

这就是 Tool Calling(OpenAI 叫 Function Calling，Anthropic 叫 Tool Use，本质一回事)。简单说就是——你提前告诉 AI："这里有一个 getWeather 工具，给它传个城市名，它就能查天气。"

AI 收到你的问题后，不直接回答，而是输出一段结构化的 JSON：

{"tool_calls": [{"function": {"name": "getWeather","arguments": {"location": "beijing"}    }  }]}

回到餐厅比喻——你跟服务员说"我想要一份宫保鸡丁"，服务员不是亲自下厨，而是把你的话翻译成厨房能看懂的标准订单（票子上写菜名、数量、忌口），交给后厨。后厨做好再端出来。

Tool Calling 干的就是"翻译成标准订单"这件事。

但这里有个坑——OpenAI 的订单格式和 Anthropic 的不一样，Google 又是另一套。你写一个工具想同时给三家模型用，得写三份适配代码。

业内有个名字叫"N×M 问题"。N 个工具乘以 M 个模型，等于你要写 N×M 份连接器。

这就是为什么需要下一层。

第 3 层：MCP——AI 世界的 USB-C 接口

MCP 全称 Model Context Protocol，模型上下文协议。Anthropic 2024 年 11 月推出。

官方给的类比是"AI 的 USB-C 接口"。我觉得这是过去两年所有 AI 技术比喻里最准的一个。

USB-C 出现之前每个设备都有自己的线——iPhone 是 Lightning、安卓是 Micro USB、老硬盘是 USB-A、再老一点的是 PS/2。家里抽屉塞满各种线，搬一次家少一根，新设备买回来就抓瞎。

MCP 出现之前 AI 工具就是这个抽屉。每个工具一种接法、每个模型一套适配。

MCP 把它统一了。工具开发者只写一次 MCP Server，任何支持 MCP 的客户端（Claude、Cursor、Windsurf、ChatGPT 都加入了）都能直接接进来。

到底有多火？

我去查了一下数据——18 个月时间，GitHub 上的开源 MCP Server 已经超过 1000 个，从 Google Drive 到 Kubernetes 全覆盖。2026 年 4 月 AAIF 在纽约办了一场 MCP Dev Summit，去了 1200 个开发者。Anthropic 自己也在 2025 年 12 月把这套协议捐给了 Linux 基金会下的 Agentic AI Foundation——这意味着 MCP 从一家公司的私有协议正式变成了行业标准。

这里很多人会问一个问题：MCP 是不是要替代 Tool Calling？

不是。

两个概念根本不在一个层。Tool Calling 是 LLM 内部的能力（模型决定调啥），MCP 是工具被发现和接入的方式（工具怎么暴露给所有模型）。当一个 Claude 客户端通过 MCP 调用某个工具时，它内部依然走 Tool Use 的格式。MCP 只是标准化了"这个工具最初是怎么被发现和描述的"那一段。

换个说法——Tool Calling 是大脑发出"我要一杯水"的指令，MCP 是厨房和大脑之间那根标准化的传话筒。两个是协作关系，不是替代关系。

第 4 层：Agent——能拆任务的"私人管家"

到这里 AI 已经能调工具了。但还不够聪明。

Tool Calling 是"单次点菜"——你说一句它干一件事。

Agent 是什么呢？

Agent 是"全权委托管家帮你策划一场旅行"。你跟它说"我想去三亚度假，预算 8000"，它会自己拆步骤——先查天气、再比机票、再选酒店、再做攻略，过程中发现机票临时涨价了它还会调整方案。

技术上 Agent 的核心是一个循环，业内叫 ReAct 模式：

思考 → 行动 → 观察 → 反思 → 再思考...

直到它判断"任务完成了"才停下来。

我承认这套东西听起来很玄。但真把一个 Agent 跑起来你就懂了——你输入一句话，它在后台几分钟内调了七八个工具，把事情干完。第一次见的时候我盯着终端看了五分钟，感觉有点不真实。

不过话又说回来，Agent 也不是万能的。我接触过的一个项目，让 Agent 自动做客户分析，跑了一上午烧了 80 多刀 API 费用，最后输出的报告还没我用 Excel 手撸一下午来得准。它擅长的是流程明确、容错率高的事——不是所有任务都适合套个 Agent。

第 5 层：Skill——教 AI 做某件事的"小手册"

Agent 有了，问题又来了——你怎么教它"做我们公司的事"？

公司里招个新员工，你不会指望他第一天就什么都会。你会给他一本《新人入职手册》，里面写着"报销流程是这样、给客户的邮件这样写、季度复盘要走这几步"。

Skill 就是给 AI 准备的这种手册。

Anthropic 官方的描述是："Skill 是给 Claude 的自定义入职材料，打包了指令、元数据和可选资源（脚本、模板），让 Claude 在相关任务出现时自动调用，变成那个领域的专家。"

听起来跟 Prompt 有点像？关键区别有两个。

一是按需加载。 Skill 用的是"渐进式披露"——会话开始时每个 Skill 只占大约 100 token 的元数据（就是"我是干啥用的"这句描述），AI 看到任务相关时才把完整内容拉进来。这意味着你可以挂几十上百个 Skill，AI 上下文窗口不会爆。

二是模块化。 Prompt 是一段文字，Skill 是一个文件夹，里面可以塞 Markdown 指令、Python 脚本、模板文件。AI 用的时候自己决定看哪部分。

Anthropic 目前自带 4 个内置 Skill（生成 pptx/xlsx/docx/pdf 的能力，Claude.ai 的文档生成功能就是这 4 个在背后撑着），开源 Skill 仓库里还有 17 个顶级目录，从前端设计到 MCP 开发都有。

我自己上个月写了一个代码评审 Skill，每次丢一段 Java 改动进去，它不会只说“代码可以优化”，而是会按业务正确性、事务边界、SQL 性能、权限校验、日志排查、测试覆盖这几块逐项检查。最有用的一次，它帮我指出一个批量更新接口没有做幂等控制，测试环境看不出来，但线上重试一次就可能重复扣库存。那一刻我才真正理解 Skill 的价值：它不是让 AI 变聪明，而是把一套稳定的工作方法交给 AI。

第 6 层：Plugin——把上面这些打包成"安装包"

最后一层。也是最容易被绕晕的一层。

你看前面这一通——MCP 负责接工具，Agent 负责拆任务，Skill 负责教方法。它们各自有用，但真到团队里落地时，问题又来了：这些能力怎么统一安装、统一配置、统一分发？

Plugin 就是为了解决这个问题。它不是一种新的 AI 能力，而是一个容器。

更好懂的说法是：Skill、Agent、MCP 配置这些东西，像是一件件工具；Plugin 像一个工具箱。工具箱本身不替你干活，但它能把一整套工具按固定方式装好，让团队里每个人拿到的都是同一套配置。

一个 Plugin 长这样：

my-plugin/├── plugin.json    # 配置├── skills/        # Skills 集合├── commands/      # 斜杠命令├── agents/        # SubAgent 定义├── hooks/         # 钩子脚本└── mcp/           # MCP 配置

一条命令装好，团队所有人拿到同一套环境。

Plugin 是 2025 年 10 月 9 日随 Claude Code v2.1 发布的，相对最新。2026 年 1 月 Claude Cowork 上线时把 Plugin 推到了前台——那一天的发布会让美股软件板块市值蒸发了 2850 亿美元，因为大家发现以前花大钱买的某些 SaaS 工具，用一个 Plugin 加几个 Skill 就能在 Claude 里复刻出来。这是真实数据，不是吓你。

2026 年 3 月 31 日 Anthropic 把 Skills、Connectors、Plugins 三个东西统一收到 claude.ai/directory 这一个目录下——你大概率以后只会记住一个入口：找 Plugin。

6 个词的关系，一张表说清

看到这里如果有点晕，我用一张表把它们串起来：

它们不是 6 个互相替代的方案。是从底到顶的 6 层。

最底下的是 Prompt——所有 AI 应用都建在 Prompt 上。中间几层让 AI 越来越有能力（动手、规范化、自主、专业化）。最顶上的 Plugin 解决"怎么传给下一个人"。

那个问我问题的朋友，看完我发的解释，回了一句："早讲这么清楚，我面试就不丢人了。"

我说，下次面试官问你 MCP 和 Tool Calling 区别，记住一句话——一个是协议，一个是动作；一个对外，一个对内。

Prompt 是要求，Tool Calling 是动作，MCP 是接口，Agent 是循环，Skill 是手册，Plugin 是安装包。