OpenAI 这周发了 GPT-6，朋友圈又开始了新一轮“把整个代码库喂进去”的炫耀。我不反对大窗口，但窗口越大，越多人放弃思考什么该进场。把几万 token 历史原封不动递给模型，成本涨了，效果反而经常掉——这不是什么注意力涣散的玄学，是噪声把指令位挤占了。
窗口怎么切，终于从“装不下”的问题变成“不知道什么该进来”的问题。
窗口变大，垃圾也变大了
先看一个极端例子。SENTINEL-RL 做的是企业安全运营中心（SOC）：几千台主机的认证关系图，根本塞不进任何上下文窗口。他们的做法很干脆——不塞了。拓扑推理单独做成专用模块，LLM 只负责下游的决策和解释，用代码查完图再把结论喂给模型。
这比任何裁剪技巧都彻底：先问“这个信息必须让模型想吗”，答案是否定的，就把它移出上下文。窗口最狠的切法不是删文本，是搬任务。
普通场景没这么极端，但预算意识要有。我自己习惯把上下文预算分三段：系统约束固定占一块——角色设定、工具定义、红线规则，这些被截了模型立刻变傻，没得商量；任务状态单独占一块——正在改哪个文件、当前计划走到哪一步，这是会话的脊梁；剩下所有位置才给检索结果、历史证据、工具输出，满了就从最不相关的往外扔。比例我没法给你拍个数，自己调两轮就能找到感觉，判断标准很简单：系统提示被截的代价，永远比少给一段参考资料惨得多。
裁剪顺序：工具输出最不值钱
如果只能靠纯文本裁剪，我的顺序很死板：先砍历史工具输出，再砍旧轮对话，最后动系统提示。这个顺序不是拍脑袋定的，是按“丢了对当前决策伤害最小”排的。
工具输出往往最长，同时冗余最大。跑一次测试，几千行日志，真正有价值的可能只是退出码加最后几行报错。保留命令、退出码、报错尾部就够，中间的输出全是“当时有用、现在没有”的中间态。
砍旧轮对话要细心。不能把用户意图变化也砍掉。我会保留每轮用户的原始请求，哪怕只是一句原话；要折叠的是 assistant 的长篇解释和工具调用过程，把它压成一行状态写进去。结论比过程值钱，但“用户最初到底想干什么”不能丢。
系统提示是钉子户，最后才允许动。它当然可以精简，但原则是删措辞、不删实体。一个工具名、一个权限 ID、一条硬性禁止项从系统提示里消失，模型后面可能完全不知道该调什么工具，而且你很难在几万字历史里发现是哪个词导致它跑偏的。
摘要不是免费的，它是一次模型调用
很多人把“窗口快满”和“做个摘要”画等号。我现在越来越怀疑这个默认操作。
摘要的本质是一次额外的生成调用，而且是有损压缩。模型很可能把“这块逻辑别碰，上周刚修过”压成一句废话，也可能把你在第三轮说的“不要用 Redis”直接丢掉。等到第二十轮它自作主张选了 Redis，你翻遍整个摘要都找不到原始出处，只能接受一个注定会犯的错。
过早摘要尤其危险。有些细节当时看着没用，后面几轮才成为约束。与其急着一把梭哈成五百字梗概，不如先按上面的顺序砍掉工具输出,让原始对话多活几轮。真要摘要，就把“不可丢约束”单独拉出来让模型逐项确认——多花一次调用，好过丢一条约束。
状态放文件里，别压在窗口里
Hacker News 上那篇 Agent memory as a file format 讲的是把 agent 的长期记忆写成盘上的结构化文件，而不是每次灌进 prompt。这个方向和上下文预算是暗合的：任务状态本质是程序数据，不是自然语言，用的时候让 agent 去查对应文件段落，比整段躺在窗口里划算得多。
Meta 安全研究员那个 agent 误删邮件的新闻，也顺手提醒我另一件事：你越把整个邮箱倒给模型、“它自己看着办”的空间就越大，踩雷的概率越高。上下文是一种信用额度，不是仓库。你把额度花在哪，模型就会往哪出错。