> 译文仅供阅读便利。具有规范效力的是英文原文。 # 参考仓库 **元宇宙规范** **文档编号：** MU-V2-REFARCH-006 **标题：** 标准仓库示例 **文档类别：** 说明性 **版本：** 2.0（草案） **状态：** 工作草案 **规范性引用：** 元宇宙宪章（MUC）、MMAS、MUFP **说明性引用：** Architecture、Naming Examples **版权：** © Orkestron.AI **许可：** Apache-2.0 --- # 1. 目的 本文档为符合元宇宙的规范、领域元模型与语义包，规定推荐的仓库结构。 参考仓库提供一套共同的组织模型，以提升可发现性、互操作、治理与长期可维护性。 这一结构作为参考架构而被推荐，在有正当理由时可以调整 - 只要不违反 MUC、MMAS 或 MUFP。 --- # 1a. 元宇宙也是一套知识发布标准 元宇宙不只是*构建*语义模型的办法；它同时也是*发布*语义模型的标准。这一族标准把职责划得干净： - **MMAS** 规定*如何构建*模型 - 它们的架构、版本管理与校验。 - **MUC** 规定一切模型与一切交换都要遵守的*法*。 - **MUFP** 规定模型在主权宇宙之间*如何交互*。 - **参考仓库**（即本文档）规定*模型如何发布* - 那一套共同的组织形态，使知识变得可被发现、可被核验、可被联邦。 这与其他生态把创建与发布分开的做法如出一辙。Git 保存历史；GitHub 发布代码。OpenAPI 发布 API。OCI 发布容器。本着同样的精神，**元宇宙发布语义模型** - 而参考仓库就是那份正典布局，它让一份已发布的模型，在任何人或 AI 智能体撞见它时都能被认出来。 如此组织的仓库，本身就是它所含知识的一种投影：一片可预期的表面，把基础、架构、联邦、核心概念、领域模型与指南摆在已知的位置、配以已知的元数据，使消费方无须事先商量便能穿行、校验并结成联邦。 --- # 2. 设计原则 合规的仓库应当是： - 可读于人的； - 可读于 AI 的； - 原生于 Git 的； - 模块化的； - 带版本的； - 可追溯的； - 可扩展的。 仓库的组织必须把语义上的清晰置于实现上的便利之前。 --- # 3. 正典仓库结构 推荐的顶层结构： ``` Repository/ ├── README.md ├── LICENSE ├── CHANGELOG.md ├── archive/ ├── 00-foundation/ ├── 01-constitution/ ├── 02-architecture/ ├── 03-federation/ ├── 04-core-concepts/ ├── 05-reference-architecture/ ├── 06-domain-models/ ├── 07-guides/ ├── examples/ └── schemas/ (optional) ``` 可以引入额外的目录，只要它们不改变仓库的语义含义。 --- # 4. 各目录的职责 **archive/** 存放为可追溯而保留的历史版本。 **00-foundation/** 愿景、原则、术语与术语表。 **01-constitution/** 规范性的宪章文档。 **02-architecture/** 架构标准（MMAS）。 **03-federation/** 联邦协议规范（MUFP）。 **04-core-concepts/** 作为地基的语义概念。 **05-reference-architecture/** 参考架构与架构模式。 **06-domain-models/** 可复用的领域元模型。 **07-guides/** 关于实施与迁移的说明性指引。 **examples/** 演示如何正确运用这些标准的示意性示例。 --- # 5. 对文档的要求 每一份规范性文档都应当写明： - 文档标识符； - 标题； - 版本； - 状态； - 类别； - 目的； - 结语。 文档应当各自独立可懂。 --- # 6. 命名约定 仓库的命名应当遵循 MMAS 的命名约定。 文件应当： - 取具描述性的名称； - 避免歧义； - 在各版本之间保持稳定。 规范性文件名不应当带上版本号。 --- # 7. 版本管理 仓库的演进必须遵循语义化版本。 历史发布应当继续可得。 破坏兼容的结构性改动必须伴随一个新的主版本。 --- # 8. 可追溯性 仓库中的制品必须保全： - 溯源； - 作者归属； - 版本历史； - 文档谱系； - 相关标准。 可追溯性必须贯穿仓库的整段历史。 --- # 9. 可扩展性 仓库可以包含： - 模式； - 契约； - 模板； - 校验资产； - 生成出来的制品； - 自动化资源。 这些扩展必须在语义上与参考结构保持兼容。 --- # 10. 校验 合规的仓库应当校验： - 必备目录； - 必备元数据； - 文档标识符； - 命名是否一致； - 版本是否一致； - 文档之间的交叉引用。 校验应当能够自动化。 --- # 11. 治理 每个仓库都必须标明： - 管辖权威； - 发布流程； - 所支持的标准版本； - 合规级别。 治理必须保持透明。 --- # 12. 架构不变量 合规的仓库必须保全： - 宪章合规； - 语义上的组织； - 可追溯性； - 模块性； - 长期可维护性。 仓库结构必须在不牺牲历史完整的前提下支撑语义演进。 --- # 未来方向 参考仓库讲的是单个仓库如何布局。顺理成章的下一步，是一份**元宇宙注册表规范**，讲清仓库如何*在规模上被发现与核验*，从而结成注册表的联邦。这样一份规范会让 AI 智能体得以： - 从一个众所周知的注册表入口自动发现元宇宙仓库； - 探明每个仓库支持哪些 MUC、MMAS 与 MUFP 版本； - 自动核验合规（必备目录、元数据、标识符、命名与交叉引用）； - 并在此基础上，无须人工配置便在各仓库之间建立联邦。 参考仓库让一份已发布的模型可被认出；注册表规范则会让*整个模型生态*变得可以穿行 - 这就好比单独一份已发布的 API，与一份收录所有已发布 API 的索引之别：后者让智能体能自行查询、核验并接入。 --- # 结语 参考仓库规定了元宇宙标准与元模型的正典组织方式。 采纳共同的仓库结构，发布方便让人与 AI 智能体得以在各自独立的仓库之间一致地发现、理解、校验并演进语义知识，同时在整个元宇宙生态中保全治理、可追溯与互操作。