上下文工程的核心方法

继续看相关机制：F28 · 检索先找候选，再判断能否回答F27 · 压缩要保留行动所依赖的事实O10 · 压缩、检索与Prompt Cache：三种不同的“省”

上下文工程的对象是“本轮决策”

本篇对应Effective Context Engineering。核心问题不是怎样塞进更多资料，而是下一步需要哪些约束、事实、状态和工具信息。内容的价值随任务阶段变化。[S084]

原创例子：调查阶段需要失败日志和调用关系；实现阶段需要接口约束与相关代码；交付阶段需要补丁与最新验证。把所有历史无差别复制给每一轮，既增加成本，也可能保留旧假设污染。

一个可执行的信息分层

把输入分为稳定约束、当前任务状态、当前证据、可重读历史四层。稳定约束应短而明确；状态记录已完成与未完成；证据带来源与版本；历史留在外部并有可查路径。

这不是要求引入复杂数据库。小项目可以用简洁文件和工具结果引用实现。只有检索、更新或多用户规模出现实际瓶颈时，再增加基础设施。

五种减负方式不能混用

选择是不加入；裁剪是删除；摘要是改写；外置是保留在别处；重检索是需要时再取回。Prompt Cache则是计算复用，不改变这些内容本身的语义职责。[S092][S039]

每种方法都可能失败。没加入可能漏证据，删除可能丢失败线索，摘要可能改变确定性，外置可能引用失效，重检索可能找错版本。设计应明确补救路径。

一个前后对比

原创压缩前历史有：十次搜索、三种已排除原因、一个未确认假设、两次失败测试和一个禁止改动的接口。

压缩后应保留目标、禁止条件、已排除原因及依据、当前假设状态、最新修改和验证。不能只留下“调查了很多，准备修复”，因为那不能指导继续工作。

怎样判断“更多内容”是否有害

长上下文研究说明容量与有效利用不同，但不能把特定研究结果泛化成所有新模型必然在某位置失败。应在自己的任务中测量。[S085][S087][S088]

原创实验固定必要证据，只增加无关日志；再固定总长度，增加需要同时满足的约束。两组分别测干扰和组合复杂度，比只测能否找到一句话更贴近工程。

完成本篇后，应能为每段上下文回答“为什么现在需要它、何时可以移除、以后如何取回”。