Drew Breunig 在整理的演讲文字里，把上下文工程理解为管理模型此刻能看到的信息。问题不只是窗口能装多少：错误内容可能污染后续判断，过多材料会分散注意力，互不相干的工具或相互冲突的指令也会干扰执行。不同症状需要先区分，不能都靠增加上下文解决。
他梳理了几类做法：按需补充材料、选择工具、隔离不同任务的上下文、修剪历史、把信息存到外部，以及总结。它们都在改变信息何时进入模型、以什么形态保留。尤其值得注意的是他的个人经历：一个使用了半年的 Hermes 对话积累了互相牵扯的修补，旧假设开始让新的处理难以转向。他倾向于留下有用产物，再重开对话。
这篇材料的价值是把工程选择与具体症状连起来。作者使用的上下文阈值和长期对话经历属于个人经验，不能当作所有模型的统一上限；本期读的是完整文章及演讲文字，没有观看视频，也没有逐篇复核文中引用的全部研究。
可信度 65 · 重要性 84 · 新颖度 73
技术与主题
Agent 系统 · AI 编程 · 检索与知识 · Context Engineering · Prompt Caching · Agent Memory
Drew Breunig
作者自己的长期 Agent 使用经验。
忠实转述（非原句）：他把长期对话里旧思路难以摆脱的现象称为上下文惯性。保存工作产物后重新开始，是他处理这一问题的办法；这不代表重开次数越多越好。
agentdev001
HN 评论；描述考虑过但尚未测试的自动修剪方案。
忠实转述（非原句）：他曾考虑让快速模型在压缩前修剪历史，但担心删除中间内容会破坏后续前缀缓存。对他而言，速度并非主要瓶颈，所以目前更关注工具输出；他希望有实际基准来比较，并未声称自动修剪已经改善结果。
jdw64
HN 评论中的个人使用观察，没有给对照实验。
忠实转述（非原句）：他补充另一端的困难：上下文太少也会出现奇怪行为。因此问题是给出足够且相关的信息，不能把缩短长度本身当成目标。
编辑评读
最值得迁移的做法，是把“值得保留的成果”与“产生它时的猜测”分开。比如调试时确认过的复现输入、测试结果和当前代码可以交给下一轮，而已经被排除的原因应标明失效。若把整段推理压缩成一条肯定结论，虽节省长度，却可能把暂时假设变成下一轮的前提；摘要质量因此要看它保留了哪些判断条件。
但频繁删改也会付出成本。缓存依赖可复用的输入前缀，抽走中间一段可能使后续内容重新计算；另一方面，保留所有历史又可能让过时要求继续影响模型。可以先观察何种变化会使任务的目标或约束真正失效，再决定重开对话；日常信息读取则尽量按需进行。这个方法把稳定执行与更新判断分开处理，尚未证明是最优策略。实际比较还需要同时看旧假设造成的返工、缓存费用和恢复任务所需的人工说明。
需要留意
- 文章方法梳理与作者经验；未验证全部引用论文，也未把个人阈值推广到所有模型。