最近很多同學特別關注 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 應該怎么干？

理想流程可能是這樣的：

1. 查濟南十一當天的天氣（看是否適合出行）
2. 查從濟南到北京的高速路況
3. 查加油站分布和服務區情況
4. 安排中途住宿
5. 綜合輸出一份行程建議

注意，這不是一步能干完的，而是一個“多步驟 + 多工具 + 多輪決策”的鏈條。

普通的 Function Call，只能調用一個函數。但是，這個流程里，模型要自己判斷用哪些工具、什么順序、調幾次，每次結果又影響下一步行為。

這時候，就該輪到 Agent（智能體） 出場了。

什么是 Agent？

Agent，說白了就是讓模型具備一定程度的自主決策和任務規劃能力。

它就像一個“多線程”的模型調度器：

• 每接一個任務，自己思考怎么拆解
• 根據情況調用多個工具
• 遇到中間結果會重新思考下一步
• 最后一步步把復雜任務完成

你可以理解成：它會思考、規劃、決策、執行，真正具備了“完成任務”的閉環能力。

我們可以通過一張 Agent 流程圖 進行展示：

圖片

用戶輸入 → 模型分析意圖 → 判斷要調用哪個工具  → 生成參數 → 執行函數 → 拿到結果  → 判斷是否繼續 → 再次調用或返回最終答復

并且，這整個流程可以重復多輪，直到目標完成。

還是以“濟南十一自駕去北京”為例，它可能經歷這樣的 Agent 執行鏈：

• 查詢天氣 → 如果有雨，提醒注意安全
• 查詢路線 → 如果太遠，中途加一站住宿
• 住宿安排 → 查附近酒店并給出建議
• 最終輸出一個可執行的旅行計劃

這就是 Agent 的特性：不是你一步步告訴它怎么干，而是它自己規劃該怎么干。直接給你最終的規劃和結果

到目前，大家是不是已經感覺 Agent 挺牛批 的了。

但是（哎，必須得有個但是），他依然還存在一些問題。比如：標準化

大家想想，就和手機充電頭一樣，各家的可能都不一樣，從而導致除了現在這種奇葩的 “一拖三”：

那么對于 Agent 也一樣，調用的工具那么多。當工具越來越多、系統越來越復雜的時候，如何讓模型可以按照統一的標準，低成本地接入更多工具呢？

答案就是：MCP 協議！

MCP 協議：標準化協議接口

MCP（Model Context Protocol，模型上下文協議）是由人工智能公司 Anthropic 于 2024 年 11 月 24 日正式發布并開源的協議標準。你可以簡單理解成：AI 世界的 “USB 接口協議”。

它的目標是：標準化模型和外部工具之間的連接方式。

什么意思？

來看幾個典型痛點：

舉個例子：

• 你想接入地圖服務 → MCP 上直接裝騰訊地圖插件
• 想用圖生文 → MCP 上調用 Qwen-VL 工具
• 想自動發送企業微信 → MCP 上調用飛書/企業微信接口

一句話總結就是：以前是 M × N 的混亂對接，現在是 M + N 的標準接口。

圖片

你可以這么理解現在 AI 技術棧的關系：

圖片

這就是我們現在看到的 AI 應用演進路徑......