1. 从Prompt Engineering到Context Engineering一次被逼出来的范式转移过去两年我参与过不少LLM应用从0到1的搭建也帮团队做过大量Prompt调优。说实话早期那种“把提示词写得漂亮一点”就能显著提升效果的红利期早就过去了。现在你打开任何一个稍微复杂点的Agent项目会发现真正决定成败的往往不是那句提示词写得多精妙而是模型在每一次推理时到底“看到”了什么。这就是Context Engineering要解决的核心问题。先把这个概念说清楚。Context Engineering直译过来是“上下文工程”指的是围绕LLM的上下文窗口系统性地设计、组织、压缩、检索和动态注入信息的工程实践。它和Prompt Engineering最大的区别在于Prompt Engineering关注的是“怎么问”而Context Engineering关注的是“模型在回答之前它的上下文里应该有什么、以什么形式存在、按什么优先级排列”。为什么这个转变是必然的因为Agent类应用的复杂度上来了。一个典型的ReAct风格Agent单次任务可能要经历十几轮“思考-行动-观察”的循环。每一轮都要把历史对话、工具返回结果、系统指令、当前任务状态全部塞进上下文。如果只是简单拼接上下文窗口很快就会被撑爆而且大量无关信息会稀释模型的注意力导致推理质量断崖式下降。我见过太多项目Prompt写得无可挑剔但因为上下文管理混乱Agent跑到第五轮就开始“胡言乱语”。所以这篇文章我想从一线工程的角度把Context Engineering这件事拆开讲透。它适合正在做LLM应用、Agent系统、RAG管线的开发者也适合那些发现“Prompt调不动了”的团队技术负责人。我会讲清楚它的核心构成、和ReAct等范式的关系、实际落地时的关键决策点以及我自己踩过的那些坑。2. Context Engineering到底在工程上管什么2.1 上下文窗口不是“越大越好”的垃圾桶很多人有个误区既然现在模型支持128K甚至更长的上下文那我全塞进去不就行了实测下来这个想法非常危险。原因有两个层面。第一是成本。上下文长度直接决定推理费用尤其是高频调用的Agent场景token消耗是线性甚至超线性增长的。我做过一个粗略测算一个中等复杂度的Agent任务如果每轮都把完整历史塞进去到第十轮时单次调用的输入token可能是第一轮的8到10倍。这不是小数目。第二是效果。学术界有个被反复验证的现象叫“Lost in the Middle”当上下文很长时模型对中间部分信息的召回率明显低于开头和结尾。也就是说你塞进去的信息越多模型真正“用上”的比例反而可能越低。这就像你给一个人递了一百页资料让他现场答题他大概率只会翻前几页和最后几页。所以Context Engineering的第一个工程决策就是什么该进上下文什么不该进什么该以压缩形式进。这需要你对任务的信息依赖关系有清晰判断而不是无脑堆砌。2.2 上下文的四个层次系统层、任务层、记忆层、观察层在实际项目里我习惯把上下文分成四个层次来管理这样职责清晰也方便做动态裁剪。系统层是相对静态的部分包括角色设定、输出格式约束、安全边界、工具使用规范等。这部分通常变化不大但要注意的是它应该放在上下文的最前面因为模型对开头信息的遵循度最高。任务层是当前这一轮要解决的具体目标比如“用户想查询上季度华东区的销售数据”。它需要足够明确但也不能太啰嗦。我的经验是任务描述控制在两三句话内把关键约束点出来即可。记忆层是最容易被忽视也最考验工程能力的部分。它包括长期记忆跨会话的用户偏好、历史结论和短期记忆当前会话的对话历史。长期记忆通常需要外部存储加检索短期记忆则需要做滚动压缩。我一般会用“摘要关键实体”的方式压缩历史对话而不是保留原始逐字记录。观察层是Agent执行过程中工具返回的结果、环境反馈等。这部分信息量大、噪声多必须做过滤和结构化。比如一个搜索工具返回了20条结果你不能全塞进去而要提取最相关的3到5条并且统一格式。把这四层分开管理之后你会发现上下文的组装变成了一个可配置、可测试的工程问题而不是靠感觉拼字符串。2.3 动态组装上下文不是拼一次就完事真正复杂的Agent场景里上下文是每一轮都要重新组装的。这意味着你需要一个上下文管理器它能在每次模型调用前根据当前状态决定哪些记忆要召回、哪些观察结果要保留、哪些历史要压缩、哪些工具描述要动态加载。我自己的做法是维护一个“上下文预算表”。比如给系统层分配500 token任务层300 token记忆层2000 token观察层3000 token留出余量给模型输出。当某一层超预算时触发对应的压缩策略。这个预算不是拍脑袋定的而是根据实际任务的token消耗分布反复调整出来的。这里有个很实用的技巧把工具描述做成按需加载。很多Agent项目一上来就把所有工具的完整schema塞进系统提示结果光工具描述就占了两三千token。实际上你可以先只给模型一个工具名称列表等它决定要用某个工具时再动态注入该工具的详细参数说明。这样能省下大量上下文空间。3. ReAct范式下上下文是怎么被“消耗”掉的3.1 拆解一次ReAct循环的上下文膨胀过程ReActReasoning Acting是目前Agent最常用的范式之一它的核心循环是Thought → Action → Observation → Thought → ...。看起来简洁但每一轮都在往上下文里追加内容。我拿一个真实案例来拆。假设用户问“帮我查一下北京今天天气如果下雨就提醒我带伞。”第一轮上下文里有系统提示、用户问题、可用工具列表。模型输出Thought和Action调用天气查询工具参数是“北京”。第二轮工具返回了天气数据这段Observation被追加进上下文。模型再输出Thought今天有雨需要提醒用户。然后调用提醒工具。第三轮提醒工具返回执行结果模型输出最终回答。看起来只有三轮但如果你把每一轮的完整上下文打印出来会发现token数在快速攀升。到第三轮时上下文里已经包含了前两轮所有的Thought、Action和Observation。如果这个任务再复杂一点比如需要查多个城市、对比多个数据源循环次数轻松上十轮上下文膨胀会非常严重。3.2 上下文膨胀带来的三个典型故障我在实际项目中遇到过三类由上下文管理不当引发的故障非常有代表性。第一类是“指令遗忘”。当上下文太长时模型会逐渐忘记系统提示里的格式要求。比如你要求它每次输出JSON跑到后面几轮它开始输出自然语言了。这不是模型能力问题而是系统指令被淹没在了大量中间内容里。第二类是“工具误用”。当历史Observation里包含大量工具返回的原始数据时模型可能会把某些数据误认为是当前可用的工具参数导致调用错误。我遇到过模型把上一轮搜索结果的URL当成新一轮的API端点直接发起了一个无效请求。第三类是“推理死循环”。上下文里保留了太多失败的尝试记录模型会倾向于重复之前的错误路径而不是尝试新方案。这有点像人陷入思维定势越看之前的记录越觉得只能那么做。解决这三类问题的核心思路是一致的不要让上下文无限增长要有主动的压缩和清理机制。比如每三轮做一次历史摘要把已经完成的子任务从详细记录压缩成一句话结论对于失败的尝试只保留“某方案不可行”的结论删掉具体过程。3.3 用“状态机”思路管理Agent上下文后来我换了一个思路不再把Agent看成一条不断追加的对话流而是看成一个状态机。每个状态有自己独立的上下文需求状态切换时只保留与当前状态相关的信息。具体做法是定义一个任务状态对象包含当前阶段、已完成子任务列表、待办子任务列表、关键实体和约束。每次调用模型前根据当前状态动态生成上下文而不是把历史全量传入。这样上下文长度基本是恒定的不会随轮次增长。这个思路的代价是需要额外维护状态逻辑但收益非常明显推理稳定性大幅提升token成本可控而且调试起来容易得多——你可以单独测试每个状态的上下文组装逻辑。4. 上下文压缩与检索工程落地的核心战场4.1 摘要压缩什么时候压、压到什么程度上下文压缩最常用的手段是摘要。但摘要不是随便压的压得太狠会丢关键信息压得太松等于没压。我的经验是分场景处理。对于对话历史我通常按“轮次”压缩。比如每5轮对话做一次摘要保留用户的核心诉求、已达成的结论、未解决的问题。摘要长度控制在原文的20%到30%。对于工具返回结果我按“信息密度”压缩。结构化数据如JSON通常保留关键字段即可非结构化文本如网页内容则提取与当前任务最相关的段落。这里可以用一个小模型来做提取成本低且效果好。对于系统指令原则上不压缩但可以拆分。把必须每轮都遵守的硬约束放在最前面把参考性的说明放在后面这样即使后面被截断核心约束还在。4.2 检索增强不是所有记忆都值得召回长期记忆的召回是另一个关键点。很多项目一上来就做向量检索把top-k个记忆片段全塞进上下文。但实测下来召回数量比召回质量更容易出问题。我的做法是先做粗排用向量相似度召回10到20条候选再做精排用一个小模型判断每条候选与当前任务的相关性只保留最相关的2到3条。而且召回的记忆要带上时间戳和置信度让模型自己判断是否采信。还有一个容易被忽视的点记忆的格式。原始对话记录作为记忆召回效果往往不如结构化摘要。我一般会把记忆存成“情境-行动-结果”的三元组形式召回时直接注入这个结构模型理解起来更高效。4.3 上下文隔离多Agent协作时的信息边界当系统里有多个Agent协作时上下文管理会变得更复杂。我的原则是每个Agent只看到自己需要的信息。比如一个负责搜索的Agent不需要知道最终输出的格式要求一个负责格式化的Agent不需要知道搜索的中间过程。这需要设计一个上下文路由层根据Agent的角色和当前任务从全局状态中抽取相关字段组装成该Agent的专属上下文。这样做的好处是每个Agent的上下文都很短、很聚焦推理质量和速度都会提升。5. 那些文档不会告诉你的实操坑5.1 上下文顺序的微妙影响前面提到“Lost in the Middle”但具体怎么排还是有讲究的。我的实测经验是最关键的约束放开头当前任务放结尾参考信息放中间。因为模型对开头和结尾的注意力最集中。另外工具返回结果如果很长尽量把最重要的字段放在最前面。比如一个搜索结果列表把标题和摘要放前面把完整URL和元数据放后面。这样即使后面被截断核心信息还在。5.2 Token计数不是精确科学不同模型对token的切分方式不同同一个字符串在GPT和Claude下的token数可能差10%到20%。所以做上下文预算时一定要用目标模型对应的tokenizer来计数不能拿一个通用估算糊弄。而且很多API返回的usage字段是事后统计的你不能依赖它来做实时预算。我的做法是在本地用tokenizer库预先计算留出10%到15%的余量。5.3 上下文缓存的双刃剑现在很多模型支持上下文缓存比如把系统提示缓存起来复用这确实能省钱。但要注意缓存的内容一旦更新缓存就失效了。如果你把动态内容也放进缓存区会导致频繁失效反而增加成本。我的做法是严格区分静态区和动态区。静态区放系统指令、工具schema、固定示例这些内容长期不变适合缓存。动态区放任务描述、记忆召回、观察结果每轮都变不参与缓存。5.4 调试上下文问题的实用手段当Agent行为异常时第一件事应该是把完整上下文打印出来。我见过太多人盯着Prompt改来改去结果问题出在上下文里混入了脏数据。我一般会做一个上下文可视化工具把四个层次用不同颜色标出来并且显示每部分的token占比。这样一眼就能看出是不是某一层膨胀了或者某条记忆被错误召回了。另外建议在开发阶段保留每次调用的完整上下文快照方便做回归测试。当你调整了压缩策略或召回逻辑后可以用同一批历史快照跑一遍对比输出变化。6. 从Prompt到Context一个团队的能力升级路径6.1 角色分工的变化在Prompt Engineering时代调优工作往往由一个人完成写提示词、测效果、改措辞。但Context Engineering涉及检索、压缩、状态管理、工具编排等多个模块很难由一个人包揽。我观察到的趋势是团队里开始出现专门的“上下文工程师”角色或者由后端工程师和算法工程师协作完成。后端负责状态管理和数据管线算法负责召回策略和压缩模型。这种分工下接口设计变得很重要——上下文管理器应该是一个独立的服务对外提供“给定状态返回组装好的上下文”的能力。6.2 评估体系的建立Prompt时代评估很简单拿一批测试问题看输出对不对。但Context Engineering的评估要复杂得多因为上下文是动态变化的。我建议从三个维度建立评估任务完成率最终目标是否达成、上下文效率token消耗与任务复杂度的比值、推理稳定性多轮运行的结果一致性。这三个指标能帮你判断上下文策略是否健康。6.3 工具链的选型思路目前市面上还没有一个“开箱即用”的Context Engineering框架更多是靠组合现有工具。我的选型原则是状态管理用成熟的工作流引擎检索用向量数据库加轻量精排模型压缩用便宜的小模型编排逻辑自己写。不要试图找一个万能框架因为每个项目的上下文结构都不一样。把每个环节做成可替换的模块比押注一个框架更稳妥。7. 我个人的几条经验法则做了这么多项目我总结了几条在Context Engineering上反复验证有效的法则分享出来供参考。法则一上下文是稀缺资源不是免费存储。每往上下文里加一段内容都要问自己这段信息对当前决策真的必要吗如果删掉它模型还能做对吗如果答案是“可能也行”那就删掉。法则二压缩要趁早不要等爆了再压。我习惯在上下文达到预算的70%时就触发压缩而不是等到95%。因为压缩本身也需要调用模型留出余量才能从容处理。法则三让模型做它擅长的事别让它做检索。很多人喜欢把大量候选信息塞给模型让它自己挑。但模型的检索能力远不如专门的检索模块。正确的做法是检索模块负责找模型负责用。法则四上下文结构要稳定内容可以变。模型对格式的敏感度很高。如果你每轮的上下文结构都不一样模型需要花额外精力去理解结构而不是解决问题。保持结构一致只换内容效果会好很多。法则五永远保留一个“逃生出口”。当上下文管理出问题时要有一个降级方案。比如压缩失败时直接截断最老的历史召回失败时回退到只用当前任务描述。这个逃生出口能在关键时刻保住系统的可用性。最后说一个我最近在尝试的方向把上下文组装逻辑做成可配置的DSL让非工程人员也能调整上下文策略。这样产品经理可以直接参与调优而不需要每次都找工程师改代码。目前还在早期阶段但初步效果不错上下文策略的迭代速度提升了好几倍。如果你也在做类似的事情欢迎交流。