ARTICLE · 1242411
卸载了所有减肥 App 后,我用 Hermes Agent 在微信里搭了个全自动健康中枢
按理说这时候该去办张健身卡，但搞IT的死穴大家都懂——遇到问题的第一反应永远是：这玩意儿能不能搞套自动化系统解决？
市面上的健康软件我基本趟过一遍坑：薄荷健康、手环自带 App、体脂秤客户端……最后全都在吃灰。原因很简单，太繁琐了。 每次吃饭前要先打开 App、搜菜名、估摸着填个克数；称个体重还得先开手机蓝牙，盯着屏幕等它转圈同步。只要哪天项目上线忙起来，断更两天，后面就再也不想打开了。减肥还没开始，人先被记录流程折腾废了。
这几天我干脆换了个思路：把开源的 Hermes Agent 扔到云服务器上，接入微信，再把家里的硬件网关和本地脚本串起来，搓了一套几乎不需要动手操作的健康管理系统。今天跟大家聊聊这套东西是怎么跑起来的。
一、 为什么是 Hermes Agent + 微信？
平时我们在网页里用的大模型，本质上就是个“陪聊”。你问它怎么减肥，它给你列一二三四五，但干活的还是你自己。
我选 Hermes Agent，看中的是它有操作系统的实权。它是个长驻在 Linux 里的自主 Agent，这意味着：
它真能动手干活：自带 Bash 和 Python 环境，有本地文件读写权限。遇到需求不是“建议你怎么做”，而是自己写脚本、调接口、改配置，甚至在后台偷偷拉起一个无头浏览器去抓数据。 微信就是唯一入口：我不需要额外装任何 App。平时就像跟朋友聊天一样，吃饭前随手拍张照发给微信，剩下的识别、算热量、记账，全在后台自己跑完。
整套链路非常轻量：
[日常交互] 微信聊天框 (发文字 / 随手拍菜) │ ▼ (Webhook / 协议桥接)[云端大脑] Hermes Agent 主进程 (Linux 后台长驻) ├── 视觉识别 (调多模态大模型认菜、估重) ├── 本地账本 (直接读写 Markdown 记账 / 维护身体指标) ├── 定时任务 (Linux Cron 每天早晚定时跑汇总) └── 硬件网关 (OpenScale Gateway 蓝牙直连体重秤)
二、 拍张照就能记账：中餐识别没那么简单
自己记饮食，最头疼的就是“这盘菜到底有多少克”。中国菜不像西餐那样按标准份数来，一盘小炒肉里肉有多少、油有多少，全靠猜。
现在的流程被我压到了极致：菜端上来，掏手机拍一张扔微信里，完事开吃。
为了保证准确率，后台视觉这块我直接上了旗舰级的多模态模型（实测小模型认中餐就是灾难，经常指鹿为马）。现在的顶尖多模态模型在看图算热量这件事上，细节抓得非常准：
有天我拍了张晚餐过去：一碗带骨头的禽肉、一盘炒瓜、一碗白米饭、几块南瓜，外加一碗青菜豆腐汤。
模型在后台是这么拆解的：
认菜与做法：从骨头形状和外皮的油脂反光，直接认出是“带骨豆豉蒸鸭”而不是红烧肉；看南瓜表面干爽、没有油光，判断是“清蒸”而非油焖。 参照物估重：拿桌上的标准饭碗直径当参照物，顺手把米饭和菜的重量全推算出来了： 豆豉蒸鸭：150g（去骨纯肉约 100g）≈ 270 kcal / 20g 蛋白质 肉丁炒瓠瓜：猪肉 80g + 瓠瓜 150g ≈ 240 kcal / 14g 蛋白质 青菜豆腐汤：豆腐 80g ≈ 65 kcal / 7g 蛋白质 算完之后，Agent 自己调本地读写工具，把数据追加到我的 Markdown 饮食账本里，顺手在微信上回我一条：
“午饭记好了：豆豉蒸鸭、炒瓠瓜、豆腐汤、南瓜、米饭。这顿大概 973 大卡，蛋白质 49.4g（达标）。不过米饭有 150g 稍微多了点，晚饭主食建议减到一拳头（100g 左右）。今天还剩 560 大卡的额度。”
前后也就三秒钟，不用搜词条，也不用拉滑块选克数。
三、 扔掉原厂 App，把体脂秤直接焊在本地网关上
搞定了吃，接下来是体重。家里原本那台商业体脂秤，原厂 App 打开全是买课广告，关键是数据全锁在厂商自己的云端，我想导出来做个分析都费劲。
我干脆用开源的 OpenScale Gateway 把它接管了：
1. 蓝牙数据直传本地把原来去厂商云端扒数据的脚本停了，直接在本地网关跑了个监听服务。每天早上踩一脚秤，蓝牙广播出来的数据直接被网关截获，推进本地数据库，彻底断掉外网依赖。
2. 过滤白天的“假体重”体重这东西早晚能差出两三公斤（喝水、吃饭、穿衣服）。如果每次上秤都记，折线图根本没法看。我让 Agent 写了个简单的过滤逻辑：每天只认早上起床后的第一条空腹数据。白天哪怕心血来潮踩十次秤，也会被直接当成噪点丢掉。
3. 抹平换设备的读数跳水刚换到本地网关那两天，因为传感器底层标定逻辑不同，称出来的体重跟以前比突然跳了一下。如果直接画图，趋势线肯定就断崖了。Agent 顺手写了个平滑脚本，用最近 7 天和前 7 天的移动平均值（MA）做对冲，把换设备带来的固定偏差抹平，只看真实的掉秤趋势。
现在每天早上 7 点，Linux 的 Cron 定时任务一跑，微信就会准时弹出一份简报：今天多重、最近 7 天掉了多少、昨天热量有没有超标，一目了然。
四、 给大模型加个“备胎链”（Fallback 机制）
自己搭服务自己用，最烦的就是关键时刻掉链子。比如正在饭桌上拍完照发过去，结果 API 报个 502 Bad Gateway 或者节点超时，体验当场归零。
为了防止这种情况，我在 Hermes 里配了一套多模型自动兜底（Fallback）：
主力干活：平时简单的文本对话、读写账本，用响应快、性价比高的主力模型； 故障秒切：只要当前调的接口报错、超时或者触发限流，后台会在几秒钟内自动切到备用模型重新请求。
这套容灾逻辑跑起来之后，在微信那头基本感觉不到后台的波澜。不管接口供应商今天抽什么风，发过去的消息永远能稳稳当当地回过来。
写在最后
其实折腾这么一大圈，最大的感受并不是技术有多牛，而是终于不用再靠“毅力”去对抗人性了。
以前减肥失败，往往是因为还没瘦下来，人先被每天繁琐的打卡、算卡路里给耗没了耐心。现在这套东西跑在后台，不弹广告、不搞打卡焦虑。我每天只管正常吃饭、早起踩一脚秤，剩下的脏活累活全交给后台那个 24 小时不睡觉的脚本小子。
搞技术这么多年，能用自己敲出来的东西把身体指标一点点拉回正轨，大概就是技术宅最爽的时刻了。
