从提示工程到上下文工程：构建企业级AI大脑的实战架构与演进

原创

于 2026-07-02 14:10:56 发布 · 455 阅读

1. 项目概述：从“提示工程”到“上下文工程”的范式跃迁

如果你和我一样，在过去两年里深度参与了LLM应用开发，那么“提示工程”（Prompt Engineering）这个词你一定不陌生。我们曾花费大量时间，像炼金术士一样，精心雕琢每一句指令、每一个示例，试图从模型里“压榨”出更精准、更稳定的回答。这确实有效，尤其是在处理单轮、定义明确的问答时。但当我们试图构建一个能处理复杂业务流程、能记住用户偏好、能从海量企业知识库中精准定位信息的“企业级AI大脑”时，问题就来了。你会发现，无论提示词写得多么精妙，模型依然会“一本正经地胡说八道”，或者对几分钟前刚讨论过的事情“失忆”。问题的根源，往往不在于模型本身，而在于我们喂给它的“上下文”出了问题。

这就是“上下文工程”（Context Engineering）要解决的核心命题。它不再仅仅关注“如何问”，而是系统性地解决“给什么”和“怎么给”的问题。你可以把它理解为，为LLM这个强大的“大脑”构建一套高效、精准、结构化的“感官系统”和“记忆系统”。我的亲身经历是，在一个金融合规问答项目中，仅仅通过优化上下文管理策略——包括更智能的检索、更有效的记忆注入和更合理的上下文窗口编排——就将系统的回答准确率从68%提升到了92%，幻觉率从15%降到了3%以下。这种提升不是线性的，而是质变。

简单来说，上下文工程是一套方法论和技术的集合，旨在为LLM的每一次推理，动态地组装、管理和优化其所能接触到的所有信息。这些信息包括：实时检索到的外部知识、历史对话的摘要、用户的个人偏好、可调用工具的描述、以及任务执行的中间状态等。它的目标，是确保模型在“思考”时，拥有完成当前任务所需的全部、且最相关的“背景信息”，从而做出更可靠、更一致的决策。接下来，我将结合多个实战项目，为你拆解上下文工程的完整体系。

2. 核心架构解析：构建企业级AI的“信息中枢”

一个健壮的上下文工程系统，绝非简单的“检索+拼接”。它是一个分层、解耦的架构，每一层都有其明确的职责和最佳实践。我通常将其划分为四个核心支柱，它们共同构成了LLM应用的“信息中枢”。

2.1 知识检索层：从“大海捞针”到“精准制导”

知识检索层是上下文工程的基石，负责从外部知识源（文档、数据库、API）中实时查找相关信息。早期的“朴素RAG”（Naive RAG）存在明显缺陷：固定长度的文本分块常常割裂语义；简单的向量相似度检索可能召回不相关的内容；缺乏对检索结果的验证机制。

实战演进：三代RAG架构对比 在我的项目中，RAG的演进清晰地反映了我们对“精准”的追求：

第一代：朴素RAG (2023年初)
- 模式：文档→固定长度分块→向量化→存入向量数据库→用户查询时进行Top-K相似度检索→结果直接拼接给LLM。
- 痛点：回答质量极不稳定。当用户问“我们公司第三季度的销售政策有什么变化？”时，系统可能检索到“第一季度销售政策”、“第三季度财报摘要”等不完整或无关的片段，导致模型生成混淆或错误的答案。
- 教训：语义分块是关键。我们后来转向了基于句子边界、段落或章节的“语义分块”，并引入了10-15%的重叠，保证了上下文的连贯性。
第二代：高级RAG (2023-2024年)
- 核心增强 ：引入了查询改写、混合搜索、重排序等环节。
- 查询改写 ：LLM将原始用户问题“销售政策变了吗？”改写成更利于检索的“2024年Q3销售政策修订内容”或“销售政策最新版本”。
- 混合搜索 ：结合向量搜索（语义）和关键词搜索（如BM25）。例如，搜索“API速率限制”，向量搜索能找到“接口调用频次控制”，而关键词搜索能精准命中包含“API”、“速率”、“限制”字样的文档段落。两者结果融合后重排序，召回率显著提升。
- 工具链 ：这个阶段我们重度依赖LangChain和LlamaIndex。它们提供了可插拔的模块，让我们能快速搭建管道。例如，使用LlamaIndex的 SentenceSplitter 进行智能分块，用 CohereRerank 对检索结果进行重排序。
第三代：智能体化RAG (2024年至今)
- 范式转变 ：RAG不再是一个被动的管道，而是一个由LLM驱动的、具备规划、反思和决策能力的智能体。这是当前企业级项目的标配思路。
- 工作流程 ：
  1. 路由判断 ：LLM首先判断用户问题是否需要检索外部知识。例如，“今天天气怎么样？”可能直接调用天气API，而无需检索知识库。
  2. 多源检索规划 ：如果需要检索，LLM决定检索哪些来源。是向量数据库？还是知识图谱（GraphRAG）？或是需要调用某个内部API查询结构化数据？例如，“找出去年Q4表现最好的产品及其负责团队”，可能需要同时检索销售数据（API）和产品文档（向量库）。
  3. 迭代检索与验证 ：LLM评估首次检索结果是否充分。如果不够，它会自主改写查询或调整检索策略进行二次、三次检索，直到获得满意信息。
  4. 生成后验证 ：LLM生成答案后，会再次检查答案是否与提供的检索来源一致，是否存在幻觉。如果发现矛盾，则触发“反思”机制，重新检索或修正答案。
- GraphRAG的引入 ：对于需要“全局洞察”的问题，传统向量RAG显得力不从心。比如，“公司近两年在可持续发展方面有哪些关键举措，它们之间有何关联？”。微软提出的GraphRAG技术，通过从文档中自动提取实体和关系构建知识图谱，并能对图谱中的社区进行摘要，非常适合回答这类需要跨文档推理的开放性问题。我们在一个竞品分析项目中，将向量RAG与GraphRAG结合，前者处理具体产品参数查询，后者分析市场趋势和竞争格局，效果拔群。

实操心得 ：不要盲目追求最复杂的Agentic RAG。对于简单、明确的文档问答，Advanced RAG已经足够。引入Agentic RAG会显著增加复杂度和延迟。决策的关键在于问题的“开放性”和“推理步骤”。我的经验法则是：如果一个问题可以通过在单一文档中查找一句话来回答，用Advanced RAG；如果需要串联多个文档中的信息并进行归纳、对比或推理，则必须上Agentic RAG。