什么是上下文工程?

什么是上下文工程?

发表于昨天 23:47

上下文工程，通俗地说，就是“给人工智能准备一份合适的资料包”。人工智能模型本身很聪明，但它每次回答问题，只能看到你当前给它的信息，以及它被允许参考的上下文。上下文工程就是研究：该给它看什么，不该给它看什么，按什么顺序放，放多少，怎么删掉无关信息，怎么及时更新信息。

可以把它想成给一位临时来帮忙的同事准备桌面资料。你不仅要告诉他“帮我写份报告”，还要把相关数据、公司模板、写作要求、历史案例放在他眼前。放得太少，他容易瞎猜。放得太多，他会被干扰。放得乱，他找不到重点。放得过时，他会用错信息。

它通常包括这些事：挑选有用信息，去掉无关内容，把资料分好结构，控制长度，安排先后顺序，接入检索结果，保留必要的历史对话，更新会变化的信息，并明确任务目标、限制条件和输出格式。

所以，上下文工程不等于只写一句更好的提示词。提示词更像“你怎么交代任务”。上下文工程更像“你把整个工作环境和参考资料怎么布置好”。它的核心目标是：在模型有限的注意力空间里，让它看到最该看的信息，从而更稳定、更准确地完成任务。

举个例子。你要让模型回答客户投诉。只写“请回复这个投诉”，效果可能一般。做好上下文工程，可以同时提供：客户原话、订单信息、退换货政策、品牌语气要求、可参考的优秀回复、不能承诺的条款。这样模型更容易给出靠谱答案。

发表于昨天 22:35

上下文工程（Context Engineering）是指在构建大语言模型应用时，系统性地设计、选择、组织、压缩和更新模型在推理时能够看到的全部信息。它不只关注提示词怎么写，更关注整个上下文窗口里应该放什么、按什么顺序放、放多少、何时更新，以及如何避免无关或错误信息干扰模型。

简单说，上下文工程就是管理模型的“工作记忆”。这些信息可能包括系统指令、用户问题、对话历史、检索到的文档、工具调用结果、长期记忆、任务状态、输出格式约束等。

它和提示工程的区别是：提示工程更偏向优化指令的措辞和结构；上下文工程则站在系统层面，决定模型在每一次推理时应该获得哪些信息，以及这些信息如何流动和更新。

上下文工程的核心目标包括：提高回答相关性，减少幻觉，节省上下文窗口，保持多轮对话一致性，让工具调用和检索结果更可靠，并通过评估和迭代持续优化上下文组织方式。

发表于昨天 21:26

上下文工程是指在构建大语言模型应用，尤其是对话系统、检索增强生成和智能体时，对模型在每次推理中可见的全部信息进行系统性设计、选择、组织、压缩和更新的工程实践。它不只关心一句提示词怎么写，而关心模型做决定的那一刻，上下文窗口里应该出现什么、以什么顺序出现、以什么格式出现、占多少预算、何时替换或删除。模型能力不仅取决于参数，也取决于被提供的上下文是否充分、相关、干净、及时。上下文工程把这件事从“临场写提示”变成可管理的信息供应链。

一个完整的上下文通常包括系统指令、任务目标、用户画像、对话历史、检索文档、工具调用结果、长期记忆、环境状态、约束条件和输出格式要求。上下文工程首先要做选择，判断哪些信息与当前任务相关，哪些信息虽然相关但已经过时，哪些信息存在重复或冲突，哪些信息来自不可信来源。然后要做压缩，把长文档变成摘要、要点、引用片段或结构化字段，把冗长历史变成阶段总结，把工具返回的大段结果裁剪成模型真正需要的部分。接着要做排序和格式化，把最重要的约束放在清晰位置，用标题、标签、分隔符和结构化数据降低歧义，并标明信息来源和可信级别。还要做隔离，避免网页内容、检索文本或工具输出中的恶意指令混入系统指令，防止提示注入。

上下文工程与提示词工程有交集，但范围更大。提示词工程更偏向单次指令的表达和措辞，上下文工程则覆盖信息从产生、筛选、存储、检索、组装到进入模型的整个生命周期。它需要考虑上下文窗口限制、token成本、延迟、缓存、权限、隐私、安全、可观测性和评估。比如客服智能体不能把用户全部订单、全部政策文档和全部历史对话一次性塞给模型，而应根据当前问题检索相关订单、匹配适用政策、保留必要历史，并在工具调用后更新状态。长任务中还需要阶段性摘要、外部记忆和任务清单，避免旧信息误导或关键约束被淹没。上下文过多会稀释注意力，内容冲突会降低可靠性，来源不明会增加幻觉风险，因此需要优先级规则、去重机制、冲突处理和回放追踪。评估时不仅要看任务成功率，还要看事实性、引用准确性、指令遵循、成本、延迟和失败原因。上下文工程因此是一套持续运行的系统能力：任务前构建上下文，执行中维护和修正上下文，任务后沉淀可复用记忆，并让开发者能够解释、调试和迭代信息如何进入模型。

什么是上下文工程?

本周热门