MCP三大核心概念拆解:如何让LLM从"空谈家"变"实干派"
1. Resources(资源管理器)—— 给LLM装上"记忆外挂"
核心作用:
-
RAG式数据供给:像图书馆管理员,告诉LLM**"这里有什么数据可用"**(数据库/文件夹/API等)。 -
动态通知机制:当资源更新时,主动通知Client端(如新增了一份产品文档,实时同步给LLM)。
典型场景:
-
企业知识库问答(自动获取最新版手册) -
实时数据查询(股票、天气等动态信息)
"Resources让LLM不再依赖训练数据,而是随时调用最新信息。"
2. Tools(工具集)—— 让LLM学会"动手"
略过但关键:
-
标准化工具调用:通过MCP协议封装Python函数、API等,LLM只需说**"帮我做XX"**,无需关心实现细节。 -
示例: # MCP协议定义的Tool(YAML格式)
- name: "send_email"
endpoint: "http://api.example.com/mail"
params: ["recipient", "subject", "content"]
"Tools是LLM的'双手',把'我想发邮件'变成实际动作。"
3. Prompts(模板大师)—— 给LLM"写剧本"
特殊之处:
-
不是普通提示词,而是可复用的交互模板,像拍戏的"分镜脚本"。 -
服务器预定义推理流程(如"故障排查五步法"),客户端只需填参数。 工作流示例:
-
服务端定义Prompt模板: "你是一名客服,请用友好语气回答关于{product}的问题,参考{resources},最后询问用户是否需要进一步帮助。"
-
客户端调用时填入参数: prompt = get_prompt("客服模板", product="iPhone15", resources="最新产品手册")
为什么归入MCP协议
-
标准化交互:避免每次重新设计Prompt,通过协议约定模板结构和参数。 -
与Tools联动:例如Prompt中嵌入 {{call tool=search_docs}}
,直接触发工具调用。
"Prompts是LLM的'台词本',把自由发挥变成可控的工业化生产。"
Tool 的“一统江湖”:为什么现实项目中大家只靠 Tool 硬刚
核心结论:
-
Prompts 和 Resources 理论上很美好,但现实里 Tool 已经够用,甚至更灵活。 -
Cherry(MCP 参考实现)也没认真做 Prompts/Resources,导致大家默认“Tool 即一切”。 -
但 Prompts 和 Resources 仍有潜力,只是现在生态还没成熟。
1. 为什么 Prompts 和 Resources 被冷落
(1) Prompts:理想很丰满,现实很骨感
理论:预定义交互模板,让 LLM 按剧本走。 ? 现实:
-
LLM 本身就有强大的上下文理解能力,临时写 Prompt 也能搞定。 -
动态性太强:业务需求千变万化,固定模板反而可能限制发挥。 -
Cherry 的实现很简陋,导致大家觉得“不如直接写 Tool”。
✅ Tool 替代方案:
-
把常用 Prompt 逻辑封装成 Tool,比如: def generate_response(prompt_template, **kwargs):
return llm.run(prompt_template.format(**kwargs)) -
效果一样,但更自由,不用依赖 MCP 的 Prompts 机制。
(2) Resources:RAG 的另一种说法
理论:动态数据源,让 LLM 实时获取最新信息。 ? 现实:
-
RAG 已经足够成熟,直接用 VectorDB + 检索 API 就能实现。 -
Cherry 的 Resources 实现太简单,没有比传统 RAG 更优势的地方。 -
Tool 可以直接封装数据查询,比如: def query_knowledge_base(question):
docs = vector_db.search(question)
return format_docs(docs) -
更可控,不依赖 MCP 的 Resources 机制。
2. 为什么 Tool 能“一统江湖”
(1) 灵活性最高
-
Tool 可以模拟 Prompts 和 Resources: -
需要固定交互模式→ 封装成 Tool(如 customer_service_prompt
)。 -
需要动态数据→ 封装成 Tool(如 query_latest_news
)。 -
不依赖 MCP 的额外抽象,直接代码控制,更符合工程师思维。
(2) 生态支持更好
-
LangChain / LlamaIndex / AutoGen 等框架都围绕 Tool 设计,MCP 的 Prompts/Resources 反而像“非主流”。 -
Cherry(MCP 参考实现)也没认真做 Prompts/Resources,导致大家默认“Tool 就够了”。
(3) 现实项目需求更匹配 Tool
-
企业级应用:需要精准控制流程,Tool 比 Prompts 更可靠。 -
复杂逻辑:比如“先查数据库,再调 API,最后生成报告”,用 Tool 组合比 Prompts 更直观。
3. 但 Prompts 和 Resources 仍有潜力
(1) Prompts:如果能标准化,可以降低重复劳动
-
未来可能变成“可复用的技能包”,比如: -
客服话术模板
、代码审查模板
等,直接调用,不用重复写。 -
需要更强大的 MCP 实现(Cherry 目前不够)。
(2) Resources:如果能实现动态订阅,会比传统 RAG 更灵活
-
理想情况:LLM 可以“订阅”数据源,实时获取更新(比如股票行情自动推送)。 -
但目前 RAG + Tool 已经够用,所以大家没动力去用 MCP 的 Resources。
现实建议:Tool 为主,Prompts/Resources 观望
-
优先用 Tool 实现功能,灵活可控,生态成熟。 -
如果发现大量重复 Prompt 逻辑,可以考虑封装成 MCP Prompts(但 Cherry 可能不够用)。 -
如果需要动态数据,直接用 RAG + Tool,别等 MCP Resources。
总结:
-
现在:Tool 是王道,Prompts/Resources 还没真正发挥价值。 -
未来:如果 MCP 生态成熟,Prompts/Resources 可能成为“高阶玩法”,但目前 Tool 已经能解决 99% 的问题。
(所以,别纠结,先用 Tool 莽穿一切! ?)