上下文工程（Context Engineering）是一个在人工智能领域逐渐走红的新术语。行业内讨论的焦点正从 "提示词工程"（prompt engineering）转向一个更广泛、更强大的概念：上下文工程（Context Engineering）。托比・卢克（Tobi Lutke）[1] 将其描述为 " 为任务提供完整的上下文背景，使『大语言模型』能够合理解决问题的一门艺术 "，他说得很到位。
随着 Agents 的兴起，将哪些信息输入 "有限的工作记忆（limited working memory）" 中变得越来越重要。我们观察到，决定一个 Agent 成败的关键因素，通常就在于你提供给它的上下文质量。大多数 Agent 的失败早已不是模型本身的问题，而恰恰是上下文供给的失败。
01 什么是上下文（Context）？
要理解上下文工程（Context Engineering），我们首先必须扩展对 "上下文" 的定义。它不仅指你发送给 LLM 的单一提示词（prompt）。应该将其视为模型在生成响应前所看到的一切信息。
指令 / 系统提示词（Instructions / System Prompt） ： 用于定义模型在对话期间行为的初始指令集，可以 / 应该包含示例、规则等。
用户提示词（User Prompt） ： 来自用户的即时任务或问题。
状态 / 历史（短期记忆）[State / History (short-term Memory] ： 当前的对话内容，包括导致此刻结果的 "用户与模型的历史回复"。
长期记忆（Long-Term Memory） ： 在之前的多次对话中收集的持久性知识库，包含学习到的用户偏好、过往对话摘要、或被明确告知需要记忆以备后续使用的信息。
检索信息（RAG）[Retrieved Information (RAG)] ： 外部的、最新的知识，来自文档、数据库或 API 的相关信息，用于回答特定问题。
可用工具（Available Tools） ： 所有可调用函数或内置工具的标准化描述（如输入参数、输出格式、功能说明）（例如 check_inventory, send_email）。
结构化输出（Structured Output） ： 对模型响应格式的定义，例如一个 JSON 对象。
