上下文不是越多越好：上下文工程

任务分解解决了"一个任务块多大"的问题。但每个任务块执行时，Agent 的上下文窗口里装什么，同样关键。

直觉做法是把所有可能相关的信息都塞进去：完整的架构文档、所有相关模块的代码、历史设计讨论记录、项目的 README。信息越多越好，对吧？

实践表明恰恰相反。社区实验观察到：冗长或噪声上下文会降低成功率并提高推理成本，即使远未达到 token 上限。更多上下文导致信息之间相互竞争注意力，关键信息被噪声稀释。

上下文污染有六种典型类型。

过时污染。过时的文档、注释、架构图进入上下文，Agent 基于过时信息做出决策。代码已经重构了三次，但架构文档还停留在第一版。

冲突污染。多个信息源优先级不明，Agent 面对矛盾信息做出随机选择。第二章的信任环机制可以缓解这个问题，但前提是冲突被识别并标注。

推理污染。Agent 被要求跨多个文档进行推理时，可能在推导过程中引入错误。文档 A 说"用户 ID 是 UUID"，文档 B 说"订单表的外键是 user_id"，Agent 推导出"订单表的 user_id 字段是 UUID 类型"。但实际上订单表是遗留系统，user_id 是自增整数。

压缩污染。上下文过长时，部分工具或框架会自动压缩历史内容。压缩过程中可能丢失关键信号，而保留的信息可能不是最重要的。

共谋污染。AI 生成的测试验证 AI 生成的代码，第三章已经讨论了这个问题。

遗留污染。废弃的代码模式、死代码、已弃用的 API 进入上下文，Agent 将其视为有效参考并复制这些模式。

应对上下文污染的核心原则是：设计时分层，执行时扁平化。在设计和组织阶段，信息按层级结构管理（信任环、文档分类、优先级标注）。但在 Agent 实际执行时，将分层的文档展开为一份扁平的、自包含的输入文档。避免 Agent 在执行过程中跨层推理，因为跨层推理是推理污染的主要来源。

基于优先级的信息筛选决定了什么进入上下文窗口。P0 信息（规约、当前任务的验收标准、直接相关的 API 契约）必须在上下文中。P1 信息（相关模块的接口定义、架构约束）根据空间选择性包含。P2 及以下的信息（背景讨论、历史决策、参考资料）默认排除，仅在 Agent 明确需要时按需提供。

上下文窗口是稀缺资源。对它的管理和对服务器内存的管理遵循同样的原则：装不下所有东西，所以需要决定什么该在、什么该出、什么该缓存到外部。