1. 初识Dify上下文变量:你的AI应用“记忆中枢”
如果你用过ChatGPT,肯定遇到过这样的烦恼:聊着聊着,AI就把之前聊过的事情给忘了。你刚说完“我喜欢吃辣”,下一句问“有什么餐厅推荐吗?”,它可能给你推荐个粤菜馆。这种“健忘”在简单的聊天里还能忍,但如果你在用它搭建一个客服机器人、一个智能导诊助手,或者一个帮你写周报的AI员工,这种失忆就是致命的。
Dify的上下文变量,就是为了解决这个问题而生的。你可以把它理解为你为AI应用亲手搭建的一个“记忆中枢”或者“随身笔记本”。它不是简单地让AI模型自己记住所有对话历史(那会消耗大量Token,成本高且效率低),而是让你,作为应用的构建者,能够精准地决定什么信息需要被记住,以及如何被记住和调用。
我刚开始接触Dify时,也觉得“变量”这个概念有点技术化,但用多了才发现,它其实是把复杂问题变简单的关键。举个例子,想象你在教一个新人助理工作:你不会让他死记硬背所有对话,而是会给他一个记事本,告诉他:“客户的名字、上次沟通的关键结论、他的偏好,都记在这个本子的第一页;当前正在处理的任务进度,记在第二页。” 这个“记事本”,就是Dify里的上下文变量系统。
在Dify中,变量主要分为四大类:用户变量、系统变量、环境变量和会话变量。我们今天要深入实战的“上下文变量”,主要与系统变量和会话变量紧密相关。系统变量是Dify自动为你记录好的“系统日志”,比如用户这次问了什么(sys.query)、这是第几轮对话(sys.dialogue_count)、会话的唯一ID(sys.conversation_id)等。而会话变量,则是你自定义的“个性化备忘录”,比如用户说“我喜欢用中文沟通”,你就可以把这个偏好存到一个叫 user_language 的会话变量里,让AI在整个对话过程中都记得用中文回复。
为什么这很重要?因为这让你的AI应用从“一问一答的复读机”,进化成了“有状态、有记忆的智能体”。它能基于整个对话的上下文做出更连贯、更个性化的决策,这才是真正实用的AI应用该有的样子。
2. 核心系统变量深度解析与实战场景
Dify预置了一系列以 sys. 开头的系统变量,它们是理解用户和当前会话状态的“传感器”。光知道定义没用,关键是怎么用。下面我结合自己踩过的坑和成功的案例,带你看看这些变量在真实场景里能玩出什么花样。
2.1 sys.query:抓住用户的“当下意图”
sys.query 存储用户当前输入的问题。这看起来最简单,但用好它却是所有复杂交互的起点。
基础用法:直接传递给LLM节点作为问题,或者传递给知识检索节点进行查询。这太基础了,我们来看点高级的。
实战场景一:动态问题预处理 在客服场景中,用户可能输入“我要退款!!!”这样带有强烈情绪和冗余符号的句子。你可以先用一个代码节点,对 sys.query 进行清洗和情绪分析。
import re
def main(query: str) -> dict:
# 1. 清洗文本,去除多余感叹号和空格
cleaned_query = re.sub(r'!+', '!', query).strip()
# 2. 简单情绪判断(实际项目可用更复杂的NLP库)
sentiment = "neutral"
if '!!!' in query or '生气' in query or '投诉' in query:
sentiment = "negative"
elif '谢谢' in query or '好评' in query:
sentiment = "positive"
return {
"cleaned_query": cleaned_query,
"sentiment": sentiment
}
然后,将清洗后的 cleaned_query 传给知识检索,将 sentiment 变量传给LLM。你的系统提示词就可以这样写:“用户情绪为 {
{sentiment}},请用相应的语气回答以下问题:{
{cleaned_query}}”。这样,AI的回复就能更好地匹配用户情绪。
实战场景二:多轮对话中的意图继承 假设你在做一个旅行规划助手。第一轮用户问:“我想去北京玩。” 系统推荐了景点。第二轮用户只问:“天气怎么样?” 这里的 sys.query 只有“天气怎么样?”,缺少了地点。 这时,你需要结合会话变量。在第一轮,当识别到用户确定了目的地“北京”后,用一个变量赋值节点,把“北京”存入一个叫 destination 的会话变量。在第二轮,你的LLM提示词应该这样组合:“用户当前问题是:{
{sys.query}}。结合已知的旅行目的地 {
{destination}},回答用户关于该地天气的询问。” 这样,AI就能准确回答“北京的天气怎么样?”了。
2.2 sys.dialogue_count:对话节奏的“指挥棒”
这个变量记录当前是第几轮对话。它是我实现对话流程控制的秘密武器。
踩坑经验:早期我试图用复杂的逻辑判断对话轮次,比如记录用户

2210

被折叠的 条评论
为什么被折叠?



