2026年7月1日，Google Health 社区发布了一条消息：一款名为 ghealth 的开源命令行工具正式可用。它不是一个给普通用户设计的 App。它是一个 Go 语言编译的单文件二进制程序，能在终端里查询你的心率、睡眠、血氧、步数——涵盖40种健康指标——并以结构化 JSON 输出。
ghealth 的 README 里有一句明确的话：“built for AI agents and developers。”为此，每个命令返回固定结构的 JSON，exit code 可预测，甚至附带两份 SKILL.md 文件——一种 AI Agent 可以直接安装的技能描述格式。
用一句话概括：谷歌的健康数据平台，现在有了一个直接面向 AI Agent 的入口。
一场迁移催生了一个工具
要理解 ghealth 的定位，得先看清它背后的迁移背景。
Google 已正式宣布，自 2026 年 9 月起，旧版 Fitbit Web API 将全面下线，所有开发者必须在此之前迁移到 Google Health API v4。这不仅是换了个名字。认证体系从 Fitbit 自有授权切换为 Google OAuth 2.0，数据模型全面重构，每个用户都必须重新授权。谷歌将这个新 API 描述为“在 Google Cloud 基础设施上完全重建的 Fitbit Web API 进化版本”。
就在这场迁移的尾巴上，Google-Health-API 这个 GitHub 组织下出现了 ghealth。该组织由 Google 长期用于托管 Fitbit 相关开源仓库。ghealth 本身被标注为社区项目（非 Google 官方产品），但获得了 Google Health 的官方推广——9to5Google、Google Health Community 论坛均发布了关于它的消息。Apache 2.0 许可证，任何人可以克隆、编译、修改。
Agent 优先：从输出到认证都在为 AI 改造
ghealth 最不寻常的地方在于，它的设计优先级排序里，“AI Agent 用起来顺手”可能排在了“人类开发者用起来顺手”前面。
输出即上下文
默认输出是简化 JSON，字段名在全部40种数据类型上保持稳定。--raw 返回原始的 API 响应，--format csv 和 --format table 支持其他格式。-o 标记可以写入文件并预览 schema。
假如你是一个 AI Agent，你只需要执行：
ghealth data heart-rate list --from today --limit 10
得到 JSON，直接喂入你的上下文窗口。不需要解析 HTML，不需要适配不同 API 版本间的响应差异。
SKILL.md：Agent 的说明书
仓库里附带两份 SKILL.md 文件。一份覆盖认证、设置和全局标志。另一份覆盖全部40种数据类型、每种支持的操作、使用模式与常见陷阱。
SKILL.md 是一种文件格式——AI Agent 可以通过 npx skills add 将这份文档作为技能加载。这意味着你的 AI 助手可以自动学会如何使用 ghealth，而不需要你在 prompt 里写一系列指令。
认证也考虑了无头环境
ghealth 实现了 PKCE S256 流程，支持交互式浏览器登录也支持 --non-interactive-auth 模式。在无头服务器上，你可以在另一台设备上点击认证链接，把返回的 code 传回来后完成登录。GHEALTH_ACCESS_TOKEN 环境变量可以直接注入，彻底跳过设置流程。
所有凭据写入 ~/.config/ghealth/，权限设置为 0600（仅文件所有者可读写），刷新令牌自动续期。
40种数据类型：从步数到心电图的完整覆盖
Google Health API v4 列出了40种经过实时 API 验证的数据类型。常见指标如 steps（步数）、heart-rate（心率）、sleep（睡眠）、weight（体重）、oxygen-saturation（血氧饱和度）自然都在其中。更有临床价值的类型如 electrocardiogram（心电图）则需要额外的 ecg.readonly 作用域权限。
每种类型支持不同的操作集合。通用操作包括 list、rollup、daily-rollup、reconcile。可写类型——exercise、sleep、weight、body-fat、height——额外支持 create、update、delete。
其中 reconcile 操作值得注意：它合并来自多个数据源的重叠数据点。如果你同时戴着 Fitbit Air 和 Pixel Watch——Google Health App 目前已经支持同时配对两台设备——reconcile 可以帮你消除重复记录。
睡眠是验证模式识别能力的一个好例子。默认 list 返回摘要。加上 --detail 返回分阶段数据——清醒、深睡、REM。对于一个写了自动化睡眠分析的开发者来说，这比在 App 里翻图表高效得多。
这不是一个工具，是一个平台的终点信号
把 ghealth 放在过去几个月的谷歌动向里看，故事变得更清晰。
2026年5月，谷歌推出了 Fitbit Air，一款 99.99 美元的屏幕无屏可穿戴设备。主打“24/7 舒适佩戴”：没有屏幕分散注意力，一周续航，绑定 Google Health App 和 AI 驱动的 Google Health Coach（需订阅 Google Health Premium，月费 9.99 美元或年费 99.99 美元）。
谷歌的叙事越来越完整：Fitbit Air（硬件入口）→ Google Health App（数据聚合层）→ Google Health Coach（AI 分析和建议层）→ Google Health API（开发者接口）→ ghealth（Agent 接口）。
这是一套从物理世界延伸到机器终端的完整链路。ghealth 是其中最底层的那个触点——它连人类用户都不要求了，直接面向 AI Agent。
改变了谁的竞争格局
ghealth 的出现，对几个阵营产生了直接或间接的压力。
Apple HealthKit 仍然是 iPhone 原生健康应用的自然锚点。但 Apple 没有为 HealthKit 提供类似的 CLI，也没有面向 Agent 的输出设计。如果你是一个想在终端里写健康数据脚本的用户，Apple 生态的开发者可以做什么？Apple 至今没有给出答案。
Garmin Health API 在运动和耐力数据领域有深厚的积累，但同样没有 agent-native 的输出设计。它的核心受众仍然是人类开发者。
Terra、Thryve 等统一数据 API 厂商 面临更直接的挑战。它们的核心价值主张是“一次接入，多设备数据”。如果谷歌的数据开放程度足够，开发者可以直接通过 ghealth 接入 Fitbit 和 Pixel Watch 的数据，不再需要中间层。当然，Terra 们覆盖的不仅是谷歌生态——WHOOP、Garmin、Samsung Health 都在其列——但谷歌正在试图让自己的数据口径变得足够方便，以至于多设备调用的需求不再需要第三方中间件。
不过谷歌也有短板。截至稿件发布时间，ghealth 仓库仅有 4 次提交，没有正式的版本 Release。谷歌没有披露 CLI 的开发者下载量，也没有公开商用 API 的审批通过率。一个只有几天历史的仓库不是生态系统。而谷歌在 API 维护上的历史记录——从 Google Reader 到 Google Fit API 的关闭——让开发者有理由保持必要的审慎。
健康数据不再需要你来看了
ghealth 最有意思的点不在技术设计，而在于它代表了一个前提假设的转变：你的健康数据，可能不再需要你亲自查看。
AI Agent 可以在终端里查询你的静息心率趋势。如果你的恢复分数持续偏低，它可以自动调整你的日程——把今天的高强度训练换成恢复跑，或者在日历里插入一个正念时段。
Google 的官方博文给出了类似的示例场景。但更深层的问题是：当健康数据变成 AI Agent 可以自动读取的 JSON 流时，授权模型会发生什么变化？
ghealth 的回答是 PKCE + OAuth 2.0 + 本地 0600 加密存储。从架构上看，每个 AI Agent 调用健康数据 API 时，发起请求的身份令牌仍然是用户自己的。权限模型没有任何中间层。这意味着：你的 Agent 拥有和你完全一样的数据访问权限。
这是当前所有 Agent-first 架构的共性问题。但如果用健康数据做类比，它的容错率远低于天气查询或日历管理。数据一旦泄露，影响的不是你的日程安排——而是你的身体信号。
2015 年的 Fitbit API 让开发者能做健身 App。2026 年的 ghealth 让 AI Agent 能读你的心跳。
这不是一个命令行工具的发布。这是谷歌给“AI 读取人体信号”铺的第一根管道。它的开关在你自己的终端里，但管道的那一头，已经开始延伸到一个你无法完全控制的地方。
对于每一个把健康数据同步到 Google Health 的用户来说，这个 CLI 回答了一个之前没人认真问过的问题：当 AI Agent 想要了解你的身体状况时，你打算怎么让它读到这些数据？
谷歌的答案是：给它一个终端命令就够了。
快报