Agent Skill、MCP 与 Prompt：从 OOP 视角看 AI 交互抽象

用传统的 OOP 思想理解 Skill、MCP 和 Prompt 的关系与区别。

核心共识：一切皆 Prompt

从原理上，大模型的每次交互，本质上都只接收一个完整的 Prompt。

不管是 Skills、Tools 还是 MCP，最终都被打包成一段文本塞进模型的上下文里。所以严格来说：

Skills、Tools、MCP 都是”结构化的高级 Prompt”

它们不是模型原生的”新功能”，而是人类通过提示工程设计出来的模式，用来让模型的行为更可控、更高效。

Tool 调用（function calling / tool use）是 Prompt 的一个重要进化方向。

普通 Prompt 是”自由文本输出”，而 Tool 给模型加了严格的结构化约束：

这本质上是通过 Prompt 工程”强迫”模型走结构化路径，避免幻觉、提高可靠性。

MCP 可以看作 Tool 机制的直接子类，区别只在于执行方式：

类型	执行方式
普通 Tool	本地调用（模型输出 JSON → Agent 系统在本机执行函数 → 把结果塞回上下文）
MCP	网络请求（模型输出结构化指令 → Agent 通过 API 远程调用另一个模型或服务）

但对模型本身来说，输入输出完全一致：它只看到一个带工具描述的 Prompt，输出一个 JSON。

MCP 的”万能”之处在于，它把多个子任务/子模型调用抽象成工具链，本质仍是 Tool 的链式调用。

所以 MCP 不是革命性创新，而是 Tool 在 Agent 系统中的一种实现变体（解决单模型上下文限制、实现多轮协作）。

Skills 是对 Tool 机制的进一步抽象，核心解决两个痛点：

如果一次性把所有 Tools 的 description 全塞进 Prompt，上下文很快爆炸。

Skills 通过“渐进式披露”（progressive disclosure）机制，只在需要时动态注入相关工具描述。

Tool 只约束输出格式，不约束思考过程。Skills 则额外提供： - 角色定义：模型以什么身份行事 - 思维框架：处理问题的思考模式 - 执行规范：调用 Tool 前后保持一致风格

从实现上看，Skills 通常包含： - 一个固定的”元框架 Prompt”（定义角色、输出规范） - 动态加载的 Tool 子集 - 可选的记忆/状态管理

Prompt (基础)
  └── Tool (结构化输出)
        └── MCP (远程调用扩展)
        └── Skill (高级封装 + 渐进披露)

所以 Skills > MCP > Tool 在复杂度上层层递进，但本质仍是 Prompt + Tool 的组合。

如果用 OOP 的类图来表示这种关系：

理解这些概念的层级关系，有助于我们在构建 AI 系统时做出正确的选择：

不要为复杂而复杂，选择合适的抽象层级才是关键。