《未来的信息基础设施建设草案》

Pixlout

384人浏览 · 2026-04-04 07:29:52

Pixlout · 2026-04-04 07:29:52 发布

《未来的信息基础设施建设草案》（v0.1）

编制说明：本草案基于“数据要素性的双层驱动模型”（逻辑层8大接口+事实层5大规范）与“智慧路由——Web4.0的新性能”提案，系统阐述未来信息基础设施的架构原则、技术增强方向与标准化需求。旨在为政策提供从“属性要求”到“工程落地”的技术桥梁。
协作者:DeepSeek

1 总则

1.1 编制目的

本草案旨在回答一个核心问题：如果数据是生产要素，信息基础设施应当如何重新设计？

传统信息基础设施（网络、计算、存储）以“连通性”和“计算效率”为核心目标，对数据的内容、价值、权属、安全等“要素属性”缺乏原生支持。本草案提出面向数据要素的新型基础设施架构，使基础设施从“管道”升级为“可信的价值载体”。

1.2 适用范围

本草案适用于以下领域的技术规划与标准制定：

下一代网络设备（路由器、网关、基站）的架构设计
计算芯片（CPU、SoC、安全芯片）的功能增强
编程语言与运行时环境的数据要素支持
软件系统的数据为中心架构设计
数据要素流通平台的基础设施层建设
开源鸿蒙（OpenHarmony）操作系统的安全与数据要素能力增强

1.3 核心原则

原则	说明
内容与载体分离	基础设施可观测、调度、保护数据，但不得篡改数据的固有属性（意义性、关联性、意图性等）
信任下沉	信任根从软件层下沉至硬件层，通过安全可信芯片+系统级安全飞地形成不可伪造的物理锚点
软硬件隔离	安全处理与通用处理物理或逻辑隔离，安全子系统由独立安全内核控制
属性原生	基础设施需原生支持数据要素属性的表达、携带、验证与执行
可验证性	所有关键操作（处理、流转、聚合）均应产生可加密验证的证据
分层增强	不推翻现有体系，而是在边界层（输入/输出、安全、元数据）进行针对性增强

2 架构总览

2.1 四层架构模型

未来信息基础设施自下而上分为四个层次，每一层对应不同的“数据要素性”职责：

┌─────────────────────────────────────────────────────────────┐
│  第4层：应用与服务平台层                                      │
│  （数据要素驱动的应用、数据交易市场、价值分配引擎）            │
│  职责：消费数据要素，实现价值闭环                            │
├─────────────────────────────────────────────────────────────┤
│  第3层：数据要素运行时层 / OpenHarmony 安全服务层             │
│  （数据操作系统、属性注册表、策略执行引擎、审计系统、          │
│   ───────────────────────────────────────────────────────    │
│   OpenHarmony安全子系统：HUKS密钥管理、设备认证、权限管理）    │
│  职责：管理数据要素属性的全生命周期                          │
├─────────────────────────────────────────────────────────────┤
│  第2层：计算与存储基础设施层                                 │
│  （增强型CPU/TEE、安全计量器、内存标签、可信存储、             │
│   ───────────────────────────────────────────────────────    │
│   安全可信芯片：独立安全内核、硬件密码引擎、防篡改封装）       │
│  职责：提供可信执行环境与可验证计量                          │
├─────────────────────────────────────────────────────────────┤
│  第1层：网络基础设施层                                       │
│  （智慧路由器、可信网关、边缘节点）                          │
│  职责：可信采集、本地聚合、属性感知调度                      │
└─────────────────────────────────────────────────────────────┘

2.2 与数据要素属性的映射

层级	主要负责的数据要素属性	核心机制
网络层	区间性、实体性（部分）、时间性	载体哈希链、硬件签名、可信时间戳
计算层	实体性（根）、资源性（计量）、安全性	安全可信芯片、TEE、安全计量器、内存标签
运行时层	意义性（评估）、关联性（发现）、加工性（执行）	属性注册表、策略引擎、数据血缘追踪
应用层	确权性（收益分配）、应用性（SLA保障）	智能合约、价值分配引擎

3 网络基础设施层规范

3.1 智慧路由器的架构要求

智慧路由器是网络层的核心设备，应在传统路由功能之上增加以下数据要素处理能力。

3.1.1 硬件增强要求

组件	要求	对应属性
安全飞地	独立于主处理器的安全协处理器，用于密钥管理、签名生成	实体性、区间性
硬件真随机数发生器	符合国家密码管理局要求的TRNG	安全性
可信时间戳模块	硬件级实时时钟，防篡改	时间性
安全芯片（可选）	通过安全芯片生态认证的硬件安全模块	实体性、安全性

3.1.2 数据处理职责边界（重要）

智慧路由器不得改变以下数据固有属性：

属性	路由器职责	禁止行为
意义性	观测与上报流量模式	不得丢弃“低意义性”数据而不通知
关联性	发现并证明数据流向关联	不得伪造关联关系
意图性	验证并执行意图标签对应的策略	不得修改意图标签
实体性	用自己的硬件签名绑定来源证据	不得冒充其他实体

智慧路由器应当增强以下工程属性：

属性	路由器职责	实现方式
区间性	定义“事中”区间并记录载体哈希	载体哈希链（PRE/MID/POST）
资源性	本地聚合、过滤，降低成本	无效交易过滤、批量提交
加工性	执行允许的聚合、匿名化操作	策略即代码（OPA）
应用性	保障数据流的SLA	QoS、智能选路
安全性	加密传输、访问控制	IPsec、MACsec

3.1.3 数据格式扩展要求

智慧路由器应支持以下新增元数据的处理与携带：

元数据类型	格式要求	说明
W4地址	`Hash(根密钥 \|\| 网络指纹 \|\| 时间因子)`	复合身份标识
载体哈希链	有序列表，每项含`{stage, hash, type, timestamp}`	区间性追踪
意图标签	`{source_type, purpose_tags, consent_ref}`	意图性表达
硬件签名	安全飞地对数据包的签名	实体性证明
可信时间戳	ISO 8601格式，硬件签名	时间性锚定

3.2 边缘节点与网关

除路由器外，以下设备也应具备类似的数据要素处理能力：

家庭网关、企业网关
5G基站（边缘计算节点）
物联网网关

4 计算与存储基础设施层规范

4.1 安全可信芯片架构（修订）

核心设计原则：不要求每个芯片内置物理不可克隆函数（PUF），而是采用**“安全可信芯片+系统级安全飞地”**的架构，实现软硬件隔离的安全级别。

4.1.1 安全可信芯片的参考架构

参考中移芯昇CM32M435R等已通过OpenHarmony生态认证的安全MCU芯片设计：

┌─────────────────────────────────────────────────────────────┐
│                      安全可信芯片                            │
├─────────────────────────┬───────────────────────────────────┤
│     通用内核             │         安全内核（独立）           │
│   （RISC-V/ARM）         │     （负责安全子系统）             │
│                         │                                   │
│  • 主业务处理           │  • 密钥管理（HUKS）               │
│  • 网络协议栈           │  • 安全存储                       │
│  • 应用程序             │  • 加密运算                       │
│                         │  • 访问控制决策                   │
└─────────────────────────┴───────────────────────────────────┘
                              ↑
                    ┌─────────┴─────────┐
                    │   硬件隔离边界     │
                    │ （安全飞地）       │
                    └───────────────────┘

关键特性：

特性	说明	对应数据要素属性
双核独立	通用内核+安全内核，安全子系统由安全内核独立控制	安全性、实体性
可信执行环境（TEE）	提供隔离的执行环境，支持蓬莱等开源TEE方案	安全性、加工性
硬件密码引擎	内置AES、SM4等加密算法加速器	安全性
防篡改封装	物理防篡改设计，防御侧信道攻击	安全性
安全启动	基于硬件可信根的启动时完整性验证	实体性

注意：PUF（物理不可克隆函数）作为可选增强特性，不作为强制要求。不具备PUF的芯片可通过安全内核+密钥管理服务实现等效安全级别。

4.1.2 可信执行环境（TEE）的标准化

未来通用计算芯片应标配或可选配TEE能力。参考蓬莱TEE系统在RISC-V架构上的实践：

要求	说明	参考实现
隔离执行	安全世界与普通世界物理或逻辑隔离	RISC-V PMP/sPMP/WorldGuard
远程认证	可向第三方证明TEE内运行的代码身份	蓬莱TEE认证机制
密封存储	TEE内数据可加密绑定到特定平台或代码	HUKS密钥管理服务
低开销	TEE切换开销 < 1000个时钟周期	蓬莱“懒检查”机制

4.1.3 安全计量器（可选增强）

在CPU内部增加仅可由TEE访问的计量单元：

组件	功能	对应属性
单调计数器	记录数据使用次数，只增不减	资源性、确权性
计量寄存器	累计计算量（核·秒）	资源性
流量计数器	累计数据传输量	资源性

4.1.4 内存隔离机制

参考RISC-V架构的内存隔离演进：

机制	适用场景	说明
PMP（物理内存保护）	轻量系统、无MMU设备	粗粒度内存隔离，最多16个区域
sPMP（监督模式PMP）	小型系统	蓬莱提出的轻量级隔离，补齐OS-用户态隔离
WorldGuard	标准系统、多World隔离	RISC-V国际协会提案，系统级硬件隔离
内存标签扩展	高级安全场景	细粒度访问控制，可选增强

4.2 存储设备增强要求

4.2.1 可信存储

支持硬件级加密（如AES-256、SM4）
支持锁定到特定设备（防拔出后读取）
支持安全删除（物理级不可恢复）

4.2.2 存储分层与属性感知

根据数据要素的意义性评分自动选择存储层级（HOT/WARM/COLD/ARCHIVE）
根据时间性自动执行过期数据迁移或删除

5 数据要素运行时层规范

5.1 数据操作系统（Data OS）

在传统操作系统之上，增加“数据要素”管理能力。

5.1.1 核心组件

组件	功能
属性注册表	存储所有数据要素的逻辑层与事实层属性，支持版本管理
策略执行引擎	根据属性执行访问控制、加工限制、安全策略
数据血缘追踪器	记录数据派生关系，支持溯源查询
审计日志系统	不可篡改地记录所有数据操作，防篡改

5.1.2 与现有OS的关系

不取代Linux/Windows/OpenHarmony等通用OS
作为OS的扩展模块或用户态服务运行
通过系统调用或库函数向上层暴露数据要素API

5.2 属性驱动的处理流水线

数据处理函数的调度由数据属性触发：

触发条件	调度动作
`意义性 > 0.8`	进入高性能处理队列
`时间性 = REAL_TIME`	分配低延迟计算资源
`安全性 = L4_RESTRICTED`	仅在TEE内处理
`实体性 = 特定企业`	触发收益分成结算

5.3 可验证计算支持

关键处理模块应输出零知识证明或TEE签名，证明计算过程正确
第三方（如数据交易所）可验证该证明，无需重跑计算

6 编程语言与软件设计规范

6.1 编程语言增强方向

6.1.1 数据要素属性注解

语言生态应支持数据要素属性的原生表达（示例使用Java注解风格）：

@DataElement(
    intentionality = Intentionality.USER_CREATED,
    significance = 0.85,
    entity = "did:example:123",
    timeliness = Timeliness.REAL_TIME
)
public class SensorReading {
    private double temperature;
    private long timestamp;
    // ...
}

6.1.2 不可变性与可审计性增强

推荐使用不可变数据结构（如Rust的所有权系统）
内置操作日志记录：@Audited 注解的方法自动记录调用上下文

6.1.3 跨语言属性交换格式

定义标准的“数据要素属性包”序列化格式（基于Protocol Buffers或CBOR）
确保属性在不同语言和系统间流通时语义一致

6.2 软件设计架构原则

6.2.1 从“功能为中心”到“数据为中心”

传统模式	新模式
先设计功能模块	先设计数据资产及其属性模型
数据是函数的被动参数	数据+属性是驱动核心
功能决定数据流向	属性决定处理路径

6.2.2 属性驱动的微服务

服务接口应声明其“消费”和“产出”的数据要素属性要求
服务发现机制应支持按属性要求筛选服务

6.2.3 可验证的软件供应链

代码签名 + TEE远程认证，形成“代码→编译→部署→运行”的全链路可验证

7 标准化需求清单

7.1 网络层标准

序号	标准名称	说明
1	《智慧路由器数据要素属性处理规范》	定义路由器对8+5属性的处理职责与边界
2	《W4地址格式规范》	定义复合身份标识的编码与解析规则
3	《载体哈希链数据结构规范》	定义区间性追踪的数据格式
4	《网络设备可信时间戳规范》	定义硬件时间戳的格式与验证方法

7.2 计算层标准

序号	标准名称	说明
5	《安全可信芯片接口规范》	定义安全内核与通用内核的通信协议
6	《TEE通用接口规范》	统一不同TEE（蓬莱/SGX/TrustZone）的编程接口
7	《安全计量器接口规范》	定义单调计数器、计量寄存器的访问协议
8	《内存隔离机制参考模型》	定义PMP/sPMP/WorldGuard的适用场景与配置

7.3 运行时与软件层标准

序号	标准名称	说明
9	《数据要素属性描述规范》	即此前草案，定义8+5属性的数据结构与API
10	《数据要素属性包序列化格式》	跨语言属性交换的二进制格式
11	《数据血缘追踪数据格式》	定义派生关系记录的标准格式

7.4 OpenHarmony对接标准（新增）

序号	标准名称	说明
12	《OpenHarmony安全子系统数据要素扩展规范》	定义HUKS、设备认证等模块对数据要素属性的支持
13	《蓬莱-TEE与OpenHarmony集成接口规范》	定义TEE安全服务的调用接口
14	《OpenHarmony数据要素属性描述文件格式》	定义应用包中数据要素属性的声明格式

8 与现有政策体系的对齐

本草案章节	对应政策文件	对齐说明
第3章（网络层）	《数据要素×》基础设施场景	智慧路由器是“可信数据流通”的物理锚点
第4章（计算层）	《数据科技创新实施意见》	安全可信芯片、TEE是“算力基础设施”的核心增强
第5章（运行时）	《国家数据标准体系建设指南》	属性注册表、策略引擎对应“数据服务标准”
第6章（软件）	数据基础制度（三权分置）	属性驱动设计支撑“数据产权”的可编程执行
第7章（标准）	全国数标委标准征集	本草案14项标准均为当前政策空白点
第10章（OpenHarmony）	开源生态建设、信创战略	对接国产操作系统生态，实现自主可控

9 实施路线图建议

阶段一：标准预研（2026-2027）

完成《数据要素属性描述规范》团体标准制定
启动智慧路由器原型验证
参与全国数标委标准验证试点
启动OpenHarmony安全子系统数据要素扩展设计

阶段二：技术验证（2027-2028）

完成TEE通用接口规范的行业共识
实现数据操作系统（Data OS）原型
在1-2个场景（如数据交易、物联网）完成闭环验证
完成蓬莱-TEE与OpenHarmony的深度集成验证

阶段三：规模推广（2029-2030）

形成3-5项国家标准或行业标准
智慧路由器进入运营商集采目录
数据要素属性支持成为主流软件框架的可选特性
OpenHarmony成为数据要素基础设施的推荐操作系统平台

10 与开源鸿蒙（OpenHarmony）操作系统的对接规范（新增）

10.1 对接概述

OpenHarmony作为面向全场景、全连接、全智能时代的开源操作系统，是未来信息基础设施的重要组成部分。本草案定义的数据要素属性模型应与OpenHarmony的现有安全架构深度融合，而非替代或重建。

10.2 OpenHarmony安全子系统概述

OpenHarmony安全子系统包括以下核心模块：

模块	功能	与本草案的对接点
HUKS（密钥管理服务）	提供密钥生成、存储、使用能力	对应`实体性`（身份锚定）、`安全性`
设备认证	分布式设备互联的密钥协商与可信设备管理	对应`实体性`、`关联性`
应用权限管理	应用权限定义、申请、授权	对应`意图性`、`加工性`
应用完整性校验	应用签名与验签	对应`实体性`、`区间性`
数据传输管控	跨设备数据传输的风险等级管控	对应`安全性`、`应用性`

10.3 对接架构

┌─────────────────────────────────────────────────────────────┐
│                    OpenHarmony 应用层                        │
│  （数据要素驱动的应用、FA/PA组件）                           │
├─────────────────────────────────────────────────────────────┤
│              OpenHarmony 框架层（ArkUI/Ability）             │
├─────────────────────────────────────────────────────────────┤
│              OpenHarmony 系统服务层                          │
│  ┌─────────────────────────────────────────────────────┐   │
│  │              安全子系统（扩展后）                     │   │
│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐   │   │
│  │  │  HUKS   │ │设备认证 │ │权限管理 │ │数据要素 │   │   │
│  │  │（扩展） │ │（扩展） │ │（扩展） │ │属性引擎 │   │   │
│  │  └─────────┘ └─────────┘ └─────────┘ └─────────┘   │   │
│  └─────────────────────────────────────────────────────┘   │
├─────────────────────────────────────────────────────────────┤
│           OpenHarmony 内核层（Linux / LiteOS）               │
│  ┌─────────────────────────────────────────────────────┐   │
│  │            TEE支持（蓬莱/OP-TEE）                    │   │
│  └─────────────────────────────────────────────────────┘   │
├─────────────────────────────────────────────────────────────┤
│                      硬件层                                 │
│  ┌─────────────────────────────────────────────────────┐   │
│  │       安全可信芯片（通过OpenHarmony生态认证）         │   │
│  └─────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

10.4 HUKS（密钥管理服务）的数据要素扩展

HUKS是OpenHarmony的密钥管理核心服务。本草案要求对HUKS进行以下扩展：

扩展项	功能	对应属性
密钥与数据要素绑定	密钥可关联特定的数据要素ID，实现“一数一密”	实体性、安全性
属性签名	使用HUKS管理的密钥对数据要素属性包进行签名	区间性、实体性
密钥用途标签	密钥创建时声明用途（如`PURPOSE_DATA_SIGN`），运行时强制校验	意图性
硬件根密钥支持	支持将密钥存储在安全芯片或TEE中，不可导出	安全性

HUKS扩展接口示例：

// 为数据要素生成专属密钥对
int HuksGenerateKeyForDataElement(
    const char *dataElementId,      // 数据要素ID
    const KeySpec *spec,            // 密钥规格
    const DataElementAttributes *attrs, // 数据要素属性（用于绑定）
    KeyHandle *outHandle            // 输出密钥句柄
);

// 使用数据要素绑定的密钥签名
int HuksSignWithDataElement(
    KeyHandle handle,               // 密钥句柄
    const DataElementAttributes *attrs, // 待签名的属性包
    const uint8_t *data, size_t dataLen,
    uint8_t *signature, size_t *sigLen
);

10.5 设备认证模块的数据要素扩展

OpenHarmony的设备认证模块提供分布式设备间的密钥协商和可信设备管理。扩展要求：

扩展项	功能	对应属性
W4地址集成	设备认证时可交换和验证W4地址	实体性、关联性
属性交换	认证过程中交换设备的数据要素处理能力（支持的属性类型）	应用性
信任传递	基于硬件签名的信任链，实现多跳信任传递	区间性

10.6 权限管理模块的数据要素扩展

OpenHarmony的权限管理模块控制应用对敏感API的访问。扩展要求：

扩展项	功能	对应属性
属性级权限	权限定义可关联数据要素属性（如`意义性>0.8`的数据需要特殊权限）	意义性、加工性
动态授权	根据数据要素的实时属性（如时效性）动态调整授权	时间性
使用留痕	敏感属性数据的访问自动触发审计日志	安全性

10.7 与TEE的集成：蓬莱-OpenHarmony

蓬莱（Penglai）是RISC-V架构上的开源TEE解决方案，已与OpenHarmony完成深度集成。

10.7.1 蓬莱-TEE的核心能力

能力	说明	对应本草案
可信执行环境	基于RISC-V PMP/sPMP的隔离执行	第4章TEE要求
内存隔离	支持MMU和无MMU平台的统一隔离模型	4.1.4内存隔离机制
远程认证	可向第三方证明TEE内运行状态	5.3可验证计算
轻量化设计	支持OpenHarmony轻量系统、小型系统、标准系统	全层级覆盖

10.7.2 蓬莱-TEE与数据要素属性的映射

蓬莱能力	本草案属性	对接方式
TEE内密钥管理	实体性、安全性	HUKS运行在TEE内
密封存储	区间性、安全性	载体哈希链存储在TEE密封空间
远程认证	可验证性	认证报告作为“加工性”证明
内存隔离	加工性、安全性	不同安全级别的数据在不同内存域处理

10.7.3 集成架构

参考蓬莱-OpenHarmony的官方架构：

┌─────────────────────────────────────────────────────────────┐
│                    OpenHarmony 用户态                        │
│  ┌─────────────────────────────────────────────────────┐   │
│  │              安全应用 / TEE SDK                       │   │
│  └─────────────────────────────────────────────────────┘   │
├─────────────────────────────────────────────────────────────┤
│                    OpenHarmony 内核态                        │
│  ┌─────────────────────────────────────────────────────┐   │
│  │            TEE驱动 / 共享内存管理                     │   │
│  └─────────────────────────────────────────────────────┘   │
├─────────────────────────────────────────────────────────────┤
│                      固件层（M-mode）                        │
│  ┌─────────────────────────────────────────────────────┐   │
│  │              蓬莱 Monitor                             │   │
│  │  • 内存隔离管理（PMP/sPMP）                          │   │
│  │  • 安全世界调度                                      │   │
│  │  • 远程认证服务                                      │   │
│  └─────────────────────────────────────────────────────┘   │
├─────────────────────────────────────────────────────────────┤
│                      硬件层                                 │
│  ┌─────────────────────────────────────────────────────┐   │
│  │     RISC-V CPU + 安全扩展（PMP/WorldGuard）          │   │
│  └─────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

10.8 安全芯片的OpenHarmony生态认证

本草案推荐采用已通过OpenHarmony生态认证的安全芯片，如中移芯昇CM32M435R：

特性	CM32M435R	对应本草案要求
架构	RISC-V通用内核+安全内核双核设计	4.1安全可信芯片架构
安全能力	PUF、TEE、防侧信道攻击	4.1.1安全可信芯片参考架构
密码算法	内置多种加密算法	4.1.1硬件密码引擎
鸿蒙认证	通过OpenHarmony生态认证	10.8生态认证要求

生态认证要求：

安全芯片应通过OpenHarmony生态产品兼容性认证
应提供适配OpenHarmony的TEE驱动和HUKS适配层
应参与OpenHarmony安全SIG的技术交流与规范制定

10.9 OpenHarmony数据要素属性描述文件

OpenHarmony应用包（HAP）应支持声明数据要素属性：

// entry/src/main/module.json5 扩展
{
  "module": {
    "name": "entry",
    "type": "entry",
    "dataElementAttributes": {
      "intentionality": "USER_CREATED",
      "entity": {
        "type": "APPLICATION",
        "signatureRef": "@cert:app_signature"
      },
      "security": {
        "complianceLevel": "L3_CONFIDENTIAL",
        "requiredTee": true
      },
      "dataFlow": {
        "inputPermissions": ["DATA_ELEMENT.READ"],
        "outputPermissions": ["DATA_ELEMENT.SIGN"]
      }
    }
  }
}

10.10 与OpenHarmony版本计划的对接

OpenHarmony版本	本草案对接计划
当前版本（3.2/4.0）	HUKS扩展接口设计、安全子系统增强提案
未来版本（5.0+）	原生支持数据要素属性、TEE深度集成
轻量系统（mini）	轻量级属性支持（子集实现）
小型系统（small）	完整属性支持（可选模块）
标准系统（standard）	完整属性支持+ TEE集成

（草案结束）

AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

TCM-Vision-7204条多模态中医药图像问答数据集-涵盖饮片药材舌诊手诊眼诊推拿全息7大类别-中医AI训练评测基准

AtomGit开源社区

EAAI title-page-template 怎么填写

AtomGit开源社区

AI辅助网文创作理论研究笔记（十七）：编排画布深化——从顺序发言到动态编排

本文探讨了AI小说创作中会议编排画布的优化方向，提出从固定流水线转向动态编排的方案。核心改进包括：1）将轮次控制改为灵活的发言权分配机制，支持@提及点名和多种退出条件；2）引入容器概念，可配置串行/并行、顺序/提及驱动等模式；3）世界书和RAG作为独立节点，支持多实例绑定；4）新增章节拆分师等专家角色；5）开发浮动工具栏优化交互。这些改进使画布从静态流程升级为动态协作空间，支持更自然的创作讨论。目

AtomGit开源社区

所有评论(0)

查看更多评论

Pixlout

@Pixlout

已为社区贡献4条内容

《未来的信息基础设施建设草案》

Pixlout

《未来的信息基础设施建设草案》（v0.1）

1 总则

1.1 编制目的

1.2 适用范围

1.3 核心原则

2 架构总览

2.1 四层架构模型

2.2 与数据要素属性的映射

3 网络基础设施层规范

3.1 智慧路由器的架构要求

3.1.1 硬件增强要求

3.1.2 数据处理职责边界（重要）

3.1.3 数据格式扩展要求

3.2 边缘节点与网关

4 计算与存储基础设施层规范

4.1 安全可信芯片架构（修订）

4.1.1 安全可信芯片的参考架构

4.1.2 可信执行环境（TEE）的标准化

4.1.3 安全计量器（可选增强）

4.1.4 内存隔离机制

4.2 存储设备增强要求

4.2.1 可信存储

4.2.2 存储分层与属性感知

5 数据要素运行时层规范

5.1 数据操作系统（Data OS）

5.1.1 核心组件

5.1.2 与现有OS的关系

5.2 属性驱动的处理流水线

5.3 可验证计算支持

6 编程语言与软件设计规范

6.1 编程语言增强方向

6.1.1 数据要素属性注解

6.1.2 不可变性与可审计性增强

6.1.3 跨语言属性交换格式

6.2 软件设计架构原则

6.2.1 从“功能为中心”到“数据为中心”

6.2.2 属性驱动的微服务

6.2.3 可验证的软件供应链

7 标准化需求清单

7.1 网络层标准

7.2 计算层标准

7.3 运行时与软件层标准

7.4 OpenHarmony对接标准（新增）

8 与现有政策体系的对齐

9 实施路线图建议

阶段一：标准预研（2026-2027）

阶段二：技术验证（2027-2028）

阶段三：规模推广（2029-2030）

10 与开源鸿蒙（OpenHarmony）操作系统的对接规范（新增）

10.1 对接概述

10.2 OpenHarmony安全子系统概述

10.3 对接架构

10.4 HUKS（密钥管理服务）的数据要素扩展

10.5 设备认证模块的数据要素扩展

10.6 权限管理模块的数据要素扩展

10.7 与TEE的集成：蓬莱-OpenHarmony

10.7.1 蓬莱-TEE的核心能力

10.7.2 蓬莱-TEE与数据要素属性的映射

10.7.3 集成架构

10.8 安全芯片的OpenHarmony生态认证

10.9 OpenHarmony数据要素属性描述文件

10.10 与OpenHarmony版本计划的对接

所有评论(0)

温馨提示：您尚未绑定手机号

Pixlout