功能架构
这一页讲 Trove 的功能与边界：产品有哪些功能块、分给谁用、 怎么串成一条链路、哪些事刻意不做。代码怎么分层在系统架构， 一次提问经过了哪些节点在查询工作流—— 本页不重复机制细节，只把功能说全、把边界划清。
两个界面，三种角色
Trove 对外只有两个界面：用户端（提问与读答案）与 管理台（治理与运营）。功能按角色投放—— 用户看到的数据源也已被两层授权筛过（数据源授权 + 主题域授权）， 只有「已连接且知识库已初始化」的数据源才可能出现。
管理台入口、生成时的 schema 枚举工具，都是按角色与档位挂载的：不具备就不出现，而不是出现了再被拦回来。服务端接口另有自己的鉴权（fail-closed）——两道门各自成立。
| 角色 | 在哪工作 | 能做什么 |
|---|---|---|
| 普通用户 | 用户端 | 提问；读答案的每一块（结论 / 结果表 / 图表 / 依据抽屉 / 归因分析卡）；会话管理与反馈；切换主题域 |
| 分析员 | 用户端 + 管理台（只读） | 普通用户的全部；管理台只读浏览（数据源、知识库、语义层、判定历史等）；生成时可用 schema 枚举工具（值确认 / 结构懒加载 / 执行计划）。不能改任何治理内容 |
| 管理员 | 管理台 | 数据源注册、知识库初始化 / 学习与确认、语义模型编辑与版本回滚、判定规则、订阅与定时任务、行动审批、Skills、记忆确认、主题域与授权、审计、系统设置与模型配置 |
功能块：四段链路，一层支撑
首页把 Trove 概括为一条链路——问数 · 分析 · 决策 · 行动。 落到功能上，每一段都有用户端形态与管理端配套。图 1 是功能分解（不是调用图）： 四段链路在上，一层横向支撑在下——支撑层不对应某一个环节， 而是所有环节共用的治理与沉淀。
flowchart TB
%% 配色 = 站点 token 的半透明版，与总览页同一套链路色（问数 indigo · 分析 teal ·
%% 决策 amber · 行动 violet · 外部 zinc 虚线）；半透明填充 + 实色描边，亮暗两档同源
subgraph chain["链路：问数 · 分析 · 决策 · 行动（终点在系统外）"]
direction LR
Q["问数<br/>提问 → 可核对的答案<br/>对话问答 · 可答边界<br/>扩展确认 · 元数据 · 澄清"]:::q
A["分析<br/>「为什么」的分解与检验<br/>归因卡 · 噪声带 · 来源四档"]:::a
D["决策<br/>算不算有问题，有多确定<br/>判定规则 · 历史对照 · 订阅<br/>因果升级梯 · What-if<br/>主动扫描 · 质量回评"]:::d
ACT["行动<br/>停在一份可审计的提案<br/>提案 · 审批 · 拉通道<br/>回执对账 · 效果验收"]:::act
EXT["外部系统<br/>执行与后果"]:::ext
Q --> A
A --> D
D --> ACT
ACT -.->|回执对账| D
ACT -.->|交付 / 回执| EXT
end
SUP["横向支撑（所有环节共用）<br/>知识库 · 语义模型 · 记忆 · Skills<br/>主题域 · 权限 · 审计 · 令牌 · 评测台<br/>人工确认的闸门贯穿全部"]:::sup
%% 带间不连线：跨带边会让带内 direction LR 失效（mermaid v11），支撑层用单节点绕开
chain ~~~ SUP
classDef q fill:#6366f11f,stroke:#6366f1,stroke-width:2px;
classDef a fill:#14b8a614,stroke:#14b8a699,stroke-width:1.5px;
classDef d fill:#f59e0b14,stroke:#f59e0b99,stroke-width:1.5px;
classDef act fill:#8b5cf614,stroke:#8b5cf699,stroke-width:1.5px;
classDef ext fill:transparent,stroke:#71717a80,stroke-width:1.5px,stroke-dasharray:4 4;
classDef sup fill:#71717a14,stroke:#71717a59,stroke-width:1px;
style chain fill:#71717a0d,stroke:#71717a2e,stroke-width:1px
linkStyle 3 stroke:#8b5cf6,stroke-width:1.5px
四段链路
| 段 | 功能块 | 界面 | 一分钟说明 |
|---|---|---|---|
| 问 数 |
对话问答 | 用户端 | 全管线：意图分流 → 生成与自校验 → 规则链校验 → 人话解释 + 依据抽屉（机制见查询工作流） |
| 可答边界 | 用户端 / 管理端 | 超出语义模型的声明范围时：结构性缺口（硬 MISS）拒绝并给扩展引导；词表 / 值 / 口径未声明（软 MISS）产出骨架照常作答，未解析部分由生成补齐 | |
| 模型扩展确认 | 管理端 | 被拒不是终点：LLM 草拟扩展（术语 / 枚举 / 口径）→ 管理员确认 → 自动重答原问 | |
| 元数据问答 | 用户端 | 「有哪些表 / 某字段是什么意思」走独立的解释与自校验回路 | |
| 澄清纠错 | 用户端 | 指代不明先反问（可选档）；纠错题在上一问的结果上直接出新答案 | |
| 分 析 |
归因分析卡 | 用户端 | 问「为什么」时多出的卡：总变化按已声明度量拆到主维度（瀑布图 + 维度贡献表 + 基期口径），附本次证据查询清单；不成时整卡不出现，绝不改变答案本身 |
| 分析面板 · 来源 | 用户端 | 答案旁可看它怎么一步步算出来；每条 SQL 标注四档来源之一——已认证复用 / 知识库复用 / 语义编译 / 模型生成 | |
| 决 策 |
判定规则 | 管理端 | 阈值规则声明在语义模型自己的词汇上（与语义查询同一个形状）；确定性引擎求值，零 LLM |
| 判定历史 | 管理端 | 每次触发留下版本、相邻两次对照；每条判定带 SQL 与原始行——证据可回放 | |
| 因果升级梯 | 管理端 | 声明 causal 的规则在噪声带之后逐级升级（相关 → 差中差 → 合成对照），每条假设带体检（通过 / 不通过 / 无法检验），过不去就停在上一级并说明——因果是附录，绝不改变触发结论 |
|
| What-if 重放 | 管理端 | 把最近一条判定留下的数字行灌进同一个 judge 纯函数当场重判：零业务库查询、显著性只重放不重算；规则被改过，结果自报「重放的是旧规则」 | |
| 主动扫描 | 管理端 | 反向的找问题：scan_spec（度量 × 维度 × top_k）扫出超出噪声带的异常按 |z| 排序，落草稿、确认后才成规则；可选的 LLM 假设层默认关 |
|
| 质量回评 | 管理端 | 按 (rule_id, rule_rev) 分桶看每条规则的四类结局与触发率；分母不够就明说「样本不足」，不给伪精度 |
|
| 报告订阅 | 管理端 | 按主题域订阅，结果主动找到人 | |
| 定时任务 | 管理端 | 判定 / 订阅 / 问数统一调度；不可求值的规则以错误上报，不静默 | |
| 行 动 |
行动提案 | 管理端 | 判定触发即生成提案：载荷创建即定稿、同一触发只提案一次 |
| 审批与总闸 | 管理端 | 两道门加一个总闸；谁批的、何时发的全程留痕 | |
| 拉通道交付 | 外部系统 | webhook 与 MCP 并列；对方回执回来对账 | |
| 效果验收 | 管理端 | 交付不是终点：按约定窗口回来测量，与判定用同一套噪声带比对，给「超出噪声带 / 无可辨识变化 / 测不了」三态结局——没有变化也是诚实的结论 |
横向支撑层
支撑层是功能「用起来之后变准」的地方——它不直接回答问题， 但决定了下次回答的依据从哪来、谁说了算。
| 功能块 | 谁在用 | 一句话 |
|---|---|---|
| 知识库 | 管理员（+ 自动草案） | 五个 YAML 按「谁能写」分工；自动写入一律 pending，管理员确认后才进检索 |
| 语义模型 | 管理员 | 可答边界的唯一声明处：初始化起草、可视化编辑、版本历史与回滚 |
| 记忆 | 自动 + 管理员确认 | 情节记忆（问过什么）自动可用；偏好与晋升先落草案，确认才生效（晋升默认关） |
| Skills | 管理员 | 组织方法论（区别于数据源事实）：四档——整段注入、按需加载、只断言不注入（validator 断结果、guard 断 SQL，拦在交付前与执行前） |
| 主题域 · 权限 · 审计 | 管理员 | 给问题划范围 + 第二层授权收窄（不可见即不存在）；角色授权、审计日志、API 令牌 |
| 质量与成本运营台 | 管理员 | 评测对比与回归门：答得对不对、花得值不值摊开成一页 |
service.py:41 MemoryService service.py:96 _TIERS
产物链：谁产生，谁消费
把上图拆散看，功能之间真正流动的是产物—— 这也决定了「用起来会变准」具体是怎么发生的：每一次问答与判定都在留下 下一次要用的东西，而自动留下的部分必须过确认门。
| 产物 | 谁产生 | 谁消费 | 落在哪 |
|---|---|---|---|
| 答案卡（结论 / SQL / 证据） | 问数管线 | 提问者；依据抽屉随时复查 | 会话记录 |
| 归因卡 | 独立的只读分析 | 提问者 | 会话记录（不成时不出现） |
| 情节记忆 | 每次问答自动写回（事实记录） | 下一次生成：成功 SQL 当锚点、失败与纠正当反例 | 本机记忆库 |
| 待确认草案（示例 / 教训 / 偏好） | 自动沉淀 | 管理员确认 | 知识库的 pending 区 → 确认后进检索 |
| 判定（verdict + 证据） | 定时判定引擎 | 判定历史、订阅推送、行动提案 | 判定运行记录 |
| 行动提案 | 判定触发 | 管理员审批 | 提案台 |
| 交付与回执 | 审批通过后的拉通道 | 外部系统；回执回来对账 | 审计轨迹 |
| 效果结局（三态） | 效果验收窗口到期后的测量 | 质量回评的分桶统计；判定历史 | 判定运行记录 |
这条链上有一条贯穿的分工：凡是「算不算、对不对、变没变好」的判断 都交给确定性代码——门禁判定、编译器、结果规则链、版本比对、 判定引擎、审批留痕，全是零 LLM；LLM 只负责理解与表达。所以「行动」才可能 停在一份可审计的提案上，而不是一个不可解释的自主执行。
service.py:334 DecisionService expr.py:499 parse_condition service.py:155 ActionService
边界：刻意不做的事
下面这些不是待办清单，是产品口径的一部分—— 写出来，才不会在演示时被过度承诺。
| 不做的事 | 为什么 |
|---|---|
| 不由 Trove 执行行动 | 系统只到「提案 → 审批 → 交付 → 回执」；执行与后果在外部系统——行动在系统外是刻意边界，不是缺口 |
| 自动内容不直接进检索 | 记忆 / Skills / 教训的自动写入一律落 pending，晋升默认关——人工确认是知识库不被污染的闸门 |
| 未建模的数据源不开放问数 | 语义模型是可答边界的唯一声明处：接入即建模——先初始化知识库，再开放给用户 |
| 判定不做「AI 判断」 | 阈值规则声明式（无 eval 的闭集表达式）、三值逻辑、证据可回放；「判不了」绝不报成告警 |
| 人工环节默认拒绝 | 人工确认与行动审批的失败方向都是不放行——拿不准时宁可停在原地 |