应用七：把 Dify 接入现有业务系统

当原型在 Dify 的预览窗口里运行稳定后，下一步通常是把它接进真实产品。集成时最容易混淆的是调用方向：有时是 Dify 主动访问业务接口，有时是业务系统调用已经发布的 Dify 应用。

Dify 调用外部服务

在 Workflow 或 Chatflow 中，可以通过 HTTP 请求节点、已安装工具或自定义工具访问外部 API。例如，客服助手根据订单号查询物流，报告工作流读取统计数据，Agent 使用搜索服务获取公开资料。

这类调用需要明确请求方法、地址、认证、超时和返回结构。先在接口外部验证一份最小请求，再配置到节点中。对返回值只提取后续需要的字段，不要把整个响应无条件传给模型。

应限制 Dify 能访问的目标地址，尤其是自托管环境，避免用户输入被直接拼成任意 URL。写操作要使用专门的低权限凭据，并设计幂等键、确认步骤和失败补偿。

应用发布后，可以通过 Web App 直接分享，也可以由你的服务端调用应用 API。聊天类应用适合连续对话，调用时需要正确维护会话标识；Workflow 更适合一次输入、一次输出的任务；文本生成类应用则用于完成式生成。具体端点和字段应以当前部署版本生成的 API 文档为准。

浏览器前端不应直接持有 Dify API 密钥。更稳妥的结构是：

浏览器 → 你的服务端 → Dify API

你的服务端负责认证用户、限制频率、保存必要的会话映射，并过滤不应返回到前端的字段。Dify 的密钥只保存在服务端环境变量或密钥管理系统中。

把 Dify 应用当作一个独立服务，就要为它定义契约：输入字段及类型、必填项、成功结果、错误结果和超时策略。Workflow 的最终输出尽量使用结构化字段，业务系统不要依赖一段自然语言中的固定句子。

更新工作流时，先在测试环境验证兼容性，再发布新版本。字段改名、删除输出或改变含义都会影响调用方，应像修改普通 API 一样谨慎。

测试正常调用、无效参数、鉴权失败、超时、限流和 Dify 暂时不可用。记录请求标识和错误类别，但不要把 API 密钥、完整提示词或敏感正文写入普通日志。

集成完成的标志不是接口返回了 200，而是调用方能够理解成功与失败、密钥没有暴露、版本变化可以被发现，并且外部系统故障时不会产生错误的业务动作。