当 RAG 失效时, 我们该如何让 AI 真正“理解”企业系统?

RAG曾是企业构建智能问答系统的“黄金方案”，但在复杂业务场景中，它的边界正在显现。本文将从RAG的失效机制出发，探讨如何通过Agent化、语义建模与系统协同，让AI真正“理解”企业系统，走出知识调用的浅层困境。

0.结论先行

从“检索即答案”到“上下文工程”：重新定义企业级AI的交互范式

1.背景

在最近落地企业级智能体的过程中，我越来越清晰地意识到一个问题：我们不能指望一个通用大模型，仅凭几段检索到的文本，就能让AI准确理解一个复杂、动态的企业系统。

我曾寄希望于RAG（检索增强生成）来帮助AI理解企业的一切数字资产。但现实是残酷的：

信息密度低：检索到的文档片段往往信息密度低且充满噪音。

结构化鸿沟：系统的Schema和配置规则是高度结构化的，而RAG提供的却是非结构化文本

知识更新滞后：系统能力不断更新，但向量库却难以实时同步，导致知识严重滞后。

结果就是：AI一本正经地胡说八道，这对于容错率极低的企业级AI应用来说是致命的。

2.RAG已死？拥抱上下文工程

最近，Chroma的创始人JeffHuber抛出观点：“RAGisdead”。这并非否定检索本身，而是宣告简单拼接文本的RAG范式已经走到尽头。他提出的替代方案是上下文工程（ContextEngineering）。

这让我开始思考：我们是否可以绕过RAG，直接为AI构建一个精确、动态提示词？

于是，我尝试了一个新思路：构建一个AI配置中心。

3.从“喂文档”到“建沙盒”

我的目标很明确：实现一句话生成工作流（NL2Workflow），让非技术人员也能通过自然语言指令，生成合法、可执行的工作流。

为此，我们设计了一个核心系统——AI配置中心。它不是另一个知识库，而是一个上下文工程引擎，其核心思想是：不要让AI去理解杂乱的文档，而是为它提供一份清晰的“能力说明书”和“操作手册”。

3.1.能力说明书：结构化、清晰

我不再将原始配置文件扔进向量库，而是将其解析为一系列结构化的RESTfulAPI：

GET/api/ai-config/triggers→获取所有触发器类型

GET/api/ai-config/nodes→获取所有节点类型及其配置Schema

GET/api/ai-config/examples→获取精选的高质量工作流示例

这些API返回的不是自然语言描述，而是机器可读、带约束的元数据。例如，request节点的method字段只能是GET,POST,PUT…，且url为必填。

这相当于给AI一本“白名单手册”，从根本上杜绝了幻觉。

3.2.操作手册：Few-shotLearning

我没有让AI从海量历史工作流中“找相似”，而是手动维护2-3个高质量的范例，作为Few-shotLearning的模板。

这些范例不是为了“模仿”，而是为了教会AI：

常见的节点组合模式（如“条件判断→调用API→更新记录”）

如何正确填充复杂配置（如嵌套的filter和values）

3.3.上下文工程：动态注入，实时同步

我使用模板引擎（如Mustache），在运行时将上述元数据动态注入到Prompt中，生成最终的上下文。

更重要的是：当n8n平台新增一个节点时，AI配置中心会自动感知并更新API，下一次Prompt生成时，AI就“知道”了这个新能力。

这解决了知识更新的滞后性，实现了系统与AI的“共生演进”。

4.效果与启示

通过这套“AI配置中心+上下文工程”的方案，我们实现了：

准确性提升：AI生成的工作流几乎不再出现非法节点或错误配置。

可维护性增强：Prompt的维护从“手动更新文本”变为“管理结构化数据”。

用户体验飞跃：非技术人员只需说一句话，系统就能生成合法工作流。

5.结语：从“AI友好”到“工程友好”

这场实践让我深刻体会到：企业级AI落地，不是比拼谁的模型更大，而是比拼谁的“上下文工程”做得更好。

未来的AI系统，不应是“黑箱猜测”，而应是“白箱协作”。我们需要的不是更多文档，而是一个为AI量身打造的、动态的、可编程的认知基础设施。

也许，这正是JeffHuber所说的“RAG之后”的下一个篇章。