MCP 不只是函数调用：理解 Resources 与 Tools 构建的 AI 操作系统
撰写日期：2025年11月9日
作者：Honlnk / 鸿影
适用场景：企业级智能体平台（支持多数据源、细粒度权限、审计追踪）集成基于 MCP 的动态工具与资源发现能力
目标：在保障现有权限模型与数据隔离的前提下，安全、可解释、可组合地实现“LLM 主动感知并操作业务实体”的智能交互能力
引言：我曾以为 MCP 只是更好的 Function Calling
很长一段时间里，我和许多人一样，把 Model Context Protocol（MCP）简单理解为“带权限的函数调用”。毕竟，它看起来和 OpenAI 的 function_calling 很像——都是让 LLM 调用外部接口。
但当我尝试构建一个能自动总结用户可见合同、对比条款差异、并邮件通知相关人的企业级助手时，我发现：仅靠“工具”根本不够。LLM 不知道有哪些合同可用，也无法向用户清晰说明“我正在处理哪份文件”。
直到我真正理解了 MCP 的两个正交模块——Resources（资源） 与 Tools（工具），我才意识到：MCP 不是在增强函数调用，而是在为 AI 构建一个可感知、可操作的操作系统。
核心抽象：Resources 与 Tools 是独立的
MCP 的设计哲学中，最关键的洞见是：
“有什么”（Resources） 和 “能做什么”（Tools） 必须解耦。
✅ 什么时候不需要 Resource？
对于纯动作型服务，如：
- 发送短信
- 查询天气
- 创建日历事件
这些操作不作用于已有数据实体，只需定义全局工具（Global Tools） 即可。此时 Resource 可省略。
✅ 什么时候必须引入 Resource？
当你的系统涉及已有数据实体（如文档、任务、数据库记录），且满足以下任一条件：
- 用户可能需要“浏览/选择”操作对象；
- LLM 需要主动告知“我能访问哪些文件”；
- 系统需支持基于实体的细粒度权限控制；
- 未来可能扩展对该实体的新操作（如版本查看、协作评论）。
此时，Resource 是不可替代的抽象。
工作流程：LLM 如何与 MCP 协作？
一个典型的企业知识库查询流程如下：
-
初始化阶段
MCP Client 向知识库服务发起GET /resources请求，获取当前用户有权访问的文档列表（含 URI、标题、支持的工具）。 -
用户提问
用户问：“总结我有哪些采购合同？” -
LLM 决策
LLM 结合注入的资源列表，识别出两份合同文档，并决定对每份调用summarize工具。 -
顺序执行（ReAct 循环）
- LLM 输出：
summarize(resource_uri="doc://contract-A") - MCP Client 执行调用，返回摘要
- LLM 再输出：
summarize(resource_uri="doc://contract-B") - ……直到任务完成
- LLM 输出：
-
生成回答
LLM 整合结果，回复：“我找到了2份采购合同：《2024服务器采购》金额120万，《云服务协议》期限3年……”
🔁 注意：每一步都依赖上一步的结果，因此是严格串行的 ReAct 循环。所谓“连续调用多个接口”，只是高速串行带来的错觉。
为什么 Resource 让系统更安全、更智能？
| 能力 | 无 Resource（仅 Tool） | 有 Resource + Tool |
|---|---|---|
| 权限控制 | 每次调用需传 ID 并校验 | /resources 已过滤可见实体，后续调用只需验证 URI 白名单 |
| 用户体验 | “已总结 doc-8890” → 用户困惑 | “已总结《2024采购合同》” → 用户清晰理解 |
| AI 自主性 | 被动等待用户指定 ID | 主动列出可用文档，引导用户选择 |
| 系统扩展性 | 新功能需新增全局 Tool | 在 Resource 的 available_tools 中声明即可 |
Resource 是天然的权限边界单元，也是 LLM 理解业务上下文的锚点。
实践建议：如何设计你的 MCP 服务？
-
为数据实体建模 Resource
使用语义化 URI（如knowledge://dept/finance/contract-2024.pdf），避免裸 ID。 -
工具绑定到 Resource 或全局
summarize→ 绑定到文档 Resourcesend_notification→ 全局 Tool
-
在
/resources接口做权限过滤
返回前确保用户确实有权访问该实体。 -
限制 ReAct 循环次数
防止无限调用（建议默认 ≤ 5 步）。 -
日志记录完整调用链
便于审计：“谁在何时通过什么工具操作了哪个资源”。
结语：MCP 是智能体时代的“系统调用”
如果说 Function Calling 是让 LLM “打电话找人办事”，
那么 MCP 就是给 LLM 配了一台能看见文件柜、知道每个抽屉里有什么、还能使用各种办公工具的智能工作站。