第 10 章 上下文装配策略¶
知道上下文重要还不够，真正困难的是装配。一个 Agent 系统通常同时面对多种输入来源：系统规则、用户输入、任务状态、工具说明、知识片段、历史会话、外部数据和错误记录。问题从来不是“有没有信息”，而是“该选哪些、按什么顺序放、以什么形式放”。
本章讨论的就是上下文装配策略。重点不在某个框架 API，而在工程上如何建立一套稳定的装配原则，让每轮模型调用都尽量具备同样清晰的输入结构。
10.1 装配不是拼接¶
最容易犯的错误，是把上下文装配理解成字符串拼接。系统把各种信息从不同来源拿来，然后顺手拼成一个大 Prompt，看起来什么都没漏，实际上丢掉了结构。
真正的装配应该至少解决三个问题：
- 选择：哪些信息值得进入本轮。
- 排序：哪些信息优先级更高。
- 压缩：哪些信息应保留原文，哪些应被摘要。
如果这三件事没有显式设计，上下文就只是一个不断膨胀的缓冲区，而不是支持决策的工作面。
10.2 任务优先的装配原则¶
上下文装配应始终围绕“当前任务阶段”展开，而不是围绕“信息来源”展开。系统最先应该问的不是“我有哪些数据”，而是“这一步模型要做什么决策”。
例如：
- 如果当前是澄清阶段，最重要的是任务歧义和缺失条件。
- 如果当前是分析阶段，最重要的是相关事实和约束。
- 如果当前是执行阶段，最重要的是工具描述、最新状态和门禁规则。
- 如果当前是总结阶段，最重要的是已确认结论和必要证据。
任务优先的好处是，它天然会帮系统压缩输入。不是所有信息都要在任何阶段都出现，只有能影响当前动作选择的信息才值得保留。
10.3 历史、状态与外部知识的装配顺序¶
一个比较稳妥的装配顺序通常是：
- 稳定控制信息。
- 当前任务目标。
- 当前阶段状态与中间结论。
- 与当前动作直接相关的外部知识或工具结果。
- 必要的近期历史。
这个顺序的意义在于，先让模型知道自己是谁、当前在做什么，再让它知道已经做到哪里、现在掌握了什么依据，最后再补足必要的局部上下文。顺序不是绝对真理，但随意混排通常会增加模型忽略关键信号的概率。
flowchart TB
A["稳定控制信息"] --> B["任务目标"]
B --> C["当前阶段状态"]
C --> D["外部知识 / 工具结果"]
D --> E["必要近期历史"]
E --> F["本轮模型输入"]10.4 摘要、裁剪与去重¶
任何非简单 Agent 系统都会遇到上下文变长问题，而解决方案不可能只是不断换更长上下文窗口。系统必须学会裁剪。
最常见的三个动作是：
- 摘要：把长历史或长工具输出压缩成状态化结论。
- 裁剪：把当前阶段不再相关的信息直接移出本轮输入。
- 去重：避免同一事实以多种形式重复出现。
这里的关键不是压得越短越好，而是压完之后模型还能否继续做出正确判断。一个可用的摘要，应尽量保留结论、依据来源和未解决问题，而不是只剩一段泛泛而谈的概括。
10.5 工具结果与检索结果如何进入上下文¶
很多系统在这一步最容易失控。原始工具日志、完整搜索结果、整段文档片段都被直接回灌给模型，导致上下文预算被迅速耗尽。
更稳妥的做法是分层进入：
- 原始结果先进入状态层或缓存层。
- 再由系统提炼出与当前决策直接相关的摘要。
- 只有在需要逐字证据时，才把原文片段局部放回模型输入。
这意味着工具系统和知识系统都应当具备“面向上下文供给”的二次处理能力，而不是只负责把原始结果返回给模型。
10.6 本章小结¶
上下文装配的本质，不是把更多信息送给模型，而是围绕当前任务阶段选择、排序、压缩和组织信息。一个可维护的 Agent 系统，必须让每轮模型调用都带着明确的输入结构，而不是任由上下文演化成无法解释的文本堆。
下一章会继续讨论上下文装配最常见也最难处理的极端情况：长上下文。当信息越来越多时，系统为什么会开始失真，又该如何压制这种失真。