第 3 章 上下文工程

学习目标

• 解释上下文窗口预算与上下文腐化分别是什么意思，并为一个请求编制上下文预算表。
• 从问题出发，反过来推算回答所需的信息，只选取必要的资料放入上下文。
• 按照有助于提高回答质量的顺序，安排长文档与问题的位置，并为文档标明出处和版本。
• 要求模型先从长文档中引用作为依据的原文，再检查这些引文是否足以支撑结论。
• 解释对话摘要、上下文压缩和检索增强的原理，并将检索失败与回答失败区分开来进行诊断。
• 将无法信任的外部内容与指令分开，放在各自适当的位置。

引言

一家咨询公司的分析师一次放入五篇年度报告，询问“今年行业的三个核心变化”。上下文窗口足够大，请求也顺利处理，没有报错。但回答中的一个变化，夸大了第三篇报告附录里的一行脚注，而五篇报告共同强调的变化反而被遗漏。分析师问：“都放进去了，为什么还漏？”答案就在问题里：正因为全放进去了，所以漏了。模型并未编造脚注，而是在缺少判断重要性线索的情况下收到数十万 token；在容量充裕的上下文窗口内，无关脚注与关键信号争夺同一个位置。

本章讨论指令以外的内容，也就是模型一次看到的全部信息。我们先解释上下文为何是有限资源，再依次介绍预算表、必要信息筛选、文档元数据与排列顺序、先获取引文及引用功能、检索增强的原理与失败诊断、对话摘要与压缩、长期运行智能体的策略、提示词缓存，以及不可信内容的位置。深入阅读讨论长窗口与检索之间的选择、工具设计，以及将对话状态交给服务器时的注意事项。

核心概念

上下文就是桌面上的空间

桌子大，就能摊开很多文件；可文件越多，越难找到眼下需要的那一张。Anthropic 文档将上下文窗口（context window）解释为一种与训练数据不同的“工作记忆”，它容纳生成回复时参考的全部文本以及回复本身，并强调窗口大并不自动意味着效果更好。输出是否计入同一窗口，因供应商和模型而异。原因是 token 越多，准确率与信息提取能力越差，也就是上下文腐化（context rot）。

Anthropic 的上下文工程文章用注意力预算解释这一现象。在 Transformer 中，每个 token 都与其他所有 token 建立关系；有 n 个 token 时，关系数增长为 n²，每增加一个 token，都要分摊有限的注意力。因此，目标是找到“能最大限度提高获得理想结果可能性的、尽可能小的高信号 token 集合”，也就是有用信息密集的最少 token。如果说提示词工程是打磨指令，那么上下文工程就是每次挑选模型会看到的全部 token。

上下文窗口预算表

制定预算前，先弄清楚哪些内容占用窗口。根据 Anthropic 文档，系统提示词、messages 中所有消息（包括工具结果、图像、文档）、工具定义，以及模型在本轮生成的输出（包括思考），都进入窗口。通过提示词缓存读取的 token 也占用窗口。缓存只能降低费用，不能腾出窗口空间。token 数因语言和写法而异，因此即使是韩语资料，也不要按字数估计，而应使用 token 计数功能测量实际输入。

输出余量尤其容易被忘记。即使窗口很大，单次请求的输出也有独立上限。按 Anthropic 文档，即使最新模型拥有 100 万 token 窗口，单次请求输出最多仍为 128k（约 12 万 8 千）token。要求重写整篇长报告时，输入虽未超出窗口限制，输出却可能因达到上限而被截断，stop_reason 变成 max_tokens。官方文档建议提高限制或接续生成。产出较长的任务，应从一开始就分段，并为每段附上术语表等共同标准。

只挑选必要的信息

放入资料前，先从问题反向梳理。

1. 将问题拆成子议题。 “下半年价格策略的风险因素”可拆成成本变化、竞品价格、需求变化。
2. 为各议题列出所需资料。 成本变化需要采购单价表，竞品价格需要 9 月价格调查。
3. 区分必要与辅助。 区分缺少就会答错的资料，和能使回答更丰富的资料。
4. 选择原文或摘录。 条款比较等重视措辞的任务用原文，背景说明则可用摘录或摘要。
5. 超预算先移除辅助资料。 提前确定删除顺序。
6. 标明没有依据的议题。 资料缺失的议题也向模型标为“无资料”，避免它用常识填补。

目的并非只有节省成本。混入其他产品、年份或部门资料的上下文本身，就会成为错误答案的素材。

为文档附上出处、版本和适用范围

只放内容，模型无法知道哪份文档最新、各自适用于哪里。应为每份文档附加元数据。

<documents>
  <document index="1">
    <source>差旅费规定第4条</source>
    <version>2026-07-01 修订</version>
    <applies_to>正式员工，韩国境内出差</applies_to>
    <document_content>{{RULE_4}}</document_content>
  </document>
  <document index="2">
    <source>差旅费规定第4条</source>
    <version>2025-01-01 修订（已废止）</version>
    <applies_to>仅适用于 2026-06-30 以前的出差报销</applies_to>
    <document_content>{{RULE_4_OLD}}</document_content>
  </document>
</documents>

Anthropic 指南建议，多份文档各用 <document> 包裹，再用 <document_content>、<source> 等子标签分隔内容和元数据。修订日期、生效日期、适用对象，是模型判断“应遵循哪份文档”的依据。如果没有元数据，同时检索到同一条款的新旧版本时，模型可能混合二者作答。

文档彼此矛盾时，元数据尤其重要。只要求“综合整理”，模型可能强行将冲突揉成一句话，或默默舍弃一方。应要求分别整理共同确认的内容、数值或定义不同的内容，以及仅一方拥有的内容，并给出解决规则。例如：“同一条款的新旧版本，以问题基准日正在施行的版本为准。”规则无法解决的冲突，不要擅自化解，而应报告“冲突：文档 1 与文档 3 不同”。

长文档放前面，问题放最后

对于超过 2 万 token 的长输入，Anthropic 建议把长文档放在问题、指令、示例之前。官方测试显示，把问题放在最后，特别是在复杂多文档输入中，回复质量最多可提升 30%。Gemini 指南也建议将具体问题放在最后，用“根据以上信息”等表述衔接前面的资料；OpenAI 指南则举例，将每次请求变化的上下文放在靠后位置。图像也是如此。Anthropic 文档建议图像先于文本，多张图像用“Image 1:”“Image 2:”等标签标注，并通过名称引用。

官方建议是起点，并非适用于所有任务的定律。可默认将关键行为约束放最前、长资料放其后、具体问题放最后；对重要任务，应与不同排列方式的版本比较确认。

先让模型给出引文

从长文档中获取答案时，最大的风险是混入文档中没有的内容。官方指南建议在执行任务之前，先让模型引用相关部分。模型在挑选引文的过程中会聚焦于相关内容，人也可以立即把引文与原文对照。Anthropic 的减少幻觉文档还补充两点：找不到相关引文时要明说；写完回答后，为每个论断寻找支持它的引文，找不到就撤回该论断。

1. 在 <quotes> 中将与问题相关的原文句子编号并原样抄写。
   如果没有相关句子，只写“无相关引文”。
2. 仅以 <quotes> 中的内容为依据，在 <answer> 中作答，每条论断附上引文编号。
3. 从回答中移除无法附上引文编号的论断。

有引用，并不意味着依据充分。还需检查三点。

引用功能与检索结果块

除了通过提示词获取引文，也可使用供应商的引用功能。启用 Anthropic 的 Citations 后，引用内容所在的文本块会附上原文位置：纯文本为字符位置，PDF 为页码，自定义块为块编号。是否有未附引用的论断，仍要另行检查。官方文档列出三个优点：被引用的文本（cited_text）不计入输出 token；API 负责解析引用，保证位置有效且指向所提供文档；其内部评估中，引用语句的相关性高于提示词方式。

纯文本和 PDF 按句引用；对于文字稿、项目符号等需要自行定义单位的内容，可用自定义块输入。此功能无法与结构化输出同时使用，同一次请求若包含启用引用的文档和 output_config.format，会返回 400 错误。两者都需要时，应拆分调用。

自有检索结果可通过 Anthropic 的 search_result 块（出处、标题、内容）输入，从而获得类似网页搜索的带来源引用。Gemini 的 Google 搜索 grounding 由模型自行判断是否需要搜索，并为回复各片段附上出处 URL。频繁更新的公开信息用搜索 grounding，公司内部资料用内部检索结果；二者同时使用时，应让回答的每句话都能区分其依据来自哪一方。

检索增强的原理

检索增强生成（RAG，retrieval-augmented generation）是在提问时查找模型不知道的资料并放入上下文的方法。就像图书管理员听完你的问题，只挑出几本相关的书放到你桌上。

Anthropic 的 Contextual Retrieval 文章指出第 1 步的问题：切割文档后，“营收比上一季度增长 3%”之类片段会丢失公司和时期信息。解决办法是参考完整文档，为每个片段添加简短说明（通常 50～100 token）后再生成嵌入，并用同样的文本建立 BM25 索引。嵌入检索擅长查找含义相似的文本，但对于错误代码、模型名等必须精确匹配字符的查询较弱；基于词语匹配的 BM25 可弥补这一弱点。文章实验中，仅加入上下文嵌入，检索失败率就降低 35%；加入 BM25 后降低 49%；再加重排序后降低 67%。

并非每个问题都需要检索。同一篇文章指出，知识库小于 20 万 token 时，也可以不建立检索环节，直接放入全部资料，再通过提示词缓存减少成本与延迟。资料较小时，最简单的方法可能就是最好的方法。

区分检索失败与回答失败

RAG 给出错误答案时，先改提示词是常见错误。应先区分在哪一步失败。

1. 存储库中是否有正确答案的依据。 没有就是资料问题。
2. 检索结果前列是否有正确依据。 没有就是检索问题，应修改查询生成、索引或检索方式。
3. 依据是否进入了上下文。 若被重排序或筛选排除，应修改筛选标准。
4. 依据已进入上下文，回答是否仍然错误。 到这时才修改生成阶段，也就是指令、编排和引用方式。

要作出这类判断，需要预先准备评估集，将每个问题与正确答案的依据文档配对。第 5 章介绍的评估集，其中一种用途正是如此。

对话摘要与压缩

对话变长，就需要缩减历史。最常见的方法是总结前半部分，但摘要会丢失具体措辞。尤其经过多次摘要后，数值、日期、条件会被模糊成“适当水平”“近期”等表达。因此，应把摘要设计成“工作状态记录”，而非“故事梗概”。

<conversation_state>
  已确定条件：交货数量 1,200 件，交期 11 月 14 日，独立塑料袋包装
  未解决问题：标志印刷颜色（客户确认设计稿后回复）
  决策历史：10 月 20 日完成单价协商（报价单 Q-2026-118）
  下一步行动：收到设计稿回复后，确定印刷规格
</conversation_state>

已确定的值保留原始表达，明确区分已定事项与待定提议，并让每项内容都能追溯来源。保留最近几个轮次的原文，以维持对话连贯性。

也可使用供应商功能。Anthropic 以 beta 形式提供服务器端压缩（compaction），用模型撰写的摘要替换旧轮次，继续对话。如果默认摘要遗漏所需信息，可自行编写摘要指令；需要更精细控制时，可使用上下文编辑功能，按规则删除旧工具结果或思考块。必须保留什么，应由业务负责人确定。

长期运行智能体的上下文策略

连续几个小时调用工具的智能体，上下文很快就会被填满。Anthropic 文章介绍的方法和适用场景如下。

按需加载较慢，但能避免索引过时的问题，并保持上下文轻量。也可以预先放入部分资料，其余按需查找，形成混合方式。

提示词缓存与编排

提示词缓存会保存各次请求重复的前缀，在下一次请求中复用。关键是前缀必须逐字完全一致。Anthropic 按 tools、system、messages 顺序组成前缀，直到缓存点必须 100% 相同才会命中。OpenAI 在支持的模型上也默认开启缓存，只有渲染后的完整前缀一致才会复用。

也要了解费用结构。按 Anthropic 文档，写入缓存比基础输入价格略贵（5 分钟缓存为 1.25 倍），读取则便宜得多（多数模型为基础输入价格的 10%）。默认有效期为 5 分钟，每次使用都会刷新，也有 1 小时选项。OpenAI 表示，最新模型会缓存 1,024 token 以上的提示词，缓存不会改变输出的生成方式。

不可信内容的位置

网页、收到的电子邮件、用户上传的文件和工具结果等，来自我们无法控制的来源，其中可能隐藏着试图操纵模型的语句。这种攻击称为间接提示词注入。它不同于用户亲自发起攻击的直接注入：这里的用户是可信的，攻击路径却是模型代替用户阅读的第三方内容。OWASP 在《大语言模型应用十大风险》（2025）中将其列为第一项风险，并指出，即使采用 RAG 或微调，也无法完全阻止这种攻击。

Anthropic 文档建议，放置这些内容时应遵守以下原则。

1. 第三方内容只放在工具结果（tool_result）内，不放入系统提示词或普通用户文本。
2. 在工具说明或结果结构中，说明这些内容是什么、从哪里来，例如“来自未知发件人的收件邮件正文”。
3. 在系统提示词中明确说明：工具、文档、检索提供的内容是不可信数据，不能覆盖系统提示词或用户原始请求。
4. 对于外部字符串，尽可能将其放进 JSON 对象中再输入。JSON 转义可以明确内容的边界，防止攻击者通过闭合引号或标签，从内容区域脱出并进入指令区域。
5. 反过来，也不要把自己的指令放在工具结果里。这些指令可能被视为可疑内容，或被忽略。
6. 为防备防护被突破的情况，只赋予模型最小权限。不让模型访问任务不需要的机密信息，缩小工具权限范围，并要求危险操作经过人工批准。

对于用户亲自试图破坏规则的直接注入（越狱），Anthropic 文档建议：先用轻量模型检查输入，用已知的攻击措辞验证输入，在系统提示词中规定如何拒绝，并对反复尝试攻击的用户采取应对措施。OWASP 提出的对策也沿着同一方向：限制行动范围、验证输出格式、过滤输入与输出、遵守最小权限原则、危险行动须经人工批准、将外部内容分开标明，以及在假设存在攻击的情况下进行测试。在最受信任的位置，只放入最可信的内容。

深入阅读

全部放入长窗口，还是检索

窗口扩大后，“是不是不检索，全放进去就行”的问题越来越多。答案因任务而异。Google 的长上下文文档指出，查找单条信息的测试可获得高准确率，但同时查找多条信息时无法保持相同准确率。而且每次提问都要重新支付输入 token 费用，输入越长，首个 token 的延迟也越大。

工具设计也是上下文设计

对智能体来说，工具既是它的手，也是它的眼睛。工具定义和工具返回的结果同样会占用上下文，因此，工具如何设计，也就决定了上下文的质量。Anthropic 的文章指出，工具返回信息时应高效利用 token，各项工具的功能应尽量少有重叠。文章还强调：“如果人类工程师都无法明确说出应该使用哪个工具，智能体也不可能做得更好。”

Anthropic 关于工具定义的文档指出，影响工具表现的最重要因素，是为每个工具写出非常详细的说明，至少要有三四句话。说明中应写清工具做什么、什么时候使用、什么时候不使用、各参数的含义，以及它不会返回哪些信息。相似的操作合并为一个带有 action 参数的工具；如果涉及多个服务，则以服务名称作为工具名称的前缀。工具返回的结果只包含下一步判断所需的字段，以及有实际意义的标识符。返回结果过于臃肿，就会浪费上下文空间。

将对话状态交给服务器时

也可把对话历史交由供应商服务器管理。OpenAI Responses API 可用 previous_response_id 串联回复，或用 Conversations API 将对话存为长期对象。根据官方文档，即使用 previous_response_id 衔接，先前回复的输入 token 仍会再次按输入收费。已存储回复默认保留 30 天，store 设为 false 则不保存响应对象。不过，滥用监控日志（默认最多 30 天）等有单独保留政策，需同时阅读数据政策文档。对话对象不受这一 30 天期限约束。应根据费用预算和保留规定选择方式。

推理模型与工具配合时，还需传递先前的推理记录。OpenAI 强烈建议在函数调用后一起传回推理项，在不存储模式下传入加密推理内容（encrypted_content）。Anthropic 则建议将 assistant 轮次连同思考块按 API 返回的原样追加，并说明在部分最新模型中，修改思考块之前的对话会报错或使该块被丢弃。需要改变规则时，不要改写历史，而应像第 1 章的对话中系统消息那样追加。

工作场景

蔚蓝物流：检索 400 份规章的问答机器人

物流企业“蔚蓝物流”运营着一个问答机器人，检索公司内部 400 份规章文档作答。员工有三点不满：回答看似合理，却不知道依据哪条规章；差旅费问题混入休假规定；问 7 月修订的住宿费限额时，有时仍得到旧金额。

负责人文科长先收集 50 个失败问题，逐步判断。其中 3 个问题的正确依据不在存储库里。14 个问题在检索前 30 条中没有正确依据，多数是按“第 4 条之 2”之类条款编号提问。剩下 33 个，依据虽已进入上下文，答案却仍错误。文科长还检查了现有结构：问题放在最前面，下面连续拼接 30 条检索结果，没有边界标记，最后以“请回答”结尾。

他根据诊断，为每一步制定不同措施。

1. 资料。 三个缺依据的问题，内容只在公告栏中而非规章中。他将这些公告交给规章负责部门，纳入规章。
2. 检索。 对需要精确匹配条款号、规章名的查询，在语义检索中加入词语匹配检索。生成查询时，先判定业务类别（差旅、休假、采购），作为检索过滤条件。
3. 筛选。 按相关度重新排序候选，只保留前 5 条。
4. 编排与元数据。 每条保留的规章附上 <document> 标签、规章编号、修订日期、适用对象，放在前面，问题移到最后。废止版本默认排除；若问题涉及过去日期，则同时放入当时有效的版本。
5. 生成。 作答前先将相关条文抄到 <quotes>，回答末尾写规章编号和修订日期。若同一条款新旧版本同时出现，以问题基准日适用的版本为准；无法判断则展示两个版本。

他没有采纳“窗口还有空间，把检索结果增加到 50 条”的意见，因为大量失败正是由混入无关规定造成，增加数量只会放大问题。改进后重跑相同的 50 个问题，大部分都能附上正确依据给出正确答案，输入 token 减至原先的四分之一。员工也能凭答案后附的规章编号直接找到原文。

新光日报：把三年的竞选承诺写成一篇报道

地方报纸“新光日报”数据组的张记者，在市长选举前准备比较四名候选人过去三年的竞选承诺变化。资料包括新闻稿、辩论会文字稿、竞选纲领 PDF、市议会会议记录，总计数百万 token。起初，他按候选人放入全部资料，要求“整理承诺变化”，结果不稳定：某位候选人已撤回的承诺被当成当前承诺，也混入了其他候选人的发言。

张记者从报道的问题反向梳理。报道要回答的是“各领域中，每位候选人当前的承诺是什么，何时改了什么”。领域分交通、住房、照护、财政四类，因此把任务单位拆成“一名候选人 × 一个领域”，为十六项任务分别制定预算表。

资料通过检索挑选。用候选人姓名和领域关键词查询，再仅保留发言者确为该候选人的内容。文字稿按发言切分，附上发言者、日期、活动名称。混入其他候选人发言的问题，借助这些元数据消失了。

生成阶段先获取引文。模型原样抄录承诺语句，按日期排列，再标出与先前发言不同之处。是否撤回等需要解释判断的内容，保留为“待确认”。张记者请同事编写脚本，将引文与原文进行机器核对，筛除所有字词不同的引用。

最后合并阶段，只放入十六张汇总表而非原始资料，制作分领域比较表。每项任务的进度笔记记录已核实的引文和待确认项，确保即使工作跨越多日，也能掌握已完成的进度。

他还记录了放弃的方案。一次放入全部资料直接生成比较表，需要同时查找多条信息，很容易漏掉承诺。先摘要再根据摘要比较，则有日期和数值被模糊的风险，因此他选择积累原文引文代替摘要。报道刊出时，每条承诺语句都附上出处和日期，回应读者咨询的依据也完整保留。

易错点

• 以为窗口大，把全部资料放进去就更有利。 由于上下文腐化，无关信息反而会降低回答质量，同时增加成本与延迟。
• 以为窗口大，就能获得更长的输出。 输出有另外的上限。对于较长的产出，应该划分区段，分段获取。
• 以为先写问题，模型才能知道目的。 对于长输入，官方推荐将文档放在前面，把问题放在最后。关键的行为约束则仍放在前面。
• 以为 RAG 回答错误，就应该修改提示词。 应先判断失败究竟发生在资料、检索、筛选还是生成阶段。
• 以为做成摘要就不会损失信息。 摘要会模糊数值与条件。已经确定的值，应在工作状态记录中按原文保留。
• 以为越是外部资料，就越该放进系统提示词，才能让模型充分采用。 将不可信的内容放在最受信任的位置，会增加提示词注入的风险。
• 以为开启缓存，系统自然就会节省费用。 如果变化的值放在前面，后面的内容就会每次重新计算，缓存几乎无法命中。应把固定内容移到前面，把变量移到后面。

要点速览

查阅官方文档

• Anthropic — Prompting best practices: long context：阅读文档编排、标签结构和先给引文的方法。
• Anthropic — Effective context engineering for AI agents：阅读上下文腐化、按需加载、压缩、结构化笔记、子智能体和工具设计。
• Anthropic — Contextual Retrieval：阅读片段上下文补充、BM25、重排序的效果，以及针对小型知识库的建议。
• Anthropic — Prompt caching：确认缓存顺序、失效条件、有效期和价格倍数。
• Anthropic — Mitigate jailbreaks and prompt injections：阅读应对间接注入的内容放置原则。
• OWASP — LLM01:2025 Prompt Injection：确认直接与间接注入，以及七项对策。

自测

3-1. 用一句话定义上下文腐化，并给出两条反对“窗口大，把相关资料全放进去”这一提议的依据。

3-2. 写出单次请求的上下文预算表应包含的五项组成部分，说明最容易遗漏的是哪一项，以及遗漏后的表现。

3-3. 用标签写出一个包含两份 60 页审计报告和一个问题的提示词框架。每份文档附上出处与编写日期，并要求先给出引文。

3-4. 按检查顺序写出四个用来区分检索增强回答失败阶段的问题，再用一句话解释为何直到最后一个问题才修改指令。

3-5. 因负责人变更，需要将与模型持续数周的活动策划对话交接给新负责人，并在新会话中继续。举出三类必须在交接记录中保留原文的信息，并展示记录格式的示例。

3-6. 某智能体使用相同的长篇指南，但每次请求会按用户权限等级增减部分工具。说明这对提示词缓存造成什么损失，并提出一种在保留权限差异的同时减少损失的方法。

3-7. 设计一个读取竞争对手网站、整理价格表的调查智能体。分别写出：抓取的网页正文应放在提示词的什么位置、采用什么形式；若网页中的隐藏指令突破防护，有哪些减轻损失的防护机制。两部分各写两点。

实操练习