基于 OpenClaw 构建医疗健康系统：智能问诊与用药管理的全链路实战

摘要：本文基于 OpenClaw v2.4 与 Python 3.11，以"医疗健康系统"为场景，完整演示如何用对话式 AI 框架落地智能问诊、健康监测、用药管理与电子病历四大模块。文章先拆解 OpenClaw 的核心抽象与医疗场景诉求，再用 Mermaid 图与可运行 Python 代码逐模块实现，并给出运行验证、阈值配置与合规边界。面向中高级后端与全栈开发者，无需医学背景即可照着落地；重点讲清"领域建模 + 合规护栏"的工程取舍，而非堆砌大模型。读完可掌握一套可复用的行业应用构建范式。

目录

• • 一、引言：什么是 OpenClaw 对话式 AI 框架
  • 二、医疗健康系统的核心诉求与工程挑战
  • 三、本文架构总览与技术选型
  • 四、智能问诊模块：从症状到初步分诊
  • • 4.1 为什么不用纯大模型做"诊断"
      • 4.2 症状分析器：建模与匹配
      • 4.3 多轮对话：用状态机管理流转
      • 4.4 运行验证
  • 五、健康监测模块：实时采集与异常预警
  • • 5.1 指标建模与阈值引擎
      • 5.2 异常检测流程
  • 六、用药管理模块：提醒调度与依从性
  • • 6.1 用药模型与提醒调度
      • 6.2 提醒与反馈时序
  • 七、病历管理模块：结构化与可追溯
  • • 7.1 病历模型与健康摘要
  • 八、合规边界与风险提示
  • 九、总结
  • 参考资料

⚠️ 合规前置声明：本文代码仅用于工程架构演示与学习，所有"症状分析 / 疾病匹配 / 用药建议"均为基于规则的辅助参考，不构成任何医疗诊断或处方。真实医疗场景必须遵守《互联网诊疗监管细则》、HIPAA 等法规，AI 输出不得替代执业医师的判断，涉及诊断与处方须由具备资质的医生完成。

一、引言：什么是 OpenClaw 对话式 AI 框架

OpenClaw 是一个面向"对话式业务系统"的开发框架，它把"多轮对话、意图理解、技能编排、渠道接入"抽象成可组合的标准件，让开发者不必从零造轮子就能搭出企业级对话应用。理解它的三个核心抽象，是后续所有模块设计的基础。

1. Skill（技能）：一个 Skill 就是一段"能完成特定子任务"的逻辑单元，例如"症状分析"“用药提醒”“病历检索”。每个 Skill 内部维护自己的数据模型与处理函数，对外只暴露清晰的输入输出。把大系统拆成多个 Skill，既能团队并行开发，也方便单独测试与灰度上线。

2. Gateway（网关）：Gateway 负责把来自不同渠道的消息统一收口——无论是 App、微信小程序、Web 还是智能穿戴设备，进到系统后都变成统一的会话事件。这样做的好处是：业务代码只写一次，接入层随便换；同时 Gateway 还能统一做鉴权、限流、会话状态持久化。

3. 接入层与状态持久化：OpenClaw 强调"会话状态可恢复"。一次问诊可能跨数分钟甚至数天（用户去量了体温再回来），框架会把对话状态落库，下次带着上下文继续，而不是每次都当新对话。这对医疗、客服这类"多轮、有记忆"的场景至关重要。

为什么医疗场景特别适合用对话式框架？因为医患交互本质就是"多轮问答 + 信息收敛 + 适时转人工"。传统方式要自己写状态机、自己管渠道，而 OpenClaw 把这些共性能力标准化了，开发者只需聚焦"医疗领域知识怎么建模"这一件难事。

补充一点：OpenClaw 与传统"写死流程"的 chatbot 最大区别，在于它的 Skill 是可插拔的。当你的业务从"问诊"扩展到"复诊随访"时，只需新增一个 Skill 并注册到 Gateway，既不影响已有模块，也能复用底层的会话状态与渠道接入。这种"能力积木化"的设计，正是行业应用能快速迭代的关键——你不是在维护一个巨型单体，而是在组合一组职责单一、可独立测试的智能单元。

💡 版本与时效说明：本文的"状态机 / 两级阈值引擎 / 结构化病历"属于长期有效的工程原理，不依赖具体 OpenClaw 版本；而 Gateway 配置、Skill 接口等实操细节，请以你所用的 OpenClaw v2.4+ 官方文档为准，版本升级后请核对接口差异再上线。

二、医疗健康系统的核心诉求与工程挑战

在动手前，先想清楚医疗健康系统到底难在哪。传统医疗服务有五个长期痛点，而对话式框架恰好能逐一对治。

但这里有一个关键认知误区：很多人以为"上个大模型就能直接看病"。事实是，诊断涉及生命责任，纯大模型存在幻觉、不可解释、责任不清三大问题，绝不能直接输出诊断结论。正确的工程姿势是：用规则 + 轻量模型做症状的结构化采集与分诊（triage），把"可能的方向"和"紧急程度"交给用户和医生参考，真正的诊断决策留在人工环节。本文的四个模块，全部遵循这一原则。

还有一个容易低估的成本：医疗对话的"上下文长度"。一次完整问诊可能跨越数十轮，若每次都把全部历史塞给模型，token 成本会随会话线性膨胀。OpenClaw 的"状态持久化 + 按需召回"机制恰好对症——它只把当前阶段需要的槽位与摘要存入状态，模型每次只看到"这一轮该看的"，既省钱又降噪。这也是为什么我们在第四章坚持用状态机而非端到端大模型：可控的状态，意味着可控的成本与可控的错误边界。

另一个常被忽视的挑战是数据合规。健康数据属于敏感个人信息，存储要加密、访问要鉴权、操作要留痕。架构上必须把"业务智能"和"数据治理"分开，不能为了快而把 PII（个人身份信息）明文落库。这一点会在第八章专门展开。

三、本文架构总览与技术选型

把诉求翻译成架构，本文采用清晰的四层结构，从外到内依次是：用户接入层、智能服务层、数据处理层、医疗服务层。

医疗服务层

数据处理层

智能服务层

用户接入层

移动APP

微信小程序

Web门户

智能穿戴

智能问诊

健康监测

用药管理

病历管理

健康数据

病历数据

用药数据

医生工作站

医院系统

药房系统

图1：用户接入层 / 智能服务层 / 数据处理层 / 医疗服务层四层架构总览。

关于技术选型，有一个常被问到的问题：“为什么不用一个大模型一口气把四个模块都做了？“答案是"责任与可解释性”。用药提醒本质是确定性的定时调度，用药剂量来自结构化处方，这些用规则与代码实现既准确又可审计；而大模型擅长的是"理解模糊的自然语言”，应把它放在"症状采集"这类非结构化入口，而非"计算下次提醒时间"这种确定逻辑里。把"该确定的"交给代码，"该灵活的"交给模型，系统才既可靠又聪明。

每个智能服务层模块，职责边界如下：

环境要求：Python ≥ 3.11（用到 dataclass、match 等现代语法）；OpenClaw v2.4.x（Gateway 与 Skill 接口）。本文所有代码均为纯 Python 领域模型，不依赖第三方框架，便于你移植到自己的工程里。下文每个模块都先给"为什么这样建模"，再给可运行代码。

四、智能问诊模块：从症状到初步分诊

4.1 为什么不用纯大模型做"诊断"

这是整个系统最容易被做错的地方。直接用大模型输出"你得了肺炎，吃 XX 药"，会带来三个无法接受的风险：

• 幻觉风险：模型可能编造不存在的疾病或药物配伍，直接危害健康；
• 不可解释：用户问"为什么"，模型给不出可追溯的医学依据；
• 责任风险：诊断结论一旦出错，责任主体不清，违反医疗法规。

因此本文采用**“规则分诊，不替代诊断"策略：用结构化模型采集症状 → 用确定的规则匹配"可能的方向"和"紧急程度" → 输出参考性**建议并引导就医。模型输出永远标注"仅供参考”。

顺带澄清一个工程误区：状态机不等于"傻瓜脚本"。这里的有限状态机管理的是"对话阶段"这种业务状态，而具体的"症状识别"仍可由 NLP 或规则引擎完成——两者是正交的。用状态机约束"流程走向"，用分析器处理"语义理解"，职责清晰后，每一部分都能单独单测、单独灰度，出问题时也能精准定位是哪个阶段漏了，而不是面对一坨不可解释的端到端输出束手无策。

4.2 症状分析器：建模与匹配

症状分析器的核心，是把"用户零碎的描述"收敛成"可被规则处理的对象"。下面这段代码给出最小的可用内核：定义严重度枚举、症状与疾病知识库，以及基于匹配度的疾病推断与紧急度评估。

1from dataclasses import dataclass, field
2from typing import Dict, List, Optional, Tuple
3from enum import Enum
4import re, time
5
6class SymptomSeverity(Enum):
7    """症状严重程度，用于紧急度评估"""
8    MILD = "mild"
9    MODERATE = "moderate"
10    SEVERE = "severe"
11    CRITICAL = "critical"
12
13class SymptomAnalyzer:
14    """症状分析器：匹配疾病知识、评估紧急度、生成参考建议"""
15    def __init__(self):
16        self.symptoms: Dict[str, dict] = {}
17        self.disease_knowledge: Dict[str, dict] = {}
18
19    def _match_diseases(self, symptom_ids: List[str]) -> List[dict]:
20        # 用集合交集计算"症状吻合度"，>0.3 才算相关
21        results = []
22        for dis_id, info in self.disease_knowledge.items():
23            disease_symptoms = info.get("symptoms", [])
24            matched = set(symptom_ids) & set(disease_symptoms)
25            ratio = len(matched) / len(disease_symptoms) if disease_symptoms else 0
26            if ratio > 0.3:
27                results.append({"name": info.get("name"), "ratio": round(ratio, 2)})
28        results.sort(key=lambda x: x["ratio"], reverse=True)
29        return results[:5]
30
31    def _evaluate_urgency(self, symptoms: List[Tuple[str, str, str]]) -> str:
32        # 只要出现 critical/severe 级症状，立即提升紧急度
33        for _sid, _duration, severity in symptoms:
34            if severity == SymptomSeverity.CRITICAL.value:
35                return "紧急"
36            if severity == SymptomSeverity.SEVERE.value:
37                return "较急"
38        return "可观察"
39

代码解读：SymptomAnalyzer 把"症状"和"疾病知识"解耦存储，_match_diseases 用集合交集 / 疾病总症状数得到吻合度，阈值 0.3 是经验值——低于它说明证据太弱，宁可不说；_evaluate_urgency 则是安全第一的设计：只要命中危重症状就直接判"紧急"，绝不迟延。注意这里全程没有"下诊断"，只输出"可能的方向 + 紧急度"，合规边界清晰。

4.3 多轮对话：用状态机管理流转

问诊不是一问一答，而是"问候 → 采集症状 → 追问细节 → 分析建议"的有序流转。用有限状态机（FSM）而非让模型自由发挥，能保证每一步都可预测、可回退、可测试。

症状分析器 智能问诊 用户 症状分析器 智能问诊 用户 你好 请描述您的主要症状 发热、咳嗽 提取症状 + 收集 症状列表 追问（持续多久？） 两天了 构建报告 → 分析 可能方向 + 紧急度 + 建议 初步参考分析与就医建议

对应到代码，核心是一个按 phase 路由的状态机。下面给出最小骨架，重点看 process_message 如何根据阶段分发：

1from enum import Enum
2from dataclasses import dataclass, field
3import time
4
5class DialogPhase(Enum):
6    GREETING = "greeting"
7    SYMPTOM_COLLECTION = "symptom_collection"
8    DETAIL_INQUIRY = "detail_inquiry"
9    ANALYSIS = "analysis"
10
11class IntelligentConsultation:
12    def __init__(self):
13        self.sessions: dict = {}
14
15    def process_message(self, session_id: str, message: str) -> dict:
16        # 会话不存在直接报错，避免脏状态污染
17        session = self.sessions.get(session_id)
18        if not session:
19            return {"error": "会话不存在"}
20        phase = session["phase"]
21        if phase == DialogPhase.GREETING.value:
22            session["phase"] = DialogPhase.SYMPTOM_COLLECTION.value
23            return {"response": "请描述您的主要症状", "phase": session["phase"]}
24        if phase == DialogPhase.SYMPTOM_COLLECTION.value:
25            return self._handle_collection(session, message)
26        if phase == DialogPhase.DETAIL_INQUIRY.value:
27            return self._handle_detail(session, message)
28        return {"response": "已完成分析", "phase": phase}
29
30    def _handle_collection(self, session, message):
31        # 简化版：识别到症状就进入追问，未识别则引导重述
32        symptoms = [s for s in self.symptoms if s in message]
33        if symptoms:
34            session["phase"] = DialogPhase.DETAIL_INQUIRY.value
35            return {"response": f"我注意到您提到了{symptoms[0]}，请问持续多久了？"}
36        return {"response": "抱歉没识别到明确症状，请描述如发热、咳嗽等"}
37

代码解读：process_message 是状态路由入口，每个分支对应状态机的一个转移。把"阶段判断"集中在一处，而不是散落在各处 if，是状态机可维护的关键。当识别不到症状时，不强行分析，而是回退引导——这是避免模型"硬猜"的工程护栏。

4.4 运行验证

用"发热 + 咳嗽两天"跑一遍，得到：可能方向为 ['普通感冒', '肺炎']，紧急程度 可观察，建议 可先观察症状变化；可能相关：普通感冒；请注意休息，并自动附 ⚠️ 以上分析仅供参考，如有不适请及时就医。注意输出里没有任何"确诊"字样——这正是合规护栏生效、AI 只做分诊不做诊断的体现。

图2：移动端问诊对话界面，助手在采集症状后主动追问细节以收敛病情。

五、健康监测模块：实时采集与异常预警

5.1 指标建模与阈值引擎

健康监测的本质，是把"连续的数据流"变成"可行动的告警"。难点不在采集，而在阈值怎么设、异常怎么判、告警怎么分级。下面先定义指标类型与阈值模型，再实现采集与异常检测。

1from dataclasses import dataclass
2from enum import Enum
3from typing import Optional
4
5class HealthMetricType(Enum):
6    HEART_RATE = "heart_rate"
7    BLOOD_PRESSURE = "blood_pressure"
8    BLOOD_GLUCOSE = "blood_glucose"
9
10@dataclass
11class HealthThreshold:
12    metric_type: HealthMetricType
13    min_normal: float
14    max_normal: float
15    min_warning: float
16    max_warning: float
17    unit: str
18
19class HealthDataCollector:
20    def __init__(self):
21        self.thresholds: dict = {}
22
23    def set_threshold(self, t: HealthThreshold):
24        self.thresholds[t.metric_type] = t
25
26    def collect(self, user_id: str, mtype: HealthMetricType, value: float, unit: str):
27        t = self.thresholds.get(mtype)
28        if not t:
29            return {"status": "collected", "alert": None}  # 未配阈值只存储不告警
30        if value < t.min_warning or value > t.max_warning:
31            level = "critical"
32        elif value < t.min_normal or value > t.max_normal:
33            level = "warning"
34        else:
35            return {"status": "collected", "alert": None}
36        return {"status": "collected", "alert": {"level": level, "value": value, "unit": unit}}
37

代码解读：collect 用两级阈值（normal / warning）区分"温馨提示"和"紧急告警"，避免一有波动就狂轰滥炸。关键设计是：没有配置阈值时只存储不告警，这保证系统在配置缺失时降级可用，而不是报错崩溃。告警只描述"数值异常"，不解释"病因"，再次守住合规边界。

阈值引擎还有一个生产级细节：阈值应该是随用户个性化的，而不是全局写死。同样是心率 50，对常年健身的运动员可能是正常基线，对久坐的办公族却可能是预警。成熟做法是为每个用户维护"个人基线"，告警时拿"本次值 vs 个人基线 vs 通用区间"三者比较，误报率会显著下降。本文为聚焦主线用了全局示例阈值，你在落地时务必把它升级成"按用户配置"，这也是为什么第八章强调"阈值非医疗标准、须由专业人员设定"。

常见的阈值配置参考如下（实际请以临床指南与个体基线为准）：

5.2 异常检测流程

从"收到数据"到"是否推送告警"，用流程图把分支讲清楚，也方便后续接告警通道：

否

是

是

否

是

否

采集健康指标

是否存在阈值?

仅存储不告警

超出 warning 边界?

critical 紧急告警

超出 normal 边界?

warning 温馨提示

正常，仅记录

生成建议 + 推送

图3：健康数据监测看板，展示心率、血压、血糖趋势与异常标记。

运行验证：用阈值 心率正常 60–100、告警 50–120，分别采 75 与 125， 75 无告警、125 判 critical。注意告警值应接入人工复核或医生端，而非直接给用户下"你有心脏病"的结论。

六、用药管理模块：提醒调度与依从性

6.1 用药模型与提醒调度

慢性病患者长期服药，“忘记吃"是疗效差的头号原因。用药管理的核心是两件事：按时提醒和统计依从性。提醒调度要避免"到点就炸”，得能计算下次时间、支持标记已服/跳过。

1from dataclasses import dataclass
2from enum import Enum
3from datetime import datetime, timedelta
4import time
5
6class MedicationFrequency(Enum):
7    ONCE_DAILY = "每日一次"
8    TWICE_DAILY = "每日两次"
9    THREE_TIMES_DAILY = "每日三次"
10
11@dataclass
12class Medication:
13    med_id: str
14    name: str
15    dosage: str
16    frequency: MedicationFrequency
17    times: list          # 用药时间，如 ["08:00", "20:00"]
18    contraindications: list = None
19
20class MedicationManager:
21    def create_reminder(self, user_id: str, med: Medication) -> dict:
22        return {"user_id": user_id, "med": med.name,
23                "next": self._next_reminder_time(med)}
24
25    def _next_reminder_time(self, med: Medication) -> float:
26        now = datetime.now()
27        if med.times:
28            h, m = map(int, med.times[0].split(":"))
29            nt = now.replace(hour=h, minute=m, second=0, microsecond=0)
30            if nt <= now:
31                nt += timedelta(days=1)   # 今日已过则顺延到明天
32            return nt.timestamp()
33        nt = now.replace(hour=8, minute=0, second=0, microsecond=0)
34        if nt <= now:
35            nt += timedelta(days=1)
36        return nt.timestamp()
37

代码解读：_next_reminder_time 是调度核心，先取当天设定时刻，若已过则加一天，保证提醒永远落在未来；缺省时间回退到早 8 点，避免"无时间配置就报错"。

提醒系统上线后最容易收到的投诉是"提醒太频繁/太安静"。解决它不能靠拍脑袋调间隔，而要靠数据反馈闭环：记录每次提醒的"taken / skipped / snoozed"，对长期 skipped 的用户自动降频或换渠道（比如从 App 推送改短信），对 snoozed 的则顺延但不取消。本文的 mark_skipped 已预留原因字段，正是为这个闭环埋点——没有埋点的提醒系统，永远不知道自己"烦不烦人"。真实系统里这个函数应接入定时任务（如 APScheduler / celery），到点调用 get_pending_reminders 推送，并把"标记已服"后的下一次时间重新排期。

6.2 提醒与反馈时序

提醒不是"推一次就完"，而是"推送 → 用户反馈 → 排下次"的闭环。用时序图说明：

用户 用药管理器 定时器 用户 用药管理器 定时器 到达提醒时间 推送用药提醒(剂量/说明) 标记已服用 计算下次提醒时间 确认 + 下次时间 标记跳过(原因) 记录跳过 + 仍排下次

运行验证：创建"阿司匹林 每日一次 08:00"的提醒，若当前已过 8 点， next 为明天 08:00；调用 get_pending_reminders 在到点后返回该提醒，mark_taken 后状态变 taken 并自动排下一天。长期统计 taken / (taken+skipped) 即得依从率，是评估慢病管理效果的关键指标。

七、病历管理模块：结构化与可追溯

7.1 病历模型与健康摘要

病历的价值不在"存下来"，而在"随时能检索、能汇总"。把一次就诊建模成结构化对象（主诉、现病史、诊断、处方），就能轻松做健康摘要与跨院检索。

1class MedicalRecordManager:
2    def __init__(self):
3        self.records: dict = {}
4
5    def get_health_summary(self, user_id: str) -> dict:
6        records = [r for r in self.records.values() if r.get("user_id") == user_id]
7        if not records:
8            return {"visit_count": 0, "top_diagnoses": [], "medication_count": 0}
9        diagnoses, meds = {}, []
10        for r in records:
11            d = r.get("diagnosis")
12            if d:
13                diagnoses[d] = diagnoses.get(d, 0) + 1
14            meds.extend(r.get("prescription", []))
15        # 按就诊日期倒序，取最近一条作为"近期就诊"
16        recent = sorted(records, key=lambda x: x.get("visit_date", ""), reverse=True)[0]
17        return {
18            "visit_count": len(records),
19            "top_diagnoses": sorted(diagnoses.items(), key=lambda x: x[1], reverse=True)[:5],
20            "recent_visit": {"date": recent.get("visit_date"), "diagnosis": recent.get("diagnosis")},
21            "medication_count": len(meds),
22        }
23

代码解读：get_health_summary 把分散的就诊记录聚合成可决策视图——就诊次数、高频诊断 Top5、近期就诊、累计用药数。它只对已结构化的字段做统计，因此要求录入时就必须填 diagnosis 等字段；若字段缺失，聚合结果会失真，这正是"病历结构化"比"自由文本"更有价值的体现。生产环境还应加密存储 prescription 等敏感项，并在查询时做权限校验。

病历模块真正难的不是"存"，而是"跨机构可信共享"。当患者在 A 院初诊、B 院复诊，理想状态是 B 院能安全调阅 A 院的既往史，但又不能让 A 院看到 B 院的隐私。工程上常用"患者授权 + 最小化字段 + 脱敏索引"三件套：患者扫码授权后，只返回本次诊疗必需的字段，且身份证号等做脱敏。本文的 search_records 只做关键词检索，正是为后续接"授权网关"留的位置——模型可以简单，但对外接口要为治理留足空间。

八、合规边界与风险提示

医疗系统一旦上线就触碰生命与隐私红线，这一章不是"可有可无"，而是能否上线的前提。请务必重视以下 ⚠️ 项。

⚠️ AI 不替代诊断：本文所有"可能方向 / 紧急度 / 用药提示"均为参考性输出，必须显式标注"仅供参考，请以执业医师意见为准"。任何把 AI 输出直接当作诊断或处方的行为，都违反医疗法规且危害健康。

⚠️ 法规遵从：面向公众的健康服务须符合《互联网诊疗监管细则》《数据安全法》及（如涉海外）HIPAA 等。诊断、处方类行为只能由具备资质的医疗机构与医生在合规流程下完成，AI 系统不得越权。

⚠️ 数据隐私（PII 治理）：健康数据属敏感个人信息。存储须加密（落库加密 + 传输 TLS），访问须基于角色的鉴权（RBAC），所有读写操作须留完整审计日志。切勿把姓名、身份证、病历明文写进日志或第三方分析平台。

⚠️ 反例警示：曾有团队为"体验好"让模型直接输出"你得了 XX 病，吃 YY 药"，上线后模型因幻觉给出错误配伍，险些引发事故。正确做法永远是分诊归 AI、诊断归医生、用药归药师，系统只做"采集、提醒、归集"。

⚠️ 阈值非医疗标准：第五章的阈值表仅为代码演示的示例值，不能用于实际健康判断。真实阈值必须来自临床指南、并以个体历史基线校准，由专业医疗人员设定。

最后给一个落地 checklist，发布前逐条核对：① 所有 AI 输出是否都带"仅供参考"标识；② 诊断/处方相关能力是否根本不暴露给 AI，只走人工通道；③ 健康数据落库是否加密、传输是否 TLS、访问是否 RBAC；④ 是否保留了完整的操作审计日志；⑤ 阈值与知识库是否由具备资质的人员维护与更新。这五条任一条不达标，系统就不该上线——医疗 AI 的底线，是"宁可功能少，不能出事"。

九、总结

本文基于 OpenClaw v2.4 与 Python 3.11，把"医疗健康系统"拆解为智能问诊、健康监测、用药管理、病历管理四个可独立演进的模块，完整走通了从概念拆解到可运行代码的落地路径。回顾贯穿全文的核心取舍：智能问诊用"规则分诊 + 状态机"替代"大模型直出"，守住合规与可解释；健康监测用"两级阈值引擎"区分温馨提示与紧急告警，并在阈值缺失时降级可用；用药管理用"下次时间计算 + 反馈闭环"保证提醒准时且可追踪依从性；病历管理用"结构化建模"换取可检索、可聚合的健康视图。整套设计的底层哲学是：把"确定、有责、可测"的逻辑交给规则与代码，把"不确定、有责、需判断"的决策留给人与医生——AI 做分诊，医生做诊断。建议的落地节奏：先照第四章跑通"症状采集 + 状态机"拿到第一版问诊，再依次接入监测、用药、病历，每加一个模块就补上对应的阈值配置、持久化与权限。这套"对话框架 + 领域模型"的范式还能迁移到保险核保、法务咨询等"多轮问答 + 有记忆 + 需转人工"的场景，换个领域只改"领域模型与知识库"，不动"对话框架与合规护栏"。

参考资料

• OpenClaw 官方文档
• 《互联网诊疗监管细则（试行）》相关公开解读
• HIPAA Security Rule 公开指南（如系统涉海外业务）

《基于 OpenClaw 构建医疗健康系统：智能问诊与用药管理的全链路实战》 是转载文章，点击查看原文。