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

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

• 版本：v3
• 更新日期：2026-07-09
• 目标读者：架构 / 后端 / 前端 / 产品
• 边界说明：本册是「元数据驱动的智能体架构」这条横切主线的单一 owner，收束四件此前散落无主的事——元引擎与功能链如何共同驱动智能体、拆书作为通用抽取智能体的两处用场、target type 结构本体的全清单与分层判据、统一创作数据读取器与 base 内置机制。术语与双轨不变式的权威在 架构-02-核心数据结构与双轨模型（MetaSchema、Canonical/Shadow、domain/scope）；AI 链路合同与 Context Assembly 在 专题-03-AI编排上下文与质量评测实现规范；外部 Agent 协议在 专题-05-AI统一交互协议与外部AgentAdapter设计；表结构与字段合同在 后端-04-统一数据库Schema-v1。上述对象本册只链接、不重复定义。
• 变更记录：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 与配置模型。

功能链（FunctionChain）是流程骨架。一条链由若干节点串成，节点分两种：开放槽位允许替换子智能体，保护节点不可替换。它约束的是「智能体按什么次序跑、哪一步不能外包」。功能链的节点/开放槽位/保护节点语义见 专题-03 §2 系统功能链路，落地的槽位模型见 架构-02 §5.2 系统功能编排与槽位。

一句话区分：MetaSchema 定义「结构」，FunctionChain 定义「流程」。二者同住元引擎（Meta BC）——功能链的定义、版本、节点、槽位与 MetaSchema 是一族数据，表结构见 后端-04 §7.2 系统功能链路和槽位。AI runtime 不自持一套编排，而是经 FunctionChainQueryApi 读端口取激活的功能链，据此解析节点序列与开放槽位再做运行编排。这样「谁来定义能力怎么串」与「谁来执行这次编排」分属两个 BC，定义在 Meta、执行在 AI，避免编排逻辑在两处各写一份而漂移。

由这两枢得到本架构最重要的性质：每个智能体都是 f(作品 + 元数据 + 知识库)。任何智能体运行时同时结合三样输入——作品提供「写什么/改什么/查什么」的对象与近邻语境，元数据决定「读哪些字段、抽哪些实体、产出什么结构」（它是产出结构的模具），知识库提供「作品事实」与「公共参考」两类支撑。因此智能体的类型是固定的产品功能（写死在功能链节点上），但产出是元数据驱动的动态结果：管理员在元引擎里给「世界设定」加一个字段「金手指类型」，或给「文风」加一个维度「反转密度」，不改一行智能体代码，拆书就会多抽这个属性、规划会多生成这个字段、检测会多查这个维度。这就是「类型固定、元数据变则产出变」。

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。

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）。迁移成本被接缝锁定为：一个新的检索运行时实现加摄入链，上层合同、统一读取器与双轨全部不动。

一次生成的完整数据流由 muse-cloud 全程编排，外部两平面只在「检索」与「能力执行」两处被调用，产出一律以候选身份回到 Muse 的保护节点。

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-生成质量门控与创作健康度设计方案。

第三层 · 知识基座（不是「app」）：RAG 检索按授权从绑定库的 Dify dataset 循环检索合并，返回带来源/授权/状态的片段；切块、入 RAG、索引是资料摄入的保护节点，处理未过不得进生成上下文。

三层与功能链节点一一对应：生成链对应写作智能体，分析/导入解析链对应拆书智能体，检测链对应检测智能体，规划链对应规划智能体，知识处理链对应拆书入库与 RAG，质量链与合规链落在保护节点智能体上。功能链是编排骨架，智能体是槽位里的能力。

---

4. target_type 结构本体

4.1 元数据用途类与本体分组的分层

元数据不是一张平表。它按用途分五个元数据用途类，其中只有第一类是「实体有哪些属性」、被拆书与生成直接消费；其余四类各有独立 owner，本册只在此定位、不重复定义。

元数据用途类	管什么	载体与 owner
① 结构本体	实体有哪些属性（拆书抽、生成写、检测查的结构模具）	MetaSchema target types（本册 §4.2 起）
② 质量维度	怎么评判好坏	Quality Policy（专题-04）
③ 编排	智能体怎么串	FunctionChain（本册 §1，落地见 后端-04 §7.2）
④ 智能体配置	每个能力怎么配（prompt/模型绑定/工具授权/输出合同）	Agent Version（专题-05）
⑤ 可见与策略	每字段的权限行为与灰度	MetaVisibilityPolicy（架构-02 §9）

为免「大类」串词，下文一律称这一层切分为元数据用途类（五类），称结构本体内部的分组为本体分组（作品骨架/世界设定/人物/画像/技法，加容器、系统侧、配套三个附组）。「固定」的是这几个用途类；类型与属性是开放集——管理员可增类型、用户可在作品级扩字段。

4.2 前置地基：domain 与 scope 两轴

结构本体的每个 target type 先由两根正交的轴定位。这两轴的概念权威在 架构-02 §9，此处给的是面向本体分类的应用视图。

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，管理面见 产品-02B-管理员控制台功能规格。

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，两者单向咬合、不共享定义）；叙事运行态的事实载体独立（Narrative State 归 Content 聚合，见 架构-02 §3 作品内容模型；narrative_state 型只是它的字段模具，同容器型逻辑，不把状态实例当知识实体管理）；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 与 后端-05 §4.3 作品和正文。容器 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）。它与「MetaSchema 不替代事实载体」一致（架构-02 §9）。一条权力边界必须写死：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 的近邻正文层早已把「章节目标、近期叙事状态」列为续写不可省略的输入，而章节表的固定列里并没有「目标」这个字段，章节容器的扩展字段（本章目标、伏笔清单、情绪曲线）正是这处既有设计欠账的落点；场景卡承载 POV、地点、出场角色、时间锚与情绪基调，正文本身仍在 Block，schema 只管结构面。

5.3 base 是全局 active schema，叠加与继承

base 不是新机制：base 就是 effective_scope=全局 的 active schema 版本，「内置」就是系统出厂 seed 的那批全局 schema。一个作品能看到的结构，是三层叠加：全局 active ⊕ 类型灰度版本 ⊕ 作品级 override。override 只增不改——只能扩展字段，不能删改全局字段的定义与可见性；这是 架构-01 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 禁「作品资产模板化」）。
• 作品级（用户）：每确认一章正文，拆本章新实体与关系入局域知识库的确认链；质量校验智能体同时查与既有事实的一致性。

拆书的入库不越过双轨——系统级入 Global KB 与作品级入 Local KB 都走 Draft→确认→Canonical，接受 AI 候选只写正文、不自动确认知识（不变式见 架构-02 §1 双轨模型）。全局公共库作为每个作品的默认可检索来源，但走显式绑定、不自动注入：用户或管理员把公共属性库绑定到作品后才进入检索选库集，用量归系统、口径可控。

6.2 参考作品档案 reference_work

系统级拆书要吃进的参考书本身得有个落处，即 reference_work（domain=knowledge、scope=entity）——一份系统侧的资料资产档案，不是用户创作事实。它不复用作品表：参考作品的 owner 是系统、生命周期是「采购→拆解→归档」，与用户创作的「起草→连载→完结」是两码事，塞进 Content 会违反「Content 只拥有正文和作品结构」的边界。库位落 Global KB 的 document 特化（Knowledge BC），复用既有的资料、版本与处理任务链（表见 后端-04，知识库治理面见 产品-02E-知识库工作台功能规格）；拆书任务本身归 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）。每条进 Global KB 的范式 Canonical 记录带上来源快照引用与 lineage 载荷，指向它的 reference_work、拆书任务与章节定位摘要——只存定位摘要，不存原文段落（版权约束）。「某本书贡献了哪些范式」不是一张新表，而是按 lineage 的读模型投影。

当某参考作品的版权状态收紧，走既有的来源状态变化传播（架构-02 §11.3 来源状态变化）：阻断该来源派生范式的新使用，但不回滚已确认的 Canonical，与知识域现有来源传播语义一致，不引入新机制。

系统级范式的入库走一条专门入口——「管理员确认系统级知识草稿 → Global KB 范式 Canonical」，确认人是管理员，产出走 Draft→确认→Canonical 同构链。该入口是双轨 Canonical 封闭枚举的一项，权威登记见 架构-02 §1.2 进入 Canonical 的入口。

---

7. 统一创作数据读取器

f(作品 + 元数据 + 知识库) 里「读入」这一半，落在一个专门的读取层上。它不是第四套读设施，而是把既成的 Context Assembly（专题-03 §4 上下文组装）的取数面，显式分层为 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）。Context Assembly 消费它完成分层组装与 Token 预算（分层定义见 专题-03 §4.2 四层上下文）；检测、导出预检等非生成链路复用同一读取器，不各自重写取数与裁剪。

它与用户面的 meta-projections 同源不同面：共享模具投影的计算，不共享裁剪策略——用户面按 uiVisible/userEditable 裁，AI 面按 aiContext 裁，两者互不蕴含（架构-02 §9）。一条负约束必须写死：读取器只作为服务端内部端口存在，不暴露为通用 app API，否则它会成为与「通用写 SDK」对称的滥用面。

读统一、写各 owner。写侧零新设计——动态字段没有跨 owner 的通用写接口，前端禁通用写 SDK（前端-03 §5.2），Canonical 入口是封闭枚举，智能体产出只进 Shadow，这些约束一条不改。统一读取器对写的唯一贡献，是沿用动态字段校验接口「校验加路由建议、不写入」的语义，把「智能体想改哪个字段」翻译成「该走哪个 owner 的命令」。

最小读合同：

• 输入六项：actor；workId；分区请求集（作品容器 / 规划 / 按 target_type 与 scope 过滤的 Local KB 实体 / 仅限已绑定的 Global KB 公共范式，对齐「显式绑定不自动注入」）；运行权限包引用（其分区许可上限只能收紧不能放宽）；purpose（generation/detection/planning/parse，授权按用途裁，对齐 专题-03 §4.3 来源和授权 的「允许阅读不等于允许进 AI 上下文」）；期望 schemaVersion（可选，防任务中途版本漂移）。
• 输出：分区化的结构块列表，每块含 targetType、schemaKey、schemaVersion、已按 aiContext 裁剪的结构化字段值、dataRevision、来源标注（对齐 专题-03 §5.3 检索结果合同），以及 omittedFields 及原因。

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

---

8. 关联阅读

主题	权威文档
MetaSchema、domain/scope、双轨不变式、来源 lineage、Canonical 入口枚举	架构-02-核心数据结构与双轨模型
BC 边界与协作规则、override 只增不改的边界推论	架构-01-系统全貌与边界上下文
AI 编排、Context Assembly、检索合同、质量评测	专题-03-AI编排上下文与质量评测实现规范
质量维度定义与创作健康度	专题-04-生成质量门控与创作健康度设计方案
外部 Agent 统一协议与 adapter	专题-05-AI统一交互协议与外部AgentAdapter设计
MetaSchema 表、功能链表、reference_work 表、storage_binding 落点	后端-04-统一数据库Schema-v1
作品与动态字段接口契约	后端-05-统一API契约-v1
拆书公共属性本体管理面与参考作品治理	产品-02B-管理员控制台功能规格
知识库三库两面与全局库绑定	产品-02E-知识库工作台功能规格