上下文工程：如何为模型提供完成任务所需的信息

模型看不到其所处的产品、数据库、组织或世界。它在每次推理时，只能依据训练期间学到的行为，以及系统为该次调用提供的信息来行动。

这些信息常被笼统地称为“提示词（prompt）”。在真实系统中，它可能包括系统指令、用户请求、会话历史、检索到的文档、工具定义、工具结果、示例、权限以及选取的任务状态。决定哪些内容应当放入其中，是一项系统设计问题，而不仅仅是写作练习。

论点

上下文工程（Context Engineering）是对模型在每次推理时可用信息的有意设计。其目标是提供充分、相关、权威、最新且被许可的信息——同时不假设更多 token 会自动带来更好的行为。

因此，上下文是一项需要治理的运行时依赖。它需要明确负责人、选择规则、来源信息、信任边界、容量限制和评估方法。提示工程依然有用，但它只覆盖了这项更广泛职责的一部分。

本章确立心智模型。后续“架构”一章将负责检索、排序、压缩、缓存、记忆与运行时组装机制。

什么是上下文——什么不是

在本章中，上下文指一次模型推理输入中所表示的信息。具体序列化方式因模型与服务商而异，但工程上的区分是稳定的。

上下文不止于用户消息

一次模型调用可能由多种来源共同塑造：

来源	其贡献	典型风险
系统与开发者指令	角色、任务、策略、输出要求	冲突、过时规则或无法兑现的承诺
用户输入	目标、偏好、提供的事实	含糊、信息缺失或恶意指令
检索到的证据	领域知识与当前事实	不相关、陈旧、权威性弱或注入
工具定义	可用操作与期望参数	工具过多且相似、描述误导或权限过大
工具结果	来自外部系统的观测	错误、部分结果、陈旧值或不可信内容
会话或任务历史	既往决策、承诺与中间产物	噪声累积、矛盾或敏感数据保留
示例	期望行为的具体演示	过拟合示例或复制偶然细节
选取的状态或记忆	跨步骤或会话携带的事实	检索不当、事实过时或隐藏假设

这些来源的可信度并不相同，也不应享有同等权威。应用维护的策略、用户陈述的偏好以及嵌入在检索网页中的指令，虽然都是文本，但并非同一种指令。

上下文不是模型的全部知识

模型参数编码了训练期间学到的模式，但工程师通常无法像操作应用数据库那样精确枚举或更新这些知识。运行时上下文用任务特定的指令与证据来补充该能力。它并不能揭示究竟是哪部分训练信息会影响响应。

上下文窗口只是容量上限

**上下文窗口（context window）**限制了模型在一次调用中能处理的输入与生成的输出。把信息塞进该限制内，并不意味着模型会正确使用每一项。

在《Lost in the Middle》中，Liu 及其同事发现在其测试的多文档问答与检索任务上，相关信息若出现在长输入的开头或结尾，模型往往比信息位于中间时表现更好（Liu et al., 2024）。这一结果来自特定时期的模型和任务，不能当作普遍适用的位置规律。更稳妥的结论是：信息已经放入上下文，不等于模型能够有效利用。因此，应当测试实际模型在实际上下文组织方式下的表现。

提示词、上下文、状态与记忆

这些概念相互作用，但不应互换使用。

概念	实用含义	关键问题
提示词	为引出行为而有意提供的指令或内容	我们在要求模型做什么？
上下文	此次推理步骤可供模型使用的一切信息	此刻有哪些信息能影响该响应或决策？
状态	跨步骤持续存在或不断变化的任务及环境事实	模型调用之外的当前真实状态是什么？
记忆	跨交互保存并在以后取回信息的机制	后续工作可能需要重新取回哪些信息？

采购订单可以作为持久状态存在于数据库中。记忆服务可以保留用户的配送偏好。在系统检索并将相关信息表示进上下文之前——或者在确定性的应用逻辑中直接使用之前——二者都不会影响特定的一次推理。

这种区分能避免两个常见错误。首先，会话记录并不会因为模型可见就自动成为可靠的真实来源。其次，存储信息并不能保证在正确的时间检索到正确的信息。

上下文选择问题

好的上下文不是尽可能大的上下文。它是在实际模型与任务下，实现预期行为所需的最小集合，并为选择过程可能遗漏的情况留出安全余量。

选择需要平衡可能冲突的性质：

相关性：此项是否有助于当前决策？
完整性：是否缺失了关键事实或约束？
权威性：该来源是否有资格确立此事实或指令？
时效性：在使用时该信息是否仍然有效？
溯源：系统能否识别其来源与变更过程？
一致性：是否与另一项冲突，且是否已定义优先级？
许可：该信息是否可向此模型、工具、用户或下游服务披露？
成本：它带来何种延迟、token 使用与运维复杂度？

将整个代码库或文库全部加入上下文，或许能保留检索系统可能错过的事实，但也会增加成本并稀释相关信息。严格筛选可以提高效率，却可能因漏掉一份文档而让答案看似肯定、实则不完整。上下文策略不能脱离具体任务及其评估单独决定。

将上下文视为带类型的信息流

纯文本会模糊来源与权威。一种实用方法，是把每条上下文信息都看作带有以下属性的记录：

内容：
来源：
来源类型：
权威性：
创建或观测时间：
有效时间：
信任域：
与任务的相关性：
允许披露的对象：
转换过程：

运行时表示无需逐字包含每个字段。系统应保留足够的元数据，以便应用选择与访问规则、在需要时支持引用，并诊断某项被纳入的原因。

NIST 的生成式 AI 风险管理框架建议记录数据来源、内容流转过程、转换与上游依赖，并评估数据和内容在系统中的流动（NIST AI 600-1, 2024）。它并未规定此类记录格式；上述形式是本手册根据这一更广泛要求给出的实践建议。

检索带来的是证据，不是真相

检索增强生成（RAG）明确了一项重要的架构思路：系统不必只依赖模型参数中保存的知识，还可以从可更新的外部来源选取信息并提供给模型。最初的 RAG 研究也把来源追踪和知识更新列为主要动机（Lewis et al., 2020）。

然而，检索自身引入了一串主张：

系统检索了正确的集合。
该集合包含所需信息。
排序选择了相关材料。
选中的来源足够权威且最新。
转换或摘要保留了材料本意。
模型正确使用了该证据。
输出为用例保留了足够的溯源。

任一步骤的失败都可能产出看似有根据、实则无支撑的结果。检索能缩小某些知识缺口；它并不证明完整性或真实性。

将指令与不可信内容分开

外部文档、网页、消息、代码与工具结果中可能包含看起来像指令的文本。即使应用本意仅将其视为数据，模型也可能对该文本作出响应。OWASP 将这一类风险描述为间接提示注入（indirect prompt injection），并建议分离外部内容、限制权限、验证输出，并对高风险操作要求审批（OWASP LLM01:2025）。

没有任何格式约定或指令层级能保证模型会忽略恶意内容。上下文工程可以保留信任区分，但安全还需要模型之外的控制：

仅检索当前主体可访问的信息；
标注并隔离不可信内容；
避免在模型可见的指令中放置机密；
赋予工具所需的最小能力与权限；
独立验证拟议动作；以及
在执行可能造成严重后果的操作之前，要求真正有效的审批。

Model Context Protocol 规范也提出类似警告：除非工具注解来自可信服务器，否则客户端应将其视为不可信信息（MCP Tools specification, 2025）。这是上述通用原则在一个具体协议中的体现：能够连接，不代表可以信任。

跨多步任务的上下文

在一次调用即可完成的能力中，上下文可能只需组装一次。在多步工作流或智能体中，每个结果都会产生一个新的选择问题。工具输出、观测、中间产物、用户更正与变更的状态都可能对下一步决策重要。

保留完整历史很简单，但最终会变得昂贵且嘈杂。对历史进行摘要或压缩能节省空间，但可能抹去来源信息、不确定性、被拒绝的替代方案或未完成工作。把持久任务状态保存在对话记录之外，可以改善工作的连续性，但需要明确的数据结构和更新规则。委派子任务可以隔离细节，但也会引入信息交接问题。

Anthropic 将上下文工程描述为：在有限的上下文容量内，持续筛选和整理指令、工具、外部数据与消息历史（Anthropic, 2025）。这是一份有用的厂商工程经验，而不是普遍适用的实现方案。正确的机制取决于后续步骤必须知道什么，以及系统如何验证这些信息没有丢失。

设计选项与权衡

方法	适用情形	主要成本或失效风险
提供范围明确的全部源材料	资料量较小且遗漏细节代价很高	token 成本、信息干扰、位置敏感性与数据暴露
检索与任务相关的材料	庞大或经常变更的知识集合	检索遗漏、排序错误与新增基础设施
维护结构化的任务记录	长时运行且有明确里程碑与决策的工作	模式设计，以及错误或不完整的状态更新
压缩或总结历史	超出实际可用上下文大小的工作	细节、溯源、不确定性或早先约束的丢失
隔离子任务并回传结果	中间上下文巨大的独立子任务	交接损失、不一致的假设与协调成本
向用户询问缺失的上下文	关键偏好或解读无法安全推断	打断与将工作量转移给用户

这些方法可以组合使用。工程任务是将选择规则与损失显性化，并在具代表性的工作上进行测试。

失效模式

只在提示词上找原因

团队反复重写指令，却忽视了证据缺失、工具描述不佳、历史陈旧或状态不正确。提示词为系统其他位置的失败背锅。

不加筛选地堆入上下文

因为窗口够大，就把能放的一切都塞进调用。成本上升、冲突的指令累积、重要证据更难被利用。

把检索结果当作正确性的证明

输出引用了检索到的片段，于是团队就假定结论正确。来源可能不相关、过时、无权威、不完整，或被误解。

将对话记录当数据库

系统把先前对话文本当作持久状态依赖。更正、事务与当前事实变得含糊、重复，或在压缩中默默丢失。

使用已经过期的记忆

存储的偏好或事实在无范围、无时间戳或未经确认的情况下被检索。系统自信地采用已不再真实的信息。

抹平不同来源的可信度差异

应用策略、用户请求、检索页面与工具输出被直接拼接，没有保留其权威性差异。不可信内容可能因此改变系统行为或导致数据暴露。

无法还原上下文的组装过程

系统无法重建是哪些上下文项、版本或变换塑造了某次决策。即便提供了错误信息，失败也看起来像神秘的模型行为。

本手册的建议

为每一项重要的模型介导决策，写清以下上下文说明：

决策或产物：
必需指令：
必需证据：
可选的补充信息：
权威来源：
时效要求：
冲突与优先级规则：
不可信来源及其隔离方式：
相关状态：
记忆的取回条件：
排除项与敏感数据规则：
token 或延迟预算：
为诊断保留的证据：
针对缺失、过期、冲突和恶意上下文的评估用例：

这是一张评审工作表，而非新协议。架构工作可通过检索、状态存储、记忆、缓存、压缩或更简单的代码来实现它。

清单

参考文献及其用法

Anthropic, “Effective context engineering for AI agents” (2025) — Anthropic 工程文章，将上下文工程定义为超越提示词措辞的范畴，并讨论有限上下文、工具、历史、压缩与长时智能体。本章采用其务实范围，但不将其建议视为标准。
Liu et al., “Lost in the Middle: How Language Models Use Long Contexts” (TACL, 2024) — 经同行评审的证据，显示信息位置影响了测试的长上下文任务表现。它并未为所有当前模型确立普适的排序规则。
Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” (NeurIPS, 2020) — 支持外部、可更新知识与溯源动机的奠基性 RAG 研究。其具体架构与结果不应被泛化为检索必然正确的保证。
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1 (2024) — 自愿性的全生命周期风险管理资料，支持记录与评估数据来源、沿袭、转换与上游依赖。
OWASP, “LLM01:2025 Prompt Injection” — OWASP 社区风险条目，支持把外部内容视为不可信信息，并在模型之外控制权限与操作后果。它不提供万无一失的预防方法。
Model Context Protocol, “Tools” specification (2025-06-18) — 展示工具定义与结果如何进入模型交互的协议示例，并说明来自不可信服务器的注解不能被直接信任。