AnimusHQ/mllaboratory

 [](LICENSE) [](go.mod) [](https://github.com/AnimusHQ/mllaboratory/stargazers) **主要语言：** Go (services) **数据 / 策略层：** PostgreSQL migrations (SQL/PLpgSQL) **运行时：** Kubernetes (生产环境) • Docker Compose (本地开发与演示) **执行模型：** 控制平面 (**Animus DataPilot**) + 数据平面 (**Animus DataPlane**) **权威元数据存储：** PostgreSQL **对象和制品存储：** S3 兼容对象存储 **契约：** 位于 `core/contracts/*` 的 OpenAPI 和基线规范 [快速开始](docs/quickstart.md) · [架构](#architecture) · [安全性](SECURITY.md) · [常见问题](docs/faq.md) · [对比](docs/comparison.md) · [贡献](CONTRIBUTING.md) · [AI 索引](docs/ai/llms.txt) ## 范围和仓库模型 本仓库是 **Animus Datalab** 的开放核心宿主。 ### 规范根目录 代码库、脚本和部署资产使用的稳定顶级根目录包括： * `core/contracts` — 规范的 API 契约、模式和兼容性基线 * `deploy` — Helm charts、Dockerfiles 和策略资产 * `closed/*` — 控制平面和数据平面服务实现 * `scripts` — 开发、CI、规范检查和发布工具 * `docs` — 企业、运维、安全和架构文档 ### 子模块和迁移存根 本仓库包含用于外部化拆分模型的脚手架： * `./enterprise` — 企业仓库内容的目标位置 * `./sdk` — SDK 仓库内容的目标位置 在迁移期间，一些遗留路径作为显式的兼容性垫片保留，不应被视为规范的真相来源： * `open/api` — 遗留契约垫片；请使用 `core/contracts/*` * `open/sdk` — 遗留 SDK 垫片；请使用 `sdk` * `closed/deploy` — 遗留部署垫片；请使用 `deploy/*` * `closed/scripts` — 遗留企业脚本垫片 当仓库结构和生成的资产不一致时，规范的真相来源为： 1. `closed/migrations/` 中的迁移 2. `deploy/helm/*/values.yaml` 中的部署值 3. `closed/*` 中的服务实现 4. `core/contracts/*` 中的契约 5. `docs/*` 中的运维和安全文档 ## 概述 Animus Datalab 是一个面向企业环境的集中式 ML 平台，在这些环境中，**可重现性**、**可审计性**和**安全性**是必备的平台属性，而非尽力而为的约定。 在系统层面上，该平台将以下部分分离： * **控制平面**：存储权威元数据、评估策略、管理访问权限、协调制品操作，并记录不可变的审计证据 * **数据平面**：在隔离的 Kubernetes 环境中执行不受信任的用户工作负载，并将执行证据报告回控制平面 该平台旨在解决以下运维问题： * 保持 **数据集版本、运行规格、执行计划、策略决策和审计记录** 的集中化和权威性 * 在 Kubernetes 上通过显式的控制平面协调，在 **隔离的容器中执行用户工作负载** * 通过不可变绑定、稳定哈希、持久化的执行计划和证据记录，使运行 **可重现且可解释** * 维护针对状态更改操作和受保护访问的 **完整的仅追加审计跟踪** * 通过项目范围划分、RBAC、会话控制和仅限内部的服务边界，实施 **默认拒绝的安全模型** ### 目标用户 * **数据科学家和 ML 工程师**：需要托管执行、数据集版本控制、制品跟踪和可重现性证据 * **平台运维人员**：需要部署自动化、可观测性、升级安全性、配额控制和物理隔离支持 * **安全与合规团队**：需要不可变审计、策略执行、有界信任区和到 SIEM 系统的导出管道 * **维护者和工程师**：需要显式的模块边界、确定性的行为以及治理与执行之间文档化的分离 ### 核心能力 * 控制平面 / 数据平面分离并带有显式的信任边界 * 项目范围的元数据和授权边界 * 不可变的数据集版本元数据和完整性字段 * 持久化的运行规格和不可变的执行计划 * 确定性规划和稳定的规范哈希 * 通过 S3 兼容对象存储进行的制品协调 * 带有可导出证据记录的仅追加审计 * 带有生产环境 Cookie 控制的基于 OIDC 的会话处理 * 默认拒绝的 RBAC，带有角色控制的读/写/管理员接口 * 通过数据平面中 Kubernetes 支持的工作负载启动进行执行 * 部署和 CI 中的签名镜像及供应链执行钩子 ## 快速开始 ## 本地开发与演示 ### 前置条件 * 与 `go.mod` 中声明版本匹配的 Go 工具链 * 带有 Docker Compose 支持的 Docker * 适用于 SDK 及相关工具的 Python 3（如适用） * Git ### 引导 ``` make bootstrap ``` ### 启动本地技术栈 ``` make dev ``` ### 冒烟测试技术栈 ``` make dev DEV_ARGS=--smoke ``` ### 停止技术栈 ``` make dev DEV_ARGS=--down ``` 诸如 `make demo`、`make demo-smoke` 和 `make demo-down` 等遗留别名可能为了兼容性而存在，但 `make dev` 是规范的入口点。 ## Kubernetes 部署快速开始 最小化的基于 Helm 的部署使用 `deploy/helm/` 中的两个生产 chart： ``` kubectl create namespace animus-system helm upgrade --install animus-datapilot ./deploy/helm/animus-datapilot \ --namespace animus-system \ --values ./deploy/helm/animus-datapilot/values.yaml helm upgrade --install animus-dataplane ./deploy/helm/animus-dataplane \ --namespace animus-system \ --values ./deploy/helm/animus-dataplane/values.yaml ``` 典型的就绪检查是： ``` kubectl -n animus-system get pods kubectl -n animus-system port-forward svc/animus-datapilot-gateway 8080:8080 curl -fsS http://127.0.0.1:8080/readyz ``` 对于生产环境，预期的部署模型包括： * 带有备份和还原验证的外部 PostgreSQL * 外部 S3 兼容对象存储，或经过加固的对象存储部署 * 带有安全会话配置的 OIDC 模式 * 用于服务内部通道的轮换内部认证密钥 * 镜像摘要固定和可选的签名镜像策略执行 ## 架构 Animus Datalab 实现了 **治理平面 + 执行平面** 模型。 仓库的生产部署模型并非单一的单体应用。它是一个多服务架构，带有一个公共入口点、多个控制平面后端以及一个专用的数据平面执行器服务。 ### 架构原则 * **控制平面服务不执行不受信任的用户代码。** * **数据平面服务执行不受信任的工作负载，并且对业务状态不具备权威性。** * **PostgreSQL 是元数据、不可变记录、策略决策和执行证据元数据的唯一真实来源。** * **S3 兼容对象存储用于存储二进制数据**，而 PostgreSQL 用于存储引用、元数据和完整性值。 * **关键实体在设计上是不可变的，并在需要时在数据库层进行强制实施。** * **安全态势是默认拒绝的**，带有显式的 RBAC 和仅限内部的控制通道。 * **项目范围划分是数据集、运行、制品和权限的默认业务边界。** * **运维真相以数据库优先**：中央状态被持久化并显式协调，而不是仅从工作负载状态推断。 ### k8 中的项目生命周期 ``` sequenceDiagram autonumber participant Dev as Developer / CI-CD participant Helm as Helm / kubectl participant API as kube-apiserver participant ETCD as etcd participant Ctrl as Controllers participant Sch as kube-scheduler participant Kubelet as kubelet (target node) participant Runtime as Container Runtime participant CNI as CNI Plugin participant CSI as CSI Driver participant Pod as Application Pod participant EP as EndpointSlice / Service participant User as Client Traffic Dev->>Helm: helm upgrade --install / kubectl apply Helm->>API: Submit desired state (Deployment, Service, ConfigMap, Secret, PVC, ...) API->>ETCD: Persist declarative objects Ctrl->>API: Watch desired state Ctrl->>API: Create / update ReplicaSet Ctrl->>API: Create Pod objects Sch->>API: Watch unscheduled Pods Sch->>API: Bind Pod to target node Kubelet->>API: Watch Pods assigned to node Kubelet->>Runtime: Pull image and create Pod sandbox Runtime-->>Kubelet: Sandbox ready Kubelet->>CSI: Attach / mount volumes (if PVC present) CSI-->>Kubelet: Volumes mounted Kubelet->>CNI: Configure Pod network CNI-->>Kubelet: Pod IP and networking ready Kubelet->>Runtime: Start init containers Runtime-->>Kubelet: Init phase complete Kubelet->>Runtime: Start application container(s) Runtime-->>Pod: Process started Kubelet->>Pod: Run startup probe Pod-->>Kubelet: Startup succeeded Kubelet->>Pod: Run liveness probe Pod-->>Kubelet: Container alive Kubelet->>Pod: Run readiness probe Pod-->>Kubelet: Ready to serve traffic API->>EP: Update EndpointSlice / Service endpoints EP-->>User: Pod becomes routable through Service User->>EP: Send traffic EP->>Pod: Route requests rect rgb(245,245,245) note over API,Pod: Steady state / reconciliation Ctrl->>API: Ensure desired replicas Kubelet->>Pod: Continue probes Kubelet->>API: Report Pod status end alt Deployment update / rollout Dev->>Helm: Apply new chart / manifest version Helm->>API: Update Deployment spec Ctrl->>API: Create new ReplicaSet Sch->>API: Schedule new Pods Kubelet->>Runtime: Start new Pods Kubelet->>Pod: Probes pass API->>EP: Shift traffic to new Pods Ctrl->>API: Scale down old ReplicaSet end alt Pod termination / rollout / eviction API->>Kubelet: Pod deletion / termination request Kubelet->>Pod: SIGTERM Pod-->>Kubelet: Graceful shutdown Kubelet->>Runtime: Stop containers API->>EP: Remove Pod from endpoints end ``` ### 生产服务组成 #### 控制平面 — Animus DataPilot 控制平面由 `deploy/helm/animus-datapilot` 部署，默认由以下服务接口组成： * `gateway` — 公共入口点、会话/认证处理、请求路由、就绪状态 * `dataset-registry` — 数据集和数据集版本操作 * `quality` — 质量和管理导向的服务接口（如果启用） * `experiments` — 实验、运行、规划、策略评估、执行协调 * `lineage` — 数据血缘端点和面向图的管理功能 * `audit` — 仅追加审计的写入和导出接口 * 可选的 `ui` — 面向浏览器的控制台，取决于部署设置 chart 值中的默认端口分配为： * gateway: `8080` * dataset-registry: `8081` * quality: `8082` * experiments: `8083` * lineage: `8084` * audit: `8085` * ui: 启用时为 `3000` #### 数据平面 — Animus DataPlane 数据平面由 `deploy/helm/animus-dataplane` 部署，主要包括： * `dataplane` — 负责启动和协调 Kubernetes 工作负载的内部执行服务 chart 值中的默认端口分配为： * dataplane: `8086` ### 系统上下文 ``` flowchart LR subgraph Users["Users / Clients"] DS[Data Scientist] OPS[Platform Operator] SEC[Security / Compliance] SA[Service Account] end subgraph CP["Control Plane: Animus DataPilot"] GW[Gateway] EXP[Experiments] DSR[Dataset Registry] LIN[Lineage] AUD[Audit] QLT[Quality] UI[UI optional] DB[(PostgreSQL)] OBJ[(S3-compatible Object Store)] end subgraph DP["Data Plane: Animus DataPlane"] DPAPI[DataPlane Service] K8S[(Kubernetes)] JOBS[Run Jobs / Pods] end subgraph EXT["External Systems"] IDP[OIDC Provider] SECRETS[Secrets Provider] SIEM[SIEM / Log Pipeline] end DS --> GW OPS --> GW SEC --> GW SA --> GW GW --> DSR GW --> EXP GW --> LIN GW --> AUD GW --> QLT UI --> GW DSR <--> DB EXP <--> DB LIN <--> DB AUD <--> DB QLT <--> DB DSR <--> OBJ EXP <--> OBJ GW <--> IDP AUD --> SIEM EXP -->|internal CP->DP protocol| DPAPI DPAPI --> K8S K8S --> JOBS JOBS --> OBJ DPAPI --> SECRETS DPAPI -->|status / heartbeats / terminal events| EXP ``` ### 信任边界 ``` flowchart TB subgraph Untrusted["Untrusted zone"] CLIENT[Clients / SDK / Browser] end subgraph Trusted["Trusted management zone"] GW[Gateway] CP[Control Plane Services] DB[(PostgreSQL)] OBJ[(Object Store)] end subgraph Partial["Partially trusted execution zone"] DP[Data Plane] PODS[User Workload Pods] end subgraph External["External integration zone"] IDP[OIDC] SECRETS[Secrets Provider] SIEM[SIEM] end CLIENT --> GW GW --> CP CP <--> DB CP <--> OBJ CP --> DP DP --> PODS PODS --> OBJ GW <--> IDP DP --> SECRETS CP --> SIEM ``` ### 仅限内部的接口 公共流量预期在 Gateway 或 ingress 层终止。 内部服务到服务的路径与公共 API 接口不同，绝不能对外暴露。内部路径族包括： * `/internal/cp/*` * `/internal/dp/*` 它们使用共享的内部认证密钥进行认证，与用户 RBAC 分开。 ### 架构职责 #### Gateway * 公共 HTTP 入口点 * 认证和会话处理 * 路由到后端控制平面服务 * 请求边界执行 * 就绪状态和运维接口 #### Dataset Registry * 数据集和数据集版本元数据操作 * 针对数据集有效载荷流的对象存储协调 * 面向完整性的元数据持久化 #### Experiments * 运行提交和编排 * 持久化的运行规格和执行计划 * 策略评估和审批集成 * 控制平面到数据平面的协调 * 状态协调和终态处理 #### Audit * 仅追加审计记录摄取 * 用于下游证据管道的导出接口 * 对安全重大行动的管理可见性 #### Lineage * 面向数据血缘的查询和图接口 * 管理或受限的图遍历用例 #### Quality * 面向质量和验证的服务接口 * 部署槽可能是可选的，取决于分发或推出阶段 #### Data Plane * 将工作负载启动到 Kubernetes 中 * 协调工作负载状态 * 向控制平面报告心跳和终态 * 在执行时进行有界的密钥注入 * 执行证据发射，不具备业务状态权威性 ## 安全与治理模型 ### 认证 生产环境的认证模式是可配置的，在实际环境中预期使用 OIDC。 部署时支持的认证模式包括： * `dev` * `oidc` OIDC 配置通过 chart 值提供，包括颁发者设置、客户端凭证、声明处理和会话行为。 ### 会话管理 在 OIDC 模式下，会话处理基于 Cookie 并可配置： * 安全 Cookie 行为 * SameSite 策略 * TTL / max-age * 强制登出处理 ### 授权和 RBAC RBAC 是项目范围的，并在服务端强制执行。 文档化的默认执行语义为： * `GET`、`HEAD` 和 `OPTIONS` 需要查看者级别的访问权限 * 诸如 `POST`、`PUT`、`PATCH` 和 `DELETE` 等变更动词需要编辑者级别的访问权限 * 审计、数据血缘和质量管理接口受到超越标准项目角色的严格限制 * 缺少所需项目范围的请求将被拒绝，除非设计中明确豁免 * 访问拒绝将被记录并可供审计 ### Run Token 限制 绑定执行的凭证受到约束。Run Token 的访问范围有意设计得比用户或管理员身份更窄，并仅限于执行报告和制品协调所需的安全白名单能力。 ### 密钥处理 密钥旨在来自外部提供商或受控模式，并仅在必要时提供。 安全预期包括： * 最小范围 * 有界生命周期 * 不通过 UI 有效载荷、日志或不相关的 API 暴露 * 在执行时交付，而不是作为通用应用状态持久化 ### 控制平面 / 数据平面边界执行 在代码检查中强制执行静态模块边界。控制平面包被禁止直接导入数据平面运行时执行内部构件。这保留了治理代码不得成为不受信任用户工作负载执行路径的架构规则。 ### 供应链控制 仓库包含用于生产加固的钩子，支持： * 镜像摘要固定 * SBOM 生成 * 漏洞扫描 * 镜像签名和验证 * 基于策略的签名镜像准入执行 ## 契约、API 和模式 ### 规范契约位置 * `core/contracts/openapi/*.yaml` — 按服务划分的 OpenAPI 契约 * `core/contracts/baseline/*.yaml` — 兼容性基线和快照 * `core/contracts/pipeline_spec.yaml` — 管道规范模式 遗留兼容位置： * `open/api` — 仅作兼容性垫片，不是规范的契约来源 ### 公共和 API 接口 公共接口通过 Gateway 暴露，通常包括： * `/api/*` * `/auth/*` * 就绪端点，例如 `/readyz` 内部 CP/DP 协调接口是刻意分离的，不属于公共 API 契约。 ### 契约真相模型 如果行为在文本描述和实现之间出现差异，真相优先级顺序为： 1. 服务代码和处理程序 2. 迁移和持久化不变量 3. OpenAPI 契约和模式 4. 部署值和文档化的运维参考 5. README 级别的总结，例如本文档 ## 持久化、不可变性和执行证据 权威模式位于 `closed/migrations/*.sql`。 ### 持久化模型 PostgreSQL 存储： * 项目和项目范围的元数据 * 数据集和数据集版本 * 运行规格和执行计划 * 策略版本、决策和审批 * 审计事件和完整性字段 * 上下文执行元数据 S3 兼容对象存储存储： * 数据集有效载荷对象 * 运行输出和制品 * 证据包和相关的二进制材料（如适用） ### 完整性模型 模式使用面向完整性的字段，例如关键记录上的 `integrity_sha256` 和内容哈希。对象存储不是元数据真相的来源；对象引用和哈希持久化在 PostgreSQL 中。 ### 不可变性模型 关键记录通过数据库端的强制实施来防止修改或删除。 示例包括： * 数据集版本 * 审计事件 * 运行上的不可变字段 * 执行计划 数据库级不可变性的目的是确保重放、审计和取证重建不仅仅依赖于应用端的自律。 ### 运行模型的细微差别 模式中包含反映平台演进的相邻运行概念： * `experiment_runs` 被实验和策略相关的子系统使用 * `runs` 和 `execution_plans` 被较新的 pipeline-run 轨道使用 这不是偶然的。它反映了一条架构演进路径，在这条路径上，运行证据、策略决策和管道规划可以共存，而无需重写完整性模型。 ### 持久化和关系概览 ``` erDiagram PROJECTS { text project_id PK text name jsonb metadata timestamptz created_at text created_by text integrity_sha256 } DATASETS { text dataset_id PK text project_id FK text name jsonb metadata timestamptz created_at text created_by text integrity_sha256 } DATASET_VERSIONS { text version_id PK text dataset_id FK text project_id bigint ordinal text content_sha256 text object_key bigint size_bytes jsonb metadata timestamptz created_at text created_by text integrity_sha256 } RUNS { text run_id PK text project_id FK text idempotency_key text status jsonb pipeline_spec jsonb run_spec text spec_hash timestamptz created_at } EXECUTION_PLANS { text plan_id PK text run_id FK text project_id FK jsonb plan timestamptz created_at } POLICIES { text policy_id PK text name timestamptz created_at text created_by text integrity_sha256 } POLICY_VERSIONS { text policy_version_id PK text policy_id FK int version text status text spec_yaml jsonb spec_json text spec_sha256 timestamptz created_at text created_by text integrity_sha256 } POLICY_DECISIONS { text decision_id PK text run_id FK text policy_id FK text policy_version_id FK text policy_sha256 jsonb context text context_sha256 text decision text rule_id text reason timestamptz created_at text created_by text integrity_sha256 } POLICY_APPROVALS { text approval_id PK text decision_id FK text run_id FK text status timestamptz requested_at text requested_by timestamptz decided_at text decided_by text reason text integrity_sha256 } AUDIT_EVENTS { bigint event_id PK timestamptz occurred_at text actor text action text resource_type text resource_id text request_id inet ip text user_agent jsonb payload text integrity_sha256 } PROJECTS ||--o{ DATASETS : contains DATASETS ||--o{ DATASET_VERSIONS : versions PROJECTS ||--o{ RUNS : contains RUNS ||--|| EXECUTION_PLANS : has POLICIES ||--o{ POLICY_VERSIONS : versions POLICY_VERSIONS ||--o{ POLICY_DECISIONS : evaluated_as POLICY_DECISIONS ||--o{ POLICY_APPROVALS : may_require ``` ## 核心流程 ### 运行提交流程 ``` sequenceDiagram autonumber participant User participant GW as Gateway participant EXP as Experiments participant DB as PostgreSQL participant DP as DataPlane participant K8S as Kubernetes User->>GW: Submit run request GW->>EXP: Routed API call EXP->>EXP: Validate request and policy requirements EXP->>DB: Persist run and immutable execution plan EXP-->>GW: Accepted / queued response GW-->>User: Run identifier and status EXP->>DP: Internal execution request DP->>K8S: Launch workload DP-->>EXP: Heartbeats / status K8S-->>DP: Completion DP-->>EXP: Terminal state and execution evidence EXP->>DB: Finalize authoritative state ``` ### 制品和对象流 ``` sequenceDiagram autonumber participant Job as Workload Pod participant OBJ as Object Store participant DP as DataPlane participant EXP as Experiments participant DB as PostgreSQL Job->>OBJ: Upload output object Job->>DP: Report object reference and metadata DP->>EXP: Commit execution evidence EXP->>DB: Persist authoritative artifact metadata EXP->>DB: Emit audit-relevant state transitions where required ``` ### 协调流程 ``` sequenceDiagram autonumber participant EXP as Experiments participant DB as PostgreSQL participant DP as DataPlane participant K8S as Kubernetes EXP->>DB: Load active or stale runs EXP->>DP: Query workload state DP->>K8S: Inspect execution objects K8S-->>DP: Current state DP-->>EXP: Reconciled execution evidence EXP->>DB: Apply authoritative state transition ``` ### 策略和审批流程 ``` sequenceDiagram autonumber participant User participant GW as Gateway participant EXP as Experiments participant DB as PostgreSQL User->>GW: Submit action requiring policy evaluation GW->>EXP: Forward request EXP->>DB: Resolve policy versions and context EXP->>DB: Persist policy decision alt Approval required EXP->>DB: Persist approval request EXP-->>GW: Awaiting approval else Allowed EXP-->>GW: Continue operation end ``` ## 仓库结构 ``` . ├── core/ │ └── contracts/ # Canonical contracts, schemas, and baseline compatibility assets ├── deploy/ │ ├── helm/ # Helm charts: animus-datapilot and animus-dataplane │ ├── docker/ # Dockerfiles and build assets │ └── policy/ # Admission and policy examples ├── closed/ # Canonical service implementations │ ├── gateway/ # Public entrypoint, auth/session, routing │ ├── dataset-registry/ # Dataset and dataset-version services │ ├── experiments/ # Runs, planning, execution coordination, policy logic │ ├── lineage/ # Lineage service │ ├── audit/ # Audit service │ ├── dataplane/ # Data Plane executor service │ ├── frontend_console/ # Optional UI sources │ ├── internal/ # Shared internal packages and adapters │ ├── migrations/ # PostgreSQL migrations; schema source of truth │ ├── deploy/ # Compatibility shim for deploy assets │ └── scripts/ # Compatibility shim for enterprise script split ├── open/ │ ├── demo/ # Demo and smoke-test assets │ ├── api/ # Legacy contract shim │ └── sdk/ # Legacy SDK shim ├── scripts/ # Development, CI, hygiene, and release tooling ├── docs/ # Architecture, enterprise, ops, and security documentation ├── enterprise/ # Submodule target placeholder ├── sdk/ # Submodule target placeholder ├── cmd/ # Auxiliary command packages ├── tools/ # CI/CD and helper tooling ├── third_party/ # Externalized or vendored helper assets ├── vendor/ # Vendored Go dependencies where applicable ├── .golangci.yml # Lint and depguard boundary enforcement ├── go.mod ├── go.sum ├── Makefile └── README.md ``` ## 开发工作流 ### 常用命令 引导依赖： ``` make bootstrap ``` 运行格式化： ``` make fmt ``` 运行代码检查： ``` make lint ``` 运行测试： ``` make test ``` 构建代码库： ``` make build ``` 启动本地开发技术栈： ``` make dev ``` ### 开发说明 * `closed/migrations/` 是持久化的唯一真实来源。 * `core/contracts/` 是契约的唯一真实来源。 * `deploy/helm/*/values.yaml` 是部署默认值的唯一真实来源。 * `docs/*` 包含规范的运维和安全参考。 * `.golangci.yml` 强制执行架构边界，包括控制平面代码和运行时执行内部构件之间的分离。 ## 生产运维 生产部署应满足以下基线条件： * 支持 Kubernetes 的 DataPilot 和 DataPlane 部署 * 具有经过测试的备份和还原程序的外部托管 PostgreSQL * 具有受控访问和项目安全对象布局的 S3 兼容对象存储 * 具有安全会话设置的 OIDC 集成 * 用于 CP/DP 通信的轮换内部认证密钥 * 公共、控制和执行区域之间的网络隔离 * 服务、工作负载和请求路径的可观测性 * 环境要求的基于策略的镜像完整性控制 ### 运维特性 * 当由外部有状态依赖提供支持时，控制平面可水平扩展 * 数据平面可隔离到单独的集群或执行域 * 工作负载状态被协调到数据库支持的权威状态中，而不是被直接信任 * 生产部署应按摘要固定镜像 * 通过预构建的资产和策略感知的安装流程支持物理隔离部署 ### 可观测性 该平台旨在支持： * 结构化日志 * 关联和请求标识符 * 指标和跟踪（如已配置） * 用于安全证据管道的审计导出 ### 备份和恢复预期 运维人员应将 PostgreSQL 和对象存储一起视为可恢复的状态面。备份验证和还原演练在生产级部署中不是可选的。 ## 路线图 路线图在 `roadmap.json` 中跟踪。 本 README 记录了当前的生产架构形态和仓库真相模型。除非存在相应的代码、迁移、部署资产和文档，否则不应将路线图状态解释为已实现的行为。 ## 明确的非目标 * 内置 Git 托管 * 完全的 IDE 替代品 * 独立的推理平台 * 独立的特征存储产品 ## 文档 更广泛的文档入口点是 `docs/README.md`。 重要的文档组包括： * `docs/enterprise/` — 企业和规范的平台规范 * `docs/ops/` — 部署、配置、备份和物理隔离操作 * `docs/security/` — RBAC、会话和安全执行模型 * `docs/architecture/` — 架构说明和迁移/拆分参考 当 README 文本与详细的运维/安全文档在精度上存在差异时，以详细的文档和源代码资产为准。 ## 许可证 Apache-2.0。请参阅 [LICENSE](LICENSE)。 ## 联系方式 有关工程、维护或运维的联系： **[rewanderer@proton.me](mailto:rewanderer@proton.me)**

标签：Apex, API契约, DataPilot, DataPlane, Docker Compose, EVTX分析, Go语言, Helm Charts, MLOps平台, ML开发全生命周期管理, OpenAPI, PostgreSQL, S3对象存储, SQL/PLpgSQL, 人工智能平台, 企业级数字实验室, 元数据存储, 子域名突变, 安全策略, 审计与合规, 容器化部署, 开放核心, 微服务架构, 控制平面, 提示词设计, 数据平面, 数据治理, 数据科学, 日志审计, 机器学习, 模型可复现性, 模型管理, 测试用例, 版权保护, 程序破解, 资源验证