324 lines
43 KiB
Markdown
324 lines
43 KiB
Markdown
# 专题-06：元数据驱动的智能体架构
|
||
|
||
- 版本：v5
|
||
- 更新日期：2026-07-20
|
||
- 目标读者：架构 / 后端 / 前端 / 产品
|
||
- 边界说明：本册是「元数据驱动的智能体架构」这条横切主线的单一 owner，收束四件此前散落无主的事——元引擎与功能链如何共同驱动智能体、拆书作为通用抽取智能体的两处用场、target type 结构本体的全清单与分层判据、统一创作数据读取器与 base 内置机制。术语与双轨不变式的权威在 [架构-02-核心数据结构与双轨模型](架构-02-核心数据结构与双轨模型.md)（MetaSchema、Canonical/Shadow、domain/scope）；AI 链路合同与 Context Assembly 在 [专题-03-AI编排上下文与质量评测实现规范](专题-03-AI编排上下文与质量评测实现规范.md)；外部 Agent 协议在 [专题-05-AI统一交互协议与外部AgentAdapter设计](专题-05-AI统一交互协议与外部AgentAdapter设计.md)；表结构与字段合同在 [后端-04-统一数据库Schema-v1](后端-04-统一数据库Schema-v1.md)。上述对象本册只链接、不重复定义。
|
||
- 变更记录：v5（2026-07-20）§7.1 登记 `generation_context` 的 generation purpose 严格 schema 投影、卡索引视图和事实/原文双证据字段，具体合同仍由专题-03/07 owner 定义。v4（2026-07-17）拆书实验台证据回填——§4.5 拍板双层型开放问题（`craft` 公共面实测无损写入同一字段合同，单模具双库成立，不拆）并登记世界域实体型共享「演变历程」元素；§6 新增 6.4 参照作品面（参考书实体演变卡 = 系统侧证据资产，蒸馏为叙事域成长曲线范式后才入 Global KB）；知识消费选择契约与质量闭环整体归新册 [专题-07-知识消费契约与质量闭环](专题-07-知识消费契约与质量闭环.md)，本册补链接；§7 读取器 purpose 枚举 `parse` 统一为 `extraction`、字段级裁剪随 `aiContext` 值域升级（布尔或用途集，权威在 [架构-02 §9](架构-02-核心数据结构与双轨模型.md)）对齐表述。v3（2026-07-09）结构本体补全 scope 轴空格位——新增 `chapter`（章节容器）、`scene`（场景卡）、`narrative_state`（叙事状态模具）三型，清单 20→23、scope 七值全挂靠，种子四档同步 23 项；钉死读取器只依赖 owner api 模块具名端口（服务即 API）与 storage_binding 的权力边界（映射非数据通道）。v2（2026-07-09）新增 §2.1 检索基座的替换合同与演进方向（引擎缝 + 引擎中立合同，预期纯 Java 自研：PG 向量插件 + New-API 嵌入/重排，切块收回保护节点）。v1（2026-07-09）定稿自 2026-07-08 架构评审，将「agent = f(作品 + 元数据 + 知识库)」主线、三体关系、20 型结构本体、统一读取器与 base 机制蒸馏为 canonical。
|
||
|
||
---
|
||
|
||
## 1. 中枢：元引擎与功能链双枢
|
||
|
||
理解本册全部内容的钥匙是一句话：**Muse 不是「一个功能挂一个外部 app」，而是一套元数据驱动的智能体编排**。它的中枢在 muse-cloud 的元结构模块里，由两套彼此正交的东西组成。
|
||
|
||
**元引擎（MetaSchema）是结构模具**。它定义一个角色有哪些属性、一段文风从哪些维度刻画、一次转折由哪些要素构成，以及每个字段是否可见、可编辑、可检索、是否可进入 AI 上下文。它约束的是智能体「读哪些字段、抽哪些实体、产出什么结构」。其权威定义见 [架构-02 §9 MetaSchema 与配置模型](架构-02-核心数据结构与双轨模型.md)。
|
||
|
||
**功能链（FunctionChain）是流程骨架**。一条链由若干节点串成，节点分两种：开放槽位允许替换子智能体，保护节点不可替换。它约束的是「智能体按什么次序跑、哪一步不能外包」。功能链的节点/开放槽位/保护节点语义见 [专题-03 §2 系统功能链路](专题-03-AI编排上下文与质量评测实现规范.md)，落地的槽位模型见 [架构-02 §5.2 系统功能编排与槽位](架构-02-核心数据结构与双轨模型.md)。
|
||
|
||
一句话区分：**MetaSchema 定义「结构」，FunctionChain 定义「流程」**。二者同住元引擎（Meta BC）——功能链的定义、版本、节点、槽位与 MetaSchema 是一族数据，表结构见 [后端-04 §7.2 系统功能链路和槽位](后端-04-统一数据库Schema-v1.md)。AI runtime 不自持一套编排，而是经 `FunctionChainQueryApi` 读端口取激活的功能链，据此解析节点序列与开放槽位再做运行编排。这样「谁来定义能力怎么串」与「谁来执行这次编排」分属两个 BC，定义在 Meta、执行在 AI，避免编排逻辑在两处各写一份而漂移。
|
||
|
||
由这两枢得到本架构最重要的性质：**每个智能体都是 `f(作品 + 元数据 + 知识库)`**。任何智能体运行时同时结合三样输入——作品提供「写什么/改什么/查什么」的对象与近邻语境，元数据决定「读哪些字段、抽哪些实体、产出什么结构」（它是产出结构的模具），知识库提供「作品事实」与「公共参考」两类支撑。因此**智能体的类型是固定的产品功能（写死在功能链节点上），但产出是元数据驱动的动态结果**：管理员在元引擎里给「世界设定」加一个字段「金手指类型」，或给「文风」加一个维度「反转密度」，不改一行智能体代码，拆书就会多抽这个属性、规划会多生成这个字段、检测会多查这个维度。这就是「类型固定、元数据变则产出变」。
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
subgraph Meta["元引擎 MetaSchema（结构模具）"]
|
||
MS["target type / 字段 / 枚举 / 校验<br/>aiContext 开关 / 输出合同"]
|
||
end
|
||
subgraph Chain["功能链 FunctionChain（流程骨架 · 经 FunctionChainQueryApi 激活）"]
|
||
direction LR
|
||
N1["保护节点<br/>输入合规 / 权限过滤"] --> SLOT["开放槽位<br/>能力子智能体"] --> N2["保护节点<br/>质量门控 / 输出合规"]
|
||
end
|
||
W["作品 Content"] --> SLOT
|
||
K["知识库 Knowledge"] --> SLOT
|
||
MS -. 约束读入与产出结构 .-> SLOT
|
||
MS -. 定义可入 AI 字段 .-> W
|
||
SLOT -->|候选| Shadow["Shadow 待审"]
|
||
Shadow -->|用户确认| Canonical["Canonical 正式事实"]
|
||
```
|
||
|
||
---
|
||
|
||
## 2. 三体关系：muse-cloud / dify-agent / dify-rag / New-API
|
||
|
||
先破一个误解：**dify-agent 与 dify-rag 不是两套部署，而是同一个 Dify 实例的两个功能平面**，靠两类 API key 区分——app key 只能打 app/workflow，dataset key 只能打 datasets，混用即被拒。四方职责如下。
|
||
|
||
| 角色 | 是什么 | 持有什么 | 边界 |
|
||
|---|---|---|---|
|
||
| **muse-cloud** | 大脑与主权 | 元引擎、功能链、运行权限包、双轨（Shadow/Canonical）、审计、用量归属、编排 | 业务事实源与权限裁判；绝不让外部写 Canonical |
|
||
| **dify-agent** | 开放槽位的能力执行 | Dify chat/workflow app | 只是能力节点，只返回候选，不是可入库事实 |
|
||
| **dify-rag** | 检索基座 | Dify Datasets（每知识库一物理库） | 检索基座不等于事实源；缺来源/授权的结果不进上下文 |
|
||
| **New-API** | 底层模型网关 | 真实模型与向量/重排 | 用量、成本、归属的权威；Dify 用量仅作脱敏审计 |
|
||
|
||
主权原则一句话：**Muse 编排，Dify 执行，Muse 裁判**。两个 Dify 平面都是可替换的外部底座——指定了 Dify 却未配置时失败关闭，绝不回退 New-API 伪装成功；Dify 全挂时 Muse 也只失败关闭，用户读写 Canonical 不受影响。外部运行时接入的统一协议与 adapter 边界见 [专题-05](专题-05-AI统一交互协议与外部AgentAdapter设计.md)。
|
||
|
||
### 2.1 检索基座的替换合同与演进方向
|
||
|
||
检索基座的可替换不是口号，而是由两道既有接缝保证的。**引擎缝**：知识域内部只有一个检索运行时接口，引擎实现（当前是 Dify Datasets，未配置时是失败关闭的空实现）按装配切换，dataset 等引擎侧标识全部收在接缝之下；**合同缝**：知识域对上（AI 编排、统一读取器）暴露的检索 facade-api 是引擎中立的——请求携带租户、用户、作品等隔离与授权要素，返回携带来源标注与被剔除来源清单。由此，**查询语义（查什么、按什么授权、怎么进上下文）永远在 muse-cloud，引擎只执行「给定集合范围内的相似度检索」**；逻辑与物理的用户隔离同样是 muse-cloud 服务端的裁决，引擎不承载信任边界——Dify 并不认识 Muse 的用户，今天的隔离本来就是「每知识库一 dataset + Muse 侧授权前置」。
|
||
|
||
这两道接缝决定了演进路径：**当期取 Dify Datasets 快速闭环；预期演进方向是纯 Java 自研检索基座**（方向性预期，非当期承诺）——PostgreSQL 向量插件承担向量索引与行级隔离过滤（向量检索与作品/库/用户过滤在同一条查询内完成，隔离强于外部 dataset），嵌入与重排经 New-API 端点调用（二者本就是模型调用而非库能力），切块收回 Muse（设计上它本就是保护节点，见 [专题-03](专题-03-AI编排上下文与质量评测实现规范.md)）。迁移成本被接缝锁定为：一个新的检索运行时实现加摄入链，上层合同、统一读取器与双轨全部不动。
|
||
|
||
一次生成的完整数据流由 muse-cloud 全程编排，外部两平面只在「检索」与「能力执行」两处被调用，产出一律以候选身份回到 Muse 的保护节点。
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant U as Studio 用户
|
||
participant M as muse-cloud（编排 + 主权）
|
||
participant R as dify-rag（检索）
|
||
participant A as dify-agent（能力执行）
|
||
participant N as New-API（模型网关）
|
||
U->>M: 续写请求
|
||
M->>M: 生成运行权限包 + 按 MetaSchema 组装上下文
|
||
M->>R: 按授权检索绑定库
|
||
R->>N: 向量检索 / 重排
|
||
R-->>M: 授权片段（带来源 / 状态）
|
||
M->>A: 组装后的上下文
|
||
A->>N: 模型推理
|
||
A-->>M: 候选（仅候选）
|
||
M->>M: 保护节点：静态检查 / 质量门控 / 输出合规
|
||
M-->>U: Shadow 候选 + 创作健康度解释
|
||
U->>M: 接受 / 改后合并 / 丢弃
|
||
M->>M: 写 Canonical 正文 + 来源归因
|
||
```
|
||
|
||
---
|
||
|
||
## 3. 智能体三层清单
|
||
|
||
按主权边界，智能体分三层，**只有第一层可以挂 Dify app**。这样切分有三个理由：主权（Shadow→Canonical 的裁决不能被外部替换）、可替换性（同一开放槽位可在 Dify、New-API、未来 AgentScope 之间换而不动主链）、可解释与可审计（保护节点必须产出 Muse 可追溯的结论）。
|
||
|
||
**第一层 · 开放能力子智能体**（可挂 Dify app/workflow 或 New-API，也是用户/市场智能体的插入点）：
|
||
|
||
| 智能体 | 做什么 | 依赖（作品 + 元数据 + 知识库） | 产出与边界 |
|
||
|---|---|---|---|
|
||
| **写作** | 续写/改写/扩写/润色/纠错/去 AI 味/角色声音 | 近邻正文 + `style`/`pacing`/`craft` + Local KB 与检索片段 | 只进 Shadow；不写 Canonical，不替换保护节点 |
|
||
| **拆书/分析** | 按 MetaSchema 从文本抽实体/关系；全书解析、章节抽取、结构拆解 | 源文本 + 实体类 target type + 目标库（Global/Local） | 章节审阅后才建草稿；系统级只产抽象范式、不留原文 |
|
||
| **检测** | 一致性/角色声音/文风/风险/语义偏离检查 | 候选或正文 + 检查约束 target type + Local KB Canonical | 只产解释与定位，不直接改正文或知识 |
|
||
| **规划** | 生成大纲/世界设定/人设 | 作品方向 + `work_core`/`outline`/`world`/`character` + Local KB | 规划候选只进 Shadow；未确认不得进后续生成上下文 |
|
||
|
||
**第二层 · 保护节点智能体**（Muse 自持，即使调用 LLM 也不外包为可配置 Dify app，只走受控内部路径）：质量门控与 LLM-Judge 在候选交付前按质量维度评分并做 Shadow 内有限重写；合规与语义围栏对输入输出做失败关闭的合规裁决，不可被质量分放开；离线质量评估对智能体/Prompt/策略跑评估集回归，不影响用户当前候选。它们是「先审后入」主权的执行者，质量维度的定义见 [专题-04-生成质量门控与创作健康度设计方案](专题-04-生成质量门控与创作健康度设计方案.md)。
|
||
|
||
**第三层 · 知识基座**（不是「app」）：RAG 检索按授权从绑定库的 Dify dataset 循环检索合并，返回带来源/授权/状态的片段；切块、入 RAG、索引是资料摄入的保护节点，处理未过不得进生成上下文。
|
||
|
||
三层与功能链节点一一对应：生成链对应写作智能体，分析/导入解析链对应拆书智能体，检测链对应检测智能体，规划链对应规划智能体，知识处理链对应拆书入库与 RAG，质量链与合规链落在保护节点智能体上。功能链是编排骨架，智能体是槽位里的能力。
|
||
|
||
---
|
||
|
||
## 4. target_type 结构本体
|
||
|
||
### 4.1 元数据用途类与本体分组的分层
|
||
|
||
元数据不是一张平表。它按用途分五个**元数据用途类**，其中只有第一类是「实体有哪些属性」、被拆书与生成直接消费；其余四类各有独立 owner，本册只在此定位、不重复定义。
|
||
|
||
| 元数据用途类 | 管什么 | 载体与 owner |
|
||
|---|---|---|
|
||
| **① 结构本体** | 实体有哪些属性（拆书抽、生成写、检测查的结构模具） | MetaSchema target types（本册 §4.2 起） |
|
||
| **② 质量维度** | 怎么评判好坏 | Quality Policy（[专题-04](专题-04-生成质量门控与创作健康度设计方案.md)；输入侧知识质量维度与回放评测见 [专题-07](专题-07-知识消费契约与质量闭环.md)） |
|
||
| **③ 编排** | 智能体怎么串 | FunctionChain（本册 §1，落地见 [后端-04 §7.2](后端-04-统一数据库Schema-v1.md)） |
|
||
| **④ 智能体配置** | 每个能力怎么配（prompt/模型绑定/工具授权/输出合同） | Agent Version（[专题-05](专题-05-AI统一交互协议与外部AgentAdapter设计.md)） |
|
||
| **⑤ 可见与策略** | 每字段的权限行为与灰度 | MetaVisibilityPolicy（[架构-02 §9](架构-02-核心数据结构与双轨模型.md)） |
|
||
|
||
为免「大类」串词，下文一律称这一层切分为**元数据用途类**（五类），称结构本体内部的分组为**本体分组**（作品骨架/世界设定/人物/画像/技法，加容器、系统侧、配套三个附组）。「固定」的是这几个用途类；类型与属性是开放集——管理员可增类型、用户可在作品级扩字段。
|
||
|
||
### 4.2 前置地基：domain 与 scope 两轴
|
||
|
||
结构本体的每个 target type 先由两根正交的轴定位。这两轴的概念权威在 [架构-02 §9](架构-02-核心数据结构与双轨模型.md)，此处给的是面向本体分类的应用视图。
|
||
|
||
**domain 描述语义域，不描述存储 BC**——它回答「这块结构属于哪个意义世界」，与实例落在哪个 Bounded Context 无关；例如 Local KB 实体的实例存 Knowledge BC，但其 schema 多属 world 或 narrative 域。**scope 恒等于实例对象的粒度**，取值是 work/chapter/block/entity/relation/event/agent 之一；系统级与作品级之分不占 scope 轴，由 `effective_scope` 承载（见 §5）。
|
||
|
||
| domain | 一句话判据 | 承载 |
|
||
|---|---|---|
|
||
| `content` | 作者对作品的戏外承诺与计划，角色感知不到 | 作品容器、创作定位、大纲 |
|
||
| `world` | 角色可感知的戏内世界事实 | 世界观、地点、组织、力量体系、物品、事件、角色、关系 |
|
||
| `narrative` | 只关「怎么讲」、不关「讲什么」的叙事表达层 | 文风、节奏、技法、桥段、套路 |
|
||
| `knowledge` | 知识库域自身的资料资产结构（非知识实体的内容结构） | 参考作品档案 |
|
||
| `ai_context` | AI 上下文组装与输出合同的结构 | 生成上下文快照模具 |
|
||
|
||
有一处同词须点明：target type `world`（世界观总纲，一个具体结构型）与 domain `world`（世界事实语义域）字面相同却分属两轴，前者是「型」、后者是「域」，不是一回事。
|
||
|
||
### 4.3 结构本体全清单（23 型）
|
||
|
||
下表是与两轴对齐后的 target type 全清单，给的是归属、粒度与本体分组的总览；落地节奏由执行计划承载，本表只陈述设计本身。
|
||
|
||
| # | domain | scope | target_type | 中文名 | 本体分组 |
|
||
|---|---|---|---|---|---|
|
||
| 1 | content | work | `novel_work` | 作品容器 | 容器 |
|
||
| 2 | content | chapter | `chapter` | 章节容器 | 容器 |
|
||
| 3 | content | block | `scene` | 场景卡 | 容器 |
|
||
| 4 | content | work | `work_core` | 作品核心 | 作品骨架 |
|
||
| 5 | content | work | `outline` | 大纲 | 作品骨架 |
|
||
| 6 | content | work | `narrative_state` | 叙事状态 | 配套 |
|
||
| 7 | world | work | `world` | 世界观总纲 | 世界设定 |
|
||
| 8 | world | entity | `location` | 地点 | 世界设定 |
|
||
| 9 | world | entity | `faction` | 组织阵营 | 世界设定 |
|
||
| 10 | world | entity | `power_system` | 力量体系 | 世界设定 |
|
||
| 11 | world | entity | `item` | 物品 | 世界设定 |
|
||
| 12 | world | event | `event` | 事件 | 世界设定 |
|
||
| 13 | world | entity | `character` | 角色 | 人物 |
|
||
| 14 | world | relation | `character_relation` | 角色关系 | 人物 |
|
||
| 15 | narrative | work | `style` | 文风画像 | 画像 |
|
||
| 16 | narrative | work | `pacing` | 节奏画像 | 画像 |
|
||
| 17 | narrative | entity | `craft` | 叙事技法 | 技法 |
|
||
| 18 | narrative | entity | `combat` | 打斗桥段 | 技法 |
|
||
| 19 | narrative | entity | `emotion` | 情感桥段 | 技法 |
|
||
| 20 | narrative | entity | `scene_pattern` | 通用桥段 | 技法 |
|
||
| 21 | narrative | entity | `trope` | 套路 | 技法 |
|
||
| 22 | knowledge | entity | `reference_work` | 参考作品档案 | 系统侧 |
|
||
| 23 | ai_context | agent | `generation_context` | 生成上下文 | 配套 |
|
||
|
||
scope 落座有两处最易被误判，须点明。`outline` 取 `work` 而非 chapter：scope 是实例集合的聚合归属粒度，大纲是全书单一计划，其内部的全书/卷/章三层用字段表达层级，不改 scope。`world` 取 `work`：按边界判据它不可数、无法单章出场，是每作品一份的单例总纲，故归 work 而非 entity。
|
||
|
||
三处命名也须点明。型 `chapter` 与 scope 值 chapter 同词不同轴（同 `world` 先例），前者是章节容器这个「型」、后者是粒度轴的一格。型 `scene` 落 scope=block 而不叫 block：Block 的粒度已定为场景/小节级，型名取产品语义「场景卡」，并避免与 scope 值同义反复（与 `character_relation` 不叫 relation 同理）；它与 `scene_pattern` 是实例与范式的关系——前者是本作品某一场戏的结构卡（content 域），后者是跨作品的场景公式（narrative 域公共范式）。「段落」不独立建模：Muse 的正文最小编辑单元就是 Block，段落的结构语义由 `scene` 承载。
|
||
|
||
补全后一个完备性事实值得留档：scope 的七个取值（work/chapter/block/entity/relation/event/agent）每一格至少有一个型挂靠，轴上不再有空格位。
|
||
|
||
### 4.4 精炼原则与拆分判据
|
||
|
||
**一型一格位、一概念一 owner**。一个候选要挣得独立 target type，须同时占据「它是什么（实体/计划/画像/装置/范式）× 谁在何时消费（规划/写作/检查期）」平面上的一个空格位，且承载邻接型收编不了的字段合同；否则按三条规则降级：差异只能举例、给不出判据的**变体收进枚举**（如拍卖会、比武会）；属性可由他型查询导出的**投影收进读模型**（如时间线、关系网、伏笔看板）；离开某型无独立生命的**附属收进字段**（如金手指例外）。这条准绳兑现「类型可更多但边界必清晰」——品类增型走同一判据，判据说不出一句就降级，杜绝为拆而拆。
|
||
|
||
判断「一个概念落一个还是多个 target type」用四条判据，与上面三条降级规则叠加使用。**粒度判据**：两个用场里实例挂靠的粒度不同（work 级单例画像 vs entity 级多条目），倾向拆。**字段合同判据**：字段交集不足一半、或校验规则互斥，拆。**消费判据**：仅消费链路不同而字段相同，不拆，消费差异走可见性策略。**写入路径判据**：进 Canonical 的入口不同（用户直接命令 vs 确认链），倾向拆。四判据回答「拆不拆」，三条降级规则回答「不拆时降到哪一级」。
|
||
|
||
17 个结构骨架型（容器、系统侧、配套三个附组不计入）的边界判据如下，每型给最锋利的一句「纳入 / 排除去向」；完整字段合同落 [后端-04](后端-04-统一数据库Schema-v1.md)，管理面见 [产品-02B-管理员控制台功能规格](产品-02B-管理员控制台功能规格.md)。
|
||
|
||
| target_type | 层次 | 边界判据（纳入 ‖ 排除→归哪） |
|
||
|---|---|---|
|
||
| `work_core` | 骨架 | 只有作者读者知、角色感知不到的作品级承诺 ‖ 角色可感知世界事实→`world`；逐章安排→`outline` |
|
||
| `outline` | 骨架 | 对「接下来写什么」的计划（全书/卷/章任一层级）‖ 戏内已定事实→`event`；跨作品公式→`trope` |
|
||
| `world` | 骨架 | 角色可感知但不可数、无法单章出场的世界级规则格局 ‖ 可指名出场者→`location`/`faction`/`item`；决定强弱排序→`power_system` |
|
||
| `location` | 骨架 | 可到达、可发生场景的具名空间 ‖ 弥漫地理→`world`；空间上的组织→`faction` |
|
||
| `faction` | 骨架 | 有宗旨/层级/成员的具名集体（含组织化种族、朝廷）‖ 无组织的文明背景→`world`；成员个体→`character` |
|
||
| `power_system` | 骨架 | 直接决定角色强弱排序的规则（可多套并存）‖ 约束所有人而不排序→`world`；具体功法技能→品类开放集增型 |
|
||
| `item` | 骨架 | 可持有可流转的具名物件（含秘籍载体）‖ 「怎么描写」的笔法→`style` 公共层 |
|
||
| `event` | 骨架 | 戏内时间轴上有参与者与因果的已定/预定事实（时间线=event 有序投影，不另设型）‖ 作者写作安排→`outline`；节奏分布→`pacing` |
|
||
| `character` | 双层 | 具名/可指认的行动主体，说话方式即该角色语言指纹 ‖ 作者全书指纹→`style`；关系→`character_relation`；集体→`faction` |
|
||
| `character_relation` | 骨架 | 演变轨迹本身就是剧情、值得立传的关系 ‖ 只更新当前值的结构性从属→Knowledge Relation 边+枚举；推进公式→`trope` |
|
||
| `style` | 双层 | 与章序无关的语言表层指纹（打乱章序不变）‖ 顺序敏感分布→`pacing`；单角色语言→`character` 说话方式 |
|
||
| `pacing` | 双层 | 顺序敏感的分布（值是曲线/比率，打乱章序即毁）‖ 单个爽点构成→`craft`；逐章安排→`outline` |
|
||
| `craft` | 双层 | 单点装置——删去它场景仍成立、读者体验变平；台账只收有跨章履约的装置 ‖ 承载整场戏→桥段三型；跨章公式→`trope` |
|
||
| `combat` | 公共 | 以武力/超自然力分胜负的对抗场景 ‖ 非武力博弈（商战/权谋/斗嘴）→`scene_pattern`；情绪弧主导→`emotion` |
|
||
| `emotion` | 公共 | 以情绪弧为主体的场景（告白/离别/爆发）‖ 武力分胜负→`combat`；关系实体本身→`character_relation` |
|
||
| `scene_pattern` | 公共 | 有「目标-推进-收束」完整结构的场景范式，枚举显式排除打斗与情感 ‖ 点装置→`craft`；跨场景公式→`trope` |
|
||
| `trope` | 公共 | 规定「这条线接下来几章怎么走」的公式 ‖ 单场景流程→`scene_pattern`；本作品自己的计划→`outline`（挂引用） |
|
||
|
||
四条外边界与型内判据同等效力：质量维度不进本体（模具与检尺分立，见 [专题-04](专题-04-生成质量门控与创作健康度设计方案.md)，两者单向咬合、不共享定义）；叙事运行态的事实载体独立（Narrative State 归 Content 聚合，见 [架构-02 §3 作品内容模型](架构-02-核心数据结构与双轨模型.md)；`narrative_state` 型只是它的字段模具，同容器型逻辑，不把状态实例当知识实体管理）；RAG 文档面不进本体（上传的百科语料是检索素材，非实例，除非经确认链落成作品实体）；品类特化与作品私有字段不进基础层，走开放集增型与作品级 override。
|
||
|
||
### 4.5 三层浇铸与双层型
|
||
|
||
结构本体按浇铸去向分三层：**结构骨架**只浇作品事实实例，入 Local KB 或规划；**公共参考**只浇跨作品范式，由系统级拆书入 Global KB，只存抽象范式与脱敏例证、不留原文；**双层**两处都浇（参考书的世界域实体演变另有落位，见 §6.4 参照作品面）。所有型共享名称/别名/摘要/标签等基础字段，各型只在此之上标注特有字段；世界域实体型（`location`/`faction`/`power_system`/`item`/`event`/`character`）在此之上共享**演变历程**元素（{章, 台阶, 周期} 结构化里程碑，实验台已在六型实证；长线消费语义见 [专题-07 §5](专题-07-知识消费契约与质量闭环.md)，字段合同落 [后端-04](后端-04-统一数据库Schema-v1.md)）。
|
||
|
||
`character`、`style`、`pacing`、`craft` 四型是双层型。主案取**单模具双库**——一型一 schema，作品面实例与公共范式共用同一字段合同，公共面实例落 Global KB。是否为公共面另立独立的 `*_paradigm` 型，判据本身不变——三样本实测无损写入则不拆、字段合同不同构才拆。`craft` 已由拆书实验台以远超三样本的量级实测通过（1326 条公共范式无损写入同一字段合同），**拍板不拆**；`character`/`style`/`pacing` 依同一三样本判据在各自公共面首批落库时判定，无损即沿用单模具。判定机制至此闭合，不再是开放问题。
|
||
|
||
---
|
||
|
||
## 5. 作品容器与 base 内置机制
|
||
|
||
### 5.1 作品容器 novel_work 与 work_core 拆两 schema
|
||
|
||
作品容器不是新造的抽象。`muse_content_work` 已有一批固定列——归属用户、书名、品类、简介、状态、字数、章节数、导入与解析状态，并已预留可选关联 MetaSchema 的钩子；作品动态字段的修改入口也已预设校验 schemaVersion，表与接口见 [后端-04](后端-04-统一数据库Schema-v1.md) 与 [后端-05 §4.3 作品和正文](后端-05-统一API契约-v1.md)。容器 schema 化是给这批既有固定列补上元描述，不是无中生有。
|
||
|
||
容器（`novel_work`）与作品核心（`work_core`）拆成两个 schema，依据是四判据的字段合同与写入路径两条。字段合同不同构：容器承载书名、简介、封面、状态、字数、时间这类运营与结构身份，`work_core` 承载题材、主题立意、基调、禁区、结局方向这类创作承诺。写入路径不同：容器走用户直接修改加系统回算，`work_core` 走规划确认链。消费面不同：容器喂列表、卡片、导出与市场快照，`work_core` 喂全部开放智能体的上下文。
|
||
|
||
### 5.2 同体加投影，storage_binding
|
||
|
||
容器 schema 与 Work 聚合的关系是**同体加投影，不派生**——不另建实例表，避免双写漂移。schema 是对 Work 固定列的元描述与读投影模具：字段合同为每字段标注落点，`native_column`（物理列）、`extension_json`（扩展字段）或 `computed`（回算字段，用户不可编辑），这就是 `storage_binding` 机制，由 `muse_meta_field` 承载对固定列的元描述（属性落点见 [后端-04](后端-04-统一数据库Schema-v1.md)）。它与「MetaSchema 不替代事实载体」一致（[架构-02 §9](架构-02-核心数据结构与双轨模型.md)）。一条权力边界必须写死：`native_column` 映射是元描述、不是数据通道——Meta 不因持有映射而获得读写 Content 表的任何权力，字段值的读写永远经值的 owner 自己的 API，模具（经 meta-api）与值（经 owner api）在消费方组装，Meta 侧不出现对他模块表的连接查询。卷章结构不进容器字段合同，按「投影收进读模型」降级，由 §7 统一读取器的作品分区输出。
|
||
|
||
容器组不止作品一级，`chapter`、`scene` 与 `narrative_state` 是同一机制在章节、Block 与叙事状态上的适用：固定列（章节标题/序号/字数、Block 归属与修订）走 `native_column` 元描述，创作侧结构字段走 `extension_json` 扩展。这不是凭空加需求——[专题-03 §4.2](专题-03-AI编排上下文与质量评测实现规范.md) 的近邻正文层早已把「章节目标、近期叙事状态」列为续写不可省略的输入，而章节表的固定列里并没有「目标」这个字段，章节容器的扩展字段（本章目标、伏笔清单、情绪曲线）正是这处既有设计欠账的落点；场景卡承载 POV、地点、出场角色、时间锚与情绪基调，正文本身仍在 Block，schema 只管结构面。
|
||
|
||
### 5.3 base 是全局 active schema，叠加与继承
|
||
|
||
`base` 不是新机制：**base 就是 `effective_scope=全局` 的 active schema 版本**，「内置」就是系统出厂 seed 的那批全局 schema。一个作品能看到的结构，是三层叠加：全局 active ⊕ 类型灰度版本 ⊕ 作品级 override。**override 只增不改**——只能扩展字段，不能删改全局字段的定义与可见性；这是 [架构-01](架构-01-系统全貌与边界上下文.md) BC 边界的推论，全局定义的主权不因作品扩展而被作品侧改写。
|
||
|
||
继承靠动态合成、不靠复制：系统不落 per-work schema 实例，读取时按投影版本动态合成。新作品开箱即有全部结构，因为全局 schema 天然生效、零初始化；容器上预留的品类包钩子默认空，即纯继承。
|
||
|
||
系统内置的 base schema 出厂全集是 23 项，分四档，每档的开箱形态与可见性基线如下。
|
||
|
||
| 档 | 开箱形态 | schema | 可见性基线 |
|
||
|---|---|---|---|
|
||
| 作品与结构身份档 | 开箱即有 | `novel_work`、`chapter`、`scene`、`work_core` | 可见、可编辑（容器与结构回算字段除外）、可进 AI 上下文（禁区/结局方向按需） |
|
||
| 创作骨架档 | 开箱即有、空实例 | `outline`、`world`、`location`、`faction`、`power_system`、`item`、`event`、`character`、`character_relation`、`narrative_state` | 可见/可编辑/可检索三者全开 |
|
||
| 画像与技法档 | 开箱即有画像；公共范式随 Global KB 绑定进入 | `style`、`pacing`、`craft`、`combat`、`emotion`、`scene_pattern`、`trope` | 作品面全开；公共面例证与出处字段的可见性待例证口径 |
|
||
| 系统侧档 | 用户不可见 | `reference_work`（仅管理面）、`generation_context`（运行时） | 不可见、不可编辑 |
|
||
|
||
---
|
||
|
||
## 6. 拆书与参考作品
|
||
|
||
### 6.1 一套模具，两处浇铸
|
||
|
||
拆书不是管理员专用的一次性管线，而是一个**通用抽取智能体**：给定文本、MetaSchema 与目标库，按 target type 定义的实体类型解析出实体并入库（经 Shadow→Canonical）。同一个智能体有两个用场，产出结构都由 MetaSchema 决定，因此系统级参考库与作品级实体库天然共用一套结构。
|
||
|
||
- **系统级（管理员）**：把几十上百本参考书拆成小说公共属性范式，沉淀进全局知识库。产出的是抽象属性与技法范式，不是逐字原文（版权约束，且 [专题-03](专题-03-AI编排上下文与质量评测实现规范.md) 禁「作品资产模板化」）。
|
||
- **作品级（用户）**：每确认一章正文，拆本章新实体与关系入局域知识库的确认链；质量校验智能体同时查与既有事实的一致性。
|
||
|
||
拆书的入库不越过双轨——系统级入 Global KB 与作品级入 Local KB 都走 Draft→确认→Canonical，接受 AI 候选只写正文、不自动确认知识（不变式见 [架构-02 §1 双轨模型](架构-02-核心数据结构与双轨模型.md)）。全局公共库作为每个作品的默认可检索来源，但走**显式绑定、不自动注入**：用户或管理员把公共属性库绑定到作品后才进入检索选库集，用量归系统、口径可控。
|
||
|
||
### 6.2 参考作品档案 reference_work
|
||
|
||
系统级拆书要吃进的参考书本身得有个落处，即 `reference_work`（domain=knowledge、scope=entity）——一份系统侧的资料资产档案，不是用户创作事实。它不复用作品表：参考作品的 owner 是系统、生命周期是「采购→拆解→归档」，与用户创作的「起草→连载→完结」是两码事，塞进 Content 会违反「Content 只拥有正文和作品结构」的边界。库位落 Global KB 的 document 特化（Knowledge BC），复用既有的资料、版本与处理任务链（表见 [后端-04](后端-04-统一数据库Schema-v1.md)，知识库治理面见 [产品-02E-知识库工作台功能规格](产品-02E-知识库工作台功能规格.md)）；拆书任务本身归 AI BC，是一类新的抽取任务 `reference_extraction`。
|
||
|
||
字段合同分四组。**标识**：书名、作者、品类、别名。**来源**：上传、公开语料或授权采购。**版权授权状态**：`licensed`、`public_domain`、`research_only`、`unauthorized` 四值，其中 `unauthorized` 失败关闭，不进任何拆书任务。**拆书处理状态**：`pending`、`parsing`、`extracted`、`curated`、`failed`。
|
||
|
||
### 6.3 范式溯源与版权传播
|
||
|
||
范式的溯源不新设 target type、不新建表，复用知识域既有的来源 lineage、快照与状态事件机制（见 [架构-02 §4.3 来源和 lineage](架构-02-核心数据结构与双轨模型.md)）。每条进 Global KB 的范式 Canonical 记录带上来源快照引用与 lineage 载荷，指向它的 `reference_work`、拆书任务与章节定位摘要——**只存定位摘要，不存原文段落**（版权约束）。「某本书贡献了哪些范式」不是一张新表，而是按 lineage 的读模型投影。
|
||
|
||
当某参考作品的版权状态收紧，走既有的来源状态变化传播（[架构-02 §11.3 来源状态变化](架构-02-核心数据结构与双轨模型.md)）：**阻断该来源派生范式的新使用，但不回滚已确认的 Canonical**，与知识域现有来源传播语义一致，不引入新机制。
|
||
|
||
系统级范式的入库走一条专门入口——「管理员确认系统级知识草稿 → Global KB 范式 Canonical」，确认人是管理员，产出走 Draft→确认→Canonical 同构链。该入口是双轨 Canonical 封闭枚举的一项，权威登记见 [架构-02 §1.2 进入 Canonical 的入口](架构-02-核心数据结构与双轨模型.md)。
|
||
|
||
### 6.4 参照作品面：参考书实体演变的浇铸位
|
||
|
||
系统级拆书除产出抽象范式外，还会按章推进沉淀参考书自身的实体演变卡——力量体系、物品、角色等世界域形态，带真实章号的 {章, 台阶, 周期} 里程碑。这类产物**不进 Global KB、不可被用户作品绑定**，浇铸位是**参照作品面**：挂在 `reference_work` 档案之下的系统侧中间资产（knowledge 域），生命周期随参考作品档案的「采购→拆解→归档」走。它的正式用途只有两个：**回放评测的标准答案底座**与**叙事域范式的蒸馏源**（两个用途的定义见 [专题-07](专题-07-知识消费契约与质量闭环.md)）。
|
||
|
||
进入 Global KB 的只能是蒸馏后的叙事域「成长曲线范式」（`trope`/`pacing` 形态：台阶间距分布、周期结构、爆发节奏），溯源与版权传播沿用 §6.3——只存定位摘要，不存原文。一句话钉死边界：**世界域形态是证据，叙事域形态才是范式；参照作品面存证据，Global KB 只收范式。**
|
||
|
||
承载与治理三条钉死：参照作品面**不是第四类知识库**，不进 [架构-02 §4.1](架构-02-核心数据结构与双轨模型.md) 的三类库清单，用户不可见、不可检索；物理承载复用 §6.2 已定的 Global KB document 特化与资料处理任务链，父对象是 `reference_work` 档案，随档案「采购→拆解→归档」同生命周期；参考作品版权状态收紧时沿 §6.3 的来源传播语义处理——阻断其派生证据用于新的评测与蒸馏（均属新使用），不回滚已确认的范式 Canonical。
|
||
|
||
---
|
||
|
||
## 7. 统一创作数据读取器
|
||
|
||
`f(作品 + 元数据 + 知识库)` 里「读入」这一半，落在一个专门的读取层上。它**不是第四套读设施**，而是把既成的 Context Assembly（[专题-03 §4 上下文组装](专题-03-AI编排上下文与质量评测实现规范.md)）的取数面，显式分层为 AI Orchestration 内部的服务端读取器。它按 actor、作品与分区请求及授权上下文，经各 owner 的 facade-api 拉数——Content 出作品容器、章节、正式规划与叙事状态，Knowledge 出 Local KB 实体、关系、事件与绑定库检索，Meta 出模具投影——再对每条数据套上该 target type 的 active MetaSchema 投影，做字段级 `aiContext` 裁剪、按 target type 结构化、附来源标注。模块边界从严：读取器是 AI 模块的内部组装件，不是新模块，它对各 owner 的依赖**只允许落在对方的 api 模块（具名只读端口）上，服务即 API**——每个分区的取数能力就是一个端口合同，owner 没暴露的端口就先在其 api 模块补端口，绝不绕到对方 server 实现或数据表（模块依赖红线见 [后端-02 §3](后端-02-工程结构与模块职责.md)）。Context Assembly 消费它完成分层组装与 Token 预算（分层定义见 [专题-03 §4.2 四层上下文](专题-03-AI编排上下文与质量评测实现规范.md)）；检测、导出预检等非生成链路复用同一读取器，不各自重写取数与裁剪。
|
||
|
||
它与用户面的 meta-projections **同源不同面**：共享模具投影的计算，不共享裁剪策略——用户面按 `uiVisible`/`userEditable` 裁，AI 面按 `aiContext` 裁，两者互不蕴含（[架构-02 §9](架构-02-核心数据结构与双轨模型.md)）。一条负约束必须写死：读取器只作为服务端内部端口存在，**不暴露为通用 app API**，否则它会成为与「通用写 SDK」对称的滥用面。
|
||
|
||
读统一、写各 owner。写侧零新设计——动态字段没有跨 owner 的通用写接口，前端禁通用写 SDK（[前端-03 §5.2](前端-03-元引擎与动态表单.md)），Canonical 入口是封闭枚举，智能体产出只进 Shadow，这些约束一条不改。统一读取器对写的唯一贡献，是沿用动态字段校验接口「校验加路由建议、不写入」的语义，把「智能体想改哪个字段」翻译成「该走哪个 owner 的命令」。
|
||
|
||
**最小读合同**：
|
||
|
||
- **输入**六项：actor；workId；分区请求集（作品容器 / 规划 / 按 target_type 与 scope 过滤的 Local KB 实体 / 仅限已绑定的 Global KB 公共范式，对齐「显式绑定不自动注入」）；运行权限包引用（其分区许可上限只能收紧不能放宽）；purpose（generation/detection/planning/extraction，授权按用途裁，对齐 [专题-03 §4.3 来源和授权](专题-03-AI编排上下文与质量评测实现规范.md) 的「允许阅读不等于允许进 AI 上下文」）；期望 schemaVersion（可选，防任务中途版本漂移）。
|
||
- **输出**：分区化的结构块列表，每块含 `targetType`、`schemaKey`、`schemaVersion`、已按 `aiContext` 裁剪的结构化字段值、`dataRevision`、来源标注（对齐 [专题-03 §5.3 检索结果合同](专题-03-AI编排上下文与质量评测实现规范.md)），以及 `omittedFields` 及原因。
|
||
|
||
裁剪分三级、同时生效：**字段级**（`aiContext` 不含本次 purpose 的字段剔除——`false` 即任何用途不入、`true` 即全用途可入，值域权威见 [架构-02 §9](架构-02-核心数据结构与双轨模型.md)）、**来源级**（状态受限的来源整块不进）、**用途级**（来源授权 `allowedPurpose` 不含本次 purpose 的剔除）。任一级判定剔除，数据即不进上下文。受限来源整块进 `omittedSources`，失败关闭并留痕可审计。
|
||
|
||
### 7.1 `generation_context` 的正文生成登记
|
||
|
||
`generation_context`（domain=`ai_context`、scope=`agent`）在正文实验中启用 generation purpose 的严格 schema 投影。这里仅登记 MetaSchema 结构入口，不复制邻册合同：
|
||
|
||
| 登记项 | MetaSchema 约束 | 唯一 owner |
|
||
|---|---|---|
|
||
| purpose | 固定枚举值 `generation`；不接受别名、空值或未知值 | purpose 值域与字段级 `aiContext` 语义仍见 [架构-02 §9](架构-02-核心数据结构与双轨模型.md) |
|
||
| schema / output 版本 | 必填、精确匹配；缺字段与未知字段失败关闭 | `WriterContext v1` / `WriterOutput v1` 见 [专题-03 §4.5](专题-03-AI编排上下文与质量评测实现规范.md) |
|
||
| cardIndexView | 只登记抽取卡的索引视图与来源引用，不承载原文正文 | “卡是索引、根据来源回读原文”见 [专题-07 §2.1](专题-07-知识消费契约与质量闭环.md) |
|
||
| factEvidence / proseEvidence | 两个独立字段组，禁止互相冒充或合并成通用 evidence | 双证据字段、哈希和冻结规则见 [专题-03 §4.5](专题-03-AI编排上下文与质量评测实现规范.md) |
|
||
| 正式事实来源 | 正式设定、Canonical 状态和细纲新事实保留各自不可变版本引用，不强造抽取卡或历史原文来源 | 权威来源分类见 [专题-07 §2.1](专题-07-知识消费契约与质量闭环.md) |
|
||
|
||
该登记先约束实验台 schema 和上下文投影，不代表产品 API、数据库结构或正式 MetaSchema 种子已经变更；产品化必须等正文 Gate B 通过后另立契约与迁移计划。
|
||
|
||
---
|
||
|
||
## 8. 关联阅读
|
||
|
||
| 主题 | 权威文档 |
|
||
|---|---|
|
||
| MetaSchema、domain/scope、双轨不变式、来源 lineage、Canonical 入口枚举 | [架构-02-核心数据结构与双轨模型](架构-02-核心数据结构与双轨模型.md) |
|
||
| BC 边界与协作规则、override 只增不改的边界推论 | [架构-01-系统全貌与边界上下文](架构-01-系统全貌与边界上下文.md) |
|
||
| AI 编排、Context Assembly、检索合同、质量评测 | [专题-03-AI编排上下文与质量评测实现规范](专题-03-AI编排上下文与质量评测实现规范.md) |
|
||
| 质量维度定义与创作健康度 | [专题-04-生成质量门控与创作健康度设计方案](专题-04-生成质量门控与创作健康度设计方案.md) |
|
||
| 知识消费选择契约、知识质量三性、回放评测、长线进度消费语义 | [专题-07-知识消费契约与质量闭环](专题-07-知识消费契约与质量闭环.md) |
|
||
| 外部 Agent 统一协议与 adapter | [专题-05-AI统一交互协议与外部AgentAdapter设计](专题-05-AI统一交互协议与外部AgentAdapter设计.md) |
|
||
| MetaSchema 表、功能链表、reference_work 表、storage_binding 落点 | [后端-04-统一数据库Schema-v1](后端-04-统一数据库Schema-v1.md) |
|
||
| 作品与动态字段接口契约 | [后端-05-统一API契约-v1](后端-05-统一API契约-v1.md) |
|
||
| 拆书公共属性本体管理面与参考作品治理 | [产品-02B-管理员控制台功能规格](产品-02B-管理员控制台功能规格.md) |
|
||
| 知识库三库两面与全局库绑定 | [产品-02E-知识库工作台功能规格](产品-02E-知识库工作台功能规格.md) |
|