一文剖析大模型、RAG、Agent、MCP、Function Calling、知识库、向量数据库、知识图谱、AGI 的区别和联系-优快云博客

MCP构建AI大模型全景技术架构体系

我们要把 AI 大模型当做人的大脑，因此调用 AI 大模型，相当于调用一个人，把 AI 大模型当人看，TA 懂人话、TA 说人话、TA 会直接给出结果，但结果不一定正确。

因此在 AI 大模型的推理基础上，通过 RAG、Agent、MCP、Function Calling、知识库、向量数据库、知识图谱等技术手段实现了真正的 AGI（通用人工智能）。这些技术到底有哪些区别和联系，下图作了横向对比，接下来我们详细剖析。

—1—

大语言模型（LLM）

大语言模型（LLM）是通过深度学习方法，利用庞大的文本数据集进行训练的机器学习模型，它具备生成自然流畅的语言文本以及准确理解语言文本深层语义的能力。大语言模型广泛应用于各种自然语言处理任务，包括但不限于文本分类、智能问答以及人机交互对话等，是 AI 领域的重要支柱之一。

过去的一年中，大语言模型及其在 AI 领域的应用受到了全球科技界的广泛关注。特别值得注意的是，这些大语言模型在规模上取得了显著的增长，参数量从最初的数十亿激增到如今惊人的万亿级别。这一飞跃性的增长不仅使得大语言模型在捕捉人类语言的微妙差异上更为精准，更让它能够深入洞察人类语言的复杂本质。

随着 DeepSeek V3 的发布，回顾过去的一年，大语言模型在多个方面取得了显著的进步，包括高效吸纳新知识、有效分解复杂任务以及图文精准对齐等。随着技术的不断演进和完善，大语言模型将继续拓展其应用边界，为人们带来更加智能化、个性化的服务体验，从而深刻改变我们的生活方式和生产模式。

大语言模型拥有推理能力，TA 是一切应用的基石。

—2—

检索增强生成（RAG）

RAG（Retrieval-Augmented Generation）技术是一种集成检索与生成双重能力的知识增强方案，旨在应对复杂多变的信息查询和生成挑战。在如今的大模型时代背景下，RAG 巧妙地引入外部数据源，比如：本地知识库或企业信息库，为 AI 大模型赋予了更强大的检索和生成实力，从而显著提升了信息查询和生成的品质。

RAG 技术的核心在于它将先进的向量数据库与大模型的智能问答能力进行了完美结合。知识库中的信息被精心存储在向量数据库中，当接收到用户的问题时，系统能够迅速从知识库中检索出相关的知识片段。随后，这些片段会与大模型的智慧相结合，共同孕育出精确而全面的回答。这种技术的运用极大地提高了 AI 系统在处理复杂问题时的准确性和响应速度，为用户带来了更加优质和高效的体验。

总之，RAG 技术就是给大语言模型新知识。

—3—

智能体（Agent）

在 AI 大模型时代，任何具备独立思考能力并能与环境进行交互的实体，都可以被抽象地描述为智能体（Agent）。这个英文词汇在 AI 领域被普遍采纳，用以指代那些能够自主活动的软件或硬件实体。在国内，我们习惯将其译为“智能体”，尽管过去也曾出现过“代理”、“代理者”或“智能主体”等译法。

智能体构建在大语言模型的推理能力基础上，对大语言模型的 Planning 规划的方案使用工具执行（Action） ,并对执行的过程进行观测（Observation）,保证任务的落地执行。

总之，Agent 智能体 = 大语言模型的推理能力 + 使用工具行动的能力。

—4—

MCP（Model Context Protocol）

MCP（模型上下文协议）是由 Anthropic 定义的一个开放协议，标准化应用程序如何为大语言模型（LLM）提供上下文。更具体地说，它试图标准化基于 LLM 的应用程序与其他环境集成的协议。

在 AI Agent 系统（Agentic Systems）中，上下文可以通过多种方式提供：

1、外部数据：这是长期记忆的一部分。

2、工具：系统与环境交互的能力。

3、动态提示词：可以作为系统提示词（System Prompt）的一部分注入。

第一、为什么要标准化？

目前，AI Agent 应用的开发流程很混乱：

1、有许多 AI Agent 框架存在细微差异。虽然看到生态系统蓬勃发展令人鼓舞，但这些细微差异很少能带来足够的价值，但可能会显著改变你的代码编写方式。

2、与外部数据源的集成通常是临时实现的，并且使用不同的协议，即使在组织内部也是如此。对于不同公司来说，这显然是如此。

3、工具在代码库中以略微不同的方式定义。如何将工具附加到增强型 LLM 上也是不同的。

目标是提高我们创新 AI Agent 应用的速度、安全性以及将相关数据带入上下文的便利性。

第二、MCP 架构设计

1、MCP Host：使用 LLM 为核心并希望通过 MCP 访问数据的程序。

2、MCP Client：与 MCP Server 保持1:1连接的客户端。

3、MCP Server：每个 MCP Server 都通过标准化的模型上下文协议公开特定功能的轻量级程序。

4、Local Data Sources：你计算机上的文件、数据库和服务，MCP Server 可以安全访问。

5、Remote Data Sources：通过互联网可用的外部系统（比如：通过 API），MCP Server 可以连接到这些系统。

—5—

Function Calling

Function Calling 是由 OpenAI 等公司推动的一种技术，它允许大语言模型（LLM）通过自然语言指令与外部工具和服务进行交互，从而将自然语言转换为具体的 API 调用。这一技术解决了大语言模型在训练完成后知识更新停滞的问题，使大模型能够获取实时信息，比如：当前的天气、股市收盘点数等。

第一、工作原理

Function Calling 的工作原理可以通过以下4个步骤来理解：

1、识别需求：大模型识别出用户的问题需要调用外部 API 来获取实时信息。比如：用户询问“今天北京的天气如何？”大模型会识别出这是一个关于实时天气的问题。

2、选择函数：大模型从可用的函数库中选择合适的函数。在这个例子中，大模型会选择 get_current_weather 函数。

3、准备参数：大模型准备调用函数所需的参数。例如：{ “location”: “北京”, “unit”: “celsius”}

3、调用函数：AI 应用使用这些参数调用实际的天气 API，获取北京的实时天气数据。

4、整合回答：大模型将获取的数据整合成一个完整的回答，比如：“根据最新数据，北京今天的天气晴朗，当前温度23°C，湿度45%，微风。今天的最高温度预计为26°C，最低温度为18°C。”

第二、对开发者的好处

对于开发者来说，使用 LLM 的 Function Calling 入门相对容易。开发者只需按照 API 的要求定义函数规格（通常是 JSON 格式），并将其随 Prompt 请求发送给大模型。大模型会根据需要调用这些函数，整个逻辑相当直观。因此，对于单一大模型、少量功能的简单应用，Function Calling 的实现非常直接，几乎可以“一键”将大模型输出对接到代码逻辑中。

第三、局限性

然而，Function Calling 也有一些局限性：

缺乏跨大模型的一致性：每个 LLM 供应商的接口格式略有差异，这使得开发者在支持多个大模型时需要为不同的 API 做适配，或者使用额外的框架来处理这些差异。

平台依赖性：Function Calling 通常依赖于特定的平台或框架，这限制了其在不同环境中的通用性。

扩展性有限：虽然 Function Calling 能够解决特定问题，但在面对更复杂的任务时，其扩展性可能会受到限制。开发者可能需要为每个新功能编写新的函数，并确保这些函数与模型的交互逻辑兼容。

第四、总结

Function Calling 是一种强大的工具，它为大语言模型提供了与外部工具和服务交互的能力，从而解决了大模型知识更新停滞的问题。然而，它的局限性在于缺乏跨模型的一致性和平台依赖性。尽管如此，Function Calling 仍然是一个重要的技术，尤其是在需要快速实现特定功能时。未来，随着技术的不断发展，我们期待看到更多能够克服这些局限性的解决方案。

—6—

知识库

对于企业而言，构建一个符合自身业务需求的知识库是至关重要的。通过RAG、微调等技术手段，我们可以将通用的大模型转变为对特定行业有着深度理解的“行业专家”，从而更好地服务于企业的具体业务需求。这样的知识库基本上适用于每个公司各行各业，包括：市场调研知识库、人力资源知识库、项目管理知识库、技术文档知识库、项目流程知识库、招标投标知识库等等。

知识库的技术架构分为两部分：

第一、离线的知识数据向量化