oh-my-muse/design-docs/专题-06-元数据驱动的智能体架构.md

# 专题-06：元数据驱动的智能体架构

- 版本：v1
- 更新日期：2026-07-09
- 目标读者：架构 / 后端 / 前端 / 产品
- 边界说明：本册是「元数据驱动的智能体架构」这条横切主线的单一 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)。上述对象本册只链接、不重复定义。
- 变更记录：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)。

一次生成的完整数据流由 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)） |
| **③ 编排** | 智能体怎么串 | 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 结构本体全清单（20 型）

下表是与两轴对齐后的 target type 全清单，给的是归属、粒度与本体分组的总览；落地节奏由执行计划承载，本表只陈述设计本身。

| # | domain | scope | target_type | 中文名 | 本体分组 |
|---|---|---|---|---|---|
| 1 | content | work | `novel_work` | 作品容器 | 容器 |
| 2 | content | work | `work_core` | 作品核心 | 作品骨架 |
| 3 | content | work | `outline` | 大纲 | 作品骨架 |
| 4 | world | work | `world` | 世界观总纲 | 世界设定 |
| 5 | world | entity | `location` | 地点 | 世界设定 |
| 6 | world | entity | `faction` | 组织阵营 | 世界设定 |
| 7 | world | entity | `power_system` | 力量体系 | 世界设定 |
| 8 | world | entity | `item` | 物品 | 世界设定 |
| 9 | world | event | `event` | 事件 | 世界设定 |
| 10 | world | entity | `character` | 角色 | 人物 |
| 11 | world | relation | `character_relation` | 角色关系 | 人物 |
| 12 | narrative | work | `style` | 文风画像 | 画像 |
| 13 | narrative | work | `pacing` | 节奏画像 | 画像 |
| 14 | narrative | entity | `craft` | 叙事技法 | 技法 |
| 15 | narrative | entity | `combat` | 打斗桥段 | 技法 |
| 16 | narrative | entity | `emotion` | 情感桥段 | 技法 |
| 17 | narrative | entity | `scene_pattern` | 通用桥段 | 技法 |
| 18 | narrative | entity | `trope` | 套路 | 技法 |
| 19 | knowledge | entity | `reference_work` | 参考作品档案 | 系统侧 |
| 20 | ai_context | agent | `generation_context` | 生成上下文 | 配套 |

scope 落座有两处最易被误判，须点明。`outline` 取 `work` 而非 chapter：scope 是实例集合的聚合归属粒度，大纲是全书单一计划，其内部的全书/卷/章三层用字段表达层级，不改 scope。`world` 取 `work`：按边界判据它不可数、无法单章出场，是每作品一份的单例总纲，故归 work 而非 entity。

### 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 是独立事实载体，见 [架构-02 §3 作品内容模型](架构-02-核心数据结构与双轨模型.md)，本体只提供其字段模具）；RAG 文档面不进本体（上传的百科语料是检索素材，非实例，除非经确认链落成作品实体）；品类特化与作品私有字段不进基础层，走开放集增型与作品级 override。

### 4.5 三层浇铸与双层型

结构本体按浇铸去向分三层：**结构骨架**只浇作品事实实例，入 Local KB 或规划；**公共参考**只浇跨作品范式，由系统级拆书入 Global KB，只存抽象范式与脱敏例证、不留原文；**双层**两处都浇。所有型共享名称/别名/摘要/标签等基础字段，各型只在此之上标注特有字段。

`character`、`style`、`pacing`、`craft` 四型是双层型。主案取**单模具双库**——一型一 schema，作品面实例与公共范式共用同一字段合同，公共面实例落 Global KB。是否为公共面另立独立的 `*_paradigm` 型，留待三样本实测（拆书产出的公共范式能否无损写进同一字段合同）再定：能无损写入则不拆，字段合同不同构才拆。在此之前 W1 先落作品面种子，不被这个开放问题阻塞。

---

## 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)）。卷章结构不进容器字段合同，按「投影收进读模型」降级，由 §7 统一读取器的作品分区输出。

### 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 出厂全集是 20 项，分四档，每档的开箱形态与可见性基线如下。

| 档 | 开箱形态 | schema | 可见性基线 |
|---|---|---|---|
| 作品身份档 | 开箱即有 | `novel_work`、`work_core` | 可见、可编辑（容器回算字段除外）、可进 AI 上下文（禁区/结局方向按需） |
| 创作骨架档 | 开箱即有、空实例 | `outline`、`world`、`location`、`faction`、`power_system`、`item`、`event`、`character`、`character_relation` | 可见/可编辑/可检索三者全开 |
| 画像与技法档 | 开箱即有画像；公共范式随 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)。

---

## 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 结构化、附来源标注。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/parse，授权按用途裁，对齐 [专题-03 §4.3 来源和授权](专题-03-AI编排上下文与质量评测实现规范.md) 的「允许阅读不等于允许进 AI 上下文」）；期望 schemaVersion（可选，防任务中途版本漂移）。
- **输出**：分区化的结构块列表，每块含 `targetType`、`schemaKey`、`schemaVersion`、已按 `aiContext` 裁剪的结构化字段值、`dataRevision`、来源标注（对齐 [专题-03 §5.3 检索结果合同](专题-03-AI编排上下文与质量评测实现规范.md)），以及 `omittedFields` 及原因。

裁剪分三级、同时生效：**字段级**（`aiContext=false` 的字段剔除）、**来源级**（状态受限的来源整块不进）、**用途级**（`allowedPurpose` 不含本次 purpose 的剔除）。任一级判定剔除，数据即不进上下文。受限来源整块进 `omittedSources`，失败关闭并留痕可审计。

---

## 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) |
| 外部 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) |