🔗 懒人直看版
一图胜千言，我们用一个表格来总结下它们的关系和区别：
| 特性 | MCP (模型上下文协议) | RAG (检索增强生成) | Agent (智能体) | Function Call (函数调用) |
|---|---|---|---|---|
| 核心思想 | 标准化 AI 与外部数据/工具的通信协议 | 检索外部知识 + 增强提示 + 生成回答 | LLM驱动的自主决策与任务执行系统 | LLM请求执行外部预定义函数/工具的能力 |
| 本质 | 协议/规范 | 技术框架/方法 | 系统/应用范式 | 模型能力/特性 |
| 通俗比喻 | 标准化的 USB 接口 | 写论文前先查资料 | 能干的私人助理 | 助理按指令使用工具 |
| 关系链 | 可作为 Agent 调用工具的底层标准 | 常被 Agent 用作获取知识的手段 | 核心指挥官，使用 RAG/Function Call 等工具 | Agent 执行具体动作的基本手段 |
1. 大语言模型（LLM）的缺陷
LLM（如GPT-4、Claude）它的核心能力是：
✅ 根据输入的文字，预测最合理的下一段文字。
但它有三大硬伤：
缺陷1：知识截止性
- LLM的训练数据停留在某个时间点（比如GPT-4是2023年10月），无法主动获取新知识。
- 后果：问它“今天天气如何？”它只能回答：“根据我的知识库，2023年10月之前上海7月平均气温是…”
缺陷2：无法操作现实世界
-
LLM只是一个“大脑”，没有手和眼睛，不能：
- 调用API（比如查天气、发邮件）
- 读取本地文件（比如整理你的D盘）
- 控制智能家居（比如关灯）
缺陷3：短期记忆有限
- LLM的上下文窗口（比如GPT-4-turbo是128K tokens）决定了它能“记住”的对话长度。
- 后果：聊到第50句时，它可能已经忘了你第1句说过“我不喜欢打乒乓球”。
2. 四大技术如何补足LLM？
（1）Agent（智能体）—— AI的“决策中枢”
- 这是啥？ Agent（智能体）是一个更高级、更自主的 AI 系统。它以 LLM 作为核心“大脑”，不仅能理解你的目标，还能自己思考、规划步骤，并主动调用工具（比如 RAG 和 Function Call）来执行任务，与外部环境互动。
- 为啥要它？ 为了完成那些光靠聊天解决不了的复杂任务，比如“帮我规划下周去上海的出差行程，包括订机票酒店，并把日程发给我”。
- 通俗比喻： Agent 就像一个超级能干的私人助理。你给个目标，它自己就能拆解任务、查信息（可能用 RAG 查公司差旅标准，用 Function Call 查航班酒店）、做决策、执行操作（用 Function Call 调用预订 API），最后给你结果。它是有自主“行动力”的。
Agent的三大核心能力
1. 任务规划（Planning）
-
用户说：“帮我订一张明天北京飞上海的机票，选靠窗座位。”
-
Agent拆解：
- ① 查航班（调用RAG或Function Call）
- ② 筛选符合时间的航班
- ③ 调用订票API（Function Call）
- ④ 确认座位偏好（MCP记忆用户喜欢靠窗）
2. 工具调用（Tool Use）
-
Agent知道什么时候该用哪个外挂：
- 需要最新数据 → 调用RAG
- 需要操作现实世界 → 调用Function Call
- 需要记忆用户习惯 → 调用MCP
3. 自我反思（Self-Reflection）
- 如果任务失败（比如航班已售罄），Agent会尝试替代方案（查高铁票）。
Agent的典型架构
用户输入 → Agent大脑（LLM） → 决策
↓
RAG Function Call MCP
↓ ↓ ↓
查资料 调API 读记忆
（2）RAG（检索增强生成）—— AI的“实时搜索引擎”
- 这是啥？ RAG (Retrieval-Augmented Generation) 是一种让 AI 回答更靠谱的技术框架。简单说，就是在 AI 回答问题 之前，先让它去指定的资料库（比如公司内部文档、最新的行业报告）里查找 相关信息。
- 为啥要它？ 防止 AI一本正经地“胡说八道”（专业术语叫“幻觉”），让它的回答基于最新的、准确的、特定的事实依据。
- 通俗比喻： 好比你写论文要引用最新数据。你不会光凭记忆（LLM 的内部知识）瞎写，而是会先去图书馆或数据库查资料 (检索) ，把找到的关键信息整合 (增强)进你的论据里，最后才下笔写作 (生成) 。RAG 就是让 AI 也学会这种“先查再答”的好习惯。
- 简单例子： 你问 AI：“我们公司最新的报销政策是啥？” RAG 系统先去公司内部知识库检索“报销政策”文档，找到相关段落。然后把这些段落和你的问题一起“喂”给 AI，AI 参考着这些最新政策，给你一个准确的回答。
RAG的工作流程
-
用户提问：“2024年欧洲杯冠军是谁？”
-
检索模块：
- 去数据库/互联网搜索“2024欧洲杯 冠军”
- 返回相关段落（比如：“西班牙2-1英格兰夺冠”）
-
生成模块：LLM把检索结果整合成自然语言回答。
RAG的两种用法
- 主动式：用户明确要求查资料（“帮我查最新的医保政策”）
- 被动式：Agent自动触发（当LLM发现自己数据过时，悄悄让RAG补课）
RAG的局限性
- 依赖检索质量（如果数据库没更新，照样答错）
- 不适合动态数据（比如股票实时价格，更适合用Function Call调API）
（3）Function Call（函数调用）—— AI的“机械手”
- 这是啥？ 它允许 LLM 在需要的时候，请求外部程序帮它做点事。注意，是“请求”，不是“亲自做”。
- 为啥要它？ 因为 LLM 自己查不了实时股价、订不了机票、发不了邮件。有了 Function Call，LLM 就能“指挥”其他工具来完成这些操作。
- 通俗比喻： 就像你让智能音箱帮你“查下今天北京天气”。音箱（LLM）自己感知不到天气，但它知道要去调用“天气查询”这个App（预定义的函数/工具）。它生成指令（“查北京天气”），App 执行后把结果（“晴，25度”）告诉音箱，音箱再用自然语言告诉你。
- 简单例子： 你问 AI：“AAPL 股价多少？” AI 判断需要查实时数据，于是生成一个“请求”：
{调用函数: "查股价", 参数: {"股票代码": "AAPL"}}。外部程序收到请求，查询API，返回结果{"价格": 180.50}。AI 再根据这个结果回答你：“苹果当前股价是 180.50 美元。”
Function Call的执行流程
- LLM识别用户意图（“这是一个天气查询请求”）
- LLM生成结构化参数（
{ "location": "上海", "date": "2024-07-30" }） - 系统调用天气API，返回数据（
{ "temp": 28℃, "rain": true }） - LLM把API结果转换成人类语言：“明天上海28℃，有雨，记得带伞！”
由于它可以让开发者自由定义函数和API调用方式，所以当不同开发者采用不同方式时，就会出现不通用的问题，导致普及困难且需要重复开发。 这就再次凸显出MCP的重要性。
为什么不能直接用API？
因为普通用户不会写代码！Function Call的本质是 “把自然语言翻译成API调用”。
（4）MCP（模型上下文协议）—— AI的“记忆增强”
- 这是啥？ MCP (Model Context Protocol) 是 Anthropic 公司（就是搞出 Claude 那个）在 2024 年底提出并开源的一种标准化通信协议。它定义了一套规则，让 AI 应用（客户端）能以统一的方式，与各种外部数据源或工具（服务器）进行交互。
- 为啥要它？ 想象一下，如果每个工具都有自己独特的接口，那 Agent 想用多个工具时，岂不是要学 N 种“方言”？MCP 就是想统一这个接口标准，让工具“即插即用”。
- 通俗比喻： MCP 就像是给 AI 大脑和外部工具之间制定了一个通用的 USB 接口标准。无论是本地文件系统、数据库，还是 GitHub 这些应用，只要它们提供符合 MCP 标准的“服务器”，AI 应用（客户端）就能轻松连接并使用它们的功能，无需为每个工具单独适配。
比如我想让Cursor（不限制任何模型）总结这篇文章并将所有图片都下载到本地，以前单纯的自然语言指令是实现不了的，现在有了MCP，就可以接入fetch MCP（专门做信息抓取的），在Agent模式下实现大模型对这些外部信息的抓取。
需要注意的是：
MCP并不绑定任何大模型，也就是你可以在支持MCP的工具（目前包括但不限于Claude客户端、Cursor等）中，在任何大模型下使用MCP。
之所以单独提到这点，是因为和Function Call**有所区别。
如果单从概念上看，大家是不是觉得MCP和Function Call还挺像的，都是让大模型更好地获取外部信息。
实际上，Function Call通常是和大模型绑定的（而MCP并不绑定任何大模型），也不是所有大模型都支持Function Call功能，以扣子中的DeepSeek-R1为例，它有两种模型：
一种是原生DeepSeek R1，一种是支持Function Call版本（扣子自己推出的），后者可以在Single-Agent模式下调用各类扣子工具（插件、工作流、知识库）。
3. 四大技术如何协同作战？
实战案例：用户说“帮我规划一个周末上海游”
（1） Agent拆解任务：
- ① 查上海景点（RAG）
- ② 查用户偏好（MCP：上次用户说“讨厌排队”）
- ③ 订门票/餐厅（Function Call）
（2） RAG检索最新信息：
- 从旅游网站抓取“2024年上海必去景点”，排除需要排队的。
（3） Function Call执行操作：
- 调用携程API订外滩观景台门票
- 调用大众点评API订一家不排队的本帮菜
（4） MCP持续记忆：
- 记录用户本次选择了“文艺路线”，下次推荐博物馆而非游乐场。
（5） LLM生成最终回复：
> “为您规划了轻松文艺的上海周末游：
>
> - 周六上午：参观浦东美术馆（已订票，免排队）
> - 周六中午：在「老吉士」吃正宗本帮菜（已订座）
> - 周日下午：漫步武康路历史街区（免费）
> 需要调整随时告诉我~”
4. 总结
总结来说：
Agent是一种AI应用，能感知环境、规划任务并调用服务（外部工具、数据库等，包括调用MCP Servers、Function Call）完成任务；如果Agent想要更好地完成任务，一般需要接入足够多的外部工具，而外部工具的接入千差万别；
Function Call是大模型本身的一种能力，可以调用外部函数或API以增强大模型能力，但它同样面临着不同开发者自由定义导致的不标准问题；
MCP则是给AI应用提供了一套标准化协议，方便AI应用更好地访问外部工具，以提升大模型的响应能力。
最终效果：让AI不仅“能说会道”，还能“真办实事”！ 🚀
扫一扫
332
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
