第 10 章 · 上下文窗口解剖

本章目标：把上下文看成有限工作台，而不是无限记忆。你要知道每类内容为什么进入、占多少、何时退出。

1. 上下文里到底装了什么

编码 Agent 的一次模型请求可能同时包含系统规则、项目指令、用户目标、历史消息、工具定义、已读文件、命令输出、记忆和当前计划。它们共同占用模型窗口，但价值并不相同。

系统规则和当前目标通常优先级最高；最近的真实工具结果决定下一步；大段旧日志往往价值迅速下降；工具目录如果有几百项，也会在任务开始前消耗大量空间。

2. 容量不是唯一问题

即使没有达到硬上限，内容过多也会产生检索困难。关键要求埋在早期对话，几十个相似日志互相干扰，模型可能关注最近但不重要的信息。这被称为上下文污染或上下文腐化。

因此优化目标不是“塞得下”，而是让当前决策需要的证据更突出。一个 128k 窗口装满无关材料，可能不如 16k 的精心上下文可靠。

3. 上下文预算

可以为不同类别预留预算：

预算不是死比例。调试任务可能需要更多日志，架构任务需要更多代码地图。Runtime 可以根据任务类型动态调整。

4. 工具输出是最大噪声源

一条测试命令可能输出上万行。正确结果对象应保留退出码、关键错误、头尾片段、截断标记和完整日志路径。模型先使用摘要，只有诊断需要时再调用 read_log 读取局部。

同样，大文件应支持按行读取和搜索。把 5000 行文件一次送入模型，不仅贵，还让下一轮更难聚焦。

5. 延迟加载

Skills 和 MCP 工具常使用渐进披露：开始时只提供名称和简短描述，模型选择后才加载完整说明。项目记忆也应先检索索引，再读取相关主题。这个模式可以概括为“先给地图，需要时再展开地形”。

子 Agent 是另一种上下文治理：让探索或日志分析在独立窗口进行，主 Agent 只接收摘要。它既节省主上下文，也减少中间噪声改变主任务判断。

6. 本章实验

实验 04 把系统、历史、文件和日志画成可调预算条。尝试让总和超过 100%，再分别选择丢弃旧输出、摘要和子 Agent。观察它们释放空间的方式不同，也会丢失不同信息。