简介：本文从底层机制层面解析Agent Skill、模型上下文协议（MCP）与Prompt三者的本质差异：Prompt作用于模型推理上下文，Skill提供可移植、按需加载的知识包，MCP负责外部工具与数据源的标准化连接。文章拆解三者在完整工作流程中的协作方式与选型边界，并延伸说明Skill与子代理的适用场景，帮助读者在智能体架构中正确组合使用。
本文要解释的核心原理是：在大模型智能体（Agent）体系中，Prompt、Agent Skill与模型上下文协议（MCP，Model Context Protocol）分别工作在架构的不同层次上——Prompt是作用于模型推理层的指令输入，Skill是作用于代理能力层的可复用知识封装，MCP是作用于系统集成层的工具与数据接入协议。三者并非互斥竞争关系，而是在一次任务执行中按“指导—知识—执行”的分工协作。理解三者的差异，本质上要回答三个问题：它们各自改变了系统的哪个部分、数据如何流动、状态如何变化。
随着智能体架构从“单轮问答”演进为“多工具、多环节、长流程”的自动化系统，开发者实际面临的是三类不同性质的问题：
三者都带着“让模型变强”的意图，又常在同一架构中同时出现，因此容易被误解为同一层面的东西。实际上，它们分别回答的是“怎么指导”“会什么知识”“能触达什么资源”。
Prompt（提示词）：输入给模型的自然语言指令与上下文。它直接进入模型的上下文窗口（Context Window），通过注意力机制条件化模型的生成过程。它是“一次性指令载体”——每次会话都需要完整注入，本身不具备独立的版本管理、按需加载和外部执行能力。
Agent Skill（技能）：将“完成某类任务所需的知识”打包为可移植单元的封装形式。典型结构包含两层：一层是常驻的元信息（技能名称、描述、适用条件），体积很小；另一层是完整内容（操作指引文档、参考材料、可执行脚本、模板文件），仅在任务匹配时才被加载进上下文。Skill的本质是“知识与方法论的模块化封装”。
模型上下文协议（MCP）：一种面向智能体与外部系统连接的开放协议规范。它定义了统一的客户端—服务端通信方式：智能体侧运行协议客户端，外部能力以协议服务端形式暴露。协议标准化的内容主要包括三部分——能力发现（列出可用工具与资源）、能力调用（以结构化参数请求执行）、结果返回（把执行结果回传给模型继续推理）。
补充概念——子代理（Subagent）：一个拥有独立上下文窗口、独立系统提示词和独立工具权限的代理实例，由主代理按需调起，用于隔离上下文、执行专项任务。
从架构分层看，三者占据的位置完全不同：
| 对比维度 | Prompt | Agent Skill | MCP |
|---|---|---|---|
| 本质形态 | 指令文本 | 知识包（文档+脚本+资源） | 通信协议规范 |
| 作用层次 | 模型推理层 | 代理能力层 | 系统集成层 |
| 注入方式 | 全量进入上下文 | 元数据常驻、内容按需加载 | 工具清单进入上下文，执行在外部 |
| 执行主体 | 模型自身生成 | 模型按指引推理，可触发脚本 | 外部服务端真实执行 |
| 状态与生命周期 | 会话内有效 | 可版本化、跨代理复用 | 长期部署，有连接与会话状态 |
| 核心解决问题 | 行为指导 | 知识复用 | 能力接入 |
一句话概括：Prompt改变模型“怎么想”，Skill改变代理“会什么”，MCP改变系统“能做什么”。
以一次“代码安全审查”任务为例，按步骤拆解完整运行过程：
第一步：上下文组装。 系统提示词（Prompt层）注入；所有已安装Skill的元信息（名称加一句话描述）注入；所有已连接MCP服务端的工具清单（工具名与参数结构说明）注入。此时上下文里只有“目录索引”，没有“正文全文”。
第二步：任务理解与匹配。 用户请求进入后，模型根据请求语义判断需要哪些能力。若识别出需要安全审查方法论，则触发Skill加载；若需要读取代码仓库或查询漏洞库，则触发MCP工具调用。
第三步：Skill内容按需加载。 完整技能文档（审查清单、危险模式说明）进入上下文，成为模型后续推理的知识依据。这一步可能伴随脚本执行——技能包内的可执行脚本在受控环境中运行，产出结构化扫描结果。
第四步：MCP工具调用。 模型生成结构化调用请求（工具名+参数），由代理运行时（而非模型本身）通过协议客户端发送给对应服务端；服务端执行真实操作（读文件、查库），再把结果回传给模型。
第五步：结果整合与输出。 模型将技能指引、脚本输出、工具返回结果综合推理，产出最终结论。若流程复杂或需要隔离，主代理可将该任务整体委派给子代理，子代理在独立上下文中完成后仅返回摘要，避免细节污染主上下文。
Prompt之所以有效，根源在于大模型的工作方式：模型学习的是“给定前文、预测后文”，因此注入上下文的每一段指令都会直接条件化后续每一步生成。这带来两个重要推论：其一，Prompt对模型行为的约束是“软约束”——它依赖模型的理解与遵循能力，没有执行层的强制力，指令越复杂、遵循度越不稳定；其二，Prompt持续占用上下文的token预算，内容过长会稀释注意力、增加成本。因此，篇幅庞大且需要长期维护的领域知识，并不适合全量写进Prompt——这正是Skill存在的动因。
Skill的核心机制是“两层加载”：
这一机制化解了“知识量与上下文预算”的固有矛盾。它之所以能成立，是因为模型具备语义匹配能力，可以根据任务描述与技能描述的相关性判断是否加载。其代价是存在误判可能：技能描述写得含糊，就可能出现漏加载或错加载，因此技能元信息的撰写质量直接决定命中率。另一个关键属性是可移植性：Skill以标准化目录结构封装，不依赖特定代理的内部实现，任何兼容该结构的代理都能加载——这正是“Skill具有可移植性与复用性”这一论断背后的机制根源。
MCP服务端在连接建立后主动声明自身能力（工具清单与参数结构），客户端将其转译为模型可理解的工具描述注入上下文；模型决定调用时输出结构化请求，运行时负责协议通信、序列化与结果回传，底层可通过本地进程通信或网络传输承载。这一机制的核心价值在于把集成复杂度从M×N降为M+N：过去每个智能体框架要为每个外部系统单独编写适配逻辑，有了统一协议后，能力提供方只需实现一次服务端，所有兼容客户端都能接入。需要注意其边界：MCP只解决“连接与调用的标准化”，不解决“如何用好工具”——调用时机、参数组织、结果解读仍依赖Prompt与Skill层的指导；工具执行的真实性与权限控制在服务端，安全上需要配合认证、鉴权与审计。
“什么时候用Skill而不是子代理”这一问题的答案，可以从机制层面推导：
判断标准可以归纳为下表：
| 判断条件 | 选择 |
|---|---|
| 多个代理、多段对话都需要同一类专业能力 | Skill |
| 需要独立执行任务、配备特定工具权限 | 子代理 |
| 需要保持上下文隔离、避免细节污染主流程 | 子代理 |
| 需要统一演进、版本化管理方法论 | Skill |
两者还可以组合使用：子代理加载Skill执行专项任务，兼得隔离与复用。
用通用伪代码示意三者的组合方式：
# Skill定义示意：目录结构skill/security-review/├─ manifest # 名称与描述（常驻元信息）├─ GUIDE # 审查方法论（按需加载）├─ scripts/scan # 危险模式扫描脚本（按需执行）└─ refs/checklist # 审查清单（按需加载）
# 一次任务的执行流（伪代码）context = system_prompt() # Prompt层：角色与行为约束+ skill_metadata() # Skill层：技能目录+ mcp_tool_list(["repo", "vuln_db"]) # MCP层：工具清单if task.match("安全审查"):context += load_skill("security-review") # 按需加载知识scan_result = run_script("scan", repo) # 技能脚本执行files = mcp_call("repo", "read_file", path) # 协议调用外部能力vulns = mcp_call("vuln_db", "query", vuln_id)answer = model.generate(context, scan_result, files, vulns)
对比说明：如果不用Skill，方法论全文必须写进每个代理的系统提示词，流程改一次就要同步修改所有代理；如果不用MCP，读仓库和查库就需要为每个框架分别编写适配代码。
回到原理本身：Prompt、Agent Skill与MCP分别作用于智能体架构的推理层、能力层与集成层。Prompt以文本条件化模型生成，是“软性指导”；Skill以两层结构实现知识的按需加载与跨代理复用，是“可移植的方法论”；MCP以统一的发现—调用—返回协议连接模型与外部世界，是“标准化的执行通道”。三者叠加，才构成一个“知道怎么做、拥有沉淀的方法论、能够真实执行操作”的完整智能体。实践选型时把握一条主线即可：指导用Prompt，沉淀知识用Skill，接入能力用MCP，隔离执行用子代理。