真正影响 AI 应用稳定性的，已经不只是 Prompt，而是每一次模型调用时，我们到底给了它什么上下文。
Prompt 只是冰山一角
过去两年，很多团队把大量精力花在 Prompt 上。
"你是一个资深专家。"
"请一步一步思考。"
"用三点总结。"
这些写法有用，但它们解决的是很小的一块问题。Prompt 更像是一次任务说明里的最后一句话，而不是完整 briefing。
一个真正可用的 AI 应用，不是靠一句漂亮提示词跑起来的。它还需要系统规则、任务目标、用户偏好、历史对话、检索资料、工具定义、工具返回结果、输出格式、失败后的重试策略。这些东西加起来，才是模型实际看到的世界。
所以，上下文工程要回答的问题不是"这句话怎么写更有效"，而是：
text
这一次调用模型时，哪些信息应该进入上下文？
它们应该以什么顺序出现？
每部分占多少 token？
哪些旧信息应该被删除？
哪些事实必须被保留？
模型输出后，哪些结果要写回记忆或状态？如果 Prompt 是一句指令，上下文工程就是整套作战简报。
一个好比喻：你在给一位聪明但失忆的同事派活
原文用了一个很好的类比。
想象你有一位新同事，能力很强，理解速度很快，执行也很快。但他有一个问题：每次开工前都会失忆。他不知道之前发生了什么，不记得你们讨论过什么，也不知道团队有哪些规则。
你想让他做好工作，就必须在一页纸里讲清楚：
- 他现在扮演什么角色
- 这次任务是什么
- 需要参考哪些背景资料
- 过去有没有类似案例
- 可以使用哪些工具
- 输出应该长什么样
- 有哪些边界不能越过
少给一个关键信息，他就只能靠猜。猜对了是运气，猜错了就是系统问题。
LLM 也是这样。它本身没有状态。每一次请求进来，模型都只知道上下文窗口里放了什么。上下文好，输出就稳定；上下文乱，模型再强也会乱。
这也是为什么一个弱一点的模型，在上下文设计得很好的情况下，可能比一个强模型表现更稳定。因为生产系统里真正的瓶颈，很多时候不是模型智商，而是我们给模型的材料太差。
上下文窗口里到底应该放什么
真实的 AI 应用里，上下文通常不是一段话，而是一组有层次的信息。
第一层是系统提示词。它定义角色、规则、禁止事项、输出格式。比如"你是客服助手，只能根据知识库回答，不能编造政策"。这部分通常最稳定，也最应该放在前面。
第二层是 few-shot 示例。模型很擅长从例子里学习格式和风格。一个好例子，往往比十句抽象规则更有效。
第三层是检索出来的文档，也就是 RAG。模型不应该读完整知识库，而应该只读和当前问题最相关的片段。这里的质量取决于切块、召回、重排和过滤。
第四层是工具定义。Agent 能不能调用搜索、数据库、浏览器、代码执行器，取决于上下文里有没有清楚告诉它工具能做什么、参数怎么传、什么时候该用。
第五层是记忆。用户偏好、长期事实、历史决策都可能影响当前任务。但记忆不能一股脑塞进去，只能取和当前任务有关的部分。
第六层是当前会话历史。它提供连续性，但会话越长，噪音越多。老信息必须被总结、裁剪或淘汰。
第七层是工具结果。模型调用工具后，工具返回的内容会进入下一轮上下文，模型再基于结果继续判断。
最后才是用户当前这句话。它通常放在上下文末尾，因为模型对开头和结尾更敏感。把关键任务埋在中间，是很常见的错误。
Prompt Engineering 和 Context Engineering 的区别
Prompt Engineering 关注一句话怎么写。
比如：
text
总结这篇文章。改成：
text
请用三条要点总结这篇文章，面向非技术读者，避免术语。这就是 Prompt Engineering。它调整的是单次指令的表达方式。
Context Engineering 管的是整个信息环境。它不仅包括这句 Prompt，还包括系统规则、RAG 资料、few-shot 示例、工具列表、记忆、历史对话和输出 schema。
两者不是对立关系。Prompt 是上下文的一部分，但不是全部。
如果一个 AI 应用经常答错，问题未必是"提示词不够优雅"。更可能是下面这些问题：
- 检索资料没召回正确文档
- 召回了太多无关文档
- 关键规则被放在上下文中间
- 历史对话太长，旧信息干扰当前任务
- 工具描述不清楚，模型不知道什么时候该调用
- 输出格式只靠口头要求，没有 schema 约束
- 记忆过期了，但仍然被注入上下文
这就是为什么生产级 AI 应用越来越像工程系统，而不是"写几句神奇 Prompt"。
常见模式：RAG、示例、工具、记忆和压缩
上下文不是一次性写死的。每一轮调用模型时，系统都会重新组装上下文。
最常见的做法是 RAG。不要把整个知识库塞进去，而是先检索，再重排，只放入当前问题需要的片段。RAG 的重点不是"能搜到"，而是"搜到的内容刚好够用"。多了会稀释注意力，少了会让模型猜。
few-shot 示例适合规范输出风格。比如你希望模型生成固定结构的客服回复、SQL、代码审查意见或短视频脚本，与其写一堆抽象规则，不如给两三个高质量样例。
工具调用是 Agent 的基础。模型不应该凭空完成所有事。它需要知道有哪些工具、每个工具什么时候用、参数是什么、工具返回结果如何继续处理。
记忆注入解决跨会话连续性。比如用户长期偏好、项目背景、重要决策，都不应该每次重新解释。但记忆必须按需注入。把所有记忆都塞进上下文，只会把模型拖进噪音里。
长对话需要历史管理。常见办法包括滑动窗口、阶段性总结、选择性保留关键事实。真正可靠的 Agent，不会把所有旧消息无限 append。它会在每一步重新判断：当前任务到底需要哪些信息？
当上下文太长时，还需要压缩。压缩不是简单摘要，而是保留任务所需事实，删掉表达、重复和过期信息。压缩得太狠，会丢关键约束；压缩得不够，又会把上下文撑爆。
最容易犯的六个错误
第一个错误是把所有东西都塞进上下文。很多人以为上下文越大越安全，其实不一定。上下文越长，成本越高，速度越慢，噪音也越多。模型要从一堆无关内容里找信号，质量会下降。社区里有人把这个现象叫 context rot，也就是上下文腐烂。
第二个错误是给得不够。模型看不到退款政策，就不可能稳定回答退款问题；看不到项目约束，就不可能正确做技术方案。不要指望模型猜出你没给的信息。
第三个错误是顺序混乱。模型更关注上下文开头和结尾。规则最好放前面，当前任务最好放最后。把关键要求埋在中间，模型很容易漏掉，这就是常说的 lost in the middle。
第四个错误是上下文过期。旧工具结果、旧会议结论、旧用户偏好，如果已经不适用，就应该被清掉。过期信息比没有信息更危险，因为它看起来像事实。
第五个错误是没有结构。把一大段文字直接贴进去，模型也能读，但会更容易混淆。标题、分隔符、来源标签、时间戳、优先级，这些结构会显著提高稳定性。
第六个错误是指令互相打架。系统提示词说"只能根据知识库回答"，用户消息又要求"自由发挥"；两个检索文档给出相反结论；记忆和当前任务不一致。上下文里只要存在冲突，模型就会被迫猜。
怎么把上下文当成工程来做
真正成熟的做法，是把上下文当成一等工程资产。
首先要有预算。每次调用里，系统提示词、检索资料、记忆、历史对话、当前任务分别占多少 token，应该有清晰分配。没有预算，上下文会自然膨胀。
其次要按稳定程度排序。稳定规则放前面，动态资料放中间，当前任务放最后。这样也有利于缓存，稳定部分可以复用，减少成本。
第三，要给上下文加结构。不要只拼接字符串。更好的做法是明确分区：SYSTEM、EXAMPLES、RETRIEVED DOCUMENTS、MEMORY、TOOLS、CONVERSATION、CURRENT TASK。模型看到结构，才更容易判断信息用途。
第四，要记录失败时的完整上下文。AI 应用出错时，第一反应不应该是"换个模型试试"，而是看当时模型到底看到了什么。多数 bug 都藏在上下文里。
第五，要版本化和评测上下文。Prompt、RAG 策略、记忆选择规则、工具描述，都应该能 diff、能回滚、能 A/B 测试。上下文不是一次性文案，而是生产系统的一部分。
最后，不要迷信长上下文。长上下文是能力，不是借口。真正厉害的系统，会在每一步给模型刚好够用的信息。
对 Agent 系统尤其重要
普通聊天机器人只需要回答当前问题。Agent 不一样，它会分解任务、调用工具、观察结果、调整计划、继续执行。
这意味着 Agent 的上下文每一步都应该变化。
第一步可能需要任务目标和可用工具。
第二步可能需要工具返回结果和下一步判断。
第三步可能需要失败原因、重试策略和用户约束。
如果 Agent 只是把所有内容不断追加到对话里，它迟早会被自己的历史淹没。可靠的 Agent 必须会"整理现场"：保留当前步骤相关的信息，丢弃已经不影响决策的内容，把重要结论写入状态或记忆。
这也是为什么很多 Agent demo 看起来很酷，但一进生产就不稳定。问题不是模型不会推理，而是系统没有管理好它每一步看到的东西。
一句话总结
上下文工程不是 Prompt Engineering 的新包装。它是构建可靠 AI 应用的基础工作。
Prompt 解决的是"怎么说"。
上下文工程解决的是"让模型基于什么做判断"。
模型越来越强之后，差距反而会出现在这里：谁能把资料、记忆、工具、历史和任务组织得更清楚，谁的 AI 应用就更稳定。
未来做 AI 应用，不能只问"用哪个模型"。还要问：
text
这次调用的上下文是怎么组装的？
关键事实从哪里来？
过期信息怎么删？
工具结果怎么进入下一步？
失败时怎么复盘？
上下文有没有版本和评测？把这些问题答清楚，AI 应用才可能从 demo 走向生产。