将输入时设备 GPS 作为 Fact 元数据落盘

[utopiafar]

背景

Memex 现在已经有位置相关能力：输入链路会获取一次当前位置并作为 location_context_reminder 传给部分 Agent；图片分析链路也会从 EXIF 中提取 GPS；卡片详情页支持用户手动选择位置并写入 user_fixed_location。

但这些能力目前没有形成一个稳定的、每次输入都可查询的原始坐标数据层。后续如果要做地点分布、热力图、轨迹、时间地点关联、地图类洞察等分析，需要一个可信、结构化、可回溯的坐标来源。

Proposal

在用户每次提交输入时，尝试读取设备 GPS，并将其作为该条 Fact 的原始 metadata 落盘。

建议写入 Fact entry header 的 JSON metadata 中，例如：

## <id:ts_3> 14:22:10 {"input_location":{"lat":31.212345,"lng":121.456789,"accuracy_meters":12.3,"source":"device_gps","coordinate_system":"WGS84","captured_at":"2026-06-16T14:22:10+08:00"}}

今天把方案整理完了

字段建议：

• lat: 设备 GPS 纬度
• lng: 设备 GPS 经度
• accuracy_meters: 设备返回的精度
• source: 固定为 device_gps
• coordinate_system: 固定为 WGS84
• captured_at: 坐标采集时间

行为建议：

• 只从设备 GPS 获取坐标。
• 不从文本推断位置。
• 不让 Agent 生成或猜测坐标。
• GPS 获取失败不阻塞输入，只是不写 input_location。
• 不改 Agent prompt；如果 Agent 在 ReAct 链路中读到 Fact metadata 并认为位置有用，可以自然使用。
• 暂不做逆地理地址落盘；第一版先保证精确坐标和精度可信。

非目标

• 不新增单独的“保存 GPS”开关。Memex 是本地优先存储，用户输入本身已经是敏感本地数据，GPS 可以作为输入 metadata 一并本地保存。
• 不做文本地点识别或地点推断。
• 不把“记录时位置”混同为“事件发生位置”。第一版字段名使用 input_location，只表达输入发生时设备所在位置。
• 不复用 user_fixed_location。该字段应继续表示用户手动修正或选择的位置。
• 不在第一版强制改 Card 展示或地图分析。

后续可选扩展

• 在 Card YAML 中镜像 input_location，方便详情页或地图组件读取。
• 在 SQLite cache 中增加 lat/lng/accuracy/location_source 等字段，用于地图、统计、聚类、筛选等高频查询。
• 后续如需要，可另行设计 event_location / captured_location，用于照片 EXIF 或用户手动确认的事件发生位置。

收益

• 为地点分析、热力图、地图洞察、时间地点关联提供稳定数据基础。
• 数据来源清晰：这是设备 GPS 原始 metadata，不是 Agent 推断结果。
• 对现有 Agent 链路侵入较小，Fact 仍是统一原始记录入口。
• 本地优先存储下，坐标数据不会引入额外服务端依赖。

风险与注意点

• Fact 会进入多个 Agent 的上下文，精确坐标会随 Fact metadata 一起被 Agent 看到；这是可接受的，但需要保持字段语义清晰，避免 Agent 把它误当作事件地点。
• GPS 可能不准确，必须保存 accuracy_meters。
• 老 Fact header 可能是 {} 或没有该字段，解析逻辑需要兼容。
• 如果未来 Card 和 SQLite 都镜像位置数据，需要明确 Fact metadata 是 source of truth，其他层是派生索引或读取便利层。

验收建议

• 提交输入且设备 GPS 可用时，Fact entry header 写入 input_location。
• GPS 不可用、权限不可用或超时时，输入仍然成功，Fact 不写 input_location。
• 老数据和空 metadata 仍可正常解析。
• 写入数据只包含设备 GPS 和精度等采集 metadata，不包含文本推断地点。