《大模型上下文工程实践》- 序章
过去几年，我们谈论大模型应用时，最常出现的词是“提示词工程”。它简单、直接，也确实重要：一段清晰的指令、几个恰当的示例，往往就能显著改变模型输出。然而，当应用从一次性的问答走向持续运行的产品，仅靠提示词很快就会触碰边界。
真实系统需要处理长期对话、动态知识、用户状态、外部工具、任务计划和执行反馈。模型每一次推理面对的仍然只是一段有限的上下文，工程要做的事情，就是在正确的时间，把正确的信息，以正确的结构送到模型面前。这正是上下文工程的核心。
从“写一句好指令”到“设计信息系统”
提示词工程关注的是如何表达任务，上下文工程关注的则是整个推理环境如何被构造。它不仅包含系统提示词和用户输入，还包括：
- 当前任务、目标与约束；
- 对话历史和压缩后的阶段性摘要；
- 从长期记忆中召回的用户事实；
- 从知识库检索到的外部资料；
- 可调用工具的定义、权限与返回结果；
- 智能体的计划、执行轨迹和环境反馈。
因此，上下文工程不是提示词工程的替代品，而是它的上层系统。提示词仍然是重要的原子能力，只是需要和记忆、检索、工具、状态管理与智能体编排协同工作。
为什么上下文越长，结果不一定越好
模型上下文窗口持续增长，但“能放进去”并不等于“应该放进去”。无差别地堆积信息会带来注意力稀释、关键信息被淹没、成本上升和延迟增加等问题。多轮对话还可能不断引入过期状态、重复内容和互相冲突的约束。
高质量上下文应当具备四个特征：
- 相关：只保留对当前决策有帮助的信息；
- 清晰：不同来源、优先级和可信度可以被区分；
- 及时：动态数据在使用前得到刷新；
- 可控：信息进入、压缩、召回和淘汰都有明确策略。
这意味着工程目标不是不断扩张上下文，而是建立一条稳定的信息管道：采集、筛选、组织、注入，再根据执行结果持续修正。
一套完整的上下文工程技术栈
本系列从提示词出发，逐步走向可运行的智能体系统。
- 第 1 章：从提示词到上下文梳理提示词工程向上下文工程演进的原因，并建立统一认知。
- 第 2 章：上下文工程技术栈讨论上下文窗口、信息组织、压缩、隔离和动态装配。
- 第 3 章：提示词技术介绍零样本、少样本、思维链、元提示、ReAct 等常用方法。
- 第 4 章：记忆系统与持久化解释短期记忆、长期记忆以及从存储走向智能知识管理的过程。
- 第 5 章：检索增强生成覆盖分块、向量化、召回、重排、评估及 GraphRAG 等实践。
- 第 6 章：工具使用与 MCP连接模型与外部世界，理解函数调用、MCP 与安全边界。
- 第 7 章：智能体将前面的能力组合为具备计划、执行、观察、记忆与协作能力的系统。
工程实践的真正难点
一个能演示的原型通常并不难：接入模型、拼接提示词、添加几个工具，就可以得到一个看起来“会做事”的 Agent。困难在于让它稳定、可控、可评估地长期运行。
我们需要回答更多工程问题：上下文从哪里来，是否可信；记忆何时写入，如何纠错；检索结果是否真正相关；工具是否会越权或重复执行；任务失败后如何恢复；多智能体协作时如何避免信息丢失与成本失控。只有这些问题得到系统性处理，大模型能力才会转化为可靠的产品能力。
阅读建议
这套内容按照能力依赖关系组织。初次接触可以顺序阅读，先理解上下文的基本问题，再进入记忆、RAG、工具与 Agent；已经有实践经验的读者，也可以按当前系统的瓶颈直接选择章节。
上下文工程没有唯一的标准答案。不同模型、任务和业务约束会产生不同方案，但判断方法是一致的：围绕任务目标控制信息流，用可观测数据验证效果，并让每一次模型调用都拥有足够且不过载的上下文。