摘要：在AIGC 应用开发的时候我们通常会遇到两个名词提示词工程和上下文工程，而且在dify的配置上我们也会看到这两个按钮，但是他们是什么关系的，各自对于AIGC应用影响的程度是怎样的？今天我们来详细分析一下。
是否会也有疑问，提示词工程和上下文工程有什么区别？
要简单区分这两者，可以这样理解：
提示词工程，关乎“如何问一个好问题”。
它专注于单次对话的质量，核心是精心设计你的提问方式和指令例如在dify的LLM组件中的系统提示词和用户提示词，以求从大模型那里获得一个直接、准确、高质量的回答。
上下文工程，则关乎“如何维持一场有深度的对话”。
它专注于多轮交互的连贯性与智能性。其核心任务是在复杂的对话或Agent执行过程中，动态地管理与筛选AI所能接触到的背景信息——这包括系统指令 system prompt，user prompt、可用工具 tool 、MCP服务，外部数据例如搜索新闻组件返回的数据以及完整的对话历史。它的最终目标，是用最精炼且相关的“记忆”，引导AI持续输出符合我们期望的行为，避免它“遗忘”或“跑偏”。
这样说，提示词工程是上下文工程中的一部分。
那么是否会有一个疑问，在dify的各种应用中，提示词工程和上下文工程对哪些应用类型有影响了？
我们其实已经很清楚dify的工作室中的应用类型有，聊天助手，agent，chatflow、工作流、文本生成，这几种类型，我们从这几种类型中是否有多轮交互，则可以判断不同应用类型是否受上下文工程的影响。
首先我们先给出一个结论：
那么我们来详细说明一下，这几种类型为什么不同的应用类型对上下文工程有不同的需求：
1. 多轮交互支持分析
a. 聊天助手 & Agent：核心支持
这两种类型是为多轮对话而生的。
聊天助手：这是最经典的对话式应用。用户说一句，AI回复一句，并且能记住之前的对话内容，形成连贯的交流。它天然地维护着一个对话历史，这是实现多轮交互的基础。
Agent：智能体是更高级的“聊天助手”。它不仅支持多轮对话，还在此基础上增加了自主规划和工具调用
的能力。例如，用户说“帮我查一下今天北京的天气，然后规划一个户外活动”，Agent可能会先调用天气工具，再根据结果调用搜索工具，最后生成回答。这个过程本身就是多轮的（用户 -> Agent -> 工具 -> Agent -> 用户），并且依赖于对上下文的深度理解。
b. 工作流：有条件支持
工作流本身是一个有向无环图，它是否支持多轮交互，取决于你是否在流程中集成了 “对话”节点。
不带对话节点的工作流：更像一个单次执行的函数。你输入一组参数，它运行整个流程，输出一个结果，然后结束。例如，一个“新闻稿生成”工作流，你输入主题，它输出文章，对话结束。
带对话节点的工作流例如chatflow：当你将“对话”节点
作为工作流的一部分时，这个工作流就具备了多轮交互的能力。此时，工作流可以：
记住历史对话,大模型组件中的记忆组件。
在每一轮中，将用户问题和工作流中其他节点（如数据库查询、代码执行）的结果相结合，生成回复。
这使得工作流可以构建非常复杂的、基于状态的对话应用。
c. 文本生成：通常不支持
文本生成应用被设计为单次请求-响应模式。你提供一段提示词和内容，它生成一篇文本（如文章、邮件、摘要），任务就完成了。它默认不维护对话历史，每次请求都是独立的。
这里我们，我们就引出一个问题，什么样的提示词是好的提示词工程，应该怎么书写，以及优化方向是怎么样的？
如何写好一份“黄金系统提示词”？
写好系统提示词并非难事，我们可以遵循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 标签的结构化提示词
<role>你是一名专业的邮件写作助手，擅长撰写简洁、礼貌、专业的工作邮件。</role><core_task>根据用户提供的信息，起草或回复一封完整的邮件。</core_task><rules>1. 严格基于用户提供的信息进行创作。2. 如果发现信息不完整（例如缺少时间、地点、负责人等），必须主动向用户提问，严禁自行捏造。3. 邮件语气应始终保持专业与礼貌。</rules><output_format>直接输出完整的邮件正文，布局清晰，段落分明。</output_format>
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，那么它的上下文工程就包括系统提示词、知识库、工具这些内容。
总结与选择建议
如果你需要纯对话、或需要AI自主使用工具完成复杂任务：
选择 聊天助手或 Agent。
你必须高度重视系统提示词和RAG内容、工具、记忆等配置，这是应用好坏的决定性因素。
如果你需要构建一个复杂、确定性强、且需要与外部系统（数据库、API）交互的对话应用：
选择chatflow。
你必须具备强大的上下文工程能力，亲自设计和组装数据流与提示词，将合适的上下文在合适的节点传递给LLM。
如果你的场景是单次任务，不需要记忆历史：
选择 文本生成、工作流。
你的上下文工程重点在于精炼你的输入提示词，而不是管理历史。
简单来说，支持多轮交互的模式，无一例外都对上下文工程有很高的要求。区别在于，聊天助手/Agent提供了开箱即用的管理策略，而chatflow则为你提供了自己动手搭建更复杂上下文管道的强大工具
