Dify应用开发指南：提示词工程VS上下文工程

是否会也有疑问，提示词工程和上下文工程有什么区别？

要简单区分这两者，可以这样理解：

提示词工程，关乎“如何问一个好问题”。
它专注于单次对话的质量，核心是精心设计你的提问方式和指令例如在dify的LLM组件中的系统提示词和用户提示词，以求从大模型那里获得一个直接、准确、高质量的回答。

上下文工程，则关乎“如何维持一场有深度的对话”。
它专注于多轮交互的连贯性与智能性。其核心任务是在复杂的对话或Agent执行过程中，动态地管理与筛选AI所能接触到的背景信息——这包括系统指令 system prompt，user prompt、可用工具 tool 、MCP服务，外部数据例如搜索新闻组件返回的数据以及完整的对话历史。它的最终目标，是用最精炼且相关的“记忆”，引导AI持续输出符合我们期望的行为，避免它“遗忘”或“跑偏”。

这样说，提示词工程是上下文工程中的一部分。

写好系统提示词并非难事，我们可以遵循Role-Goal-Rules-(Few-Shot)。核心在于清晰、具体、无歧义。你可以遵循以下框架：

1. 明确角色与身份
这是最重要的第一步。清晰地告诉AI：“你现在是……”

• 示例：“你是一位拥有10年经验的资深软件架构师，擅长用通俗易懂的语言解释复杂的技术概念。”

2. 定义核心任务与目标
明确你希望AI完成的具体任务是什么，最终要达到什么目的。

• 示例：“你的任务是分析用户提供的业务需求，并给出推荐的技术栈方案。目标是让非技术背景的决策者也能理解方案的优劣。”

3. 设定规则与约束
这是防止AI“放飞自我”的关键。你需要划定它的行为边界。

• 格式规则：“请用Markdown格式输出，包含标题、要点列表和总结。”

• 内容规则：“只讨论后端技术，不要涉及前端框架。”

• 风格规则：“语气保持专业、中立，避免使用比喻和俚语。”

• 安全规则：“拒绝回答任何与黑客技术相关的问题。”

4. 提供示例（Few-Shot Learning）
“授之以鱼不如授之以渔”，直接给AI一个或几个输入输出的范例，是让它快速理解你期望的最有效方式。

• 示例：

• 用户输入：“我们需要一个能处理高并发订单的电商系统。”

• AI输出（示例）：“推荐技术栈：... 理由：...”

5. 结构化输出
尽管当前的大模型理解能力越来越强，即便面对未经仔细排版的“自然描述式”提示词，也能给出不错的回答。但有意识地使用结构化提示词，仍然是一个好习惯，易于读懂，并且可以少量提升大模型的性能。使用<tag></tag>或##title式的 XML 标签 / Markdown 语法，分割不同指导作用的提示词。

具体示例：邮件写作助手

假设你需要一个帮助撰写专业邮件的 AI 助手，以下分别是非结构化、XML结构化和Markdown结构化的写法，您可以直观感受其中的差异。

1. 非结构化提示词（自然描述）

你是一个专业的邮件写作助手，负责帮我起草和回复工作邮件。邮件需要简洁、礼貌、专业。如果用户提供了关键信息，请将其融入邮件中。如果用户的信息不完整，你必须反问用户以获取缺失的细节，不能自行编造。最后，请用清晰的布局输出邮件正文。

2. 使用 XML 标签的结构化提示词

3. 使用 Markdown 标题的结构化提示词

如果你对回复的格式有严格要求，一定要明确说明。

• 示例：“你的回答必须遵循以下结构：

• 一、核心观点；

• 二、分点论述（至少3点）；

• 三、行动建议。”

6. 迭代与优化
很少有提示词能一次完美。将AI的回复视为测试结果，根据其不足不断调整和优化你的系统提示词。这是一个动态磨合的过程。迭代的方向也是需要遵循这几个规则。

系统提示词的规则我们讨论清楚了，那么上下文工程的策略是什么？。

刚刚我们也说明白了，上下文工程包括系统指令 system prompt，user prompt、可用工具 tool 、MCP服务，外部数据例如搜索新闻组件返回的数据以及完整的对话历史。那么整体的上下文工程的策略是：

1、系统指令 system prompt一定要参照之前的规则，并且复杂任务尽量拆分成不同的小的agent，这样每个不同的agent里面的系统指令就非常清晰。避免系统指令太复杂，越复杂的系统指令，大模型能够处理成功的概率越大低且性能越差。

2、可用工具 tool 、MCP服务都是属于工具类型，尽量引用的精准少量的工具，这里有几个衡量准则：

• 工具间不能有重叠部分

• 可以清楚的描述什么时候调用哪一个工具

• 每个agent围绕核心任务调用的工具，不需要依赖其他工具即可以完成，不能有工具依赖关系。
  

3、rag检索的数据属于外部数据返回1-3个分段最佳：rag数据提供给大模型的上下文必须精准且长度不能太长，能够回答问题，如果是长度为300个字符，rag返回的分段结果必须在1-3个分段之间最好，rag返回的数据越长，可能大模型最后能够识别处理的内容以及生成的结果就不一定贴合问题。

4、历史对话可以采用自动压缩和结构化笔记的方式存储到外部存储，定时从这些压缩的内容或者目录检索到历史对话，可以快速的定位到历史聊天记录，避免把所以的历史记录全部推送给大模型，让大模型迷失在历史聊天记录里面了。在dify中有个配置按钮，缓存历史了解记录的按钮，尽量配置成5-10，不要超过10.

那么在dify中它的上下文工程配置涉及哪些了？下面是大模型组件中相关的配置：

这里包括 上下文输入框：这里可以填入rag检索的内容，也可以是工具返回的内容。接下来就是系统提示词、用户提示词、助理提示词、记忆功能就是历史聊天记录。

而对于聊天助手、agent，那么它的上下文工程就包括系统提示词、知识库、工具这些内容。