核心用法
Perpetua 是一个托管式 OAuth 代理服务，通过单一 API 密钥为 Claude 等 AI 助手提供标准化的第三方 API 访问能力。核心架构遵循"密钥即服务"模式：用户将 Oura Ring、Google Calendar 等平台的 OAuth 授权托管至 Perpetua.sh，后续所有调用均通过 https://www.perpetua.sh/api/proxy/:provider/:path 统一网关完成，无需处理令牌刷新、权限范围等底层细节。
典型调用流程：
1. 通过 PERPETUA_API_KEY 鉴权（支持 1Password、CI 密钥管理器注入）
2. 查询 /api/status 验证连接状态
3. 按需请求 Oura 睡眠/准备度/心率变异性数据，或 Google Calendar 日程事件
4. 使用 ?account=default 参数支持多账户场景
显著优点：
- 认证简化：将多平台 OAuth 2.0 流程压缩为单一 Bearer Token 调用，消除令牌过期、范围变更等运维负担
- 安全性隔离：实际平台密钥存储于 Perpetua 服务端，AI 上下文仅暴露代理层密钥，降低泄露面
- 协议标准化：无论底层是 Oura 的 REST API 还是 Google 的 Calendar API，上层调用范式完全一致
- 快速集成：对 Claude 等 AI 助手透明，可直接嵌入自然语言指令（如"我昨晚睡得怎么样"自动路由至 Oura）
潜在局限：
- 供应商锁定：完全依赖 Perpetua.sh 服务的可用性与持续性，本地 OSS 版本（
localhost:3001）明确标注"仅开发用途" - 功能裁剪：代理层可能过滤部分原生 API 能力（如文档警示避免调用
daily_activity等大数据端点） - 延迟与故障域：增加网络跳数，且
5xx错误需人工介入（"notify Daniel"） - 地理/合规限制：健康数据（Oura 睡眠/HRV）通过第三方代理传输，可能涉及 GDPR、HIPAA 等合规考量
适合人群：
- 希望快速为 AI 助手添加健康/日程数据能力的开发者
- 不愿维护多平台 OAuth 基础设施的个人用户
- 使用 Claude 等具备工具调用能力模型的场景
常规风险：
- 密钥泄露：
PERPETUA_API_KEY一旦泄露，攻击者可访问所有托管账户的 Oura/Google 数据（虽无写权限，但隐私风险显著） - 中间人风险：代理服务理论上可见明文请求与响应，需信任运营方
- 服务中断：文档明确提示
5xx时无自动降级路径 - 数据过度请求：AI 助手可能自动拉取大范围历史数据，需关注隐私设置