可穿戴设备每天都会产生心率、睡眠、步数、活动强度等数据但开发者真正要解决的不是“采集更多指标”而是把这些指标转成可解释、可追踪、可配置的健康提示。本文从工程角度搭建一个简化版 Agent 服务演示如何完成数据接入、趋势计算、规则判断和建议生成。本文仅讨论技术架构与工程流程示例不提供诊断、治疗、分诊或用药建议所有阈值和升级规则都应由医疗专业人员及机构规范确认。1. 业务问题拆解为什么原始指标很难直接产生价值一个健康类 App 往往能拿到很多字段静息心率、夜间平均心率、睡眠时长、深睡比例、步数、活动分钟数、卡路里等。问题在于单点数据缺少上下文。例如用户今天静息心率为 78这个数字本身很难说明什么。更有工程价值的判断通常依赖与用户自身过去 7 天或 30 天基线对比与睡眠、活动量等指标组合分析判断异常是否连续出现给出可解释原因而不是只输出一句泛化建议保留触发规则便于审计和回溯因此Agent 不应该直接读取一条数据就生成文本而应先完成结构化分析再调用建议生成模块。2. 目标架构让 Agent 只负责“编排”和“解释”一个可落地的架构可以拆成 5 层Wearable APIIngestion ServiceTime-series DBFeature BuilderRules EngineHealth AgentAPI / App / Dashboard各模块职责建议如下Ingestion Service对接 Apple Health、Google Fit、厂商 API 或自有 SDKTime-series DB存储按时间排序的指标可选 TimescaleDB、InfluxDB 或普通 PostgreSQL 分区表Feature Builder计算 7 日均值、偏离幅度、连续天数、睡眠缺口等特征Rules Engine执行可配置示例规则产出结构化事件Health Agent把事件、上下文和安全边界转成用户可读提示这里的关键设计是规则判断和文本生成分离。规则层负责可验证Agent 层负责表达和交互。3. 数据模型先统一指标再谈智能建议可穿戴设备 API 的字段差异很大建议先在服务端统一成内部事件格式。frompydanticimportBaseModelfromdatetimeimportdatetimefromtypingimportLiteral,Optional MetricTypeLiteral[resting_heart_rate,sleep_duration_minutes,deep_sleep_minutes,steps,active_minutes]classWearableMetric(BaseModel):user_id:strmetric_type:MetricType value:floatunit:strmeasured_at:datetime source:strdevice_id:Optional[str]None入库时不要急着覆盖原始数据。建议保留source、device_id、measured_at因为后续排查经常会遇到设备同步延迟、重复上传、时区错位等问题。如果使用 TimescaleDB可以按measured_at建 hypertable如果项目规模较小PostgreSQL 加索引也足够支撑早期验证。4. 趋势计算把“今天的数据”变成“相对变化”下面用 Python 演示一个最小可运行的特征计算逻辑。输入为用户近 14 天聚合数据输出可供规则引擎使用的特征。fromstatisticsimportmeanfromtypingimportList,Dictdefbuild_features(days:List[Dict])-Dict: days 示例 [ {date: 2026-05-01, rhr: 65, sleep: 430, steps: 8200}, ... ] rhr: resting heart rate静息心率 sleep: 睡眠分钟数 iflen(days)8:return{ready:False,reason:not_enough_history}historydays[:-1]todaydays[-1]rhr_baselinemean([d[rhr]fordinhistory[-7:]])sleep_baselinemean([d[sleep]fordinhistory[-7:]])steps_baselinemean([d[steps]fordinhistory[-7:]])features{ready:True,today_rhr:today[rhr],rhr_delta:today[rhr]-rhr_baseline,today_sleep:today[sleep],sleep_delta:today[sleep]-sleep_baseline,today_steps:today[steps],steps_delta_ratio:(today[steps]-steps_baseline)/max(steps_baseline,1),}returnfeatures这里没有写死医学判断只计算“相对自身基线的变化”。在健康建议类系统中相对变化通常比孤立阈值更适合做用户级提示但具体指标、窗口期和触发条件必须按项目要求配置。5. 示例规则引擎输出结构化事件而不是直接输出结论规则引擎可以从简单 JSON/YAML 开始不一定一上来就引入复杂规则平台。下面是一个示例规则函数注意所有阈值仅用于工程演示。defevaluate_rules(features:Dict)-List[Dict]:ifnotfeatures.get(ready):return[]events[]# 示例规则睡眠低于自身 7 日均值较多同时静息心率相对升高# 真实项目中阈值、窗口期和处理流程需由专业人员及机构规范确认iffeatures[sleep_delta]-60andfeatures[rhr_delta]6:events.append({event_type:recovery_attention,severity:notice,reason:sleep_drop_and_rhr_rise,evidence:{sleep_delta_minutes:round(features[sleep_delta],1),rhr_delta:round(features[rhr_delta],1)}})# 示例规则活动量明显低于自身基线iffeatures[steps_delta_ratio]-0.5:events.append({event_type:activity_drop,severity:info,reason:steps_below_personal_baseline,evidence:{steps_delta_ratio:round(features[steps_delta_ratio],2)}})returnevents这种结构的好处是后续可以审计某条提示为什么出现依据哪些指标触发了哪条规则。对于医疗健康相关应用可解释性和可追踪性往往比生成文本的流畅度更重要。6. FastAPI 封装提供建议生成接口Agent 层可以接收规则事件再生成用户可读提示。这里先不用大模型使用模板即可完成最小闭环。fromfastapiimportFastAPIfrompydanticimportBaseModelfromtypingimportList,Dict appFastAPI()classAdviceRequest(BaseModel):user_id:strdaily_metrics:List[Dict]defgenerate_advice(events:List[Dict])-List[str]:advices[]foreventinevents:ifevent[event_type]recovery_attention:eevent[evidence]advices.append(f过去一天睡眠较个人近期均值减少约{abs(e[sleep_delta_minutes])}分钟f静息心率相对升高约{e[rhr_delta]}。建议先关注休息、补水和近期压力因素f如持续不适或指标连续异常请按机构规则联系专业人员。)ifevent[event_type]activity_drop:advices.append(今日活动量明显低于个人近期水平。可以检查是否为设备未同步、休息日或行程变化导致。)returnadvicesor[当前未触发示例提示规则请继续观察趋势变化。]app.post(/agent/health-advice)defhealth_advice(req:AdviceRequest):featuresbuild_features(req.daily_metrics)eventsevaluate_rules(features)return{user_id:req.user_id,features:features,events:events,advices:generate_advice(events),disclaimer:本接口仅为技术流程示例不构成诊断、治疗、分诊或用药建议。}测试时可以先用离线 JSON 数据不要直接接入真实用户数据。等规则、日志、权限和告警链路稳定后再进入沙箱或灰度环境。7. Agent 设计要点避免把健康提示做成黑盒如果后续接入 LLM建议把 Agent 限定为“解释器”和“对话编排器”不要让模型直接决定风险等级。一个安全的调用上下文可以包含用户最近趋势特征已触发的结构化事件允许输出的建议类型禁止输出的内容边界升级规则的固定话术推荐流程是规则引擎先判定事件Agent 再把事件翻译成更自然的说明。例如“睡眠下降 静息心率相对升高”可以解释为“近期恢复状态可能需要关注”但不要扩展成未经确认的医学结论。8. 踩坑记录可穿戴数据服务常见问题第一类问题是时区。用户跨时区旅行时按 UTC 聚合会导致睡眠跨天错位建议保存原始时间和用户本地日期。第二类问题是重复数据。部分设备会补传历史记录入库时应使用user_id metric_type measured_at source做幂等处理。第三类问题是设备缺失。步数为 0 不一定代表用户没有活动也可能是设备未佩戴或权限关闭。建议引入data_quality字段区分真实低值和不可用数据。第四类问题是提示疲劳。如果每天都推送相似建议用户很快会忽略。可以增加冷却时间、合并同类事件并在 App 端展示趋势而不是频繁打扰。9. 总结与下一步把可穿戴数据转成健康建议工程核心不是“接一个 Agent”而是建立稳定的数据标准化、趋势计算、规则审计和安全输出边界。Agent 更适合作为编排层把结构化事件解释成用户能理解的提示。下一步可以继续扩展三件事引入时序数据库做高效查询把规则配置外置到 YAML 或后台管理系统增加日志与回放能力支持规则版本升级后的效果评估。对于真实医疗健康项目所有示例规则、阈值和升级流程都必须经过医疗专业人员、合规团队和机构规范确认。本文文献检索、文献挖掘以及文献翻译采用的是【超能文献| AI文献检索|AI文档翻译】。