一文搞定 AI 智能体架构设计的九大核心技术 原创 精华

AI 智能体架构设计的9大核心技术包括：AI 智能体、Agentic AI、WorkFlow、RAG、Fine-tuning、Function Calling、MCP、A2A、AG-UI 等，下文详细剖析之。

1、AI 智能体架构的9大核心技术

AI 智能体架构设计核心技术一：AI 智能体

AI 智能体是一种具备自主意识的软件，它能够感知环境、进行逻辑推理和决策，并实施相应动作。

它可以被比作一位高效的个人助手，不仅能够执行命令，更重要的是能够理解任务的上下文、规划执行方案，并在遇到挑战时灵活地改变策略。

AI 智能体的核心在于其如何接收指令、执行任务并做出决策。以下是其关键组成部分：

1. Prompt（提示词）Prompt 是指导大语言模型（LLM）如何行动的指令，它定义了 LLM 可以使用的“工具”。Prompt 的输出是一个 JSON 对象，用于描述工作流程中的下一步操作，比如：“工具调用”或“函数调用”。
2. Switch 语句Switch 语句根据 LLM 返回的 JSON 内容决定后续操作。这是整个流程中的一个重要环节，用于解析 LLM 的输出并执行相应的动作。
3. 累积的上下文累积的上下文用于记录已执行的操作步骤及其运行结果。这一部分是 AI 智能体决策的重要依据，帮助其跟踪任务的进展。
4. For 循环For 循环是整个流程的驱动机制。它循环执行以下操作，直至 LLM 返回终止信号（比如：标记为“Terminal”的工具调用或自然语言响应）：将 switch 语句的执行结果加入上下文窗口，并让 LLM 决定下一步动作。

这种设计使得 AI 智能体能够高效地执行任务，同时具备灵活性和适应性。

AI 智能体架构设计核心技术二：Agentic AI

Agentic AI 开启了一种全新的架构范式。与传统的单体 AI 智能体架构不同，Agentic AI 系统架构由多个 AI 智能体组成，这些 AI 智能体能够相互协作，具备动态任务分解、持久记忆和高级任务编排等能力。这种架构使得系统能够处理更复杂的工作流程，并实现更高层次的协调。

如果将 AI 智能体比作独奏者，那么 Agentic AI 就像是一个交响乐团。在Agentic AI 系统中，每个 AI 智能体都有其独特的角色和能力，它们可以相互协作、共享信息，并根据任务需求动态调整策略。这种协作模式让系统能够应对那些超出单个 AI 智能体能力范围的复杂任务。

Agentic AI 的应用场景极为广泛且复杂。在医疗领域，它可以协调多个专业 AI系统进行综合诊断；在科学研究中，它可以组织多个研究助手进行协作调研；在机器人技术中，它可以指挥多个机器人协同工作。这些应用场景都要求系统具备高度的协调能力和动态适应性。

AI 智能体架构设计核心技术三：工作流（WorkFlow）

工作流 WorkFlow 其实很简单，就是把一项大任务拆成很多个小任务，然后按顺序一步一步完成，最后达成目标。

想象一下工厂里的流水线：一个大任务被分成很多个小步骤，每个步骤都有专人负责。比如，第一个人做完自己的部分，就把东西交给第二个人，第二个人接着做，就这样一直传下去，直到最后完成整个任务。这样一来，每个人都知道自己该做什么，效率和质量都能提高。

在一些特别需要准确性的场景里，如果让 AI 智能体自己决定任务怎么一步步做，可能会出错，甚至产生一些不靠谱的结果（我们叫它“幻觉”）。这时候，工作流就能派上用场了。我们可以提前把任务的步骤安排好，让 AI 智能体按照这个顺序来执行，这样就能减少出错的几率。

举个例子，假设我们有一个处理订单的 AI 智能体。当员工把订单信息录进去后，工作流就会自动开始检查库存。如果库存够，AI 智能体就直接安排发货；如果库存不够，它就先创建一个补货任务，通知采购部门赶紧补货，同时还会给客户发个消息，告诉他们大概什么时候能发货。

不过，工作流也不是万能的。如果设计得不好，比如步骤太多或者顺序乱了，任务处理起来就会很慢。所以，我们需要专业的人员（比如产品经理）来帮忙优化，把工作流梳理得更合理。

AI 智能体架构设计核心技术四：RAG（Retrieval-Augmented Generation）

RAG（检索增强生成）系统一直是企业里使用 AI 智能体最有用的技术之一。

RAG 最简单的架构设计实现方式如下所示：

预处理阶段：

1. 把整个知识库的文本资料分割成一个个小块，每个小块都是一段可以查询的文本。这些资料可能来自不同的地方，比如：公司内部的文档、PDF 报告等。
2. 用一个特殊的模型（嵌入模型）把这些文本块转换成一种特殊的代码（向量嵌入）。
3. 把这些代码存到一个特殊的数据库（向量数据库）里，同时保存每个向量对应的原始文本和指向向量的链接。

检索阶段：

1. 在向量数据库里，用同一个嵌入模型处理知识库中的文档内容和用户的问题，确保查询和知识库中的信息能够准确匹配。
2. 在向量数据库的索引上运行查询，选择要检索的向量数量，这决定了你将用多少上下文信息来回答查询。
3. 向量数据库会执行一个搜索，找到最相似的向量，然后把这些向量映射回它们对应的原始文本块。
4. 把问题和检索到的上下文文本块一起通过一个提示词传递给大语言模型，告诉模型只用这些上下文来回答这个问题。这并不意味着不需要设计好的提示词--你还需要确保模型返回的答案符合预期，比如：如果检索到的上下文中没有相关信息，就不要编造答案。

AI 智能体架构设计核心技术五：微调（Fine-tuning）

通用大模型已经很强大了，落地 AI 智能体应用时，我们还需要继续微调它，有以下5点需要微调的原因：

第一、大模型和人脑在处理信息时采用的策略有很大的不同。

第二、缺乏专有数据，比如：企业内部的私有数据。

第三、缺乏最新数据，比如：Qwen-3 的训练数据截止到2024年10月。

第四、预训练成本高，比如：DeepSeek R1 预训练成本为 500万美金。

第五、提升数据安全性，比如：企业私有数据是不能传递给第三方大模型的，基于开源大模型的微调才能满足业务的需求。

微调（Fine-tuning）分为全参数量微调和局部参数量微调，或者叫 PEFT 高效参数微调，PEFT 微调步骤如下：

第一步、数据工程，选择整理本次微调所需要的知识即任务数据集，以（Q，A）的问答对整理好，微调的数据量最好在 10K~100K 量级。

第二步、加载预训练大模型（比如：Qwen-3-32B）：选择一个与所需任务相关的预训练大模型，并加载其权重。

第三步、对大模型进行微调：将第一步任务数据集作为输入，以最小化大模型在此数据集上的损失函数。在这个过程中，通常需要在训练集和验证集上进行多次迭代，以避免过拟合问题。

基于以上步骤，详细总结如下：

AI 智能体架构设计核心技术六：函数调用（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 仍然是一个重要的技术，尤其是在需要快速实现特定功能时。未来，随着技术的不断发展，我们期待看到更多能够克服这些局限性的解决方案。

AI 智能体架构设计核心技术七：MCP（Model Context Protocol）

MCP（Model Context Protocol）是由 Anthropic 公司提出的一种协议，旨在解决不同大语言模型（LLM）与不同外部工具集成的标准化问题。通过MCP，开发者能够以一种统一的方式将各种数据源和工具连接到 AI 大模型，从而提升大模型的实用性和灵活性。

1目前，MCP 生态已经得到了广泛的支持，包括 Anthropic 的 Claude 系列、OpenAI 的 GPT 系列、Meta 的 Llama 系列、DeepSeek、阿里的通义系列以及 Anysphere 的 Cursor 等主流模型均已接入 MCP 生态。

第一、MCP 的架构设计

MCP 采用了客户端-服务器架构，主要包括以下几个核心组件：

1.MCP 主机（Hosts）

角色：这是需要访问数据的程序，例如Claude Desktop、各种IDE或AI工具。

功能：它们是MCP生态系统的入口点，负责向用户提供AI功能，并作为用户与AI模型之间的桥梁。

2.MCP 客户端（Clients）

角色：这些是协议客户端，负责维持与 MCP 服务器的1:1连接。

功能：它们处理通信细节，确保主机和服务器之间的数据传输顺畅，从而实现高效的数据交互。

3.MCP 服务器（Servers）

角色：这些是轻量级程序，每个服务器都通过标准化的 Model Context Protocol 暴露特定功能。

功能：服务器是 MCP 的核心，它们连接 AI 大模型与实际数据源，使模型能够访问和操作数据。

4.数据源

本地数据源：包括您计算机上的文件、数据库和服务，MCP 服务器可以安全地访问这些资源。

远程服务：通过互联网可用的外部系统（比如：通过 API），MCP 服务器可以连接这些系统，从而扩展模型的能力。

第二、MCP 的优势

统一性：MCP 提供了一个统一的协议标准，使得不同 AI 大模型能够以一致的方式连接到各种数据源和工具，从而避免了平台依赖性问题。

安全性：通过 MCP，数据的传输和访问过程更加安全，敏感数据可以保留在本地，无需全部上传到云端。

灵活性：MCP 支持多种数据源和工具的连接，无论是本地资源还是远程服务，都可以轻松集成到AI 应用中。

生态丰富：MCP 生态已经得到了广泛的支持，开发者可以利用现有的MCP服务器和工具，快速构建和部署AI应用。

第三、总结

MCP 通过其客户端-服务器架构和标准化的协议，为 AI 大模型与外部工具和数据源的集成提供了一个高效、安全且灵活的解决方案。它不仅解决了不同大模型与工具之间的兼容性问题，还为开发者提供了一个丰富的生态系统，使得AI应用的开发和部署变得更加简单和高效。

AI 智能体架构设计核心技术八：A2A（Agent2Agent）

第一、为什么会有 A2A？

现在越来越清楚，未来的 Agentic AI 将是多 AI 智能体的。而且，这些 AI 智能体会在彼此之间远程协作，每个 AI 智体都可能使用不同的 AI 智能体框架（比如：Spring AI Alibaba、LangGraph、AutoGen、CrewAI、Agent Development Kit 等）来实现。

这里面有3个固有的问题：

    1.不同框架实现的 AI 智能体系统之间，不支持系统状态的转移和交换。

    2.远程 AI 智能体之间也无法转移系统状态。

    3.离线的 AI 智能体不共享工具、上下文和内存（包括系统状态）。

第二、A2A 解决方案

A2A 是一个开放协议，它为 AI 智能体之间提供了一种标准方式，无论底层开发框架或供应商如何，都可以进行协作。

根据谷歌的官方文档： A2A 协议促进了“客户端”和“远程” AI 智能体之间的通信。

简单来说，“客户端” AI 智能体创建任务并与“远程” AI 智能体沟通，期望执行某些工作或返回数据。

第三、A2A 架构设计

    1.能力发现：所有实现 A2A 的 AI 智能体都通过“Agent Card”公开其能力目录。这有助于其他 AI 智能体发现给定 AI 智能体实现的潜在有用功能。

    2.任务管理：通信协议，时代短期和长期任务变得更容易。它帮助通信中的 AI 智能体保持同步，直到请求的任务完成并返回答案。这很重要，因为有些 AI 智能体可能需要很长时间来执行工作，而且目前没有统一标准如何等待这种情况发生。

    3.协作：AI 智能体可以相互发送消息以传达上下文、回复、工件或用户指令。

    4.用户体验协商：这是一个很有趣的功能。它允许协商数据返回的格式，以符合用户界面的期望（比如：图像、视频、文本等）。

通过 A2A 公开的 AI 智能体的发现是一个重要话题。谷歌建议使用统一的位置来存储组织的“Agent Card”。

比如：

https://<DOMAIN>/<agreed-path>/agent.json

这并不意外，因为谷歌将处于最佳位置，能够索引全球所有可用的 AI Agent，可能创建一个类似于当前搜索引擎索引的全球 AI Agent 目录。

我喜欢 A2A 强调无需重新发明轮子，并且建立在现有标准之上：

    1.该协议建立在现有、流行的标准之上，包括：HTTP、SSE、JSON-RPC，这意味着它更容易与企业日常使用的现有 IT 堆栈集成。

    2.默认安全 - A2A 旨在支持企业级身份验证和授权，与 OpenAPI 的身份验证方案相当。

AI 智能体架构设计核心技术九：AG-UI（Agent User Interaction Protocol）

随着 AI 智能体在企业中应用越来越广，AI 智能体在落地过程中，MCP 解决了 AI 智能体到 Tools 之间的通信标准，A2A 解决了 AI 智能体到 AI 智能体之间的通信标准。但是仍缺少一块：用户到 AI 智能体的通信协议。

AG-UI 协议横空出世，专为解决前端应用与 AI 智能体的通信交互而设计。

AG-UI 让你能够轻松地在网页、APP、应用程序或嵌入式设备中集成 AI 助手、AI 客服和智能问答 UI，避免了为每个应用程序重复开发基础功能的麻烦，也省去了处理交互逻辑的烦恼。

AG-UI 完善了 AI 协议栈，专注于构建 AI 智能体与用户前端之间的桥梁。它采用事件驱动的设计，定义了16种标准事件，并支持 SSE、WebSocket 和 Webhook 等传输方式，与 LangGraph、CrewAI 等框架兼容。

它就像是为你的前端安装了一个 AI “大脑”，无需绑定到特定的模型或框架，一套协议就能满足所有的交互需求。

第一、为什么需要 AG-UI？

每个 AI 智能体后端都有自己的工具调用、ReAct 样式规划、状态差异和输出格式机制。

如果你使用 LangGraph，前端将实现自定义的 WebSocket 逻辑、杂乱的 JSON 格式和特定于 LangGraph 的 UI 适配器。

但要迁移到 CrewAI/Dify 等，一切都必须进行调整，这样工作量大大增加。

第二、AG-UI 架构设计

AG-UI 使用一个轻量级、事件驱动的协议来连接 AI Agents 和前端应用程序，架构设计如图所示：

• Front-end：通过 AG-UI 进行通信的应用（聊天或任何启用 AI 应用） ；
• AI Agent A：前端可以直接连接的 AI Agent，无需通过代理；
• Secure Proxy：一个中介代理，安全地将前端的请求路由到多个 AI Agents；
• AI Agent B 和 C：由代理服务管理的 AI Agents。

第三、AG-UI 工作机制

AG-UI 的核心工作机制非常简洁而优雅，如下图所示：

• 客户端通过 POST 请求启动一次 AI 智能体会话；
• 随后建立一个 HTTP 流（可通过 SSE/WebSocket 等传输协议）用于实时监听事件；
• 每条事件都有类型和元信息（Metadata）；
• AI 智能体持续将事件流式推送给 UI；
• UI 端根据每条事件实时更新界面；
• 与此同时，UI 也可反向发送事件、上下文信息，供 AI 智能体使用。
  

AG-UI 不再是单向的信息流，而是一种真正的双向“心跳式”交互机制。AG-UI 就像 REST 是客户端到服务器请求的标准一样，AG-UI 将实时 AI 智能体更新流式传输回 UI 的标准。从技术上讲，AG-UI 使用服务器发送事件（SSE）将结构化 JSON 事件流式传输到前端。

本文转载自​​玄姐聊AGI​​  作者：玄姐