引言

作为一名开发者，你是否曾被大语言模型（LLM）生态中层出不穷的术语搞得晕头转向？RAG、Function Calling、Agent、MCP... 这些概念听起来高大上，但它们究竟解决了什么问题？它们之间又是如何协作的？

在这篇文章中，我们将用最直白的语言和代码对比，为你揭示 LLM 技术栈的完整拼图。

一、LLM 的本质：不只是“预测下一个字”

大语言模型（LLM）的核心确实是基于海量文本数据训练出的概率模型，通过预测下一个最可能的词（Token）来生成连贯的文本。

虽然 LLM 很强大，但是仍然有三个致命伤：

  • 时效性滞后（Knowledge Cutoff）：训练一次 LLM 需要巨额算力和时间，这决定了它的知识永远停留在训练结束的那一天。
  • 幻觉问题（Hallucination）：当模型不知道答案时，它倾向于基于已有模式“一本正经地胡说八道”。
  • 行动力缺失（No Action）：LLM 本质上只是一个大脑（文本生成器），它没有手脚，无法直接帮你订机票、发邮件或查询数据库。

所以，如果你问“昨天苹果开了什么新品发布会？”，一个未经联网的 LLM 可能会编造一个听起来很像但实际不存在的发布会内容。

二、RAG：给 LLM 配个“随身小抄”

想象你要参加一场开卷考试。你记不住所有知识点，但允许带一张小抄。考试时，每道题你都先看看小抄上有没有相关内容，然后再答题。RAG (Retrieval-Augmented Generation，检索增强生成) 就是这个原理。

RAG 的三步走（接地气版）

  1. 准备小抄（Indexing）
    • 把公司手册、PDF、最新新闻切成小片段（Chunking）。
    • 关键步骤：通过 Embedding 模型把这些文字翻译成一串串数字（向量），存到专门的“智能笔记本”（向量数据库）里。
  2. 快速翻小抄（Retrieval）
    • 当你问：“我们公司的产品有哪些新功能？”
    • 系统会计算你的问题与数据库中片段的相似度，快速翻找出最相关的 3-5 个片段。
  3. 照着小抄答题（Generation）
    • 系统把这些“小抄片段”连同你的问题一起塞给 LLM。
    • LLM 结合小抄内容，生成准确答案。

效果对比

  • 没有 RAG：LLM：“双十一通常有满减、折扣...（瞎编通用套话）”
  • 有 RAG：LLM：“根据最新活动文档，本次双十一有：1. 满300减50 2. 新用户首单8折...”

所以，LLM 不需要记住你的文档，它只需要在考试时能看到你喂给它的上下文。

三、Function Calling：让 LLM 学会“打电话叫人帮忙”

我们说过，LLM 是预测下一个 token， 本质上是不能帮助用户去执行某些操作的。这就意味着，如果要开发一个“智能订票助手”，在 LLM 出现之前，你可能需要写几百行正则匹配代码，然后在配上你要用的 function，如下：

# 第一步：写一堆规则匹配用户的各种说法
def parse_user_input(user_input):
    if "订票" in user_input or "买票" in user_input:
        # 开始痛苦的参数提取...
        departure = None
        destination = None
        date = None
        
        # 处理"从北京到上海"、"北京飞上海"、"北京-上海"等各种写法
        patterns = [
            r'从(.+?)到(.+?)',
            r'(.+?)飞(.+?)', 
            r'(.+?)-(.+?)',
            # 还要处理倒装句："到上海从北京"
        ]
        
        # 处理日期："明天"、"下周三"、"10月1日"
        # 需要写复杂的日期转换逻辑
        
        # 处理省略："帮我订票"（需要追问用户）
        # 处理模糊："最近的航班"（需要查现在时间）
        
        # 用户换个说法，你的代码就要加规则
        # "搞两张去上海的票"（"搞"="订"吗？）
        # "北京出发，目的地上海"（语序又变了）
    
    return departure, destination, date

# 第二步：调用订票API
def book_ticket(departure, destination, date):
    # 调用携程/飞猪的API
    pass

# 第三步：主程序
user_input = input("你想做什么？")
dep, des, date = parse_user_input(user_input)
if dep and des and date:
    book_ticket(dep, des, date)
else:
    print("请告诉我出发地、目的地和日期")

问题： 用户只要换个说法（比如用方言、倒装句），你的代码就挂了。

但是，现在，你只需要告诉 LLM：“我有这个工具”，剩下的交给它，如下：

import json

# --- 第一部分：后厨（真正的业务逻辑） ---
# 这才是真正干活的代码！LLM 无法代替你写这个。
def book_flight(departure, destination, date):
    # 这里模拟调用携程/飞猪的真实 API
    print(f"正在连接航空系统...")
    print(f"查询：{departure} -> {destination}, 日期：{date}")
    # 假设 API 返回了结果
    return json.dumps({
        "status": "success",
        "ticket_no": "KA-123456",
        "price": 800
    })

# --- 第二部分：菜单（给 LLM 看的工具定义） ---
# 告诉 LLM 这个函数叫什么，需要什么参数
tools = [
    {
        "name": "book_flight",
        "description": "预订飞机票",
        "parameters": {
            "type": "object",
            "properties": {
                "departure": {"type": "string", "description": "出发城市"},
                "destination": {"type": "string", "description": "到达城市"},
                "date": {"type": "string", "description": "日期"}
            },
            "required": ["departure", "destination", "date"]
        }
    }

Function Calling 的核心流程（Request -> Response -> Execute -> Response）：

# --- 第三步：主程序逻辑（调度中心） ---

# 1. 模拟用户输入
user_query = "帮我订一张明天从北京去上海的票"

# 2. 把【问题】+【菜单】一起给 LLM
# (这里假装调用了 LLM API，以下是 LLM 返回的真实内容)
llm_response = {
    "function_call": {
        "name": "book_flight",
        "arguments": '{"departure": "北京", "destination": "上海", "date": "明天"}'
    }
}

# 3. 关键点！你的代码要接管控制权（解析并执行）
if llm_response.get("function_call"):
    # 获取 LLM 想要调用的函数名和参数
    func_name = llm_response["function_call"]["name"]
    func_args = json.loads(llm_response["function_call"]["arguments"])
    
    # 4. 路由分发：根据名字去调用真正的 Python 函数
    if func_name == "book_flight":
        # 执行真正的函数（这一步 LLM 做不了，必须你来做）
        execution_result = book_flight(
            departure=func_args["departure"],
            destination=func_args["destination"],
            date=func_args["date"]
        )
        
        print(f"函数执行结果: {execution_result}")
        
        # 5. (可选) 把执行结果再扔回给 LLM，让它生成给用户的最终回复
        # final_answer = call_llm(user_query, execution_result)
        # print("AI 回复用户：", final_answer)

四、MCP：AI 工具的“USB 接口标准”

每个 AI 平台（ChatGPT, Claude, Cursor）都有自己的工具连接标准，开发者要为每个平台重复造轮子。

没有 MCP 的混乱世界

  • 星期一：Claude 团队找你：“给我们写个插件！” —— 你写了一套代码。
  • 星期二：Cursor 团队找你：“也给我们接一个！” —— 接口格式不一样，你又重写了一套。
  • 星期三：公司内部系统要用 —— 你崩溃了。

MCP 的解决方案（Model Context Protocol）

MCP（模型上下文协议）就像是 Type-C 接口。
MCP 说：“大家别吵了，所有数据源和工具都按我的标准来描述。”

作为开发者，你只需要按照 MCP 标准写一次工具定义（Server）：

// weather_tool_mcp.json
{
  "name": "get_weather",
  "inputSchema": { "type": "object", "properties": { "city": "..." } }
}

结果：

  1. Claude Desktop 支持 MCP → 插上就能用。
  2. Cursor IDE 支持 MCP → 插上就能用。
  3. 任何支持 MCP 的新 AI 应用 → 只要插上，就能调用你的工具。

五、Agent：AI 界的“全能项目经理”

简单Agent vs 复杂Agent

简单Agent（实习生）：
用户："今天天气如何？"
Agent：调用天气工具 → 返回结果
（一问一答，不会多想）

复杂Agent（资深项目经理）：
用户："帮我规划一个周末北京游"

Agent的思考过程：

1. 目标分析：用户需要北京旅游规划
2. 制定计划：
   - 第一步：查北京有什么好玩的（调用搜索工具）
   - 第二步：查天气（调用天气工具） 
   - 第三步：根据天气调整行程
   - 第四步：查酒店（调用酒店查询工具）
   - 第五步：查交通（调用地图工具）
   - 第六步：汇总生成详细方案
3. 执行计划：（自动调用各个工具）
4. 生成报告：给用户完整方案

多模态Agent：全能的"特种兵"

不是多个Agent，而是一个Agent能处理文字+图片+语音+视频

场景：用户发来一张冰箱照片，语音说："帮我看看能做什么菜"

多模态Agent：

  1. 看图片：识别冰箱里的食材（鸡蛋、西红柿、牛肉...）
  2. 听语音：理解用户需求
  3. 思考：结合食材和菜谱数据库
  4. 调用工具：搜索菜谱API
  5. 生成：文字回复+图片示例

六、技术栈实战总结

RAG = 向量数据库 + 检索 + LLM生成
Function Calling = 工具描述 + LLM参数解析 + API调用
MCP = 工具标准化描述 + 统一通信协议
Agent = LLM + 规划器 + 工具集 + 记忆系统

这四项技术正在让AI从"聊天玩具"变成"生产力工具"。理解它们，你就能更好地设计和开发AI应用。

# 人工智能
Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

从一张商品图到正式上架：实测店匠 Shoplazza Athena，AI Agent 不只是聊天框

avatar AI Agent技术社区
cover

我测试了一个0.9B模型，它竟然能自动区分多人讲话）

avatar AI Agent技术社区
cover

【AI Agent】《2026年9月 AI Agent全栈开发技术选型专项面试宝典》

avatar AI Agent技术社区