agentic-ai llm rag architecture observability

智能代理AI的完整技术栈，逐层解析：从前端到可观测性。

生产代理背后的十层结构：前端、数据摄取、分块处理、嵌入模型、向量搜索、检索、提示工程、大语言模型、部署与评估。

发布者：REACTAPP.TOP加入本站 2026年10月28日阅读约 11 分钟2433 词

来源: The Full Stack of Agentic AI: From User Interface to Production-Grade Intelligence

人工智能早已超越了人们只需输入提示词就能获得回复的阶段。现代人工智能产品都是完整的软件系统，它们能够处理文档，将杂乱无序的信息转化为可用的知识，生成嵌入向量，检索上下文，与大型语言模型交互，运行各类工具，运行在云基础设施中，并持续监控自身的性能。对于代理型人工智能而言更是如此。代理并非被困在聊天窗口中的大型语言模型，一款商用级的代理应用需要围绕模型构建整套技术栈，而模型仅仅是其中的一层而已。

该技术栈的参考架构图为整个流程提供了清晰的映射，涵盖了从前端开始，经过数据摄取、检索与提示，再到模型应用、部署及监控的各个环节。以下内容将逐一介绍每一层的作用、存在原因以及各工具之间的协同方式。

各层概览

该技术栈的运行顺序为：前端、文档采集、分块与预处理、嵌入模型、向量数据库、检索、提示工程、大语言模型、基础设施与部署，最后是可观测性与评估。

这一顺序并非严格的流程链。在真正的智能体系统中，各组件会持续交互。一个智能体在生成最终结果之前，可能会多次检索信息、调用外部工具、使用不同模型、对自己的答案进行评分，并触发进一步的流程。因此，将这一技术栈视为围绕智能技术的生态系统，比视为简单的请求-响应链更为恰当。

第1层：前端

每个人工智能系统都需要一个供人们与之交互的界面。前端负责呈现用户体验，无论是聊天机器人、企业门户、分析仪表板、内部工具还是人工智能辅助的工作空间。常见的技术选择包括React、Next.js、Streamlit和Azure App Service。React用于构建交互式界面，而Next.js则是用于开发生产级网页应用的更完善的框架。Streamlit便于在无需传统前端工具链的情况下快速搭建人工智能和数据应用。Azure App Service则为网页应用和API提供托管服务。

在企业的智能代理架构中，前端不仅仅是一个聊天框。它还可以显示代理的处理进度、获取的数据来源、工作流状态、工具处理结果、审批请求、生成的文档以及人工干预的交互内容。正是在这里，企业用户能够方便地使用人工智能功能。

第二层：文档采集

一个高效的系统需要能够获取相关信息，而企业知识很少以整齐统一的格式存在。它们分散在PDF文件、Word文档、幻灯片、扫描件、网页、数据库、电子邮件等各种载体中。文档采集功能就是从这些来源中收集并提取内容。

用于此功能的工具包括Azure AI Content Understanding、Apache Tika、Microsoft Fabric、LangChain以及OCR引擎。当信息存储在扫描件或图片中时，OCR就显得非常重要。Apache Tika能够从多种格式中提取文本和元数据。Microsoft Fabric则有助于构建更完善的企业数据工作流，而像LangChain这样的框架则可以将文档采集组件集成到人工智能处理流程中。

目标很简单：将分散的企业信息转化为机器能够处理的内容。如果没有可靠的输入层，即便是最先进的模型也难以针对您的组织提供有意义的答案。

第三层：分块与预处理

仅提取文本只是第一步。一份200页的文档无法完整地放入每个模型请求中，因此大型文档必须被拆分成更小、更有意义的单元。这些单元可以是段落、章节、页面或语义单元，LangChain及类似框架提供了多种分块策略。

良好的分块方式并不仅仅是每隔几百个字符就切分一次，因为错误的分块会破坏上下文关联。当定义与赋予其意义的解释被分开时，检索结果可能会不完整。过大的分块会导致检索精度下降，而过小的分块则会丢失重要的关联信息。因此，分块策略会直接影响后续所有处理的质量。

预处理包括清洗数据、去除不必要的内容、规范格式、提取元数据、识别文档结构，以及为分块添加额外信息。检索效果的优劣往往就在这一阶段决定。

第4层：嵌入模型

在文档被分块之后，系统需要一种方法来捕捉其含义。嵌入模型可将文本转换为数值向量，这样具有相似概念的文本在嵌入空间中就会彼此靠近。

将“重置员工密码”的请求与“如何更改工作登录信息”的请求进行比较。虽然表述不同，但意图相近，优秀的嵌入模型能够识别这一点。该层所提供的服务包括OpenAI、Cohere以及基于Azure的AI服务。由此生成的向量是语义搜索和检索的基础，这也使得它成为整个技术架构中最重要的变革之一：人类语言被转化为数学表示形式，而这种表示形式则用于判断语义相似性。

第5层：向量数据库

嵌入向量必须存储在能够支持快速相似性搜索的系统中，而这正是向量数据库的职责。图表中列出了Milvus、FAISS、Azure AI Search、Azure Cosmos DB以及Azure Database for PostgreSQL。这些系统在功能与部署模式上存在很大差异，但都致力于通过语义相似性实现高效检索。

当用户提出问题时，该查询会被转换为嵌入向量，系统随后会寻找最接近的向量。匹配到的内容片段会被传递给后续的层。这正是大多数检索增强生成系统的基础。

第6层：检索层

向量数据库用于存储信息，但检索层负责决定最终向模型展示哪些内容。这一区别很容易被忽视。检索可以利用语义相似度、关键词搜索、元数据过滤、混合搜索、重新排序等技术，而Azure AI Search、LangChain和LlamaIndex等工具则可实现这些功能。

成熟的方案会结合多种策略。语义搜索用于查找概念上相关的资料，而关键词搜索则能确保不会遗漏精确的标识符、产品名称、政策编号或技术术语。这就是混合检索方式，企业级RAG系统还会逐步加入元数据过滤、重新排序、知识图谱等其他机制。

其目标并非检索尽可能多的信息，而是获取正确的信息。

第7层：提示工程

在完成信息检索后，系统还需为语言模型生成恰当的指令。一个实用的提示远不止是用户的提问，它还可以包含系统指令、检索到的上下文、对话历史、业务规则、输出格式要求、安全约束、示例、工具定义以及元数据。LangChain、Promptify和DSPy都是有助于构建和优化这类提示的工具示例。

提示词工程也正在超越手工编写巧妙措辞的阶段。人们的关注点转向了上下文工程，它提出了一个更广泛的问题：模型应该在工作流的哪个环节、以何种结构接收信息？对于那些可能需要从先前的操作、检索到的资料、工具输出以及中间结果中动态构建上下文的智能体而言，这一点尤为重要。

第8层：大语言模型

处于核心位置的是大语言模型，语言理解、推理、生成以及指令遵循等功能都在这里实现。文中提到的平台与模型包括Azure、OpenAI、LLaMA和Mistral AI。模型会收到请求，以及经过精心准备的上下文和指令。

有一个原则值得重申：大语言模型并非整个应用程序。它只是更大系统中的一个组件，而实际的生产级应用还需要配套检索、调度、安全保障、评估、监控、基础设施以及业务逻辑。从原型阶段发展到企业级生产环境时，这一点尤为明显。

从大语言模型应用到智能代理

将传统的大语言模型应用与智能代理应用区分开来很有帮助。普通应用的处理流程是用户输入、提示词、大语言模型生成响应；而基于检索增强生成的应用流程则是用户输入、信息检索、上下文构建、大语言模型生成响应。智能代理系统则更为动态，其流程包括用户指令、智能代理、计划制定、信息检索、工具调用、大语言模型生成响应、效果评估、后续行动以及最终响应。智能代理能够自主决定下一步该做什么，而不会仅仅遵循固定的流程顺序。

假设有人询问为何昨天的生产流程会出故障以及应如何处理。系统代理可以调取执行历史记录、检查日志、查询数据库、分析错误信息、参考运营规范，从而确定可能的根本原因，并提出或执行经过验证的修复方案。这与单纯生成一段文字有着本质区别。

第9层：基础设施与部署

仅仅拥有一个完善的原型并不足以让产品具备上线条件。要实现正式部署，就需要具备可扩展的基础设施、网络系统、安全保障、部署自动化功能、资源管理机制以及高可用性。相关的架构技术包括Azure Container Apps、Azure Kubernetes Service、Docker和Kubernetes。

Docker将应用程序打包为可移植的容器。Kubernetes则负责在分布式环境中协调这些容器化的任务。Azure Kubernetes Service是一种托管型的Kubernetes服务，而Azure Container Apps则简化了容器的部署流程，无需用户自行管理整个Kubernetes环境。

当系统需要应对大量用户访问、众多并发任务、模型推理负载、后台处理、文档处理流程、长时间运行的任务、外部工具集成以及企业级安全要求时，这一层就显得尤为重要。模型可能非常出色，但基础设施决定了这种出色性能能否在大规模环境中稳定地展现出来。

第10层：可观测性与评估

可观测性是人工智能工程中最常被忽视的方面之一。传统应用可以通过CPU使用率、内存占用、延迟、错误率和请求频率来监控。而人工智能应用则需要更多信息——团队必须了解模型接收了什么数据、检索到了什么内容、使用了哪些工具、做出了何种决策、每一步的耗时、token数量，以及最终答案是否有效。

Azure AI Foundry、OpenTelemetry和Grafana在此发挥了作用。OpenTelemetry负责收集分布式应用中的各类遥测数据，而Grafana则用于可视化操作层面和应用层面的指标。

评估是另一个重要维度。生产系统可能需要针对相关性、合理性、幻觉现象、检索质量、延迟、成本、安全性以及用户满意度等指标给出评分。对于智能体而言，标准更高，因为不仅最终回复需要评分，其执行动作也同样需要评估：

它是否选择了正确的工具？
它获取到正确的信息了吗？
它进行了不必要的工具调用吗？
它遵循了正确的工作流程吗？
任务完成后它会停止运行吗？
需要人工干预时它是否妥善升级处理了？

这些问题使得可观测性与评估成为生产环境中的 AI 工作不可或缺的部分。

为何整个技术栈至关重要

有一种常见的误解认为，构建 AI 应用只需选择一款强大的大语言模型并加上用户界面即可。这种方式或许适用于演示，但很难体现企业级 AI 平台的实际需求。

假设有一名员工向助手咨询公司针对某特定客户问题的处理政策。系统必须理解该请求，找到相应的政策文件，提取相关部分，将其提供给模型，生成有依据的答案，必要时注明来源，同时执行安全策略，监控交互过程并判断回复是否有用。每一层都发挥着作用：前端负责交互，数据摄取负责提供知识，预处理使其可用，嵌入模型捕捉含义，向量数据库存储可检索的表示形式，检索功能定位上下文，提示词负责结构化内容，大语言模型负责生成答案，基础设施保障规模与可靠性，而可观测性则提供透明度与责任追溯。从这个意义上说，现代人工智能是全栈式的。

选择工具

参考架构中的技术并非必须全部采用的清单。每项技术都是对应层级的可选方案。某家公司可能会首先选择 React 和 Next.js，用 Azure AI Content Understanding 处理文档，用 LangChain 进行协调，搭配托管的嵌入模型，用 Azure AI Search 进行检索，再通过 Azure 上的模型以及 Azure Container Apps 来运行整个系统；而另一家公司则可能选择完全不同的技术组合。

最重要的一点是：架构先于工具。业务需求决定了架构，架构又明确了各层级所需的功能，只有在此之后才应选择具体的技术。

不仅仅是大语言模型

全栈视角也能解释为何代理型项目会迅速变得复杂。一个代理可能需要通过RAG获取企业知识、从数据库中获取结构化数据、通过API获取外部信息、借助工具具备操作能力，还要依靠编排系统来执行工作流程。它还需要相应的保障机制：身份认证与授权、数据隐私控制、防止提示注入的措施、工具权限设置、人工审批流程、审计追踪以及评估框架。

因此，代理型AI处于多个学科的交汇点：软件工程、数据工程、AI工程、云工程、安全与可观测性。构建生产级代理是一项工程挑战，而不仅仅是编写提示语的练习。

应用架构的演变

该行业已经经历了多个发展阶段。早期的AI应用以模型为中心，随后RAG技术将模型与外部知识相连，工具增强型系统则让模型能够与外部功能交互。如今，代理型AI整合了模型、检索、工具、记忆、规划、协调和评估等功能。其发展路径从单纯的LLM，到RAG，再到工具使用，进而发展为代理和多代理系统；随着发展深入，配套的基础设施变得越来越重要。

从何处开始

并非每个应用都需要完整的技术栈。一个简单的问答工具使用基础的大语言模型就足够了。如果应用需要私有数据或频繁变动的知识，可以加入RAG技术。当实体间的关系是问题的核心时，可以考虑基于图的检索方式。而当系统需要规划任务、选择工具、执行多步骤操作并实时做出决策时，代理型人工智能则是更合适的选择。

目标不应是构建最复杂的架构，而应是找到能够可靠解决问题的最简单方案。

下一步是什么

这一领域仍在不断发展。知识图谱、向量数据库、智能体框架、工作流引擎、多模态模型、评估工具以及云平台很可能会越来越紧密地结合在一起。应用程序除了处理文本外，还将处理图像、音频、视频、结构化数据、企业系统以及现实世界中的工作流。监控和评估系统的重要性将与选择模型同等重要。未来的发展重点不再仅仅是更智能的模型，而是围绕这些模型构建的可靠系统。

核心要点

代理型人工智能并非单一技术，而是一整套完整的解决方案。从用户交互的前端，到数据摄取与预处理、嵌入向量及向量数据库、检索与提示工程，再到大语言模型、部署与监控，每一层都在塑造系统最终展现的智能水平。大语言模型仅是其中的一部分。一个具备生产级能力的代理系统需要合适的数据、检索策略、编排机制、基础设施以及评估体系。模型本身的能力远不如其周边系统的设计质量重要。