从提示词工程到上下文工程：大模型应用的下半场

做过大模型应用的同行大概都有这种体验：演示环境里效果惊艳，一旦接入真实业务就明显下滑。问题往往不上下文工程管三件事。一是写入什么：系统指令、少量示例、检索到的知识片段、工具返回结果、历史摘要，都要有明确取舍，把整份接口文档原文塞进请求只会淹没关键约束。二是何时写入：稳定内容放靠前的固定位置落地时我建议分四层。指令层放角色设定和输出格式约束；知识层放按需检索的文档片段，并带上来源标题和更新时间，方便事后排查幻觉来自哪份材料；状态层只放与本次意图相关的字段，不要把整个对象序列化进去；还有三件容易被忽略的小事：长内容放前面、短指令放后面，缓存命中率更高；召回十条不如精排三条，片段过多会让模型在相近表述之间摇摆；工具返回值不要原样入库，在中间层做一次字段裁剪常常能省下三分之一的输入长度。如果你的应用正卡在效果瓶颈上，先别急着换模型，把送给模型的上下文完整打印出来，逐段问一句这段内容本轮推理真的需要吗，答案通常会让你意外。史层是对话历史加一句滚动摘要。前两层放开头，后两层随轮次追加，这样更容易命中推理服务的前缀缓存。每轮变化的内容放靠后。三是如何淘汰：早期的工具原始输出可以优先裁剪，改过两轮的需求描述总结成一句话即可。模型本身，而在你塞给模型的那段上下文。这就是业界把重心从提示词工程转向上下文工程的原因。