为什么 context engineering 又被翻出来

过去半年里，多数 agent 产品都把焦点放在工具调用和长任务上。窗口尺寸的争论一度安静下来，因为 1M 级别的上下文已经不稀奇。

但最近 HN 的几条讨论把这件事换了一个问法：窗口大不大不重要，问题是上下文里到底装了什么、装多久、怎么裁。

三种典型的上下文坏味道

讨论里反复出现的上下文问题可以归成三类。

  • 重复上下文：同样的工具结果、文档段落或对话历史被多次塞回 prompt
  • 无结构上下文：把所有信息平铺，没有显式标注来源、时间和可信度
  • 陈旧上下文：早期的判断已经被推翻，但旧版本仍然留在窗口里

这三类问题都不是模型能力问题，是工程组织问题。

重读成本比想象中高

很多团队默认窗口大就把全部历史塞进去。这看上去省事，实际上每一轮都让模型重新读一遍冗余内容。

重读成本不仅是 token 钱。更隐蔽的是注意力被稀释：相关性最高的几条信息被埋在很多重复内容里，模型在长上下文里的注意衰减问题就会再次出现。

可以先动的几件事

讨论里被反复提到的实践，整理一下可以马上动手。

  • 按角色分桶：系统说明、用户输入、工具结果、检索结果分开，每个桶都可独立裁剪
  • 对工具结果做 dedupe：相同 URL、相同 SQL 查询、相同函数返回值，只保留一份
  • 把判断分版本：当任务方向被推翻时，不要保留旧判断，只保留最新结论加一行替换原因
  • 把检索结果摘要再回填：不要把全文塞进去，先让模型自己抽要点，再把要点带到下一轮

评估上下文质量的一条指标

如果一定要选一个最朴素的指标，可以选可追溯性：模型给出的每一个判断，能不能指回上下文里的某一条具体来源。

可追溯性高的会话，通常上下文也是干净的；可追溯性低的会话，往往上下文已经被噪声淹没了。