Agent住院管理从入院宣教到出院随访如何减少护理沟通负担住院管理中的大量沟通并不复杂却高度重复入院注意事项、检查前提醒、护理计划同步、出院后随访确认等。本文从技术架构角度演示如何用 Agent 编排消息、任务和状态流转构建一条从入院宣教到出院随访的自动化链路。本文仅讨论工程流程示例不提供诊断、治疗、分诊或用药建议所有规则均应由医疗专业人员和机构规范确认。场景拆解护理沟通为什么适合做 Agent 编排住院流程里的沟通任务有几个典型特征触发条件清晰入院、检查预约、医嘱状态变化、出院登记、随访日到达。内容模板稳定宣教材料、注意事项、复查提醒、满意度收集。状态需要闭环是否已发送、是否已读、是否确认、是否需要人工跟进。多系统协同HIS、护理系统、消息服务、随访系统、患者端应用。传统做法通常是写一批定时脚本今天入院的发宣教明天检查的发提醒出院第 3 天做随访。问题是脚本之间缺少统一状态机异常重试、人工升级、患者反馈记录会越来越散。Agent 在这里不一定要理解复杂医学知识更适合承担“流程编排器”的角色读取患者住院事件匹配机构确认过的规则生成沟通任务调用消息通道并在失败或超时后触发人工工作队列。技术目标与边界本文示例使用以下技术栈Python FastAPI提供事件接入和任务查询接口。PostgreSQL保存住院事件、沟通任务和执行状态。Message Bus可用 RabbitMQ、Kafka、Redis Stream这里用抽象接口表示。Task Scheduler可用 APScheduler、Celery Beat 或系统级调度器。Agent Orchestrator负责规则匹配、工具调用和状态流转。边界必须明确不让 Agent 生成诊疗建议。不让 Agent 自行判断病情严重程度。不在代码里硬编码真实医疗阈值。所有升级规则、提醒时间、话术模板均作为“示例规则”真实项目需由机构确认。涉及患者数据时需按机构安全规范完成鉴权、脱敏、审计和最小权限控制。总体架构把“消息发送”升级为“流程闭环”可以把系统拆成 5 个核心模块住院事件接入事件标准化Agent流程编排沟通任务表消息发送器患者端确认人工工作队列定时调度器这张图的关键不是“自动发消息”而是每一步都有状态。比如入院宣教发出后如果患者未确认系统可以在配置时间后补发一次仍未确认则进入人工队列由护士决定是否电话沟通。建议先抽象 3 类事件admission_created入院登记完成。inpatient_node_due住院期间某个提醒节点到达。discharge_completed出院流程完成。再抽象 3 类任务education宣教任务。reminder提醒任务。followup出院后随访任务。数据模型设计先把状态存下来下面是一个简化版 PostgreSQL 表结构适合做原型验证。CREATETABLEpatient_stay(id UUIDPRIMARYKEY,patient_id UUIDNOTNULL,ward_codeTEXTNOTNULL,admission_timeTIMESTAMPNOTNULL,discharge_timeTIMESTAMP,statusTEXTNOTNULL,created_atTIMESTAMPDEFAULTnow());CREATETABLEcare_event(id UUIDPRIMARYKEY,stay_id UUIDNOTNULL,event_typeTEXTNOTNULL,payload JSONBNOTNULL,occurred_atTIMESTAMPNOTNULL,processedBOOLEANDEFAULTfalse);CREATETABLEcommunication_task(id UUIDPRIMARYKEY,stay_id UUIDNOTNULL,task_typeTEXTNOTNULL,channelTEXTNOTNULL,template_codeTEXTNOTNULL,statusTEXTNOTNULL,scheduled_atTIMESTAMPNOTNULL,retry_countINTDEFAULT0,last_errorTEXT,created_atTIMESTAMPDEFAULTnow(),updated_atTIMESTAMPDEFAULTnow());这里没有保存具体诊疗内容只保存流程事件和任务状态。真实项目中患者标识、联系方式、消息内容都要结合权限、脱敏、审计策略处理不建议直接把敏感明文散落在任务表里。Agent 编排逻辑用规则驱动不让模型越界住院管理 Agent 可以设计为“规则优先模型辅助”。规则决定是否触发任务模型只用于生成非诊疗类、机构审核过边界内的沟通文本例如把模板变量填入标准话术。一个可落地的编排流程如下消费住院事件。根据事件类型匹配规则。创建沟通任务。调用消息发送工具。根据回执更新状态。超时或失败时进入人工队列。下面给出一个 FastAPI Python 的最小示例。代码中的规则均为示例真实项目必须由机构确认。fromdatetimeimportdatetime,timedeltafromenumimportEnumfromuuidimportuuid4fromfastapiimportFastAPIfrompydanticimportBaseModel appFastAPI(titleInpatient Agent Demo)classEventType(str,Enum):admission_createdadmission_createdinpatient_node_dueinpatient_node_duedischarge_completeddischarge_completedclassCareEvent(BaseModel):stay_id:strpatient_id:strevent_type:EventType occurred_at:datetime payload:dict{}classCommunicationTask(BaseModel):id:strstay_id:strtask_type:strchannel:strtemplate_code:strstatus:strscheduled_at:datetimedefcreate_task(event:CareEvent,task_type:str,template_code:str,delay_minutes:int0)-CommunicationTask:returnCommunicationTask(idstr(uuid4()),stay_idevent.stay_id,task_typetask_type,channelpatient_app,template_codetemplate_code,statuspending,scheduled_atdatetime.utcnow()timedelta(minutesdelay_minutes))defplan_tasks(event:CareEvent)-list[CommunicationTask]: 示例规则 - 入院后发送入院宣教 - 住院节点到达时发送事项提醒 - 出院完成后创建随访任务 真实项目中规则需由医疗专业人员和机构流程确认。 ifevent.event_typeEventType.admission_created:return[create_task(event,education,admission_education_v1,5)]ifevent.event_typeEventType.inpatient_node_due:node_codeevent.payload.get(node_code,general)return[create_task(event,reminder,finpatient_{node_code}_reminder_v1,0)]ifevent.event_typeEventType.discharge_completed:return[create_task(event,followup,discharge_followup_day3_v1,3*24*60)]return[]app.post(/events)defreceive_event(event:CareEvent):tasksplan_tasks(event)# 原型阶段直接返回生产环境应写入 PostgreSQL并发布到消息总线return{event_type:event.event_type,planned_task_count:len(tasks),tasks:[task.model_dump()fortaskintasks]}本地运行pipinstallfastapi uvicorn pydantic uvicorn main:app--reload测试入院事件curl-XPOST http://127.0.0.1:8000/events\-HContent-Type: application/json\-d{ stay_id: stay-001, patient_id: patient-001, event_type: admission_created, occurred_at: 2026-05-07T14:00:00, payload: { ward_code: W01 } }返回结果会包含一个admission_education_v1的宣教任务。后续可以把任务写入 PostgreSQL再由调度器扫描pending且到期的任务发送。任务调度与消息发送不要同步阻塞业务系统住院事件入口不应该直接调用短信、公众号或 App 推送接口。更稳妥的做法是FastAPI 接收事件后快速落库。发布communication_task_created消息。Worker 消费消息并发送。失败后更新retry_count和last_error。超过示例重试次数后进入人工队列。示例 Worker 逻辑如下defsend_message(task:dict)-bool: 示例消息发送函数。 生产环境应对接实际消息通道并记录请求ID、回执、失败原因。 print(fsend{task[template_code]}to stay{task[stay_id]})returnTruedefhandle_task(task:dict)-dict:try:oksend_message(task)task[status]sentifokelsefailedexceptExceptionasexc:task[status]failedtask[last_error]str(exc)returntask如果使用 APScheduler可以每分钟扫描一次到期任务如果任务量较大建议用消息队列加 Worker 横向扩展。护理沟通不是毫秒级业务稳定性、可追踪性通常比极低延迟更重要。人工升级Agent 不是替代护士而是减少重复确认自动化链路必须预留人工介入点。常见触发条件包括消息发送失败。患者长时间未确认。患者回复了无法结构化处理的内容。触发机构配置的示例升级规则。注意这些规则不应写成医学判断而应写成流程判断。例如“随访消息超过配置时间未确认进入人工队列”而不是让 Agent 判断患者是否需要进一步处置。人工队列表可以记录任务来源、最近一次消息、失败原因和处理人方便护士在统一界面处理。踩坑记录住院管理 Agent 最容易失控的地方第一模板版本管理容易被忽略。宣教模板、提醒模板、随访模板都应该有版本号例如admission_education_v1否则上线后很难追踪某位患者收到的是哪版内容。第二事件幂等必须做。HIS 或中间平台可能重复推送同一事件建议用event_id或业务唯一键做去重避免重复发送。第三不要把 LLM 当规则引擎。流程触发、时间节点、升级规则应该可配置、可审计LLM 可以辅助改写非诊疗类表达但不能替代机构制度。第四消息回执比发送成功更重要。发送接口返回成功只能说明通道接收了请求不代表患者已读或已确认。任务状态至少区分pending、sent、confirmed、failed、manual_required。扩展方向从原型到生产还差什么原型跑通后可以按优先级补齐这些能力鉴权与审计记录谁配置了规则、谁查看了患者沟通记录。模板审核流模板上线前经过机构内部确认。多通道降级App 推送失败后按机构规则切换其他通道。可观测性统计任务积压、发送失败率、人工队列数量。配置中心不同病区、不同流程可使用不同模板和时间规则。数据脱敏日志中避免输出患者姓名、联系方式等敏感信息。性能方面早期瓶颈通常不在 Agent 推理而在消息通道、数据库扫描和第三方接口限流。建议先做好任务索引例如给communication_task(status, scheduled_at)建联合索引再考虑复杂优化。总结住院管理 Agent 的价值不在于替代医疗判断而在于把高频、重复、可配置的沟通流程做成闭环事件进入、规则匹配、任务生成、消息发送、患者确认、异常升级。技术实现上FastAPI 负责事件入口PostgreSQL 保存状态消息总线解耦发送链路调度器处理延迟任务Agent 编排规则和工具调用。下一步可以先选一个低风险流程做试点例如入院宣教确认或出院后满意度随访在机构确认规则和模板后再逐步扩展。本文作者超能文献团队(https://suppr.wilddata.cn/)