配套视频：https://www.bilibili.com/video/BV1JJ14BWE3S/
引言
在 AI 应用开发领域，"提示工程"（Prompt Engineering）已经成为一个耳熟能详的术语。然而，随着 AI 智能体系统的复杂度不断提升，一个更为广泛和系统化的概念正在崭露头角——"上下文工程"（Context Engineering）。本文将通过一个生动的案例，深入探讨这两个概念的区别与联系，并揭示如何构建真正智能的 AI 系统。
一、核心概念：提示工程 vs 上下文工程
提示工程：措辞的艺术
提示工程是编写用于提示大语言模型（LLM）输入文本的过程。它专注于如何通过精心设计的指令、示例和格式提示来引导 LLM 的行为与输出。简单来说，提示工程关注的是"怎么说"——如何用恰当的语言让模型理解你的意图并产生期望的结果。
上下文工程：系统级的支持学科
上下文工程则是一个更为广泛的学科，它通过程序化的方式整合大模型在推理时所见的全部内容。这不仅包括提示词本身，还涵盖：
检索到的文档（RAG）
记忆系统（短期和长期）
可调用的工具
状态管理
上下文工程的目标是为模型提供系统级支持，确保它能够合理、准确地完成复杂任务。如果说提示工程是"措辞的艺术"，那么上下文工程就是"构建智能体生态系统的科学"。
二、案例分析：特工格雷厄姆的巴黎之旅
为了更好地理解这两个概念的差异，让我们看一个实际案例——一个名为"格雷厄姆"的自主 AI 旅行预订智能体。
第一次尝试：地理位置的尴尬
用户请求："帮我订一间巴黎的酒店，下月的 DevOps 会议。"
格雷厄姆的回复："没问题！已为您预订巴黎最佳西方酒店，Wi-Fi 优质，停车免费。"
问题出现了：这家酒店位于肯塔基州的巴黎市，而不是法国巴黎！DevOps 会议实际上在法国举行。
失败原因分析：
提示工程不足：用户没有明确指定"法国巴黎"
上下文工程缺失：智能体没有查询用户日程或搜索会议信息来确定正确地点
这个案例说明，仅靠用户的提示词是不够的，智能体需要主动获取和整合上下文信息。
第二次尝试：预算的灾难
用户请求："我的会议在法国巴黎。"（补充了位置信息）
格雷厄姆的回复："已为您预订丽兹酒店，每晚 900 欧元，含香槟早餐。"
新问题：这个价格远超公司差旅预算！
失败原因分析：
智能体缺乏公司差旅政策的上下文信息。它应该能够访问一个 JSON 格式的差旅政策文件，其中明确规定了该地区允许的最高酒店价格。
成功的关键
要让格雷厄姆成功完成任务，需要：
更精确的提示（提示工程）
公司差旅政策文件（上下文数据）
会议信息查询能力（工具调用）
用户历史偏好（记忆系统）
这正是上下文工程的价值所在——它不仅仅依赖用户的输入，而是构建一个完整的信息生态系统。
三、提示工程的关键技术
虽然上下文工程更为全面，但提示工程仍然是其重要组成部分。以下是几种经过验证的提示工程技术：
1. 角色分配（Role Assignment）
通过明确告诉模型它应该扮演的角色，可以显著改变输出的质量和风格。
示例：
你是一位资深 Python 开发人员，专门审查代码中的安全漏洞。这会产生与普通代码审查请求完全不同的输出。模型会采用该角色的专业性、术语和关注点，提供更深入、更专业的分析。
2. 少量示例学习（Few-shot Learning）
与其用文字描述你想要什么，不如直接展示 2-3 个输入输出样例。
示例：
示例 1：
输入：用户反馈："界面很卡"
输出：{"category": "performance", "severity": "medium", "action": "investigate"}
示例 2：
输入：用户反馈："无法登录"
输出：{"category": "authentication", "severity": "high", "action": "urgent"}
现在处理：用户反馈："页面加载很慢"这种方法帮助模型准确理解你的格式和风格要求，特别适用于需要特定输出格式的场景。
3. 思维链提示（Chain of Thought）
在推理模型出现之前，思维链提示是提高复杂推理任务准确性的重要技巧。
关键短语：
"让我们一步步思考"
"解释你的推理过程"
"展示你的计算步骤"
这种方法迫使模型展示其推理过程，防止它草率下结论，在数学问题、逻辑推理等任务中尤为有效。
4. 约束设定（Constraint Setting）
明确设定边界可以防止模型偏离主题或产生不符合要求的输出。
示例：
"回复请限制在 100 字以内"
"仅使用提供的上下文信息，不要使用预训练知识"
"输出必须是有效的 JSON 格式"
四、上下文工程的核心组件
上下文工程构建的是一个动态的智能体系统，协调整个智能体环境。以下是其核心组成部分：
1. 记忆管理（Memory Management）
智能体需要记忆才能提供连贯、个性化的服务。记忆管理分为两种形式：
短期记忆
功能：摘要长对话，保持在上下文窗口范围内
作用：确保过往对话不被遗忘
技术：对话摘要、滑动窗口
长期记忆
功能：存储和检索持久化信息
内容：用户偏好、历史行程、学习到的模式
技术：向量数据库、嵌入检索
实际应用：格雷厄姆可以记住你总是选择靠窗座位、偏好四星级酒店、对海鲜过敏等信息。
2. 状态管理（State Management）
在多步骤流程中，智能体需要知道"我们现在在哪个阶段？"
场景示例：预订完整行程
航班预订 ✓
酒店预订 ← 当前步骤
地面交通预订
会议注册
关键问题：
航班预订成功了吗？
到达时间是什么？（用于安排接机）
预算还剩多少？
状态管理确保智能体在复杂任务中不会丢失上下文，每一步都基于前一步的结果进行决策。
3. 检索增强生成（RAG）
RAG 将智能体连接至动态知识源，是上下文工程中最重要的技术之一。
工作原理
混合搜索：结合语义匹配和关键词匹配
上下文过滤：只返回相关部分，而非完整文档
动态注入：将检索结果注入到提示中
实际应用：
当检索公司差旅政策时，RAG 不会返回 50 页的完整政策文件，而是：
筛选出与"巴黎酒店预订"相关的条款
提取价格上限和例外情况
仅将这些上下文相关的部分返回给智能体
这大大提高了效率和准确性。
4. 工具调用（Tool Calling）
大语言模型本身无法：
查询真实数据库
调用 API
执行代码
部署基础设施
工具正是用来填补这一空白的。
常见工具类型
数据查询工具：SQL 数据库查询
API 工具：获取实时价格、天气、航班信息
执行工具：运行 Python 代码、部署云资源
通知工具：发送邮件、消息推送
上下文工程的作用
定义指导大模型正确使用工具的接口：
工具的功能是什么？
什么时候应该使用这个工具？
有哪些限制条件？
工具描述示例：
{
"name": "search_hotels",
"description": "搜索符合条件的酒店，仅在用户明确提出住宿需求时使用",
"parameters": {
"location": "城市名称（必需）",
"check_in": "入住日期（必需）",
"max_price": "最高价格（可选，应参考差旅政策）"
},
"constraints": "必须先确认位置和日期，价格不得超过政策限制"
}5. 动态提示构建
上下文工程的精髓在于动态构建提示，而不是使用静态模板。
组成比例
20% 静态指令：基础提示模板
80% 动态内容：运行时注入的上下文
动态内容来源
状态信息：当前任务进度、已完成的步骤
记忆检索：用户偏好、历史行为
RAG 检索：相关政策、知识文档
工具输出：实时数据、查询结果
示例流程：
基础提示（静态）：
分析安全日志中的异常行为。运行时注入（动态）：
分析安全日志中的异常行为。
当前上下文：
- 近期告警：[从状态获取]
- 已知误报：[从记忆检索]
- 安全政策：[从 RAG 检索]
- 最新日志：[从工具调用获取]
请基于以上信息进行分析...最终提示中，大部分内容都是根据当前情况动态生成的，这使得智能体能够适应不断变化的环境。
五、提示工程与上下文工程的关系
包含关系
提示工程是上下文工程的一个子集。上下文工程包含了提示工程，但远不止于此。
上下文工程
├── 提示工程（静态指令）
├── 记忆管理
├── 状态管理
├── RAG 检索
└── 工具调用协同工作
两者并非对立，而是互补：
提示工程提供基础框架和指令
上下文工程提供动态数据和系统支持
结合使用才能构建真正智能的系统
类比：
提示工程像是给演员写台词
上下文工程像是为演员提供完整的剧本、背景故事、道具和舞台
最佳实践
要构建优秀的 AI 智能体系统：
从提示工程开始：设计清晰的指令和角色定义
添加记忆层：让智能体记住用户偏好和历史交互
集成 RAG：连接动态知识源
实现状态管理：处理多步骤任务
提供工具能力：让智能体能够执行实际操作
持续优化：根据反馈调整各个组件
六、实际应用场景
场景 1：客户服务智能体
仅使用提示工程：
只能基于当前对话回答问题
每次都需要用户重复信息
无法访问订单历史或知识库
使用上下文工程：
记住客户历史问题和偏好
自动检索相关产品文档
查询实时订单状态
跟踪问题解决进度
场景 2：代码审查助手
仅使用提示工程：
只能分析提供的代码片段
无法考虑项目上下文
每次都需要重新说明要求
使用上下文工程：
检索项目编码规范
查询相关代码库
记住之前的审查意见
调用静态分析工具
跟踪修复状态
场景 3：数据分析智能体
仅使用提示工程：
只能提供分析建议
无法访问实际数据
无法执行分析代码
使用上下文工程：
查询数据库获取数据
执行 Python 分析代码
记住分析历史和发现
检索分析方法文档
生成可视化报告
七、技术实现建议
架构设计
用户输入
↓
提示工程层（静态指令 + 角色定义）
↓
上下文工程层
├── 记忆检索（向量数据库）
├── RAG 检索（知识库）
├── 状态获取（状态管理器）
└── 工具准备（工具注册表）
↓
动态提示构建
↓
LLM 推理
↓
工具调用（如需要）
↓
状态更新
↓
记忆存储
↓
输出结果技术栈推荐
记忆管理：
向量数据库：Pinecone, Weaviate, Milvus
会话存储：Redis, PostgreSQL
RAG 实现：
嵌入模型：OpenAI Embeddings, Sentence Transformers
检索框架：LangChain, LlamaIndex
状态管理：
工作流引擎：Temporal, Apache Airflow
状态机：XState, Finite State Machine
工具调用：
函数调用：OpenAI Function Calling, Anthropic Tool Use
API 框架：FastAPI, Flask
八、挑战与未来
当前挑战
复杂性管理：上下文工程系统复杂度高，需要精心设计
成本控制：动态检索和工具调用会增加延迟和成本
可靠性保证：多组件协同增加了故障点
调试困难：动态生成的提示难以追踪和调试
未来趋势
自动化上下文工程：AI 自动优化上下文检索和注入策略
多智能体协作：不同专业智能体协同工作
持续学习：智能体从交互中不断学习和改进
标准化框架：更成熟的上下文工程框架和最佳实践
结语
回到格雷厄姆的故事：经过提示工程和上下文工程的完善，它终于成功预订了一家靠近会场、价格合理的巴黎（法国）酒店。但故事还没结束——格雷厄姆说："预订已完成，正在等待经理、人力资源和财务部门的批准，预计需要 6-8 周。"而会议两周后就要召开了！
这个幽默的结尾提醒我们：即使技术再完善，有时候你还需要对经理做"提示工程"！ 😄
但玩笑归玩笑，核心观点是明确的：
提示工程是措辞的艺术，上下文工程是构建智能系统的科学。只有将两者结合，才能构建真正智能、可靠、实用的 AI 智能体系统。
在 AI 应用开发中，不要只关注如何写好提示词，更要思考如何为你的 AI 构建一个完整的"生态系统"——包括记忆、知识、工具和状态管理。这才是通往真正智能 AI 的道路。
关键要点总结：
✅ 提示工程 ⊂ 上下文工程
✅ 上下文工程 = 提示 + 记忆 + RAG + 状态 + 工具
✅ 动态提示 > 静态提示
✅ 系统化方法 > 单点优化
✅ 实践 + 迭代 = 成功
希望这篇文章能帮助你更好地理解和应用这两个重要概念，构建出更智能、更可靠的 AI 系统！
如果这篇文章对你有帮助，欢迎点赞、收藏、转发。也欢迎在评论区分享你的经验，我们一起交流学习！
我是 dtsola【IT解决方案架构师 | AI创业者】 ；专注AI创业、商业、技术、心理学、哲学内容分享。
提供服务：AI项目咨询 | 技术解决方案 | IT项目实施 | 企业技术顾问
博客：https://www.dtsola.com
公众号&VX：dtsola
需提供服务，加微信 dtsola，备注：IT咨询，并说明来意。
#人工智能 #上下文工程 #提示词工程 #AI创业 #独立开发者 #AI应用 #RAG #智能体 #AI工具 #AI编程
