docs(design): 结构本体补全 23 型 + 检索基座演进方向与 API 边界钉死

- 专题-06 v3:补 chapter(章节容器)/scene(场景卡)/narrative_state(叙事状态模具)三型, 20→23、scope 七值全挂靠;段落不独立建模由 scene 承载(Block=场景/小节级既有拍板); §2.1 检索基座替换合同与演进方向(引擎缝+引擎中立合同,预期纯 Java 自研:PG 向量插件+New-API 嵌入重排); 钉死读取器只依赖 owner api 模块具名端口(服务即 API)与 storage_binding 权力边界(映射非数据通道) - 章节容器证据链:专题-03 L1 早已预设「章节目标」为续写必需输入而章节表无此字段,扩展字段落此欠账 - 架构-02/后端-04/产品-02B/大纲/映射表:引用去硬编码数字防再漂移;评审稿 v0.3 同步 W1=23 项 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-09 04:28:09 -07:00 · 2026-07-09 04:28:09 -07:00 · c1662fa9d3
commit c1662fa9d3
parent 81374bc203
7 changed files with 58 additions and 43 deletions
--- a/design-docs/00-文档大纲.md
+++ b/design-docs/00-文档大纲.md
@ -100,7 +100,7 @@
 - [专题-02-Sudowrite对标与Muse产品取舍](专题-02-Sudowrite对标与Muse产品取舍.md)
 - [专题-03-AI编排上下文与质量评测实现规范](专题-03-AI编排上下文与质量评测实现规范.md)
 - [专题-05-AI统一交互协议与外部AgentAdapter设计](专题-05-AI统一交互协议与外部AgentAdapter设计.md)
- [专题-06-元数据驱动的智能体架构](专题-06-元数据驱动的智能体架构.md)——收束「agent = f(作品 + 元数据 + 知识库)」横切架构：元引擎与功能链双枢、三体关系、target type 20 型结构本体、统一创作数据读取器、base 内置机制与拆书通用抽取。
+- [专题-06-元数据驱动的智能体架构](专题-06-元数据驱动的智能体架构.md)——收束「agent = f(作品 + 元数据 + 知识库)」横切架构：元引擎与功能链双枢、三体关系、target type 23 型结构本体、统一创作数据读取器、base 内置机制与拆书通用抽取。

 说明：专题文档只负责跨文档收束，不抢走 Schema、状态机和统一 API 的单一归属。

--- a/design-docs/专题-06-元数据驱动的智能体架构.md
+++ b/design-docs/专题-06-元数据驱动的智能体架构.md
@ -1,10 +1,10 @@
 # 专题-06：元数据驱动的智能体架构

- 版本：v1
+- 版本：v3
 - 更新日期：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。
+- 变更记录：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。

 ---

@ -52,6 +52,12 @@ flowchart TB

 主权原则一句话：**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
@ -130,35 +136,42 @@ sequenceDiagram

 有一处同词须点明：target type `world`（世界观总纲，一个具体结构型）与 domain `world`（世界事实语义域）字面相同却分属两轴，前者是「型」、后者是「域」，不是一回事。

-### 4.3 结构本体全清单（20 型）
+### 4.3 结构本体全清单（23 型）

 下表是与两轴对齐后的 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` | 生成上下文 | 配套 |
+| 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，须同时占据「它是什么（实体/计划/画像/装置/范式）× 谁在何时消费（规划/写作/检查期）」平面上的一个空格位，且承载邻接型收编不了的字段合同；否则按三条规则降级：差异只能举例、给不出判据的**变体收进枚举**（如拍卖会、比武会）；属性可由他型查询导出的**投影收进读模型**（如时间线、关系网、伏笔看板）；离开某型无独立生命的**附属收进字段**（如金手指例外）。这条准绳兑现「类型可更多但边界必清晰」——品类增型走同一判据，判据说不出一句就降级，杜绝为拆而拆。
@ -187,7 +200,7 @@ scope 落座有两处最易被误判，须点明。`outline` 取 `work` 而非 c
 | `scene_pattern` | 公共 | 有「目标-推进-收束」完整结构的场景范式，枚举显式排除打斗与情感 ‖ 点装置→`craft`；跨场景公式→`trope` |
 | `trope` | 公共 | 规定「这条线接下来几章怎么走」的公式 ‖ 单场景流程→`scene_pattern`；本作品自己的计划→`outline`（挂引用） |

-四条外边界与型内判据同等效力：质量维度不进本体（模具与检尺分立，见 [专题-04](专题-04-生成质量门控与创作健康度设计方案.md)，两者单向咬合、不共享定义）；叙事运行态不进本体（Narrative State 是独立事实载体，见 [架构-02 §3 作品内容模型](架构-02-核心数据结构与双轨模型.md)，本体只提供其字段模具）；RAG 文档面不进本体（上传的百科语料是检索素材，非实例，除非经确认链落成作品实体）；品类特化与作品私有字段不进基础层，走开放集增型与作品级 override。
+四条外边界与型内判据同等效力：质量维度不进本体（模具与检尺分立，见 [专题-04](专题-04-生成质量门控与创作健康度设计方案.md)，两者单向咬合、不共享定义）；叙事运行态的事实载体独立（Narrative State 归 Content 聚合，见 [架构-02 §3 作品内容模型](架构-02-核心数据结构与双轨模型.md)；`narrative_state` 型只是它的字段模具，同容器型逻辑，不把状态实例当知识实体管理）；RAG 文档面不进本体（上传的百科语料是检索素材，非实例，除非经确认链落成作品实体）；品类特化与作品私有字段不进基础层，走开放集增型与作品级 override。

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

@ -207,7 +220,9 @@ scope 落座有两处最易被误判，须点明。`outline` 取 `work` 而非 c

 ### 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 统一读取器的作品分区输出。
+容器 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，叠加与继承

@ -215,12 +230,12 @@ scope 落座有两处最易被误判，须点明。`outline` 取 `work` 而非 c

 继承靠动态合成、不靠复制：系统不落 per-work schema 实例，读取时按投影版本动态合成。新作品开箱即有全部结构，因为全局 schema 天然生效、零初始化；容器上预留的品类包钩子默认空，即纯继承。

-系统内置的 base schema 出厂全集是 20 项，分四档，每档的开箱形态与可见性基线如下。
+系统内置的 base schema 出厂全集是 23 项，分四档，每档的开箱形态与可见性基线如下。

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

@ -255,7 +270,7 @@ scope 落座有两处最易被误判，须点明。`outline` 取 `work` 而非 c

 ## 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)）；检测、导出预检等非生成链路复用同一读取器，不各自重写取数与裁剪。
+`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」对称的滥用面。

--- a/design-docs/产品-02B-管理员控制台功能规格.md
+++ b/design-docs/产品-02B-管理员控制台功能规格.md
@ -287,9 +287,9 @@

 ### 3.9A 拆书公共属性本体与参考作品治理

-系统级拆书把管理员维护的属性本体、参考书档案与拆书产出统一收在治理面。这里只给管理入口与边界，属性本体的 20 型 target type 全清单、逐型字段合同与范式 lineage 读模型见 `专题-06-元数据驱动的智能体架构.md`。
+系统级拆书把管理员维护的属性本体、参考书档案与拆书产出统一收在治理面。这里只给管理入口与边界，属性本体的 target type 全清单、逐型字段合同与范式 lineage 读模型见 `专题-06-元数据驱动的智能体架构.md`。

- **拆书公共属性本体管理**：文风、节奏、技法、桥段、套路等小说公共属性以 MetaSchema 的 target type 承载，管理员在元结构定义（§3.3、§3.4）里增删类型、扩字段、调可见性；本体一变，拆书多抽、生成多用、检测多查。这 20 型四档（作品身份／创作骨架／画像技法／系统侧）是元结构管理面的固定内容，不新起页面。
+- **拆书公共属性本体管理**：文风、节奏、技法、桥段、套路等小说公共属性以 MetaSchema 的 target type 承载，管理员在元结构定义（§3.3、§3.4）里增删类型、扩字段、调可见性；本体一变，拆书多抽、生成多用、检测多查。这套四档本体（作品与结构身份／创作骨架／画像技法／系统侧）是元结构管理面的固定内容，不新起页面。
 - **参考作品治理**：参考作品档案（`reference_work`，落全局知识库 document 特化）登记书名、作者、品类等标识，维护版权授权状态（`licensed`／`public_domain`／`research_only`／`unauthorized`，其中 `unauthorized` 失败关闭、不进任何拆书任务）与拆书处理状态（`pending`／`parsing`／`extracted`／`curated`／`failed`）；每条进全局库的范式可按 lineage 查“某本书贡献了哪些范式”，版权收紧时经来源状态传播阻断派生范式的新使用、不回滚已确认。
 - **系统级拆书任务与管理员确认队列**：管理员发起参考书拆书任务后，按公共属性 target type 抽出的范式先入待确认队列（Shadow）；管理员逐条确认后，经「管理员确认系统级知识草稿 → 全局知识库范式 Canonical」入口落库（见 `架构-02 §1.2`），成为可被作品显式绑定的系统来源。

--- a/design-docs/内容映射表.md
+++ b/design-docs/内容映射表.md
@ -187,9 +187,9 @@
 - 元数据驱动的智能体架构（横切）：主文档 `专题-06-元数据驱动的智能体架构.md`，owns 六个概念——
  - 元数据驱动的智能体架构：agent = f(作品 + 元数据 + 知识库)，元引擎 + 功能链双枢
  - 三体关系：muse-cloud（主权）/ dify-agent（能力执行）/ dify-rag（检索基座）/ New-API（模型网关）
-  - target type 结构本体：20 型清单 + domain 逐值语义 + 拆分判据（术语权威仍在 `架构-02` §9）
+  - target type 结构本体：23 型清单 + domain 逐值语义 + 拆分判据（术语权威仍在 `架构-02` §9）
  - 统一创作数据读取器：AI 上下文的服务端读合同（三级裁剪、fail-closed omittedSources）
-  - base 内置种子清单：20 项四档全局 schema 的叠加与继承机制
+  - base 内置种子清单：23 项四档全局 schema 的叠加与继承机制
  - 拆书通用抽取与参考作品：`reference_work` 档案 + 范式 lineage（Global/Local KB 两处浇铸）
 - 状态机与约束：主文档 `架构-04-状态机与约束清单.md`
 - 后端模块职责：主文档 `后端-02-工程结构与模块职责.md`
--- a/design-docs/后端-04-统一数据库Schema-v1.md
+++ b/design-docs/后端-04-统一数据库Schema-v1.md
@ -362,7 +362,7 @@ MetaSchema 是独立模块 `yudao-module-meta` 的元结构定义，由管理后
 | `published_by` / `published_at` | 发布人和发布时间 |
 | `activated_by` / `activated_at` | 激活人和激活时间 |

-`muse_meta_field` 的 `storage_binding` 存储映射（DDL 随 W1 迁移落地）标注每个字段的物理落点：`native_column`（映射 Work 等聚合的固定列，如 `novel_work` 容器 schema 对 `muse_content_work` 的 title / genre / status 等列）、`extension_json`（扩展字段落 jsonb）、`computed`（回算字段，`userEditable=false`）。它承载容器 schema 对既有固定列的元描述，使 MetaSchema 不复制事实载体（对齐 `架构-02 §9`）。系统内置 base schema 的种子目标清单（20 项四档：作品身份 / 创作骨架 / 画像技法 / 系统侧）由 `专题-06-元数据驱动的智能体架构.md` 定义，本册不复制清单。
+`muse_meta_field` 的 `storage_binding` 存储映射（DDL 随 W1 迁移落地）标注每个字段的物理落点：`native_column`（映射 Work 等聚合的固定列，如 `novel_work` 容器 schema 对 `muse_content_work` 的 title / genre / status 等列）、`extension_json`（扩展字段落 jsonb）、`computed`（回算字段，`userEditable=false`）。它承载容器 schema 对既有固定列的元描述，使 MetaSchema 不复制事实载体（对齐 `架构-02 §9`）。系统内置 base schema 的种子目标清单（四档：作品与结构身份 / 创作骨架 / 画像技法 / 系统侧）由 `专题-06-元数据驱动的智能体架构.md` 定义，本册不复制清单。

 约束：

--- a/design-docs/架构-02-核心数据结构与双轨模型.md
+++ b/design-docs/架构-02-核心数据结构与双轨模型.md
@ -255,7 +255,7 @@ MetaSchema 不负责：

 `uiVisible=false` 不等于不能参与 AI；`aiContext=true` 不等于用户可见；`exportable=true` 仍必须受 owner、授权、来源状态和导出许可约束。

-MetaSchema 的结构本体按 `domain` 与 `scope` 两根正交轴定位每个目标类型；下面三小节补齐此前 canonical 未写明的语义地基。结构本体的 20 型 target type 全清单（两轴对齐）、逐型字段合同与统一创作数据读取器合同，owner 在 `专题-06-元数据驱动的智能体架构.md`，本节只定义语义与叠加规则，不复制清单。
+MetaSchema 的结构本体按 `domain` 与 `scope` 两根正交轴定位每个目标类型；下面三小节补齐此前 canonical 未写明的语义地基。结构本体的 target type 全清单（两轴对齐）、逐型字段合同与统一创作数据读取器合同，owner 在 `专题-06-元数据驱动的智能体架构.md`，本节只定义语义与叠加规则，不复制清单。

 **domain 逐值语义**

--- a/docs/agent-specs/2026-07-08-AI能力与元数据驱动智能体架构-设计评审.md
+++ b/docs/agent-specs/2026-07-08-AI能力与元数据驱动智能体架构-设计评审.md
@ -1,11 +1,11 @@
 # 系统 AI 能力全景 · 元数据驱动的智能体架构（设计 · 评审版）

- 版本：v0.2（评审版，未执行）
+- 版本：v0.3（评审版，未执行）
 - 更新日期：2026-07-08
 - 目标读者：创始人 / 架构 / 后端 / 前端 / 产品
 - 边界说明：本文回答四个悬而未决的架构问题——系统需要多少个 LLM 智能体、它们与 Dify 的关系、知识库如何分层、拆书如何完善系统级知识。术语以 `架构-02-核心数据结构与双轨模型.md` 为准；BC 边界见 `架构-01`；AI 链路合同见 `专题-03`；外部适配见 `专题-05`。本文是**评审版**：讲清 WHAT 与 WHY，供拍板；执行版与 canonical 落点见第八节，评审通过后再动代码与正式分册。
 - 事实基线：结论区分「已验证事实（读到代码/文档）/ 设计意图 / 待决策」。代码现状来自 2026-07-08 对 `muse-module-ai`、`muse-module-knowledge`、`muse-module-meta` 的只读盘点。
- 变更记录：v0.2（2026-07-08）整合 Fable 边界分析与创始人三项材料级拍板（功能链归属案 A、双轨 Canonical 入口增补、参考作品库位案 A）及四项默认落定；补 domain 逐值语义与对齐后 20 型本体清单，新增统一创作数据读取器、作品容器建模、base 叠加与 storage_binding 存储映射；执行计划 W1 种子扩为 20 项四档、W8 双轨入口标记解锁。
+- 变更记录：v0.3（2026-07-09）结构本体补全 `chapter`/`scene`/`narrative_state` 三型（scope 轴七值全挂靠），种子清单以专题-06 §5 为准（23 项）。v0.2（2026-07-08）整合 Fable 边界分析与创始人三项材料级拍板（功能链归属案 A、双轨 Canonical 入口增补、参考作品库位案 A）及四项默认落定；补 domain 逐值语义与对齐后 20 型本体清单，新增统一创作数据读取器、作品容器建模、base 叠加与 storage_binding 存储映射；执行计划 W1 种子扩为 20 项四档、W8 双轨入口标记解锁。

 ---

@ -330,7 +330,7 @@ Local KB **不在知识库工作台直接编辑**，只通过作品工作台的

 一处同词提醒：target type `world`（世界观总纲，一个具体的结构型）与 domain `world`（世界事实语义域）字面相同却分属两轴——前者是"型"、后者是"域"，不是一回事。

-**A. 结构本体（对齐后 20 型 · domain/scope 两轴 · Fable 边界精炼）**
+**A. 结构本体（对齐后 20 型 · domain/scope 两轴 · Fable 边界精炼；2026-07-09 补全 chapter/scene/narrative_state 至 23 型，全清单以专题-06 §4.3 为准）**

 下表是与两轴对齐后的 target type 全清单，给的是归属、粒度与落地状态的总览；逐型的字段合同与边界判据见其后的分组详表。

@ -409,7 +409,7 @@ scope 落座有两处最容易被误判，须点明。`outline` 取 `work` 而

 **四条外边界**（与型内判据同等效力）：质量维度（`专题-04` 11 维）不进本体——模具↔检尺，见 §6.2 C，不共定义；Narrative State 不进本体——运行态是独立事实载体（`架构-02 §3`），本体只提供其字段模具；RAG 文档面不进本体——上传的百科语料是检索素材，非 faction/event 实例（除非经确认链落成作品实体）；品类特化与作品私有不进基础层。

-**MECE 自检结论**：修复 6 处重叠（scene_pattern 枚举排除打斗/情感、爽点按值类型劈、打脸戏机制归 craft/流程归 scene_pattern 双面正交、物品描述档案归 item/笔法归 style、说话方式/文风按归属主体劈、character_relation/Knowledge-Relation 物化判据钉死）+ 堵 5 处缺口（卷级大纲→outline 分层字段、描写素材范式→style 公共层、非武力对抗→scene_pattern 博弈类、种族血脉按判据裁决、功法技能=开放集首验件不进基础层）；显式封死伪型候选（时间线/关系网/势力地图/伏笔看板=投影，代入感/爽感=效果词，字数/更新/书名=运营面）。**层次全景（结构本体骨架 17 型）：结构骨架 9（work_core/outline/world/location/faction/power_system/item/event/character_relation）+ 双层 4（character/style/pacing/craft）+ 公共参考 4（combat/emotion/scene_pattern/trope）**；对齐 domain/scope 后再并入容器 `novel_work`、系统侧 `reference_work`、配套 `generation_context`，合计 20 型（见上文 A 表）。
+**MECE 自检结论**：修复 6 处重叠（scene_pattern 枚举排除打斗/情感、爽点按值类型劈、打脸戏机制归 craft/流程归 scene_pattern 双面正交、物品描述档案归 item/笔法归 style、说话方式/文风按归属主体劈、character_relation/Knowledge-Relation 物化判据钉死）+ 堵 5 处缺口（卷级大纲→outline 分层字段、描写素材范式→style 公共层、非武力对抗→scene_pattern 博弈类、种族血脉按判据裁决、功法技能=开放集首验件不进基础层）；显式封死伪型候选（时间线/关系网/势力地图/伏笔看板=投影，代入感/爽感=效果词，字数/更新/书名=运营面）。**层次全景（结构本体骨架 17 型）：结构骨架 9（work_core/outline/world/location/faction/power_system/item/event/character_relation）+ 双层 4（character/style/pacing/craft）+ 公共参考 4（combat/emotion/scene_pattern/trope）**；对齐 domain/scope 后再并入容器 `novel_work`、系统侧 `reference_work`、配套 `generation_context`，合计 20 型（见上文 A 表；2026-07-09 补全 chapter/scene/narrative_state 至 23 型）。

 > **你点名的 15 维度全部有归属**：文风→`style`；叙事→`style`(视角)+`pacing`+`trope`；文采→`style`；转折/反转→`craft`枚举；节奏→`pacing`；抓手→`craft`(钩子)；套路→`trope`；打斗→`combat`；情感→`emotion`；人设→`character`；物品描述→`item`(档案)+`style`公共层(笔法)；伏笔→`craft`定义(+`outline`引用)；爽点→`craft`(构成)+`pacing`(分布)；桥段→`scene_pattern`(+combat/emotion 特化)。

@ -429,7 +429,7 @@ scope 落座有两处最容易被误判，须点明。`outline` 取 `work` 而

 **seed 现状要如实纠正（反假绿）**：生产迁移 V1–V37 **零 MetaSchema seed INSERT**（已验真），`work_core`/`setting` 只存在于测试 fixture 与文档示例——评审稿此前"当前 seed 仅 work_core + setting"的说法要弱化到这一格，W1 的真实起点比原以为的更低。

-**系统内置 base schema 清单（W1 种子目标全集 = 20 项四档）**——这也修正了评审稿 W1 原列 11 类与本节型清单的内部不一致：
+**系统内置 base schema 清单（W1 种子目标全集 = 23 项四档，以专题-06 §5 为准；2026-07-09 补 chapter/scene/narrative_state）**——这也修正了评审稿 W1 原列 11 类与本节型清单的内部不一致：

 | 档 | 开箱形态 | schema | 可见性基线 |
 |---|---|---|---|
@ -513,7 +513,7 @@ scope 落座有两处最容易被误判，须点明。`outline` 取 `work` 而
 | 决策 | 结论 |
 |---|---|
 | **落地深度与节奏** | **全量接通**：本轮把 MetaSchema + FunctionChain 真正接进 AI runtime（生成/拆书/质检按 schema 定产出、按功能链编排、两套槽位收敛）一次到位，不分期。这是跨 meta+ai+knowledge 的结构性改造，执行计划见第八节。 |
-| **元数据类型清单（6.2）** | **认可全量**：结构本体经 Fable 边界精炼、并与 domain/scope 两轴对齐后定稿 **20 型**（分 5 个本体分组，每型带 MECE 边界判据），全落为 MetaSchema target types（剩余待确认见 6.2 D）；质量维度沿用 `专题-04`；两类不重复定义。元数据整体按用途分 5 个**元数据用途类**（结构本体/质量维度/编排/智能体配置/可见策略）。 |
+| **元数据类型清单（6.2）** | **认可全量**：结构本体经 Fable 边界精炼、并与 domain/scope 两轴对齐后定稿 **20 型**（分 5 个本体分组，每型带 MECE 边界判据），全落为 MetaSchema target types（剩余待确认见 6.2 D；2026-07-09 补全至 23 型，以专题-06 为准）；质量维度沿用 `专题-04`；两类不重复定义。元数据整体按用途分 5 个**元数据用途类**（结构本体/质量维度/编排/智能体配置/可见策略）。 |
 | **拆书公共属性 SoT 归属** | 落为 MetaSchema target types（管理员在 `产品-02B` 元结构台维护）+ 收口时新建 `专题-06` 定义本体（见第九节）。 |
 | **全局库检索方式** | **显式绑定**，不自动注入（见 5.3）。 |
 | **知识实体强绑 MetaSchema** | **强绑**：`muse_knowledge_entity.entity_type` 改为引用 schema_key（target type），实体字段按 MetaField 结构存——这样"元数据变→实体结构变"才真正闭环（纳入第八节工作项）。 |
@ -532,7 +532,7 @@ scope 落座有两处最容易被误判，须点明。`outline` 取 `work` 而

 | # | 工作项 | 模块 | 做什么 | 依赖 |
 |---|---|---|---|---|
-| W1 | **元数据本体落库** | meta | 落 20 项 target type 的生产种子（四档全集见 §6.2 base 清单：作品身份档 novel_work/work_core、创作骨架档 outline/world/location/faction/power_system/item/event/character/character_relation、画像技法档 style/pacing/craft/combat/emotion/scene_pattern/trope、系统侧档 reference_work/generation_context）+ 字段/枚举/校验；并入 `storage_binding`——`muse_meta_field` 增 native_column/extension_json/computed 属性，描述容器 schema 对 Work 固定列的落点 | — |
+| W1 | **元数据本体落库** | meta | 落 23 项 target type 的生产种子（四档全集以专题-06 §5 为准：作品与结构身份档 novel_work/chapter/scene/work_core、创作骨架档 outline/world/location/faction/power_system/item/event/character/character_relation/narrative_state、画像技法档 style/pacing/craft/combat/emotion/scene_pattern/trope、系统侧档 reference_work/generation_context）+ 字段/枚举/校验；并入 `storage_binding`——`muse_meta_field` 增 native_column/extension_json/computed 属性，描述容器 schema 对 Work 固定列的落点 | — |
 | W2 | **MetaSchema → AI 上下文** | meta→ai | AI 上下文组装消费 `MetaProjection`：按 `aiContext` 裁字段、按 target type 定输出合同；`AiContextUsageContributor` 的 `verifiedZero` 改真实消费 | W1 |
 | W3 | **Local KB 实体强绑 schema** | knowledge+meta | `muse_knowledge_entity.entity_type` 引用 schema_key；实体字段按 MetaField 结构存（jsonb + schema 校验） | W1 |
 | W4 | **拆书元数据化** | ai+knowledge | 拆书 Agent 按 target type 产**结构化实体草稿**（替代现 title+content 章节切分）；接"每确认章 → 拆书抽实体 + 质检一致性"触发 | W2,W3 |
@ -555,7 +555,7 @@ scope 落座有两处最容易被误判，须点明。`outline` 取 `work` 而

 三项材料级决策与默认落定已拍（§0、§7.2），评审核心结论通过，canonical 分册可开工。按单一归属把内容蒸馏进正式分册，并在 `00-文档大纲.md` 与 `内容映射表.md` 注册。目标改动清单：

- **新增 `专题-06-元数据驱动的智能体架构.md`**：owner 收口这套横切架构——元引擎 + 功能链驱动智能体、拆书通用抽取、三体关系、**target type 本体（对齐后 20 型 + domain/scope 两轴）、统一创作数据读取器、base 种子清单**（当前散落在专题-03/05、架构-02，需一个 owner）。
+- **新增 `专题-06-元数据驱动的智能体架构.md`**：owner 收口这套横切架构——元引擎 + 功能链驱动智能体、拆书通用抽取、三体关系、**target type 本体（对齐后 20 型，2026-07-09 补全至 23 型 + domain/scope 两轴）、统一创作数据读取器、base 种子清单**（当前散落在专题-03/05、架构-02，需一个 owner）。
 - **修订 `架构-02`**：§1.2 双轨 Canonical 入口封闭枚举 +1（管理员确认系统级知识草稿→Global KB 范式）；分区表补功能链行（定义归 Meta、运行编排归 AI）；§9 补 domain 逐值语义与 **override 只增不改** 推论。
 - **修订 `后端-04`**：功能链表名与归属订正为 `muse_meta_function_chain*` 归 meta；示例 `character_entity`→`character`；`muse_meta_field` 增 `storage_binding`（native_column/extension_json/computed）；补 base 种子清单。
 - **修订 `架构-01 §3.3`**：功能链落地矩阵行（定义归 Meta、AI runtime 经 `FunctionChainQueryApi` 读激活链编排）。