上下文：Agent 真正的瓶颈

所属：第二部分 · 让它做对事的四块地基（第 5–8 章） 前置：第 4 章（一轮循环、协议状态、结果回填）、第 2 章（上下文装配）、第 1 章（上下文窗口、有效上下文） 本章新概念：本轮工作集、上下文工程、外置、外置材料管理、检索、压缩、上下文隔离（含子代理隔离）

一、上一章留下的问题¶

上一章的例子是：Agent 接到「查本周公开资料，写一页纸并附出处」的任务后，先搜索并抓回三篇网页，再把工具调用和返回结果逐轮回填。为了看清循环过程，示例把模型每轮返回的内容继续追加到下一轮输入；因此三篇网页正文、搜索过程和工具结果都会留在后续上下文里。

这个写法适合看清调用、执行和回填，却藏着一个危险的默认值：已经出现过的内容，后面每一轮都继续带着。

对只调用一两次工具的小任务，这个问题未必最先暴露；对会反复查资料、保留证据并运行多轮的 Agent，上下文往往是最早出现的系统瓶颈之一。本章标题里的「真正」指的正是这类长任务，不是说工具、验证、权限和规划都不再重要。

在那份调研任务里，搜索标题只占几行，真正抓回网页后，材料会很快变成这样：

• 三篇网页正文，每篇几千 token；
• 模型为了找到它们而试过的搜索词；
• 已经执行完的工具调用和返回结果；
• 两次失败记录，其中一次后来已经重试成功；
• 用户最初要求的一页纸格式和出处要求。

下一步只是比较三篇网页，写出三条有出处的结论。全留，模型要在整条轨迹里重新找重点；全删，出处、限制条件和还没解决的冲突也会一起消失。

所以问题不是「历史要不要保留」，而是：

下一轮为了把下一步做对，究竟需要看到历史里的哪一部分？

答案可以先压成一句：上下文不该承担整次任务仓库的职责；其中由 Agent 运行系统主动选择、装配的任务内容，构成本轮工作集。 运行系统可以在模型外保存很多材料；每次调用只装入这一步需要的部分，并为没装入的关键材料留下回查路径。

二、窗口还没满，任务可能已经先坏了¶

模型的六个性质已经介绍过上下文窗口、有效上下文和 context rot（上下文腐坏）。这里再把模型外的状态与材料、运行系统主动装配的工作集放进同一套坐标：

所以，本轮工作集是运行系统可以主动设计的任务视图，不等于接口最终呈现给模型的全部内容；它也只占上下文窗口的输入侧一部分，还要给输出和模型相关的推理过程留出空间。以 OpenAI 当前的上下文窗口说明为例，输入、输出和 reasoning token 都计入总量；其他接口的具体记账方式仍要看对应文档。

运行系统保存了一篇网页，不等于模型这一轮看到了它；模型这一轮看到了它，也不等于能稳定找到并使用其中每一处信息。

这里记住 context rot 的边界即可：Lost in the middle（迷失在中间）在所测的某些长文本任务和模型里发现，关键信息位于中间时，任务表现往往比位于开头或结尾更差；它没有给出一条「超过多少 token 必然失效」的通用定律。

2025 年，Chroma 在一份长上下文技术报告里共测试了 18 个当时的模型。在其中的 LongMemEval 对话问答实验里，完整输入平均约 11.3 万 token，聚焦到相关信息后的输入平均约 300 token；参与该实验的模型在聚焦版本上的表现都明显更高。约 300 token 的聚焦版本依据数据集标注的相关部分并经人工调整得到，接近 oracle 输入，不是一个真实检索系统自动找出的结果；实验没有证明选择过程可以没有成本、漏检或召回错误。这组结果只支持实验范围内「聚焦输入优于完整输入」，不能推出「越短越好」，也不能给 2026 年的某个模型划出通用清理阈值。它能推翻的只是一个直觉：只要窗口还装得下，多放无关材料就不会伤害结果。

完整保留历史的 Agent 循环会把这个问题放大。普通长文是一次放进去；Agent 的网页正文、工具结果和失败记录还会进入后续多轮。无关内容不只占位置，还可能与当前目标竞争、互相矛盾，或者让已经完成的旧步骤看起来仍然需要处理。

更大的窗口提高了硬上限，却没有替你决定什么值得进入本轮。previous_response_id 可以让服务端接续状态，提示缓存可以复用部分重复前缀，它们也都没有替你完成这次选择。

三、上下文工程：让工作集足够、聚焦、可恢复¶

提示词工程通常更关注怎样表达要求、示例和约束；**上下文工程（context engineering）**关注范围更广的运行时选择与装配：每一次调用时，运行系统要决定哪些要求、工具、状态、历史和证据进入，在什么时点进入，以原文还是摘要进入，又有哪些材料和调用应该留在本轮之外。两者有重叠，不是互斥的两个抽屉。

它的理想目标可以叫最小充分集：不缺少下一步的承重信息，也不携带没有明确用途的内容。但工程上通常不可能在运行前算出绝对的「最小」，所以更可执行的检查是三项：

给手上每份材料问三个问题，就能开始做这件事：

1. 以后需要回查完整材料或任务状态吗？现在不放，能不能可靠地取回来？
2. 下一步会直接用到它吗？
3. 下一步需要原文，还是摘要已经够？

如果面对的不是一份材料，而是一条会大量探索的支线，再多问一句：主线需要看完整过程，还是只需要结果和证据？

围绕这些问题，Agent 运行系统可以做四种常见操作：外置、检索、压缩和隔离。这里的运行系统，是负责调用模型、执行工具、保存状态和装配下一轮输入的应用程序。四种操作不是模型快照自动拥有的能力：模型可以帮助选择材料、拟写摘要或处理一条支线，但真正把内容写到哪里、读回什么、让哪些内容进入下一轮，仍由运行系统组织和执行。

四种操作改变的不是同一件事，也不是四选一。对于需要保留回查路径的长任务，可以依次检查四件事：先安置需要保留、可回查的材料与状态，再选本轮需要的部分，接着决定保留原文还是压成摘要，最后划定主线和支线的可见边界。

这是四个维度的检查顺序，不是必须串行执行的流水线：某一层可以不采取动作，多个动作也可以在同一次工具调用里完成。对同一篇网页，运行系统可以先把原文保存到外部存储，再把标题和短说明交给模型选择；入选后，可以在独立调用里生成证据卡；需要核对数字时，再按来源编号读回原文片段。

四、外置：把材料与任务状态放到窗口之外¶

对这份需要回查原文的调研任务，先处理存放位置。否则后面无论少取还是压短，都可能把唯一版本一起丢掉。

一份内容有两个去处：

• 窗口内：内容已经进入本轮请求，或者由服务端作为本轮调用的接续状态提供给模型；模型这一轮可以处理它，但它会占用上下文。
• 窗口外：内容保存在文件系统、对象存储或数据库等外部存储中；它不会自动进入模型当前这一轮，需要时必须由程序或工具重新读回。

让材料或任务状态的完整版本保存在窗口外，只在需要时把相关部分读进窗口，同时保留稳定的回读路径，就是本章所说的外置。这里的「外」是相对于模型当前这一轮上下文而言，不是说内容已经离开整个 Agent 系统。同一份原文可以完整保存在窗口外，同时只把其中一小段复制进窗口内。

外置由运行系统真正执行。网页正文可以写入文件存储，结构化记录可以写入数据库，任务进度可以写入一份 JSON 或 Markdown。保存时，运行系统还要分配稳定编号或路径，并记录来源、保存时间和当前状态。模型可以帮助整理任务状态，但只有运行系统把结果写入外部存储后，它才真的被保存。

窗口外通常需要分开保存三类东西。它们都能帮助任务继续，却承担不同职责：

例如，运行系统给三篇原始材料分配 S-01、S-02、S-03 三个来源编号后，可以定期把下面这份任务状态写到窗口之外：

目标：写一页本周监管动态，三条结论，每条附出处
已确认：S-01 与 S-02 讨论同一份咨询文件
未确认：S-03 所说的生效日期在原文里没有找到
已完成：三篇材料已保存并生成证据卡
下一步：回读 S-01、S-03 中关于日期的段落

有明确未来复用意图的持久任务状态，工程上常被称为外部记忆。但不能把磁盘上的所有文件都算作模型的记忆。模型不会因为磁盘上多了一个文件，就自动知道文件里写了什么。 外部存储只让信息能够持续存在；这一轮能不能使用，仍取决于运行系统有没有把相关部分重新装进上下文。

只把文件写出去还不够。运行系统在保存时，还要给材料附上来源、保存时间和状态，例如「待核对」「已核对」「已被新资料推翻」；原始材料还要保留版本或抓取时间，主张—证据记录还要保留具体定位和限定条件，任务状态还要标明最后更新时间。模型生成的摘要若未经核验，就应按「模型生成，待核对」保存，而不是直接记成事实。把外置材料与这些回读、标注和更新动作合起来，可以称为外置材料管理。

外置让暂时不需要的材料不必反复进入后续每一轮输入。没读回时，它不占当前窗口；读回之后，它仍会占用上下文并产生输入处理量。因此，外置只回答「材料存在哪里、以后怎样找回来」，还没有回答「这一轮究竟应该读什么」。后一个问题由检索解决。

五、检索：本轮只拿需要的部分¶

原文已经外置，下一步才是决定本轮取回什么。有些信息现在用不上，却可能在更晚的时候承重；删除太冒险，原样装入又没有必要。这时，运行系统先把轻量线索装进本轮上下文，例如标题、URL、来源编号、日期、文件路径和一句用途说明。标题、URL 和日期通常来自原始来源；来源编号、保存路径、保存时间和用途说明，则由运行系统在保存材料时记录。模型先看这些线索，再提出要读哪些来源；程序或读取工具负责把选中的内容真正读回来。

要让按编号回查的检索可靠，至少要满足三点：材料仍可访问，指针能稳定定位到它，程序也有可用的读取路径。缺少其中任何一个，就不能保证以后拿得回来。

等下一步真的需要，再检索相关内容：

1. 先看标题和短摘要，判断哪几个来源可能相关；
2. 再打开选中的来源，取回与当前问题有关的段落；
3. 要逐字引用时，最后回到原文核对原句和位置。

这不是一次性的开场动作。Agent 每推进一步，当前子问题或所需材料的粒度都可能变化：挑材料时需要标题，比较说法时需要相关段落，核对出处时需要原句。每个下一步开始前，都要重新决定取回范围。需要什么就取什么，比一开始把所有可能相关的内容全塞进去更接近本轮任务。

但检索不保证只带回正确材料。它可能漏掉同义说法，可能被一个看起来很像的结果带偏，也可能因为来源编号失效而取不回来。

所以「没有检索到」只能说明这一次没有找到，不能自动写成「原资料里不存在」。任务状态里应该保留「还缺什么」，让运行系统换查询、扩大范围或请人判断，而不是让模型用已有材料补出一个确定结论。

判断规则很简单：现在不用、以后可能用、而且能可靠重取的内容，先留指针，不留全文。 每一轮都需要的核心约束则不适合这样做；反复检索它们只会增加新失败点。

六、压缩：决定材料以多细的形式进入¶

外置决定材料存在哪里，检索决定本轮取哪一部分，压缩决定选中的材料以原文、片段还是更短状态进入。

「压缩」常把三类不同动作混在一起：

最粗暴的是截断：超过某个长度，就按位置直接删。它不知道被删掉的是重复日志，还是用户最初那条不能违反的要求。应用摘要多做了一步判断：先找出旧内容里仍会影响后续的部分，再把它们改写成更短的任务状态或证据记录。服务商的对话压缩处理的则是接口调用历史：服务商把较长的历史转换成后续调用可以继续使用的内容，运行系统再按接口要求把它接回去。这三种动作都能减少后续输入，却不能互相替代。

压缩前先看清正在缩短什么，以及后续还要靠它完成什么。压缩任务轨迹时，至少要保留：

• 当前目标与输出要求；
• 已确认的结论，以及每条结论对应的来源编号；
• 关键数字、日期、否定和适用条件；
• 互相矛盾的证据和尚未回答的问题；
• 已完成的事项，以及失败过且不该立刻重试的动作；
• 原始材料存在哪里，怎样重新取回。

把一篇八千 token 的网页压成一句「监管趋严」，几乎一定压过头了。它没有说明谁监管谁、哪项要求变严、什么时候生效，也没有保留出处。下一轮读到这句话，只能接着猜。

压缩单份来源时，至少要保留主张、支持片段、限定条件、来源与具体定位，以及核验状态。更可用的结果例如一张待核验的证据卡：

来源 S-02 · 标题与 URL 已保存

• 主张：这是一份征求意见文件，不是已经生效的最终规则
• 支持片段：原文中把三项要求写成「拟议要求」，并给出反馈截止日
• 定位：正文第 2 段；原文 raw/S-02.json
• 限定：不能据此推出最终实施日期
• 核验状态：模型提取，待回原文核对

这张卡不是原文的替代品。它是给后续步骤用的索引和工作状态。能回到「同一个来源」还不够，还要检查定位到的具体片段是否真的支持这条主张；同主题不等于有蕴含关系。需要逐字引用、核对数字或判断一个例外时，仍要回到原文。

因此压缩有三条边界。

第一，先保存，再压缩。 模型生成的摘要是有损变换，不能覆盖唯一一份原始材料。

第二，先保全，再变短。 Anthropic 在 2025 年的上下文工程文章里也建议先提高召回——尽量别漏掉会影响后续的内容——再逐步删掉多余信息。否则摘要越短，任务反而越不可恢复。

第三，在稳定检查点压缩。 一条工具调用已经提出、结果还没有回填时，调用编号、调用请求和返回结果仍要完成配对，不能因为「看起来很长」就删掉其中一半。对本章这份调研任务，适合压缩的检查点还包括：原始材料已经保存，阶段性任务状态也已经写到窗口外。运行系统应先保证任务能够从这里恢复，再缩短此前轨迹。

服务商的对话压缩，与运行系统自己制作证据卡不是同一份产物。OpenAI Responses API 的压缩说明就是一个例子：服务商生成的接续内容用于让后续调用继续，不是人类可审计的证据摘要，也不会替运行系统保存原始材料、管理核验状态或决定本轮该读哪一份来源。使用这类能力时，运行系统应按对应接口的要求接续它，不要把自己写的一段任务摘要冒充接口状态。

七、隔离：让支线过程不要进入主线¶

还有一种噪音不是来自一篇材料，而是来自一整条支线。

假如主循环的一个支线任务是「查清某项规则到底何时生效」。这条支线可能搜索八次、打开十篇网页、遇到三个死链接，最后只得到两句话：目前找到的是咨询稿，不是已生效规则；两份可靠来源都没有给出生效日。

主循环真正需要的是这两句话、来源和未决点，不需要那十几次探索的全部过程。运行系统可以为这条支线建立独立上下文，让它在自己的范围内探索，再只把主线完成下一步所需的结果交回来。

这属于上下文隔离。如果支线按固定步骤做一次摘要，它只是独立模型调用；如果支线能循环、调用工具并自行决定下一步，它才是子 Agent，这时也可以称为子代理隔离。模型可以在支线里分析和选择动作；运行系统负责创建独立调用、提供必要背景、保存支线材料，并控制哪些结果回到主线。两种做法起作用的都是可见边界：

• 运行系统只把子任务、判断标准和必要背景装进支线上下文；
• 支线模型提出查询或读取请求，运行系统执行工具并保存过程材料；
• 支线结束时，运行系统只把结论、证据、缺口和来源编号交回主线。

隔离保护的是主循环的工作集，不保证整项任务更省 token。支线仍然读了那些网页，也增加了模型调用；如果几个支线重复搜索，总处理量反而可能更高。

这种只把标准化结果交回主循环的交接通常是有损的。主循环后来若需要支线没写进结果的一项细节，就必须有办法回到支线保存的原始材料。子 Agent 的输出只是一个待检查的中间结果，不是事实本身。只有能回到原始来源，核对具体内容确实支持该结论时，才算证据。

这里的隔离只是信息边界，也不是安全边界。网页里的恶意文字仍然可能误导负责摘要的模型；把一段不可信内容先交给另一个模型读，不会把它自动洗成可信内容。

八、四种操作怎样放进同一个任务¶

四种操作不是四个同层选项。面对一批材料，可以沿着四层检查：

回到那份「查本周公开资料，写成一页纸并附出处」的任务。四层判断可以沿着同一条材料生命周期配合：

1. 搜索工具拿回三篇网页后，运行系统先把原文外置保存，同时记录来源编号、URL、保存时间和状态。
2. 运行系统把标题和短说明装进主循环；模型据此选择可能相关的来源，读取工具再把选中的段落检索回来。不相关的原文继续留在窗口外。
3. 运行系统可以调用模型，把每篇入选材料改写成带具体支持片段、限定条件、缺口和原文编号的证据卡；这是压缩。证据卡按「模型生成，待核对」保存，不能覆盖原文。
4. 如果制卡在独立调用里完成，运行系统只让主循环接收证据卡，不接收原文和制卡过程；这是隔离。
5. 比较时若发现两张卡对日期说法不一致，模型提出回查来源，运行系统再按来源编号读回相关原文段落。一轮结束后，运行系统把已确认结论、未决点和下一步写进任务状态。

第一步为材料回查保留路径，第二至第四步让本轮足够而聚焦，第五步则在发现缺口后补回承重信息。每到一个新步骤，都重新做这四层判断。

先安置需要保留、可回查的材料与状态，再选本轮需要的部分，接着决定保留原文还是压成摘要，最后划定主线和支线的可见边界。

九、省下了什么，又丢掉了什么¶

用一笔简化的账看压缩什么时候值得做。下面所有数字都是为了观察变量而设的假设，不是某个真实系统的测量结果。

假设三篇原文合计 24,000 个输入 token，三张证据卡合计 2,400 个。拿到材料后，主循环还要调用模型四次：第一次比较三篇材料，第二次处理互相矛盾的说法，第三次组织三条带出处的结论，第四次检查一页纸格式和出处是否完整。真实 Agent 不一定这样拆，也不一定需要四轮；这里固定为四轮，只为了看「同一批材料在后续重复出现几次」怎样改变输入量。

下表只数这批材料带来的输入量，不数固定提示、工具描述、生成的输出、缓存和价格，也先不计中途回查额外片段的输入：

第二行的 33,600 等于 24,000 加上四乘 2,400。前一个 24,000 表示生成证据卡时，摘要调用仍要先读一次原文；后面的 9,600 表示四轮主循环各带 2,400 token 的证据卡。它不是账单预测，只是在相同四轮假设下比较原文和证据卡的重复输入。

这张表真正说明的是：压缩省掉的是大材料在后续多轮里的重复处理，不是让第一次阅读免费。 如果拿到材料后只剩最后一次调用，先做模型摘要反而可能增加调用和延迟。

压缩还可能丢掉细节。这里由模型生成的证据卡不是无损编码，不保证保留 24,000 token 原文的每一处信息。少掉的可能只是导航和重复段，也可能恰好是后来承重的一句例外。

因此不能只看 token 变少。至少要一起检查四件事：

1. 最终答案是否仍覆盖所有要求；
2. 每条结论能否回到具体支持片段，而不只是回到同主题的来源；
3. 数字、否定和适用条件是否在压缩前后保持一致；
4. 累计输入 token、额外调用数和延迟是否达到原先设定的目标。

任何一项失败，都要能回退：换回更完整的片段、扩大检索范围，或者修改证据卡规则后重新生成。

Anthropic 在 2025 年 9 月 29 日公布过一组能说明方向、但不能直接外推的内部评测结果。在一项复杂、多步的 Agent 搜索内部评测中，自动清掉陈旧工具调用和结果，使评测表现相对基线提高 29%；把同一种清理与外部记忆工具组合时，相对基线提高 39%。在另一项 100 轮网页搜索评测中，前一种清理使 token 消耗降低 84%。

这三个数来自 Sonnet 4.5 发布时期的 Anthropic 内部评测。公告没有公开绝对分数、样本量、具体评分指标、统计不确定性和完整配置；29% 和 39% 都是各自相对基线的改善幅度，84% 说的是 token 消耗，不是账单。它们不能当成任何 Agent 清理上下文后都会得到的收益。可迁移的结论是：上下文管理既可能改变 token 消耗，也可能改变任务表现，两者都必须在自己的任务上测。

没有自己的测试题，压缩得更短只是一个肉眼可见的变化，不是质量提升的证据。

十、三条结论¶

一，Agent 运行系统要围绕下一步装配本轮工作集，而不是把整次任务的仓库都当成输入。 工作集只是实际上下文中运行系统主动选择的部分；上下文窗口约束输入、输出和模型相关推理过程的总容量，不保证其中的信息都能被稳定利用。

二，在需要保留回查路径的长任务里，四种操作对应四层判断。 外置处理存放位置，检索处理本轮范围，压缩处理表达粒度，隔离处理可见边界；它们可以组合，不能互相冒充。这些操作由 Agent 运行系统组织，模型可以参与判断和生成内容，但不会自动完成存储、读取和可见范围控制。

三，工作集变短不是成功标准。 任务要求仍然满足、主张能回到真正支持它的具体证据、关键限定没有丢，同时重复处理量达到目标，才说明这套上下文管理对当前任务有效。

十一、这一章引出的问题¶

主循环现在不再吞下三篇原文，但入口仍然很笨：为什么一次搜索非得同时返回标题、链接、整篇正文和摘要？如果模型当前只想先看标题，这个工具根本不给它选择。

下一章从工具本身下手：工具应该切多细，名字、描述和错误结果怎样改变模型的下一步。

十二、自检题¶

1. 一个模型有一百万 token 的上下文窗口，为什么仍不该默认把三十篇网页全文都放进去？
2. 外置、检索、压缩和隔离分别由谁组织？模型可以参与哪些部分，不能自动完成哪些部分？
3. 一个代码 Agent 连续跑了二十次测试，磁盘上有完整日志和补丁历史。下一步只需定位当前失败，另有一条依赖升级支线可能反复查文档、跑测试。四种操作分别该怎样用？
4. 原始材料、主张—证据记录和任务状态分别有什么作用？为什么后两者不能覆盖原始材料？
5. 为什么工具调用请求已经出现、结果还没回填时，不适合随意压缩这段轨迹？
6. 把三篇网页分别交给三个独立调用，再只把证据卡交给主循环，为什么可能让主循环更干净，却不一定降低整项任务的 token？

十三、参考答案¶

先自己答完再往下看。

1. 窗口只说明装得下，不说明都该装，也不保证模型能在这项任务上稳定利用每一处信息。 无关正文会增加处理量和干扰。应该从下一步需要什么出发，保留原文、摘要或指针，而不是从剩余容量出发。
2. 四种操作都由 Agent 运行系统组织。 模型可以提出查询、选择来源、生成摘要或处理支线；运行系统负责真正写入和读取外部存储、装配每轮输入、创建独立上下文并控制交接。没有这些程序动作，模型不会因为「想保存」就把内容写进磁盘，也不会自动看见窗口外的材料。
3. 先外置保存每次运行的完整日志、补丁和稳定编号；再检索当前失败的报错、相关测试和最近改动；把此前尝试压成「做过什么、结果如何、下一步是什么」的任务状态，但保留当前堆栈等承重原文；最后隔离依赖升级支线，只让它交回版本变化、测试结果、证据和未决点。 如果状态不够，就按运行编号扩大检索，而不是让主循环猜。
4. 原始材料保留可回查的原貌；主张—证据记录把一条主张接到具体片段、限定和核验状态；任务状态保存目标、进度、决定和未决问题。 后两者都可能由模型生成或经过有损整理，不能替代原始材料。需要引用、核对数字或判断例外时，仍要回到原始材料；主张—证据记录还必须确认具体片段确实支持对应主张。
5. 调用请求和结果还没有完成配对。 调用编号、模型输出和随后回填的结果是同一段接口状态。中途删掉其中一部分，可能破坏消息协议，也会让下一轮不知道动作的真实结果。到达已回填、可总结的稳定检查点后再压缩。
6. 隔离减少的是主循环可见的支线过程，不是让支线不用处理材料。 三个独立调用仍然要读正文、生成证据卡，还可能重复搜索。主循环的工作集会更聚焦，整项任务的总调用量和总 token 却可能增加。

上一章：第 4 章　一轮循环里到底发生了什么 下一章：第 6 章　工具设计：让模型选择哪些动作，怎样说明这些动作