1. 为什么需要上下文工程

大模型刚进入公众视野时，大家最直观并且最常用的使用方式就是（人机）对话：我们向大模型提出自己的问题，大模型就会给出对应问题的答案，比如豆包。在那个时期，最受关注的是提示词工程。只要我们在指令里面把角色、任务、格式、示例写清楚，再配上合适的参考示例，模型往往就能输出令人惊喜的结果。对于写作润色、翻译、代码片段生成等相对通用的任务，这种使用方式都是十分有效果的，因为这些任务主要依赖模型训练阶段已经学到的通用语言能力和公共的海量知识，无需额外的专属能力适配。

但是，真实业务问题往往不是这样的，实际情况往往是更加复杂的，完全不是上述逻辑。比如一个报销审核问题可能同时依赖公司最新制度、发票明细、员工级别、项目预算、审批历史和当地法规。一个智能客服问题可能依赖用户购买记录、当前物流状态、商品说明书、售后政策和近期公告。一个代码助手问题可能依赖当前仓库结构、接口约定、测试失败日志、历史提交和团队代码规范。仅靠一句提示词，不可能凭空让模型知道这些信息。这些场景涉及的都是企业、团队的专属私有数据与定制化规则，只依靠简单的提示词指令，根本无法让模型获取到这些关键信息，自然也就无法精准解决实际业务问题。

更加麻烦的是，业务信息本身具有实时性、私有性、碎片性和权限边界的特点。模型训练数据无法覆盖企业内部文档，也无法保证了解最新事实；即使模型知道某些公共知识，也可能因为版本的更新迭代而逐渐失效；即使我们强行将海量业务资料全部填入提示词，也会面临诸多局限：①上下文窗口容量不足；②冗余信息造成认知干扰；③使用成本大幅增加；④以及模型出现"中间信息迷失"；⑤遗漏关键内容等各类问题。

于是，问题逐渐从"如何写一句好提示词"变成了"如何把任务所需的信息以最合适的方式交给模型"。

上下文工程正是在这个转变中应运而生的。它把大模型应用看成一个动态系统，而不是一次性的问答。系统需要在用户发起请求后完成一系列连贯的核心操作：

序号	核心操作	说明
①	理解意图	识别用户的真实需求
②	确定信息需求	判断完成任务需要哪些信息
③	检索相关资料	从数据源中获取候选材料
④	过滤无关内容	去除噪声和冗余信息
⑤	压缩过长材料	在有限窗口内最大化信息密度
⑥	保留必要历史	维护多轮任务的连续性
⑦	决定是否调用工具	评估是否需要外部能力辅助
⑧	组织模型输入	将指令、证据、约束拼装为可理解的输入

在这个完成的应用体系中，大模型只是推理核心，围绕模型的信息供应、状态管理和安全控制同样重要。

从工程角度看，上下文工程解决的是三个基本矛盾：

序号	矛盾	描述
1	信息量 vs 窗口限制	任务需要的信息很多，而上下文窗口有限
2	数据噪声 vs 证据质量	外部数据源复杂而嘈杂，模型需要的是干净、有序、可信的证据
3	推理能力 vs 系统感知	模型具备语言推理能力，但对系统状态、权限、工具和业务规则没有天然感知

上下文工程的价值，就是在这三个矛盾之间建立可验证的平衡。

参考：https://juejin.cn/post/7621878684524019775

2. 基础概念：上下文工程是什么

在日常语言中，上下文通常指一句话前后的语境。例如"它多少钱"这句话本身并不完整，只有结合前文知道"它"指的是哪件商品，问题才有意义。在大语言模型系统中，上下文的含义更加广泛和深奥。模型在一次调用中能看到的所有输入，都可以视为上下文：

序号	上下文类型	示例
①	系统指令	系统级提示词与行为规则
②	开发者规则	开发者定义的约束条件
③	用户问题	用户当前输入的查询
④	历史对话	之前的多轮交互记录
⑤	检索片段	RAG 系统召回的文档片段
⑥	数据库记录	结构化查询结果
⑦	工具说明	可用工具的描述与参数
⑧	工具返回结果	工具调用后的输出
⑨	输出格式要求	对回答格式和结构的约束
⑩	权限提示	数据访问与操作权限信息
⑪	多模态内容	图像、表格、音频转写、代码文件

上下文窗口是模型一次推理能够接收的最大输入范围。窗口越大，理论上可以放入更多信息；但窗口变大并不等于质量自动提高。过长的上下文会带来成本增加、延迟上升、关键信息被噪声淹没和模型注意力分散等问题。好的上下文工程不是把所有东西都塞进去，而是让每一段进入上下文的信息都有明确作用。

参考：https://platform.openai.com/docs/guides/prompt-engineering/long-context

上下文工程可以定义为：围绕大语言模型的任务执行过程，系统性地获取、筛选、加工、排序、压缩、注入和管理上下文信息，使模型在有限窗口内获得完成任务所需的最相关、最可信、最可操作的信息。这个定义强调两点：第一，它是工程活动，需要数据管道、检索系统、权限控制、评估指标和运维监控；第二，它面向任务结果，所有设计都应服务于模型是否更准确、更稳定、更可解释、更安全。

参考：https://karpathy.github.io/2025/03/14/context-engineering/

也可以用信息流来理解上下文工程。用户提出的需求往往是高层、模糊和不完整的，外部资料往往是庞杂、重复和格式混乱的。系统要把这些高噪声材料转化为低噪声、结构化、可引用的模型输入。这个过程不是一次简单拼接，而是一个包括意图识别、信息召回、证据筛选、格式组织、记忆维护和输出约束的链路。

概念	简要说明	工程关注点
上下文	模型本次推理可见的全部信息	内容范围、可信来源、时效性、权限边界
上下文窗口	模型一次调用可接收的输入容量	token 预算、成本、延迟、关键信息位置
上下文工程	设计上下文获取、处理、注入和管理的系统方法	检索、压缩、排序、记忆、工具、安全、评估
信息密度	单位上下文中包含的有效任务信息	去重、降噪、结构化、引用来源
行动能力	模型可调用的工具、函数、API 和执行结果	工具选择、参数约束、权限审计、失败恢复

3. 上下文工程与提示词工程的区别

提示词工程并没有失效，它仍然是大模型应用的重要组成部分。系统指令、角色定义、输出格式、步骤约束和示例演示都属于上下文的一部分。区别在于，提示词工程通常聚焦于语言表达和任务引导，而上下文工程关注的是完整的信息系统。提示词工程的目标是"该怎样告诉模型做事"，上下文工程的目标是"模型做事前应该拥有哪些事实、约束、工具和历史"。

一个简单例子可以说明差异。假设用户问：“帮我判断这笔差旅报销是否合规。“提示词工程可能会把模型设定为"资深财务审核专家”，要求它"逐条分析并给出结论”。这会改善回答结构，但无法解决事实缺失的问题。上下文工程则会进一步检索报销制度、行程单、发票、员工级别、项目预算、审批记录和例外条款，然后把它们整理成可引用证据，再让模型判断。前者主要优化表达方式，后者提供判断所需的信息基础。

从失败模式看，两类问题各有不同：

维度	提示词工程	上下文工程
常见问题	指令不清、格式不稳、角色约束弱	检索不到、检索错、上下文太长、证据顺序不合理、历史记忆污染、工具调用参数错误、权限信息泄露
修复方式	重写指令或增加示例	改进数据质量、索引策略、召回算法、重排序模型、压缩流程、权限隔离和评估体系

参考：https://ai.google.dev/gemini-api/docs/context/vs-prompt

成熟的大模型系统通常同时需要二者。提示词工程提供操作规程，上下文工程提供信息供应。没有提示词，模型不知道如何使用上下文；没有上下文，提示词再精巧也只能让模型在缺少事实的情况下猜测。真正可靠的做法，是把提示词视为上下文工程中的指导性上下文，而不是把它当成全部。

维度	提示词工程	上下文工程
核心问题	怎样表达任务和约束	怎样组织模型执行任务所需的信息环境
主要对象	系统提示词、用户提示词、示例、输出格式	文档、数据库、历史、工具、权限、检索结果、压缩摘要
典型手段	角色设定、Few-shot、分步指令、格式模板	RAG、混合检索、重排序、记忆、工具调用、上下文压缩
常见风险	指令含糊、格式漂移、回答风格不稳定	检索错误、噪声过多、上下文投毒、隐私泄露、成本过高
评估重点	回答是否符合格式和语气	证据是否正确、召回是否充分、工具是否可靠、系统是否安全

4. 上下文的主要类型

为了设计清晰的系统，可以把上下文分成五类：

类型	职责	包含内容	核心作用
指导性上下文	告诉模型如何执行任务	系统提示词、角色边界、任务目标、输出格式、引用规则、禁止事项、Few-shot 示例、评分标准	规范模型行为，让模型知道应该以什么方式理解输入、如何组织推理、如何呈现结果
信息性上下文	告诉模型当前任务涉及哪些事实	检索到的知识库片段、数据库记录、网页内容、代码文件、日志、表格、图片描述、会议纪要、用户上传文档	RAG 系统的核心，其质量直接决定模型回答是否有事实基础
状态性上下文	描述任务进行到哪里	当前会话历史、用户偏好、已完成步骤、未解决问题、之前的工具调用结果、工作流状态、缓存状态	使模型能够进行多轮任务，而不是每次都从零开始
行动性上下文	告诉模型能做什么	可用工具、函数签名、API 描述、参数 schema、权限范围、调用示例、失败处理规则	让模型从"只会回答"转向"能够行动"，但也引入了安全和可靠性问题
约束性上下文	限制模型不能做什么	合规要求、隐私规则、数据访问权限、安全策略、业务边界、输出免责声明、人工审批节点	让系统可控，防止模型在不该行动时行动、在不该暴露时暴露、在证据不足时给出确定结论

参考：https://platform.openai.com/docs/guides/safety/context-constraints

5. 典型系统架构

一个典型上下文工程系统可以拆成七层：

层级	名称	职责	常见实现
1	入口层	接收用户输入、文件上传、语音转写或外部事件	Web、移动端、插件、Webhook、消息队列
2	意图理解层	判断任务类型、提取关键实体、识别是否需要检索、是否需要工具、是否存在权限风险	分类器、LLM 改写、规则引擎、实体抽取
3	数据接入层	连接文档库、向量数据库、关系数据库、搜索引擎、对象存储、业务系统和实时 API	文档库、SQL、搜索引擎、对象存储、API
4	检索与召回层	从多种数据源中找出可能相关的材料	向量检索、关键词检索（BM25）、SQL 查询、知识图谱查询、代码搜索、多模态检索
5	上下文优化层	去重、重排序、压缩、摘要、格式标准化和来源标注	重排序、去重、摘要、压缩、结构化
6	上下文组装层	把系统指令、用户问题、历史状态、证据材料、工具定义和输出格式拼装成模型输入	模板、schema、引用标注、token 预算
7	执行与反馈层	模型调用、工具调用、结果验证、日志记录、用户反馈和监控	日志、评估集、用户反馈、回归测试

这套架构的重点不是组件越多越好，而是每个环节都有可解释的职责。检索层回答"可能相关的材料在哪里"，优化层回答"哪些材料最值得放进窗口"，组装层回答"如何让模型正确使用这些材料"，评估层回答"系统是否真的变好"。如果系统没有这些边界，问题出现时很难定位：回答错了到底是模型能力问题、检索问题、文档质量问题、排序问题、提示词问题，还是工具返回错误。

从工程实现上看，成熟系统通常会保留完整的上下文构造日志。每次回答都应能追踪：

追踪项	说明
用户原始问题	用户最初输入的内容
改写后的检索查询	经过意图理解后生成的查询
召回的文档	从数据源中检索到的候选文档
重排序分数	各文档的相关性得分
最终注入的片段	经过优化后送入模型的上下文片段
模型调用参数	调用 LLM 时的参数配置
工具调用结果	工具执行后的返回数据
最终答案引用的证据	模型回答中引用的来源

没有这些日志，就无法进行可靠调试，也无法进行实验对比。

参考：https://python.langchain.com/docs/concepts/context_management