ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

用大模型和Agent打造私人AI健康伴侣:从数据采集到主动关怀的完整实践

用大模型和Agent打造私人AI健康伴侣:从数据采集到主动关怀的完整实践 过去大半年我每天醒来的第一件事不是刷消息而是对着手机问一句昨天睡得好吗回答我的不是闹钟也不是对象而是一个我自己搭建的AI健康伴侣。它知道我的心率、睡眠、活动量甚至能察觉我最近有没有连续熬夜。这个项目最初只是周末折腾的玩具现在却成了生活里离不开的一个角色。市面上的健康管理App我用过不少微信步数、智能手表、在线问诊功能看着很全但用久了总感觉不对劲——它们只是把数据堆在屏幕上让我自己看自己判断。而我希望的是一个主动的、会说话的、真正理解我生活节奏的伴侣。于是从今年年初开始我把打造自己的AI健康伴侣当成一个正经项目来做。这篇文章不是产品发布会也不是学术论文就是一次实实在在的项目复盘从需求定义到架构设计从核心功能实现到踩坑记录再到真实体验数据。如果你也想做一个能陪你聊健康、盯作息、给建议的AI系统这篇文章应该能帮你省下不少弯路。1. 现成的健康App用了五年我还是决定自己造一个1.1 大厂健康应用到底哪里让我不满意先说清楚不是大厂产品做得不好而是它们的定位和我想要的差距太大。我手机里曾经同时装着三个健康类App一个绑定了运动手表一个用来记录饮食热量还有一个是体检报告解读。结果就是数据被分成了三块彼此之间完全不说话。手表告诉我昨晚深睡只有40分钟饮食App说我今天碳水超标体检报告又说甘油三酯偏高——但没人帮我把这些信息串起来。更要命的是这些App的建议永远是一副标准答案腔调。睡眠不好就让我保持规律作息心率偏高就让我避免过度劳累血糖异常就让我注意饮食。这话没毛病但等于没说。我真正想知道的是以我这周的工作强度、最近这段焦虑状态、加上昨晚那顿烤肉到底最需要调整哪一个变量没有哪个App能回答这个问题。还有一个绕不开的痛点隐私。我的健康数据是极其私密的把心率、睡眠、甚至心理状态上传到某个云端平台总有一种说不出的不安全感。我倒不是怀疑大厂的技术而是不希望这些数据被用于我不了解的地方。与其担忧不如自己搭一套可控的系统核心数据留在本地只有需要深度分析时才选择性地调用云端AI。1.2 我需要的不是数据面板而是一个会说话的私人健康助理想明白了不满意的地方我重新定义了需求。我要的不再是看板而是一个能对话的、有常识的、能结合我生活背景的健康助理。它可以不完美但必须具备三个特征。第一是主动。不需要我每天打开App去问它应该在发现连续失眠时主动问我最近是不是压力很大要不要调整一下今晚的放松方式第二是个性化。它得知道我是程序员经常久坐晚上有喝咖啡的习惯周三晚上会打球。同样的心率数据在运动日的早晨和开会前的上午意义完全不同。第三是可解释。它给出建议时得有依据。为了支撑这三点单纯靠规则引擎远远不够必须引入大语言模型来承担理解和生成的部分。1.3 目标定清楚功能边界与不做什么项目启动前我给自己画了一根红线AI健康伴侣能做生活方式建议、能帮我发现数据里的异常趋势但绝不给任何疾病诊断也不替代医生。原因很简单大模型目前不适合做医疗器械级判断而我也没有处方权。这根红线在我后来和模型交互时反复帮我避免很多麻烦。第一阶段我锁定了四个核心功能多源健康数据接入、基于大模型的个性化问答、异常趋势预警、定时主动关怀。暂时不做的事情包括复杂的医疗知识图谱、与医院系统打通、药物副作用检查。明确边界很重要不然做到一半很容易被什么都想做拖垮。2. 整体架构设计传感器、AI大脑和交互层的三角关系2.1 数据从哪里来可穿戴设备和手动录入的取舍健康伴侣最底层的燃料就是数据。我在架构里把数据源分成了三个层级。第一层是自动化采集主要靠手头的智能手表。我用的是支持心率、血氧、睡眠、步数、体温等指标的设备通过开放接口把数据同步出来。这一步没有采用厂商云平台的API而是用了一个开源的家庭自动化中枢——Home Assistant它通过蓝牙或局域网协议直接与设备通信数据不需要经过第三方云直接进本地数据库。当时选它主要是因为生态成熟支持几百种设备而且有现成的插件可以对接心率带、血压计甚至体脂秤。第二层是半自动录入比如饮食和情绪。这类数据靠传感器很难准确捕捉我的方案是在手机里一个简单的表单每天三次弹出来让我选一下早餐包子豆浆心情比较焦虑或者通过语音说一句今天中午吃了牛肉面下午喝了杯可乐。这些非结构化文本会交给后面的AI去提取特征。第三层是环境与上下文数据包括当天的天气、我的日历安排、通勤时间。这些数据用来让AI理解为什么今天心率会高——如果日历显示上午有个大汇报那心率高就太正常了。2.2 AI大脑怎么运转本地小模型和云端大模型的分工这是整个项目里我最纠结的部分也是最值得展开讲的。AI大脑不能只用一个模型搞定所有事成本、速度、隐私三项指标互相牵制。我最终采用了本地小模型 云端大模型的双轨结构。本地部署了一个7B到8B参数量的开源语言模型跑在带GPU的旧台式机上负责几类工作数据文本的摘要整理、敏感信息的脱敏、基于固定规则的快速判断。比如睡眠数据进来后本地模型会先归纳出入睡时间、深睡比例、夜间醒来次数几个关键字段然后判断是否存在明显异常。这个过程完全离线不出家门。本地模型的好处是私密、无网络依赖、响应快坏处是推理能力上限不高复杂推理和长文本生成会明显吃力。云端大模型负责真正需要智慧的部分结合上下文背景给出个性化建议、回答开放式的健康问题、生成关怀文案。我接的是通用大模型API用的时候只把脱敏后的摘要数据发上去而不是原始心率流。这样既享受了云端模型的智力又最大程度保护了隐私。中间加了一层路由规则什么任务走本地什么任务走云端以及如果云端超时怎么办都写成了可配置的规则。不夸张地说这一层路由决定了整个系统的体验——路由设计得好用户几乎感觉不到模型切换的存在。2.3 交互层语音、推送、可视化一个都不能少交互层是伴侣感的来源。无论后端多强大如果用户每天只能对着网页点来点去那和普通App没有区别。我的交互终端是手机但入口不只一个。最常用的是语音助手我用家里现成的智能音箱通过自定义技能接入到我的后端服务。每天早上我会问它我昨晚睡得怎么样晚上它会主动播报今天活动量偏少建议出门散步20分钟。文字聊天是第二入口集成在Telegram里——这样做的好处是天然跨平台我在电脑前写代码时可以直接在电脑上问出门在外用手机也能随时对话。第三个交互面是可视化面板用网页展示趋势图表适合我空闲时候自己翻一翻看看睡眠趋势和心率变异性的相关性。交互层和AI层之间还夹着一层表达风格控制器。同样的健康建议直接输出会非常生硬你的深睡比例低于正常值建议改善睡眠卫生。我让负责表达的AI模型对这类内容做了改写让它更像一个朋友在说话看你昨晚深睡不太够是不是又熬夜赶需求了今晚试试提前半小时放下手机这套风格调整之后在家人试用时起到了很大作用。3. 一步步实现我的AI健康伴侣从数据管道到Agent编排3.1 第一步统一数据接入格式动手写第一个功能时我差点被数据格式搞疯。手表吐出来的数据可能是分钟级的JSON体脂秤返回的是历史汇总语音输入是自然语言文本日历则是iCal格式。如果直接塞给大模型它会被各种字段名绕晕更不可能给出靠谱的结论。我建了一个统一的健康事件数据模型把所有来源的数据都转成一种标准结构。这个结构包含几个关键字段时间戳、数据类型睡眠/心率/活动/饮食/情绪/环境、单位、来源设备、原始值、备注标签。举例来说手表原始数据可能是一串23:10:00, sleeping_light这样的消息我写了一段Python解析脚本把它转换成2025-03-15 23:10:00, 睡眠阶段, 类型浅睡, 来源手表备注入睡后42分钟。这一步看似啰嗦却给后面所有流程打下了基础。大模型不需要理解每种设备的私有格式只需要知道什么时候、发生了什么、量级如何。我在这个环节还做了简单的数据质量校验比如心率值不可能低于30或高于220睡眠记录和活动记录在时间上不应该交叉。脏数据宁可丢也不能污染AI的判断。3.2 第二步让大模型学会看健康数据提示词工程实战很多教程会让你直接写一句帮我分析这个健康数据然后把数据一股脑丢给大模型。我试过效果非常差。大模型不知道你的性别、年龄、生活习惯也不知道哪些数据重要只会输出一堆教科书般的废话。我花了大量时间在提示词工程上这里分享一个核心思路给模型一个角色 上下文 数据摘要 输出约束的四段式提示模板。角色设定为一位有10年经验的全科医生助理负责生活方式建议不做疾病诊断。上下文里注入了我这段时间的作息习惯、当前正在进行的运动计划、昨天的情绪记录。数据摘要不是原始数据而是经过本地模型归纳后的关键指标和趋势。输出约束则要求每条建议必须包含依据、可执行动作、以及如果……就……的条件分支。举个例子同样是收到昨晚睡眠时长6小时2分钟深睡43分钟心率平均58的数据糟糕的提示词会返回你的睡眠充足建议继续保持。而我的四段式模板会返回你昨晚总睡眠6小时出头但深睡只有43分钟比近7天平均水平低了12%。结合你白天记录的高压力状态睡前喝咖啡可能是主要原因。今晚试试睡前两小时不摄入含咖啡因饮品如果明天深睡比例能回升到15%以上说明判断方向没错。这就是可执行、有依据、讲人话的输出也正是我想要的伴侣感。3.3 第三步用多个AI Agent协作而不是一个Agent干所有事项目做到中期我踩进了一个大坑试图让一个大模型承担所有任务——既做数据清洗、又做知识问答、还要生成关怀文案。结果是功能虽然能跑通但每次对话都很慢而且不同任务之间互相干扰。后来我参考了业界常见的Agent模式把系统拆分成多个各司其职的AI Agent。当前系统里一共跑了四个Agent。数据管家Agent负责把新进来的数据转换成标准事件更新用户画像。健康分析师Agent专门处理长期趋势分析和异常检测它不直接回答用户问题而是把分析结论写进一个结论缓存表。对话问答Agent是用户直接面对的对象它负责读取缓存结论、检索用户画像生成中英文回复。关怀提醒Agent则是定时任务每天根据天气、日程和近期数据生成一条主动提醒比如今天空气湿度较大你以前的关节容易不舒服记得多活动一下手指和膝盖。四个Agent之间通过一个简易的消息队列异步通信。数据管家处理完新数据会给分析师发一条消息有新数据可以分析了分析师得出新结论再推送给对话Agent更新缓存。这样每个Agent都可以使用不同的模型分析师用更强的云端模型数据管家用快速本地模型关怀提醒Agent甚至可以用更小的嵌入式模型。多Agent协作的好处不仅仅是降低了单模型的负载更重要的是每个Agent的提示词和上下文可以高度专业化输出质量提高了一大截。我在这块也参考了AI Agent怎么扛并发的问题——日志推送、连续对话、多个设备同时调用时如果每个请求都同步等大模型返回整个系统会卡死。解决方案是给所有AI调用加了一个异步队列请求先进队后端处理完再推送给用户。这谈不上多高深但对一个单人项目来说足够稳定了。3.4 第四步异常预警与主动关怀的规则设计健康伴侣不能只等用户来问它需要自己发现问题。但AI模型偶尔会判断过头所以我采用了规则锁死边界 模型动态分级的组合策略。我定义了一套基础规则比如静息心率连续30分钟超过100次/分钟夜间血氧均值低于90%连续三天睡眠时长少于5小时这些情况会触发红色预警走最高优先级推送并且推送文案会建议用户尽快咨询专业医生。模型动态分级负责发现规则覆盖不到的隐性模式比如虽然单日睡眠正常但近两周入睡时间越来越晚且深睡比例同步下降这种渐进式恶化趋势让分析师Agent捕捉到发出黄色提醒。主动关怀不是群发而是基于时机的触发。我的关怀提醒Agent会在每天早上7点、中午12点半、晚上9点三个时间窗检查一次系统状态只有当有值得说的事情时才推送。比如中午发现上午活动量偏低就提醒一句今天上午步数只有1千步是不是在写代码起来喝口水在屋里慢慢走两圈吧。如果一切正常就绝不打扰。这个克制感很重要——一个天天刷存在感AI反而会让人迅速厌倦。4. 踩过的坑数据隐私、模型幻觉和正确的废话4.1 本地模型vs云端API隐私与智能的拉锯战最开始我天真地想全部用本地模型搞定买了一堆硬件折腾了一周被现实狠狠教训了一通。8B模型虽然能跑但智力水平确实有限面对需要多步推理的复合问题经常给出看似合理但完全是胡编的答案。而且本地推理速度慢一个问题要憋十几秒才出结果根本没有伴侣的感觉。后来换成本地做初步处理、云端做深度分析的方案后体验明显改善。但我还是很在意数据上云的问题。我的做法是在本地写了一个脱敏层所有发给云端模型的文本都经过实体识别替换。比如具体姓名、设备ID、家庭地址全部替换成用户A心率的具体时间点只保留相对时间睡前2小时。这样云端模型只能看到统计摘要看不到真实的身份和绝对时间点。我个人认为这是我这个项目里做过最值得的一个决策——既保留了智能又守住了隐私底线。4.2 模型幻觉问题AI一本正经地建议我看中医我把它治了大模型幻觉是所有人都绕不开的问题健康场景里尤其危险。有一次我手里握着一份真实体检报告数据让对话Agent帮我解读一下尿酸偏高的影响它居然一本正经地建议我尝试某种中药材泡水喝每天三次。我拿来一看这个建议完全是它自己编的我根本没有提供过任何中医相关的背景知识。这件事给我提了个醒。我做了三层防护。第一层是在系统提示词里强行约束所有具体的医疗处置建议、药物名称、中药处方、剂量信息一律禁止生成一旦涉及直接转换为建议咨询专业医生并且不展开描述。第二层是加了一个来源标注模块任何AI生成结论如果涉及具体数据指标必须说明是来自我的输入数据还是来自模型评论如果是后者要标注参考资料。第三层是对外展示时自动加一条免责声明本系统为生活方式管理工具不提供医疗服务。这一套落地之后幻觉类问题虽然不能彻底杜绝但危害已经被控制在可以接受的范围。4.3 延迟优化从问一句等十秒到几乎无感项目第一次能用语音问答时我兴奋了十分钟然后就被折磨了。因为整个链路是语音识别-文本路由-调用云端模型-生成回复-语音合成单次问答平均耗时12到15秒。这个等待时间放在手机语音交互里简直是灾难。我做了三个优化。第一把常用问题的回复做成了缓存池——比如昨晚睡得怎么样今天走了多少步我的体重趋势如何这些固定查询直接查缓存表90%的请求不需要进大模型响应时间降到1秒以内。第二对大模型调用启用流式输出生成一个字就推送一个字用户感受到的首字延迟从8秒降到2秒左右。第三把语音识别和语音合成全部改为设备端离线执行不再走云端识别服务。综合下来目前整个系统的平均响应时间大概在3秒左右基本满足日常对话。4.4 误报处理AI说我可能心梗我该怎么淡定有一次深夜系统忽然推送了一条红色预警检测到你的静息心率持续偏高且伴有一定波动风险等级较高建议……我当时刚从健身房回来没二十分钟还处在心跳没完全恢复的状态而系统取数据的窗口恰好覆盖了整个恢复期。那次确实是误报但已经把我吓出一身冷汗。事情发生后我对预警规则做了优化。加入了运动恢复期过滤逻辑如果检测到用户刚刚有过高强度运动步数暴增、心率飙升那么运动结束后的45分钟内不触发异常预警。同时急剧变化的数据不再只看绝对值还参考变化趋势和上下文背景。过程中我也学会了一件事系统里的AI不能只有严格报告一种风格还得学会区分需要担心和可能只是噪声。这套宁缺毋滥的校准逻辑让后来一个月内的误报率降低了将近七成。5. 实测两周的数据结果和我的真实体验5.1 睡眠和心率追踪的准确率复盘为了验证系统的准确性我特意做了两周对照实验一边是我的人工统计每天睡前在纸上记录入睡和起床时间一边是手表原始数据加本地模型归纳后的结果。对比下来睡眠时长误差中位数在9分钟左右深睡比例误差在5%以内满足我的日常参考需求。心率方面静息心率和日间平均心率与专业设备对比误差很小但运动中的瞬时心率有时会偏高主要受手表佩戴松紧影响。让我最惊喜的是分析师Agent发现的一个模式它注意到我周三晚上打的篮球赛会显著影响当晚的深睡质量深睡比例比平时低11%。这个关联在原始数据里其实并不明显因为单独看周二的睡眠和周四的睡眠都没问题只有把周三运动事件和周三晚睡眠结构变化放在一起才能看到。大模型在这里体现出了真正的价值——它能把看似不相关的时间线数据拼在一起做推理。不过我也清楚样本量只有两周这个结论还谈不上统计显著只能作为一个待验证的线索去看。5.2 AI健康建议的质量评估哪些能用哪些放弃两周内我大约和AI健康伴侣进行了80多次正式对话其中40%是查询类今天状态怎么样35%是疑问类为什么这周老觉得累25%是建议类给我一个今晚放松方案。我逐条给建议打了分标准是可执行性、依据充分性、个性化程度、是否安全。结果分布很能说明问题大约60%的建议我认为可以直接采纳或稍加调整后采纳30%的建议是正确的废话——不吃错但也没啥用10%的建议有明显偏差。最典型的失败案例是AI建议我在某天下午去室外跑步理由是当天温度适宜空气质量良好但它没看到那天下午我日历里排了一个需求评审会。这类问题的根源在于上下文覆盖仍不够全。我后来给系统增加了日历事件摘要的注入才慢慢把偏差比例降下来。5.3 我身边的家人试了一个月反馈如何我把系统开放给家里的长辈试用了一个月得到的反馈比我预想的更有意思。母亲最先喜欢上的是每日关怀提醒天冷了出门记得带外套今天你步数够了不用再刻意绕路这些她以前没有从任何App那里听到过。但她表示自己不太信任AI给的饮食建议还是更愿意听营养科医生的。父亲则对AI主动发现并提醒这件事非常惊讶。有一次他早上起来血压偏高系统给了他一条温和提示建议他先静坐10分钟再复测结果复测确实回到正常范围。他说如果是一个手机App弹出同样的话他大概率不会理但因为是每天早上叫我起床的那个声音说出来的他更愿意照做。这让我意识到伴侣感的核心不是技术多强而是信任感和交互习惯的养成。它不能像工具一样等指令而要像家人一样有节奏地参与生活。6. 接下来我打算怎么升级这个伴侣6.1 从单聊到多Agent协同诊断让虚惊一场变成综合会诊目前的系统虽然已经有四个Agent但它们之间的协作还是偏线性。下一阶段我想把架构改成更接近医学会诊的模式当一个异常事件被触发时多个Agent各自从不同角度分析——一个只看数据特征一个检索近期事件记录一个模拟用户生活习惯与异常模式的关联。每个Agent输出独立结论最后由一个汇总裁决Agent综合各方意见再生成最终建议。这样即使单个Agent判断有偏差也能靠交叉验证拉回来。这个改动技术上不难难的是Agent之间的沟通协议设计。我现在已经在本地测试了一个简化版异常事件发生时分析师Agent会先给出一个怀疑方向然后数据管家Agent去回溯三天前的原始数据最后关怀Agent再决定用什么样的语气告诉用户。整个流程跑下来误报比之前又少了一些而且每个结论都有了可追溯的推理链。6.2 融入更多生活场景饮食、压力、复诊提醒健康不只是睡眠和心率。我正在尝试把饮食摄入识别做得更细不再只靠手动选表单而是让AI直接分析我拍的食物照片估算营养构成。这块最大的挑战是模型对食物分量和烹饪手法的识别能力有限同一个菜在不同光线和角度下误差很大。我的折中方案是让AI只给出量级判断这一餐蛋白质偏多、蔬菜不足不给精确卡路里避免制造虚假精确感。压力管理也是下一步重点。现在已经接了日历、天气和语音输入的情绪标签下一步想再加入工作时间段内的键盘活跃度数据作为压力参考指标。坦白说这类数据的相关性需要非常小心过度解读反而会适得其反。我更倾向于把它作为对话时的背景种子而不是决策依据。6.3 给想动手做AI健康应用的你几点建议如果看完这篇文章你也想动手做一个自己的AI健康伴侣我最想说的不是具体技术选型而是三个原则。第一先定义不做什么再定义做什么。健康领域边界非常敏感写出不提供医疗诊断这条红线能避免你后期陷入合规和误导的泥潭。第二数据质量永远比模型能力更影响体验。一个8B小模型配上干净、标准化的数据往往比一个千亿大模型吃杂乱的数据表现得更好。第三交互设计要克制。能少打扰就少打扰推送发多了用户只会越来越烦和伴侣反而越来越远。最后再分享一个我个人的小技巧在搭建这类系统时我会定期把AI给出的健康建议和我的实际后续作息变化放在一个表里对照。这不是为了测试模型而是为了校准自己对健康数据的直觉。很多时候AI提出一个我没想到的关联我会带着这个假设去查资料、观察自己这是一种非常奇妙的人机协作体验。你的AI健康伴侣不会一次成型它会在你和它的共同反馈中慢慢成长就像真正的伴侣一样需要时间和耐心去磨合。
返回列表