1、什么是上下文工程？
这几天在AI圈，一个新词频频刷屏: Context Engineering(上下文工程)，就连大神 Karpathy 都为它站台！
这个概念，其实是 Al Agent 发展到一定阶段的产物。
在大语言模型(LLM)早期，应用核心是“对话交互”：
用户写好 prompt→模型生成回答，也就是我们熟悉的Prompt Engineering(提示词工程)。
但随着 Al Agent 的兴起，AI 不再只是回答问题，而是能真正动手做事：
接收一个完整任务
自主思考、规划步骤、动态决策、调用工具
完成任务！
这个过程中，LLM 作为 Agent 的“大脑”，不再只依赖静态 prompt，而是需要动态掌握环境状态、工具信息、历史数据、任务目标等各种上下文信息。
如果模型拿不到关键的信息，就可能“决策失误”，导致任务失败。
所以: 在合适的时机、用合适的格式，为LLM 准备好完成任务所需的所有相关信息，就成了 Agent 成败的关键。
这就是: Context Engineering！
2、上下文包含哪些信息？
一个 Al Agent 的上下文可能包括以下内容:
指令/系统提示词: 告诉 LLM 需要扮演什么角色、遵循哪些规则、输出什么格式，或者提供一些示例作为参考
用户提示词: 用户发出的具体问题或任务
短时记忆: 当前对话的历史信息(包括用户的提问和LLM 的回答)
长时记忆: 跨不同对话积累的知识，如用户偏好、项目总结、任务经验等
外部信息(RAG) : 通过检索获得的实时信息，如文档、数据库或互联网内容
可用工具: LLM 可以调用的所有工具和函数
结构化输出: 对 LLM 输出格式的约定(如 JSON)
这些信息可能存储在不同的介质中，通过不同策略不同方式动态获取。
3、和提示词工程的区别
主要区别在于: Context Engineering 是一个系统工程不是简单设计一个提示词模板。
Prompt Engineering 的重点，是写好一个 prompt 模板，引导模型生成理想回答。
而 Context Engineering，则需要在调用模型前，由Agent 系统动态构建出完成任务所需的全部上下文信息。
这个过程不仅包括:
确定什么时候准备上下文信息?
确定以什么格式给?
还涉及一系列复杂的工程决策，比如：
哪些信息该放进短时记忆 vs 长时记忆?
如何从记忆中取出与当前任务相关的信息，检索策略是什么?
如何裁剪/压缩内容，避免超出模型的 context window?
工具调用信息应该用什么样的数据结构展现给模型?
有些信息可能不在内部，需要从外部知识库或 API实时获取。
4、如何实现上下文工程？
目前业界还没有统一标准，不同的 AlAgent 框架都有自己的上下文管理机制。
LangChain 这两天发布的一篇文章，总结了LangGraph 中支持的四种上下文管理和构建策略，或可作为参考：
Write Context(写入上下文)
把任务中产生的重要信息写入长时记忆、草稿板或状态对象中，存储在上下文窗口之外，供后续调用。
Select Context(选择上下文)
从草稿板、状态对象、长时记忆库或知识库中动态检索出当前任务相关的信息，填充进上下文窗口。
Compress Context(压缩上下文)
对累积的上下文进行总结或修剪，只保留与当前任务相关的 token，避免超过上下文窗口限制。
lsolate Context(隔离上下文)
将复杂任务所需的上下文分区存储在状态对象、沙箱环境或多个子智能体中，避免信息干扰、保持结构清晰。
