上下文工程

去年这个时候,团队里讨论得最多的还是"这句 system prompt 该怎么措辞"。有人为了一个 Agent 不肯老老实实调用工具,把 prompt 改了三十多版,加感叹号、加大写、加"这非常重要"——最后发现真正起作用的,是把那个工具的描述从一坨 200 行的 JSON Schema 砍到 40 行。 prompt 没救活它,砍上下文救活了它。 这件事在 2026 年已经不是个例。Chroma 在 2025 年做过一组实验,测了 18 个当时最强的模型,结论很扎心:每一个模型,输入一长,准确率都会掉。有的模型能在 95% 稳住一阵,然后一旦输入越过某个长度,直接跳水到 60%。模型不是线性变笨的,是到了某个点"塌方"。 所以 2026 年大家嘴里挂着的词,从 prompt engineering 变成了 context engineering(上下文工程)。这不是换个时髦说法。它是承认了一件事:模型每一次推理,看到的是整个上下文窗口,而不只是你那段精心打磨的 prompt。 窗口里还有工具定义、历史对话、检索回来的文档、记忆、上一步工具吐出来的一大坨结果——这些东西你不管,它们就替你"管"了模型。 prompt engineering 没死,它只是被降格了 先把关系说清楚,免得误会。 context engineering 不是来取代 prompt engineering 的。Anthropic 在那篇《Effective context engineering for AI agents》里说得很直接:prompt engineering 是 context engineering 的一个子集。 写好一段指令,依然重要;只是它现在只是你要操心的众多东西里的一个。 两者问的问题不一样: prompt engineering 问的是:“这句话我该怎么措辞?” context engineering 问的是:“模型这一刻,到底需要看到哪些信息?” 一次性的任务——翻译一段话、改写一封邮件——prompt engineering 基本够用。但只要你做的是 Agent,是那种要跑很多轮、要调工具、要记住前面发生过什么的系统,问题立刻就变了。你面对的不再是"一段 prompt",而是一个随着每一步在不断变化的上下文状态。这个状态怎么攒、怎么裁、怎么压,就是 context engineering。 ...