1. 项目概述从“单次问答”到“持续协作”的范式转变如果你最近在折腾各种AI应用无论是用ChatGPT写代码还是用Claude分析文档可能都经历过这样的挫败感你问了一个问题AI答得挺好但当你基于它的回答再追问一个细节时它好像完全忘了刚才的对话给出的答案要么跑偏要么需要你重新复述一遍背景。这种“金鱼记忆”式的交互正是早期AI应用最让人头疼的地方。而“上下文工程”要解决的就是这个核心痛点。它不是一个具体的工具或算法而是一套设计哲学和工程实践旨在让AI智能体能够理解、记住并有效利用整个对话历史或任务背景从而实现真正意义上的“持续协作”。简单来说上下文工程就是为AI智能体构建“记忆”和“理解力”的系统性方法。一个没有良好上下文处理能力的AI就像是一个每次见面都要重新自我介绍的陌生人效率低下且令人沮丧。而一个精通上下文工程的智能体则像是一位默契的长期工作伙伴它记得项目的来龙去脉、你的偏好习惯甚至能主动关联起几小时前讨论过的要点。这种能力正是AI从“新奇玩具”蜕变为“生产力工具”的关键。无论是构建一个能处理多轮复杂需求的客服机器人还是一个能理解整个代码库上下文并精准修改的编程助手都离不开对上下文的精细雕琢。2. 核心需求解析为什么智能体必须“记住”和“关联”要理解上下文工程为何不可或缺我们需要先拆解智能体在实际工作中面临的核心挑战。这些挑战直接催生了对强大上下文处理能力的需求。2.1 突破“单轮对话”的局限性最原始、最简单的AI交互模式是单轮问答One-turn QA用户输入一个问题模型基于其训练数据中的知识生成一个回答。这种模式在处理孤立、定义明确的问题时有效比如“珠穆朗玛峰有多高”。然而现实世界中的任务尤其是专业和创造性工作极少是孤立的。它们通常是一个有逻辑链条的过程。场景举例-代码调试第一轮“帮我写一个Python函数从API获取天气数据并解析JSON。”第二轮“这个函数里如果API返回错误码404请增加重试逻辑。”第三轮“重试三次后如果还失败把错误信息记录到我刚才提到的error.log文件里。”在第三轮中“我刚才提到的error.log文件”这个指代对于没有上下文的模型来说是完全无法理解的。它必须记住第一轮或第二轮中关于日志文件的讨论即使当时没有明确创建文件才能正确执行任务。没有上下文每一轮对话都像是重启了一个新会话智能体无法进行累积性的学习和工作。2.2 维持任务的一致性与连贯性许多任务需要在一系列操作中保持状态和参数的一致性。例如在数据分析中你可能会要求AI“加载sales.csv这个数据集。” 然后“计算每个月的总销售额。” 接着“将结果可视化用折线图标题用‘月度销售趋势’。” 在这里智能体必须记住当前操作的对象是sales.csv这个数据集并且“结果”指的是上一步计算出的月度销售额。上下文就是维持这个“当前工作状态”的粘合剂确保一系列指令指向同一个目标而不是每次都要重新指定所有参数。2.3 理解指代与省略人类语言高效的原因之一在于大量使用指代如“这个”、“它”、“上述方法”和情景省略。在技术讨论中这种语言习惯尤为普遍。注意当你说“用第二种方法优化它”时“第二种方法”和“它”的具体所指完全依赖于之前的对话历史。上下文工程的核心任务之一就是解析这些指代将其准确地映射到历史信息中的具体实体或概念否则对话根本无法进行。2.4 实现个性化与自适应一个优秀的智能体应该能“认识”它的用户。这并不意味着拥有情感而是能记住用户的偏好、历史决策和特定领域的知识背景。例如如果你经常让AI助手用特定的代码风格如Google Python Style Guide来审查代码一个具备上下文能力的助手会在后续的代码审查中自动应用这一偏好而无需你每次都提醒。这种个性化体验极大地提升了工具的顺手程度和效率。3. 上下文工程的三大核心支柱记忆、检索与架构理解了“为什么需要”接下来我们深入“如何实现”。上下文工程并非魔法它建立在几个清晰的技术支柱之上。我们可以将其类比为构建一个高效的“外部大脑”供AI使用。3.1 记忆系统从短期缓存到长期知识库记忆是上下文的基础。根据信息的生命周期和重要性记忆系统通常被分为多层对话缓存短期记忆这是最基础的层次通常由大模型本身或调用它的应用程序来维护。它保存当前会话窗口内的所有对话历史例如OpenAI API中的messages数组。这种记忆是临时的、易失的一旦会话窗口填满或会话结束记忆就会消失。它的容量有限受限于模型的最大上下文长度如128K tokens。实操要点在开发中你需要精心管理这个缓存。例如当对话轮数过多时需要设计策略来摘要或丢弃最早的信息以腾出空间给新的对话同时保留最关键的任务背景。一种常见策略是当token数接近上限时将最早几轮对话的user和assistant消息合并摘要为一个system消息如“早期对话摘要用户最初想构建一个天气API客户端...”。向量数据库长期记忆当信息量超出单次对话窗口或需要跨会话持久化时就需要长期记忆。这是当前上下文工程中最火热的技术。其工作原理是编码将文本、代码片段、文档等非结构化数据通过嵌入模型Embedding Model转换为高维空间中的向量一组数字。存储将这些向量及其对应的原始文本或元数据存入专门的数据库如Chroma、Pinecone、Weaviate或Milvus。检索当用户提出新问题时将问题也转换为向量然后在向量数据库中搜索与之“最相似”即向量距离最近常用余弦相似度衡量的几条记录。注入上下文将检索到的相关文本作为背景信息插入到发给大模型的提示词中。 这样智能体就能“回忆”起它从未在当前对话中直接“见过”但却存储在知识库中的相关信息。例如你可以将公司产品文档全部存入向量库智能体就能在回答客户问题时引用最新的产品特性。结构化状态管理工作记忆对于需要精确控制状态的任务如一个预订流程、一个游戏仅靠文本缓存和向量检索不够。这时需要引入程序化的状态管理比如在代码中维护一个session_state对象明确记录当前任务阶段、已收集的用户信息如目的地、日期、已执行的操作等。这更像是传统软件中的状态机与AI的推理能力相结合。3.2 检索策略如何找到最相关的信息有了记忆库如何快速精准地找到所需信息是关键。检索策略决定了智能体“回忆”的质量。基于相似度的检索如上文所述这是向量数据库的核心。关键在于选择好的嵌入模型和设计优质的查询。例如查询“如何解决连接超时错误”可能直接检索效果不佳。更好的做法是进行查询扩展将问题重写为“连接超时错误 解决方案 排查步骤 网络问题”或将历史对话中的相关术语也纳入查询向量计算以提高召回率。混合检索单纯基于语义相似度的检索有时会漏掉关键词完全匹配的重要文档。混合检索结合了向量检索语义和传统全文检索关键词如BM25算法。例如搜索“Python asyncio 取消任务”关键词检索能确保找到精确包含这些术语的文档而向量检索能找到关于“异步编程中如何停止未来对象”的相关段落。两者结果融合后相关性更高。递归检索与重排序对于复杂问题可以分步检索。先检索高层级文档如目录、概述确定相关范围再在该范围内进行更细粒度的检索。检索到一批候选文档后还可以用一个更小、更快的模型称为重排序器对它们进行精细打分和排序将最相关的几条放在最前面再喂给大模型。这能显著提升最终答案的质量。3.3 上下文架构设计信息如何组织与呈现检索到相关信息后如何把它们有效地组织起来作为提示词的一部分输入给大模型同样是一门艺术。糟糕的上下文组织会让模型感到困惑。提示词模板与角色设定这是上下文架构的蓝图。一个强大的提示词模板会明确系统角色、任务目标、输出格式并为动态注入的上下文预留位置。# 一个简单的提示词模板示例 prompt_template 你是一个资深的{role}。你的任务是{task}。 请严格遵循以下要求 {format_requirements} 以下是与用户问题相关的背景资料来源于知识库 {retrieved_context} 当前对话历史 {conversation_history} 用户的最新问题是{latest_query} 请基于以上所有信息生成你的回答。 实操心得在{role}处赋予模型一个具体的专家身份如“Python后端架构师”、“挑剔的文案审校”能极大地引导其思维模式和输出风格。这本身就是一种强大的上下文设定。上下文窗口的智能管理模型上下文窗口是宝贵且有限的资源。你不能把检索到的所有文档不分主次地全塞进去。需要策略优先级排序将与当前问题最相关的片段放在最靠近用户问题或指令的位置。摘要与压缩对于长文档可以先使用另一个AI调用或摘要算法生成一个简洁的概要只将概要放入主上下文。如果模型需要细节它可以要求检索特定部分一种称为“检索增强生成”的进阶技巧。分层注入将信息分层核心指令和最关键背景放在system消息中详细参考文档放在后续的user消息中。有些模型对system消息中的指令赋予更高权重。思维链与中间步骤的保留对于复杂推理任务让模型“展示其工作过程”至关重要。这不仅让用户能跟踪逻辑更重要的是这些中间步骤思考过程本身构成了后续步骤的宝贵上下文。例如在数学解题或代码调试中将模型的推理链保留在对话历史里当它后续步骤出错时你可以指出“你在第三步的假设有问题”模型能基于这个精确的上下文进行修正。4. 实战构建一个具备上下文能力的智能体工作流理论说得再多不如动手搭建一个。下面我们以一个“技术文档问答助手”为例拆解构建一个具备上下文能力的智能体的核心步骤。这个助手能回答关于某个特定技术栈比如FastAPI的问题并能结合对话历史进行深入探讨。4.1 第一步搭建长期记忆库向量知识库这是智能体拥有“专业知识”的基础。材料准备收集所有相关的技术文档可以是Markdown文件、PDF、网页爬取的内容。假设我们有一批FastAPI的官方教程和API文档。文档预处理与分块为什么分块直接将整本手册塞进向量库效果很差。检索时可能返回整篇长文其中大部分不相关浪费上下文窗口。分块旨在创建大小适中、语义独立的片段。如何分块使用文本分割器。不要简单按固定字符数切割那样会切断完整句子。推荐使用基于语义的分割器如LangChain的RecursiveCharacterTextSplitter它会优先在段落、句子、换行符等处进行分割保持语义完整性。# 示例使用LangChain进行文档加载与分割 from langchain_community.document_loaders import DirectoryLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 加载文档 loader DirectoryLoader(./fastapi_docs/, glob**/*.md) documents loader.load() # 创建文本分割器 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 每个块大约500字符 chunk_overlap50, # 块之间重叠50字符避免语义断裂 separators[\n\n, \n, 。, , , , ] # 分割优先级 ) # 执行分割 chunks text_splitter.split_documents(documents) print(f原始文档数{len(documents)} 分割后块数{len(chunks)})注意事项chunk_size需要权衡。太小会丢失全局信息太大会降低检索精度。对于技术文档500-1000字符是个不错的起点。chunk_overlap能确保关键信息如一个概念的定义和举例不被割裂在两个块中。向量化与存储选择一个嵌入模型如OpenAI的text-embedding-3-small或开源的BAAI/bge-small-zh-v1.5中文效果好。选择一个向量数据库。对于本地开发和中小型项目Chroma因其简单易用和内置嵌入功能而备受青睐。from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings # 初始化嵌入模型请替换为你的API Key embeddings OpenAIEmbeddings(modeltext-embedding-3-small, openai_api_keyyour-key) # 创建向量库并存储 vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_fastapi_db # 指定持久化目录 ) # 之后加载只需vectorstore Chroma(persist_directory./chroma_fastapi_db, embedding_functionembeddings)执行后所有文档块都被转换为向量并存储。你的智能体就有了一个关于FastAPI的“长期记忆”。4.2 第二步设计对话引擎整合记忆与推理这是智能体的大脑负责处理用户输入、检索记忆、组织上下文并调用大模型。构建检索链当用户提问时首先将问题转换为向量在向量库中进行相似度搜索。采用混合检索提升效果。虽然Chroma主要做向量检索但我们可以结合关键词逻辑。例如可以先进行向量检索再对结果进行基于关键词的过滤或重排序。from langchain.chains import RetrievalQA from langchain_openai import ChatOpenAI # 初始化大语言模型 llm ChatOpenAI(modelgpt-4, temperature0, openai_api_keyyour-key) # 创建检索问答链 qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # “stuff”策略将所有检索到的文档内容“塞”进提示词 retrievervectorstore.as_retriever( search_typesimilarity, search_kwargs{k: 4} # 检索最相关的4个文档块 ), return_source_documentsTrue # 返回源文档便于调试 )管理对话历史短期记忆我们需要一个结构来保存当前会话的对话记录。可以使用简单的列表或更高级的LangChain的ConversationBufferMemory。from langchain.memory import ConversationBufferMemory memory ConversationBufferMemory( memory_keychat_history, return_messagesTrue, # 以消息列表格式返回 output_keyresult # 与链的输出键匹配 ) # 创建一个结合了记忆的链 from langchain.chains import ConversationalRetrievalChain qa_with_memory ConversationalRetrievalChain.from_llm( llmllm, retrievervectorstore.as_retriever(search_kwargs{k: 4}), memorymemory, verboseTrue # 打印详细日志方便调试 )这个qa_with_memory对象就具备了完整的上下文能力它内部维护着对话历史短期记忆并在每次提问时自动将历史对话和当前问题结合从向量库长期记忆中检索相关信息最后组织成完整的提示词发送给大模型。4.3 第三步优化提示词与上下文注入默认的链可能还不够智能我们需要定制提示词来更好地引导模型。from langchain.prompts import PromptTemplate # 自定义提示词模板 custom_prompt PromptTemplate( input_variables[chat_history, question, context], template你是一个FastAPI专家助手负责解答用户关于FastAPI框架的所有问题。 你的回答必须基于提供的上下文信息。如果上下文信息不足请如实说明你不知道不要编造答案。 之前的对话历史 {chat_history} 相关上下文 {context} 用户问题{question} 请以清晰、专业、有条理的方式回答 ) # 使用自定义提示词创建链 qa_chain_custom ConversationalRetrievalChain.from_llm( llmllm, retrievervectorstore.as_retriever(), memorymemory, combine_docs_chain_kwargs{prompt: custom_prompt}, verboseTrue )在这个模板中我们清晰地定义了角色(FastAPI专家助手)规定了行为准则(基于上下文不编造)并结构化地组织了对话历史、检索到的上下文和当前问题。这比默认的模板能产生更可控、更高质量的输出。5. 高级技巧与避坑指南在实际开发和运营中你会遇到各种预料之外的问题。以下是一些来自实战的经验和技巧。5.1 处理超长上下文与信息丢失即使使用了向量检索当对话轮数极多或检索到的文档本身很长时仍可能触及模型上下文窗口的上限。策略一对话历史摘要不要无限制地堆积原始对话。可以定期例如每10轮对话后或当token数接近阈值时触发一个摘要过程。用一个单独的LLM调用将之前的对话历史总结成一段简洁的“背景提要”然后用这个提要替换掉大部分原始历史只保留最近几轮详细对话。# 伪代码示例摘要对话历史 def summarize_history(full_history): summary_prompt f 请将以下对话历史浓缩成一个简洁的段落保留核心问题、关键决策和当前状态。 对话历史 {full_history} 摘要 # 调用LLM生成摘要 summary llm.invoke(summary_prompt) return summary踩坑记录摘要可能会丢失一些细节。一个折中方案是“摘要关键信息保留”即生成摘要的同时显式地将一些关键实体如项目名、文件名、核心参数值以列表形式保留下来一并放入上下文。策略二选择性记忆并非所有对话内容都同等重要。可以设计规则只将模型回复中的“结论”、“关键代码片段”以及用户消息中的“新指令”、“关键修改”存入长期记忆或重点保留在短期缓存中。那些“嗯”、“好的”、“让我想想”之类的填充内容可以优先被丢弃或压缩。5.2 提升检索质量的实战技巧检索不到正确信息再强的模型也白搭。查询重写与扩展用户的原始查询可能很模糊。在检索前先利用LLM对查询进行重写和扩展。# 伪代码查询扩展 def expand_query(original_query, chat_history): expansion_prompt f 基于以下对话历史和当前问题生成3个与当前问题相关的、更全面或从不同角度切入的搜索查询词用于检索知识库。 对话历史{chat_history} 当前问题{original_query} 生成的搜索查询每行一个 expanded_queries llm.invoke(expansion_prompt).split(\n) # 合并原始查询和扩展查询去重后用于检索 all_queries [original_query] expanded_queries # 对每个查询进行检索然后合并去重结果 ...例如用户问“怎么处理依赖”结合历史发现是在讨论FastAPI重写后的查询可能是“FastAPI dependency injection 使用方法 参数依赖 函数依赖”。元数据过滤在存储文档块时为其添加元数据如source来源文件名、section所属章节、doc_type是教程还是API参考。检索时可以结合语义相似度和元数据过滤。例如当用户明确问“官方教程里怎么说”你就可以在检索时添加过滤器{doc_type: tutorial}从而精准定位。重视负面案例建立一个“检索失败”的日志。定期分析那些用户提问后智能体回答“我不知道”或给出错误答案的情况。检查当时检索到的Top文档是什么为什么它们不相关。是分块策略问题查询表述问题还是知识库本身缺失持续迭代优化。5.3 评估上下文有效性的方法如何知道你的上下文工程做得好不好不能只靠感觉。人工评估黄金标准但耗时构建一个测试集包含多轮、复杂的对话场景。让人工评估者判断智能体的最终回答是否准确、连贯是否有效利用了历史信息。关注“指代解析是否正确”、“是否避免了信息遗忘”、“是否引用了正确的背景知识”。自动化代理评估设计一个“评估智能体”模拟用户进行多轮对话并预先设定好每轮对话后预期的“状态”或“知识要点”。在对话结束后让评估智能体检查最终状态是否符合预期。这可以自动化地进行大量回归测试。关键指标监控检索相关性计算用户问题与最终被注入上下文的文档块之间的余弦相似度平均值。如果持续偏低说明检索环节有问题。上下文利用率在模型回答后让另一个轻量模型判断回答中的关键事实是否来源于提供的上下文可以通过让模型标注引用来实现。低利用率可能意味着模型在“幻觉”或检索文档不相关。用户交互轮次与任务完成率一个良好的上下文系统应该能减少完成任务所需的平均对话轮次并提高复杂任务的完成率。监控这些业务指标的变化。6. 未来展望上下文工程的演进方向上下文工程远未定型它正在快速演进。除了目前主流的“检索增强生成”模式还有一些前沿方向值得关注。更智能的记忆管理当前的记忆系统还比较机械。未来的智能体可能需要更接近人类的记忆机制比如基于重要性、情感权重对于用户偏好或使用频率的记忆强化与遗忘曲线能够主动总结和提炼知识形成更高层次的“经验”或“模式”。多模态上下文的融合上下文不仅是文本。对于能处理图像、音频、视频的智能体上下文工程需要处理多模态信息的对齐、关联与检索。例如在讨论一张设计图时智能体需要能“记住”图中某个组件的位置和属性并在后续对话中引用。主动的上下文构建与提问目前智能体大多被动地接受和利用上下文。更高级的形态是智能体能够主动判断当前上下文是否充足并在信息不足时主动向用户提出澄清性问题引导用户提供更有效的背景信息从而共同构建一个更完善的协作上下文。这标志着从“工具”到“伙伴”的转变。构建一个真正理解上下文、拥有记忆的AI智能体就像在教一个天赋异禀但健忘的学徒如何成为一名可靠的同事。上下文工程就是那套系统的训练方法和协作协议。它没有一招制胜的银弹而是由数据预处理、检索策略、提示设计、记忆管理等一系列扎实的工程实践组合而成。每一次你让智能体“记得”之前说过的话每一次它准确地引用你提供的文档背后都是这套工程在默默支撑。