设计自定义元模型

元模型定义对象的结构，元数据是按该结构记录的实际内容。数据库和 REST API 等已有预置模型的资产优先使用预置模型；企业特有对象再考虑自定义。

四类要素

要素	含义	设计时应回答的问题
模型	某类资产的整体结构	管理什么范围
对象	具体实体类型	有哪些对象层级
属性	对象特征	每类对象记录什么信息
关系	层级、引用或业务关联	对象之间如何连接

设计前画出对象和关系，确定标识、名称、描述等公共属性。不要为了未来可能需求一次加入大量无用途字段。

创建模型

1. 进入“元模型”，创建新模型。
2. 填写代码、名称和描述。代码用于识别与引用，应稳定且具有业务含义。
3. 进入模型编辑页面。ID、GUID 由系统生成，不支持人工修改。
4. 核对模型数据区与模型结构区，随后建立对象、属性和关系。

模型编辑中的修改实时保存。生产模型调整前应先评估采集、模板和现有数据的影响，不要把关闭页面视为取消修改。

基本信息怎么填写

字段	用途	建议
代码	系统识别模型的稳定标识	使用有业务含义的英文编码，创建后尽量不改
名称/别名	页面展示和业务识别	中文名称表达管理对象，避免使用项目临时简称
描述	说明模型目标和范围	写清适用系统、责任团队和不包含的对象
ID、GUID	平台内部标识	由系统生成，不手工维护

一个模型代码只对应一套结构。若新旧结构必须并行，先建立独立模型或评估迁移策略，不要直接覆盖生产模型。

组装模型结构

1. 在“对象”集合中建立业务对象，填写名称、别名、描述及展示图标。
2. 如需作为资产目录中的资产类型，按设计设置是否允许注册到数据资产。
3. 在“属性”集合统一定义属性。同义属性尽量复用，避免各对象重复创建。
4. 为属性设置显示控件、分组名、显示顺序号；未分组属性进入默认分组。
5. 回到对象，通过“关联属性”选择已有属性。
6. 使用“关联对象”建立层级和业务关系。
7. 编辑模型根节点，关联公共基础属性，再关联业务对象。

根节点关联不可省略。 只创建对象集合与属性集合，没有把它们组装到根节点，可能导致模板不能生成、导入失败或展示不完整。

图示标出业务对象、基础属性与根节点的关联位置；对象名称按实际模型设计填写。

五步设计检查

第一步：创建对象集合

先列出真正需要管理的实体类型，例如 Agent、Goal、Knowledge、Memory 和 Model。对象不是一条数据记录，而是详情页和权限边界的类型。需要作为数据资产发布的对象，才开启“允许注册到数据资产”。

第二步：创建属性集合

在属性集合中统一定义属性，重复含义只建立一次。为属性设置控件类型、分组名和显示顺序；日期、枚举和长文本应选择适合的控件，避免全部使用普通字符。

第三步：关联属性

回到对象集合，使用“关联属性”选择已经定义的属性。关联不是复制属性，后续修改公共属性可能影响多个对象，修改前检查引用对象。

第四步：建立对象关系

使用“关联对象”表达父子、引用、依赖和业务关联。关系名称应说明方向和语义；不要把“可能相关”直接建成强依赖关系，避免搜索和影响分析产生误导。

第五步：组装根节点

根节点是模型实例的入口。先关联公共属性（例如 ID、名称、逻辑名称、定义），再关联业务对象集合。完成后用模板预览检查根节点、对象层级和属性分组。

设计原则

• 业务驱动：从要管理的业务对象出发，而不是从数据库表结构出发。
• 简洁：先保留支撑任务的核心属性，后续按真实需求扩展。
• 稳定：核心对象、属性编码和关系方向投入使用后尽量不变。
• 可扩展：预留扩展属性和新对象的边界，但不要预先创建无用途字段。
• 统一命名：对象、属性和关系采用同一命名规范，并在描述中记录业务定义。

发布前验收

用少量样例完成以下检查：

1. 模板可以生成，根节点 ID/Name 规则正确。
2. 对象树能按预期展开，父子关系没有循环。
3. 详情页的属性分组和顺序符合业务阅读习惯。
4. 可注册资产的对象能被目录类型选择，其他对象不会误出现在资产注册入口。
5. 采集、导入和血缘关系使用的对象标识一致。

验证设计

在少量示例对象上验证模板生成、父子关系、属性分组及展示顺序。检查名称是否唯一、层级是否符合业务、属性是否被错误重复定义。确认后按元模型导入建立实际数据。

对象关系只表达所定义的关联；需要加工血缘时，应另行提供源目标关系，不能假设所有对象关系自动成为血缘。