第 6 章 上下文工程与长任务

6.1 模型每轮究竟看到什么

本章目标：会分配输入预算、构造保留证据的摘要、判断资料何时需要重新读取，并理解上下文恢复与任务恢复的区别。

在运费任务中，模型可能同时看到系统规则、用户需求、工具描述、源码、失败日志、此前计划和旧文档。上下文窗口只提供有限空间；把所有信息塞进去还可能引入重复、冲突和不相关内容。模型看到了信息，也不保证它一定正确利用。

Effective context engineering for AI agents [导读] 把重点放在每轮选择高信号的信息。Prompt 是其中的指令部分；上下文工程还要决定哪些工具结果、历史和外部证据现在进入输入，哪些只留路径等待取回。

6.2 用一个预算算式安排内容

以下是应用自己设定的教学预算，不是某个产品的窗口规格：一次调用最多规划使用 16,000 token，预留 4,000 给输出，于是输入目标是 12,000。真实限制还需核对模型、请求格式和 token 计数方式，并留出封装误差。

合计 12,000。若一次测试输出占 20,000 token，应在工具层提取关键失败与获取完整日志的路径，不能直接挤掉用户规则。预算应在组装输入前检查，不应等模型报超长后才临时删掉最早的内容。

保留优先级也不是“越新的越重要”。早期明确的负数拒绝规则可能比刚读到的无关 README 更重要。优先依据任务约束、当前决策需求和证据价值，再考虑新旧顺序。

6.3 摘要应该压缩过程，保留可追溯状态

“已经修得差不多，继续测试”不是有效交接。另一个会话无法知道改了什么、哪些通过、哪些还没验证。更好的摘要类似下面的应用记录：

{
  "goal": "修复普通/会员/负数运费规则",
  "constraints": ["保持函数签名", "负数优先拒绝"],
  "facts": [{"claim": "初始边界、会员、负数检查失败", "evidence": "trace:call-1"}],
  "workspace": {"file": "pricing.py", "revision": "after-patch-hash"},
  "done": ["读取实现", "写入候选补丁"],
  "pending": ["运行当前版本测试"],
  "unknown": ["其他调用者是否依赖旧行为"],
  "artifact_paths": ["logs/initial-checks.json"]
}

这里的 done 不包含“修复完成”，因为当前补丁尚未验证。事实、计划、推断和未知事项分栏，可以减少摘要把猜测升级成结论。保留证据位置，使模型必要时回到原始内容，而不是不断总结上一份摘要。

对于关键约束还可以做确定性检查：摘要必须包含函数签名、负数规则与待测试状态。这样的检查只保证字段和部分内容保留，不保证全文语义完全正确，重要信息仍需人工抽样或任务级评测。

6.4 按需读取如何避免“省 token 却找不到信息”

把大日志留在文件中、上下文只放路径，可以降低输入成本；但策略要知道文件存在、里面有什么、何时该打开。一个有用的索引至少包括路径、内容摘要、版本和读取方式。

例如先给模型 pricing.py 路径与函数名，失败后读取对应函数；只有看到接口冲突才查调用者。完全不提供目录线索会增加盲目搜索；一次把全部仓库装入输入又会浪费预算。常见折中是短目录地图、关键约束和按需证据共同进入上下文。

读取有时间成本，也有失效风险。补丁更新后，旧片段不能继续充当当前源码。应让读取结果携带版本，遇到版本变化使相关推断与测试记录失效。参考运费实验中的哈希约束。

6.5 压缩后忘记了什么，怎样验证

设计三种配置：最近历史；状态摘要加最近历史；尽量多的原始历史。用相同任务、模型与预算比较，而不预设全量输入最好。评测至少包含：是否遗漏用户条件、是否重复失败方案、是否引用旧代码、最终通过率、调用费用与耗时。

一个具体故障是压缩后只记住“改 >=”，忘记会员条件；另一个是保留“测试通过”而忘记其版本。你可以把摘要手工删掉一个字段，观察下一轮是否能从文件或验收重新找回。恢复成功来自保留索引和重新验证，不是摘要永不丢信息。

这也解释摘要与笔记的区别：摘要面向当前模型输入，工作笔记面向跨会话的任务状态；二者可以重叠，但不必每轮完整注入。持续累积的笔记也要整理，否则只会把聊天历史换个位置堆起来。

6.6 长任务恢复：不能只把旧聊天读回来

中断发生在写文件之后、记录结果之前，恢复者可能不知道写入是否成功。它要核对实际文件和操作状态，不能直接重做所有动作。上下文摘要帮助理解目标，持久轨迹帮助定位步骤，工作区快照帮助判断当前状态，幂等机制帮助处理未确认副作用。

恢复流程可写成：加载目标与约束 → 核对工作区版本 → 找到最后已确认操作 → 处理未决动作 → 重新验证必要证据 → 继续计划。对于外部发送或部署，不确定状态要查询，而不是假定可回滚。

第 11 章 Context Engineering 与长任务 harness 会把这些机制放进更完整的运行系统。这里先掌握“模型可见上下文”与“环境实际状态”两层，否则恢复很容易成为重复执行。

6.7 练习与参考检查

在 repair_lab.py 的 budget 输出中读取前三步，只用 150 字写一份交接摘要。参考摘要应该指出：目标三条规则、初始测试失败、候选已写入、当前版本未验证、下一步测试。把它写成“全部修复且测试通过”属于事实错误。

再删掉摘要中的负数规则，让同学只看摘要继续任务。要求他说明如何从原始目标或资料取回约束，若取不回就标记未知。本章交付物是一份摘要、一个原始证据索引和一次故障恢复说明，而不仅是一段更短的 prompt。