案例分析二：Data Analysis Agent 为什么 SQL 越查越多，最后反而又回到已排除方向？

场景背景

Agent 分析，“为什么昨天收入下降？”

前10轮已经确认：

请求量稳定
曝光略降
eCPM 大幅下降
media_B 异常

但后面继续下钻：

媒体
广告位
地域
系统版本
APP
时间段

每轮 SQL 都返回几十行数据。

系统把所有原始查询结果都保留在 Context。

第25轮时，Input 已经非常大。

模型突然又开始：

按请求量查媒体

为什么？

前面的关键结论：

请求量稳定

只是埋在几十个 SQL Result 中的一小段。

没有结构化 Working Memory。

也没有 Compaction。

模型需要从大量旧数据重新找重点。

结果就容易重复。

正确改造

Working Memory：

Completed:
- 已确认 request 稳定
- 已确认 eCPM 是主要异常指标
- 已确认 media_B 是主要异常来源

Next Action:
下钻 media_B 的 position eCPM

同时旧 SQL 结果：

保留摘要
不再全部放 Context

结果

Context 变短。

分析路径反而更稳定。

Data Analysis Agent 的问题本质类似，只不过被淹没的不是安全规则，而是已经确认过的分析结论。前面明明已经确认 request 稳定、eCPM 和 media_B 异常，后续几十份原始 SQL 结果却把这些结论重新埋了起来。

把关键结论写进结构化 Working Memory，再把旧 SQL 结果从“全文常驻”改成“摘要 + 可检索原始记录”，Context 会更短，下一步下钻方向反而更连续。

复盘

这个案例说明，Context 太长的问题，不只是 Token 成本。

它会直接影响：

推理连续性
工具选择
重复调查
任务效率

所以 Context Window 管理是 Agent 质量问题，不只是性能问题。

常见误区

误解： Context Window 就是模型最多能接收多少用户文字。
正解： Context Window 面向的是整个模型调用上下文，包括 System Prompt、Conversation、Tool Result、Working Memory、Tool Schema 等输入，同时还要给本轮输出留下空间。对于 Agent 来说，用户输入往往只占很小一部分，真正大的经常是代码、日志、SQL 结果和 Tool Schema。

误解： 只要还没超过模型硬上限，就不需要做 Context 管理。
正解： 即使没有达到硬限制，过长上下文也会增加成本、延迟和噪声，让模型更容易忽略关键规则、重复调查或被旧错误误导。Context Engineering 的目标不是“勉强不报错”，而是让当前最重要的信息始终清晰、相关、可行动。因此通常在高使用率阶段就应该提前准备压缩。

误解： Agent 上下文爆炸主要是用户聊得太多。
正解： Agent 的主要膨胀来源往往不是用户消息，而是 Tool Result、代码文件、运行日志、异常栈、SQL 查询结果以及多步模型输出。用户可能只问一句“帮我修 Bug”，Agent 内部却跑 30 步。真正需要监控的是整个 Run 的上下文增长，而不是用户对话轮数。

误解： 解决 Context Window 最简单的方法就是只保留最近 20 条消息。
正解： 这种策略容易误删早期但非常重要的规则，例如“禁止修改 tests/”。更合理的是把高优先级规则、Current Task、Working Memory 独立保存，再对老 Conversation 和 Tool Result 做裁剪或压缩。上下文管理应该按语义重要性，而不是只按时间顺序。

误解： Tool Result 是真实数据，所以应该全部原样保留，避免丢信息。
正解： 原始数据可以保存在 Session Store、Trace 或文件系统，但不代表每轮都必须重新放进 LLM Context。真正应该进入当前 Context 的，是下一步决策需要的信息。大日志、完整 traceback、几千行 SQL 结果可以保留在存储中，只把摘要或关键片段送给模型。

误解： Context Window 越大的模型，就越不需要做 Context Engineering。
正解： 更大的窗口只是让问题推迟出现，并不会消除内容冗余、重复、冲突和注意力稀释。Agent 一旦运行足够久，仍然会积累大量环境信息。即使模型支持很大的窗口，把大量 Token 每轮重复发送，也会增加成本与延迟，因此 ContextBuilder、Working Memory 和 Compaction 依然重要。

误解： Run 的累计 Token 超过模型窗口，就说明这个 Run 一定已经发生 Context Overflow。
正解： Context Window 限制单次模型调用，Run 累计 Token 是多次调用实际用量的总和。十次各用 8K 的请求会累计 80K，但每次仍可能都在 16K 窗口以内。判断超限要看当前请求的 Input 加预留 Output；评估成本才看整个 Run 的累计值。

误解： 开启 Prompt Caching 以后，Context Window 就不用管了。
正解： 缓存可能降低重复前缀的成本或延迟，但不会自动删除不相关内容，也不能保证扩大模型的上下文上限。缓存与压缩可以同时使用：前者优化重复计算，后者控制当前请求真正携带什么。