跳到主要内容

ADR-031 — FinBayes 数据能力内化分诊与首条目（实时/盘后股价）

§0 决议简述​

把 ADR-0005「消费方直连商品化行情、DH 只产差异化资产」的边界，落成一套面对具体数据需求时的分诊程序（三问：真实需求 → 最佳权威源 → 商品化则 FinBayes 直连进对应数据层 / 差异化则归 DH OpenAPI），并记录首个应用：实时/盘后美股价属商品化，FinBayes 直连补进已有 equity 取数链（build_equity_chain），不走 DH、不抓网页、不打提示词补丁。实施层面 owner 2026-06-24 拍定：现阶段免费非实时数据（yfinance / stooq 延迟档）即可、不上实时付费档，实时升级留后续按需触发（见 §2.3）。

§1 背景与根因​

2026-06-24 live 监听发现 FinBayes 在「BTC+NVDA 波动监控」心跳里反复 web_fetch robinhood 股价页（累计 30 次），与同轮已调的原生 quote(NVDA) 重复。

逐层追问（非「压制 robinhood」的补丁式思路）：

  • 真实需求：robinhood 页相对原生 quote 只多两样——实时价 + 盘前盘后价。原生 equity quote 走 yfinance/stooq，延迟约 15 分钟、盘后仅给收盘；对「抓当下波动 / 盘后异动」不够新，agent 遂自发去抓网页凑合（无任何指令驱动，prompts / TOOLS / HEARTBEAT / cron 均无此指引）。
  • 根因不是缺工具，是链上实时源槽空着：equity 取数链 build_equity_chain 本就为 alpaca 留了槽，但 ① 未配 key、② alpaca 免费档同样延迟 15 分钟（data/alpaca.py 的 get_latest_quote 自陈）。实时/盘后需付费档或实时 vendor。robinhood 抓取是这个未配置的实时源的临时替代。

§2 决议详述​

§2.1 数据需求分诊三问（可复用，避免逐缺口打补丁）​

面对任一「agent 去抓网页 / 拒答」的数据症状，不先想「怎么补这张网页」，而按三问分诊：

  1. 真实数据需求是什么？（剥开症状——要的是哪类数据 / 哪个维度，不是那张被抓的页）
  2. 最佳权威源是谁？（结构化、带出处、可标 as_of 的源，而非 HTML 抓取）
  3. 该谁做、落哪层？——按 ADR-0005 的两条边界：
    • 商品化行情（多家 vendor 都能给的大路货：实时报价、历史 K 线、盘口深度…）→ FinBayes 直连，补进对应数据层取数链（data/ 下的弹性多源链 + FetchResult 出处），不经 DH；
    • 差异化聚合资产（跨源聚合、需加工判断的：清算聚合、ETF 历史流、KOL 情绪…）→ 归 DH，由 DH 出 OpenAPI 提供。

判据沿用 ADR-0005：能直连的商品化不进 DH；DH 的价值在差异化，不做大路货价的转发网关。与 ADR-0005「DH 过渡桥、FinBayes 终局自主内化」一致。

§2.2 首条目：实时/盘后美股价 = 商品化 → FinBayes 直连补 equity 链​

  • 分诊结论：实时股价是彻底的商品化行情（polygon / finnhub / alpaca-SIP 谁都能给）→ 按 §2.1 归 FinBayes 直连，不走 DH（让 DH 做实时股价网关是错配其定位）。
  • 落点：已有的 equity 取数链 build_equity_chain（data/equity_quote.py）。把空着的实时源槽补上，并让 FetchResult 出处诚实标注 实时 / 延迟 / 盘后、渲染层让 agent 看见它是实时的——从而不再去抓网页。这是把本就为此设计的链补完整，不是 robinhood 补丁、不是提示词软劝、不是绕 DH。
  • 明确排除：① 不在系统提示里劝退 robinhood（自发行为，软引导不可靠）；② 不为此走 DH。

§2.3 需求分解与 owner 决策​

实时需求要拆开看、按价值上档，避免为边际收益付月费：

  • 盘后 / 盘前价 = 真缺口：现链完全没有，捕捉盘后异动要靠它。
  • 实时盘中价 = 边际收益小：30 分钟心跳的 ±2% 监控，延迟 15 分钟大体够用（晚 15 分钟发现）；未必值实时付费档。

owner 2026-06-24 拍定：现阶段维持免费非实时数据即可（equity 链现有 yfinance / stooq 延迟档），不上实时付费档（alpaca-SIP / polygon / finnhub 暂不接）；实时 / 盘后升级留后续按真实需求触发，由取数用量记录（data_usage.jsonl 攒「股票实时 / 盘后被需要的频次」）驱动，不拍脑袋。即 §2.2 的「补实时源槽」为已定方向、暂缓实施——方向不变（要补时落 build_equity_chain 直连、不走 DH），当前不补。

§3 不变 / 变​

  • 不变：ADR-0005 两条边界与终局自主内化；FinBayes 取数容错链架构（弹性多源 + FetchResult 出处）。
  • 变：把上述边界落成可执行的分诊三问；equity 链从「延迟单档」明确为「应含实时 / 盘后源槽（待配）」；数据能力内化从「按真实使用驱动」得到首个具体条目。

§4 落地状态与待办​

  • 未实现（本 ADR 只定方向与落点）。实现 = 待 owner 定 vendor / 档位后，补 build_equity_chain 的实时源 + 出处标注。
  • 同类先例已落：2026-06-24 live RCA 已把 crypto ohlcv 从「死磕被墙 binance」改为可达 venue 兜底链（FinBayes 直连商品化 K 线的样板，代码在工程仓）——证明「商品化直连进数据层」的做法可行。
  • 数据内化主线：本条目登记进 CURRENT-MILESTONE 数据内化条。

§5 关联与对其他缺口的分诊​

本框架一分，监听报告里其余数据缺口各归其位：

  • 长历史 K 线 = 商品化 → FinBayes 直连（即已修的 ohlcv 链，深历史 = 换有深档 vendor）；
  • ETF 历史流 / 清算聚合 = 差异化聚合 → 归 DH OpenAPI（清算已是 CoinAnk pilot 在走，见 DH 集成任务书）；
  • 实时 / 盘后股价 = 商品化 → FinBayes 直连补 equity 链（本 ADR）。

关联：ADR-0005 生态级数据边界口径、ADR-030 DH↔FinBayes 数据接口分工。