先说个核心判断：要在Dify里实现对话前自动注入上下文、对话后统一记录日志或触发业务动作，必须绕开那个默认聊天界面的黑盒逻辑，直接去操作底层的工作流节点和API调用链路。

那具体怎么做呢？我们来拆成两段看。

前置处理：在用户消息进入LLM前插入系统指令

前置处理到底在做什么？说白了，就是让每一条用户输入都自动挂上一段固定的引导语。比如“你是一名资深电商客服，请始终使用中文、保持礼貌、不主动提及其他平台”这种。这事儿不能靠前端拼接，否则容易被Dify的上下文压缩机制直接截断或覆盖掉。

操作路径是这样的：进入Dify控制台 → 应用管理 → 选择目标应用 → 点击「工作流」Tab → 新建一个「文本处理」节点，给它取个名字叫“inject_system_context”。

在这个节点的「输入」字段里，填上【{{sys.query}}】；然后在「输出」字段里，填上你是一名资深电商客服，请始终使用中文、保持礼貌、不主动提及其他平台。以下是用户问题：{{sys.query}}。

接着把这个节点拖拽到工作流的最前端，然后把它的输出连接到后续的「意图识别」或「LLM调用」节点的输入端口。需要特别注意一点：必须确保这个节点位于所有RAG检索和条件判断之前，否则系统指令很可能会被知识库内容冲淡，效果大打折扣。

后置处理：对话响应生成后自动写入数据库并触发通知

后置处理需要在LLM完成最终回复、流式响应结束（event: message_end）之后才执行，只有这时候才能拿到完整、可审计的AI输出。

这里有两种主流方法。

方法一：利用Dify内置的「HTTP请求」节点

在工作流末尾添加一个「HTTP请求」节点，配置为POST方法，目标URL填上你自己的Webhook地址（比如https://api.yourcompany.com/log-conversation）。

请求体用JSON格式，关键字段必须包含这些：{"session_id": "{{sys.session_id}}", "user_input": "{{sys.query}}", "ai_response": "{{message.content}}", "timestamp": "{{sys.timestamp}}", "intent": "{{intent.class}}"}。

方法二：通过自定义Python节点做原子化处理

新增一个「Python代码」节点，粘贴以下脚本：

import requests
url = "https://api.yourcompany.com/log-conversation"
payload = {
  "session_id": sys.session_id,
  "user_input": sys.query,
  "ai_response": message.content,
  "intent": intent.class if hasattr(intent, 'class') else 'unknown'
}
requests.post(url, json=payload, timeout=5)

这个节点本身不需要返回值，但【必须勾选“忽略执行失败”】，否则任意网络抖动都可能中断整个对话流，得不偿失。

混合场景：前置校验+后置分发的串联路径

有些场景会更复杂一点——比如需要先验证用户身份再放行对话，等回复完了还要同步推送到企业微信。这时候就必须构建一条严格顺序的链路。

第一步：添加一个「条件判断」节点，去判断请求头里是否含有有效的X-User-ID字段。

第二步：如果字段缺失，就跳转到「返回错误消息」节点，提示“请先登录”。

第三步：如果存在，继续流向「inject_system_context」节点。

第四步：LLM生成响应之后，同时触发两个并行分支——一支走「HTTP请求」写入日志，另一支走「企业微信机器人」节点发送摘要。

第五步：等两个分支都跑完了，才把最终消息返回给前端。

整体来看，这套方案的关键就在于：绕开默认的黑盒，把控制权拿回到自己的工作流手里。这样既实现了上下文注入的精准控制，又确保了日志和通知的完整可审计性。