上下文工程的核心，是管理信息预算

上下文窗口越来越长，很多人自然会得出一个结论：既然能装下更多内容，那就把所有资料、日志和历史对话都塞进去。

实践中，这往往适得其反。

长上下文解决的是容量问题，不自动解决注意力问题。模型仍然需要从输入中判断什么重要、什么过期、什么彼此矛盾。当无关资料持续累积，真正关键的约束反而会被淹没。

把上下文当作预算#

上下文可以看成一笔有限预算，而不是仓库。每一段内容进入窗口前，都应该回答一个问题：它会改变这一步的决策吗？

如果不会，先不要放进去。

这条原则会带来三个动作。

一个任务进行了二十轮讨论，不代表第二十一轮需要读取全部二十轮。通常真正需要保留的是：

这类信息应该被压缩成短小、可追溯的 handoff，而不是复制整段聊天记录。

环境文档、项目资料、历史会议纪要可以存在外部知识库中。需要时检索相关片段，而不是默认注入全部。

这种做法的收益很直接：减少噪声、降低成本、让信息更新只发生在一个来源。对于不断变化的项目资料尤其重要。

任务切换时，旧任务的临时细节不应继续占用新任务的注意力。一个好的阶段交接应当把旧上下文压缩成结论，并让新任务从明确的起点开始。

每次准备给 Agent 加更多上下文时，可以检查：

最后一问最有效。答案是否定的内容，通常不值得占用窗口。

上下文工程不是“塞更多”，而是“留下更少但更有用的东西”。