第四节 — 业务对象与关系
这一节回答：FinBayes 业务里有哪些 first-class 概念，它们之间什么关系。
概览
FinBayes 业务层识别 7 个 first-class 概念。它们是用户能感知、能操作、能引用的对象。工程实现按这些概念组织数据模型与接口。
| 对象 | 工程英文名 | 是什么 |
|---|---|---|
| Fin Object 金融对象 | FinObject | 用户关注的金融对象，可以是单一标的 / 板块 / 主题 / 事件 / 政策 / 组合 / 叙事 / 关键人物中的任意一种或组合 |
| Watchlist 关注列表 | Watchlist | 用户组织 Fin Object 的列表机制，便于持续追踪 |
| Session 会话 | Session | 一次对话或任务上下文容器，承载多轮交互 |
| Task 金融认知任务 | Task | 用户的自然语言提问被识别为的具体任务，按产品定义文档当前定义的任务类型清单识别。一个输入可能触发多个并发任务 |
| 认知结果 | StructuredCognitionResult | Task 的输出，包含按任务类型组合的认知要素 |
| Judgment Record 判断记录 | JudgmentRecord | 用户在某时刻对某 Fin Object 形成的判断的可复盘记录，含成立条件 / 失效条件 / 反方证据等 |
| 动态画像 | DynamicProfile | 用户在持续使用中表现出的认知偏好、表达密度、关注模式，用户保有查看 / 修改 / 清空控制权 |
工程英文名是 Pydantic 模型 / SQLite 表名 / 代码模块名的统一约定，后续章节（§9 / §11 / §15 / §27）按这套英文名引用。中文名仅用于用户可见输出与本架构文档正文。
关系图
这张图表达什么：用户拥有动态画像（每用户一份）、维护任意多个 Watchlist、发起任意多个 Session。Watchlist 包含 Fin Object。Session 承载 Task。Task 围绕 Fin Object 并产出认知结果。认知结果经用户确认后可成为 Judgment Record。Judgment Record 针对具体 Fin Object，并能形成复盘链（用户后续更新或矫正旧判断时）。
这张图特意不表达什么：模块级实现细节（如 TaskGroup 是 Task 的并发容器、EvidencePacket 是证据单元等工程对象）、字段级数据结构、状态写入路径（候选 → 已确认等工程细节）、各对象的数量基数（一对多 / 多对多等）—— 这些在系统全景与系统运行章节展开。
怎么读这张图：实线箭头是直接关系（"用户维护 Watchlist"），虚线箭头是条件关系（"认知结果用户确认后可成为 Judgment Record"），Judgment Record 自环表示"复盘链"是同一对象内部的版本关系（旧判断 → 新判断）。
各对象的关键属性与生命周期
Fin Object
是用户关注的金融对象。可以是以下任意一种或组合：
- 标的（单一资产，如 BTC / ETH / NVDA / AAPL）
- 板块 / 行业（如半导体、Layer1、AI 概念股）
- 跨标的主题（如降息、AI 浪潮、稳定币监管）
- 用户自定义组合（如 BTC vs ETH 对比组合、自选股组合）
- 单次重要市场事件（如财报、FOMC、链上 hack、协议升级）
- 政策 / 宏观变量（利率、通胀、监管动向）
- 影响市场叙事的关键人物（KOL、机构、央行）
- 市场叙事（如 AI、降息、ETF、监管、链上周期等当前主导的故事线）
Fin Object 是 FinBayes 一切金融判断的承载体——用户的关注、历史判断、反方证据、成立条件、失效条件、复盘记录都围绕 Fin Object 组织。
Watchlist
用户主动维护的 Fin Object 集合。加入 Watchlist 是用户对该 Fin Object 表达持续关注的承诺。Watchlist 支持：
- 任意类型 Fin Object 加入（不限于"标的"，可加事件 / 主题 / 政策 / 关键人物等）
- 分组、排序、按 Fin Object 设置不同的关注密度与复盘节奏
- 与历史判断和复盘记录联动：市场变化触及用户判断时，FinBayes 围绕 Watchlist 内对象触发主动信号
Session
一次对话或任务上下文容器。FinBayes 支持：
- 默认会话：首次使用无需创建，降低首次使用门槛
- 命名会话：用户主动创建用于不同意图 / 场景 / 关注对象
- 跨会话持续状态：Judgment Record、Watchlist、动态画像 跨会话持有
Session 的生命周期：创建 → 活跃中 → 上下文超额时压缩 → 归档 → 可恢复 → 删除。具体状态机在状态对象生命周期章节展开。
Task
用户的自然语言提问被识别为的具体任务。任务类型清单由产品定义文档定义。第一阶段含以下类型（未来可能扩展或细分，工程实现按注册表查找而非硬编码 if-else 分支）：
- 解释类：金融概念 / 机制 / 现象的解释
- 分析类：围绕事件 / 数据 / 变化展开认知组织
- 比较类：多个 Fin Object 的维度化对比
- 复盘类：触发历史判断的成立条件 / 当前变化 / 是否仍成立
- 风险识别类：主动识别下行风险 / 反方 / 盲点
- 交易准备类：交易前的条件 / 风险 / 反方 / 失效边界检查
- 交易决策辅助：聚焦具体决策点的条件化判断
一个用户输入可能命中多个任务（如"NVDA 财报后我的判断要不要更新 + 现在该不该加仓"是复盘 + 交易准备的组合）。多任务的并发组织由工程层的 TaskGroup 承接（详见系统全景章节）。
自然语言到任务的识别策略（规则 / LLM / 混合 / 其他）是关键架构决策，留待 ADR-004 任务识别策略 定（详见 status.md OQ-003）。
认知结果
Task 的输出。按任务类型组合产品定义文档定义的认知要素：
- 结论 / 倾向（条件化）
- 依据
- 多视角
- 反方证据
- 成立条件
- 失效条件
- 不确定性 / 信息缺口
- 来源与时间戳
- 可继续追问项
- 历史判断链接（与用户已有 Judgment Record 的关系）
不固化字段表，按任务类型动态组合。具体哪个任务类型组合哪些要素由综合层章节展开。
Judgment Record
用户在某时刻对某 Fin Object 形成的判断的可复盘记录。是 FinBayes 持续认知能力的关键载体。每条 Judgment Record 包含：
- 时间戳与所属 Session
- 涉及的 Fin Object
- 用户判断方向 / 倾向
- 支持理由 + 反方证据（FinBayes 主动提的 + 用户接受的）
- 成立条件与失效条件
- 不确定性 / 信息缺口
- 复盘记录链（之后的更新 / 矫正）
Judgment Record 是独立的可被检索、复查、引用的认知资产，与聊天记录区分。生命周期：候选生成 → 用户确认 → 已确认 → 市场变化触及成立 / 失效条件时主动信号触发复盘 → 更新链。详见状态对象生命周期章节。
动态画像
FinBayes 在用户使用和交互过程中静默构建的用户画像。画像在用户持续使用中逐步完善，是 FinBayes "越来越懂用户" 的基础。
画像包含 (但不限于)：
- 用户当前阶段的风险偏好
- 关注模式（关注密度、复盘节奏、对新信息的敏感度）
- 关注的市场与标的范围
- 任务类型偏好（更常做分析 / 复盘 / 交易准备 / 等）
- 表达密度偏好（专业术语 vs 解释性语言）
动态画像不影响 FinBayes 输出质量的标准——反方证据 / 关键风险 / 失效条件等核心认知要素的呈现不会因画像被裁剪。画像主要影响两件事：
- 意图识别的精准度：同一句用户表达在不同用户身上可能对应不同任务类型（例如"还能追吗"在常做交易准备的用户与常做风险扫描的用户身上有不同的隐含意图）
- 输出内容范围匹配用户期望：在某个 Fin Object 上展开的深度、关注哪些细节、表达密度等会按画像调整（但核心认知要素的覆盖度不变）
用户对画像保有查看、修改、清空的完整控制权（战略层不变量，详见上位继承与不变量章节）。
不在这一章的对象
下列对象是工程层实现细节，在系统全景 / 系统运行章节展开：
- TaskGroup：多任务并发的组织容器（用户感知"答案在分步流出"但不直接操作 TaskGroup）
- EvidencePlan / EvidencePacket：证据组织的内部结构
- State Candidate：待用户确认的状态写入
- Context Snapshot：长会话的上下文压缩快照
跨层对象映射（产品 → 架构 → 工程）
本章定义的 7 个 first-class 业务对象，在产品定义 / 主架构 / 状态机 / 持久化 / 模块路径 / M0 实现度的对应：
| 业务对象 | 产品定义 § | 工程英文名 | 持久化（§15） | 独立状态机（§11） | 模块路径（§27） | M0 实现 |
|---|---|---|---|---|---|---|
| Fin Object | §3.1 | FinObject | fin_objects 表 | 无（仅 created/archived 标记） | state/fin_object.py | ✅ implement |
| Watchlist | §3.2 | Watchlist | watchlist_objects 表 | 无（由 StateCandidate 承载） | state/watchlist.py | ❌ M1+ |
| Session | §3.3 | Session | sessions 表 | ✅ 有 | state/session.py | ✅ implement（默认 Session 兜底） |
| Task | （工程派生） | Task | 仅审计 trail（内存对象） | ✅ 有 | orchestration/task.py | ✅ implement |
| 认知结果 | §7 | StructuredCognitionResult | 仅审计 trail | 无 | cognition/types.py | ✅ implement（M0 综合层输出契约） |
| Judgment Record | §3.4 | JudgmentRecord | judgment_records 表 | ✅ 有 | state/judgment.py | ❌ M1+ |
| 动态画像 | §3.5 | DynamicProfile | dynamic_profiles 表 | 无 | state/profile.py | ❌ M1+ |
派生的工程对象（不是 first-class 业务对象但有独立状态机或承载关键职责）：
| 工程对象 | 独立状态机（§11） | 模块路径（§27） | M0 实现 |
|---|---|---|---|
| TaskGroup | ✅ 有 | orchestration/task_group.py | ⚠️ stub（M0 仅单任务） |
| StateCandidate | ✅ 有 | state/candidate.py | ⚠️ stub |
| Provider Readiness | ✅ 有 | providers/readiness.py | ✅ implement |
| AuditEvent | 无 | state/audit.py | ✅ implement |
阅读约定：
- 用户视角看到的是"业务对象"（产品定义 §3）—— 5 类核心 + 隐式的 Task / 认知结果
- 工程视角看到的是"业务对象 + 派生工程对象"（架构 §4 + §11） —— 7 first-class + 4 派生
- 持久化 / 状态机 / 模块路径只是工程视角的不同 view，不引入新对象
- M0 阶段实施按"M0 实现"列，详见 M0 走通骨架工程包 §2 接口子集表