前几天晚上我在调一个 agent，它死活不听话。我塞给它的背景信息够详细了——几十页内部文档、历史对话、一堆规则——但它就是会在最关键的判断上翻车。我第一反应是：是不是 context 不够大？
后来冷静下来，发现方向反了。
先停一下，问个问题：你觉得你塞进 context 的每一段信息，模型都在认真读吗？
我以前是这么以为的。后来看到 Tom Jones 做的一组实验，被绊了一下。他把十条 note 的意思反转，模型十次全跟着翻了——说明这十条确实在起作用。但换个不相关的 lookalike 进去？毫无反应。
这说明什么？只有跟模型已有判断冲突的信息，才真正在消耗 context budget。不冲突的，塞了也白塞。
我一开始也以为多多益善……后来才发现，多多益善的是噪音，不是信息。
再往下呢？Jones 还发现了一个更扎眼的事：他的 pipeline 有个 bug，一部分 note 压根就没送到模型那里——而他一直以为模型在"参考"这些信息。
这事儿我太有共鸣了。我们总默认"我给了，它就会用"。
Vini 提了个很聪明的测试方法：把你觉得模型在用的那段 context 拿掉、改掉、甚至反转，看模型的回答变不变。不变？那它压根没在看。
我现在的判断很明确了：context window 不是越大越好。能不塞就不塞。Nnamdi 举了个例子让我特别信服——一个邮件分类 bot，一开始塞全文，效果差还贵。后来只取 subject 加前几百个字符，准确率反而上去了。
你可能会反对说：那我做 RAG 不就行了？检索只拿相关的。
对。但这层真正的 trade-off 在于：如果 context 管理是你产品的核心，你的检索和过滤层得自己握在手里，不能靠现成的默认配置。自己建 pipeline 更贵更累，但你拥有"什么该进 context、什么不该进"的控制权。把这件事外包给工具的默认行为，等于把产品质量的底线交给了别人的猜测。
Dimitris 有句话我很喜欢：better forgetting is more useful than more context。
再往下就是怎么建一套靠谱的 context 管理层了——什么时候 summarize 什么时候 retrieve——这个我还在摸索，有些地方自己也没完全想通，先放这儿，等踩够坑了再来拆。
