上下文工程正在取代提示词工程
两年来的建议都是「把提示词写好」。这条建议在模型变得能稳定遵循指令之后，基本就不再产生收益了。它至今仍然做不到的事情是：推断出你根本没给它的信息。
什么变了
提示词工程优化的是「怎么问」，上下文工程优化的是「问的时候房间里有什么」。当模型已经能可靠地遵循指令，剩下的失败就不再是措辞问题，而是缺失问题：相关文件没加载、工具输出被截断、二十轮之前的决定已经不在窗口里了。
为什么落地团队要在意
上下文是一份有硬上限的预算，而且是整个技术栈里唯一一份会被无意中花掉的预算。没人会故意写漏 token 的代码，大家只是多追加了一次工具返回，然后再多一次，直到窗口里有用的那一半被挤出去。它导致的失败是最糟的一类：不报错，只是答案悄悄变差。
该做什么
先测量。按来源记录每次请求的输入 token：系统提示、检索片段、工具输出、历史对话。多数团队会发现某一类占绝对主导，而且和自己猜的那一类不是同一个。然后按顺序用三个杠杆：第一，别发不需要的东西——把冗长的工具输出隔离起来，返回引用而不是内容；第二，压缩必须发的——总结早期轮次、给重叠片段去重；第三，最后才考虑为更长的窗口付费，这是三者里最贵、效果最差的一个。
最容易跳过的部分
把记忆持久化到窗口之外。一个随上下文一起消失的会话，用户只能手工重建一遍。把持久状态写进 Agent 可查询的存储，给模型一个指针而不是整包数据。这和分页是同一个思路，也是「演示」和「同事愿意用第二次」之间的分界线。