0.1 上下文工程是什么：与提示词工程的分界
0.1 上下文工程是什么：与提示词工程的分界
本节摘要：这是全书被搜索最多的一节，我们直接回答那个最高频的问题：上下文工程和提示词工程有什么区别？答案一句话：提示词工程管"怎么把话说好"，上下文工程管"什么信息该进模型窗口"。前者是设计期的一次性写作——打磨一段静态文本；后者是运行时的供给系统——每一轮动态决定窗口里装什么、按什么顺序装、装不下时丢什么。分界的技术根源有三个：窗口容量有限（token 是预算）、注意力会被稀释（塞满不等于用好）、窗口内容是动态组装的（历史、检索、工具结果都在变）。本节给出一张分工对照表、同一个客服任务在两种视角下的完整对比、术语演化的四部曲，并说明"分界不是分家"——提示词工程是上下文工程的一个子问题。
学习目标
阅读完本节，你应当能够：
- 用一句话向同事解释两个术语的分界，并说出三个技术根源。
- 面对同一个任务，分别列出提示词工程视角与上下文工程视角的检查清单。
- 复述术语从 prompt engineering 到 context engineering 的演化时间线。
一、从一个翻车现场说起
一个常见的剧本：你做了一个客服 Agent，上线演示那天表现惊艳。两周后用户投诉：它开始编造政策、忘记十分钟前的承诺、答非所问。你打开代码检查——那条精心打磨的 prompt 一字未改。
问题不在 prompt，在窗口。演示那天窗口里只有一条指令和一句问题；两周后的真实会话里，同一扇窗口挤进了：四十轮对话历史、每次检索回来的知识库片段、十几个工具的 schema、若干次工具执行的原始输出。指令没变，但模型"读到的东西"完全变了——而模型做到什么，取决于它读到什么。
提示词工程的工具箱修不了这类问题：它是雕琢一句话的手艺，而这里坏掉的是一套信息供给系统。这就是上下文工程（context engineering）的辖区。
二、一张分工对照表
| 维度 | 提示词工程（prompt engineering） | 上下文工程（context engineering） |
|---|---|---|
| 管什么 | 一段话怎么说 | 什么信息、以什么顺序、什么形态进入模型窗口 |
| 处理对象 | 一条静态文本模板 | 一个动态系统：历史、检索片段、工具 schema、记忆 |
| 时态 | 设计期一次写好，部署后基本不动 | 运行时每一轮重新组装 |
| 核心约束 | 语义清晰：措辞、结构、少样本 | 资源约束：token 预算、注意力、位置 |
| 典型问题 | "这句话怎么说模型才听懂" | "这条信息此刻该不该在窗口里、该占多少、放哪儿" |
| 主要手段 | 措辞、格式、思维链、少样本示例 | 预算分配、驱逐、压缩、检索、记忆分层、位置编排 |
| 产物形态 | prompt 文本 | 供料管线 + 组装策略 + 观测账本 |
| 失效方式 | 模型理解偏了 | 系统随会话变长而劣化（演示好、上线崩） |
读表的关键是最后一行：提示词工程的失败是静态的，改一句话就好；上下文工程的失败是动态的——今天好，明天会话变长就坏。后者没法靠"再改改 prompt"修复。
三、同一个任务，两种视角
任务：给电商客服 Agent 设计"退款处理"能力。
提示词工程视角的检查清单：
system_prompt.md —— 退款客服指令（提示词工程产物示意） 你是某电商的客服专员，负责处理退款申请。 - 语气：礼貌、简洁，不承诺政策之外的条件 - 步骤：先核对订单状态，再判断是否符合 7 天无理由，最后给出结论 - 输出：JSON 格式 {"decision": "...", "reason": "..."}
写完这 100 来个 token，提示词工程的工作基本结束——它假设模型除此之外什么也看不见。
上下文工程视角的检查清单：这 100 个 token 只是窗口里的一种成分。还要问：
- 指令：上面的系统提示放最前，占多少预算？关键红线要不要在最近的用户消息末尾再复述一次？
- 工具：查订单、查物流、创建退款单……十几个工具的 schema 每轮都进窗口，占几千 token，是否精简到最小集合？
- 记忆：这位用户十分钟前刚问过物流，历史要不要全量保留？昨天会话里的偏好要不要召回？
- 素材：退款政策条款是整篇塞进去，还是按问题检索三段？检索回来的片段按什么顺序排？
- 输出预留：塞满素材之后，模型还有没有生成 JSON 回复的空间？
- 超预算：会话滚到第四十轮，先丢历史还是先丢陈旧的检索片段？
同一个任务，前者交付一段文案，后者交付一套预算分配、驱逐规则与组装策略。两者的关系在第五节收尾：分界不是分家——那段 100 token 的系统提示，恰恰是上下文工程里"指令"成分的质量问题，仍然要用提示词工程的功夫去写。
四、术语演化：从 prompt 到 context 的四部曲
| 时间 | 事件 | 属性 |
|---|---|---|
| 2020~2023 | prompt engineering 黄金期：GPT-3/3.5 时代，应用多为单轮或短对话，"把话说好"几乎等于全部 | 社区 |
| 2024 | RAG 与 Agent 兴起，历史、检索片段、工具结果涌进窗口，"prompt 装不下整个问题"；年末 LlamaIndex 博客在 RAG 语境下使用 context engineering 一词 | 社区 |
| 2025-06 | Karpathy 公开帖提议用 context engineering 取代 prompt engineering：它是"给上下文窗口填上恰好够下一步使用的信息，不多不少"的艺术 | 社区 |
| 2025-09 | Anthropic 发布《Effective Context Engineering for AI Agents》，给出学科化表述：为 Agent 设计动态系统，让正确的信息在正确的时刻以正确的形态抵达模型——并统一讨论系统提示、工具、检索、记忆与子 Agent | 官方 |
| 2025~2026 | 框架化：LangChain 提炼 write / select / compress / isolate 四类策略并落进 LangGraph 与 LangMem；各家框架跟进（如 Deep Agents SDK 的 offloading 与 summarization） | 官方 |
💡 一个记忆锚点：术语的每次升级都对应"窗口里东西变多"——单轮对话（prompt 够用）→ RAG（多了素材）→ Agent（多了工具与历史）→ 长任务 Agent（多了记忆与压缩）。名字变了的背后，是窗口的内容复杂度翻了几个量级。
五、分界不是分家
把两个术语对立起来是误读。准确的关系是包含：指令成分的写作质量，仍然是提示词工程问题；上下文工程把这段文字放回整个窗口的预算与结构里审计——它值多少 token、放在什么位置、和谁挤在一起、何时被稀释。提示词工程是上下文工程的子问题，就像雕窗花是建筑设计的子问题。
由此得到本书的工作定义：上下文工程是设计并运行一套信息供给系统，让模型在每一轮都恰好读到完成下一步所需的信息——不多、不少、位置正确。"不多不少"由预算管理（第 1、2 章）保证，"是什么"由四成分框架（1.2 节）刻画，"位置正确"由位置效应（2.2 节）约束。
本节要点回顾
- 一句话分界：提示词工程管"怎么说"，上下文工程管"装什么进窗口"；前者是静态文案，后者是动态供给系统。
- 三个技术根源：窗口容量有限、注意力会稀释、窗口内容每轮动态组装。
- 两种失效模式：提示词工程失败是静态的（改话即好），上下文工程失败是动态的（会话变长即坏）。
- 术语四部曲：2024 RAG 语境萌芽（社区）→ 2025-06 Karpathy 定名（社区）→ 2025-09 Anthropic 系统化（官方）→ 2025~2026 框架化（官方）。
- 分界不是分家：提示词工程是上下文工程的子问题——指令成分的写作仍靠它。
划清了边界，下一个问题是这本书怎么读、你缺什么先修、哪些话题该去相邻教程补——下一节给出路线图。