Prompt、Skill、Agent、Tool、MCP：五个概念一次分清

Prompt、Skill、Agent、Tool、MCP 经常出现在同一场讨论里，却不是五种可以互换的叫法。有人把一段很长的提示词称为 Skill，有人认为接入 MCP 就拥有了 Agent，也有人把任何会调用函数的聊天机器人都叫作智能体。概念一旦混在一起，系统设计也会跟着错位：本该沉淀的操作规范反复重写，本该交给系统闭环完成的目标却被拆成几十条人工指令。

读完这篇文章，你应该能回答三个问题：每个概念负责什么、它们怎样协作，以及面对一个具体任务时应该从哪一层开始。

概念核对日期：2026-08-28
说明：不同厂商对 Skill、Agent 等名称的产品化定义可能不同。本文采用便于跨平台讨论的工程视角，并以当前公开规范为边界。

先看结论：它们不是同一层

可以先把五个概念压缩成五句话：

• Prompt：这一次交给模型的指令和上下文。
• Skill：一类任务可复用、可发现、可维护的操作规范与配套资源。
• Tool：系统可以执行的一项具体能力，例如搜索、读文件、查数据库或发邮件。
• MCP：AI 应用连接外部上下文与能力的一套开放协议，不只可以承载 Tool，也可以提供 Resources、Prompts 等能力。
• Agent：围绕目标做判断、选择方法、调用工具、观察结果并推进到停止条件的运行系统。

最常见的协作方式是：

你用 Prompt 交代这次的目标；Agent 根据任务选择 Skill；再直接或通过 MCP 发现并调用 Tool；过程中读取资料、检查结果，直到完成、失败或需要人来决定。

这是一种常见组合，不是强制依赖关系。Agent 可以不使用 Skill，Tool 可以通过普通 API 接入而不经过 MCP，MCP 也能服务于普通聊天应用。理解它们的关键，不是硬画一条技术栈，而是分清指令、做法、动作、连接和执行主体。

用一份季度报告走完整条任务链

假设你对系统说：“根据公司数据写一份 Q3 产品运营季报，重点分析增长、留存和核心功能使用情况，并生成管理层能直接阅读的文档。”

这句话本身是 Prompt。如果系统只根据你贴进来的文字写一份内容，它仍然可能只是一次模型调用。

一个具备执行能力的 Agent 会继续判断：需要哪些数据、使用什么统计口径、缺少什么信息、结果应如何验收。它可能加载一份“季度运营报告”的 Skill，从中取得指标定义、分析步骤、文档模板和检查清单。

随后，Agent 调用不同 Tool：从数据仓库查询季度指标，读取上季度报告，运行计算脚本，再把结果写入文档。某些 Tool 可能由应用直接集成，也可能由 MCP Server 统一暴露给 Agent。

如果 Agent 需要从大量历史文档中找出相关段落，系统还可能使用 RAG 完成检索。最后，Agent 对照 Skill 中的验收项检查数字、结论和格式，必要时修正后交付。

这条链里，每一层回答的问题不同：

Prompt：这一次要模型做什么

Prompt 是输入给模型的指令、问题、示例或上下文。它可以只有一句话，也可以包含角色、背景数据、边界和输出格式。长度不会改变它的性质：两千字的任务说明依然可能只是 Prompt。

常见 Prompt 可以分为两类：

• System Prompt：定义长期角色、优先级、边界和基础行为，例如“不得泄露凭据”“回答保持简洁”。
• User Prompt：描述这一轮的具体目标，例如“比较三款产品并输出采购建议”。

Prompt 最适合探索性或一次性任务。你还不知道最终流程时，先用 Prompt 快速尝试，成本最低。它的问题也很明显：相同要求需要反复输入，团队成员的写法不一致，长指令内部还可能出现冲突。

判断一个内容是不是 Prompt，可以问：**换到下一项任务时，我是否还要把这段要求重新交代一次？**如果答案是“要”，它大概率仍停留在 Prompt 层。

Skill：一类任务以后按什么标准做

Skill 不是“保存好的长 Prompt”的同义词。它更接近一个可复用的能力包：系统能知道它适用于什么任务，需要时加载详细步骤，并按需读取脚本、模板、参考资料和验收规则。

以 Agent Skills 规范为例，一个 Skill 至少是包含 SKILL.md 的目录；还可以附带 scripts/、references/、assets/ 等资源。规范也强调渐进式加载：系统先看到 Skill 的名称和描述，匹配到任务后再读取完整说明，需要时才继续加载其他资源。

一个成熟 Skill 通常会回答：

• 什么时候启用，什么情况不要启用；
• 开始前必须读取哪些事实源；
• 任务按什么顺序推进；
• 可以调用哪些工具或脚本；
• 输出需要满足哪些质量标准；
• 失败、缺数据或高风险操作时如何处理。

Prompt 与 Skill 的真正差别在于可运营性：

需要注意，“Skill”不是所有平台都完全一致的标准名词。有些产品把预设提示词、快捷指令或特定工具也称为 Skill。讨论架构时，最好先说明你指的是“可复用操作规范”，还是某个产品里的具体功能。

Tool：让系统真正做一次动作

Tool 是模型或 Agent 可以请求执行的具体能力。它通常具有明确名称、输入和输出，例如：

• search_web(query)：搜索网页；
• read_file(path)：读取文件；
• query_sales(start_date, end_date)：查询销售数据；
• send_email(to, subject, body)：发送邮件；
• run_tests(scope)：运行测试。

Tool 解决的是“能不能做这一下”，不负责决定整件事怎样推进。邮件工具可以把邮件发出去，但它通常不会自己判断应该联系谁、措辞是否合规、发送后是否达到任务目标。

Tool 也不一定无状态或无副作用。读取天气数据通常是只读操作，创建订单、删除文件、发送通知则会改变外部状态。因此成熟系统需要给 Tool 标明权限、风险、可重试性和确认要求。

Function Calling：调用 Tool 的一种机制

Function Calling 指模型生成结构化的工具调用请求，由应用校验参数、执行函数，再把结果返回给模型。OpenAI 的 Function Calling 指南就把这一过程定义为模型与应用工具之间的多步交互。

它是工具使用的重要技术基础，但“支持 Function Calling”不等于“已经是 Agent”。如果应用始终按固定规则调用一个函数，再把结果返回给用户，它更像具备工具能力的助手。是否构成 Agent，还要看系统有没有围绕目标进行多步判断、观察环境结果并调整路径。

MCP：规定怎么连接，不替系统做判断

MCP 全称 Model Context Protocol。按照 MCP 2026-07-28 规范，它是一套让 LLM 应用连接外部数据源和工具的开放协议，定义了 Host、Client、Server 之间如何通信、发现能力和传递上下文。

把 MCP 简称为“AI 的 USB-C”有助于入门，但要补上两个边界：

1. MCP 不只连接 Tool。 Server 还可以提供 Resources、Prompts；当前规范也定义了包括 Skills over MCP 在内的可选扩展。
2. MCP 不提供业务判断。 它让能力能够被发现和调用，却不会自动决定任务目标、执行顺序或验收标准。

因此，“接上 MCP”只说明外部能力有了一种标准化接入方式。系统是否具备 Agent 的自主执行闭环，取决于 MCP 之外的模型、指令、编排、权限和反馈机制。

反过来，没有 MCP 也能构建 Agent。应用可以直接集成 API 或本地函数。MCP 的价值在于减少重复适配，让同一个 Server 暴露的能力更容易被不同兼容应用复用。

Agent：围绕目标把闭环推进下去

Agent 不是一种单独的模型，而是以模型为核心、结合指令、工具、上下文、状态和执行循环形成的运行系统。

一个实用的 Agent 闭环通常包含：

1. 理解目标和约束；
2. 决定下一步行动；
3. 选择 Skill 或 Tool；
4. 执行动作并观察真实结果；
5. 根据结果继续、修正、请求人工判断或停止。

“Agent”在行业里没有唯一口径。一个较清晰的工程边界来自 Anthropic 的智能体工程实践：Workflow 通过预定义代码路径编排模型与工具，而 Agent 由模型动态决定自己的过程和工具使用方式。

可以用三个问题判断一个系统的 Agent 程度：

• 中间路径是否需要模型根据现场信息选择，而不是全部预先写死？
• 系统是否会读取工具结果、错误或环境状态，再决定下一步？
• 系统是否有明确停止条件，并能在完成、失败或需要授权时正确停下？

只会回答问题的聊天机器人通常不满足这些条件；只会触发单个函数的助手可能满足一部分；能根据测试失败修改代码并再次验证的编码系统，则明显更接近 Agent。

RAG、Workflow、Memory 和 Multi-Agent 放在哪

这些概念经常与前五项同时出现，但解决的是另外几类问题。

RAG：给回答找到依据

RAG（Retrieval-Augmented Generation，检索增强生成）通常先从文档库或搜索系统中检索相关内容，再把结果提供给模型生成答案。它解决“需要依据哪些资料”，不负责定义整套作业流程。

知识库像参考书，Skill 像操作手册。Skill 可以要求“先检索最新政策再分析”，RAG 负责把相关政策段落找出来。

Workflow：把确定步骤稳定跑完

Workflow 是预先编排的流程，适合步骤稳定、分支明确、需要可预测性的任务。例如“收到发票 → 提取字段 → 校验税号 → 写入系统 → 通知财务”通常更适合 Workflow。

Agent 适合目标明确但路径难以预先穷举的任务。成熟系统经常把两者组合：Agent 负责识别情况和做判断，Workflow 负责稳定执行已经确定的步骤。

Memory：保存跨步骤或跨会话状态

Memory 解决“系统需要记住什么”。它可能保存当前任务状态、用户偏好、历史决策或长期事实。记忆并不会自动变成 Skill：知道“这位用户喜欢简洁报告”是状态，知道“季度报告必须按哪套步骤验收”才属于操作规范。

Multi-Agent：把执行主体组织起来

Multi-Agent 是多个 Agent 之间的分工和协调。它可能让调研 Agent、写作 Agent 和审查 Agent 分别负责一段工作，再由协调者汇总。

只有当任务能清楚拆分、并行收益高于协调成本时，多 Agent 才值得使用。把同一段模糊任务复制给更多 Agent，并不会自动提高质量。

一张总表：名称、作用和误用

按任务选择：什么时候用哪一层

只做一次，而且结果容易人工检查

先用 Prompt。比如改写一封邮件、解释一段代码、为一次会议整理议程。不要在需求尚未稳定时急着建复杂系统。

同类任务反复出现，要求口径和质量一致

把稳定部分沉淀为 Skill。比如每周经营分析、博客发布、合同审查、故障复盘。Skill 应包含触发条件、事实源、步骤、边界和验收项，而不只是成文要求。

任务需要读取实时信息或改变外部状态

提供 Tool。查库存、读文件、跑测试、建工单、发通知，都需要可执行能力。对写入、删除、支付和对外发送类 Tool，应设置最小权限和人工确认。

同一批外部能力要接入多个 AI 应用

考虑 MCP。它适合把工具、资源和提示模板以统一方式暴露给兼容客户端。若只有一个很小的内部应用，直接函数或 API 集成也可能更简单。

目标明确，但中间步骤取决于现场结果

使用 Agent。例如“定位并修复导致测试失败的问题”无法事先知道要改几个文件、运行几轮测试。Agent 可以根据每轮结果调整路径，但必须设置权限、预算、超时和停止条件。

步骤固定、规则清楚、必须稳定可审计

优先使用 Workflow。不要为了“更智能”而让模型重新判断一个已经确定的流程。必要时只把其中确实需要语义判断的节点交给 Agent。

五个高频误区

误区一：Prompt 写得够长，就会变成 Skill

不会。长度不是分界线。只有当内容具备可发现性、明确适用范围、可维护结构和配套资源，并能在多次任务中稳定复用时，才更接近 Skill。

误区二：接入 MCP，就拥有了 Agent

不会。MCP 解决连接问题，Agent 解决决策与执行闭环。给普通聊天应用接上一个 MCP Server，它仍可能只是一个能访问更多信息的聊天应用。

误区三：会调用 Tool，就一定是 Agent

不一定。固定触发一个工具后直接返回结果，缺少持续观察、调整和停止判断。它具备 Agent 的基础能力，但未必形成完整的自主执行循环。

误区四：RAG 可以代替 Skill

不能。RAG 能找回“报销制度写了什么”，Skill 规定“审核报销时先查哪些条款、怎样处理例外、如何记录结论”。知识与做法需要分别管理。

误区五：Agent 一定比 Workflow 高级

不是。两者适合的问题不同。固定、高风险、强审计流程往往更需要 Workflow 的可预测性；开放、路径不确定的任务才更需要 Agent 的动态判断。复杂度应服务于结果，而不是成为产品标签。

从 Prompt 升级为工作系统的顺序

最稳妥的路径通常不是一次性搭出“全能 Agent”，而是逐层沉淀：

1. **先用 Prompt 做通。**确认任务有价值，并观察人工实际怎样完成。
2. **识别重复要求。**记录每次都要说明的步骤、边界、格式和验收项。
3. **沉淀 Skill。**把稳定做法、参考资料、模板和脚本组织成可维护能力包。
4. **补充 Tool。**把必须读取真实数据或执行外部操作的环节做成清晰、低耦合的能力。
5. **按需要采用 MCP。**当能力要跨客户端复用或统一治理时，再标准化接入。
6. **让 Agent 负责动态部分。**只把确实需要根据环境反馈做判断的路径交给 Agent。
7. **用评估和日志持续改进。**检查任务成功率、人工接管点、工具错误、成本和风险，而不是只看回答是否“像人”。

到这里，AI 才从一次性的内容生成器，变成可以重复交付的工作系统。

最后记住这组关系

如果只想记住最短版本，可以用餐厅类比：

• Prompt 是这桌客人的点单与忌口；
• Skill 是可以反复使用的菜谱和出品标准；
• Tool 是刀、灶、收银机和订货系统；
• MCP 是设备与系统的统一接入规范；
• Agent 是理解目标、选择菜谱、调用设备、检查出品并决定是否重做的主厨；
• RAG 是查找时令食材说明和供应商资料的检索过程；
• Workflow 是后厨已经固定下来的标准流水线。

真正重要的不是记住缩写，而是每次都问清楚：这缺的是本次指令、长期做法、执行能力、连接方式、知识依据，还是一个能把目标推进到底的执行主体。问题归对层，系统才不会越做越长、越接越乱。

官方参考

• FamilyPro ChatGPT 产品页
• FamilyPro Grok 产品页
• Agent Skills 规范：目录结构、SKILL.md 与渐进式加载
• Model Context Protocol 2026-07-28 规范
• OpenAI Function Calling 指南
• Anthropic：Building Effective Agents