上下文工程:比 Prompt 更重要的是给模型什么信息
Words: 927Read Time: 3 minLast edited: 2026-8-4
去年大家还在卷 prompt engineering,各种「万能 prompt 模板」满天飞。今年风向明显变了,业内开始讲 context engineering(上下文工程)——Karpathy 和 Shopify 的 CEO 都聊过这个词。我自己的体感也一样:同一个模型,prompt 改来改去提升有限,但把「喂给它什么信息」理清楚之后,效果立刻不一样。
上下文里装的到底是什么
一次 LLM 调用的输入,远不止你敲的那句话:
- 系统提示:角色、规则、输出格式
- 工具定义:函数签名和描述
- 检索结果:RAG 捞回来的文档片段
- 记忆:用户偏好、历史结论
- 对话历史:包括之前每一轮工具的返回
prompt engineering 关注的是「最后那句指令怎么写」;context engineering 关注的是这一整盘东西怎么组织、放什么、不放什么。模型没有自己的信息来源,你塞给它什么,它的世界就是什么。
窗口不是越大越好
现在模型动不动上百万 token 的窗口,很容易产生「全塞进去再说」的冲动。我的教训是别这么做。
2023 年那篇 Lost in the Middle 的论文就指出,模型对上下文开头和结尾的内容印象最深,中间部分容易「迷失」。我在自己的知识库问答里验证过:检索结果从 3 段加到 15 段,答案质量不升反降,模型经常引用错片段。
另外两个现实问题:
- 成本线性增长:10 万 token 的输入,每轮对话都重新计费
- 噪声稀释信号:无关内容越多,模型越容易被带偏
实战中的压缩与裁剪
我现在组上下文的策略,按收益排序:
- 先删再加。历史消息里的工具返回(比如一整段命令输出、整个文件的 dump)在后续轮次里直接裁掉或换成一行摘要,它们大多已经完成使命了
- 检索求精不求多。RAG 只放 top 3~5,宁可少放
- 稳定内容往前放。系统提示、工具定义这些不变的内容放最前面,还能吃到 KV cache 的前缀命中,省钱
- 记忆结构化。别记流水账,维护一份几十行的「用户档案/项目状态」文档,每轮更新,比塞 50 轮历史对话有效得多
一个简化版的组装逻辑大概长这样:
最大的坑是我曾把一个工具返回的两万行日志原样留在上下文里,后面每一轮都带着它计费,模型还总拿日志里的旧错误说事。加了一行「工具返回超过 500 token 自动截断」之后,成本降了一半,答案反而更准。
一句话总结
prompt 是「怎么问」,context 是「给它看什么」。模型能力差不多的情况下,后者的差距就是应用效果的差距。与其收藏 prompt 模板,不如花时间把你喂给模型的信息管好。
Loading...