企业已经在Dify整理了产品资料、配置了问答流程，现在想增加一个能够语音交流的数字人。原来的文档要重新上传吗？调试好的回答逻辑还能继续使用吗？
不一定需要重建。AI数字人对接Dify，可以通过应用API继续调用原有应用，再由数字人呈现回答。 Dify提供应用API，企业后端可以调用已发布的应用，而不是为了更换交互界面重新搭建一套业务逻辑。
一、已有知识库可以复用，但要接对入口
需要复用的不只是文档，还包括已经配置好的知识检索、提示词和对话流程。
以Dify的Chatflow应用为例，它支持通过API接收问题、执行流程、返回回答，并在后续消息中延续会话。因此，接入数字人时可以优先调用这个应用，而不是只把知识库内容导出到另一个系统。
建议先明确分工：Dify负责业务回答，数字人负责接收问题和语音呈现。
不要让Dify回答一次，数字人再调用另一套模型重新改写一次。涉及产品参数和服务条件时，建议尽量保留原应用的答案，减少额外改写。
二、不是粘贴一个网址，而是增加消息转接服务
一个可行的接入流程是：
用户提问 → 数字人取得文字 → 企业后端调用Dify → Dify返回答案 → 数字人播报。
中间的企业后端相当于“转接员”：把问题送到Dify，再把答案送回正确的数字人会话。这是一种基于双方接口的集成设计，仍然需要开发适配。
以金福来数字人对应的公开接口为例，“透传模式”支持连接企业自己的回复流程。平台处理实时数字人、音频及转写，企业后端通过MQTT接收用户消息，再发送文本回复用于播报。
这意味着，Dify数字人接入的重点是消息转发，不是重新训练一个数字人模型。
三、调用Dify，先把这几个参数弄清楚
下面以聊天类应用的 /chat-messages 接口为例。它用于提交用户问题并获取回答，不同应用类型的具体行为应以对应版本文档为准。
| 参数 | 作用 | 接入时注意什么 |
|---|---|---|
query | 用户当前的问题 | 传入本轮提问，不要误传上一轮答案 |
inputs | 应用要求的输入变量 | 按已有应用配置填写 |
user | 终端用户标识 | 不同用户应使用不同标识 |
conversation_id | 需要继续的Dify会话 | 首轮可留空，后续使用返回的会话ID |
response_mode | 回答返回方式 | 按应用类型选择完整返回或流式返回 |
例如用户先问“企业版有哪些功能”，接着问“它支持私有化吗”，第二次请求需要延续同一个Dify会话，才能保留前后关系。
另外，应用API密钥应保存在服务器端，不能直接写进WordPress页面或浏览器JavaScript。
四、想让数字人早点开口，需要正确处理流式回答
Dify的流式返回采用SSE，可以在生成过程中逐步发送回答。对于Chatflow，返回内容还可能包含工作流节点状态，因此不能收到什么就全部交给数字人播报。
转接服务需要识别事件类型：提取回答文字，按顺序发送；工作流日志、心跳和错误信息则单独处理。尤其不能把“节点开始执行”这样的内部信息念给客户听。
数字人一侧也需要对应的流式协议。金福来数字人对应的透传文档提供了 transparent.reply.text.delta 和 transparent.reply.text.done，分别用于发送文字片段和结束通知。
建议先跑通完整回答，再增加流式播报。 先验证答案有没有正确到达，再优化开始说话的时间，更容易定位问题。
五、连续追问不串话，必须维护两套会话的对应关系
数字人的会话ID与Dify的 conversation_id 不是同一个编号。建议在后端保存：
当前网站用户 → 数字人会话ID → Dify会话ID。
Dify的 user 字段用于限定会话、消息和文件等数据的访问范围，但它不是登录认证。企业后端仍需验证用户身份，不能让浏览器任意指定其他用户的标识。
上线前，建议做三组验证：
同题对比： 分别在原Dify应用和数字人中提出同一个业务问题，检查关键内容是否一致。
连续追问： 先问产品功能，再问“那部署方式呢”，检查是否保留上下文。
双用户测试： 同时打开两个独立会话，分别咨询不同产品，检查是否出现答案串线。
这些是建议验收项目，不是已经完成的测试结果。测试时应保留问题、回答和会话标识，方便定位错误。
六、金福来数字人对接Dify，先从现有应用评估
已经搭建Dify应用的企业，建议先准备Dify版本、应用类型、必要输入变量、接入页面和预计并发量，再沟通数字人方案。
金福来数字人官网提供网站接入及企业系统对接相关服务，并设有“咨询试用”入口。企业可以提交上述需求，进一步确认透传模式、消息转接和网页呈现的实施范围，不要在公开表单中提交API密钥。
AI数字人对接Dify，不应只是让人物读出一句欢迎语。真正需要验证的是：原来的知识问答能够继续使用，用户可以连续追问，不同会话保持独立，回答能够正确转成数字人的语音。
把这条流程接好，才能在保留已有业务应用的基础上，增加一个真正可用的数字人交互入口。
