Dify 实现企业微信 AI 客服的多轮对话与上下文跟踪，核心在于 Dify 内部会话管理​ 与 企业微信消息路由​ 的协同工作。

🧠 Dify 如何管理上下文

Dify 通过以下机制，让大模型拥有“记忆”能力：

1. 会话 (Session) 机制

   每个对话都绑定一个唯一的 conversation_id。Dify 在收到新消息时，会自动拉取该 conversation_id下的历史消息，与当前问题一同发送给模型，从而维持对话的连贯性。

2. 对话变量 (Conversation Variables)

   对于“查订单”、“退换货”等任务型场景，Dify 允许在工作流中定义变量（如 order_id, step），用于存储和传递关键信息，实现有状态的多轮交互。

3. 上下文优化策略

   为避免超出模型 Token 限制，Dify 会自动处理历史消息：

   • 滑动窗口：默认保留最近 N 轮对话。

   • 摘要模式：对早期的对话内容进行摘要，以保留核心信息，有效延长“记忆”长度。

注意：Dify 的免费版有调用次数限制，生产环境需关注。

🔗 企业微信与 Dify 的对接模式

企业微信本身是无状态的，要实现多轮对话，关键在于将来自同一用户的消息始终路由到 Dify 的同一个会话中。主要有两种对接模式：

方案一：使用现成接入层 (如 dify-on-wechat, LangBot)

这类开源项目已内置会话管理逻辑，能自动处理 conversation_id，是快速上手的最佳选择。

• 工作原理：

  1. 用户在微信发送消息。

  2. 接入层接收消息，根据 FromUserName(用户ID) 或 chat_id(群聊ID) 查找或创建一个唯一的 conversation_id。

  3. 使用该 conversation_id调用 Dify API，Dify 据此返回带上下文的回复。

  4. 接入层将回复发送回企业微信。

• 配置要点：

  • 在 Dify 中创建并发布一个“聊天助手”或“Agent”应用，获取 API Key 和地址。

  • 在接入层（如 dify-on-wechat）的配置文件中，填入 Dify 的 API 信息，并设置 channel_type为 wework(企业微信)。

方案二：自建中间服务 (更灵活可控)

此方案需要您自行编写代码，实现企业微信与 Dify 的对接，但对会话逻辑有完全的控制权。

• 核心步骤：

  1. 消息接收：在企业微信后台设置回调 URL，接收用户消息。

  2. 会话标识：使用企业微信的 FromUserName(用户ID) + AgentID(应用ID) 组合成一个唯一的 session_key。

  3. 状态管理：使用 Redis 等缓存服务，以 session_key为键，存储 Dify 的 conversation_id和对话状态。

  4. 调用 Dify：每次收到消息时，根据 session_key从缓存中获取 conversation_id，并在调用 Dify API 时传入。

  5. 回复用户：将 Dify 的回复通过企业微信 API 发送回给用户。

• 工作流中的上下文管理：

  对于复杂业务，建议在 Dify 中使用 Chatflow / Workflow​ 进行状态管理：

  • 定义变量：在“开始”节点定义 slots(如 order_id, step) 来收集信息。

  • 节点流转：使用“条件分支”和“LLM”节点，根据当前步骤和已收集的槽位信息，决定下一步操作（如追问、查询、结束）。

  • 会话保持：确保每次调用 Dify 时都传入相同的 conversation_id，使工作流能基于完整的对话历史继续执行。

💡 实战技巧与避坑指南

1. 会话超时与清理

   为 Redis 中的会话 session_key设置合理的过期时间（如 30-60 分钟无交互），以释放资源。

2. 控制上下文长度

   在 Dify 中设置保留 5-10 轮对话即可，避免因历史消息过长导致费用增加或模型性能下降。

3. 人工兜底与状态重置

   在 Dify 工作流中设置“转人工”或“对话结束”的条件分支。触发后，应清空 Redis 中的相关会话状态，避免影响下一轮对话。

4. 安全与合规

   企业微信消息可能包含敏感信息。建议在自建服务中对消息进行脱敏处理，并配置 Dify 的敏感词过滤功能。