AI 患者管理智能客服：从 0 到 1 的技术实战复盘
·
AI 患者管理智能客服：从 0 到 1 的技术实战复盘
当 AI 遇见医疗健康，一个解决 3 亿慢病患者管理难题的技术方案是如何诞生的？
引言：一个被忽视的万亿级市场
你有没有想过这样一个场景？
凌晨两点，一位高血压患者突然感觉头晕目眩。他想查看正在服用的降压药能不能和今晚刚吃的感冒药一起吃，于是他打开手机搜索...
搜索结果众说纷纭，有的说可以，有的说不行。他不敢冒险，只能硬扛到天亮去医院排队。
这不是小说，而是中国 3 亿慢病患者每天都在经历的真实生活。
数据是残酷的：
- 中国慢性病患者已超过 3 亿
- 慢病患者用药依从性不足 40%
- 门诊问诊时间平均不足 10 分钟
- 诊后失访率高达 60%
这些问题，催生了我们团队历时 6 个月打造的 AI 患者管理智能客服系统。
今天，我把整个技术实现过程完整复盘，分享出来。
一、为什么我们要做这件事？
1.1 三个真实的痛点
在项目启动之前，我们做了大量的用户调研。发现了三个核心痛点：
痛点一：用药依从性低
很多患者，特别是老年慢病患者，需要同时服用多种药物。但他们常常：
- 忘记服药
- 不知道药物之间的相互作用
- 自行增减药量
- 停药后也不告诉医生
一项调查显示，慢病患者的用药依从性平均只有 30-40%。这意味着，大部分患者没有按照医嘱正确服药。
痛点二：医患沟通不足
三甲医院的医生平均每天要看 80-100 个病人。每个病人的问诊时间往往不足 10 分钟。
这意味着，医生根本没有时间详细解释：
- 药物的副作用
- 服药的最佳时间
- 饮食禁忌
- 出现异常怎么办
痛点三：患者失访率高
传统随访依赖人工电话回访，效率极低。一个护士一天最多能回访 50 个患者，而且很难做到持续跟踪。
结果就是，患者出院后就像"断了线的风筝"，医生无法掌握他们的康复情况。
1.2 我们的解决方案
基于这些痛点，我们设计了一个 AI 患者管理智能客服系统：
| 痛点 | 我们的解决方案 |
|---|---|
| 用药依从性低 | AI 用药提醒 + 药物相互作用检查 |
| 医患沟通不足 | 7×24 小时 AI 健康问答 + 个性化用药指导 |
| 患者失访率高 | 智能随访 + 持续健康监测 + 异常预警 |
二、技术架构设计
2.1 整体架构
我们的系统采用分层架构设计：
┌─────────────────────────────────────────────────────────────────────────┐
│ 客户端层 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Web 应用 │ │ 移动端 App │ │ 管理后台 │ │
│ │ (Next.js) │ │(React Native)│ │ (React) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────────────┐
│ API 网关层 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 认证授权 │ │ 负载均衡 │ │ 限流熔断 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────────────┐
│ 业务服务层 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 药品管理 │ │ 指标管理 │ │ 评估建议 │ │ 用户管理 │ │
│ │ 服务 │ │ 服务 │ │ 服务 │ │ 服务 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────────────┐
│ AI 引擎层 │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ LangGraph 智能体编排 │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │主控智能体│ │药品智能体│ │指标智能体│ │评估智能体│ │知识智能体│ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────────────┐
│ 数据层 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ PostgreSQL │ │ Redis │ │ MongoDB │ │ MinIO │ │
│ │ + pgvector │ │ 缓存 │ │ 日志存储 │ │ 文件存储 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────────────────────┘
2.2 为什么选择 LangGraph？
在技术选型时，我们对比了多个方案：
| 方案 | 优点 | 缺点 |
|---|---|---|
| LangChain | 生态成熟，文档丰富 | 流程控制不够灵活 |
| LangGraph | 图结构编排，可视化监控 | 学习曲线较陡 |
| AutoGen | 多智能体协作强 | 架构较重 |
| 自研 | 完全可控 | 开发周期长 |
最终选择 LangGraph，核心原因是：
- 图结构清晰：用有向无环图（DAG）来定义工作流，非常适合医疗场景的多步骤流程
- 状态管理：内置的状态管理机制，完美契合患者管理的上下文需求
- 可观测性：每个节点的状态都可以追踪，方便调试和优化
三、核心功能实现
3.1 多智能体协作系统
这是我们系统的核心创新点。我们设计了 5 个专业智能体：
┌─────────────────────┐
│ 用户输入 │
└──────────┬──────────┘
↓
┌─────────────────────┐
│ 主控智能体 │
│ (Main Agent) │
│ │
│ - 意图识别 │
│ - 智能体路由 │
│ - 结果整合 │
└──────────┬──────────┘
│
┌──────────────────────┼──────────────────────┐
│ │ │
↓ ↓ ↓
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ 药品智能体 │ │ 指标智能体 │ │ 评估智能体 │
│ (Drug Agent) │ │(Indicator Agt)│ │(Assess Agent) │
│ │ │ │ │ │
│ - 药品查询 │ │ - 指标记录 │ │ - 健康评估 │
│ - 相互作用 │ │ - 异常检测 │ │ - 建议生成 │
│ - 用药建议 │ │ - 趋势分析 │ │ - 报告生成 │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │
└────────────────────┼────────────────────┘
↓
┌───────────────┐
│ 知识检索智能体 │
│(Knowledge Agt) │
│ │
│ - RAG 检索 │
│ - 知识图谱 │
│ - 向量搜索 │
└───────────────┘
每个智能体的职责：
| 智能体 | 职责 | 输入 | 输出 |
|---|---|---|---|
| 主控智能体 | 意图识别、路由、整合 | 用户消息 | 最终回复 |
| 药品智能体 | 药品相关查询 | 药品名称/症状 | 药品信息/建议 |
| 指标智能体 | 指标记录与分析 | 指标数据 | 记录结果/预警 |
| 评估智能体 | 健康评估建议 | 患者数据 | 评估报告 |
| 知识智能体 | 知识检索 | 查询文本 | 相关知识 |
3.2 对话管理工作流
我们使用 LangGraph 定义了完整的对话流程：
from langgraph.graph import StateGraph, END
from typing import TypedDict, Optional
class ConversationState(TypedDict):
user_input: str
intent: Optional[str]
entities: Optional[dict]
agent_response: Optional[str]
context: Optional[dict]
def build_conversation_workflow():
workflow = StateGraph(ConversationState)
workflow.add_node("preprocess", preprocess_input)
workflow.add_node("intent_recognition", recognize_intent)
workflow.add_node("entity_extraction", extract_entities)
workflow.add_node("agent_routing", route_to_agent)
workflow.add_node("response_generation", generate_response)
workflow.add_node("context_update", update_context)
workflow.set_entry_point("preprocess")
workflow.add_edge("preprocess", "intent_recognition")
workflow.add_edge("intent_recognition", "entity_extraction")
workflow.add_edge("entity_extraction", "agent_routing")
workflow.add_edge("agent_routing", "response_generation")
workflow.add_edge("response_generation", "context_update")
workflow.add_edge("context_update", END)
return workflow.compile()
关键设计点：
- 预处理：清洗用户输入，处理表情、错别字等
- 意图识别：使用 LLM 进行零样本意图分类
- 实体提取：从用户消息中提取关键信息（药品名、症状、时间等）
- 智能体路由：根据意图和实体，路由到最合适的专业智能体
- 结果整合：整合各智能体的返回，生成最终回复
- 上下文更新：更新对话上下文，为下一轮对话做准备
3.3 药品相互作用检查
这是患者最常用的功能之一。当用户同时服用多种药物时，系统会自动检查相互作用：
用户输入多个药品名称
↓
药品名称标准化（药品智能体）
↓
检索药品数据库
↓
查询相互作用数据库
↓
RAG 检索相关文献（知识智能体）
↓
LLM 分析相互作用
↓
风险等级评估（严重/中等/轻度）
↓
生成用药建议
↓
返回结果
核心代码实现：
async def check_drug_interactions(drug_names: List[str]) -> List[InteractionResult]:
# 1. 药品名称标准化
normalized_drugs = await normalize_drug_names(drug_names)
# 2. 查询相互作用数据库
interactions = await query_interaction_db(normalized_drugs)
# 3. RAG 检索相关文献
for interaction in interactions:
relevant_docs = await rag_search(
f"{interaction.drug_a} {interaction.drug_b} interaction"
)
interaction.evidence = relevant_docs
# 4. LLM 分析并生成建议
analysis = await llm.analyze_interactions(interactions)
return analysis
3.4 健康评估工作流
系统会根据患者的用药情况、健康指标、生活方式等多维度数据，生成综合健康评估报告：
用户发起评估请求
↓
收集患者数据
- 基本信息
- 用药清单
- 健康指标
↓
调用评估规则引擎
↓
各维度评分
- 用药合理性 (权重 30%)
- 指标达标率 (权重 30%)
- 生活方式 (权重 20%)
- 风险因素 (权重 20%)
↓
计算综合评分 (0-100分)
↓
生成评估报告
↓
生成个性化建议
↓
返回结果
四、技术实现细节
4.1 知识库设计
我们构建了完整的医疗知识库：
药品知识库：
CREATE TABLE drugs (
id SERIAL PRIMARY KEY,
name VARCHAR(200) NOT NULL,
generic_name VARCHAR(200),
category VARCHAR(100),
indication TEXT,
dosage TEXT,
side_effects TEXT,
contraindications TEXT
);
CREATE TABLE drug_interactions (
id SERIAL PRIMARY KEY,
drug_a_id INTEGER REFERENCES drugs(id),
drug_b_id INTEGER REFERENCES drugs(id),
severity VARCHAR(20), -- 严重/中等/轻度
description TEXT,
recommendation TEXT
);
指标知识库：
CREATE TABLE indicators (
id SERIAL PRIMARY KEY,
name VARCHAR(100) NOT NULL,
unit VARCHAR(50),
normal_range_min DECIMAL(10,2),
normal_range_max DECIMAL(10,2)
);
CREATE TABLE indicator_records (
id SERIAL PRIMARY KEY,
user_id INTEGER NOT NULL,
indicator_id INTEGER REFERENCES indicators(id),
value DECIMAL(10,2),
recorded_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
4.2 RAG 检索增强
为了提供更准确的医疗建议，我们实现了 RAG（检索增强生成）系统：
class MedicalRAG:
def __init__(self):
self.vector_store = PGVector(
connection_string=os.getenv("DATABASE_URL"),
collection_name="medical_knowledge"
)
self.llm = ChatOpenAI(model="gpt-4")
async def retrieve(self, query: str, top_k: int = 5):
# 向量检索
results = await self.vector_store.similarity_search(
query=query,
k=top_k
)
# 重排序
reranked = await self.rerank(query, results)
return reranked
async def generate(self, query: str, context: List[Document]):
prompt = f"""基于以下医学知识，回答用户问题。
医学知识：
{context}
用户问题：{query}
回答："""
response = await self.llm.agenerate([prompt])
return response.generations[0].text
五、踩坑与解决方案
5.1 问题一：医疗专业性不足
症状：早期版本的回答经常出现专业性错误，甚至会给患者带来安全风险。
根因：
- 通用 LLM 缺乏足够的医疗知识
- 无法区分"建议咨询医生"和"可以直接回答"的场景
解决方案：
- 构建专业的医疗知识库，使用 RAG 检索增强
- 引入"安全边界"机制，涉及诊断、处方等高风险内容时，主动提示"请咨询医生"
- 增加多轮确认，确保理解患者的具体情况
- 建立答案审核机制，关键回答需要经过人工审核
5.2 问题二：患者表述不清晰
症状：患者经常用方言、不规范的描述来提问，系统难以理解。
示例：
- "我血压有点高" → 到底是多高？
- "我吃那个降压药" → 哪个降压药？
- "饭后胃不舒服" → 哪个部位？什么感觉？
解决方案：
- 多轮追问：系统会主动追问确认关键信息
- 槽位填充：使用槽位机制，引导患者提供必要信息
- 意图澄清：当意图不明确时，提供选项让患者选择
- 上下文记忆：记住对话历史，避免重复提问
5.3 问题三：响应速度慢
症状：高峰期用户等待时间超过 10 秒，体验很差。
根因：
- 每次请求都调用 LLM，成本高
- 串行处理多个智能体，耗时长
- 数据库查询没有优化
解决方案：
- 缓存策略：常用问题答案缓存，减少 LLM 调用
- 并行处理：多个智能体并行执行，加快速度
- 数据库优化：添加索引，使用连接池
- 异步队列：非实时任务放入队列异步处理
5.4 问题四：并发冲突
症状：多个患者同时用药检查时，出现数据竞争。
解决方案：
import asyncio
from sqlalchemy.ext.asyncio import create_async_engine
# 使用异步数据库连接
engine = create_async_engine(
"postgresql+asyncpg://user:pass@localhost/db",
pool_size=20,
max_overflow=10
)
# 使用数据库事务保证一致性
async def update_patient_record(patient_id, data):
async with engine.begin() as conn:
await conn.execute(
update(patient_records)
.where(patient_records.c.id == patient_id)
.values(**data)
)
六、商业化探索
6.1 商业模式设计
经过深入思考，我们设计了"对患者免费 + 药企按效果付费"的商业模式：
| 收费对象 | 收费方式 | 收入占比 |
|---|---|---|
| 药企 | 按延长治疗周期付费 | 60% |
| 医院 | SaaS 订阅费 | 30% |
| 患者 | 增值服务费 | 10% |
6.2 竞品参考
| 平台 | 核心定位 | 可借鉴点 |
|---|---|---|
| 智云医汇 | 慢病管理 SaaS | 医患连接模式 |
| 方舟云康 | 在线慢病管理 | 药品服务闭环 |
| 易问医 | 诊后医助平台 | 降低失访率策略 |
| 腾讯健康药箱 | 微信生态 SaaS | 私域流量运营 |
6.3 当前进展
- ✅ 完成 MVP 开发
- ✅ 完成内部测试
- ⏳ 正在对接第一家药企客户
- ⏳ 准备启动医院试点
七、经验总结
7.1 技术层面
1. LangGraph 是好工具，但需要深入理解
LangGraph 的图结构确实很强大，但学习曲线也比较陡。我们的建议是：
- 先用简单的线性流程熟悉概念
- 再逐步引入条件分支和循环
- 最后使用并行节点优化性能
2. 医疗场景需要特殊的安全机制
医疗 AI 和通用 AI 不同，容错率极低。我们的经验是：
- 始终保留"人工审核"通道
- 高风险操作需要二次确认
- 建立完善的日志和追溯机制
3. RAG 是降低成本的关键
通过 RAG，我们可以复用已有的医学知识，而不是每次都调用 LLM。这不仅降低了成本，也提高了回答的一致性。
7.2 产品层面
1. 用户体验比功能更重要
很多功能我们开发了很多，但用户最常用的还是"用药咨询"和"指标记录"。
2. 渐进式交互更适合老年用户
很多慢病患者是老年人，他们不太习惯复杂的交互。我们采用了渐进式交互设计：
- 第一步：简单问答
- 第二步：绑定药品
- 第三步：开启提醒
7.3 团队协作层面
1. 医疗 + AI = 跨界人才
这个项目最大的挑战是，需要同时懂医疗和 AI 的人才。我们通过"医疗专家 + AI 工程师"的配对方式来解决。
2. 数据是核心竞争力
医疗知识库需要持续更新和优化。我们建立了数据闭环：
- 用户反馈 → 数据标注 → 模型优化 → 知识更新
结语
做医疗 AI，注定是一个"慢生意"。
它不像社交产品可以快速起量，也不像游戏产品可以一夜爆红。它需要：
- 扎实的医疗知识
- 严谨的技术实现
- 长期的用户信任
但我想说，这个方向值得投入。
因为真正有价值的创新，往往不是那些"最快"的，而是那些"最需要"的。
3 亿慢病患者，值得拥有一个更好的健康管理助手。
如果觉得这篇文章对你有帮助，欢迎点赞、收藏、转发。
关注我，后面会出更多技术实战干货。
本文是 AI 患者管理智能客服项目的技术复盘，记录于 2026 年 3 月。
Agent 垂直技术社区，欢迎活跃、内容共建。
10
0- 0
已为社区贡献4条内容
所有评论(0)