MCP Resources详解：AI应用如何读取上下文而非调用工具

什么是MCP Resources

MCP（Model Context Protocol）生态中，很多人熟悉的是MCP Tools——让大模型调用某个函数去执行操作。但在构建AI Agent或AI助手时，还有一个同等重要却常被忽视的概念：MCP Resources（资源）。IIT出身的技术讲师Pankaj Shukla在视频中用一个退款政策的真实场景，把这个概念讲得非常透彻。

一句话概括：MCP Resource是由MCP服务器暴露出来的、可寻址、可读取的上下文（addressable, readable context exposed by an MCP server）。它本质上是一份文档、一个文件，或者说一段外部内容，AI应用可以直接读取它的内容并喂给大模型。

MCP（Model Context Protocol）是由Anthropic于2024年底提出并开源的标准协议，旨在统一AI应用与外部数据源、工具之间的接口方式。在此之前，每个AI应用都需要为不同数据源单独编写适配代码，维护成本极高。MCP通过定义统一的Client-Server架构解决了这一碎片化问题：MCP Server负责暴露能力（工具、资源、提示模板），MCP Client（通常内嵌在AI应用或Agent框架中）负责发现并调用这些能力。Resources是MCP协议规范中与Tools、Prompts并列的三大原语之一，专门处理"读取外部内容"这一需求，其设计理念是让AI应用能以标准化方式访问任意外部文档或数据，而无需为每种数据源定制集成逻辑。

用退款政策场景理解Resources

设想一个AI应用，用户在菜单里挑选了一份名为「Refund Policy 2026」的文档，然后提问：「一位顾客8天前购买了商品，是否允许退款？」

这个问题的答案不能靠大模型凭空生成，它必须来自公司真实的退款政策文档。如果直接把问题丢给LLM，模型只会幻觉出一个看似合理却可能错误的答案。真正的答案应该从企业政策里精确提取。

关键点在于：用户已经主动选择了这份文档，应用本身已经知道上下文（the application already knows the context）。既然如此，就没必要再把问题先发给LLM、让LLM决定调用哪个工具去获取政策。应用应该做的，是直接把这份精确的外部内容读出来，连同问题一起交给大模型。

这份退款政策文档存放在MCP服务器上，而不是用户本地机器。Shukla强调了两个原因：一是部门里很多人都需要访问同一份政策；二是政策一旦更新，放在服务器上就能保证所有人拿到的永远是最新版本，避免本地缓存读到过期的旧政策。

Resources如何被寻址和读取

每个资源都有一个唯一资源标识符（URI, Uniform Resource Identifier）。比如退款政策可以表示为 policy://refund/2026。通过这个URI，应用就能定位并访问到对应的文档。

整个数据流是这样走的：

• 用户在AI应用的菜单中选中某个文档，该菜单项已绑定对应的URI
• 应用把读取请求发给MCP Client
• MCP Client连接MCP Server，请求读取这个URI对应的资源
• 服务器读取文件并返回实际内容（the server returns the actual content）
• 内容经MCP Client回传给AI应用

服务器返回的内容可能很长，视频里用了个简化示例：「Refunds are allowed within 10 days of purchase（购买后10天内允许退款）」。这段内容的来源可以是文档库、数据库，也可以是内部API。拿到精确上下文后，应用把「问题 + 政策内容」一起发给LLM，模型阅读政策并生成自然语言的准确回复。

URI（统一资源标识符）是互联网中用于唯一标识资源的字符串格式，其通用结构为 scheme://authority/path。在MCP Resources中，URI的scheme部分可以自定义（如 policy://、customer://），这与我们熟悉的 https:// 或 file:// 是同类概念，只是命名空间由MCP Server自行定义。MCP规范允许Server在初始化握手阶段通过 resources/list 接口向Client暴露所有可用资源的URI列表及元数据（名称、描述、MIME类型等），Client随后可通过 resources/read 请求获取具体内容。这种"先发现、再读取"的两阶段模式，使得AI应用可以在启动时构建完整的可用文档索引，从而支持用户在界面上进行资源选择——正如文中退款政策场景里的文档菜单所展示的交互方式。

Tool与Resource的核心区别

这是整个视频最重要的区分点，理解了它就抓住了Resources的本质。

Tool的流程由模型驱动（model-driven）：用户的问题先发给LLM，同时附上一份可用工具清单，由LLM自己判断该问题适合调用哪个工具。决策权在模型手里。

Resource的流程由应用驱动（application-driven）：因为用户已经选好了文档，应用不先经过LLM，而是第一步就自己把上下文取回来，然后再把「问题 + 上下文」交给模型。

这种设计带来两个直接好处：

• 更快：省去了让LLM先做工具选择决策的往返环节
• 更轻：Resource只需要读取内容，不需要执行任何函数或功能逻辑，而Tool的本质是「执行、运行、提供某种功能」

用Shukla的话说：工具的核心是execute（执行），而资源的核心是read（读取）。当你需要的只是一份文件的内容时，用Resource远比强行套一个 get_refund_policy 工具更合理。

从系统设计角度看，"应用驱动"与"模型驱动"的区别本质上是决策权归属的问题，这直接影响系统的延迟、可预测性和调试难度。当决策权交给LLM时（Tool模式），系统需要额外一轮LLM推理来决定调用哪个工具，这不仅增加了端到端延迟，还引入了不确定性——模型可能选错工具或产生幻觉。而Resource模式将这一决策前移到应用层（通常是确定性代码逻辑或用户显式操作），消除了这一环节的不可预测性。这与软件工程中"能在编译期确定的事情就不要留到运行期"的原则一脉相承。在实际Agent架构设计中，一个常见的最佳实践是：当上下文的选取逻辑可以在应用层明确表达时，优先使用Resource；只有当需要根据问题动态决策执行哪种操作时，才引入Tool。

动态资源：带变量的URI

前面讨论的退款政策、隐私政策、物流政策都属于固定资源。但现实中也存在动态资源，比如某个用户的个人资料。

动态资源的URI里会包含占位符，用花括号表示，例如 customer://profile/{customer_id}。当实际请求时，花括号会被真实值替换——比如客户ID为4821时，URI就变成 customer://profile/4821。

设想一个呼叫中心场景：客服的AI应用拿到来电客户的ID，拼出对应URI去MCP服务器读取该客户的完整档案，再把档案交给应用使用。这个档案可以发给LLM用于回答问题，也可以直接用于应用内的其他逻辑。

需要注意的是，即便资源可以被动态访问（和Tool一样能列出全部资源列表），决策权依然留在应用层，而非交给LLM。应用需要根据问题自己决定选哪个文档。

心智模型总结

把MCP Resources的使用逻辑浓缩成一句话：AI应用（无论是AI Agent、AI助手还是聊天机器人）先从MCP服务器把资源/上下文取回来，再把这份上下文连同用户问题一起发给LLM，由LLM生成回复。

三个要点值得记住：

• Resource用于直接读取文档内容，不涉及任何功能执行
• 文档放在MCP服务器上，便于集中更新、保证所有访问者拿到最新版本
• 最佳使用场景是：在应用层就已知上下文时，不经过LLM决策，先取资源再带着问题发给模型，既快又轻

理解Tool（模型驱动、负责执行）与Resource（应用驱动、负责读取）的分工，是设计高效MCP架构的基础。