用药提醒如果只做成定时推送本质上接近一个带药品名称的闹钟。医疗健康应用里更棘手的问题是用户是否按计划执行、漏服后如何记录、连续异常时是否需要升级提醒以及这些规则如何被机构确认并可审计。本文只讨论技术架构和工程流程示例不提供诊断、治疗、分诊或用药建议所有阈值和分层规则都应由医疗专业人员和机构规范确认。问题拆解提醒系统为什么容易做偏一个可上线的用药依从性模块至少要处理四类数据用药计划、提醒事件、用户反馈、依从性状态。单纯的 cron job 可以按时间发通知但它不知道用户昨天是否漏服也不知道某个用户最近 7 天是否持续未确认。Agent 在这里不应该被设计成“自动给医疗建议”的角色而更适合做流程编排器读取计划、调用规则引擎、生成提醒任务、根据反馈更新状态并把异常情况交给人工或合规流程处理。一个简化的数据流如下Medication PlanReminder SchedulerNotification ServiceUser FeedbackAdherence EngineAgent OrchestratorExample Intervention QueueAudit Log这里的 “Example Intervention Queue” 只是工程队列例如二次提醒、客服回访任务、人工审核任务等具体触达内容和升级规则需要按项目规范配置。技术目标和边界本文采用 Python、FastAPI、PostgreSQL、notification service 和 rules engine 设计一个最小可运行思路。目标不是替代医生或药师而是把“提醒、记录、评分、升级”做成可配置、可追踪、可优化的系统。核心约束建议如下用药计划必须结构化不能只存一段文本。每次提醒都要生成事件便于审计和重试。用户反馈要区分“已服用、跳过、稍后、无响应”等状态。依从性评分只作为示例工程指标不代表医学判断。风险分层、提醒频率、升级策略必须可配置并由专业人员确认。数据模型先把计划和行为分开PostgreSQL 中建议至少拆出三张表计划表、提醒事件表、反馈表。计划表描述“应该发生什么”事件表描述“系统做了什么”反馈表描述“用户回应了什么”。示例字段可以这样设计CREATETABLEmedication_plan(id UUIDPRIMARYKEY,user_id UUIDNOTNULL,medication_nameTEXTNOTNULL,dose_textTEXTNOTNULL,schedule_cronTEXTNOTNULL,start_dateDATENOTNULL,end_dateDATE,statusTEXTNOTNULLDEFAULTactive);CREATETABLEreminder_event(id UUIDPRIMARYKEY,plan_id UUIDNOTNULLREFERENCESmedication_plan(id),scheduled_at TIMESTAMPTZNOTNULL,sent_at TIMESTAMPTZ,channelTEXTNOTNULL,statusTEXTNOTNULLDEFAULTpending);CREATETABLEadherence_feedback(id UUIDPRIMARYKEY,event_id UUIDNOTNULLREFERENCESreminder_event(id),user_id UUIDNOTNULL,actionTEXTNOTNULL,feedback_at TIMESTAMPTZNOTNULL);不要把用户是否服药直接覆盖到计划表里否则后续很难回放历史、排查重复推送、计算周期指标。FastAPI 实现依从性评分和示例分层下面代码演示一个依从性评分接口。它读取最近 N 次提醒事件和反馈计算确认比例并返回一个示例分层。注意阈值仅为工程示例不是医学标准。fromenumimportEnumfromfastapiimportFastAPIfrompydanticimportBaseModelfromtypingimportList,Optionalfromdatetimeimportdatetime appFastAPI(titleMedication Adherence Demo)classAction(str,Enum):TAKENtakenSKIPPEDskippedSNOOZEDsnoozedNO_RESPONSEno_responseclassReminderRecord(BaseModel):event_id:strscheduled_at:datetime action:Optional[Action]Action.NO_RESPONSEclassAdherenceResult(BaseModel):total:inttaken:intscore:floatexample_level:strnext_workflow:strdefcalculate_adherence(records:List[ReminderRecord])-AdherenceResult:totallen(records)iftotal0:returnAdherenceResult(total0,taken0,score0.0,example_levelunknown,next_workflowcollect_more_events)takensum(1forrinrecordsifr.actionAction.TAKEN)scoreround(taken/total,4)# 示例规则真实项目需由医疗专业人员和机构规范确认ifscore0.9:levelstableworkflownormal_reminderelifscore0.7:levelwatchworkflowsend_second_reminderelse:levelattentionworkflowcreate_manual_review_taskreturnAdherenceResult(totaltotal,takentaken,scorescore,example_levellevel,next_workflowworkflow)app.post(/adherence/evaluate,response_modelAdherenceResult)defevaluate_adherence(records:List[ReminderRecord]):returncalculate_adherence(records)测试请求可以这样发curl-XPOST http://127.0.0.1:8000/adherence/evaluate\-HContent-Type: application/json\-d[ {event_id:e1,scheduled_at:2026-05-19T08:00:00Z,action:taken}, {event_id:e2,scheduled_at:2026-05-19T12:00:00Z,action:no_response}, {event_id:e3,scheduled_at:2026-05-19T20:00:00Z,action:taken} ]这个接口不能直接作为医疗决策模块使用但可以作为规则引擎前的一层特征计算服务。Agent 编排让模型做流程选择而不是做医疗判断在这个场景里Agent 的输入应该是结构化状态而不是让大模型自由读取用户描述后生成建议。比较稳妥的方式是规则引擎先给出可解释结果Agent 只在允许的工作流集合里选择下一步。可定义一个状态对象ALLOWED_WORKFLOWS{normal_reminder,send_second_reminder,create_manual_review_task,collect_more_events}defagent_route(adherence_result:dict)-dict:workflowadherence_result[next_workflow]ifworkflownotinALLOWED_WORKFLOWS:workflowcreate_manual_review_taskreturn{workflow:workflow,reason:{score:adherence_result[score],level:adherence_result[example_level],rule_version:demo-rule-2026-05},medical_notice:工程流程示例不生成诊断、治疗或用药建议}这个设计有两个优点第一输出可审计方便排查为什么进入某个流程第二Agent 的行为被限制在系统动作范围内降低生成不可控内容的风险。性能优化别让提醒任务压垮主服务用药提醒有明显的时间尖峰例如早上 8 点和晚上 9 点。优化重点通常不在算法而在任务调度和幂等设计。建议做法提醒事件提前生成例如滚动生成未来 24 小时事件。notification service 使用队列消费避免 FastAPI 请求线程直接发送。reminder_event 增加幂等键例如plan_id scheduled_at channel。对无响应用户做延迟检查不要在发送后立即计算漏服。依从性评分可按用户和周期缓存反馈更新后再失效。如果使用 PostgreSQL可以给待发送事件建立组合索引CREATEINDEXidx_reminder_dueONreminder_event(status,scheduled_at);查询待发送任务时只扫描statuspending且scheduled_at now()的数据配合批量拉取和状态锁定可以减少重复推送。踩坑记录医疗健康场景不要省略审计第一类问题是重复提醒。移动端推送、短信和站内信可能来自不同通道如果没有统一事件 ID用户会收到多次相同提醒。解决方式是所有通道共享 reminder_event并记录每次发送尝试。第二类问题是把“无响应”直接等同于“漏服”。从工程角度看无响应只表示系统没有收到反馈可能是通知未达、用户未点击、网络延迟或设备问题。真实项目应根据机构规则决定如何解释。第三类问题是规则版本不可追踪。依从性评分、分层、升级策略一旦调整历史结果会发生变化。建议在每次计算结果里保存 rule_version便于后续审计和复盘。结论Agent用药提醒的工程重点不是把定时任务包装成智能助手而是建立一套可配置、可审计、可扩展的依从性管理流程。推荐从结构化用药计划、提醒事件、反馈记录和规则引擎开始再把 Agent 放在流程编排层。下一步可以继续完善三件事接入真实 notification service、增加规则配置后台、补充审计日志和人工处理队列。涉及任何风险分层、提醒文案和升级策略时都应由医疗专业人员和机构规范确认。本文文献检索、文献挖掘以及文献翻译采用的是【超能文献| AI文献检索|AI文档翻译】。