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

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

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

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

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

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

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

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

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

1. 第一代：朴素RAG (2023年初)

   • 模式：文档→固定长度分块→向量化→存入向量数据库→用户查询时进行Top-K相似度检索→结果直接拼接给LLM。
   • 痛点：回答质量极不稳定。当用户问“我们公司第三季度的销售政策有什么变化？”时，系统可能检索到“第一季度销售政策”、“第三季度财报摘要”等不完整或无关的片段，导致模型生成混淆或错误的答案。
   • 教训：语义分块是关键。我们后来转向了基于句子边界、段落或章节的“语义分块”，并引入了10-15%的重叠，保证了上下文的连贯性。

2. 第二代：高级RAG (2023-2024年)

   • 核心增强：引入了查询改写、混合搜索、重排序等环节。
   • 查询改写：LLM将原始用户问题“销售政策变了吗？”改写成更利于检索的“2024年Q3销售政策修订内容”或“销售政策最新版本”。
   • 混合搜索：结合向量搜索（语义）和关键词搜索（如BM25）。例如，搜索“API速率限制”，向量搜索能找到“接口调用频次控制”，而关键词搜索能精准命中包含“API”、“速率”、“限制”字样的文档段落。两者结果融合后重排序，召回率显著提升。
   • 工具链：这个阶段我们重度依赖LangChain和LlamaIndex。它们提供了可插拔的模块，让我们能快速搭建管道。例如，使用LlamaIndex的SentenceSplitter进行智能分块，用CohereRerank对检索结果进行重排序。

3. 第三代：智能体化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。

2.2 记忆管理层：赋予AI“持续对话”的能力

默认情况下，LLM是“金鱼脑”，没有记忆。记忆管理层的目标就是打破这个限制，让AI能记住对话历史、用户偏好，甚至从过去的错误中学习。

三层记忆模型实战我参考了学术研究并加以工程化，设计了以下三层记忆架构，在多轮对话助理项目中取得了很好效果：

• 工作记忆 (Working Memory)：

  • 是什么：相当于LLM当前上下文窗口里的内容。这是最“热”、最昂贵的数据。
  • 管理策略：不能无脑地把所有历史对话都塞进去。我们采用“滑动窗口+摘要”策略。保留最近3-5轮完整对话，对于更早的对话，则用LLM生成一个简短的摘要（例如：“用户之前咨询了关于VPN报销的政策，已告知需部门领导审批”），然后将摘要而非原始对话放入上下文。这大大节省了Token，并保留了关键信息。

• 情节记忆 (Episodic Memory)：

  • 是什么：存储在外部数据库（如Redis或PostgreSQL）中的过去对话“经历”。
  • 如何工作：每次对话结束时，系统自动生成本次对话的摘要和关键点（例如：“用户偏好用Markdown格式查看代码示例”），并向量化后存入向量数据库。当新对话开始时，系统会检索与当前话题相关的历史“情节”记忆，并将其摘要注入工作记忆。
  • 价值：实现了跨会话的个性化。用户下次再来说“像上次那样总结”，AI就知道他指的是什么。

• 语义记忆 (Semantic Memory)：

  • 是什么：这就是企业的知识库本身，是相对静态的“世界知识”。
  • 实现：即RAG系统中的向量索引和知识图谱。它是记忆系统的基石。

Reflexion模式：让AI从错误中学习这是记忆系统最酷的应用之一。我们在一个内部运维问答机器人中实现了它。当系统给出的答案被用户标记为“错误”或“不准确”时，会触发以下流程：

1. LLM对这次失败的交互进行“反思”，分析错误原因（例如：“混淆了A服务和B服务的重启命令”）。
2. 将这段反思文本，连同问题、错误答案、正确答案一起，存储为一条“情节记忆”。
3. 未来遇到类似问题时，系统在检索知识的同时，也会检索相关的“反思”记录，并在上下文中加入提示：“注意：历史上曾在此类问题上出错，需仔细区分A和B”。 实测下来，系统的重复犯错率在一个月内下降了70%。

2.3 上下文编排层：信息呈现的“艺术”

这是最体现“工程”二字的地方。当知识、记忆、工具描述都准备好后，如何将它们“喂”给LLM，直接影响模型的理解和输出质量。这里有几个核心策略：

1. 结构化与标记千万不要把一堆文本杂乱无章地拼接起来。一定要使用清晰的标记来区分不同来源和类型的信息。XML或特定的Markdown格式是很好的选择。

<system_instruction> 你是一个专业的金融合规顾问，回答必须基于提供的法规条文，并注明出处。如果信息不足，请明确说明。 </system_instruction> <conversation_history> [用户] 上次我们说到内幕交易，处罚力度是怎样的？ [助理] 根据《证券法》第202条，内幕交易行为人没收违法所得，并处以违法所得一倍以上五倍以下的罚款。 </conversation_history> <retrieved_documents relevance_score="0.96" source="证监会2024年处罚案例库"> 案例编号：2024-001 涉事主体：XX公司高管李某 违法事实：利用内幕信息交易本公司股票 处罚结果：没收违法所得350万元，并处以1050万元罚款（三倍）。 </retrieved_documents> <user_query> 如果是五倍罚款，具体怎么计算？ </user_query>

这种结构化的上下文，让模型能清晰地分辨指令、历史、依据和当前问题，极大减少了混淆。

2. 位置与顺序管理LLM对上下文不同位置的注意力是不同的，存在“中间迷失”（Lost in the Middle）现象。关键信息应放在开头或结尾。我们的策略是：

• 开头：放置最核心的System Prompt和本次任务的关键指令。
• 紧随其后：放置相关性最高的检索结果（经过重排序的Top 1-2）。
• 中间偏后：放置补充性背景知识和压缩后的对话历史。
• 结尾：放置当前的用户查询。有时也会把工具描述放在较后的位置。

3. 动态压缩与选择当总上下文长度接近模型限制时，需要对低优先级信息进行压缩。例如，将十轮前的长对话压缩成一句话摘要：“用户曾深入讨论过项目A的预算问题，最终倾向增加10%”。或者，在有多条检索结果时，只注入相关性分数超过0.9的那几条。

2.4 工具与环境层：连接数字世界的“手脚”

对于需要执行具体操作（查数据库、发邮件、调用API）的AI智能体，工具的描述和状态也是上下文的重要组成部分。这部分的关键是提供清晰、准确、结构化的工具定义（通常遵循OpenAI Function Calling或ReAct格式），并将工具的执行结果（成功或失败，包括返回的数据）及时地反馈到上下文中，供模型进行下一步推理。

3. 关键技术选型与实战配置

理论讲完，我们来点硬的。搭建一个上下文工程系统，需要做出一系列技术选型。以下是我在多个项目中总结出的选型建议和配置心得。

3.1 向量数据库：存储与检索的基石

我的选择：对于大多数企业级知识库项目，如果数据量在百万级以内，我倾向于Weaviate。它的混合搜索能力在实际业务中非常实用（用户经常用关键词提问），开源属性也让后期定制和成本控制更有把握。如果项目要求快速上线且预算充足，Pinecone是最省心的选择。

3.2 Embedding模型：语义理解的“翻译官”

Embedding模型将文本转换为向量，其质量直接决定检索的准确性。别再只用OpenAI的text-embedding-ada-002了，现在有更好的选择。

• 选型关键：

  1. MTEB排行榜：关注 Massive Text Embedding Benchmark 榜单，排名靠前的模型通常表现更优。
  2. 多语言支持：中文业务必须选择在中文语料上训练良好的模型，如BGE-M3、Alibaba-NLP/gte-multilingual。
  3. 维度与性能权衡：text-embedding-3-large达到3072维，能力很强但更贵更慢。BGE-M3支持可变维度，在1024维下就能达到很好的效果，是性价比之选。

• 实战配置示例（使用Sentence Transformers库）：

  from sentence_transformers import SentenceTransformer # 加载多语言模型 model = SentenceTransformer('BAAI/bge-m3') # 编码时指定维度 embeddings = model.encode(documents, normalize_embeddings=True, batch_size=32)

  注意：normalize_embeddings=True至关重要，它会将向量归一化，使得相似度计算（余弦相似度）更高效准确。

3.3 LLM框架：LangChain vs LlamaIndex

这是开发者最常面对的选择。两者并非互斥，常结合使用。

• LangChain：更像一个“胶水”框架，其核心概念是“链”（Chain）和“智能体”（Agent）。它擅长将不同的组件（模型、检索器、工具）连接成复杂的工作流。如果你要构建一个多步骤、有状态、需要复杂逻辑编排的AI智能体，LangChain（尤其是其LangGraph扩展）是首选。它的抽象层次高，灵活性强，但学习曲线稍陡。
• LlamaIndex：专注于“数据层”和“检索”。它在文档加载、智能分块、向量索引构建、高级检索策略（如父子分块、递归检索）方面提供了极其强大和易用的接口。如果你的核心需求是快速构建一个高效、可靠的RAG系统，LlamaIndex往往更直接、更“傻瓜式”。

我的策略：用LlamaIndex做“数据引擎”和“检索器”，用LangGraph编排“智能体工作流”。例如，用LlamaIndex建立知识库索引并提供高质量的检索结果，然后将检索结果和用户查询喂给LangGraph构建的智能体，由智能体决定如何调用工具、如何反思、如何生成最终答案。

3.4 长上下文模型：是救星还是新坑？

Claude 200K，Gemini 200万Token……长上下文窗口让人兴奋。是不是可以把所有文档都塞进去，告别复杂的RAG了？答案是：几乎不可能，也不应该。

• 成本：长上下文的推理成本呈超线性增长。处理一个20万Token的上下文，费用可能是4K上下文的数十倍。
• 性能：“中间迷失”效应在超长上下文中被放大。模型对开头和结尾的信息关注度高，中间部分的信息容易被忽略。
• 延迟：生成200K Token的上下文需要时间，可能导致用户体验不佳。

正确用法：将长上下文能力作为RAG的补充，而非替代。我们的策略是：先用RAG从海量知识库中精准检索出最相关的5-10个文档片段（可能总计2-3万Token），然后将这些精选过的片段，连同系统指令和对话历史，一起放入长上下文窗口。这样既利用了长上下文模型能同时处理多文档的优势，又通过RAG保证了信息的精准性，还控制了成本。

4. 企业级落地：从零搭建一个上下文工程系统

假设我们要为一个中型科技公司搭建一个内部技术问答与文档助理。以下是完整的实战步骤和避坑指南。

4.1 阶段一：需求分析与数据准备

1. 明确范围：确定知识库覆盖范围（如API文档、部署指南、故障排查手册、公司制度）。切忌一开始就贪大求全。
2. 数据收集与清洗：
   • 从Confluence、GitHub Wiki、Google Docs、PDF手册等来源收集原始数据。
   • 关键步骤：清洗HTML/PDF格式噪音，统一字符编码（确保UTF-8），处理乱码。一个常见的坑是PDF中的换行符和空格异常，需要用pymupdf或pdfplumber仔细提取后做正则化处理。
3. 选择分块策略：
   • 不要用固定长度分块！我们使用基于语义的分块。
   • 工具：采用LangChain的RecursiveCharacterTextSplitter，并设置separators为["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""]，结合chunk_size=512和chunk_overlap=50。对于代码文档，我们单独写了一个分块器，确保函数定义或类定义的完整性。
   • 父子分块：对于较长的文档（如一篇完整的架构设计文档），我们同时创建“父块”（整个文档的摘要）和“子块”（各个章节）。检索时先找到相关的子块，但返回给模型时附上其父块摘要，以提供全局背景。

4.2 阶段二：索引构建与嵌入

1. 嵌入模型选择：选择BGE-M3模型，因为它对中英文混合文本支持好，且开源可私有化部署。
2. 向量数据库部署：选择自托管Weaviate，使用Docker Compose部署。

   # docker-compose.yml version: '3.4' services: weaviate: image: semitechnologies/weaviate:latest ports: - "8080:8080" environment: - QUERY_DEFAULTS_LIMIT=25 - AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED=true - PERSISTENCE_DATA_PATH=/var/lib/weaviate - DEFAULT_VECTORIZER_MODULE=text2vec-transformers - ENABLE_MODULES=text2vec-transformers - TRANSFORMERS_INFERENCE_API=http://t2v-transformers:8080 t2v-transformers: image: semitechnologies/transformers-inference:sentence-transformers-paraphrase-multilingual-MiniLM-L12-v2 environment: - ENABLE_CUDA=0 # 如果无GPU则设为0

3. 构建索引管道：
   • 使用LlamaIndex的SimpleDirectoryReader加载清洗后的文档。
   • 使用自定义的语义分块器进行分块。
   • 使用BGE-M3模型生成嵌入向量。
   • 将向量和元数据（如来源文件、章节标题、创建日期）批量导入Weaviate。务必为元数据建立索引，以便后续进行混合搜索和过滤（如“只搜索2024年之后的文档”）。

4.3 阶段三：检索与编排逻辑开发

1. 实现混合检索器：在Weaviate中，可以轻松配置同时进行向量搜索和关键词搜索（BM25），并对结果进行融合重排序。
2. 设计上下文组装模板：使用LangChain的PromptTemplate或LlamaIndex的ChatPromptTemplate，定义一个结构化的上下文模板，明确指令、知识、历史、查询的位置和格式。
3. 实现记忆管理：
   • 工作记忆：使用LangChain的ConversationBufferWindowMemory或ConversationSummaryMemory来管理对话历史。
   • 情节记忆：在PostgreSQL中创建一张表，用于存储session_id,user_id,conversation_summary,embedding_vector。每次对话结束，用LLM生成摘要并向量化存储。新对话开始时，根据当前用户问题检索相关的历史摘要。
4. 构建智能体工作流（使用LangGraph）：

   from langgraph.graph import StateGraph, END from typing import TypedDict, List import operator class AgentState(TypedDict): question: str retrieved_docs: List[str] analysis: str final_answer: str def retrieve(state: AgentState): # 调用Weaviate进行检索 state["retrieved_docs"] = weaviate_hybrid_search(state["question"]) return state def analyze(state: AgentState): # 判断检索结果是否充分，是否需要进一步分析 if not state["retrieved_docs"]: state["analysis"] = "知识库中未找到相关信息，需告知用户无法回答。" elif needs_deeper_analysis(state["question"], state["retrieved_docs"]): state["analysis"] = "信息已找到，但需要进行对比和归纳。" else: state["analysis"] = "信息充分，可直接回答。" return state def generate_answer(state: AgentState): # 根据分析和检索结果，组装最终上下文并调用LLM生成答案 context = assemble_context(state["question"], state["retrieved_docs"], state["analysis"]) state["final_answer"] = call_llm(context) return state workflow = StateGraph(AgentState) workflow.add_node("retrieve", retrieve) workflow.add_node("analyze", analyze) workflow.add_node("answer", generate_answer) workflow.set_entry_point("retrieve") workflow.add_edge("retrieve", "analyze") workflow.add_conditional_edges( "analyze", lambda x: "answer" if x["analysis"] != "无法回答" else END, {"answer": "answer", END: END} ) workflow.add_edge("answer", END) app = workflow.compile()

4.4 阶段四：评估、迭代与监控

1. 建立评估集：收集100-200个真实用户可能问的问题，并准备好标准答案或参考答案。
2. 定义评估指标：
   • 检索相关度 (Retrieval Precision@K)：人工或使用LLM-as-Judge评估检索出的前K个文档是否相关。
   • 答案忠实度 (Answer Faithfulness)：生成的答案是否严格基于提供的检索来源，有无幻觉。
   • 答案相关性 (Answer Relevance)：答案是否直接回答了问题。
   • 延迟 (Latency P95)：从请求到响应的95分位耗时。
3. 自动化评估：使用RAGAS或DeepEval等框架，定期（如每周）在评估集上运行测试，监控指标变化。
4. 持续迭代：根据评估结果，调整分块大小、重排序模型、提示词模板等。建立一个反馈循环，将用户标记的“踩”回答，加入评估集并分析原因。

5. 常见问题与避坑指南

在多个项目的摸爬滚打中，我踩过无数坑，也总结出一些宝贵的经验。

问题一：检索结果看似相关，但模型就是不用。

• 原因：上下文噪音太大，或者关键信息被埋没在长篇文档的中间。
• 解决方案：
  1. 实施重排序：在向量检索后，增加一个基于交叉编码器（如bge-reranker）的重排序步骤，将最相关的1-2个片段排在前面。
  2. 优化上下文结构：将最相关的检索结果放在系统指令之后、用户查询之前。使用<highly_relevant>这样的标签包裹它。
  3. 在指令中明确要求：在System Prompt里加入“你必须严格依据以下提供的参考信息来回答问题，忽略与你已有知识冲突的部分。”

问题二：多轮对话中，模型“忘记”了之前的设定。

• 原因：工作记忆管理策略不当，过早丢弃或过度压缩了关键历史信息。
• 解决方案：
  1. 关键信息持久化：将用户明确指定的重要偏好（如“叫我老王”、“用表格输出”）提取出来，存入“情节记忆”或单独的“用户画像”存储中，并在每次对话开始时作为系统指令的一部分注入。
  2. 更智能的摘要：不要简单截断历史。使用LLM对较长的历史对话进行“针对性摘要”，聚焦于当前任务相关的部分。例如，如果当前在讨论API，就摘要之前关于API的讨论点。

问题三：系统响应速度慢，用户体验差。

• 原因：检索链路长，或LLM生成速度慢。
• 解决方案：
  1. 异步与流式：将耗时的检索步骤与LLM生成步骤解耦，甚至可以考虑在用户输入时就开始预检索。对于长答案，采用流式输出（Streaming），让用户先看到部分结果。
  2. 缓存：对常见问题（FAQ）的检索结果和生成答案进行缓存。可以使用Redis存储query_embedding到answer的映射。
  3. 模型选型：在保证效果的前提下，考虑使用更小、更快的模型（如Qwen2.5-7B-Instruct）进行初步检索重排序或答案生成，用大模型做最终校验。

问题四：知识库更新后，回答质量下降。

• 原因：新文档的嵌入分布与旧索引不同，或新旧知识冲突。
• 解决方案：
  1. 增量更新与版本控制：为向量索引引入版本概念。每次全量更新时创建新版本索引，并通过一个路由层将查询导向新旧两个索引，对比结果，平滑过渡。
  2. 定期全量重建：对于更新频繁的知识库，建立自动化管道，每周或每天在低峰期全量重建索引。虽然耗时，但能保证一致性。
  3. 冲突检测：在更新时，用新文档的嵌入去旧索引中搜索最相似的旧文档。如果相似度高但内容有冲突，则打上“待审核”标签，提醒管理员处理。

上下文工程不是一个一劳永逸的项目，而是一个需要持续观察、测量和优化的动态系统。它一半是科学，一半是艺术。科学的部分在于严谨的评估指标和架构设计；艺术的部分在于对模型行为的细微体察和对用户体验的不断打磨。当你看到自己构建的系统，能够像一个真正专业的助手一样，准确、连贯、有记忆地处理复杂问题时，那种成就感是无与伦比的。这条路没有终点，但每一步的优化，都会让你的AI应用变得更聪明、更可靠。