最近读了一篇很长的技术文章，聊的是 AI Agent 开发里一个越来越重要的话题：Context Engineering（上下文工程）。作者把 Anthropic、Karpathy、Shopify CEO 这些人的观点串在了一起，读完挺有收获，给大家说说里面的核心内容。

大家都知道 Prompt Engineering 对吧？就是琢磨怎么写提示词，让大模型回答得更好。这招在一问一答的场景里很好使，但一旦任务变复杂，要跑几十轮对话、调好几次工具，光靠写好提示词就不够了。Context Engineering 就是在这个背景下出来的。

先说它到底在干什么。你可以把大模型的上下文窗口想象成电脑的内存，空间有限。Context Engineering 干的事情，就是像博物馆策展人一样，从一大堆可能有用的信息里，精挑细选出一小部分放进去。放什么、怎么放、什么时候放，都有讲究。

再说为什么要这么精细地管理。文章引用了斯坦福的一个实验：给模型同时塞十几篇文档，把正确答案放在最前面或最后面，模型答对的概率大概 75%。但如果把答案夹在中间，正确率能掉到 35%，比什么都不给还低。也就是说，塞太多东西进去，反而帮倒忙。另外，随着对话轮次增加，早期设定的规则会被大量新内容“淹没”，模型慢慢就不遵守了，这叫 Context Rot，上下文腐化。

那怎么治？文章讲了三个核心方法。

第一个叫上下文压缩，就是对话快满了的时候，自动把前面的历史总结成一段精华摘要，然后用摘要加最近几轮对话重新开始，腾出空间。

第二个叫结构化笔记，Agent 一边干活一边把重要结论写到外面的文件里，上下文被清掉也不怕，随时能把笔记读回来。

第三个叫子 Agent 架构，遇到大任务就拆成几条线，每条线派一个子 Agent 单独去跑，跑完只把总结交回来，主 Agent 的上下文始终保持干净。

文章还提到了一些常见的坑。比如很多人觉得上下文窗口够大就行了，200K token 随便塞。但窗口再大，无关内容稀释有用信息这件事照样发生，而且窗口越大，计算成本按平方级增长。还有人拼命加工具，十几个功能差不多的工具摆在那里，模型自己都不知道该用哪个。

文章最后给了一句总结我觉得很到位：最优的上下文等于最少的 token 数乘以最高的信噪比。说白了，每一个塞进去的 token 都得有价值，多余的就是在添乱。