Data Horizon 现有系统与战略映射图
版本：2026-05-26
用途：为战略白皮书、system-product-definition.md、现实差距分析和逐项评估提供一份“当前真实能力映射图”
边界：本文不是产品定义、不是路线图、不是研发 current-state 报告，也不把当前实现视为目标形态
图 1：本文把已运行系统事实、战略白皮书和后续定义工作连接起来，作为事实校准层，而不是目标产品形态。
1. 文档定位
Data Horizon 在 FinTec AI Ecosystem 中的定位，是面向外部信息世界的感知层：持续采集市场、宏观、产业、社交和新闻信号，将结构化、半结构化和非结构化金融信息转化为可消费、可追踪、可分发的标准化信息资产，并向数据视界管理系统、FinBayes、AI Trading Matrix、Telegram、人类运营界面和机器接口供给。
本文只回答一个问题：
当前 Data Horizon 已经具备哪些可被战略和系统 / 产品定义复用的系统事实，以及哪些地方还只是工程实现、历史遗留或未经验证的假设。
因此，本文刻意不从代码文件、数据库表、任务名出发，而从系统能力、对象、边界、流程和评估问题出发。工程证据只放在附录中，用来校验事实来源。
2. 一句话结论
Data Horizon 当前已经不是一个单纯的“新闻爬虫”或“推送脚本”。它已经形成了一个可运行的感知管线雏形：
但它还没有自然长成一套完整产品定义。当前最适合被保留的是“感知管线、标准化能力、分发机制、运营控制面和机器接口”的系统骨架；最需要谨慎的是“把现有字段、旧文档链路或当前菜单直接上升为正式产品对象”。
3. 与战略白皮书的关系
战略白皮书应回答 Data Horizon 为什么存在、服务哪个生态位置、长期要成为什么。本文回答的是：当前工程事实能支撑白皮书里的哪些主张，哪些主张还缺证据。
图 2：本文承接战略白皮书，并为系统 / 产品定义和逐项评估提供可校验的输入。
映射时建议遵守三条规则：
- 战略语言不能直接替代系统对象定义。
- 当前实现可以作为证据，但不能自动成为目标形态。
- 旧文档和历史任务记录只能作为来源线索，不能覆盖当前真实链路。
图 3：Step 0.5 的职责，是把战略、共识和工程事实校准为 system-product-definition.md 可使用的事实输入；它不直接冻结 API、schema、菜单或实施任务。
4. 当前系统边界
Data Horizon 当前可被理解为五层系统。这里的“五层”是从已运行链路观察当前系统，不等同于战略白皮书中的“五大能力域”。
图 4：当前系统已经形成从信息接入、标准化、Agent 路由到交付分发的骨架；运营控制和运行证据是后续定义与评估的重要支撑。
当前最清晰的边界是：
| 层级 | 当前已有事实 | 不应过早声明 |
|---|---|---|
| 信息源层 | 已接入多类新闻、Telegram、RSS、宏观和市场相关来源 | 来源覆盖已经足够完整 |
| 采集与接入层 | 已有周期性采集和入库机制 | 所有采集器都稳定生产 |
| 标准化层 | 已有清洗、翻译、去重、LLM 辅助结构化能力 | 标准化质量已经达到产品级 |
| 决策与分发层 | 已有 Agent、订阅、直推和推送记录 | 已形成最终策略决策引擎 |
| 消费与反馈层 | 已有 Telegram、Webhook、Trading Matrix、Open API 和控制台面 | 已有完整闭环反馈和归因体系 |
4.1 与五大能力域的对应关系
战略白皮书中的五大能力域是能力地图，不是业务流、团队边界或部署边界。真实业务闭环可以跨多个能力域一体化完成。
| 战略能力域 | 当前事实组 | 对 Step 1 的定义问题 |
|---|---|---|
| 信息接入域 | 信息源层、采集与接入层、来源感知 | 哪些公开源、私域源、API / MCP / SDK、历史数据包应纳入第一阶段边界 |
| 信息处理域 | 标准化层、感知处理、Agent 与路由 | 哪些处理由规则完成，哪些由本地模型或通用大模型完成，哪些需要人工复核 |
| 信息资产域 | Raw Signal、Perception Record、Operating Evidence | 什么对象可以被称为金融感知资产，需要携带哪些证据、状态、质量和可检索属性 |
| 资产输出域 | 交付分发、机器接口、Delivery Artifact | 第一阶段输出先服务谁，以什么契约输出，如何证明被消费和产生价值 |
| 运营管理域 | 数据视界管理系统、运行证据、配置与干预点 | 内部团队如何配置、观察、复核、干预、告警和控制输出 |
5. 系统能力地图
从当前实现观察，系统能力可以分成六组。这是“当前实现能力组”，不是战略能力域；它用于帮助五大能力域找到现有事实锚点。
这张图的含义不是“这些能力已经完美”，而是“这些能力已经有可被评估和复用的系统位置”。
| 能力组 | 当前可确认的含义 | 对 Step 1 的价值 |
|---|---|---|
| 来源感知 | 系统已经能把多类外部信息源纳入采集范围 | 帮助定义第一阶段要服务哪些信息域和来源边界 |
| 感知处理 | 系统已经具备从原始信息到标准化信息的处理链 | 帮助定义核心输出资产和质量要求 |
| Agent 与路由 | 系统已经有按配置处理、订阅和分发的机制 | 帮助判断 Agent 是产品对象、处理单元还是内部路由能力 |
| 交付分发 | 系统已经能向人和下游系统输出结果并留下记录 | 帮助定义消费者、交付契约和第一阶段产品形态 |
| 数据视界管理系统 | 系统已经有人类可操作的管理界面雏形 | 帮助定义运营角色、内部工作流和人工干预点 |
| 机器接口 | 系统已经有面向机器消费的信息查询面 | 帮助定义 API/feed/search 等机器消费产品边界 |
6. 当前核心对象
为了后续系统 / 产品定义，建议先使用概念对象，而不是直接沿用当前工程命名。
| 概念对象 | 当前含义 | 后续定义重点 |
|---|---|---|
| Source | 信息来源、采集入口、KOL、RSS、API 或外部数据源 | 来源可靠性、覆盖范围、权限、成本、健康度 |
| Raw Signal | 未完成标准化的原始信息材料 | 原文、时间、来源、去重线索、采集上下文 |
| Perception Record | 已标准化的信息资产候选 | 摘要、分类、资产、语言、置信度、证据链 |
| Agent | 对信息进行转发、分析或筛选的处理单元 | 触发方式、可见性、订阅关系、输出责任 |
| Delivery Artifact | 面向人或机器的实际输出 | 目标、payload、状态、失败原因、重试策略 |
| Consumer | 下游消费方 | Trading Matrix、Telegram、人类运营、Open API 客户端 |
| Operating Evidence | 系统运行证据 | 延迟、成本、错误、重复、执行记录、质量反馈 |
当前数据库和代码里已经能看到这些对象的雏形，但对象命名、字段边界和产品语义仍需要后续正式定义。
7. 当前主流程
当前真实主流程可以概括为四段。
7.1 进入系统
系统从多个外部渠道采集信息，形成原始材料。当前这个阶段已经有周期性任务和多种 source 类型，但仍需要评估真实运行覆盖、成功率、重复率和失败恢复能力。
7.2 变成可理解的信息
原始材料会被清洗、翻译、去重，并通过规则或 LLM 辅助提取分类、关键词、相关资产和摘要。这个阶段是 Data Horizon 最重要的“感知能力”雏形，也是后续最应该做质量评估的地方。
7.3 决定谁需要它
标准化后的信息会进入 Agent、订阅或直推逻辑。当前已经具备“转发”和“分析”两类处理方向，但它们更像处理路径雏形，还不应直接等同正式产品中的智能体体系。
7.4 交付给消费者
系统能够向 Telegram、Webhook、Trading Matrix 和 Open API 消费方输出信息，并记录推送状态、错误和耗时。这给后续 delivery contract、SLA、失败补偿和消费反馈提供了基础。
8. 子系统构成
8.1 Source Operations
负责把外部世界纳入系统可管理范围。它不仅是“爬虫”，还包括 source 注册、启停、分类、Topic/KOL 管理和后续 source reliability 的入口。
8.2 Perception Processing
负责把原始信息变成可消费的信息资产。它是 Data Horizon 区别于普通信息抓取系统的核心层，需要被正式定义为质量、证据、成本和可追踪性的综合能力。
8.3 Agent & Routing
负责决定信息如何被处理和送往哪里。当前已经有 Agent 和订阅/直推机制，但后续需要明确 Agent 是运营配置、分析能力、规则路由，还是更完整的产品对象。
8.4 Delivery Hub
负责输出给不同消费者，并留下交付证据。它是连接 Trading Matrix、Telegram 和外部 API 消费方的现实接口层。
8.5 Data Horizon / 数据视界管理系统
负责让人能配置、观察、复核、干预和控制输出。它是第一阶段最需要优先满足的内部产品形态，不只是普通后台页面集合。当前控制台能力已经覆盖多个管理面，但还需要按实际用户工作流重新组织，而不是简单继承工程菜单。
8.6 Machine Interface
负责让机器消费 Data Horizon 的标准化信息。当前接口可以作为候选，但正式系统 / 产品定义需要明确权限、幂等、分页、过滤、语义版本和消费契约。
8.7 Operating Evidence
负责支撑系统可信度。当前已经有错误、耗时、执行和推送记录，但还不足以支撑“感知质量”“来源可靠性”“下游价值贡献”等高阶判断。
9. 战略能力映射
| 战略能力 | 当前事实基础 | 当前不足 | 后续评估问题 |
|---|---|---|---|
| 市场感知 | 多源采集和标准化管线已经存在 | 覆盖范围、时效、稳定性未充分量化 | 哪些 source 构成最小有效感知网络 |
| 信息结构化 | 已有翻译、去重、分类、摘要、资产识别 | 质量、置信度、失败样本缺评估 | 什么才算一个合格 Perception Record |
| 生态供给 | 已能向 TM、Telegram、Webhook、API 输出 | 消费契约和反馈闭环未固化 | 下游需要的是 feed、alert、signal 还是 evidence package |
| 人机协同运营 | 控制台已有配置与观察能力 | 工作流未按角色重组 | 运营者每天真正要完成哪些判断和动作 |
| Agent 化处理 | 已有转发和分析处理路径 | Agent 语义偏工程配置 | Agent 是产品角色、处理器、策略单元还是订阅规则 |
| 可追踪性 | 有执行、错误、耗时和推送记录 | provenance 与质量证据不完整 | 输出应携带哪些可解释证据 |
| RMF/反馈闭环 | 战略上需要与交易/风控反馈连接 | 当前证据不足 | 是否存在可回流的价值评估和归因数据 |
10. 第一阶段闭环事实映射
第一阶段不是从零建设，也不是把当前工程原样固化。它应围绕三类业务闭环校准已有基础、缺口和定义风险。
| 第一阶段闭环 | 当前事实基础 | 当前判断 | 对 system-product-definition.md 的影响 |
|---|---|---|---|
| 实时公开信息闭环 | 高频新闻 / RSS / TelegramRSS / 宏观与市场相关采集任务、标准化任务、分发任务、推送任务和 Open API 候选已经存在 | 当前事实基础最强，已经形成部分闭环；但覆盖、时效、去重、质量和反馈仍需量化 | 应定义公开金融信息资产、实时 / 准实时流、输出验证和运营复核方式 |
| 私域 / KOL 信息闭环 | Telegram、KOL、Topic、source 管理、KOL source 查询和部分私域来源处理能力已有雏形 | 当前已有部分基础，优先级高；但来源授权、证据保留、低密度高价值信息筛选和复核机制需要补证 | 应定义私域金融信号资产、权限 / 合规边界、复核责任和输出控制 |
| 历史市场数据闭环 | 已有市场相关采集候选和部分宏观 / 市场数据接入痕迹 | 当前不能声明完整闭环；交易所历史数据包导入、清洗、标准化入库、检索复用仍需单独补证 | 应作为第一阶段补齐目标之一，而不是作为已经完成的能力来写 |
三类闭环都不应被拆成彼此割裂的实施域。五大能力域用于定义能力地图，真实业务闭环可以在一个工作流里同时经过信息接入、信息处理、信息资产、资产输出和运营管理。
11. 系统/产品定义映射
后续系统 / 产品定义不宜从“已有菜单”开始，而应从使用者、任务、资产和系统边界开始。第一阶段建议先形成 system-product-definition.md：它同时承接产品侧的消费者、场景、价值和系统侧的对象、能力域、运行边界。若后续需要更细拆分，再从该文档下推独立的产品定义或系统定义。
11.1 可能的使用者
| 使用者 | 可能任务 | 当前支撑情况 |
|---|---|---|
| 数据视界运营人员 | 配置来源、观察处理状态、复核异常、干预关键结果、控制输出规则 | 有管理系统雏形，但工作流需重组，是第一阶段最优先的内部产品面 |
| FinBayes | 消费标准化信息、证据材料、事件材料和情绪 / 研报材料，支撑金融认知 | 战略消费方明确，当前直接消费契约需要补证 |
| Trading Matrix | 消费结构化信息，辅助策略或风险判断 | 有交付链路，消费契约需要补清 |
| 研究/分析人员 | 查看高价值事件、追踪资产和主题 | 有信息查询面，分析体验不足 |
| 机器客户端 | 搜索、拉取、订阅标准化信息 | 有 Open API 候选，协议需正式定义 |
| 生态管理者 | 判断系统覆盖、质量、成本和贡献 | 有运行证据碎片，缺仪表盘和指标体系 |
11.2 产品对象候选
正式系统 / 产品定义可以围绕这些对象展开，而不是围绕当前数据库表或后台页面展开。
12. 系统定义映射
system-product-definition.md 中的系统定义部分建议重点回答以下问题：
| 主题 | 需要定义 | 当前底图给出的线索 |
|---|---|---|
| 系统边界 | Data Horizon 负责到哪里，Trading Matrix 从哪里接手 | 当前有 TM 推送，但反馈边界不清 |
| 对象协议 | Source、Signal、Record、Agent、Delivery 的正式含义 | 当前已有对应实现雏形 |
| 状态机 | 信息从进入系统到交付完成的状态变化 | 当前已有原始信息状态和推送状态 |
| 消费契约 | 下游如何拉取、订阅、确认、回放 | 当前有 API 和 push，但契约未冻结 |
| 质量口径 | 去重、分类、摘要、资产识别如何验收 | 当前有能力，但缺样本评估 |
| 运营控制 | 人能在哪些环节干预、回滚、禁用、复核 | 当前有控制台，但工作流未抽象 |
| 可观测性 | 如何看 source、任务、LLM、推送、成本、错误 | 当前证据分散，需要指标化 |
13. 当前错位与矫正方向
| 错位 | 表现 | 矫正方向 |
|---|---|---|
| 把 Data Horizon 写成旧式新闻标准化链路 | 旧文档仍保留过时任务和旧表述 | 用“感知管线”替代旧任务链描述 |
| 把工程实现当成产品对象 | 直接使用表名、任务名、菜单名定义系统 | 先抽象 Source、Signal、Record、Delivery 等对象 |
| 把已有推送等同生态供给 | 能发出去不等于形成下游契约 | 补定义消费协议、失败补偿、反馈闭环 |
| 把 Agent 当成已经成熟的智能体体系 | 当前 Agent 更像处理和路由配置 | 明确 Agent 的产品语义和职责层级 |
| 把控制台当成产品体验 | 现有页面偏工程管理 | 从角色任务重组运营工作流 |
| 把 LLM 输出当成标准化质量 | 有 LLM 处理不代表质量可靠 | 建立抽样、置信度、失败分类和人工复核机制 |
14. 后续逐项评估框架
建议后续每个能力都用同一组标签评估：
| 标签 | 含义 |
|---|---|
| 保留 | 当前事实符合战略方向，可进入系统 / 产品定义 |
| 挑战 | 方向可能正确，但质量、边界、成本或价值需要证明 |
| 重构候选 | 职责正确，但表达、对象或接口不适合长期使用 |
| 废弃候选 | 与当前真实链路或战略方向冲突 |
| 补证 | 需要运行数据、样本、日志、用户反馈或下游证据 |
| 迁移治理 | 应进入正式战略/产品知识库，而非只留在工程仓库 |
评估顺序建议：
15. 需要补证的关键问题
| 问题 | 为什么重要 |
|---|---|
| 当前哪些 source 真正在稳定运行 | 决定“市场感知覆盖”是否成立 |
| 标准化结果质量如何 | 决定是否能上升为 Perception Record |
| 去重是否可靠 | 决定下游是否会被重复信息污染 |
| Trading Matrix 如何消费这些信息 | 决定 Data Horizon 是否真的形成生态供给 |
| Telegram / Webhook / API 消费者是谁 | 决定系统 / 产品定义中的用户和场景 |
| Agent 输出是否有明确价值 | 决定 Agent 是否应成为核心产品对象 |
| 运营人员如何使用控制台 | 决定控制台是内部工具还是产品界面 |
| 错误、成本、延迟如何被观察 | 决定系统是否具备生产级可信度 |
| 是否存在反馈和归因闭环 | 决定 Data Horizon 是否能从 feed 系统升级为 RMF 感知层 |
16. 承接关系
本文完成 Step 0.5 的现有系统映射校准职责后，后续工作应按以下顺序推进：
- 用本文承接正式战略白皮书，识别当前已有事实、缺口和决策问题。
- 基于战略白皮书、已收束共识和本文重建
system-product-definition.md，定义消费者、场景、输出资产、产品形态、五大能力域和第一阶段边界。 - 基于
system-product-definition.md和当前工程事实做现实差距分析，识别已有能力可承接、已有能力需矫正、空白能力需补齐。 - 对 source coverage、standardization quality、delivery contract、operator workflow、machine feed contract 分别做评估。
- 评估完成后再拆工程任务，避免让当前实现反向决定系统 / 产品形态。
进入 system-product-definition.md 前，本文应提供以下输入：
| 输入 | 本文应提供的状态 |
|---|---|
| 消费者与协同对象 | 数据视界运营人员、FinBayes、AI Trading Matrix、机器客户端和生态管理者的候选任务 |
| 三类业务闭环 | 实时公开信息、历史市场数据、私域 / KOL 信息的已有基础、缺口和优先级 |
| 五大能力域 | 信息接入、信息处理、信息资产、资产输出、运营管理与当前事实组的对应关系 |
| 管理系统优先级 | 数据视界管理系统作为第一阶段内部产品面，FinBayes / AI Trading Matrix 输出作为验证场景 |
| 暂不冻结项 | API、SDK、MCP、schema、菜单结构、Agent 语义和工程任务包 |
附录 A：工程证据锚点
以下只作为事实校验入口，不作为正文叙述中心。
| 主题 | 证据入口 |
|---|---|
| 当前运行任务注册 | server/internal/job/cron_manager.go |
| 标准化处理 | server/internal/job/standardize_job.go、server/internal/standardize/standardize.go |
| 分发与 Agent 处理 | server/internal/job/raw_news_job.go、server/internal/agent/ |
| 推送执行 | server/internal/job/push_message_job.go |
| 核心数据结构 | docs/sql/ |
| 后台与 Open API | server/api/ |
| 控制台路由 | web/src/router/routes/modules/datahorizon.ts |
| Python 采集候选 | python-service/ |
| 旧链路漂移来源 | README.md、AGENTS.md、CLAUDE.md、部分历史任务文档 |
Changelog / 演化记录
2026-05-26：认知层下游对象从 FinClaw 同步为 FinBayes，与 生态对象注册表 中 2026-05-24 完成的对象重命名对齐；生态自称由「Curvature 金融生态」校正为「FinTec AI Ecosystem」，与本仓统一术语一致；maturity 收敛为模板枚举 active。