十二个月前，检索增强生成（RAG）是所有人都在汇聚的架构。这种模式已被充分理解，工具正在成熟，社区已经发展出足够的共享词汇，以至于新工程师在一周内就能在 RAG 管道中高效工作。当时感觉尘埃似乎已经落定。
然后它崩溃了。不是一下子，也不是对所有人，而是在生产系统所处的边缘——高查询量、对抗性用户输入、不配合分块边界的文档、需要多次检索才能完成的任务。这些失败是具体的且具有启发性。它们迫使该领域反思 RAG 是终点还是中途站点。
答案越来越倾向于后者。过去一年上演的从 RAG 到 AI 智能体的架构演变，是应用机器学习领域一个相当有趣的转折点——不是因为它提供了清晰的答案，而是因为它揭示了决定 AI 系统是否能在大规模下发挥真正作用的实际限制。这是对这一转变的技术性记述：什么崩溃了，什么取代了它，必须构建什么基础设施，以及仍然存在哪些差距。
我们的起点：RAG 作为默认架构
2025 年初的典型 RAG 架构是一个四组件系统。您使用类似 text-embedding-3-large 或开源等效模型的模型来嵌入您的文档。您将这些嵌入存储在向量数据库中——根据您的托管偏好和预算，可以选择 Pinecone、Weaviate、Chroma 或 Qdrant。在查询时，您嵌入用户的问题，检索最相似的 top-k 个分块，然后将它们与指令和原始查询一起放入提示中。LLM 从该上下文中综合生成答案。
该管道足以支撑一波有意义的生产部署。企业知识库、内部文档搜索、客户支持副驾驶和研究工具都基于 RAG 基础推出。这种模式具有真正的优势：它是可解释的，在检索层是可调试的，并且为团队提供了一种将 LLM 输出锚定在特定源材料中的方法，而不是仅仅依赖模型知识。
工具生态系统强化了这种融合。LangChain 和 LlamaIndex 提供了高级抽象，能够用几百行代码构建一个 RAG 管道。向量数据库提供了托管层，消除了基础设施开销。OpenAI 的嵌入 API 足够稳定和便宜，可以处理大型文档集而不会超出预算。这种组合催生了大量基于 RAG 的原型，其发布速度超出了任何人的预期。
到 2025 年中期，RAG 已成为”如何利用我们的专有数据构建 AI 功能”的默认答案。这种共识既有其合理性，也有其 premature 的一面。
大规模应用中的问题
朴素 RAG 管道的局限性并非理论上的——它们来自生产遥测数据、用户反馈，以及当系统处理来自数百万真实用户的查询时才会出现的对抗性边缘情况，这些用户的行为与评估集并不一致。
检索质量存在硬性上限。当查询模糊、领域特定或需要跨多个概念综合时，基于密集向量的余弦相似度是一种出奇粗糙的工具。Top-k 检索返回在词汇或语义上最接近的块——但它并不理解查询实际在询问什么。用户询问”上一季度的退款政策有什么变化”，这是一个时间性、比较性的问题，而扁平的相似度搜索无法在一次检索中回答。系统检索最新的政策文档和最突出提及”退款”的块。它不会检索之前的版本。它无法进行比较。它自信地给出了不完整的信息。
上下文窗口管理成为真正的工程问题。针对检索质量差的简单答案是”检索更多块”。随着检索 k 值从 5 增加到 20 再到 50，上下文窗口急剧膨胀，延迟增加，成本上升，而且关键的是，LLM 在长上下文推理方面的性能以基准测试未预测的方式下降。”迷失在中间”的现象（模型系统性地降低放置在长上下文中间信息的权重）意味着更大的检索不会线性提高答案质量。通常情况下，它反而会降低质量。
幻觉在检索过程中依然存在。RAG 背后的直觉——将模型基于检索到的事实进行锚定可以减少捏造——在简单情况下成立，但在复杂情况下失败。当检索到的块部分相关时，模型会发明出桥接逻辑。当多个检索到的块相互矛盾时，模型通常通过编造一个一致的叙述来解决矛盾，而不是揭示这种不一致。检索减少了事实回忆中的幻觉；但在推理任务中并未消除幻觉。
单次检索无法处理多跳问题。 相当一部分生产环境中的查询需要从多个文档中获取信息，进行跨时间比较，或通过中间步骤进行综合。”我们哪些企业客户没有续费并且在过去30天内提交了支持工单？”这个问题需要至少连接两个数据源，应用日期过滤器，并推理缺席情况——而不仅仅是存在情况。平面RAG回答了可以从单个块中解决的问题。其他所有问题都无法解决。
填补差距的中间模式
该领域并没有直接从简单RAG跳转到完整代理架构。一系列中间模式出现，它们扩展了基础流程，但没有完全取代它。这些模式值得被命名，因为当今许多生产系统仍基于它们构建——它们并未过时，但有其局限性。
代理式RAG在检索前引入了查询规划步骤。模型不是直接嵌入用户查询，而是先将查询分解为子问题，分别检索每个子问题，然后综合结果。这解决了多跳失败问题，并显著提高了复杂查询的答案质量。它还引入了首次有意义的延迟和成本放大：单个用户查询现在会在产生答案前触发三到五次LLM调用。
混合检索结合了密集向量搜索与稀疏关键词匹配（BM25及其变体），然后使用交叉编码器对合并结果进行重排序。这提高了特定领域查询的检索精度，其中精确术语很重要。它增加了操作复杂性——需要维护两个检索系统、调整重排序器以及校准合并策略——但对于许多团队而言，技术文档和法律文本上的质量提升足以证明这种开销是合理的。
工具增强生成将检索范围扩展到向量存储之外。团队不再将”检索”等同于”对嵌入文档进行语义搜索”，而是开始让模型访问结构化工具：SQL查询执行、API调用、日历查找、计算器函数。正是在这一点上，架构开始看起来不那么像信息检索系统，而更像一个代理——模型根据查询选择调用哪个工具，而不仅仅是从固定语料库中检索。
多步推理链将复杂任务需要多次调用大语言模型并在其间传递中间状态这一想法形式化。思维链提示、从最少到最多提示以及 ReAct 等结构化推理格式为团队提供了模式，使中间推理变得明确且可审计。这些推理链在很大程度上仍然是线性的——一个步骤的输出作为下一个步骤的输入——但它们确立了跨多步推理作为一流设计原则的架构概念。
当前代理架构栈
当前生产级代理架构并非单一框架或供应商产品——它是一种分层模式，由团队从组件组装而成。理解这些层次比了解哪些特定库实现了它们更有用，因为库生态仍然不稳定。
规划层。 系统接收目标或查询，并将其分解为一系列操作。这可能是专门的规划模型调用、逐步计划的结构化提示，或规划与执行交织的 ReAct 循环。规划层决定需要做什么；它不执行操作。
工具使用层。 代理可以访问一组定义好的工具——它可以调用的函数、可以调用的 API、可以查询的数据库。这里的关键设计决策是工具范围：狭窄的工具集更容易测试和推理；广泛的工具集增强了能力但放大了错误的波及范围。在生产系统中，有效的系统往往有 5-15 个文档完善的工具，而不是 40 个定义松散的工具。模型上下文协议 (MCP) 和新兴的代理间 (A2A) 标准正在尝试标准化工具的描述和调用方式，这对跨团队和供应商的可组合性很重要。
记忆层。 跨代理运行的状态持久化在传统软件中是已解决的问题，而在代理系统中则是未解决的问题。工作记忆（当前上下文窗口）对每个代理都可用。情景记忆——代理在先前会话中所做事情的记录——需要明确持久化基础设施。语义记忆——从多次运行中提炼的理解——是一个活跃的研究和工程问题。当今大多数生产代理具有工作记忆和基本的情景日志；更高层次的记忆在很大程度上仍然是理想化的。
评估循环。 生产环境中的代理需要一种机制来检查其输出是否符合目标，然后再将其返回给用户。这可能是一个自我批判提示、一个独立的评估模型、针对预期结构进行确定性测试，或它们的组合。评估循环是将一次性 LLM 调用与值得称为”代理”的系统区分开来的关键——该系统具有反馈机制，可以触发重新规划、额外的工具调用或拒绝并重试。
这四个层次——规划、工具使用、记忆和评估——构成了当前代理架构的结构骨架。RAG 并不会从这个技术栈中消失；它变成了工具使用层中的一个工具，当任务需要从非结构化文档中检索时，由规划器调用。
必须构建的基础设施
从 RAG 管道转向代理堆栈不仅仅是架构上的改变。它需要基础设施，而这些基础设施在第一代 RAG 系统发布时并不以成熟形式存在。低估了这些成本的团队都有相应的惨痛教训。
评估框架。 如何测试代理是否正确完成了多步骤任务？当输出是生成式内容时，针对固定输出的单元测试不再适用。评估必须从确定性断言演变为 LLM 作为评估者的方法、人类偏好标注以及按用例定义的任务完成指标。LangSmith、Braintrust 和 Promptfoo 等工具应运而生以填补这一空白，但该领域尚未形成统一标准，而构建严肃代理系统的团队仍在花费大量工程时间开发自定义评估工具。
多步骤执行的可见性。 RAG 管道有三个可观察的阶段：检索查询、检索到的块和生成的响应。一次代理运行可能涉及 15 次工具调用、8 次模型推理、中间状态对象，以及基于中间结果做出的分支决策。追踪这种执行过程——构建一个清晰的时间线，说明发生了什么以及为什么发生——需要新的可见性基础构件。基于 OpenTelemetry 的追踪被适配用于 LMS 跨度，供应商特定的代理运行仪表板，以及将工具输入和输出与模型输入和输出分开记录的日志模式，这些都需要早期从业者从零开始设计，然后才由供应商将其产品化。
多步骤链的成本管理。 单次代理运行可以多次调用同一模型，在不同成本层级的模型之间切换，并累积随每个步骤增长上下文。如果在运行层面缺乏成本控制——对每项任务的总代币支出设置硬性限制、为简单步骤选择成本更低模型的路由逻辑、丢弃低价值历史的上下文修剪策略——成本会以破坏单位经济性的方式累积。这并非整个行业已解决的问题；它是工具开发的一个活跃领域。
重试和容错模式。 工具调用会失败，API 会返回意外响应，模型偶尔会拒绝遵循结构化输出格式。生产环境中的代理需要优雅降级——能够重试失败的工具调用，在复杂方法失败时回退到更简单的方法，并向用户显示有意义的错误信息，而不是静默返回错误答案。这些模式存在于分布式系统工程中；将它们适应到 LLM 驱动的执行流程中需要新的库级别抽象，而这些抽象现在才趋于稳定。
仍缺失的部分
从 RAG 到 AI 代理的架构演进是真实且实质性的，但当前状态并非已解决并移交给运维团队的问题。仍存在几个关键差距。
CI/CD 中的可靠代理测试。 作为部署流程的一部分运行代理评估套件，需要足够确定性的行为来编写有意义的回归测试，足够快的执行速度以适应 CI 窗口，以及足够便宜的推理成本以在每个拉取请求上运行。如今这些条件都无法可靠满足。团队正在做出权衡——使用更小的评估集、缓存模型响应以提高速度、定期运行评估而非每次提交都运行——但结果是，代理系统的回归测试显著弱于其所部署的其他软件。
标准化的代理协议。 MCP 已获得关注，成为一种以可移植格式描述工具的方式。新兴的 A2A 协议解决了代理如何委派给其他代理的问题。但采用是碎片化的，实现与规范存在分歧，跨代理通信的安全模型尚不成熟。今天构建代理的开发者不能假设由另一个团队构建的工具服务器或供应商提供的代理服务能够无需大量集成工作就能互操作。
生产环境调试。 当代理运行产生错误答案或无法完成任务时，追溯原因仍然非常困难。执行轨迹理论上存在，但目前没有任何平台能够提供软件工程师期望的调试器质量水平，来导航包含30个步骤的代理轨迹、识别推理出现偏差的决策点，以及理解不同的工具调用会产生什么结果。代理故障的事后分析仍然主要依赖人工。
长期可靠性。 运行数分钟或数小时的代理——如安排一周的任务、管理持续的研究项目、执行多日工作流——面临着短期代理不会遇到上下文窗口限制、状态管理复杂性和模型一致性问题。持久化、长期运行代理的架构仍在激烈争论中，远未稳定。
何时使用RAG、代理或混合方法
为构建AI驱动产品的团队提出的实际问题不是”哪个更好？”，而是”哪个适合这个特定问题？”决策框架比架构争论更有用。
使用RAG 当任务主要是信息检索和综合，查询可以通过一次检索或少量独立检索完成，文档语料库是主要知识来源，且可接受的延迟低于两秒时。知识库、文档搜索、内容摘要和单文档问答是很好的应用场景。与代理方案相比，RAG的流程更简单、成本更低且更易于调试。
使用代理 当任务需要在现实世界中采取行动（不仅仅是回答问题），解决方案涉及多个步骤（后续步骤依赖前序结果），输入需要判断调用哪些工具及调用顺序，或任务有可验证的成功标准供系统评估时。代码生成与执行、多系统数据集成、工作流自动化以及需要跨来源比较信息的任务非常适合代理架构。
使用混合方法——这是最常见的生产模式——当检索是系统所需多种能力之一，但不是唯一能力时。能够调用向量搜索工具、SQL执行器、网络搜索API和代码解释器的代理是一个混合系统，其中RAG是组件而非架构。超过一定复杂度阈值的大多数严肃生产AI系统正趋向于这种混合模型：代理负责协调，RAG是其协调使用的工具之一。
能够做出最佳架构决策的团队，是从精确的任务陈述开始的，明确哪些步骤需要检索、哪些需要行动、哪些需要推理，然后选择能够可靠处理这些步骤的最简单架构。为 RAG 已经能充分解决的问题增加代理复杂性，是一种没有面向用户回报的工程成本。
处于转型中的领域
对 2026 年初 AI 应用架构状况的诚实描述是：正处于转型中期。方向是明确的：朝着拥有更丰富内存、更强大规划和更好评估循环的代理栈发展。但大多数团队还无法可靠地到达目的地。
RAG 并未过时。它是大量 AI 应用用例的正确工具，而且现在已经足够成熟，团队可以将其作为成熟模式部署，而不必将其视为研究。朴素 RAG 能实现的上限已被充分理解；解决方法已有详细文档；工具链也已稳定。
代理架构是真实存在的，在特定领域中，它们能产生 RAG 管道无法实现的结果。但它们带来了可观测性、评估、成本管理和调试方面的基础设施成本，许多团队系统性地低估了这些成本。几乎所有成功应用代理的团队，在宣布其代理生产就绪之前，都已在周围基础设施上进行了大量投资。
未来 12 个月的发展，将更多地取决于工具层的成熟，而非新模型的能力：更好的评估框架、稳定的代理协议、生产级调试工具，以及使多步链在经济上大规模可行的成本管理。架构已经勾勒出来，基础设施仍在构建中。