大模型周边概念速通：MCP、Skill、Agent、Tool 到底是什么

大模型应用发展到现在，很多词会一起出现：MCP、Skill、Agent、Tool、Prompt、Resource、Memory、Guardrail、Handoff、Plugin、Connector。它们看起来都像“给 AI 增强能力”的东西，但实际所在的层级完全不同。

如果把大模型应用想成一个软件系统：大模型负责理解和生成，Agent 负责决策和调度，Tool 负责执行动作，MCP 负责把外部能力标准化接进来，Skill 负责沉淀一套可复用的任务方法。理解这些边界之后，再看各种 AI IDE、智能客服、自动化助手、博客发布机器人，就不会被概念绕晕。

总览：先看一条完整链路#

一次典型的大模型应用调用，可以拆成这条链路：

用户请求
  -> 应用 / Agent
  -> 组装 Prompt、历史记录、上下文 Resource、Memory
  -> 调用大模型
  -> 大模型决定是否调用 Tool
  -> Tool 可能来自本地代码、平台内置能力，或 MCP Server
  -> 工具返回结果
  -> Agent 继续推理、校验、生成最终回答

这里最容易混淆的是三层：

一句话概括：大模型是大脑，Agent 是工作流控制器，Tool 是手，MCP 是标准插口，Skill 是做事手册和工具包。

大模型：能力核心，但不是完整应用#

大模型，也就是 LLM 或多模态模型，核心能力是根据上下文预测和生成内容。它可以读文字、写代码、解释日志、分析图片、生成计划，但它本身通常不直接拥有你的文件系统、数据库、浏览器、Git 仓库、公司内部系统权限。

所以，大模型应用真正要解决的是：

1. 给模型什么上下文。
2. 允许模型调用哪些能力。
3. 模型何时该自己回答，何时该查数据或执行动作。
4. 工具调用前后如何校验安全性和结果质量。
5. 多步骤任务失败时如何恢复。

这就是 Agent、Tool、MCP、Skill 等概念出现的原因。

Agent：让模型从“回答问题”变成“完成任务”#

Agent 可以理解为一个带目标、工具和运行规则的执行单元。它不只是把用户输入丢给模型，而是会组织上下文、调用工具、观察结果、继续下一步，直到得到最终输出。

一个 Agent 通常包含这些东西：

比如一个“博客写作 Agent”可能会先读取历史文章，分析标签风格，生成封面图，上传图片，再创建文章。大模型负责推理和写作，但整个任务的推进是 Agent 在编排。

Tool：模型可以请求执行的具体动作#

Tool 是最基础的能力单位。它一般有名称、描述、输入参数 schema、输出结果。模型根据用户请求和当前上下文，判断是否要调用工具。

例如：

{
  "name": "search_posts",
  "description": "按关键词、标签或日期范围搜索博客文章",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string" },
      "tag": { "type": "string" }
    }
  }
}

Tool 的重点不是“模型更聪明了”，而是“模型可以把一部分工作交给确定性的系统执行”。查询数据库、发送 HTTP 请求、读文件、跑测试、调用 Kubernetes、生成图片，这些都适合做成 Tool。

工具设计有几个基本原则：

1. 一个工具只做一类清晰动作。
2. 参数要结构化，不要只给一大段自然语言。
3. 高风险动作要有权限控制、确认机制和日志。
4. 工具输出要尽量短、准、可被模型继续使用。

MCP：给 AI 应用连接外部系统的标准协议#

MCP，全称 Model Context Protocol，可以理解为“AI 应用连接外部系统的标准接口”。它解决的是集成问题：如果每个 AI 客户端都要单独适配每个外部系统，组合会很快爆炸；MCP 把外部能力包装成统一的 Server，让 AI 应用通过标准协议发现和使用这些能力。

MCP 里常见角色包括：

MCP 的关键不只是“调用工具”，它还把外部系统拆成几类不同能力：

这个区分很重要。Tool 偏动作，Resource 偏上下文，Prompt 偏可复用任务入口。把所有东西都做成 Tool，会导致权限、交互和安全边界变得混乱。

Skill：不是一个工具，而是一套可复用工作方法#

Skill 更像“任务技能包”。它通常不是某一次函数调用，而是一组说明、脚本、模板、参考资料和约定，用来让 Agent 在特定任务上稳定工作。

一个 Skill 可能包含：

skill-name/
  SKILL.md        # 什么时候启用、怎么做
  scripts/        # 可复用脚本
  templates/      # 文档、邮件、配置模板
  references/     # 领域知识或操作手册
  assets/         # 示例文件或素材

Skill 的核心价值是“渐进加载”。系统先只知道有哪些 Skill 以及它们适合什么任务；当用户请求匹配某个 Skill 时，再加载完整说明；只有真正需要脚本或参考文件时，才继续加载更多内容。这样既节省上下文，又能让复杂流程稳定复用。

举个例子，写博客这件事可以做成一个 Skill：

1. 先读取博客现有标签，避免标签碎片化。
2. 生成或选择封面图。
3. 上传图片到正确目录。
4. 按 Hugo frontmatter 规范创建文章。
5. 再读回文章确认标题、摘要、标签、封面是否正确。

这些规则不适合每次都塞进系统提示词，也不应该全做成一个 Tool。它更适合作为 Skill：告诉 Agent 这类任务该怎么完成，并在必要时调用具体工具。

Skill、Tool、MCP 的区别#

这三个概念经常一起出现，但边界很清楚：

所以：MCP Server 可以提供很多 Tool；Skill 可以指导 Agent 使用哪些 Tool；Agent 负责把用户目标拆解成步骤；大模型负责理解、推理和生成。

Prompt：不是魔法咒语，而是运行时输入结构#

Prompt 不只是用户说的一句话。在复杂应用里，Prompt 往往由多部分组成：

系统指令：你是谁、边界是什么
开发者指令：这个应用的规则和约束
用户请求：用户这次要做什么
上下文：文件、日志、网页、数据库信息
工具结果：刚才调用工具返回了什么
输出格式：最终应该怎么回答

Prompt 的质量会直接影响模型行为，但 Prompt 不能替代权限控制、工具 schema、测试和安全校验。把所有规则都堆进 Prompt，通常会让系统变脆。更好的做法是：稳定规则放在应用和 Skill 里，动态上下文通过 Resource 或检索加入，动作交给 Tool 执行。

Resource：给模型看的上下文，不一定是动作#

Resource 是模型可以参考的信息来源，例如：

1. 当前项目的 README。
2. 数据库表结构。
3. API 文档。
4. 设计稿导出的节点信息。
5. 某个用户的配置和偏好。

Resource 的重点是“读”。它不应该默认产生副作用。比如读取一张订单表结构是 Resource，创建订单或退款就是 Tool。

这个边界可以帮助我们设计权限：读上下文和执行动作的风险等级不同，审批和审计方式也应该不同。

Memory：让系统跨轮次记住东西#

Memory 是长期或中期记忆。它可以保存用户偏好、项目事实、历史决策、常用命令、业务约束。Memory 不是越多越好，因为过期、错误或冲突的记忆会污染推理。

实践里可以把 Memory 分成三类：

Memory 适合保存稳定信息，不适合保存每次都可能变化的数据。比如“今天的部署状态”应该实时查，而不是记在 Memory 里。

Guardrail：给输入、输出和工具调用加护栏#

Guardrail 是校验和拦截机制。它可以在用户输入、模型输出、工具调用前后运行，用来降低风险。

常见 Guardrail 包括：

1. 输入是否包含越权请求。
2. 输出是否泄露密钥、隐私或内部数据。
3. 工具参数是否危险，比如删除目录、覆盖生产配置。
4. 模型回答是否符合业务格式。
5. 是否需要人工确认后才能继续。

Guardrail 不能只靠一句“不要做危险操作”的 Prompt。高风险系统应该在代码层实现确认、白名单、最小权限、审计日志和回滚策略。

Handoff：把任务交给更合适的 Agent#

Handoff 是 Agent 编排里的“转交”。当一个 Agent 判断自己不是最合适的处理者时，可以把任务交给另一个 Agent。

比如：

入口 Agent
  -> 用户要排查线上数据库慢查询
  -> 转交给 Database Agent
  -> Database Agent 读取慢日志、分析索引、给出建议

Handoff 和 Tool 调用不同。Tool 是执行一个动作；Handoff 是把对话或任务控制权交给另一个专业 Agent。适合在多领域系统里使用，比如客服的退款、订单、技术支持分工，或者开发助手里的前端、后端、数据库、安全分工。

Plugin、Connector、Extension：打包和分发层#

Plugin、Connector、Extension 这些词更偏产品和分发方式，不同平台定义不完全一样。

一般可以这样理解：

它们不是模型推理的核心概念，而是把能力交付给用户的方式。一个 Plugin 里面可能包含 MCP 配置、Skill、脚本和 UI 入口。

一个具体例子：AI 帮你发布 Hugo 博客#

假设你对 AI 说：“帮我写一篇关于 MCP 和 Skill 的博客，可以配图。”背后可以这样组合：

这个例子里，MCP 不是“智能”的来源，Skill 也不是“外部服务”。真正的智能来自模型和 Agent 编排；MCP 提供标准化连接；Skill 提供可复用流程；Tool 执行具体动作。

设计大模型应用时的取舍#

如果你正在设计自己的 AI 应用，可以按这个顺序思考：

1. 先定义用户要完成的任务，而不是先堆概念。
2. 把只读上下文设计成 Resource。
3. 把有副作用的动作设计成 Tool。
4. 多个外部系统需要标准化接入时，再引入 MCP。
5. 重复出现的复杂流程，沉淀成 Skill。
6. 需要多领域分工时，再引入多个 Agent 和 Handoff。
7. 所有高风险动作都加 Guardrail、权限和日志。

不要一开始就把系统设计成“多 Agent + 多 MCP + 多 Skill”的复杂形态。能用一个 Agent 讲清楚流程，就先用一个 Agent；能用一个明确 Tool 完成，就不要做成一堆模糊工具。

常见误区#

误区一：MCP 等于 Tool。

不准确。MCP 可以暴露 Tools，也可以暴露 Resources 和 Prompts。Tool 只是 MCP 能力的一类。

误区二：Skill 等于插件。

不准确。Skill 更像任务手册和资源包；插件更像分发包，里面可能包含 Skill、连接器、命令和配置。

误区三：Agent 越多越高级。

不一定。多 Agent 会带来转交成本、上下文丢失、调试复杂度和权限问题。只有当专业分工真的清晰时，Handoff 才有价值。

误区四：Prompt 写好就万事大吉。

Prompt 很重要，但不能代替工具 schema、权限、测试、日志和安全边界。

误区五：Memory 越全越好。

过期记忆会误导模型。Memory 应该保存稳定事实，并且有更新和清理机制。

总结#

可以用这几句话记住它们的关系：

1. 大模型负责理解、推理和生成。
2. Agent 负责把目标拆成步骤，并决定下一步做什么。
3. Tool 是可以被调用的具体动作。
4. MCP 是把外部系统接入 AI 应用的标准协议。
5. Resource 是上下文，Prompt 是任务模板，Memory 是跨轮次记忆。
6. Skill 是可复用的任务流程、说明、脚本和资源包。
7. Guardrail 负责校验和拦截，Handoff 负责专业 Agent 之间的转交。

理解这些边界之后，再搭大模型应用就会清楚很多：先把任务流跑通，再决定哪些地方需要标准化、哪些流程值得沉淀、哪些动作必须加安全边界。

参考资料#

• Model Context Protocol 官方 FAQ
• MCP Server Concepts
• MCP Tools 文档
• MCP Resources 文档
• MCP Prompts 文档
• Claude Skills Overview
• OpenAI Agents SDK Guardrails
• OpenAI Agents SDK Handoffs