emoon-backend/docs/initiatives/FEAT-202606-001-unified-entry-client/需求文档.md

---

doc_id: PRD-202606-001 feature_id: FEAT-202606-001-unified-entry-client type: prd title: 统一入口客户端 v0.1 设计方案 status: approved owner: 医梦研发团队 created_at: 2026-06-17 updated_at: 2026-06-17 reviewers: [] related_docs:

• PRD-202605-001
• ODS-202606-001 related_modules:
• emoon-openplatform
• emoon-ai-agent
• emoon-ai-card
• emoon-ai-mcp tags:
• 统一入口客户端
• 挂号演示
• HIS Mock
• Dify ---

结论：方向可行，但第 3 步必须收敛

你的 4 步整体方向是合理的，但要做三个关键修正：

你原来的想法	判断	修正方案
部署极简 HIS Mock 服务	合理	必须模拟真实 HIS 的关键语义：患者、科室、医生、排班、号源锁定、订单、支付、预约确认
AI 中台通过 MCP 注册 HIS 接口	合理	下周演示不必完整实现标准 MCP 协议，可先实现 MCP Tool Service / HTTP Tool Facade，但接口形态要按未来 MCP 治理设计
DeepSeek 意图识别后转发 Dify 不同 workflow	部分合理，但不能直接这么做	DeepSeek 只能作为“无活跃任务时”的兜底分类器；优先级必须是：任务状态机 > 卡片状态 > 确定性规则 > DeepSeek 分类 > Dify Workflow
Web 端类似蚂蚁阿福完成挂号闭环	合理	Web 端只负责对话和卡片交互，不直连 Dify、不直连 HIS、不直接完成业务写操作

这个边界和你们现有中台技术方案一致：OpenPlatform 负责入口、权限、会话、卡片状态、审计和事实记录；Dify 负责流程编排；MCP/HIS Adapter 负责院内系统工具调用；统一入口客户端负责终端交互，而不是业务事实判断。

---

一、最终建议方案

下周演示建议只做一个清晰闭环：

患者通过统一入口 Web 客户端自然语言发起挂号诉求 → AI 中台识别任务 → Dify 完成问诊/导诊/话术编排 → MCP 调用 Mock HIS 查询科室、医生、号源 → 前端卡片让患者选择 → Card Runtime 执行建档、锁号、支付、预约确认 → 返回挂号成功卡片。

不要做成“Dify 直接把所有事情干完”。原因是挂号、建档、支付、锁号都属于确定性业务动作，必须经过卡片确认、幂等、状态机和后端工具调用。你们对外接口文档也明确：普通终端不得直接调用 HIS Tool，不直接持有 Dify Key；写操作必须幂等；设备和客户端只能走 Agent API、Card Action API、Device API 等受控入口。

---

二、系统分层

2.1 演示版系统组成

统一入口 Web 客户端
  ↓
AI 中台 OpenPlatform
  ↓
AgentRouter / TaskStateService / Card Runtime
  ↓
Dify 挂号智能体 Workflow
  ↓
MCP Tool Service
  ↓
Mock HIS Service

2.2 各层职责

层	负责	不负责
统一入口 Web 客户端	聊天 UI、虚拟助手、业务卡片、二维码展示、用户点击确认	不做业务判断，不直连 Dify/HIS
OpenPlatform	鉴权、会话、任务状态、路由、SSE、卡片实例、审计	不写复杂自然语言流程
AgentRouter	判断当前消息应进入哪个业务流程	不直接生成 AI 回复
DeepSeekIntentClassifier	无活跃任务时做意图识别和槽位抽取	不直接调用 HIS，不决定业务写操作
Dify Workflow	问诊追问、导诊话术、科室推荐解释、卡片输出建议	不直接写 HIS，不直接完成支付
Card Runtime	创建卡片实例、处理用户动作、幂等、推进任务状态	不做自然语言理解
MCP Tool Service	封装 HIS 工具、审计、幂等、错误码映射	不做 UI，不做对话
Mock HIS Service	模拟真实 HIS 业务接口	不包装成真实支付/医保/医院接口

当前 Demo 已经有类似“前端负责统一交互入口，后端负责对话意图路由与业务流程编排”的雏形，但它现在仍是 Demo 级：会话状态在内存里，建档写 CSV，医生排班模拟，卡片协议和任务状态机不完整。下周演示可以借鉴这个交互资产，但不能继续沿用 Demo 后端架构。

---

三、关键流程是否合理

3.1 Step 1：极简 HIS Mock 服务

合理，而且必须先做。

否则 Dify 和前端都只能“假装挂号成功”，甲方追问“科室、医生、号源、支付、预约号从哪里来”时会露馅。

Mock HIS 最小接口

| 模块 | 接口 | 说明 | | -- | -------------------------------------------- | ---------------- | | 患者 | POST /mock-his/patients/search | 根据身份证号/手机号查询患者 | | 患者 | POST /mock-his/patients | 创建患者档案 | | 科室 | GET /mock-his/departments | 查询科室列表 | | 医生 | GET /mock-his/doctors?departmentId= | 查询科室医生 | | 排班 | GET /mock-his/schedules?doctorId=&date= | 查询医生排班 | | 号源 | POST /mock-his/slots/lock | 锁定号源，返回 lockId | | 号源 | POST /mock-his/slots/release | 释放号源 | | 支付 | POST /mock-his/payments/orders | 创建挂号支付订单，返回二维码 | | 支付 | POST /mock-his/payments/mock-paid | 演示用：模拟支付成功 | | 支付 | GET /mock-his/payments/{orderId} | 查询支付状态 | | 挂号 | POST /mock-his/appointments | 支付成功后创建预约 | | 挂号 | GET /mock-his/appointments/{appointmentId} | 查询预约详情 |

Mock HIS 数据表

表	用途
his_patient	模拟患者主索引
his_department	科室字典
his_doctor	医生信息
his_schedule	医生排班
his_slot	号源库存
his_slot_lock	号源锁定记录
his_payment_order	支付订单
his_appointment	挂号记录

关键实现约束

1. 号源锁定必须有过期时间：例如 5 分钟。
2. 创建预约必须校验支付成功。
3. 重复提交必须幂等：同一个 idempotencyKey 不能创建多条预约。
4. 支付必须明确是模拟支付：二维码可以是 demo-payment://orderId=xxx，不要伪装成真实微信/支付宝/医保支付。
5. 号源扣减必须真实发生：甲方反复演示时，应能看到剩余号源减少。

---

3.2 Step 2：AI 中台通过 MCP 注册 HIS 接口

合理，但下周演示不要追求完整 MCP 协议。

建议做一个“符合未来 MCP 思路的 HTTP Tool Service”：

AI 中台 MCP Tool Service
  ├── his.searchPatient
  ├── his.createPatient
  ├── his.listDepartments
  ├── his.listDoctors
  ├── his.listSchedules
  ├── his.lockSlot
  ├── his.releaseSlot
  ├── his.createPaymentOrder
  ├── his.queryPaymentStatus
  └── his.createAppointment

你们中台方案本身也写清楚了：MCP 是医梦内部 AI 工具网关设计，MVP 阶段可以先用 HTTP/JSON Tool Service 实现，不必一次性实现完整 Model Context Protocol 生态；核心目的是让 Dify 工具调用、卡片动作和 HIS Adapter 都进入同一个可授权、可审计、可幂等的工具出口。

工具注册结构

每个工具至少包含：

{
  "toolName": "his.lockSlot",
  "riskLevel": "BUSINESS_WRITE",
  "method": "POST",
  "path": "/mock-his/slots/lock",
  "timeoutMs": 3000,
  "idempotent": true,
  "requiredContext": ["projectId", "conversationId", "patientId"],
  "inputSchema": {},
  "outputSchema": {}
}

风险分级

风险级别	工具	控制策略
查询	查询科室、医生、排班	可由 Dify 调用
敏感查询	查询患者档案	必须有患者身份上下文
业务写入	建档、锁号、预约	必须通过 Card Action，不能由 Dify 直接写
财务动作	创建支付订单、确认支付	必须幂等，必须卡片确认
医疗正式写入	暂无	下周演示不做

---

3.3 Step 3：Dify 挂号智能体与 DeepSeek 意图识别

你的想法里最危险的是这一句：

“调用 DeepSeek 进行意图识别，然后再转发给 Dify 的不同 workflow。”

这句话如果直接照做，会出现几个问题：

1. 用户已经在选时间，输入“下午”，DeepSeek 可能无法判断上下文。
2. 用户正在建档，突然问“医保能报销吗”，系统可能错误切换流程。
3. Dify Workflow 太多，状态分散，难以保证挂号闭环。
4. 写操作如果由 Dify 直接触发，会绕开幂等、卡片确认和审计。
5. 多轮对话中最重要的是任务状态，不是每句话重新识别意图。

正确方案

优先级 1：是否有 activeTask
优先级 2：是否有 waitingCard
优先级 3：确定性规则
优先级 4：DeepSeek 意图分类
优先级 5：Dify Workflow

也就是：

DeepSeek 只做“新任务入口”和“意图兜底”，不做整个挂号流程的主控。

DeepSeek 分类输出

只输出结构化 JSON：

{
  "intent": "REGISTRATION",
  "subIntent": "SYMPTOM_TRIAGE",
  "confidence": 0.91,
  "slots": {
    "symptom": "头疼三天，有点恶心",
    "departmentName": null,
    "doctorName": null,
    "dateText": null,
    "timePreference": null
  },
  "risk": {
    "emergencyLevel": "NORMAL",
    "needEmergencyWarning": false
  },
  "shouldAskClarification": false
}

不允许 DeepSeek 做的事

禁止项	原因
直接返回“挂号成功”	它没有真实 HIS 结果
直接决定扣号源	必须走 MCP 和锁号
直接创建支付订单	财务动作必须幂等
当前任务中每轮都重新路由	会破坏多轮流程
替代任务状态机	无法保证流程可恢复

---

3.4 Step 4：统一入口 Web 客户端

合理。下周演示只做 Web，不要扩展机器人、自助机硬件。

统一入口客户端的真实目标是多终端运行时，但下周甲方演示只需要一个 Web 端先证明“蚂蚁阿福式入口 + 挂号闭环”成立。门诊方案里，统一入口本来就是门诊入口控制点，导诊大屏、自助机、机器人等都属于 P0 入口，但下周不必全部硬件落地。

Web 端必须包含

页面/组件	说明
虚拟助手区域	类似蚂蚁阿福的人机对话入口
聊天消息流	支持用户输入、AI 回复、SSE 流式
快捷入口	我要挂号、我要建档、科室导诊、查医生
建档卡片	姓名、身份证、手机号、性别、出生日期
科室推荐卡片	推荐科室、推荐理由、备选科室
医生选择卡片	医生、职称、专长、可预约日期
时间选择卡片	上午/下午/具体时段、剩余号源
支付二维码卡片	二维码、金额、倒计时、模拟支付按钮
挂号成功卡片	预约号、医生、科室、时间、诊区、二维码凭证
异常提示卡片	无号源、支付失败、信息缺失、流程取消

---

四、确定的端到端流程

4.1 启动前准备

1. 启动 Mock HIS
2. 导入科室、医生、排班、号源、示例患者
3. AI 中台注册 HIS 工具
4. AI 中台配置 DifyAgentEngine
5. Dify 配置挂号相关 Workflow
6. Web 端配置默认 agentCode = outpatient-registration-agent

---

4.2 用户发起挂号

用户输入：

我头疼三天，还有点恶心，想挂号

流程：

Web Client
→ POST /agent/chat/stream
→ OpenPlatform 创建 conversation
→ TaskStateService 判断无 activeTask
→ 规则未完全命中
→ DeepSeekIntentClassifier 分类为 REGISTRATION + SYMPTOM_TRIAGE
→ 创建 REGISTRATION task
→ 调用 Dify triage workflow
→ Dify 追问或推荐科室
→ 创建 department-selection 卡片
→ SSE 返回文本 + 卡片

---

4.3 建档检查

系统发现当前没有患者身份：

TaskStateService
→ currentStep = CHECK_PATIENT_IDENTITY
→ MCP Tool: his.searchPatient
→ 未找到 patient
→ 创建 patient-record 卡片

用户填写：

姓名：张三
身份证：620xxxxxxxxxxxxx
手机号：13800000000

点击确认：

Web Client
→ POST /cards/{cardInstanceId}/actions/confirm_create_patient
→ Card Runtime 校验状态 + 幂等
→ MCP Tool: his.createPatient
→ Mock HIS 创建 patientId
→ TaskStateService 写入 patientId
→ 继续挂号任务

---

4.4 症状分诊与科室推荐

Dify triage workflow
→ 读取 symptom slots
→ 判断是否需要追问
→ 若信息足够，输出推荐科室
→ MCP Tool: his.listDepartments
→ Card Runtime 创建 department-selection 卡片

卡片示例：

{
  "cardKey": "department-selection",
  "data": {
    "title": "为您推荐以下科室",
    "departments": [
      {
        "departmentId": "D010",
        "name": "神经内科",
        "reason": "头痛伴恶心，建议优先排查神经系统相关问题"
      },
      {
        "departmentId": "D001",
        "name": "普通内科",
        "reason": "可作为综合初筛科室"
      }
    ]
  }
}

---

4.5 选择医生

用户点击“神经内科”。

Web Client
→ Card Action: select_department
→ Card Runtime 校验
→ MCP Tool: his.listDoctors(departmentId)
→ Mock HIS 返回医生列表
→ 创建 doctor-selection 卡片

医生卡片：

{
  "cardKey": "doctor-selection",
  "data": {
    "departmentName": "神经内科",
    "doctors": [
      {
        "doctorId": "DOC001",
        "name": "李明",
        "title": "主任医师",
        "specialties": ["头痛", "眩晕", "脑血管病"],
        "availableDateCount": 3
      }
    ]
  }
}

---

4.6 选择时间与锁号

用户选择医生和日期：

Card Action: select_doctor
→ MCP Tool: his.listSchedules
→ 返回可用日期和时段
→ 创建 time-slot-selection 卡片

用户选择时段：

Card Action: select_time_slot
→ MCP Tool: his.lockSlot
→ Mock HIS 创建 lockId，锁定 5 分钟
→ 创建 confirm-registration 卡片

这里必须有锁号，否则演示逻辑不真实。真实 HIS 场景里，号源并发和过期释放是挂号流程的核心风险点；你们技术方案里也明确排班号源工具需要幂等、短锁、超时释放和并发控制。

---

4.7 支付二维码

用户确认挂号：

Card Action: confirm_registration
→ MCP Tool: his.createPaymentOrder
→ Mock HIS 创建 orderId
→ 返回 qrCodeBase64 / qrContent
→ 创建 payment-qrcode 卡片

支付卡片：

{
  "cardKey": "payment-qrcode",
  "data": {
    "orderId": "PAY202606020001",
    "amount": 25.0,
    "qrContent": "demo-payment://PAY202606020001",
    "expireSeconds": 300,
    "debugAction": "mock_paid"
  }
}

演示中可以提供一个“模拟支付完成”按钮，但必须向团队明确：这只是 Mock 支付，不是实际支付。

---

4.8 支付成功后创建预约

用户点击模拟支付完成
→ MCP Tool: his.mockPaymentPaid
→ 前端轮询或主动触发 queryPaymentStatus
→ 支付成功
→ MCP Tool: his.createAppointment(lockId, orderId)
→ Mock HIS 消耗号源
→ 生成 appointmentId
→ 创建 appointment-success 卡片

挂号成功卡片：

{
  "cardKey": "appointment-success",
  "data": {
    "appointmentId": "APT202606020001",
    "patientName": "张三",
    "departmentName": "神经内科",
    "doctorName": "李明",
    "visitDate": "2026-06-05",
    "timeSlot": "09:30-09:45",
    "room": "门诊三楼 302 诊室",
    "queueNo": "A023",
    "tips": "请提前 15 分钟到诊区签到候诊"
  }
}

---

五、推荐的 Dify Workflow 设计

5.1 不建议一开始拆太多 Workflow

为了下周演示稳定，建议先做 1 个 Dify App + 3 个 Workflow 场景分支，而不是做一堆互相跳转的 App。

Dify App

outpatient-registration-agent

内部分支

分支	负责
registration_intake	判断是否挂号、建档、查医生、查科室
triage_recommendation	症状追问、科室推荐、风险提示
registration_reply	围绕卡片动作生成自然语言说明、失败解释、下一步引导

5.2 Dify 不负责的内容

内容	归属
是否有患者身份	OpenPlatform / TaskState
患者建档写入	Card Runtime + MCP
查询医生排班	MCP Tool
锁号	Card Runtime + MCP
支付订单	Card Runtime + MCP
预约创建	Card Runtime + MCP
幂等	Card Runtime / MCP
审计	OpenPlatform
任务状态	TaskStateService

5.3 Dify 输出必须结构化

Dify 每次输出必须包含：

{
  "answer": "我先为您推荐合适的科室。",
  "taskUpdate": {
    "taskType": "REGISTRATION",
    "currentStep": "RECOMMEND_DEPARTMENT"
  },
  "cards": [
    {
      "cardKey": "department-selection",
      "cardData": {}
    }
  ],
  "safety": {
    "riskLevel": "LOW",
    "needEmergencyWarning": false
  }
}

OpenPlatform 必须对这个输出做校验。不能让 Dify 随便输出一个 JSON，前端就直接渲染。

---

六、AgentRouter 的确定实现

6.1 路由优先级

1. 当前是否有 activeTask
2. 当前是否有 waitingCard
3. 用户是否明确取消/切换任务
4. 确定性规则：挂号、建档、医生、科室、支付、取消
5. DeepSeek 意图分类
6. 低置信度澄清

6.2 路由示例

用户输入	当前状态	路由结果
我要挂号	无任务	REGISTRATION_START
头疼三天	无任务	SYMPTOM_TRIAGE
下午	正在选时间	SELECT_TIME_SLOT，不调用 DeepSeek
换个医生	已选择医生	回退到 SELECT_DOCTOR
取消	任意 activeTask	CANCEL_TASK，释放号源
支付了吗	等待支付	QUERY_PAYMENT_STATUS
医保能报销吗	挂号中	临时 FAQ，不中断挂号；回答后提示继续
胸痛喘不上气	任意	EMERGENCY_WARNING，提示急诊/人工

6.3 DeepSeek 分类 Prompt 重点

DeepSeek 分类器不要写成聊天助手，而要写成严格分类器：

你是医院统一入口客户端的意图分类器。
只输出 JSON。
不要回答用户问题。
不要编造医院信息。
不要判断挂号成功。
如果用户处于 activeTask，优先根据 currentStep 解释用户输入。

---

七、核心 Case 验证清单

下周要经得起使用，至少要覆盖这些 case。

7.1 正向链路

Case	输入	预期
直接挂号	我要挂号	追问症状或科室
症状挂号	我头疼三天想看病	推荐科室
指定科室	我要挂神经内科	展示神经内科医生
指定医生	我要挂李明医生	查询该医生排班
指定时间	我要明天上午	筛选明天上午号源
已建档患者	输入手机号/身份证	识别已有患者，跳过建档
新患者	未查到患者	引导建档
支付成功	扫码/模拟支付	创建预约并返回成功卡

7.2 异常链路

Case	风险	处理
无号源	医生无可用号	推荐其他医生/日期
号源锁过期	用户支付太慢	释放号源，提示重新选择
重复点击确认	创建多条预约	幂等返回同一结果
支付失败	订单未支付	提示重试/重新生成二维码
建档信息缺失	无法创建 patient	返回字段校验卡片
用户中途取消	锁号未释放	释放 lockId，任务 cancelled
用户切换科室	状态混乱	回退到科室选择并清理后续状态
急症描述	医疗风险	不走普通挂号，提示急诊/人工
Dify 输出异常	卡片无法解析	降级文本提示 + traceId
Mock HIS 超时	工具失败	返回可解释错误，不假装成功

---

八、演示范围必须冻结

8.1 下周必须做

模块	必做内容
Mock HIS	独立极简服务，使用 SQLite，覆盖患者、科室、医生、排班、号源、锁号、Mock 支付、预约
MCP Tool Service	注册并调用 Mock HIS 工具，写操作带幂等键和 traceId
OpenPlatform	/agent/chat/stream、会话、任务状态、路由、Dify 调用、卡片创建
AgentRouter	activeTask / waitingCard 优先，规则兜底，必要时 DeepSeek 分类
Card Runtime MVP	卡片实例、卡片动作、幂等、状态更新、下一张卡片返回
Dify	一个挂号智能体 App，支持症状追问、科室推荐和失败解释，不直接写 HIS
Web 客户端	对话、卡片、二维码、模拟支付、成功页，所有业务按钮走 Card Action
测试脚本	至少 20 个 case，覆盖正向和异常

8.2 下周不要做

暂缓项	原因
真实 HIS 对接	你们现在没有接口资料
真实支付	周期和合规风险高
医保结算	复杂度远超演示需要
机器人硬件联调	会拖慢挂号闭环
自助机读卡/打印	可用 Web 表单和二维码模拟
完整 Device Registry	下周只需固定演示设备和默认 deviceContext
完整计费账本	先记录 usage/audit，不做真实能力值扣费
多院多租户	演示只做单医院单项目
舌诊/报告解读混入	容易稀释挂号主线

---

九、最终架构流程

flowchart TD
    A["患者在统一入口 Web 输入诉求"] --> B["OpenPlatform /agent/chat/stream"]
    B --> C["加载 conversation 和 activeTask"]
    C --> D{"是否有活跃任务"}
    D -->|是| E["按任务状态继续流程"]
    D -->|否| F["规则 + DeepSeek 意图分类"]
    F --> G["创建 REGISTRATION task"]
    E --> H["调用 Dify 挂号智能体"]
    G --> H
    H --> I["Dify 输出 answer + card suggestion"]
    I --> J["OpenPlatform 校验输出"]
    J --> K["Card Runtime 创建卡片实例"]
    K --> L["Web 客户端展示卡片"]
    L --> M["用户点击卡片动作"]
    M --> N["Card Runtime 校验幂等和状态"]
    N --> O["MCP Tool Service 调用 Mock HIS"]
    O --> P["Mock HIS 返回业务结果"]
    P --> Q["更新 task/card/conversation"]
    Q --> R{"流程是否完成"}
    R -->|否| H
    R -->|是| S["返回挂号成功卡片"]

---

十、推荐技术实现

10.1 Mock HIS

建议：

Spring Boot 3 + SQLite

这里明确改为 SQLite，不使用 MySQL。原因：

1. 下周演示目标是验证真实业务语义，不是验证数据库运维能力。
2. SQLite 单文件部署，方便 Claude/DeepSeek/交付人员本地启动和重置演示数据。
3. Mock HIS 是可替换的演示服务，不进入 AI 中台后端 Maven reactor，也不作为长期生产 HIS 数据库。
4. 后续真实 HIS 接入通过 HospitalAdapter 替换，不依赖 Mock HIS 的数据库选型。

SQLite 必须仍然模拟真实 HIS 语义：号源锁定、锁过期释放、支付状态、预约创建、幂等键、剩余号源扣减都要真实落库，不能用内存随机数据。

服务名

emoon-mock-his

部署

docker-compose:
  - emoon-mock-his
  - emoon-ai-platform
  - dify
  - emoon-terminal-web

emoon-mock-his 挂载一个 SQLite 数据文件，例如 ./data/mock-his.db。演示前提供 seed 脚本初始化科室、医生、排班、号源和示例患者；需要重置演示环境时删除或重新生成该 db 文件即可。

SQLite 表和约束

表	必要约束
his_patient	identity_no、phone 至少一个唯一索引，避免重复建档
his_department	department_code 唯一
his_doctor	关联 department_id，包含职称、专长、诊室
his_schedule	关联医生和日期，包含午别、价格
his_slot	关联排班，包含 total_count、remaining_count、version
his_slot_lock	lock_id 唯一，包含 expires_at、status、idempotency_key
his_payment_order	order_id 唯一，包含 mock:true、status、qr_content
his_appointment	appointment_id 唯一，idempotency_key 唯一

号源锁定和预约创建要用 SQLite 事务包住。his_slot.remaining_count 扣减必须和锁记录/预约记录在同一事务中完成，避免重复点击或并发演示时生成多条预约。

Mock 支付口径

Mock 支付只允许返回 demo-payment://orderId=... 或二维码图片内容，不允许使用微信、支付宝、医保等真实品牌或真实支付文案。前端必须展示“联调演示 / Mock 支付”标识。

---

10.2 AI 中台模块

建议最小新增/改造：

模块	类
路由	AgentRouterService
分类	DeepSeekIntentClassifier
任务	TaskStateService
Dify	DifyAgentEngine
输出校验	DifyOutputNormalizer
卡片	CardInstanceService、CardActionService
工具	McpToolRegistry、McpToolInvokeService
HIS Adapter	MockHisAdapter
支付	MockPaymentTool

你们现有中台工程已经具备 AgentEngine 抽象、Mock 引擎、OpenPlatform 对话入口、项目签名鉴权、会话记录、初步卡片表等基础，但缺口是 DifyAgentEngine 尚未进入统一主链路、MCP 工具协议未形成生产工具集、卡片动作闭环不足。下周工作应优先补这几项，而不是扩展业务场景。

---

十一、演示脚本建议

11.1 标准演示链路

用户：我头疼三天，还有点恶心，想挂号。
AI：我先了解一下情况……是否伴随发热、视物模糊？
用户：没有发热，就是头痛恶心。
AI：建议优先选择神经内科，也可选择普通内科。
用户点击：神经内科。
AI：以下是神经内科可预约医生。
用户点击：李明 主任医师。
AI：以下是可预约时间。
用户点击：明天 09:30。
AI：请确认挂号信息。
用户点击：确认挂号。
AI：请扫码支付挂号费 25 元。
用户点击：模拟支付完成。
AI：挂号成功，预约号 A023，请明天 09:15 到门诊三楼神经内科候诊区签到。

11.2 甲方可能追问

甲方问题	建议回答
这是真实 HIS 吗？	目前是 Mock HIS，用于演示完整接口闭环；真实项目会替换为医院 HIS Adapter，AI 中台和前端不需要大改
支付是真的吗？	当前是模拟支付二维码，演示业务状态流转；真实支付会接医院现有支付平台
AI 会不会乱挂号？	不会。AI 只负责理解诉求和生成建议，挂号、锁号、支付都必须经过卡片确认和后端工具调用
患者信息安全吗？	建档信息不进入 Dify，由后端卡片动作链路提交到 HIS；Dify 只处理必要上下文
Dify 出错怎么办？	OpenPlatform 有输出校验和降级；卡片必须通过 schema 校验后才会落库和展示
后续能接真实 HIS 吗？	可以。Mock HIS 和真实 HIS 都通过同一套 MCP Tool / HospitalAdapter 抽象接入

---

十二、最终判定

这个需求可以做，而且下周演示可行。但必须按下面的边界执行：

1. Mock HIS 先行，覆盖患者、科室、医生、排班、号源、支付、预约。
2. AI 中台作为唯一入口，前端不直连 Dify，不直连 HIS。
3. DeepSeek 只做兜底意图识别和槽位抽取，不做主流程控制。
4. Dify 负责编排和话术，不直接完成建档、锁号、支付、预约写操作。
5. Card Runtime 承接所有关键业务动作，点击卡片后再通过 MCP 调 Mock HIS。
6. MCP Tool Service 是 HIS 唯一工具出口，查询可以给 Dify 用，写操作必须卡片确认。
7. 支付明确为 Mock，只演示二维码、订单状态和预约确认流程。
8. 演示范围只做挂号闭环，不要混入舌诊、报告、机器人硬件、自助机读卡等支线。

冻结后的方案一句话：

统一入口 Web 端负责像蚂蚁阿福一样与患者对话；OpenPlatform 负责会话、任务、路由、卡片和审计；DeepSeek 负责新任务意图分类；Dify 负责挂号流程的话术和分支编排；Card Runtime 负责所有确认动作；MCP Tool Service 负责调用 Mock HIS；Mock HIS 负责模拟真实挂号业务状态。