拨云见日：MCP核心概念（Prompt、Resource、Tool）的设计初心与最佳实践思考

推荐语

探索MCP核心概念，洞悉大模型与Agent协同进化的未来趋势。

核心内容：
1. MCP生态发展现状与核心概念的深度解析
2. Prompt、Resource、Tool在MCP中的作用与最佳实践
3. MCP作为模型理解与改造世界的“连接器”的本质与价值

杨芳贤

53A创始人/腾讯云(TVP)最具价值专家

上周末在2025AIGC上海开发者大会（MCP引领Agent互联网新时代）上分享了主题为《大模型、Agent、MCP协同进化趋势的思考》的演讲，分享预测了未来一年大模型、Agent、MCP生态的发展趋势，需要PPT的朋友，可以点击上面卡片关注我，回复关键词（MCP）即可领取。

本文的内容源自于其中一页PPT的深度思考

以下是正文：

01 / 缘起

MCP（Model Context Protocol 模型上下文协议）生态悄然发展已逾半年，然而放眼望去，多数 Server 实现似乎都将目光聚焦于 Tool 的构建。当 Google A2A 发布将 MCP 归为 Agent 工具协议时，不禁引人深思：MCP 真的只是一个工具协议吗？那些精心设计的 Prompt 与 Resource 概念，其最初的构想与应用蓝图，又在何方？为什么大部分 MCP Server 都只实现了 Tool 功能？

02 / MCP 中的上下文：模型认知世界的基石

要解答上述关于 MCP这几个核心概念的种种疑惑，我们首先需要回到它的名字——模型上下文协议。这“上下文”究竟指什么？它如同我们认知世界时，周遭的环境信息、历史对话、以及手边的参考资料。对于大模型而言，上下文是其进行有效思考和行动的全部输入。它通常由几个核心部分构成：

• 用户指令 (Prompts)：这不仅是用户的直接命令，更应是经过领域优化的、引导模型高效输出的“引路标”。
• 静态信息 (Resources)：如同模型桌边的参考书或背景材料，可以是文档、图片、URI 指向的数据，为模型提供决策所需的稳定背景知识。
• 动态反馈 (Tool Results)：模型在与外部工具交互后，工具返回的结果——无论是成功、失败还是过程数据，都成为模型下一步行动的关键动态上下文。

这些元素共同编织了模型理解任务、环境乃至用户真实意图的“信息场”。

03 / MCP的本质：模型理解与改造世界的连接器

若仅仅停留在上述定义，我们看到的还只是 MCP 协议的表象。那么，其更深层的本质是什么？

这个连接器，一端连接着模型的强大推理核心，另一端则延伸至广阔的数字与物理世界。

模型理解世界：上下文的只读力量

所谓模型理解世界，是指模型通过注入和解读上下文信息，来认知用户所处的环境、待解决问题的具体细节，以及在执行任务过程中产生的即时或非即时反馈。这些上下文信息对于环境而言是只读的、幂等的，不会直接产生副作用。Prompts 的指引、Resources 的知识补充、Tools 的执行结果反馈，皆为此列。

1. Prompts：精心调校的场景最佳实践

在 MCP 的设计中，Prompts 远不止于用户在对话框输入的简单问句。我将其定位为特定垂直领域下的指令最佳实践集合。

想象一下，一个集成了百度地图能力的 MCP Server，它不应仅仅满足于被动响应“查找最近的咖啡馆”这样的原子查询能力。更理想的状态是，它能主动提供一系列精心调校过的 Prompt 模板，例如：

// 旅行规划Prompt模板示例：
请帮我制定一个详细的三日自驾游路线计划，要求如下：

1. 出发地为 [出发点名称或经纬度]，目的地为 [终点名称或经纬度]。
2. 沿途需经过至少3个 [兴趣点类型，例如“国家森林公园”或“历史文化景点”]。
3. 路线需尽量避开拥堵路段（可使用实时路况判断），优先选择风景优美路段（如滨海公路或高评分自驾路线）。
4. 每日行驶距离控制在不超过 [公里数] 公里，建议每日 8:30 出发，17:00 前到达住宿点。
5. 为每段行程中途推荐合适的加油站（需包含名称、经纬度、服务类型），每150公里至少推荐一次。
6. 推荐合理的住宿点，要求靠近当天行程终点，包含名称、评分、价格范围及经纬度。
7. 返回完整路线建议，包括：
   - 每日行程起止点、途经地标/景点列表及其经纬度
   - 每段路程的估算时长与距离
   - 每日加油点与住宿点的推荐清单

请以结构化格式输出，必要时调用地图搜索、路线规划、兴趣点检索等工具进行参数补全。

这些模板内置了对地图服务参数的优化理解，封装了提问的“最佳姿势”，能够显著拓宽用户的使用视野，引导用户更充分地利用模型及背后服务的能力，从而获得远超预期的结果。

这才是 MCP 中 Prompts 的核心价值所在——降低优质结果的获取门槛，提升交互的确定性与效率。那么，问题来了，为何多数现有实践忽略了这一点，仅仅把 Prompt 的构建完全抛给了 MCP Host 或终端用户呢？

2. Resources：静态知识的按需注入

Resources 在 MCP 中的定位是静态的、可引用的上下文信息单元。它可以是一段文本、一篇文档、一个指向知识库的 URI，甚至是一张图片、一段视频或任何约定格式的数据文件。

这些静态资源，既可以是 MCP Server 在过往交互中生成的有价值的“沉淀物”（例如一份分析报告、一张设计图、一个数据集），也可以是预先精心准备的各类范文、案例库、行业规范文档，或是通过 URI 动态访问的最新数据。

{
  "resources":[
    {
      "uri":"file:///travel_guides/beijing_classic_routes.md",
      "name":"北京经典旅游路线指南",
      "description":"包含故宫-天安门-景山-北海的经典一日游路线",
      "mimeType":"text/markdown"
    }
]
}

根据协议的初衷，Resources 的选择与注入，更倾向于由人（用户或开发者）在特定场景下主动进行，而非完全交由模型自行判断。MCP Host 会在应用时，根据当前任务和用户选择，决定何时、以何种方式将这些 Resources 的内容融入到给模型的最终上下文中，以辅助模型更精准地理解用户意图与特定情境。

试想，用户在撰写一份市场分析报告时，可以主动 @ 引入一份行业基准数据 Resource，或是一篇优秀的同类报告范文 Resource，模型便能“站在巨人的肩膀上”进行创作。这种显式、可控的知识注入，是 Resource 设计的关键考量。

3. Tools 执行结果：动态反馈的即时获取

AI Agent 若要完成复杂任务，往往需要通过多轮、多种工具的协同调用。在这个“观察-思考-行动-再观察”的循环中，每一次工具调用的执行结果，无论成功与否，都构成了模型至关重要的学习素材和决策依据。

这些信息需要被即时、准确地反馈给模型。例如，模型尝试预订一张机票（Tool 调用），若因余票不足而失败，这个“失败”的结果以及可能的原因（如“经济舱已售罄，是否考虑商务舱？”），便是模型进行反思、调整策略（例如，询问用户是否升级舱位，或更换临近日期）的直接输入。

因此，Tools 的执行结果，在“理解世界”这个阶段，扮演的是动态上下文提供者的角色，帮助模型在与世界的互动中持续校准认知。

模型改变世界：Tools 的双重身份之谜

谈完理解世界，我们再看模型如何“改变世界”。在 MCP 的框架下，这主要通过 Tools 的执行来实现——那些能够对外部环境产生副作用（Side Effect）的动作，如发送邮件、创建日程、下单购物、控制智能家居等。

然而，现实中的景象颇为有趣：无论是为了获取理解世界的只读上下文（如查询天气、搜索知识），还是执行会产生副作用的写操作，业界似乎不约而同地将它们统一打包实现为了 Tools。这与协议设计时，对 Prompts 和 Resources 在提供上下文方面的清晰定位，形成了一种张力。

这种“万物皆 Tool”的现状，一方面简化了 MCP Server 的实现复杂度——只需关注一种交互模式；另一方面，却也模糊了不同类型信息交互的本质区别，可能导致了 Prompts 和 Resources 潜能的未能充分释放。这种现象是设计与现实的矛盾，还是特定发展阶段的必然趋同？值得我们深入思考。

04 / 应用场景与交互形态的畅想：让完整 MCP“活”起来

时至今日，我们所熟知的 MCP Host 应用，几乎清一色地以 Tools 的使用为核心，对于 Prompts 和 Resources 的原生支持与交互设计，似乎还是一片待开垦的处女地。这使得我们对一个完整实现了 MCP 协议三驾马车的应用，究竟能带来怎样焕然一新的体验，多少有些缺乏具体的画面感。

基于对协议底层逻辑的理解，以及参考一些官方团队的访谈片段，我们可以尝试对 Prompts 和 Resources 在 MCP 生态中的应用场景和交互形态，做一番更生动的畅想与推演。

Prompts 的交互与场景

交互形态：

1. 1. 隐式触发与检索：在 MCP Host 的输入界面，用户可以通过输入特定前缀（如 / 或中文的“唤起指令”）配合关键词，快速检索并选用 MCP Server 提供的优质 Prompt 模板。例如，输入 /旅行，即可列出与旅行规划相关的多个 Prompt 模板。
2. 2. 显式列表与引导：MCP Host 可以根据当前连接的 MCP Server 能力，在界面特定区域（如灵感面板、助手建议区）清晰地陈列出可用的 Prompt 模板列表，供用户浏览和点选，尤其适合初次接触或希望探索服务能力边界的用户。
3. 3. 模型驱动与智能推荐：基于用户当前的输入、对话历史或正在处理的任务上下文，MCP Host 内置的辅助模型可以智能分析用户意图，并主动推荐一个或多个高度相关的 Prompt 模板，实现更智能的引导。

应用场景：

1. 1. 百度地图 MCP Server：提供“周末家庭游规划”、“三日徒步路线设计”、“规避限行通勤方案”等 Prompt 模板。用户点选后，只需填入少量关键信息（如目的地、偏好），即可获得高度定制化的出行方案。
2. 2. 小红书 MCP Server：提供“热门[品类]产品测评笔记框架”、“[城市]探店攻略创作向导”、“[技能]学习心得分享结构”等 Prompt 模板，辅助用户高效生成符合平台调性的优质内容。
3. 3. 代码助手 MCP Server：提供“生成符合[某设计模式]的[语言]代码骨架”、“为[函数名]编写单元测试用例”、“解释这段[异构语言]代码的逻辑”等 Prompt 模板，赋能开发者快速完成标准化、高质量的编码任务。

Resources 的交互与场景

交互形态：

1. 1. @ 符号注入与多选：借鉴成熟的代码编辑器或知识管理工具（如 Cursor 的 @ 文件/符号，Notion 的 @ 页面/日期），用户在 MCP Host 输入时，可以通过 @ 符号快速搜索并选中一个或多个由 MCP Server 管理或用户个人积累的 Resources，将其动态注入当前对话的上下文中。
2. 2. 上下文感知推荐与点击注入：当用户处理特定任务时（如撰写报告、分析数据），MCP Host 可以根据任务特征和已加载的 MCP Server，智能推荐相关的 Resources（如行业模板、历史案例、相关数据集），用户点击即可注入。
3. 3. 可视化列表与拖拽管理：MCP Host 可以提供一个专门的 Resource 管理面板，用户可以清晰看到当前 MCP Server 提供的可用公共 Resources，以及自己有权访问的私有 Resources，支持拖拽注入或预设加载。

应用场景：

1. 1. 企业知识库 MCP Server：企业内部的规章制度、产品手册、最佳实践案例、FAQ 等均可作为 Resources。员工在处理客户咨询或内部协作时，可以快速 @ 相应文档，模型基于此提供更精准的回答或方案。例如，客服在处理售后问题时，@ 产品维修手册 Resource。
2. 2. 科研协作 MCP Server：研究员可以将实验数据、参考文献、项目计划书、会议纪要等注册为 Resources。在撰写论文或进行项目讨论时，可以方便地 @ 相关材料，模型能够围绕这些核心资料提供分析、总结或建议。
3. 3. 教育辅导 MCP Server：教师可以将课程大纲、知识点讲义、典型错题集、优秀学生作业范例等作为 Resources。学生在提问或请求辅导时，可以 @ 相关章节的讲义或错题集，AI 助教便能提供更有针对性的讲解与练习。

Tools 的交互与场景 (现状回顾与展望)

Tools 的交互目前相对成熟，通常是模型分析用户意图后，决定调用哪个 Tool，并组装参数发起请求。Host 负责执行并返回结果。

现有场景很广泛：

• 查询天气、股票、新闻。
• 预订机票、酒店、餐厅。
• 发送邮件、设置提醒、管理日历。
• 在代码编辑器中执行代码、应用重构。

未来的想象空间在于更复杂的编排与更深度的融合：例如，一个“一站式旅行规划”场景，可能需要模型依次调用：机票查询Tool、酒店预订Tool、景点推荐Tool、当地交通规划Tool，并将前一个Tool的输出作为后一个Tool的部分输入，同时结合用户通过 @ 注入的个人偏好Resource（如“偏爱安静的住宿环境”），以及选用一个“深度文化体验游”的Prompt模板。这才是 MCP 三者协同的理想画面。

05 / 为何行业只关注了 Tools，而忽略了 Prompts 和 Resources？

这是一个值得我们共同探讨的问题。我认为，可能存在以下几方面原因：

1. 1. 即时价值与可见性：Tools 直接关联“行动”，其效果立竿见影，更容易展现 AI Agent 的能力，满足市场对于“能做事”的迫切需求。相比之下，Prompts 和 Resources 更侧重于优化“理解”的深度和广度，其价值传递链条稍长。
2. 2. 实现门槛与标准化：Tools 的设计与实现，可以类比传统的 API 接口，开发者有成熟的范式可循。而优质 Prompts 的设计需要深厚的领域知识和对模型脾性的洞察；Resources 的管理与高效检索，也涉及更复杂的信息架构考量。
3. 3. Host 应用的成熟度：目前 MCP Host 应用本身仍在快速迭代，优先保障核心的 Tool 调用功能是自然选择。对 Prompts 和 Resources 的精细化支持，需要 Host 在交互设计、用户体验、甚至内置智能推荐能力上投入更多。
4. 4. 认知与习惯：开发者和用户可能尚未充分认识到结构化、可复用的 Prompts 与 Resources 能带来的巨大效率提升和体验改善。打破“直接提问-直接调用”的惯性思维，需要时间和成功案例的引导。
5. 
   

06 / 未来半年，这种情况会改变吗？

展望未来半年，MCP 生态中 Prompts 和 Resources 的地位是否会迎来转机？我持谨慎乐观的态度。

一方面，随着大模型应用从尝鲜走向实用，用户对结果的可靠性、交互的便捷性、以及个性化体验的要求会越来越高。这自然会驱动 MCP Server 的提供者去思考，如何通过更优质的 Prompts 设计来提升模型的“可用性”，如何通过丰富的 Resources 支持来增强模型的“专业性”。

另一方面，社区中已经开始出现一些前沿的思考和实践。例如，一些致力于构建复杂 Agent 的团队，可能会率先意识到，仅仅依赖模型自身的泛化能力和临场发挥是远远不够的，必须辅以高质量的“导航图”（Prompts）和“知识库”（Resources）。

同时，我们期待 MCP 协议自身或其扩展提案中，能对 Prompts 和 Resources 的发现、注册、版本管理、权限控制等机制，给出更明确的指导和最佳实践，从而降低 Host 和 Server 的实现门槛。

07 / 结语：从“可用”到“好用”，重拾设计的初心

MCP 的设计，如同一座精心勾勒的桥梁，意图连接模型的智慧与世界的广阔。Tools 是坚实的桥墩，承载了交互的通路。而 Prompts 与 Resources，则是桥面上的导航与路书，决定了通行的效率与风景。

现实是，我们匆匆建起了桥墩，便急于通行。未来，是时候铺设更平坦的路面，树立更清晰的指引了。从“知晓”MCP的全貌，到“践行”其完整的设计哲学，这本身就是一场“理解”与“改造”的旅程。

期待MCP 的下一程，是 Prompts、Resources 与 Tools 三者并驾齐驱，共同驶向更智能、更懂我们的未来。