Dify 是一个低代码 AI 应用平台自带知识库、工作流、工具调用。用它接企微可以少写很多代码但也有一些坑要避开。整体架构客户消息 → 企微 Webhook → 你的服务 → Dify API → 知识库检索 → LLM 生成 → 你的服务 → 企微发送你的服务只做两件事接收企微回调、调用 Dify API。知识库、Prompt、模型都在 Dify 侧管理。Dify 侧配置创建应用选聊天助手类型绑定模型DeepSeek / GPT / Claude 都可以。上传知识库把产品文档、FAQ、操作手册传上去Dify 自动做向量化和索引。配置检索策略相似度阈值 0.7返回 top 3别贪多多了反而干扰生成。发布 APIDify 会生成一个 API Key 和 endpoint你的服务用这个调。你的服务桥接企微和 Difyimport requests DIFY_API_KEY app-xxxx DIFY_ENDPOINT https://api.dify.ai/v1/chat-messages def handle_wecom_message(data): text data[content] conv_id data[conversationId] # 调 Dify resp requests.post( DIFY_ENDPOINT, headers{Authorization: fBearer {DIFY_API_KEY}}, json{ inputs: {}, query: text, response_mode: blocking, # 或 streaming user: str(data[senderUin]), } ).json() answer resp.get(answer, 抱歉我没听懂) # 发回企微 send_text(conv_id, answer)流式输出的处理Dify 支持response_mode: streaming但企微没有消息编辑接口发出去的消息不能改。所以流式在企微里的实现是分段发送def handle_stream(data, conv_id): resp requests.post( DIFY_ENDPOINT, headers{Authorization: fBearer {DIFY_API_KEY}}, json{ inputs: {}, query: data[content], response_mode: streaming, user: str(data[senderUin]), }, streamTrue ) buffer for line in resp.iter_lines(): if line: chunk parse_dify_chunk(line) buffer chunk if len(buffer) 50 or chunk.endswith((。, , , \n)): send_text(conv_id, buffer) buffer if buffer: send_text(conv_id, buffer)知识库更新的坑Dify 的知识库更新有延迟刚上传的文档可能几分钟后才能检索到。如果客户问了一个新文档里的问题机器人答不上来别急着调阈值先确认文档索引完成了。另外知识库别塞太多。一个客服机器人放 50 篇高质量 FAQ比放 500 篇杂七杂八的文档效果好得多。会话上下文的维持Dify 的user参数用来做会话隔离同一个 user 的多次调用会共享上下文。但企微的客户可能会话隔几天再来Dify 的上下文早就过期了。做法是把企微的 conversationId 映射成 Dify 的 conversation_id持久化存储def get_dify_conversation(wecom_conv_id): key fdify_conv:{wecom_conv_id} conv_id redis.get(key) if not conv_id: # 新建会话 conv_id create_dify_conversation() redis.set(key, conv_id, ex86400 * 7) # 7 天过期 return conv_id一个真实场景某 SaaS 公司的客服机器人用 Dify 接了 80 篇产品文档和 FAQ。客户问怎么配置 SSO机器人 3 秒内返回步骤截图和链接准确率 85% 以上。剩下的 15% 转人工人工处理完顺手把答案补进知识库。Dify 的价值在于让非技术人员也能维护知识库和 Prompt不用每次都找开发改代码。企微回调和发送的字段在Eyun 开发文档里能查到Dify 的 API Key 在 Dify 控制台生成。
Dify 是一个低代码 AI 应用平台自带知识库、工作流、工具调用。用它接企微可以少写很多代码但也有一些坑要避开。整体架构客户消息 → 企微 Webhook → 你的服务 → Dify API → 知识库检索 → LLM 生成 → 你的服务 → 企微发送你的服务只做两件事接收企微回调、调用 Dify API。知识库、Prompt、模型都在 Dify 侧管理。Dify 侧配置创建应用选聊天助手类型绑定模型DeepSeek / GPT / Claude 都可以。上传知识库把产品文档、FAQ、操作手册传上去Dify 自动做向量化和索引。配置检索策略相似度阈值 0.7返回 top 3别贪多多了反而干扰生成。发布 APIDify 会生成一个 API Key 和 endpoint你的服务用这个调。你的服务桥接企微和 Difyimport requests DIFY_API_KEY app-xxxx DIFY_ENDPOINT https://api.dify.ai/v1/chat-messages def handle_wecom_message(data): text data[content] conv_id data[conversationId] # 调 Dify resp requests.post( DIFY_ENDPOINT, headers{Authorization: fBearer {DIFY_API_KEY}}, json{ inputs: {}, query: text, response_mode: blocking, # 或 streaming user: str(data[senderUin]), } ).json() answer resp.get(answer, 抱歉我没听懂) # 发回企微 send_text(conv_id, answer)流式输出的处理Dify 支持response_mode: streaming但企微没有消息编辑接口发出去的消息不能改。所以流式在企微里的实现是分段发送def handle_stream(data, conv_id): resp requests.post( DIFY_ENDPOINT, headers{Authorization: fBearer {DIFY_API_KEY}}, json{ inputs: {}, query: data[content], response_mode: streaming, user: str(data[senderUin]), }, streamTrue ) buffer for line in resp.iter_lines(): if line: chunk parse_dify_chunk(line) buffer chunk if len(buffer) 50 or chunk.endswith((。, , , \n)): send_text(conv_id, buffer) buffer if buffer: send_text(conv_id, buffer)知识库更新的坑Dify 的知识库更新有延迟刚上传的文档可能几分钟后才能检索到。如果客户问了一个新文档里的问题机器人答不上来别急着调阈值先确认文档索引完成了。另外知识库别塞太多。一个客服机器人放 50 篇高质量 FAQ比放 500 篇杂七杂八的文档效果好得多。会话上下文的维持Dify 的user参数用来做会话隔离同一个 user 的多次调用会共享上下文。但企微的客户可能会话隔几天再来Dify 的上下文早就过期了。做法是把企微的 conversationId 映射成 Dify 的 conversation_id持久化存储def get_dify_conversation(wecom_conv_id): key fdify_conv:{wecom_conv_id} conv_id redis.get(key) if not conv_id: # 新建会话 conv_id create_dify_conversation() redis.set(key, conv_id, ex86400 * 7) # 7 天过期 return conv_id一个真实场景某 SaaS 公司的客服机器人用 Dify 接了 80 篇产品文档和 FAQ。客户问怎么配置 SSO机器人 3 秒内返回步骤截图和链接准确率 85% 以上。剩下的 15% 转人工人工处理完顺手把答案补进知识库。Dify 的价值在于让非技术人员也能维护知识库和 Prompt不用每次都找开发改代码。企微回调和发送的字段在Eyun 开发文档里能查到Dify 的 API Key 在 Dify 控制台生成。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
