背景最近在做项目里面涉及AI应用领导选型为dify为此需要研究下关于AI应用大家是如何做的在此分析了medical-consultation-system项目https://gitee.com/hn2004214/medical-consultation-system受益匪浅此dify中的工作流具有通用性。分析前端后端数据库在此就不在分析仅仅分析dify中的AI应用以及如何用最简单方法调用AI应用。从dify中的图标可以看出这里创建的就是“工作流”。进入后流程还是比较简单的开始时开始有几个参数如下从中可以知道这个就是调用AI应用的输入因为是医疗系统嘛大家应该都明白的在此就说明一个东西history对话历史JSON这个是最关键的API调用不像使用对话框大模型是没有记忆功能的需要用户在每一次交流时带上历史的对话进行AI再进行分析。第二个节点就是知识库查询第三个节点就是路由判断判断是继续追问还是得出分诊结果。看下追问生成的LLM逻辑这个qwen3:0.6b是我自己配置调试能用真实项目看自己配置首先是SYSTEM为对话提供高层次指导你是一个医疗预检分诊 AI 助手负责根据患者主诉进行关键追问。 ## 追问原则 1. 围绕症状的「发病时间、部位、程度、伴随症状、诱因」等关键维度 2. 参考患者健康档案的基础病做针对性追问如高血压患者问血压 3. 如医生提供了打回理由必须按医生指示方向提问 4. 语气友好关切避免给出诊断结论 5. 一次最多追问 2 个问题不可过多 6. 直接输出追问内容纯文本禁止 JSON、禁止 markdown 代码块 # 知识库参考 请优先参考知识库检索结果中的分诊规则、急危重症提示和问诊规范。 如果知识库内容与当前患者描述无关不要强行引用。 ## 示例输出 请问您的头痛是搏动性的还是持续性钝痛是否伴有恶心呕吐或畏光症状然后是User向模型提供指令# 患者健康档案 {{#start_1.patient_profile#}} # 医生打回理由如有 {{#start_1.doctor_reason#}} # 对话历史 {{#start_1.history#}} # 患者最新消息 {{#start_1.user_message#}} #知识库参考 {{#context#}} 请结合知识库参考、患者健康档案、医生打回理由和对话历史输出 1-2 个关键追问纯文本。最终输出是一个变量下面是综合分诊需要用户主动提交首先是SYSTEM为对话提供高层次指导你是一个医疗预检分诊专家 AI负责根据患者对话、健康档案给出结构化分诊建议。 ## 输出格式严格 JSON禁止任何 markdown 代码块或额外文字 { is_final: true, recommended_dept: 神经内科, possible_causes: [偏头痛, 紧张型头痛], advice: 建议充分休息并监测体温若症状持续或加重请前往急诊。, urgency_level: 一般, answer: 根据您的描述结合您的健康档案初步建议前往神经内科…… } ## 字段约束 1. is_final**必须严格为 true**标识分诊建议已最终生成供后端更新状态 2. recommended_dept常见一级/二级科室如 内科 / 外科 / 神经内科 / 呼吸内科 / 消化内科 / 心血管内科 / 骨科 / 皮肤科 / 儿科 / 急诊科 / 妇科 / 泌尿外科 / 耳鼻喉科 等 3. possible_causes数组列出 2-3 个最可能的病因 4. advice居家护理或就医建议不超过 100 字 5. urgency_level**必须严格是** 一般 / 紧急 / 危重 三者之一 - 危重意识障碍、胸痛胸闷、呼吸困难、大出血、持续剧烈头痛 - 紧急持续高热、剧烈疼痛、症状持续加重 - 一般常见轻度症状 6. answer给患者看的人性化解释语气温和专业不超过 200 字 # 知识库参考 请优先参考知识库检索结果中的分诊规则、急危重症提示和问诊规范。 如果知识库内容与当前患者描述无关不要强行引用。 ## 注意事项 - 如果医生提供了打回理由必须在建议中明确体现对该理由的回应 - 如果打回理由中含有【医生仅要求修改以下字段】提示请**重点重新生成这些字段**其他字段尽量与上次分诊保持一致同时 answer 要围绕这些字段的修改进行解释 - 结合患者健康档案中的既往病史、过敏史、家族史等因素综合判断 - 绝对不要输出 JSON 之外的任何内容然后是User向模型提供指令# 患者健康档案 {{#start_1.patient_profile#}} # 医生打回理由如有 {{#start_1.doctor_reason#}} # 完整对话历史 {{#start_1.history#}} # 患者最新消息 {{#start_1.user_message#}} # 知识库参考 {{#context#}} 请结合知识库参考、患者健康档案、医生打回理由和完整对话历史输出分诊 JSON。开放接口就选择“访问API”进行配置即可查看下HTTP调用的例子看下这个开源项目里面python是如何调用的class DifyClient: Dify 工作流调用客户端。 本项目使用模块底部的全局单例 dify_client 即可一般无需手动实例化。 使用方式 result await dify_client.run_workflow( user_message头痛、发烧两天, conversation_id1, patient_profile32岁 女 高血压3年 青霉素过敏, target_nodefollowup, history[{role: user, content: ...}, ...], ) def __init__( self, api_base: str | None None, api_key: str | None None, timeout: float 60.0, ) - None: # api_base / api_key 默认从应用配置读取可被参数覆盖以便单测注入 mock # rstrip(/) 防止配置里末尾多写斜杠导致 URL 拼出 //workflows/run self.api_base (api_base or settings.dify_api_base).rstrip(/) self.api_key api_key or settings.dify_api_key # LLM 推理可能耗时较长给到 60 秒超时 self.timeout timeout property def _headers(self) - dict[str, str]: Dify 要求所有请求携带 Bearer token每个工作流绑定一个独立 API Key。 return { Authorization: fBearer {self.api_key}, Content-Type: application/json, } async def run_workflow( self, *, user_message: str, conversation_id: int, patient_profile: str, target_node: str, history: list[dict[str, str]] | None None, doctor_reason: str | None None, ) - dict[str, Any]: 调用 Dify 工作流 /workflows/run 接口本客户端的唯一对外入口。 Args: user_message: 患者最新一条消息文本用于 LLM 推理与知识检索 query。 conversation_id: 会话 ID仅用于 Dify 端日志追踪与限流隔离。 patient_profile: 患者档案摘要已由 profile_service 拼接为单行字符串。 target_node: 工作流路由开关仅接受 triage 或 followup。 对应 YAML 中 if_else_1 节点的判断条件。 history: 对话历史 [{role, content}, ...]会被 json.dumps 后 作为字符串变量传入工作流Dify 变量类型限制。 doctor_reason: 医生打回时的修正意见非打回场景传 None。 Returns: 统一契约 dict { is_final: bool, # True 时上层将更新会话状态为 pending_review assistant_text: str, # AI 回复文本给患者看 triage_payload: dict | None, # 综合分诊节点的结构化结果4 个字段 } Raises: RuntimeError: 网络异常或 Dify 返回非 2xx 时抛出由上层 service 捕获处理。 # ---------- 降级分支未配置 Dify 时直接返回 Mock 数据 ---------- # 占位符 your-dify* 是 .env.example 里的默认值 # 用 startswith(your-dify) 兼容用户忘改 .env 的情况。 if not self.api_key or self.api_key.startswith(your-dify): logger.warning(DIFY_API_KEY 未配置或为占位符使用 Mock 模拟返回) return self._mock_response(user_message, target_node) # ---------- 构造请求 payload ---------- # inputs 中 6 个 key 必须与 Dify 工作流 开始 节点定义的 6 个变量一一对应。 # 任何 key 缺失或拼写不一致都会被 Dify 返回 400。 url f{self.api_base}/workflows/run payload { inputs: { # 与 YAML 中 start_1.variables 严格对齐 user_message: user_message, conversation_id: str(conversation_id), # Dify text-input 类型要求字符串 patient_profile: patient_profile or , target_node: target_node, # 决定走 triage 还是 followup 分支 # Dify 不支持复杂结构变量对话历史需序列化为 JSON 字符串后再注入 prompt history: json.dumps(history or [], ensure_asciiFalse), doctor_reason: doctor_reason or , }, # blocking一次性返回完整 JSON后端要解析 is_final 才能决定状态机跳转 # 因此不能用 streamingSSE 流式更适合给前端做打字机效果。 response_mode: blocking, # Dify 用 user 标识做对话隔离 限流计数同会话保持一致即可 user: fpatient-{conversation_id}, } # ---------- 发起 HTTP 请求 ---------- # 用 async with 上下文确保连接关闭避免连接泄漏每次创建短连接以隔离故障。 try: async with httpx.AsyncClient(timeoutself.timeout) as client: resp await client.post(url, headersself._headers, jsonpayload) print(Dify原始返回报文, resp.text) print(请求发送的body, json.dumps(payload, ensure_asciiFalse)) resp.raise_for_status() # 4xx/5xx 抛 HTTPStatusError data resp.json() except httpx.HTTPError as exc: # 把 httpx 体系下所有异常统一为业务侧的 RuntimeError # 上层 service 不必感知 httpx 细节反腐层关键设计。 logger.exception(调用 Dify 工作流失败%s, exc) raise RuntimeError(fDify 工作流调用失败{exc}) from exc # ---------- 解析响应并返回统一契约 ---------- return self._parse_response(data, target_nodetarget_node)可知都放到input里面。优化提升点知识库的准确性是最重要得准备好数据进行召回测试如果使用其他方式可能会让整改工作流变慢这种呢准确性很感觉。感觉这个地方是提升的重点。