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

0. 结论先行

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

1. 背景

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

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

• 信息密度低：检索到的文档片段往往信息密度低且充满噪音。
• 结构化鸿沟：系统的Schema和配置规则是高度结构化的，而RAG提供的却是非结构化文本
• 知识更新滞后：系统能力不断更新，但向量库却难以实时同步，导致知识严重滞后。

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

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

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

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

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

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

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

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

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

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

• 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-shot Learning

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

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

• 常见的节点组合模式（如“条件判断→调用API→更新记录”）
• 如何正确填充复杂配置（如嵌套的filter和values）

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

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

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

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

4. 效果与启示

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

• ✅准确性提升：AI生成的工作流几乎不再出现非法节点或错误配置。
• 🔧可维护性增强：Prompt的维护从“手动更新文本”变为“管理结构化数据”。
• 🚀用户体验飞跃：非技术人员只需说一句话，系统就能生成合法工作流。

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

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

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

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