上下文工程 vs. 提示工程：RAG与Agent时代的AI新范式

从“措辞艺术”到“系统科学”的演变

提示工程 (Prompt Engineering)

专注于精心设计输入给大型语言模型（LLM）的文本。它包括指令、示例和格式提示，旨在引导模型的行为和输出。

核心：优化输入文本本身。

上下文工程 (Context Engineering)

这是一个更广泛的系统级学科。它通过编程方式组装 LLM 在推理过程中看到的所有内容——包括提示、检索到的文档、记忆、工具和状态。

核心：优化模型运行的整个环境。

案例分析：特工 Graham 的订票困境

为什么仅仅优化提示是不够的？让我们看看旅行预订 Agent Graham 的遭遇，它生动展示了缺乏上下文工程的后果。

🧑‍💻 用户：帮我预订下个月 DevOps 大会的巴黎酒店。

🤖 Graham：没问题。Best Western Paris Inn 已预订，Wi-Fi 很好，停车免费。

❌ 失败：地理位置错误

问题是，酒店在美国肯塔基州巴黎市，而大会在法国巴黎。

💡 CE 缺失：Agent 应该使用工具检查用户的日历或在线查找会议地点。

🧑‍💻 用户：我的会议在法国巴黎。

🤖 Graham：好的。每晚 900 欧元，丽兹酒店已预订，含香槟早餐。

❌ 失败：预算超支

这显然无法通过公司报销。

💡 CE 缺失：Agent 应该能够访问（例如通过 RAG）公司的差旅政策文件，了解最高限价。

深入：提示工程 (PE) 的核心技术

PE 是基础，是“措辞的艺术”。它依赖于关键技术来提高输出质量。

🎭

角色分配 (Role Assignment)

告诉 LLM 它应该扮演谁。模型会采用该角色的专业知识和词汇。

"你是一名高级 Python 开发者，正在审查代码的安全性漏洞。"

💡💡💡

少样本示例 (Few-Shot)

展示，而不仅仅是告知。提供几个输入输出对的示例，帮助模型理解确切的格式要求。

"如果需要特定的 JSON 输出，请在示例中展示它。"

🧠🔗👣

思维链 (CoT)

强制模型展示其工作过程。防止 LLM 直接跳到结论，对复杂推理任务尤其有效。

"让我们一步步思考..." 或 "解释你的推理过程。"

🚫

约束设定 (Constraint Setting)

明确定义边界，防止模型偏离主题。

"将回复限制在 100 字以内。" 或 "仅使用提供的信息。"

进化：上下文工程 (CE) 的系统蓝图

上下文工程是构建动态 Agentic 系统的学科，它负责编排整个环境。

Agentic AI 系统架构

🤖
LLM Agent

🧠 记忆管理 (Memory)

短期记忆：总结长对话以适应上下文窗口。

长期记忆：使用向量数据库检索用户偏好、历史记录和学习模式。

📚 RAG (检索增强生成)

连接 Agent 到动态知识源。使用混合搜索（语义+关键词）检索最相关的文档片段，而非整个文档。

📊 状态管理 (State)

跟踪多步骤流程的进度（例如：预订航班、酒店、租车）。确保 Agent 在任务中途不会丢失上下文。

🛠️ 工具调用 (Tools)

允许 LLM 与外部世界交互。查询 SQL 数据库、调用 API、获取实时数据或执行代码。CE 负责定义接口和使用规范。

上下文工程负责编排整个 Agent 环境。

融合：动态提示注入

在上下文工程中，提示工程依然重要，但形式发生了变化。我们不再编写静态的长篇提示，而是在运行时动态注入上下文。

运行时提示的构建

以基础提示“分析安全日志中的异常”为例。在运行时，CE 系统会动态地将当前上下文注入该模板。

提示模板中的变量会从状态管理、记忆和 RAG 检索结果中填充。

示例：动态注入过程

基础提示

Analyze security logs...

+

动态上下文

{recent_alerts}, {known_false_positives}

最终提示词的构成比例

最终发送给 LLM 的提示可能包含 80% 的动态内容和 20% 的静态指令。

总结：构建更智能的 AI

提示工程带来
更好的问题

+

上下文工程带来
更好的系统

通过正确结合这两者，我们可以构建出真正智能、可靠且能有效解决复杂任务的 Agentic AI。

特工 Graham（升级后）：

"酒店已预订。法国巴黎，预算内，靠近会场。太棒了！"

"...待您的经理、HR 和财务批准。预计批准时间：六到八周。会议在两周后举行。您试过对您的经理进行提示工程吗？"