OMNIVESEINSIGHTSAI 健康观察历史版本

GitHub 开源项目精选

员工健康守护与智能体

看清项目能做什么、如何组合,以及距离实际使用还有哪些工作。

首批 8 个项目均已核对仓库、源码版本和许可文件。每张卡片直接说明功能、应用、部署条件和限制,来源链接集中在底部。

仓库状态每 6 小时检查;推送时间和星标只用于了解维护情况,不代表医疗有效性或部署质量。项目介绍基于资料审阅,本次未执行这些项目的部署验收。

一个最小组合 · 本站设计建议

从个人记录,到可核对的健康反馈

  1. Open Wearables自愿授权与数据接入
  2. NeuroKit2有合适信号时做指标计算
  3. LangGraph摘要、依据核对与人工审核
  4. OpenClaw把结果交付给员工本人

这些项目尚未在本站组合部署。先用合成数据验证流程,再验证设备、模型与服务条件;HRV 等指标需要合适的原始输入。

员工健康:应用与基础组件

5 个项目

应用原型与技术组件分别标记,便于判断还需要开发什么。

01
可穿戴数据接入开发平台 · 持续迭代

Open Wearables

把不同设备的健康记录接到统一 API,适合作为员工自愿参与的健康服务的数据入口。重点价值是数据连接与标准化,AI 健康助手的成熟度需单独验证。

已具备的功能
仓库提供自托管服务、开发者界面、设备授权与数据同步能力,技术栈包括 FastAPI、React、PostgreSQL、Redis 和 Celery。README 将部分 AI 助手与健康洞察能力列为开发中,不能把规划功能都算作已交付。
员工健康应用
本站应用建议:先支持一种实际使用的设备,让员工自行连接和撤回授权。向个人展示记录覆盖情况与趋势,把需要专业判断的反馈留给后续服务。企业侧先关注服务参与和完成情况,而不是展示个人健康排名。
技术与部署条件
可研究用 Compose 或 K3s 承载 API、数据库和异步同步任务;设备连接仍依赖各厂商接口、移动 SDK 和授权条件。先用合成数据验收分页、重复同步、时区与撤权,再接真实设备。
成熟度与限制
这是 AI 应用的数据基础,不是开箱即用的员工健康守护系统。不同连接器、数据类型和自托管版本的支持范围必须逐项核对,不能仅凭支持设备列表承诺所有指标都可获取。

最小可运行方案

第一步:做一个设备授权演示和个人数据完整度页面,验证一天的数据能稳定同步、去重和删除,再接健康周报智能体。

开源协议:MIT内容核对:2026-09-08

核对于 2026-09-08 · 仓库推送 2026-09-08 · ★ 2,471 · 未归档

02
员工关怀访谈原型研究原型 · 需重新验证

AgentCare

提供预约、回访和员工状态访谈等语音 AI 工作流。它与员工健康关怀直接相关,但仓库中的倦怠评分与合成数据实验不等于真实员工场景的有效性证明。

已具备的功能
Python 框架将通话接入、结构化抽取、分析规则、流程路由与存储分开。wellness_checkin 处理员工定期访谈,结合语言模型和规则提取状态线索。仓库实验使用合成员工语料,不能作为临床量表或现实预测性能证明。
员工健康应用
本站应用建议:借鉴访谈记录、原话证据和问题跟进流程。把员工主动求助与专业支持人员的处理结果串起来;不要直接沿用模型分数、阈值和向经理升级的默认路径,更不能用于绩效、招聘或解雇判断。
技术与部署条件
Python 服务适合在当前 VPS 做隔离演示。真实语音流程需要 Bolna、模型网关等集成;邮件和外呼也各有渠道配置。先用录制的合成对话或文本夹具测试,不需要立刻启用自动电话。
成熟度与限制
资料核对时最近仓库推送在 2026 年 4 月。应验证依赖、接口和测试能否复现。MBI 相关维度描述不代表程序分数就是正式量表结果;模型推断必须与员工原话分开呈现。

最小可运行方案

第一步:实现一次自愿文本签到,输出“员工原话—待澄清问题—人工处理状态”,先关闭自动评分和向管理者自动发送功能。

开源协议:MIT内容核对:2026-09-08

核对于 2026-09-08 · 仓库推送 2026-04-25 · ★ 1 · 未归档

03
个人健康记忆与问答个人原型 · 集成范围有限

health-agent

使用 Telegram、n8n、Python 和 PostgreSQL,把个人记录与长期记忆连接起来。架构与现有 VPS 上的基础设施接近,适合研究个人健康摘要和记忆纠正。

已具备的功能
仓库介绍了 Apple Health 导入、健康记录工具调用、pgvector 检索和由用户确认的长期记忆。其说明明确把 Oura、Whoop、Garmin 连接器列为计划功能。项目以个人使用为主,核对时最近推送在 2026 年 3 月。
员工健康应用
本站应用建议:优先学习“用户先确认,再写入长期记忆”的机制。员工看到系统对自己的解释,可以纠正或删除;个人助手与企业共享信息应明确分开,不能把个人聊天和健康原始记录直接放入团队看板。
技术与部署条件
需要 Python、PostgreSQL/pgvector、n8n、消息渠道和模型配置。可先把消息入口换成独立测试页面。README 虽强调自托管,但配置包含外部 LLM 和 Telegram,数据是否出站取决于实际选择,不能宣称天然完全本地。
成熟度与限制
多员工身份隔离、授权、删除流程、中文解析和部署文件完整性都需要重新验收。作者的个人使用经验不能作为临床有效性或企业可用性证明,本次未执行该项目。

最小可运行方案

第一步:用合成健康记录做“查询本周记录—生成摘要—纠正一条记忆—再次查询”的闭环,验证撤回的记忆不再被检索。

开源协议:MIT内容核对:2026-09-08

核对于 2026-09-08 · 仓库推送 2026-03-28 · ★ 0 · 未归档

04
端侧姿态识别组件通用 ML 组件 · 非健康成品

MediaPipe

通过图像或视频识别人身体的关键点,可以用来开发工位姿态反馈与活动演示。端侧推理有助于减少视频上传,但职业健康评估仍需另外设计和验证。

已具备的功能
Google 的 Pose Landmarker 输出图像坐标和三维姿态关键点,支持图片、视频和实时输入,提供 Web、Python、Android 等实现指南。姿态模型估计 33 个身体关键点,属于机器学习视觉组件。
员工健康应用
本站应用建议:做员工主动打开的短时姿态自查,在本机处理画面,只向本人解释检测到的姿态变化。需要企业服务统计时,优先汇总使用次数与反馈,不持续保存摄像画面,也不从面部或动作推断员工情绪。
技术与部署条件
姿态推理可优先放在浏览器或设备侧;VPS 负责静态资源和经用户选择提交的结果。先使用已知姿态视频测试遮挡、视角、距离、光线和检测失败,不必为原型给服务器增加 GPU。
成熟度与限制
关键点坐标不是职业病诊断,也不自动等于 RULA 或 REBA 评分。若要计算这些评估,需要额外信息、规则和专业验证;摄像角度不同会影响几何量的解释。模型资产与第三方依赖也应按各自条款核对。

最小可运行方案

第一步:建立 30 秒的个人姿态演示,显示关键点是否被可靠检测和哪些数据不可用,先不输出未经验证的健康风险等级。

开源协议:Apache-2.0内容核对:2026-09-08

核对于 2026-09-08 · 仓库推送 2026-09-05 · ★ 36,875 · 未归档

05
生理信号计算组件研究工具库 · 非智能体

NeuroKit2

提供心电、光电容积脉搏、皮电等生理信号处理与 HRV 分析。适合放在健康 AI 前面,先产生可复现的指标,再由智能体解释结果与数据限制。

已具备的功能
NeuroKit2 是 Python 生理信号工具库,包含信号清理、峰值检测和多类 HRV 指标计算,仓库提供示例数据与分析示例。它本身不提供员工关怀对话,也不是一个已验证的工作压力预测模型。
员工健康应用
本站应用建议:建立“原始信号—质量检查—计算结果—文字解释”的处理链,每个结果保留采样率、算法版本和有效数据区间。员工能看到结果来自哪段记录,无法可靠计算时明确说明。
技术与部署条件
适合在 VPS 上以 Python 批处理方式运行。第一阶段使用项目示例或合成波形,核对重复执行结果一致;只有日均心率等汇总数据时,不能假定可以重建原始波形或所有 HRV 指标。
成熟度与限制
不要将单一 HRV 数字直接转换为倦怠、抑郁或工作能力标签。数据类型、噪声处理、采样条件与实际人群会影响解释,需要为具体应用另做评估。

最小可运行方案

第一步:用固定样本建立可重复的处理任务,展示输入质量、峰值检测和指标来源,再让智能体解释计算过程而非作疾病判断。

开源协议:MIT内容核对:2026-09-08

核对于 2026-09-08 · 仓库推送 2026-09-06 · ★ 2,345 · 未归档

智能体:状态、工具与协作

3 个项目

这些是通用框架与助手,健康能力需要另外实现和验证。

01
有状态智能体编排通用框架 · 需开发业务

LangGraph

适合需要暂停、人工审核和失败恢复的员工健康助手流程。把资料整理、核对、生成草稿和确认发送变成可追踪的步骤。

已具备的功能
LangGraph 提供有状态的智能体编排、持久执行和人工参与能力。它负责流程状态与步骤衔接,模型、数据源、权限和健康业务规则仍由应用开发者配置。
员工健康应用
本站应用建议:设计“读取授权记录—确定性计算—生成摘要—核对依据—专业人员审核—交付本人”的图。每一步保存输入、输出与版本,用户修改资料后可以从合适节点重新运行。
技术与部署条件
Python 编排服务可运行在当前 VPS,持久状态可使用适配的数据库检查点实现;模型选择与计算位置独立配置。先测试进程重启和重复触发,确认不会重复发出同一份反馈。
成熟度与限制
框架支持人工介入,不会自动让生成内容成为专业审核结果。还需要身份隔离、工具权限、业务幂等和失败处理;核心开源库与托管产品是不同交付形态。

最小可运行方案

第一步:做一个必须由审核者点确认才能完成的周报流程,在中途重启服务,验证草稿、审核状态与发送记录都能恢复。

开源协议:MIT内容核对:2026-09-08

核对于 2026-09-08 · 仓库推送 2026-09-06 · ★ 41,241 · 未归档

02
多角色研究与内容流程通用框架 · 需设质量门槛

CrewAI

用多个角色分别检索、核对和撰写内容,并通过事件流程控制执行。适合先做员工健康知识资料整理,给每项结论绑定来源。

已具备的功能
CrewAI 的 Crews 面向角色协作,Flows 面向事件驱动的状态和分支控制。仓库提供 Python 框架、任务与工具配置示例,可组合成资料搜集与报告编写流程。
员工健康应用
本站应用建议:把角色划分为来源检索、证据核对、中文解释三个步骤。核对者必须回到原始材料,标记研究人群、日期和限制;内容缺乏来源时返回待补充,不自动生成看似完整的健康建议。
技术与部署条件
可部署为有并发上限的 Python 任务服务,由已有 n8n 触发。模型调用费用、上下文长度和网页抓取配额要逐任务记录,先从每天一份资料摘要演示开始。
成熟度与限制
多个智能体一致同意不构成独立证据,也不会自动消除幻觉。健康内容发布仍需明确来源审核和人工责任,不能让角色名字制造出实际不存在的医生背书。

最小可运行方案

第一步:输入三篇公开原始研究,生成一个带逐条引用的中文摘要;故意加入互相矛盾或缺失的材料,检查系统是否如实标记。

开源协议:MIT内容核对:2026-09-08

核对于 2026-09-08 · 仓库推送 2026-09-08 · ★ 58,228 · 未归档

03
自托管助手与渠道入口通用助手 · 健康能力需另建

OpenClaw

提供智能体网关、工具和消息渠道接入,可作为健康记录查询、个人周报与服务提醒的交互入口。健康分析能力需要由独立工具和经验证的业务流程提供。

已具备的功能
OpenClaw 支持在自有设备或服务器运行助手,连接多种消息渠道,并替换模型与工具实现。当前 LICENSE 为 MIT;本次 GitHub API 未识别 SPDX,协议判断依据固定提交里的原始许可文件。
员工健康应用
本站应用建议:复用现有助手入口,让员工主动查询自己的记录或请求一份周报。给工具设置明确的数据范围,健康摘要先回到本人;需要专业服务时,再由明确的人工流程接手。
技术与部署条件
现有 VPS 已有 OpenClaw 服务,可以先增加一个只读的合成数据演示工具。部署前需核对现有安装版本与上游文档的差异,不直接把最新主分支配置覆盖到现有服务。
成熟度与限制
自托管网关并不意味着模型和消息渠道都在本地。外部提供方、插件权限和个人数据范围取决于具体配置。本次只收录项目介绍,没有扩大现有 OpenClaw 的权限或接入员工数据。

最小可运行方案

第一步:让助手调用一个只返回合成周报的只读接口,验证不同测试身份看不到彼此数据,且每条摘要都能回到原始计算。

开源协议:MIT(已核对 LICENSE)内容核对:2026-09-08

核对于 2026-09-08 · 仓库推送 2026-09-08 · ★ 389,188 · 未归档