Data Horizon 系统架构设计（L3）
状态：L3 正文 §1–§29 全部主笔完成（对标 FinBayes L3 架构 29 节 9 部分，适配 Data Horizon 感知 / 资产语义，逐部双路评审）。九部分：立架（§1–3）/ 业务架构（§4–6）/ 系统全景（§7–10）/ 系统运行（§11–13）/ 部署与基础设施（§14–16）/ 横向关注点（§17–19）/ 质量与验收（§20–21）/ 缺口与决策（§22–24）/ 落地映射（§25–29）。收尾待办：双路总评审 + ADR 落盘 + 复盘 + playbook 反馈。DH 语义改写：FinBayes 的「认知流转 / 问答 / Provider L1–L4 降级 / 澄清回路 / 会话压缩」→ DH 的「感知流转（采集 → 标准化 → 资产 → 输出）/ 来源健康降级 / 复核回路 / 去重聚合 / 高频管线（Scraper / Standardize / RawNews / Push Job）」。
文档结构（九部分）
| 部分 | 节 | 主题 |
|---|---|---|
| 第一部分 立架 | 1–3 | 文档角色与读者、上位继承与不变量、架构目标与质量取舍 |
| 第二部分 业务架构 | 4–6 | 业务对象与关系、感知价值与信息流转、关键业务场景 |
| 第三部分 系统全景 | 7–10 | 系统与外部世界的关系、进程与服务划分、子系统内部组件、关键场景流转图 |
| 第四部分 系统运行 | 11–13 | 状态对象生命周期、并发与异步处理、故障与降级路径 |
| 第五部分 部署与基础设施 | 14–16 | 部署形态、数据存储划分、通信协议 |
| 第六部分 横向贯穿的关注点 | 17–19 | 边界与安全、可观测性、演化与版本管理 |
| 第七部分 质量与验收 | 20–21 | 测试体系、质量与反馈闭环 |
| 第八部分 已知缺口与决策 | 22–24 | 第一阶段缺口、架构决策索引、风险登记 |
| 第九部分 落地映射 | 25–29 | 里程碑/任务对应、审计点、代码仓位置映射、首个工程包、感知能力前沿承接 |
第一部分 立架
1. 文档角色与读者
这一节回答：这份文档是什么，怎么用。
这是什么
Data Horizon 系统架构文档是 Data Horizon 系统设计的总图。它从战略白皮书（L1）与系统 / 产品定义（L2，含第十五节 L3 承接补强）派生，把战略与定义层的「感知什么、做什么、沉淀什么资产」翻译成工程层的「系统是什么样的、信息怎么流转、状态怎么变、怎么部署、怎么演化」。
本文是 L3：它不重新定义 Data Horizon，也不替代 L2 定义与差距映射表；它把 L2 的概念对象、关键场景、状态轮廓、接触契约、不变量与 ADR 候选，落到子系统、组件、接口、状态机、存储与部署。
怎么用
按需查阅，不必从头读到尾。
- 写代码时：去第三部分「系统全景」找当前要实现的子系统与组件；去第四部分「系统运行」找状态机与并发时序；去第二十七节「代码仓位置映射」找代码落点。
- 设计评审时：先读第二部分「业务架构」建立总体认识，再核对要评审的模块所属子系统与状态对象。
- 遇到模糊点：查第二十三节「架构决策索引」，每个关键决策列出决策点、约束与优先级；高优先级 ADR 在起代码前须先有结论。
- 接手维护时：从第一部分「立架」三节建立坐标系，再按需 zoom in。
与上下游文档的承接
- 战略白皮书（L1）：Data Horizon 是什么、感知版图与重要度分层、三类战略资产、职责分工与战略边界。
- 系统 / 产品定义（L2）：概念对象、业务闭环、六类资产与七维度、一主四辅形态、五能力域、验收；第十五节专为本文提供承接抓手（关键场景 / 对象关系与跨层映射 / 状态轮廓 / 外部接触契约 / 边界不变量与 ADR 候选 / 质量取舍）。
- 差距与需求映射（gap-map）：感知覆盖差距、闭环 / 资产 / 横向能力差距、任务包候选——喂入本文第二十二节缺口与第二十五节任务对应。
- 本文（L3）：把上述落到子系统、组件、接口、状态机、存储、部署、演化。
- 实施任务包 / 工程设计：按本文与 gap-map 切片实施。
任何冲突以战略白皮书与系统 / 产品定义为准，本文须修正。
2. 上位继承与不变量
这一节回答：Data Horizon 的工程实现必须承接哪些战略层事实。
Data Horizon 是什么
Data Horizon 是 FinTec AI Ecosystem 感知环节中的金融感知资产生产与输出系统。它把公开金融信息、私域 / KOL 信息与市场数据，经接入、处理、组织、溯源、质量判断与输出控制，转化为可被人和系统持续消费的金融感知资产。它不是单一产品，而是由一组产品面、工具族、处理框架、资产库与输出机制组成的系统群。
战略边界
Data Horizon 合成事实，不代为认知；产出信号资产，不产生交易动作；保留反馈样本边界，不做模型训练设施。
工程层承接：runtime 范围只包含「采集 → 处理 → 资产化 → 输出」的感知资产生产，三条战略边界的逐条架构承接见下方边界不变量表（第 1 / 2 / 5 条，不在此复述）；输出端不产出「看多 / 看空 / 下单」类动作语义，只产出可信、可回测的事件与信号资产。
边界不变量（继承 L2 第十五节之五，架构层逐条承接）
| # | 不变量 | 架构层承接 |
|---|---|---|
| 1 | DH 合成事实，不代为认知 | 处理子系统只做清洗 / 去重 / 翻译 / 抽取 / 聚合，不写「结论 / 倾向 / 看多看空」字段；认知请求一律不在 runtime 内实现 |
| 2 | 信号（含采集的他人职业信号）是资产，不是交易动作 | 金融信号资产的 schema 不含可执行指令；输出契约不携带下单参数 |
| 3 | 私域 / 受限来源必须保留授权与适用限制，不得越权输出 | 授权维度绑定到 Source 与受限 Information Asset；输出前校验授权与适用限制（第十七节）；未授权 / 受限资产在交付前被拦截 |
| 4 | 结构化行情第三方可自助，DH 不以重复路由为主线 | 行情接入按需、低优先（第二十二节缺口、ADR-候选-07），不建为 P0/P1 主链路 |
| 5 | DH 不做模型训练设施（归 FEFM）；仅保留反馈样本 / 质量标签边界 | 反馈与质量标签作为资产维度保留，不实现训练 / 微调流程 |
| 6 | 质量不确定时显式标记，不包装成确定判断 | 标准化失败 / 低置信不静默丢弃，置质量标记，不进入「可用」资产（第十三节、第十一节状态不变量③） |
| 7 | 每项信息资产必含七维度（来源 / 双时间戳 / 证据 / 质量 / 状态 / 授权 / 反馈） | 资产存储模型强制七维度（第十五节）；缺维度即不可交付 |
除上述七条边界不变量，本架构还继承 L2 第十五节之三的四条状态不变量，作为第十一节状态机与第二十六节审计点的基线：① 终态不可回退（已标准化 / 已采纳 / 丢弃 / 失败 / 已归档 / 已撤回 / 失败终态 / 已确认消费；其中标准化记录的「已采纳」为本文第十一节据状态机闭环细化的 L3 细化态，L2 §15.3 轮廓止于「已复核 / 已纠错」）；② 受限或未授权资产不得对外输出；③ 质量不确定的 标准化记录 不得直接进入「可用」资产；④ 每个终态都应留运行证据、经 Feedback / Evidence 可追溯。
概念使用约定
本文术语与战略白皮书、系统 / 产品定义保持一致：用「感知 / 资产 / 信号候选 / 标准化事件 / 私域职业信号」；信号资产层不用「下单 / 仓位 / 看多看空」等执行 / 认知措辞。概念对象沿用 L2 第七节与第十五节之二的七对象（Source / 原始信息 / 标准化记录 / Information Asset / 交付记录 / Consumer / Feedback），授权（Authorization）为 Source / 资产的维度而非独立建模对象。
如实施中需引入 L1/L2 未授权的新概念，先在战略白皮书或系统 / 产品定义授权（走 governance change-protocol），不在本工程文档自创。
本文档变更时的快速核查
本文每次改动时，下列核查作为变更评审的必要条件（不替代实质语义 review）：
- 战略边界三句「合成事实不代认知 / 产出信号不产交易动作 / 不做训练设施」仍在文档中。
- 七条边界不变量与 L2 第十五节之五一致、无删减、无被同义改写隐藏。
- 信号 / 资产层未出现执行语义（下单 / 仓位 / 具体买卖价位）。
- 七维度强制约束仍在第十五节存储模型中体现。
- AI Trading Matrix 消费对象形态相关处仍为「待对齐 / proposed」，未在未对齐时冻结具体形态。
3. 架构目标与质量取舍
这一节回答：这个架构在追求什么；冲突时按什么规则取舍。
总体目标
让 Data Horizon 实施者（写代码的 AI 助手 / 接手维护的工程师）能实现的系统：
- 不漂移 L1/L2 的不变量（第二节）与职责边界；
- 把复杂、多源、实时、非标准的金融信息持续转化为可追踪、可标准化、可复用、可输出的感知资产；
- 优先把差异化、第三方难自助、高杠杆的信息（私域职业信号、实时突发事件、宏观系统化）做成可实时消费、可回测的资产；
- 资产全程可追溯（七维度）、输出可被机器消费（消费方最小契约）、运营可干预、质量与成本可观测。
关键质量属性
| 质量属性 | 含义 | 主要承接节 |
|---|---|---|
| 可追溯性 | 任一资产可回到来源、双时间戳、证据、授权、处理路径 | §11 状态机、§15 存储、§26 审计点 |
| 时效 | 突发事件 / 私域信号实时链路低延迟 | §12 并发异步、§13 降级 |
| 质量可判 | 标准化质量、置信、复核状态可见且可评估 | §18 可观测性、§21 反馈闭环 |
| 成本可控 | 高频持续运行下分层处理，关键链路成本 / 延迟 / 重复可见 | §13 降级与分层处理、§18 可观测性 |
| 可干预 | 运营人员可配置 / 暂停 / 复核 / 阻断 / 重试 | §9 运营管理子系统、§17 边界 |
| 授权合规 | 私域 / 受限来源授权与适用限制贯穿到输出 | §17 边界与安全 |
| 可演化 | 资产 schema / 契约 / 能力域可扩展、向后兼容 | §19 演化与版本 |
冲突时的取舍
总体优先序（统摄跨链路冲突，承接 L2 第十五节之六并在其上给全局序）：
合规与可追溯 ＞ 时效 ＞ 成本 ＞ 完备。
即：任何输出不得突破授权合规与可追溯（不变量 3、7）；在此前提下，差异化实时链路抢时效；时效满足后压成本；完备性（全市场全覆盖）最后保证、按缺口逐步补。质量不确定时，显式标记优先于强行下结论（不变量 6）。
各链路在总体序下的局部取舍（承接 L2 第十五节之六）：
| 链路 | 局部相对优先 |
|---|---|
| 突发事件 / 事件驱动 | 时效 ＞ 成本 ＞ 完备（抢时效，允许后续补全） |
| 标准化事件 | 质量 / 可追溯 ＞ 时效 |
| 私域职业信号 | 可追溯 / 授权合规 ＞ 时效 |
| 历史市场数据闭环 | 成本 / 完整性 ＞ 时效 |
| 反馈回流 | 可追溯 / 完整 ＞ 时效（可后到，须可关联回来源 / 处理 / 资产） |
第一阶段技术取向
- 复用现行技术栈：Go（go-zero）+ Python 爬虫 + MySQL + Redis + Weaviate（去重向量库）；不为架构纯洁性重写已验证的采集 / 标准化 / 推送链路（详见第二十七节代码仓映射、第八节进程划分）。
- 管线优先、单实例起步：采集 / 处理 / 推送以现行高频 Job（采集 ~60s、Agent ~1s、Push ~1s）为基线演化，第一阶段不引入重型分布式编排（第八节、第十二节）。
- 运营控制面先成立：P0 运营管理子系统（配置 / 观察 / 复核 / 干预 / 输出控制）是所有闭环成立的前提（第九节）。
- 差异化主链路做硬：P1 实时公开信息（突出突发事件）→ ATM、与 P1 并列的私域职业信号资产化优先打通（第六、十节场景）。
第一阶段不投入优化的事
- 结构化行情底座的自建存储与实时路由（第三方可自助，按需、低优先——不变量 4、ADR-候选-07）；
- 全市场全板块铺满（按感知覆盖缺口逐步补，第二十二节）；
- 重型分布式 / 多区域部署与极致吞吐优化（第十四节，第一阶段单实例 / 简单水平扩展为主）；
- 外部商业化产品形态（To B / To C）的接口与计量（边界保留，不牵引第一阶段主线）。
第二部分 业务架构
4. 业务对象与关系
这一节回答：系统里有哪些独立建模对象（即有独立标识与生命周期、被系统直接建模存储的对象），它们之间什么关系，怎么映射到工程。
两套语言不是同一根轴（承接 L2 第十五节之二，不复述）
L2 §15.2 已辨明「六类信息资产」（资产分类，内容是什么）与「七概念对象」（流转阶段对象，处在管道哪一环）是两根不同的轴、互为派生 / 留存而非等同。L3 据此只锁两条工作口径：① 后文一律以七概念对象为独立建模单位（Source / 原始信息 / 标准化记录 / Information Asset / 交付记录 / Consumer / Feedback，各有独立标识与生命周期）；② 六类资产是 Information Asset 上的 type 字段（原始 / 标准化事件 / 金融信号 / 市场数据 / 运行证据 / 输出交付），非第七类对象。派生细节（如输出交付资产＝Information Asset 交付时的快照、交付对象为交付记录）见 §11.5 与 ADR-候选-04 / 08，不在此复述。
关系图
授权（Authorization）不画为独立节点：它是 Source 与受限 Information Asset 的维度（见下）。
各对象的关键属性与生命周期入口
每个对象都承载 L2 第六节的资产必含七维度切面（来源 / 双时间戳 / 证据 / 质量 / 状态 / 授权 / 反馈），具体状态机见第十一节。
| 对象 | 归属能力域 | 关键属性切面 | 持久化 | 生命周期 |
|---|---|---|---|---|
| Source | 信息接入域 | 来源标识 / 类型 / 授权维度 / 健康度 | 是 | §11 Source |
| 原始信息 | 接入 → 处理域 | 原文 / 来源 / 双时间戳（源侧）/ 采集上下文 | 是 | §11 原始信息 |
| 标准化记录 | 信息处理域 | 清洗 / 翻译 / 抽取结果 / 置信 / 复核状态 / 系统侧时间戳 | 是 | §11 标准化记录 |
| Information Asset | 信息资产域 | 六类 type / 七维度 / 可用性 / 适用限制 | 是 | §11 Information Asset |
| 交付记录 | 资产输出域 | 资产引用 / 通道 / 粒度 / 时效 / 交付状态 / 消费确认 | 是 | §11 交付记录 |
| Consumer | 外部（DH 侧留订阅/消费记录） | 角色 / 订阅 / 消费记录 / 契约 | 订阅与消费记录持久化 | §11 Consumer |
| Feedback / Evidence | 运营管理域（贯穿） | 消费结果 / 误报漏报 / 延迟 / 成本 / 人工干预 / 回流目标 | 是 | §11 Feedback |
授权（Authorization）维度的落法
授权不是独立建模对象，而是 Source 与受限 Information Asset 的维度，子状态「已授权 → 受限 → 过期 / 撤销」绑定在来源 / 资产上。工程层第一阶段倾向落为：Source 上的授权字段 + 受限 Information Asset 上的适用限制标记；是否抽出独立「授权记录表」由 ADR-候选-02（私域授权模型） 决定。授权过期 / 撤销 → 关联资产即转「受限」、交付前被拦截（第十七节）。
跨层对象映射（产品 → 架构 → 工程）
| 产品（L2 资产分类 / 对象） | 架构（L3 独立建模对象） | 工程（持久化倾向，最终由 ADR-候选-08 定） |
|---|---|---|
| 原始信息资产 | 原始信息（→ Information Asset.type=raw 的沉淀） | 原始信息表（现行 dn_raw_news 一带） |
| 标准化事件资产 | 标准化记录 → Information Asset.type=event | 现行写入 dn_raw_news 的 std_content 等字段（status≥1），见第十五节；旧表 dn_event_news_std 已停写（CLAUDE.md 仍述为活跃属文档↔运行漂移，§24 风险），不作现行存储 |
| 金融信号资产（自产候选 + 采集他人职业信号） | Information Asset.type=signal | 信号资产存储（新建；区分自产候选 vs 采集职业信号，落字段由 ADR-候选-08 / 工程包定） |
| 市场数据资产 | Information Asset.type=market | 市场数据存储（按需、低优先） |
| 运行证据资产 | Feedback / Evidence | 执行 / 推送 / 反馈证据存储（现行 dn_agent_execution / dn_push_log 一带） |
| 输出交付资产 | 交付记录 | 交付记录存储（现行 dn_push_log 一带） |
| 来源 | Source | 来源 / 爬虫源（现行 dn_crawler_source / dn_kol 一带） |
| 消费方 | Consumer | 订阅者 + 消费记录（现行 dn_subscriber 一带） |
存储是否「六子类各表 vs 单表 + type」由 ADR-候选-08 决定；交付对象的生命周期归 ADR-候选-04、其作为资产快照的归档归 ADR-候选-08，二者非同物。
概念对象 ↔ 现行代码标识（桥接，使文档词可对接代码；完整映射见第二十七节）：
| 概念对象 | 现行代码标识（近似） |
|---|---|
| 信息来源（Source） | dn_crawler_source / dn_kol |
| 原始信息 | dn_raw_news |
| 标准化记录 | 标准化后的 dn_raw_news（status=1） |
| 信息资产（Information Asset） | 多表（标准化事件 / 信号 / 证据 / 交付） |
| 交付记录 | dn_push_log |
| 消费方（Consumer） | dn_subscriber + 消费记录 |
| 反馈 / 证据（Feedback） | dn_agent_execution / dn_push_log |
不在这一章的对象
子系统 / 容器 / 进程是运行时单位（第八、九节），不是业务对象；任务包 WP-* 是实施单位（第二十五节）；ADR 是决策单位（第二十三节）。本章只建业务对象。
5. 感知价值与信息流转
这一节回答：一条信息从进入到被消费，价值如何被逐步生产出来。
感知主线
Data Horizon 的价值不是「看到更多碎片」，而是把多源、实时、非标准的信息流转化为可消费资产。主线一条贯穿五能力域：
这条主线替代 FinBayes 的「认知流转」：Data Horizon 做的是事实层聚合（对齐、去重、关联成可追溯结构），不做解释层结论。
关键节点的业务约束
| 节点 | 业务约束（不变量落点） |
|---|---|
| 采集 / 接入 | 私域 / 受限源须先有授权（不变量 3）；保留源侧时间戳与采集上下文（七维度） |
| 去重 | 重复命中不静默吞掉差异，保留可追溯（Weaviate 向量去重，§12/§15） |
| 抽取 | LLM 抽取失败不静默丢弃：置质量标记、转「失败 / 低置信」，不进入「可用」资产（不变量 6，纠正现行 "continue without result" 隐患，§13） |
| 资产化 | 强制七维度，缺一不可交付（不变量 7） |
| 输出 | 携带消费方最小契约（粒度 / 时效 / 证据·质量）；受限 / 未授权资产交付前拦截（不变量 3、§16/§17） |
| 反馈回流 | 消费结果须可关联回来源 / 处理 / 资产质量判断（§21） |
三套视角的对应（承接白皮书第四节之四）
同一条感知链路的三个切面，贯穿第四–五节与第九节：
| 感知对象（感知什么） | 能力域（如何处理） | 资产类型（产出什么） |
|---|---|---|
| 公开金融信息（新闻 / 公告 / 监管 / 宏观） | 接入 → 处理（清洗 / 标准化） → 资产 → 输出 | 公开金融信息资产 → 标准化事件 |
| 私域职业信号 / KOL | 接入（授权） → 处理（解析 / 证据保留） → 资产 → 输出 | 私域金融信号资产 |
| 行情 / K线 / 盘口（结构化） | 接入 → 组织 / 时间化 → 资产（按需、低优先） | 市场数据资产 |
6. 关键业务场景
这一节回答：第一阶段系统要支撑哪些端到端业务流。承接 L2 第十五节之一的场景清单，详述于此；时序 / 分支图见第十节。
场景一览
| 编号 | 场景 | 闭环 | 优先级 |
|---|---|---|---|
| S1 | 突发事件 / 突发新闻 → AI Trading Matrix | P1（主线，实时主链路） | 硬 |
| S2 | 私域职业信号资产化 → AI Trading Matrix（跟单 + 可回测） | P2（差异化主线，与 P1 并列） | 硬 |
| S3 | 来源异常处理（运营干预） | P0 | 硬 |
| S4 | 公开高价值事件复核 | P0 / P1 | 硬 |
| S5 | 反馈回流（消费结果 → 质量判断） | P1 | 硬 |
| S6 | FinBayes 证据包消费 | P4 | 后置 |
| S7 | 历史市场数据资产化（导入 / 标准化 / 检索 / 复用） | P3 | 后置 |
| S8 | 运营工作台与输出控制总览 | P0（主产品面） | 硬 |
P0–P4 是闭环归属编号，不是线性优先级（承接 L2 §5）：表中「闭环」列标识场景所属业务闭环，「优先级」列（硬 / 后置）才是落地排序。S2 私域职业信号归 P2 闭环，但属重要度第一层差异化主线、与 P1 并列做硬——不因编号在后而降权。
场景详述
S1 — 突发事件 / 突发新闻 → AI Trading Matrix（P1 实时主链路）
- 触发：实时突发事件 / 突发新闻进入接入域。
- 流转：采集 → 突发识别 → 标准化（清洗 / 翻译 / 抽取）→ 跨源互证 → 标准化事件 / 突发事件资产 → 交付 ATM。
- 对象 / 状态：原始信息（待处理 → 已标准化）→ 标准化记录（生成 →〔高价值时〕已复核 → 已采纳）→ Information Asset（草拟 → 可用）→ 交付记录（待交付 → 已交付 → 已确认消费）。
- 约束：在授权 / 可追溯满足前提下最高时效优先（与 §3 总序一致）；跨源互证以降误报；高价值可触发人工复核但不得阻塞突发事件实时主链路；输出形态待与 Trading Matrix 对齐（§7 / ADR-候选-03）。
S2 — 私域职业信号资产化 → AI Trading Matrix（P2 差异化主线）
- 触发：私域职业分析师 / 交易员发出策略观点或交易信号。
- 流转：授权接入 → 解析 / 证据保留 → 区分职业信号 vs 一般 KOL → 资产化（实时 + 可回测两形态）→ 交付 ATM（跟单 + 策略沉淀）。
- 对象 / 状态：Source（职业信号源，已授权）→ 原始信息 → 标准化记录（解析 / 证据保留）→ Information Asset.type=signal（采集职业信号，草拟 → 可用 → 受限 → 已归档 / 已撤回）→ 交付记录。
- 约束：须保留授权与适用限制（不变量 3）；信号是资产不是交易动作（不变量 2）；历史信号须可回测沉淀；唤醒并矫正现行休眠的信号提炼链路（§22 缺口、gap-map WP-P2-04）。
S3 — 来源异常处理（P0 运营干预）
- 触发：某来源采集失败 / 重复率升高 / 质量下降。
- 流转：接入域健康监测 → 运营管理域告警 → 运营人员查看来源状态 / 暂停 / 调规则 / 重试 → 确认是否影响下游。
- 对象 / 状态：Source（活跃 → 降级 / 暂停 / 死源）；Feedback 留证据。
- 约束：运营人员可干预；死源（数月无数据）须可识别（现行存在多个死源，§24 风险）。
S4 — 公开高价值事件复核（P0/P1）
- 触发：公开金融事件进入、命中高价值 / 异常。
- 流转：标准化 → 高价值 / 异常判定 → 复核队列 → 运营复核 / 纠错 / 阻止输出。
- 对象 / 状态：标准化记录（生成 → 待复核 → 已复核 / 已纠错 → 已采纳）。
- 约束：质量不确定显式标记（不变量 6）；复核不阻塞 S1 实时主链路。
S5 — 反馈回流（P1）
- 触发：ATM / 机器客户端 / FinBayes 消费后回传结果。
- 流转：输出域收消费确认 / 反馈 → 运营管理域 → 回流到来源 / 处理路径 / 资产质量判断。
- 对象 / 状态：Consumer → Feedback（采集 → 已关联）→ 影响 来源 / 标准化记录 / 信息资产。
- 约束：误报 / 漏报 / 延迟 / 低价值须可回流并影响后续质量；当前 webhook 仅返回传输层 received、无业务消费确认 / 反馈落库，是缺口（§22、gap-map WP-P1-03）；RLE / FEFM 仅保留边界反馈样本，第一阶段不进硬场景。
S6 — FinBayes 证据包消费（P4，后置）
- 触发：FinBayes 发起研究 / 问答检索。
- 流转：资产检索 → 证据包组织 → 交付（拉取）。
- 对象 / 状态：Information Asset → 交付记录（待交付 → 已交付（拉取已取））。
- 约束：只读消费；DH 提供事件 / 信号 / 证据 / 历史材料，不产认知结论（不变量 1）。
S7 — 历史市场数据资产化（P3，后置）
- 触发：交易所历史数据包 / K 线 / 盘口 / 成交量等市场数据接入与评估。
- 流转：数据包导入 → 清洗 / 标准化 / 时间化 → 市场数据资产入库 → 检索 / 复用（回测 / 复盘）。
- 对象 / 状态：Source（数据包源）→ 原始信息 → 标准化记录 → Information Asset.type=market（草拟 → 可用）。
- 约束：纳入第一阶段定义、后置但非「以后再说」（承接 L2 §5 P3、§11 边界、gap-map WP-P3-01）；结构化行情第三方可自助、不以重复路由为主线（不变量 4）；成本 / 完整性优先于时效（§3）。
S8 — 运营工作台与输出控制总览（P0，主产品面）
- 触发：运营人员 / 业务负责人进入数据视界管理系统。
- 流转：运营管理域汇总接入 / 处理 / 资产 / 输出全链路状态 → 配置 / 观察 / 复核 / 干预 / 告警处理 / 输出控制（阻断 / 放行） / 消费反馈总览。
- 对象 / 状态：贯穿全部对象（只读观察 + 干预写）；交付记录（输出控制：阻断 / 放行）；Feedback（消费反馈总览）。
- 约束：管理系统是横向控制面，不是旁路后台（承接 L2 §3 第一主用户、§7 一主四辅、§9 运营管理域）；P0 是所有闭环成立的前提，先于 P1/P2 做硬。
不在第一阶段场景之列
外部商业消费者（To B / To C）的计量与产品化、RLE / FEFM 的训练样本主供、结构化行情实时路由——边界保留，不在第一阶段场景（§3 不投入优化的事）。
第三部分 系统全景
7. 系统与外部世界的关系
这一节回答：系统边界在哪，谁在边界外，各自怎么接触。
系统上下文图
DH 与生态内其他项目的边界：合成事实不代认知（→ FinBayes）、产出信号资产不产交易动作（→ AI Trading Matrix）、保留样本边界不做训练（→ FEFM）（第二节不变量 1/2/5）。
七类外部角色接触契约
承接 L2 第十五节之四，逐角色定义接触形态、输入、输出、控制权、禁止事项与第一阶段接入。
| 外部角色 | 接触形态 / 方向 | 输入（→DH） | 输出（DH→） | 控制权 | 禁止事项 | 第一阶段 |
|---|---|---|---|---|---|---|
| 数据视界运营人员 | 管理系统主面（双向） | 配置 / 复核 / 干预指令 | 链路状态 / 资产 / 证据 / 告警 | 暂停 / 重试 / 复核 / 阻断输出 | 不代下游认知 / 执行 | P0 硬 |
| AI Trading Matrix | 输出机制（拉取 / 订阅 + 回传） | 拉取 / 订阅请求；消费确认 / 反馈 | 标准化事件 / 突发事件资产 / 私域职业信号（实时+可回测）—— 形态待与 Trading Matrix 对齐 | 按契约消费 + 回传证据 | DH 不下单 / 不产交易动作 | P1 硬 + 私域信号主线 |
| FinBayes | 查询 / 证据包（拉取） | 研究 / 问答检索 | 事件 / 信号 / 证据 / 历史材料 | 只读消费 | DH 不产认知结论 | P4 后置 |
| 机器客户端（API/MCP/SDK/CLI） | 稳定协议（拉取 / 订阅） | 查询 / 订阅 / 拉取 | 按消费方最小契约的资产 | 按权限消费 | 不得越权访问受限私域资产 | P1 起评估（评估对象，不抢 ATM 第一验证场景） |
| RLE | 反馈样本 / 质量标签边界 | 后续 | 训练样本 / 质量信号（边界保留） | 后续 | 第一阶段不主供 | 边界保留 |
| FEFM | 语料 / 能力建设材料边界 | 后续 | 语料 / 质量标签（边界保留） | 后续 | DH 不做训练设施 | 边界保留 |
| 外部商业消费者（ToB/ToC） | 长期产品边界 | 后续 | 数据 / 资讯产品（待定） | 后续 | 不牵引第一阶段主线 | 边界保留 |
待对齐项·AI Trading Matrix 消费对象形态（外部依赖，本节锚定）
AI Trading Matrix 实际以何种对象消费（标准化事件 / 信号 / 数据流 / 告警 / 证据包？）需与 Trading Matrix 团队跨项目对齐；对齐前本文不冻结具体形态。
在对齐前：上表 AI Trading Matrix 行的输出形态保持「待对齐」，对应架构决策 ADR-候选-03 仅为待定（proposed）、不冻结（第二十三节）。对齐后回填三处：本节该行、L2 第八节消费方最小契约、差距映射表第九节核对项。第一阶段两类策略消费需求（私域职业信号跟单 + 策略沉淀、突发事件驱动）已明确（第六节 S1/S2、L2 §4），此项只锁「以何种对象封装」。
战略边界在这一层的体现
| 不变量 | 接触层体现 |
|---|---|
| 不代认知（1） | 对 FinBayes / ATM 的输出只含事实层资产，不含「看多看空 / 结论」 |
| 信号非交易动作（2） | 对 ATM 的信号资产不含下单参数；执行在 ATM 侧 |
| 私域授权（3） | 私域来源采集前校验授权；对机器客户端按权限隔离受限资产 |
| 不做训练（5） | RLE / FEFM 仅边界保留，不在第一阶段建训练供给链路 |
8. 系统内部的进程与服务划分
这一节回答：系统在运行时拆成哪些进程 / 服务，怎么协作。
第一阶段的整体取向
现行系统已是「多 Job 管线」（以实际代码 internal/job/ 为准）：采集（多个独立 Scraper Job，多数 ~60s，GDELT ~15m、FRED ~60m）写入原始信息（status=0 待标准化）→ StandardizeJob（~1s，清洗 / 标准化，status 0→1）→ RawNewsJob（~1s，读 status=1，并发 AgentTask 处理 + DirectPushTask 直推，status→2 已分发）→ PushJob（~1s，推送）。Job 由 cron 管理、经数据库表状态流转协作。上述频率为现行观察值、非架构 SLA（SLA / 正式调度在第十二节与实施方案定）。第一阶段复用并矫正这条已验证管线（第三节技术取向），不重写为重型分布式编排：
- 逻辑上按五能力域划分服务边界（接入 / 处理 / 资产 / 输出 / 运营管理），便于演化与职责清晰；
- 物理上第一阶段允许同实例多 Job 协作（单实例优先、简单水平扩展），不强求每个能力域独立进程；
- 拆分粒度的正式决策（单进程 vs 多服务）留 ADR（第二十三节，可新增一条部署形态 ADR）。
容器图
各容器职责
| 容器 / 服务 | 职责 | 对应能力域 / 形态 |
|---|---|---|
| 接入服务 | 多源采集、授权校验、来源健康、原始信息入库 | 信息接入域 / 信息接入工具族 |
| 处理服务 | StandardizeJob：清洗 / 翻译 / 抽取 / 去重（Weaviate）/ 质量标记 → 标准化记录与资产；RawNewsJob：分发（AgentTask 处理 + DirectPushTask 直推） | 信息处理域 / 信息处理框架 |
| 输出服务 | 按契约交付（ATM / 机器客户端 / FinBayes / Telegram），幂等 / 重试 / 消费确认 | 资产输出域 / 资产输出机制 |
| 运营管理服务 | 配置 / 观察 / 复核 / 干预 / 告警 / 输出控制——横向控制面，非旁路后台 | 运营管理域 / 数据视界管理系统（主产品面） |
| 信息资产库与检索 | 六类资产存储 / 索引 / 溯源 / 检索（跨服务共享） | 信息资产域 / 资产库与检索系统 |
容器间通信
- 状态流转为主：采集 → 处理 → 输出经数据库表状态字段（如原始信息 待处理→已标准化、交付 待交付→已交付）+ Job 轮询驱动（现行模式，第十二节并发详述）；
- Redis 承载缓存与轻量队列 / 去重前置；Weaviate 承载语义去重；
- 运营管理服务对其余服务为控制 / 观察关系（配置读写 + 干预指令），不夺取数据主链路。
与工程仓代码位置映射（详见第二十七节）
接入 → internal/job/scraper_*_job.go + 采集适配器；处理 → internal/job/standardize_job.go + internal/job/raw_news_job.go，Agent 族 internal/agent/*（analyst / social / forward）；输出 → internal/job/push_message_job.go + Open API；运营管理 → console。具体路径与矫正点见第二十七节。
9. 每个子系统的内部组件
这一节回答：每个子系统里有哪些组件、对外什么接口、怎么失败、怎么算合格。承接 L2 一主四辅与五能力域。
5 个子系统概览
| 子系统 | 主责对象 | 主责场景 |
|---|---|---|
| 9.1 信息接入 | Source、原始信息 | S1/S2/S3/S7 采集侧 |
| 9.2 信息处理 | 标准化记录、Information Asset | S1/S2/S4 处理侧 |
| 9.3 信息资产库与检索 | Information Asset（六类）、Feedback | 全场景资产侧 |
| 9.4 资产输出 | 交付记录、Consumer | S1/S2/S5/S6 输出侧 |
| 9.5 运营管理（控制面） | 贯穿全部 | S3/S4/S8 控制侧 |
9.1 信息接入子系统
- 组件：来源注册与授权校验、采集适配器族（公开源 / 私域 / API / 数据包 / 另类源）、来源健康监测、原始信息入库与源侧时间戳。
- 关键接口：注册来源（含授权维度）、采集回调 / 入库、来源状态查询。
- 失败模式：采集失败 / 限流、授权缺失或过期（拒采，不变量 3）、重复率过高 / 死源（→ 降级，第十一节 Source 状态）。
- 验收信号：来源状态 / 失败原因 / 重复率 / 延迟可见（gap-map WP-P0-02）；私域源无授权即不可采。
9.2 信息处理子系统
- 组件：清洗、去重（Weaviate 语义）、翻译、抽取（LLM，subjects / category / keywords）、跨源互证 / 聚合、质量与置信标记、复核路由。
- 关键接口：提交原始信息 → 标准化记录；标准化记录 → 资产；复核队列读写。
- 失败模式：抽取失败 / 低置信——不静默丢弃，置质量标记转「失败 / 低置信」、不进入「可用」资产（不变量 6，矫正现行 "continue without result" 隐患）；翻译失败重试；去重命中保留差异。
- 验收信号：可抽样评估事件质量（成功 / 低置信 / 失败 / 需复核），重复识别可解释（gap-map WP-P1-01）。
9.3 信息资产库与检索子系统
- 组件：六类资产存储（Information Asset + type）、七维度强制校验、索引与检索、溯源链、运行证据（Feedback / Evidence）。
- 关键接口：写资产（校验七维度，缺维度拒写——不变量 7）、检索 / 溯源、证据写入与回流读取。
- 失败模式：维度缺失拒写、溯源断链告警、受限资产标记（授权 / 质量）。
- 验收信号：任一资产可回到来源 / 双时间戳 / 证据 / 授权 / 处理路径（第二十六节审计点）。
9.4 资产输出子系统
- 组件：消费方契约封装（最小契约：粒度 / 时效 / 证据·质量）、交付通道（ATM / 机器客户端 / FinBayes / Webhook / Telegram）、幂等 / 重试 / 回放、消费确认与反馈采集、输出前授权 / 受限校验。
- 关键接口：交付（按角色契约）、消费确认回传、订阅管理。
- 失败模式：推送失败重试 → 超上限失败终态（第十一节 交付记录）；当前
/v1/webhook仅返回传输层 received、无业务消费确认 / 无反馈落库——是缺口（gap-map WP-P1-03，第二十二节）；受限 / 未授权资产交付前拦截（不变量 3）。 - 验收信号：ATM / 机器客户端可按契约消费并回传使用结果（不只推送文本）；ATM 消费对象形态待与 Trading Matrix 对齐。
9.5 运营管理子系统（控制面）
- 组件：来源 / 链路健康总览、复核 / 干预队列、告警处理、输出控制（阻断 / 放行）、成本 / 质量 / 延迟 / 消费反馈总览、配置管理。
- 关键接口：配置读写、干预指令（暂停 / 重试 / 复核 / 阻断）、观察查询。
- 失败模式：干预指令未达 / 冲突；告警风暴（需聚合）。
- 验收信号：运营人员能配置 / 暂停 / 复核 / 重试 / 处理告警 / 控制输出——控制面非只读看板（L2 §12 验收「运营可干预」）。
子系统间数据流
接入（来源 / 原始信息）→ 处理（标准化记录 / 信息资产）→ 资产库（持久 + 检索）→ 输出（交付记录 / 消费方）→ 反馈（回流接入 / 处理 / 资产）；运营管理横向贯穿，对四者为配置 / 观察 / 干预 / 输出控制（第八节容器图、第十节场景流转图）。
10. 关键场景流转图
这一节回答：关键场景在子系统间怎么逐步流转。把第六节场景升级为时序图，对象 / 状态承接第四、十一节。
S1 — 突发事件 → AI Trading Matrix（P1 实时主链路）
S2 — 私域职业信号资产化 → ATM（P2 差异化主线）
S5 — 反馈回流（P1）
S8 — 运营工作台与输出控制（P0 主产品面）
场景清单与关系
S1（突发事件）与 S2（私域职业信号）是两条差异化主链路；S3（来源异常）/ S4（高价值复核）/ S8（输出控制）是 P0 运营干预；S5（反馈回流）闭合质量环；S6（FinBayes 消费）/ S7（历史市场数据）后置。其余场景（S3/S4/S6/S7）沿用「接入 → 处理 → 资产 → 输出 + 运营横向干预 + Feedback 回流」主模式，但各有差异分支——S3 偏 Source 降级 / 暂停、S4 偏 标准化记录 复核、S6 偏 交付记录 拉取消费、S7 偏 市场数据 资产化——其状态分支在第十一节状态机逐对象详述，不在本节共用主图强行合并。
第四部分 系统运行
11. 状态对象生命周期
这一节回答：每个对象在生命周期里有哪些状态、怎么转移、各态守什么不变量。承接 L2 §15.3 状态轮廓与第二节四条状态不变量。状态名为定义层口径，与现行字段（如原始信息 status、交付 push_status、重试上限）的对应在第二十七节 / 工程包定，本节不冻结字段。
11.1 Source（来源）
不变量：私域 / 受限来源进入「活跃」前须「已授权」（不变量 3）；「死源」须可被运营识别（现行存在多个死源，§24 风险）。
代码对应（留第二十七节）：现行来源仅「启用 / 停用」二态，降级 / 死源 / 退役为目标态、落字段待定。
11.2 原始信息
不变量：终态（已标准化 / 重复丢弃 / 处理失败）不可回退（状态不变量①）；「处理失败」不静默丢弃，置质量标记留证据（不变量 6、状态不变量④）。
代码对应（留第二十七节 / 工程包）：现行以单一失败状态 + last_err 的 duplicate: 前缀承载「重复丢弃 / 处理失败」两个定义层终态；是否拆为独立状态 / 字段待定。
11.3 标准化记录
不变量：质量不确定的 Record 不得跳过「待复核」直接进入「可用」资产（状态不变量③）；复核不阻塞 S1 实时主链路（高价值异步复核）。
终态口径：「已采纳」是本节据状态机闭环细化出的 L3 细化态——L2 §15.3 的标准化记录轮廓终态止于「已复核 / 已纠错」，本节在其后补「已采纳」表示采纳为可用资产前的确认（生成→可用资产的过渡终态），非 L2 自带终态。L2 §15.3 已加前瞻注指向此细化。
11.4 Information Asset（信息资产，六类 type）
不变量：进入「可用」须七维度齐（不变量 7）；「受限」资产不得对外输出（不变量 3、状态不变量②）；终态（已归档 / 已撤回）不可回退。
11.5 交付记录（状态不分推送 / 拉取通道）
不变量：受限 / 未授权资产不得创建 交付记录（输出前拦截，不变量 3）；交付生命周期归 ADR-候选-04，其作为资产快照的归档归 ADR-候选-08（见 §4，二者非同物）；终态（已确认消费 / 失败终态）不可回退。
11.6 Consumer / Feedback / Authorization
| 对象 | 状态轮廓 | 说明 |
|---|---|---|
| Consumer（外部） | 已订阅 / 活跃 → 暂停 / 失效 | DH 侧仅维护订阅与消费记录，不持有完整内部生命周期 |
| Feedback / Evidence | 采集 → 已关联 → 已归档 | 回流到来源 / 处理 / 资产质量判断后「已关联」；每个其他对象的终态都应留 Feedback（状态不变量④） |
| Authorization（维度） | 已授权 → 受限 → 过期 / 撤销 | 非独立对象，绑定 Source / 受限 Information Asset；过期 / 撤销 → 关联资产转「受限」 |
运行证据资产 vs 下游反馈（见第十五节已定）：「运行证据资产」（Feedback / Evidence）与「下游反馈」的状态机 / 存储 / 保留策略归属，已在第十五节存储划分落定（见 §15「运行证据 vs 下游反馈」小节），避免混表。
12. 并发与异步处理
这一节回答：高频管线怎么并发、怎么不重不丢不堵。
第一阶段并发模型
现行以 cron 多 Job 驱动（cron.WithSeconds() + SkipIfStillRunning）：每个 Job 到点触发，若上一轮未结束则跳过本轮，天然防同 Job 重入。Job 间经数据库表状态字段流转（待处理 → 已标准化 → 已分发），按状态轮询取下一批，不共享内存态。第一阶段保留此模型，不引入重型消息队列编排（第三节技术取向）。
| 并发面 | 现行机制 | 矫正 / 注意 |
|---|---|---|
| 同 Job 防重入 | SkipIfStillRunning | 保留 |
| Job 间协作 | 表状态轮询（StandardizeJob → RawNewsJob → PushJob） | 轮询频率为观察值、非 SLA；积压用状态计数可见（§18） |
| 单条内并发 | RawNewsJob 对每条 news 并发 AgentTask（处理）+ DirectPushTask（直推） | 两任务返回后置「已分发」；现行 task 内失败不阻断分发、仅记日志（与「错误必须返回 / 不静默丢」需在工程包对齐，§13 / §24） |
| 去重聚合 | Weaviate 语义去重（N Raw → 1 标准化记录） | 去重命中保留差异、不静默吞（§11.2、§13） |
幂等与去重
- 交付幂等：交付记录 须带幂等键，防重复推送 / 重试导致重复消费（现行有推送幂等键；失败重试机制为缺口、待补，ADR-候选-04、§22）。
- 资产去重：Weaviate 语义去重在「待处理 → 已标准化」前置；重复命中转「重复丢弃」并保留差异线索。
上游积压与节流
状态轮询模型下，上游积压表现为某状态计数上升（如「待处理」堆积）→ 可观测（§18）并触发告警 / 扩容评估；下游慢（如 LLM 抽取慢）不丢数据，只延迟。第一阶段不做复杂流控，但积压须可见、可干预。
批与流
突发事件链路偏「流」（低延迟逐条）；历史市场数据（S7）偏「批」（数据包导入）；两者共用对象与状态机，调度策略不同（流式高频、批式按需）。具体调度参数留实施方案。
13. 故障与降级路径
这一节回答：链路各环失败时怎么办，什么降级、什么不能丢。
故障处置矩阵
| 故障点 | 现行 / 风险 | 架构处置 | 不变量 / 状态 |
|---|---|---|---|
| 来源采集失败 / 限流 | 采集失败、重复率升高 | Source 转「降级 / 暂停」，运营可重试 / 调规则 | §11.1；不静默 |
| 授权缺失 / 过期 | 私域源授权问题 | 拒采 / 关联资产转「受限」、不输出 | 不变量 3 |
| 标准化 / 抽取失败 | 现行 "continue without result" → 空抽取、无质量标记（隐患） | 矫正：转「处理失败 / 低置信」、置质量标记、留证据，不进「可用」资产 | 不变量 6、状态不变量③④ |
| 翻译失败 | 现行翻译失败仅记日志后继续（单侧语言缺失），不重试不阻塞 | 待补：失败置标记、留证据（有限重试为目标设计） | 留证据 |
| 推送 / 交付失败 | 现行 PushJob 失败即置失败状态、无重试自增（retry_count<3 过滤器因失败转终态而永不触发，是缺口） | 待补失败重试 → 超上限「失败终态」，留交付证据 | §11.5；§22 缺口；ADR-候选-04 |
| 消费端无业务确认 | 现行 /v1/webhook 仅返回传输层 received，无业务消费确认 / 无反馈落库（缺口） | 补消费确认回流（gap-map WP-P1-03，§22 缺口） | S5、状态不变量④ |
| 依赖故障（MySQL / Redis / Weaviate / LLM Provider） | 单实例依赖；现行 Weaviate 不可用时去重静默跳过、全部放行（无兜底，§24 风险） | 待补：去重不可用时退化为规则去重 + 标记；存储不可用时停采集保留已入库；Provider 故障时降级 / 重试 | 实时主链路不被非关键故障无限阻塞 |
注：现行状态字段无「低置信」中间态。矫正目标的「低置信质量标记」须落为独立质量 / 置信字段，不得复用状态字段（落字段见第十五节 / 工程包）。
降级原则
- 不静默丢：任何失败都留状态 + 证据（状态不变量④），可被运营观察与反馈回流；
- 保护实时主链路：突发事件链路（S1）的非关键增强（如深度跨源互证、人工复核）可降级 / 异步，不阻塞主交付；
- 可追溯优先于完备：故障下宁可少出、显式标记，不出错误确定判断（§3 取舍、不变量 6）。
具体重试上限、超时阈值、熔断参数留实施方案 / 工程包，不在本节冻结。
第五部分 部署与基础设施
14. 部署形态
这一节回答：系统怎么部署、依赖什么、第一阶段什么规模。
第一阶段部署取向：单实例优先
现行为 go-zero 服务（含 cron 调度的多 Job）+ Python 爬虫，单实例运行。第一阶段保留单实例优先（第三节），把复杂度投在差异化资产而非部署架构：
- 计算：一个 go-zero 进程承载接入 / 处理 / 输出 / 运营管理服务与 cron Job；Python 爬虫按源接入。
- 水平扩展：当某类负载（如采集源数、LLM 抽取量）成为瓶颈时，按 Job 类型拆分 / 多实例，而非一开始就微服务化。
- 不做多区域 / 多活 / 极致吞吐优化（第三节不投入优化的事）。
外部依赖
| 依赖 | 用途 | 现行 |
|---|---|---|
| MySQL | 资产 / 来源 / 证据 / 交付 / 配置持久化 | 业务表多为 dn_*，权限 / 系统管理表含 sys_* |
| Redis | 缓存 / 轻量队列 | 现行 |
| Weaviate | 语义去重向量库 | 现行 |
| LLM Provider（可多家） | 抽取 / 图像分析 | dn_llm_provider / dn_llm_config（多 provider 可配） |
| 翻译服务 | 多语言翻译 | 现行（Google / LLM） |
Provider / 翻译为可替换外部依赖；故障降级见第十三节，配置见第十九节。
部署对容器选择的影响
第一阶段「逻辑五能力域、物理同实例」（第八节）：部署单元少、运维简单；代价是单实例故障域大（第十三节降级、第二十四节风险登记）。拆分进程 / 部署形态的正式决策留 架构决策（ADR）（可新增一条「部署形态」ADR）。
环境与配置
环境差异（开发 / 生产）、外部依赖地址、Provider Key、调度频率、重试 / 超时阈值等全部走配置，不在本文冻结具体值（第十九节演化与版本管理给配置位置）。
15. 数据存储划分
这一节回答：哪些东西存在哪、怎么切分、七维度落在哪。
存储映射（资产 / 对象 → 现行表）
| 资产 / 对象 | 现行表（近似） | 说明 |
|---|---|---|
| 原始信息 | dn_raw_news（及 dn_raw_news_direct / dn_raw_news_history） | 接入原文 + 源侧时间戳 + 采集上下文 |
| 标准化记录 | dn_raw_news 的 std_content / subjects / std_extra 等字段（status≥1：1 已标准化待分发、2 已分发，均为标准化后记录；旧表 dn_event_news_std 已停写，见 §4/§24 漂移） | 清洗 / 翻译 / 抽取结果（置信 / 复核状态为矫正目标字段，现行无） |
| 信息资产（六类 type） | 待按 ADR-候选-08 落定 | 标准化事件 / 信号 / 市场数据 / 原始 / 证据 / 交付 |
| 交付记录 | dn_push_log | 推送状态 / HTTP 状态 / retry_count / 错误 / 耗时 / 消息 id（无消费确认字段，是缺口） |
| 来源 + 授权 | dn_crawler_source / dn_crawler_source_category / dn_kol | 现行字段为 source / status / category / std_config / tags；明确授权维度待补（第十七节安全设计） |
| 消费方 | dn_subscriber（订阅）+ 消费记录【缺口】 | 外部角色，DH 侧留订阅；消费记录为缺口（见 §13 / WP-P1-03） |
| 运行证据 | dn_agent_execution / dn_llm_call_log / dn_translate_call_log / dn_push_log 证据 | 处理 / 调用 / 翻译 / 推送 / 失败 / 成本 / 延迟过程证据 |
| 事件分类 | dn_event_category | 分类字典 |
六类信息资产的存储切分（ADR-候选-08）
「六子类各表」还是「单表 + type 字段」是第一阶段必锁的架构决策（ADR-候选-08，高优先）。承接第四节两轴消歧：六类资产是 Information Asset 的 type，是否物理分表由该 ADR 定；交付对象的生命周期（dn_push_log 类）归 ADR-候选-04，其作为资产快照的归档归 ADR-候选-08，二者非同物（第四节、第十一节交付记录）。
去重向量库
Weaviate 承载语义去重（第十二节）；现行 Weaviate 不可用时去重静默放行、无规则兜底（第十三节缺口、第二十四节风险）。去重命中保留差异线索，不静默吞。
运行证据 vs 下游反馈（落定第十一节之六协调点）
两者都归 Feedback / Evidence 概念对象，但来源不同、可分表：
- 运行证据（内部过程）：采集 / 处理 / 调用 / 推送 / 失败 / 成本 / 延迟——现行落
dn_agent_execution/dn_llm_call_log/dn_push_log。 - 下游反馈（外部回传）：消费方使用结果 / 误报漏报 / 低价值——现行缺口（webhook 仅传输层 received、无业务确认 / 反馈落库，第十三节、gap-map WP-P1-03）。
架构判断：保留为同一逻辑对象（反馈与运行证据 / Feedback / Evidence）、两类来源；物理上运行证据沿用现行多表、下游反馈新建反馈记录（表 / 视图形态留 L3 / ADR），经统一反馈口径回流（第二十一节质量与反馈闭环）。保留策略 / 留存期留工程包。
七维度落点
每项信息资产强制七维度（来源 / 双时间戳 / 证据 / 质量 / 状态 / 授权 / 反馈，第二节不变量 7）。其中「质量 / 置信」须落独立字段、不复用状态字段（第十三节注）；「双时间戳」= 源侧时间 + 系统侧时间各一。缺维度即不可交付（L3 目标校验 / 不变量，现行 dn_raw_news / dn_push_log 未强制；资产库写入校验，第九节之三）。具体字段名 / 类型留工程包。
16. 通信协议
这一节回答：对外怎么收发、消费方按什么契约消费、内部怎么协作。
对外协议与接入
| 通道 | 用途 | 现行 / 接入控制 |
|---|---|---|
| API | 机器客户端查询 / 拉取 | Open API；按权限 |
| MCP | Agent 客户端接入 | dn_mcp_api_key（校验 X-API-Key + 状态 / 过期 / 日限额） |
| SDK / CLI | 程序化消费 | 评估方向（第一阶段不全实现） |
| Webhook | 事件 / 信号推送 | 现行 /v1/webhook 仅返回传输层 received；无业务消费确认 / 无反馈落库是缺口（第十三节、gap-map WP-P1-03） |
| Telegram | 人类分发通道 | 现行强项 |
机器客户端现行接入校验 API Key 与状态 / 限额（后台权限表 sys_api_perms 服务于管理后台，非 MCP 资产隔离）；对受限私域资产的细粒度权限隔离待补（第十七节、不变量 3）。
消费方最小契约
面向机器消费的每条输出，除资产本身外携带最小契约（承接 L2 第八节）：
- 粒度：单条事件 / 信号 / 批量数据包等输出单元；
- 时效：产生到可消费的延迟 + 源侧 / 系统侧时间戳；
- 证据与质量标记：来源、置信、复核状态、适用限制。
最小契约让消费方能判断「这条输出是什么、多新、可信到什么程度、能否据以行动」。
交付语义（幂等 / 回放 / 消费确认）
- 幂等：交付带幂等键，防重试 / 重复推送导致重复消费；
- 失败重试：现行
MaxRetryCount=3常量已定义但无任何调用方，dn_push_log.retry_count列恒为 0、不自增；失败即置终态（待推送筛选retry_count<3因失败不回 pending 而永不触发）——是缺口，待补失败重试 → 超上限失败终态（第十一节交付记录、第十三节、ADR-候选-04）； - 消费确认 / 回放：消费方回传确认（现行缺口），支持反馈回流（第二十一节）。
AI Trading Matrix 消费对象形态
ATM 以何种对象消费（标准化事件 / 信号 / 数据流 / 告警 / 证据包）待与 Trading Matrix 对齐（第七节、ADR-候选-03，对齐前不冻结）。两类策略消费需求（私域职业信号跟单 + 策略沉淀、突发事件驱动）已明确。
内部协作协议
内部服务间不引入重型消息队列：经数据库表状态字段流转 + cron Job 轮询（第八、十二节）；Redis 承载缓存与轻量队列。第一阶段保留此模式。
第六部分 横向贯穿的关注点
17. 边界与安全
这一节回答：谁能接入什么、私域信息怎么授权、受限的东西怎么不外泄。
凭证边界
Data Horizon 不持有用户的金融执行凭证（私钥 / 交易所 API Key / 银行账户等）——它不做交易执行（不变量 2、5）。它持有的是采集侧凭证（源 API Key、Telegram token 等），属本机配置秘密，与「用户金融凭证」严格区分，不进入资产内容 / 输出。现行风险：部分采集侧凭证（Bot token / Google API Key / proxy / JWT secret）以明文存于 etc/*.yaml 配置——目标须迁至环境变量 / 密钥管理（第二十四节风险、第十九节配置）。
私域授权模型（ADR-候选-02）
不变量 3：私域 / 受限来源必须保留授权与适用限制，受限资产不得对外输出。现行缺口：dn_crawler_source（source_no / platform / source_type / status / category_id / kol_id / std_config / tags 等）与 dn_kol（kol_name / organization / market / strategy_style / status 等）均无授权 / 适用限制维度——授权模型是待补的安全设计，非现行已具备（现行另有 dn_source_eval_flag.eval_eligible，是评测放行白名单 / 安全闸门，不等于完整私域授权模型）。L3 需定义：
| 要素 | 含义 |
|---|---|
| 授权 | 该私域源是否获授权接入 / 资产化 / 对外输出，及授权范围 |
| 适用限制 | 资产的可用边界（仅内部 / 仅特定消费方 / 不可转售等） |
| 输出限制 | 交付前据授权 + 适用限制校验，未授权 / 超范围即拦截 |
授权维度绑定到来源与受限信息资产（第四节、第十一节）；落为来源字段还是独立授权记录由 ADR-候选-02 定。
接入鉴权与权限隔离
- 机器客户端 / MCP：现行
dn_mcp_api_key校验 X-API-Key + 状态 / 过期 / 日限额（真实）；sys_api_perms是管理后台权限表、非资产隔离。 - 缺口：对受限私域资产的细粒度权限隔离待补——第一阶段须定义「哪个消费方能取哪类资产」的隔离规则（承接第十六节）。
越权与泄露防护
- 受限 / 未授权资产在交付前拦截（不变量 3、第十一节交付记录）；
- 输出端不产出执行语义（下单 / 仓位，不变量 2）；
- 采集侧凭证不进入资产内容、日志正文与对外输出。
具体鉴权协议、加密、密钥管理留工程包；本节定义边界与待补安全设计，不冻结实现。
18. 可观测性
这一节回答：运营人员怎么看见链路健康、成本、质量、消费效果。承接 L2 第十二节验收「运营可干预 / 质量可评估」。
可观测对象
| 维度 | 内容 | 现行证据来源 / 缺口 |
|---|---|---|
| 来源健康 | 采集成功 / 失败 / 重复率 / 延迟 / 死源 | 部分现行；统一健康视图待补（WP-P0-02） |
| 处理成本 | LLM 调用次数 / token、翻译字符 | dn_llm_call_log / dn_translate_call_log（真实，可统计 token / 字符；具体量级以监控为准） |
| 处理质量 | 标准化成功 / 低置信 / 失败 / 需复核 | 缺口：现行无质量 / 置信字段与抽样（第十三节、WP-P1-01） |
| 链路延迟 | 各环耗时 / 积压计数 | dn_agent_execution 耗时 + 状态计数；统一视图待补 |
| 分发效果 | 推送成功 / 失败 / 消费确认 | dn_push_log（可统计推送成功 / 失败，成功率以监控为准）；消费确认 / 反馈为缺口（第十六节） |
| 人工干预 | 复核 / 暂停 / 阻断 / 重试操作 | sys_operation_log（后台操作证据底表）；复核 / 阻断 / 重试的业务干预语义仍需工作台 / 状态机补齐（WP-P0-01） |
运营总览（控制面观测）
第一阶段须把上述散落证据升级为运营人员可读的总览（承接 L2 第十二节「质量可评估、运营可干预」、本文第九节之五运营管理子系统）：来源状态、处理质量抽样、成本 / 延迟、分发与消费反馈、告警队列。现行多为底层记录、未成运营视图——是 P0 工作台的核心缺口（第二十二节）。
告警
现行有 MonitorJob：监控抓取源活性（Website / Discord 长时间无新闻 → Telegram 告警 + 恢复通知，Redis 去重防风暴）——即来源静默 / 死源告警（非价格监控，DH 不做行情）。缺口：失败率 / 成本异常 / 积压计数尚未纳入，须统一进运营告警体系（第十三节）。告警阈值留实施方案。
不要求第一阶段完美指标体系，但关键链路的成本 / 延迟 / 失败 / 重复 / 质量须「能判断变好或变坏」（L2 第十二节）。具体指标 / 阈值留实施方案。
19. 演化与版本管理
这一节回答：配置放哪、契约 / 资产怎么演化、感知版图怎么逐步长大。
配置驱动（不冻结值）
环境差异、依赖地址、Provider Key、调度频率、重试 / 超时 / 限额阈值、重要度分层等目标全部走配置。现行仍有硬编码待迁移（如 monitor_job.go 的 1h / 2h / 12h 阈值、push_log 的 retry_count<3、cron @every 60s），是第二十四节风险 / 演化任务：
- 服务级配置：go-zero
etc/*.yaml（环境 / 依赖 / 端口等）； - 模型 / Provider 配置：
dn_llm_provider/dn_llm_config（多 Provider 可配）； - 重要度分层为战略可调参数（承接白皮书第四节之三，由项目负责人调整）。
契约与资产 schema 演化
- 消费方契约：输出协议 / 最小契约带版本，变更向后兼容（旧消费方不被破坏）；ATM 消费对象形态对齐后落版（第十六节、ADR-候选-03）。
- 资产 schema：六类信息资产与七维度可扩展（新增字段 / type 向后兼容）；状态机演化经 ADR 留痕（第十一、二十三节）。
- 能力域扩展：五能力域内新增接入源 / 处理能力 / 输出通道不改变对象模型主干。
感知版图演进路径
承接白皮书第四节之四的演进缺口序列（成熟态版图减当前覆盖，按「重要度 × 杠杆 × 差异化」排序）：
私域职业信号资产化（实时 + 可回测）→ 突发事件 / 新闻实时资产 → 宏观系统化 → 监管 / 公告与链上 → 各市场纵深 → 商品 / 外汇 / 债券 / 衍生品 → 结构化行情底座（按需、低优先）→ 深度多模态。
L3 架构应支撑沿此序列增量扩展感知覆盖，而非一次铺满（第二十二节缺口、第二十五节任务对应）。
向后兼容原则
契约 / schema / 状态机变更默认向后兼容；破坏性变更须经 ADR + 版本迁移，且不静默改变已交付资产语义。
第七部分 质量与验收
20. 测试体系
这一节回答：怎么验证系统真的做对了。承接 L2 第十二节验收五条。
分层测试策略
| 层 | 验什么 | 现行 / 缺口 |
|---|---|---|
| 单元 / 工具 | 清洗 / 解析 / 工具函数 | 现行 11 个 *_test.go，偏工具层（pkg/cleaner / pkg/llm provider 选择 / redislock / xprivacy 等）+ standardize JSON 解析 / 修复 + logic 配置序列化 |
| 主链路 | 接入 → 标准化 → 分发 → 推送 业务流 | 缺口（重）：internal/job/ 与 internal/agent/ 零 test，核心数据流无单元 / 集成测试（gap-map WP-P1-01、第二十二节） |
| 标准化质量 | 抽取成功 / 低置信 / 失败分类、质量抽样 | 缺口：无质量抽样评估（gap-map WP-P1-01、第十八节质量缺口） |
| 去重效果 | 重复识别 / 聚合 / 保留差异 | 缺口：去重效果未量化（gap-map WP-P1-01） |
| 输出契约 | 消费方最小契约（第十六节）+ 交付契约（幂等 / 状态 / 待补消费确认） | 缺口：契约测试待建（最小契约 WP-P1-02 / 交付契约 ADR-候选-04） |
| 端到端闭环 | 关键场景 S1–S8（第六 / 十节，承接 L2 第十五节之一）从接入到交付 | 缺口：系统性集成 / 端到端测试待补 |
质量样本与抽样
第一阶段须建标准化质量抽样（成功 / 低置信 / 失败 / 需复核），支撑第十八节质量观测与第二十一节反馈闭环；样本同时作为回归基线（可承接 DH-WP-001 S0 导出的生产脱敏样本）。抽样规模 / 标准留实施方案。
回归
状态机（第十一节）、输出契约（第十六节）变更须有回归：终态不可回退、契约向后兼容（第十九节）、不静默改变已交付资产语义。
验收对应
测试覆盖映射 L2 第十二节五条最低验收（闭环可运行 / 资产可追溯 / 输出可消费 / 运营可干预 / 质量可评估）；不要求完美覆盖率，但五条须各有可执行验证。现行对此五条覆盖均不足（主链路 / 契约 / 反馈 / 质量抽样皆缺口），是第二十二节缺口与第二十八节任务的测试债。具体框架 / 命令留工程包。
21. 质量与反馈闭环
这一节回答：消费结果怎么回流、怎么让感知质量越用越好。这是 Data Horizon 的「质量 + 反馈」环，在生态闭环中处于 FinBayes「评估闭环」的相邻位置，但内容是感知质量与消费反馈，不是认知评估（不替代 FinBayes 的认知评估体系）。
闭环目标
把下游消费结果回流为对来源 / 处理 / 资产质量的判断，驱动改进（承接 L2 第十五节之一反馈回流场景 S5、第九节之三结果可反馈）：
反馈来源与现行缺口
| 反馈 | 现行 | 缺口 |
|---|---|---|
| 消费确认 / 使用结果 | webhook 仅返回传输层 received | 无业务消费确认 / 无反馈落库（第十六节、gap-map WP-P1-03） |
| 内部质量证据 | dn_agent_execution / dn_llm_call_log / dn_push_log | 未成统一质量视图 |
| 标准化质量 / 置信 | — | 无质量 / 置信字段与抽样（第十八、二十节） |
第一阶段须补下游反馈落库 + 统一反馈视图（第十五节运行证据 vs 下游反馈落定），把「运行证据（内部）」与「消费反馈（外部）」经统一反馈口径汇入质量判断。注：上述三表为运行日志；dn_raw_news（status / repeat_news_id / std_cost_ms / last_err / image_analysis_status）是资产状态底座——统一质量视图须同时纳入资产状态，不止运行日志。
质量评估与治理
- 质量评估：标准化质量抽样（成功 / 低置信 / 失败）、去重效果、契约消费成功率（第十八、二十节）；
- 误报 / 低价值治理：高误报来源降权 / 暂停、低价值资产标记、死源退役（第十一节 Source 状态）；
- 反哺：质量判断回流到来源健康（第十一节）、处理路径（分层处理，第十三节）、资产质量标记（七维度）。
与 FinBayes 评估闭环的边界
Data Horizon 评估的是感知资产质量（准 / 全 / 新 / 可追溯）与消费满足度，不评估认知结论对错（认知与其评估归 FinBayes，不变量 1）。
第八部分 已知缺口与决策
22. 第一阶段缺口
这一节回答：架构落地前已知的坑在哪。汇总前面各节登记的缺口，承接 gap-map（感知覆盖 + 闭环 + 资产 + 横向能力差距）。
能力 / 闭环缺口
| 缺口 | 现状 | 出处 / 任务 |
|---|---|---|
| 消费确认 / 反馈落库 | webhook 仅返回 received，无业务确认、无反馈落库 | §16/§21、WP-P1-02 / WP-P1-03、ADR-候选-11 |
| 推送失败重试 | MaxRetryCount=3 无调用方、retry_count 恒 0、失败即终态 | §13/§16、WP-P1-02、ADR-候选-04 |
| 私域职业信号资产化 | 信号提炼 agent 层休眠；未区分职业信号 vs 一般 KOL | gap-map WP-P2-04、§6 S2 |
| 突发事件资产 | 未单列突发识别 / 时效 / 跨源互证 | WP-P1-04、§6 S1 |
| 标准化质量 / 置信 | 无质量 / 置信字段；抽取失败曾静默（已定矫正目标） | §13/§18、WP-P1-01 |
| 运营工作台 / 统一观测 | 底层记录散落，未成运营视图与输出控制面 | §9/§18、WP-P0-01/02/03 |
| 可观测最小指标口径未定 | 关键链路指标口径未定（指标 / 阈值留实施方案） | §18、ADR-候选-12 |
感知覆盖缺口（承接 gap-map 感知覆盖差距矩阵）
| 缺口 | 现状 | 任务 |
|---|---|---|
| 语言 / 板块覆盖偏置 | zh 偏多、加密为主，股票 / 外汇 / 商品 / 债券稀疏；多死源 | WP-P0-02 / WP-MACRO-01 |
| 宏观系统化 | 宏观 / 另类源以新闻行入库、未系统化 | WP-MACRO-01 |
| 结构化行情底座 | 无结构化行情表（按需、低优先） | WP-P3-01 |
| 另类数据资产化 | 卫星 / 海事 / 灾害等采集痕迹未资产化 | WP-ALT-01（后置） |
安全 / 工程缺口
| 缺口 | 现状 | 出处 |
|---|---|---|
| 明文凭证 | etc/*.yaml 含明文 Bot token / API Key / JWT secret | §17/§24、ADR-候选-10（已派生安全任务） |
| 私域授权模型 | 来源表无授权 / 适用限制维度 | §17、WP-P2-01、ADR-候选-02 |
| 细粒度权限隔离 | MCP 仅校验 Key / 状态 / 限额，无资产级隔离 | §17、WP-P2-01 |
| 主链路 / 契约 / 端到端测试 | server/internal/job/ 与 server/internal/agent/ 零测试；契约 / 端到端测试待建 | §20、WP-P1-01 / WP-P1-02、ADR-候选-04 |
| 配置硬编码 | monitor 1h/2h、retry<3、@every 60s 硬编码 | §19/§24、ADR-候选-10 |
| 部署形态待决 | 单进程优先 vs 多服务拆分未定；单实例故障域大 | §8/§14/§24、ADR-候选-09 |
| 标准化事件存储漂移 | dn_event_news_std 停写（CLAUDE.md 仍述活跃） | §4/§15/§24 |
缺口按「重要度 × 杠杆 × 差异化」进入第二十五节任务对应；不在本节排期。
23. 架构决策索引
这一节回答：起代码前必须先有结论的架构决策有哪些。承接 L2 第十五节之五八条 ADR 候选（01–08）+ 本文评审新增（09–12）共 12 条。「高」= L3 起稿 / 起代码前需先有决策。
| 候选 | 决策点 | 优先级 | 状态 |
|---|---|---|---|
| ADR-候选-01 | 突发事件识别口径与时效边界 | 高 | 待起草 |
| ADR-候选-02 | 私域授权模型（授权 / 适用限制 / 输出限制，落字段还是独立表） | 高 | 待起草 |
| ADR-候选-03 | AI Trading Matrix 消费对象形态 | 高 | proposed（待与 Trading Matrix 对齐，不冻结） |
| ADR-候选-04 | 输出交付幂等 / 重试 / 回放（交付生命周期与传输语义） | 高 | 待起草 |
| ADR-候选-05 | 人工复核触发条件（高价值 / 低置信 / 异常） | 中 | 待起草 |
| ADR-候选-06 | 成本分层处理路径（规则 / 小模型 / 大模型 / 人工） | 中 | 待起草 |
| ADR-候选-07 | 结构化行情按需接入策略 | 低 | 待起草（或并入边界不变量） |
| ADR-候选-08 | 信息资产存储切分（六子类各表 vs 单表 + type） | 高 | 待起草 |
| ADR-候选-09 | 部署形态（单进程优先 vs 多服务拆分） | 中 | 待起草（§8/§14/§24） |
| ADR-候选-10 | 密钥与配置迁移（明文凭证 → 密钥管理；硬编码 → 配置） | 高 | 待起草（§17/§19/§24） |
| ADR-候选-11 | 下游反馈对象 / schema / 存储（与 ADR-04 分管：04 管交付传输、11 管反馈落库） | 高 | 待起草（§16/§21） |
| ADR-候选-12 | 可观测最小指标口径 | 中 | 待起草（§18） |
ADR-候选-01 / 05 / 06 在 L3 应进一步拆「决策点 + 取舍方案」；正式 ADR 落 governance / decisions，本表为索引。边界不变量（第二节）作为各 ADR 的共同约束基线。
24. 风险登记
这一节回答：架构层已知风险与缓解方向。证据来自三源事实底图与本文各节。
| 风险 | 影响 | 缓解方向 |
|---|---|---|
明文凭证：etc/*.yaml 含明文 Bot token / API Key / JWT secret | 凭证泄露 / 被滥用（高） | 迁环境变量 / 密钥管理 + 轮换已暴露凭证（ADR-候选-10，已派生安全任务） |
主链路零测试：internal/job/ / internal/agent/ 无测试 | 核心数据流回归无保护、改动易破坏（高） | 补主链路单元 / 集成测试（§20、WP-P1-01） |
文档↔运行漂移：CLAUDE.md 述 dn_event_news_std 活跃，实际停写 | 误导工程决策（中，本文已矫正） | 以实际代码 / fact-map 为准，更新 CLAUDE.md |
| 智能分析层休眠：仅 3 个转发 agent 启用，信号提炼 agent 停用 | 差异化主线（私域职业信号）未真正运行（中） | 唤醒 + 矫正信号链路（WP-P2-04） |
| AI Trading Matrix 实收低：现行下游机器消费占比极低 | P1 主线「机器可消费闭环」未坐实（中） | 与 TM 对齐消费契约（ADR-候选-03）+ 消费反馈（§21） |
| 覆盖偏置：zh / 加密为主，多市场稀疏、多死源 | 感知版图与成熟态差距大（中） | 矫正覆盖偏置 + 宏观系统化（WP-P0-02 / WP-MACRO-01） |
| 标准化静默失败：抽取失败曾 continue-without-result、无质量标记 | 低质资产混入「可用」（中，已定矫正目标） | 失败置标记 + 独立质量字段（§13、不变量 6） |
| 私域越权输出：来源表无授权 / 适用限制维度，受限资产可能越权对外输出 | 合规风险（中） | 补私域授权模型 + 输出前校验（§17、WP-P2-01、ADR-候选-02） |
| 去重无兜底：Weaviate 不可用时静默放行 | 重复污染下游（中） | 规则去重兜底 + 标记（§13、WP-P1-01） |
| 单实例故障域：单进程 + 单实例依赖 | 故障影响面大（中） | 降级路径（§13）+ 按需拆分（ADR-候选-09） |
| 配置硬编码：阈值 / 频率写死在代码 | 难调优 / 难适配环境（低） | 配置化迁移（§19、ADR-候选-10） |
风险随实施推进在工作流 / governance 持续维护；高风险（明文凭证、主链路零测试）应在 M0 前处置。
第九部分 落地映射
25. 与里程碑 / 任务的对应
这一节回答：架构落到哪些任务包、M0 先做什么。承接 gap-map 第八节任务包与 implementation 路线图。
架构 → 任务包映射
| 架构子系统 / 缺口 | 任务包 | 相关 ADR / 节 |
|---|---|---|
| 运营管理子系统（工作台 / 输出控制 / 来源健康） | WP-P0-01 / 02 / 03 | §9/§18、ADR-候选-12 |
| 输出子系统（事件 / 信号对象、契约、交付证据） | WP-P1-01 / 02 / 03 | §16、ADR-候选-04/11 |
| 突发事件资产（实时主链路） | WP-P1-04 | §6 S1、ADR-候选-01 |
| 私域职业信号资产化 + 授权边界 | WP-P2-04 / WP-P2-01 | §6 S2/§17、ADR-候选-02 |
| 宏观系统化 / 历史行情 / 另类数据 | WP-MACRO-01 / WP-P3-01 / WP-ALT-01 | §22 感知覆盖、ADR-候选-07 |
| 密钥与配置迁移、主链路测试 | （新增工程债任务） | §17/§19/§20/§24、ADR-候选-10 |
M0 起点
第一阶段 M0 优先（承接 §3 技术取向、§24 高风险「M0 前处置」）：
- 工程债先行：明文凭证迁密钥管理 + 主链路测试补齐（§24 两条高风险）；
- P0 运营控制面：WP-P0-01/02/03 工作台 + 输出控制 + 来源健康（所有闭环前提）；
- P1 / 差异化主线契约：突发事件资产 + 私域职业信号资产化的对象与输出契约（WP-P1-04 / WP-P2-04），ATM 消费形态与 Trading Matrix 对齐（ADR-候选-03）；
- 首发牵引：以 DH-WP-001（第二十八节）跑通一条真实业务闭环。
具体排期 / 里程碑拆分留 implementation 路线图，不在本节排期。
26. 审计点
这一节回答：哪些动作必须留下可追溯证据。承接状态不变量④「每个终态都应留运行证据」（第二节）。
| 审计点 | 必留证据 | 关联 |
|---|---|---|
| 授权变更 | 私域源授权 / 撤销 / 适用限制变更 + 操作人 | §17、不变量 3 |
| 人工复核 / 干预 | 复核 / 纠错 / 暂停 / 阻断 / 重试 + 操作人 + 前后状态 | §9.5、sys_operation_log |
| 输出控制 | 阻断 / 放行决定 + 依据（授权 / 质量 / 复核） | §6 S8、§16 |
| 交付与消费确认 | 交付状态、幂等键、（待补）消费确认 / 反馈 | §16/§21、dn_push_log |
| 资产终态 | 已标准化 / 丢弃 / 失败 / 已归档 / 已撤回 + 原因 | §11、不变量① |
| 成本 | LLM / 翻译调用 token / 字符 / 耗时 | §18、dn_llm_call_log / dn_translate_call_log |
审计证据经 Feedback / Evidence 对象与运行证据存储留存（第十五节）；保留期 / 不可篡改性留工程包。审计点同时是 L2 第十二节验收「资产可追溯」与本文第二十一节质量闭环的证据来源。
27. 代码仓位置映射
这一节回答：架构组件落在现行代码哪里。便于「拿文档找代码、拿代码找文档」。仓库
data-horizon/server/。
子系统 ↔ 代码
| 子系统 / 组件 | 现行代码位置 |
|---|---|
| 接入（采集） | internal/job/scraper_*_job.go（多源）；internal/job/sync_tg_topic_job.go |
| 处理（标准化） | internal/job/standardize_job.go、internal/standardize/；Agent 族 internal/agent/（analyst / social / forward） |
| 处理（分发） | internal/job/raw_news_job.go（AgentTask + DirectPushTask） |
| 输出（推送） | internal/job/push_message_job.go；Open API internal/logic/open/；Webhook internal/logic/webhook/ |
| 资产库与检索 | internal/model/mysql/（dn_* 表）；去重 Weaviate 客户端 |
| 运营管理（控制面） | console / 后台（sys_* 权限、sys_operation_log） |
| 监控告警 | internal/job/monitor_job.go（来源静默告警） |
| 调度 | internal/job/cron_manager.go |
概念对象 ↔ 表
承接第四节桥接表：信息来源 → dn_crawler_source / dn_kol；原始信息 / 标准化记录 → dn_raw_news（+ dn_raw_news_direct / dn_raw_news_history）；交付记录 → dn_push_log；消费方 → dn_subscriber；反馈与运行证据 → dn_agent_execution / dn_llm_call_log / dn_translate_call_log。
漂移登记（以代码 / fact-map 为准，非 CLAUDE.md）
dn_event_news_std已停写（CLAUDE.md 仍述活跃，第二十四节风险）；- CLAUDE.md 述
agent_job.go/news_std_agent.go，实际为raw_news_job.go+ analyst/social/forward agent； - 现行频率 / 阈值为代码硬编码（第十九节，待配置化）。
本表为索引；精确文件 / 行号随代码演化在工作流维护。
28. 首个工程包（附录）
这一节回答：M0 用哪个真实任务包牵引落地。
DH-WP-001 — AI Trading Matrix 信源候选与样本交付（承接 implementation 的 dh-wp-001-trading-matrix-source-candidate/）：以「向 Trading Matrix 交付信源候选 + 脱敏样本」这条真实业务，跑通第一条端到端闭环。
为什么它适合首发：
- 贯穿主链路：接入 → 标准化 → 资产 → 输出（验证第八–十节子系统与场景流转）；
- 牵引差异化主线：信源候选含私域职业信号源（第六节 S2），直接对接 ATM 消费需求（与 ADR-候选-03 对齐联动）；
- 脱敏交付：经
server/pkg/xprivacy脱敏（呼应第十七节边界），样本可对外； - 可度量：交付样本数、信源覆盖、消费反馈构成首个可观测闭环（第十八、二十一节）。
DH-WP-001 的工程设计（schema / 接口 / 任务调度 / 验收命令）在其任务包目录内承接，不在本文展开。后续 P0/P1 任务包按第二十五节映射，以 DH-WP-001 的经验逐个下推。
29. 感知能力前沿承接
这一节回答：白皮书提出的「AI 时代感知能力前沿」在架构里落在哪、还差什么。承接战略白皮书第四节之二，确保这些差异化能力不在工程化中丢失。
逐条对应白皮书第四节之二的六条前沿能力：
| 感知前沿能力（白皮书第四节之二） | 架构承接 | 现状 / 缺口 |
|---|---|---|
| ① 海量 / 多语种 / 多模态 / 非结构化纳入同一实时感知链路 + 标准化 | 多源 scraper + standardize 管线（§8/§27）；图像分析 | 仅图像（深度多模态后置，白皮书 §4.3 第三层）；语言 / 板块覆盖偏置待补（§22） |
| ② 跨源去重 / 印证 / 事件聚合 / 时间线重建 | 去重（Weaviate）+ 跨源互证（§9.2/§12）；N 原始信息 → 1 标准化记录聚合（§4/§10）；双时间戳（§15） | 去重无兜底；事件级合成 / 时间线待补 |
| ③ 低密度高价值信号提取 | 私域职业信号资产化（§6 S2、WP-P2-04） | 信号提炼层休眠，待唤醒 |
| ④ 结构化 ↔ 叙事关联（看到价格也知为何） | 行情（按需）与事件 / 信号关联（§5/§15） | 行情底座缺、关联待建 |
| ⑤ AIGC 可追溯 / 质量标记 | 质量 / 置信标记 + 来源可信度（§13/§18） | 质量 / 置信字段缺，待补 |
| ⑥ 资产持续可溯源 / 可复核 / 可复用 | 七维度强制（§15）+ 审计点（§26）+ L2 第十二节验收「资产可追溯」 | 七维度部分字段（质量 / 反馈）缺，待补 |
边界：以上均属事实层聚合（对齐 / 去重 / 关联 / 标记），不越界到解释层结论（认知归 FinBayes，不变量 1）。这些能力按第十九节演进路径增量建设，是 Data Horizon 相对「商品化数据路由」的差异化所在——L3 架构为它们预留对象、状态与扩展位，不在第一阶段全部实现，但不得在工程化中被悄悄丢弃。
L3 正文（§1–§29）完。 收尾见工作流：双路总评审 + ADR 落盘 + 复盘 + playbook 反馈。
Changelog / 演化记录
2026-06-01：创建 L3 系统架构骨架（对标 FinBayes 架构 29 节 9 部分，适配 Data Horizon 感知/资产语义），承接 L2 第十五节 L3 承接补强。立架阶段，各节为「职责 + 承接来源 + 待主笔」骨架，经结构 Gate 后分部主笔。