“上下文工程”指的是：系统性地设计、组织和动态管理大语言模型（LLM）输入窗口中的上下文信息，以确保模型在执行任务时具备最优表现的技术与艺术结合。
这一概念由 Cognition 的 Walden Yan 明确提出：
被 Shopify CEO Tobi Lutke 等多位 AI 实践者在社交媒体广泛转发，迅速走红。
如 Dex Horthy （数据平台 Hex 的联合创始人）所言：
“Own your context window.”
🔍 为什么它现在变得重要？
上下文窗口不断扩大（Claude 3.5 已到 200K，GPT-4o 是128K，GPT-4 Turbo是128K，Gemini 1.5甚至到达100万 token），但更大上下文≠更好效果。相反：
塞太多无关信息，会稀释重点； 塞得不够或格式混乱，又会导致 hallucination 或 reasoning failure； 多模态信息（图、音、视频、函数调用等）加入后，结构复杂度指数级增长。
这就要求我们从 prompt 工程迈入 context 工程的新阶段。
🔧 实践中的解法框架
以下是多位 AI 开发者对“Context Engineering”的具体定义与操作方法：
1. Harrison from LangGraph
LangGraph 是为“上下文工程”而生的图状 RAG 框架，用于搭建带状态的、多轮交互式 Agent 应用。
https://x.com/hwchase17/status/1937648042985030145
2. Lance Martin 的类比：像 RAM 管理器
“就像操作系统负责将关键数据调入 CPU 的 RAM 中一样，LLM 应用也需要上下文工程师管理 Prompt、检索内容与工具调用的组合逻辑。”
https://rlancemartin.github.io/2025/06/23/context_engineering/
3. Kwindla 的推荐：以“工作流状态”组织上下文
对于语音 Agent 或任务代理，应该把对话流设计成状态机，每个状态只需要引入完成该任务的必要上下文。
https://gist.github.com/kwindla/f755284ef2b14730e1075c2ac803edcf
4. Andrej Karpathy 的总结
“上下文工程既是科学，也是艺术。”
https://x.com/karpathy/status/1937902205765607626
他列举了上下文组成的各种组件，包括：
任务描述； few-shot 示例； 历史状态； 检索内容（RAG）； 工具使用记录； 多模态输入等。
最好的上下文工程需要在高性能、低延迟、低成本之间找到最佳点。
