Hello，大家好，我是 Sunday。
最近很多同学特别关注 AI 相关的领域。c但是，AI 技术发展太快了，AIGC、RAG、Agent、Function Call、MCP 等等的各种热词层出不穷的。多到就算是很多程序员都搞不明白了。
所以，咱们今天这篇文章，我就来用最简单的方式，帮你把这些热词一次性讲清楚~
从 AIGC 到多模态
大部分同学应该都是从 ChatGPT 开始接触 AI 的，比如我就是。
刚开始用 ChatGPT 的时候，我们体验到的其实是一种典型的 文生文 能力：
你输入一句话，它给你生成一段文字回应。
不管是写文章、改简历，还是输出代码、写周报，都是 AI 在根据你的文字 Prompt，生成另一段文字。
这种让 AI 自动生成内容的能力，就叫做 AIGC。
AIGC，全称是 AI Generated Content（AI 生成内容），它的核心能力是：用 AI 自动生成“人类常干的活”。
在最初的时候，AIGC 他只能处理 一种类型 的内容，比如：GPT-3 只懂文字，SD 只会画画，这种模式就被称之为 单模态。
但是，随着 AI 的进化，不只是文生文，像：文生图、图生文、文生视频、图文生视频……也都逐渐支持了（并且进化的速度特别快），而这种支持 多种类型 消息的，就被称为是 多模态。 比如现在的 CPT-4。
而这些多模态模型，才是真正让 AI 从“工具”进化成“助手”的关键。
但 AIGC 有两个“天生的限制”：
- 第一就是 不具备实时性。比如，以 DeepSeek 为例，他的知识库就只更新到了 2024 年 7 月。如果想要让他知道最新的数据怎么办呢？就得给他 “喂数据！”
- 第二就是 不会使用工具。最初的 AIGC 只可以从现有的知识库中获取内容，而不会查询最新的信息，也不能调用 API。
因此，这就引出了两个技术方向，一个叫 RAG，一个叫 Function Call。
RAG 实时信息查询
RAG，全称是 Retrieval-Augmented Generation（检索增强生成）。
就像上面的 DeepSeek 截图一样，如果查询的内容超过了知识库怎么办呢？
很简单 实时查询就可以了！ 查完以后，把资料贴给 AI，再让它写。
比如你问“北京明天的天气”，它自己不知道，但可以去“检索模块”查一遍，把查到的结果再结合起来给你回答。
你可以理解成：原来模型靠死记硬背，现在它学会“看资料答题”了。
但如果你仔细想一想：只会看，越不行呀。
咱们需要的时，他可以把资料看完之后，把内容返回给咱们。甚至可以做到，当我说：“给我订个明天下午去北京的高铁票” 时，他可以 自动调用 12306 接口，选好车次直接下单
如果你可以想到这里，那么恭喜你。你已经摸到 Agent 智能体 的门槛了。
中间就只差了一个 Function Call（函数调用）
Function Call 调用函数
简单来说，Function Call 就是让模型 根据你的指令，自动调用外部的函数或接口，把任务真正执行掉。
比如你说：“我现在在北京，查一下明天上海的天气。”
传统的 LLM：
“对不起，我只能提供截至 2023 年的信息。”
支持 RAG 的模型：
“明天上海天气 28°C，小雨。”（它查了资料，但没动手）
支持 Function Call 的模型：
它会判断你这个请求，需要调用一个叫 getWeather(city) 的函数，然后自动生成参数city = "上海"，调用完天气 API → 拿到结果 → 生成回复：
“明天上海 28°C，小雨，建议带伞。”
你看，整个过程中，它已经从一个单纯的回答者，变成了 可以自己思考你接下来应该怎么做 “带伞” 的 “人” 了
因此，我们说 Function Call 是 AI 走向“智能体”的关键
这时候，该登场的，就是最近特别火的词：Agent（智能体）。
Agent：传说中的 “人工智能”
前面咱们说了，Function Call 让模型拥有了“动手能力”。
但是你会发现，现实世界的任务，往往不是一句话、调一次函数就能搞定的。
比如说你问它： “我十一想自驾从济南去北京，帮我规划下出行方案。”
一个聪明的 AI 应该怎么干？
理想流程可能是这样的：
- 查济南十一当天的天气（看是否适合出行）
- 查从济南到北京的高速路况
- 查加油站分布和服务区情况
- 安排中途住宿
- 综合输出一份行程建议
注意，这不是一步能干完的，而是一个“多步骤 + 多工具 + 多轮决策”的链条。
普通的 Function Call，只能调用一个函数。但是，这个流程里，模型要自己判断用哪些工具、什么顺序、调几次，每次结果又影响下一步行为。
这时候，就该轮到 Agent（智能体） 出场了。
什么是 Agent？
Agent，说白了就是让模型具备一定程度的自主决策和任务规划能力。
它就像一个“多线程”的模型调度器：
- 每接一个任务，自己思考怎么拆解
- 根据情况调用多个工具
- 遇到中间结果会重新思考下一步
- 最后一步步把复杂任务完成
你可以理解成：它会思考、规划、决策、执行，真正具备了“完成任务”的闭环能力。
我们可以通过一张 Agent 流程图 进行展示：
用户输入 → 模型分析意图 → 判断要调用哪个工具 → 生成参数 → 执行函数 → 拿到结果 → 判断是否继续 → 再次调用或返回最终答复
并且，这整个流程可以重复多轮，直到目标完成。
还是以“济南十一自驾去北京”为例，它可能经历这样的 Agent 执行链：
- 查询天气 → 如果有雨，提醒注意安全
- 查询路线 → 如果太远，中途加一站住宿
- 住宿安排 → 查附近酒店并给出建议
- 最终输出一个可执行的旅行计划
这就是 Agent 的特性：不是你一步步告诉它怎么干，而是它自己规划该怎么干。直接给你最终的规划和结果
到目前，大家是不是已经感觉 Agent 挺牛批 的了。
但是（哎，必须得有个但是），他依然还存在一些问题。比如：标准化
大家想想，就和手机充电头一样，各家的可能都不一样，从而导致除了现在这种奇葩的 “一拖三”：
那么对于 Agent 也一样，调用的工具那么多。当工具越来越多、系统越来越复杂的时候，如何让模型可以按照统一的标准，低成本地接入更多工具呢？
答案就是：MCP 协议！
MCP 协议：标准化协议接口
MCP（Model Context Protocol，模型上下文协议）是由人工智能公司 Anthropic 于 2024 年 11 月 24 日正式发布并开源的协议标准。你可以简单理解成：AI 世界的 “USB 接口协议”。
它的目标是：标准化模型和外部工具之间的连接方式。
什么意思？
来看几个典型痛点：
没有 MCP 以前 | 有了 MCP 之后 |
每个工具都要独立接入 | 所有工具统一协议，复用成本低 |
模型和工具强绑定 | 松耦合，谁来调用都行 |
平台之间协议不通用 | 基于开放标准，可跨平台、跨模型 |
没有工具生态 | MCP 广场上线，AI 应用像“装插件”一样用工具 |
举个例子：
- 你想接入地图服务 → MCP 上直接装腾讯地图插件
- 想用图生文 → MCP 上调用 Qwen-VL 工具
- 想自动发送企业微信 → MCP 上调用飞书/企业微信接口
一句话总结就是：以前是 M × N 的混乱对接，现在是 M + N 的标准接口。
你可以这么理解现在 AI 技术栈的关系：
这就是我们现在看到的 AI 应用演进路径......
