摘要：在 AI 大规模落地企业的今天，数据智能底座的技术架构面临前所未有的重构压力。本文围绕企业级数据智能底座的三大核心技术模块——统一语义层（Unified Semantic Layer）、指标本体治理（Metric Ontology Governance）和 Agent 协同执行架构（Agent Collaborative Execution Architecture）——进行深度技术剖析，结合工程实践经验，探讨如何构建一个既能保证企业级严谨性，又能充分释放 AI 自主执行能力的数据智能基础设施。

一、问题背景：大模型为什么无法直接作用于企业数据？

1.1 三个根本性约束

当企业尝试将大模型直接对接数仓、让员工用自然语言查询数据时，很快会遭遇三道难以逾越的工程墙：

约束一：数仓的确定性要求

企业经营决策依赖数据的严谨性。财务报告、KPI 考核、合规审计——任何一个场景都不允许"大概正确"的答案。而大模型的本质是概率模型，其生成结果天然带有不确定性。当大模型不确定"活跃用户"的定义时，它会做出一个看似合理的猜测，并将其包装成自信的 SQL 语句——这种"自信的错误"比"明显的错误"危害更大。

约束二：上下文窗口的物理限制

一个中型企业的数仓可能包含：

  • 500+ 张业务表，总字段数超过 50,000 个
  • 数千个历史指标定义，包含复杂的 Case When 逻辑
  • 跨系统的数据血缘关系图谱

即便是最新的长上下文大模型（200K tokens），也无法容纳这一体量的结构化信息。更重要的是，将全量 Schema 塞入上下文不仅成本极高，还会严重稀释大模型对关键信息的注意力权重，导致准确率下降。

约束三：企业级关键能力的系统性缺失

大模型不知道：

  • 哪些用户可以看哪些数据（行列级权限控制）
  • 同名指标在不同业务域的口径差异（指标统一治理）
  • 查询操作是否符合数据安全合规要求（审计与水印）
  • 数据的更新频率和时效性（数据新鲜度管理）

这些能力不属于大模型的能力范畴，必须由数据智能底座在系统层面提供保障。

1.2 正确的技术架构思路

解决上述约束的正确思路，不是试图让大模型变得"更聪明"，而是为大模型构建一个精准的企业业务上下文基础设施，使其能够在有限的上下文窗口内，以接近确定性的方式完成企业数据操作。

这就是企业级数据智能底座的核心价值主张。

二、统一语义层：消除 AI 与企业数据之间的认知鸿沟

2.1 语义层的定义与价值

语义层（Semantic Layer）并不是新概念——它在传统 BI 时代就已存在，其核心功能是将物理数据模型（表、字段、外键关系）抽象为业务用户可理解的概念模型（指标、维度、业务主题）。

在 AI 时代，语义层的价值被放大到了前所未有的高度，因为它现在需要同时服务两类"消费者"：

  1. 人类分析师：通过仪表盘和报告理解业务数据
  2. AI Agent：通过工具调用自主完成数据任务

这要求语义层不仅要"人类可读"，还要"机器可解析"——即以结构化的方式表达业务语义，使 Agent 能够基于语义层进行精确的推理和执行。

2.2 Headless BI 架构：语义层的正确实现姿势

Headless BI 是当前语义层实现的最佳架构模式。其核心思想是将语义层从前端展示层中彻底解耦，使其成为独立的、可被任意消费方访问的基础服务。

传统 BI 架构（耦合式）：
┌─────────────────────────────────┐
│  前端展示层                      │
│  ┌─────────────────────────┐   │
│  │  业务语义（内嵌/隐式）    │   │
│  └─────────────────────────┘   │
│            │                    │
│  数据访问层（直连数仓）           │
└─────────────────────────────────┘

Headless BI 架构（解耦式）：
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Web 仪表盘│ │ AI Agent │ │  API 调用 │
└────┬─────┘ └────┬─────┘ └────┬─────┘
     │             │             │
     └─────────────┼─────────────┘
                   │
         ┌─────────▼──────────┐
         │   统一语义层服务    │
         │   (Semantic Layer) │
         └─────────┬──────────┘
                   │
         ┌─────────▼──────────┐
         │    数据存储层       │
         │  (OLAP/数仓/湖仓)   │
         └────────────────────┘

Headless BI 的核心技术组件：

组件一：语义模型（Semantic Model）

# 语义模型定义示例
semantic_model:
  name: "订单分析模型"
  version: "2.1.0"
  
  entities:
    - name: order
      type: primary_entity
      primary_key: order_id
      source: "dwd.dwd_order_detail"
      
    - name: customer
      type: dimension_entity
      primary_key: customer_id
      source: "dim.dim_customer"
      
  relationships:
    - name: order_to_customer
      type: many_to_one
      from: order.customer_id
      to: customer.customer_id
      
  measures:
    - name: order_amount
      type: SUM
      field: order.payment_amount
      filter: "order.order_status = 'completed'"
      
    - name: order_count
      type: COUNT_DISTINCT
      field: order.order_id
      
  dimensions:
    - name: order_date
      type: time
      field: order.created_at
      granularities: [day, week, month, quarter, year]
      
    - name: product_category
      type: categorical
      field: order.product_category_l1

组件二：语义查询引擎（Semantic Query Engine）

语义查询引擎负责将面向语义层的查询请求（无论来自人类还是 Agent）编译为可执行的 SQL：

# 语义查询请求示例（Agent 调用）
semantic_query = {
    "metrics": ["order_amount", "order_count"],
    "dimensions": ["product_category", "order_date"],
    "time_filter": {
        "field": "order_date",
        "granularity": "month",
        "range": "last_3_months"
    },
    "filters": [
        {"field": "customer.region", "operator": "IN", "values": ["华东", "华南"]}
    ]
}

# 语义引擎生成的 SQL
generated_sql = """
SELECT
    o.product_category_l1 AS product_category,
    DATE_TRUNC('month', o.created_at) AS order_date,
    SUM(CASE WHEN o.order_status = 'completed' THEN o.payment_amount ELSE 0 END) AS order_amount,
    COUNT(DISTINCT o.order_id) AS order_count
FROM dwd.dwd_order_detail o
JOIN dim.dim_customer c ON o.customer_id = c.customer_id
WHERE
    o.created_at >= DATE_TRUNC('month', CURRENT_DATE - INTERVAL '3 months')
    AND c.region IN ('华东', '华南')
GROUP BY 1, 2
ORDER BY 2 DESC, 1
"""

2.3 语义层的 AI 增强：从静态到动态

传统语义层是静态的——由数据工程师手动维护，更新周期长。AI 增强的语义层引入了以下动态能力：

自动语义推断（Automated Semantic Inference）：

  • 分析历史 SQL 查询日志，自动识别常用的字段组合和过滤模式
  • 结合字段名称、注释、数据分布，自动推断字段的业务含义
  • 从 BI 工具的使用行为中，识别高频指标的计算逻辑

语义一致性校验（Semantic Consistency Validation）：

  • 检测跨部门使用相同术语但口径不同的指标冲突
  • 验证指标定义变更前后的数据一致性
  • 识别僵尸指标（长期无人使用的指标定义）

三、指标本体治理：企业数字资产的核心管理工程

3.1 为什么指标治理是企业数据智能的核心难题？

在实际企业环境中，指标混乱是数据价值无法充分释放的最主要原因。典型问题包括：

  • 口径分歧："月活用户"在产品部门、运营部门、财务部门的计算口径各不相同
  • 命名混乱：同一指标有 “DAU”、“日活”、“每日活跃用户数”、“日活跃用户量” 等多种表述
  • 指标孤岛：各业务线各自维护指标，缺乏跨域关联分析能力
  • 来源不明：数据分析师无法追溯某个指标值的计算来源和数据血缘

在 AI 加持的场景下，上述问题会被成倍放大——因为 AI Agent 在执行分析任务时，无法像人类分析师一样通过"沟通确认"来消除歧义，它只能依赖已有的指标定义进行推断。指标定义不清，AI 的输出必然混乱。

3.2 指标本体论的技术架构

指标本体论（Metric Ontology）是一套形式化的知识表示体系，将企业业务指标以结构化的方式组织为可计算、可检索、可推理的知识图谱。

指标分类体系：

企业指标体系
├── 原子指标（Atomic Metrics）
│   ├── 直接来自数据源，无需额外计算
│   └── 示例：订单金额、用户注册数
│
├── 衍生指标（Derived Metrics）
│   ├── 基于原子指标和维度组合计算
│   └── 示例：月均订单金额 = SUM(订单金额) / COUNT(DISTINCT 月份)
│
├── 复合指标（Composite Metrics）
│   ├── 多个原子/衍生指标的组合运算
│   └── 示例：ROI = (营收 - 成本) / 成本 × 100%
│
└── 目标指标（Target Metrics）
    ├── 带有业务目标值的指标
    └── 示例：Q1 销售目标完成率 = 实际销售额 / 销售目标额

指标元数据规范：

{
  "metric_id": "m_gmv_monthly",
  "name": "月度GMV",
  "aliases": ["月GMV", "月成交额", "Monthly Gross Merchandise Value"],
  "category": "交易核心指标",
  "type": "derived",
  "definition": {
    "formula": "SUM(order_payment_amount)",
    "conditions": [
      "order_status IN ('paid', 'delivered', 'completed')",
      "is_valid_order = true"
    ],
    "time_grain": "month",
    "dedup_key": null
  },
  "data_source": {
    "primary_table": "dwd.dwd_order_detail",
    "join_tables": [],
    "data_freshness": "T+1",
    "update_frequency": "daily"
  },
  "dimensions": {
    "supported": ["region", "product_category", "channel", "customer_tier"],
    "required": [],
    "restricted": ["customer_id"]
  },
  "governance": {
    "owner": "交易分析团队",
    "reviewer": "财务数据委员会",
    "approved_at": "2026-01-15",
    "version": "3.2",
    "change_log": [
      {
        "version": "3.2",
        "date": "2026-01-15",
        "change": "新增售后退款订单排除逻辑",
        "approved_by": "CFO 办公室"
      }
    ]
  },
  "usage": {
    "access_level": "public",
    "row_security": null,
    "certified": true,
    "last_used": "2026-04-17",
    "monthly_query_count": 3420
  }
}

3.3 指标集市（Metrics Store）：让指标成为可复用的数字资产

指标集市是指标本体论的工程实现载体，它将企业所有经过认证的指标以统一的形式发布为可检索、可订阅、可复用的服务。

指标集市的核心功能模块：

┌─────────────────────────────────────────────────────────┐
│                     指标集市 (Metrics Store)              │
├─────────────────────────────────────────────────────────┤
│  搜索与发现层                                             │
│  ├── 全文检索（支持别名、描述、业务域）                    │
│  ├── 语义相似度检索（向量化指标描述）                     │
│  └── 多维度过滤（分类/业务域/认证状态/更新时间）           │
├─────────────────────────────────────────────────────────┤
│  指标详情层                                               │
│  ├── 完整口径定义（公式、数据源、口径说明）               │
│  ├── 数据血缘图谱（上游依赖/下游引用）                    │
│  ├── 版本历史与变更记录                                   │
│  └── 使用情况统计（引用次数、使用部门）                   │
├─────────────────────────────────────────────────────────┤
│  访问控制层                                               │
│  ├── 指标级别权限（哪些角色可以查询此指标）               │
│  ├── 维度权限（某角色只能按特定维度查询）                 │
│  └── 数据脱敏（敏感指标的字段掩码）                      │
├─────────────────────────────────────────────────────────┤
│  AI 集成层                                                │
│  ├── MCP Tool 接口（Agent 工具调用）                      │
│  ├── 向量嵌入（语义检索优化）                             │
│  └── 上下文摘要（为 LLM 生成精简的指标摘要）             │
└─────────────────────────────────────────────────────────┘

3.4 指标治理的全生命周期管理

创建阶段：

  • AI 辅助从现有 SQL 查询中提取和标准化指标定义
  • 自动检测与现有指标的重复和冲突
  • 生成初始口径文档草稿，供业务方确认

发布阶段：

  • 多级审批工作流（数据工程师 → 业务负责人 → 数据委员会）
  • 自动数据质量校验（空值率、异常值、历史趋势合理性）
  • 版本冻结与向后兼容性保证

使用阶段：

  • 实时访问统计与热度分析
  • 指标使用场景自动标注
  • 跨团队复用发现与推荐

退休阶段：

  • 低频使用指标的自动识别与下线建议
  • 下线前影响范围分析（哪些报告/仪表盘依赖此指标）
  • 历史数据的归档与下线保护期管理

四、Agent 协同执行架构：让 AI 真正"干活"

4.1 单 Agent 的能力边界

单一的 LLM Agent 在面对复杂的数据基建任务时，存在明显的能力上限：

  • 推理深度受限：复杂任务的推理步骤超过模型的有效推理长度
  • 工具专注度降低：任务越复杂，单个 Agent 在工具选择上越容易出错
  • 并行能力缺失：串行执行无法利用多步骤任务中的天然并行性

4.2 多 Agent 协同架构设计

面向企业数据场景的多 Agent 协同架构，通常采用**分层专业化（Hierarchical Specialization）**模式：

┌─────────────────────────────────────────────────────────────┐
│                   主协调 Agent (Orchestrator)                 │
│   • 接收用户意图，进行任务分解                               │
│   • 分配子任务给专业 Agent                                   │
│   • 监控执行状态，协调结果合并                               │
└────────────────────────┬────────────────────────────────────┘
                         │
          ┌──────────────┼──────────────┐
          │              │              │
┌─────────▼────┐ ┌───────▼──────┐ ┌───▼──────────┐
│ 数据建模 Agent│ │ 指标创作 Agent│ │ 权限配置 Agent│
│              │ │              │ │              │
│ • 数据集创建  │ │ • 指标定义   │ │ • 角色分配   │
│ • JOIN 配置   │ │ • 仪表盘生成 │ │ • 行过滤设置 │
│ • Schema 推断 │ │ • 图表优化   │ │ • 访问审计   │
└──────────────┘ └──────────────┘ └──────────────┘

协调 Agent 的任务分解算法：

class OrchestratorAgent:
    def decompose_task(self, user_intent: str) -> TaskDAG:
        """
        将用户意图分解为有向无环图（DAG）形式的任务依赖图
        """
        # 第一步：意图理解
        intent = self.llm.parse_intent(user_intent)
        
        # 第二步：能力映射（将意图映射到所需的 Agent 能力）
        required_capabilities = self.capability_mapper.map(intent)
        
        # 第三步：依赖分析（识别任务间的先后依赖关系）
        task_dependencies = self.dependency_analyzer.analyze(required_capabilities)
        
        # 第四步：生成任务 DAG
        task_dag = TaskDAG()
        for capability in required_capabilities:
            task = Task(
                capability=capability,
                agent=self.select_agent(capability),
                dependencies=task_dependencies.get(capability, [])
            )
            task_dag.add_task(task)
        
        return task_dag
    
    def execute_dag(self, task_dag: TaskDAG) -> ExecutionResult:
        """
        按 DAG 拓扑顺序执行任务，支持并行执行无依赖的任务
        """
        # 识别可并行执行的任务层
        execution_layers = task_dag.topological_sort_by_layer()
        
        results = {}
        for layer in execution_layers:
            # 同一层的任务并行执行
            layer_results = self.parallel_execute(layer, context=results)
            results.update(layer_results)
            
            # 检查是否有失败任务，决定是否继续
            failed_tasks = [t for t in layer if results[t.id].status == "failed"]
            if failed_tasks:
                recovery_plan = self.self_heal(failed_tasks, results)
                results.update(self.execute_recovery(recovery_plan))
        
        return ExecutionResult(results)

4.3 Agent 的自愈机制实现

自愈能力是 Agentic BI 区别于传统工作流自动化的关键特征。实现高质量的自愈机制需要：

错误分类系统（Error Taxonomy）：

class ErrorTaxonomy:
    SEMANTIC_ERRORS = [
        "AMBIGUOUS_METRIC",        # 指标定义歧义
        "SCHEMA_MISMATCH",         # 字段映射错误
        "BUSINESS_RULE_VIOLATION", # 违反业务规则
    ]
    
    TECHNICAL_ERRORS = [
        "SQL_SYNTAX_ERROR",        # SQL 语法错误
        "QUERY_TIMEOUT",           # 查询超时
        "OOM_ERROR",               # 内存溢出
        "PERMISSION_DENIED",       # 权限拒绝
    ]
    
    DATA_ERRORS = [
        "DATA_NOT_FOUND",          # 数据不存在
        "STALE_DATA",              # 数据过期
        "DATA_QUALITY_FAILURE",    # 数据质量不达标
    ]

对应自愈策略：

错误类型 自愈策略 备注
AMBIGUOUS_METRIC 检索语义层，精确匹配指标定义 优先选择认证指标
SCHEMA_MISMATCH 重新检索字段映射，更新 JOIN 逻辑 触发语义重建
SQL_SYNTAX_ERROR 分析错误位置，定向修复 最多重试 3 次
QUERY_TIMEOUT 拆分查询，分批执行后合并 或降采样预览
PERMISSION_DENIED 切换到有权限的备选数据源 记录权限缺口告警
DATA_NOT_FOUND 扩大时间范围或切换数据粒度 向用户说明数据限制

4.4 Agent 执行的可观测性设计

企业场景下的 Agent 执行必须具备完整的可观测性，以支持审计、调试和持续优化：

执行追踪（Execution Tracing）：

{
  "trace_id": "exec_20260418_143022_a7f3",
  "task": "创建Q1销售分析仪表盘",
  "initiated_by": "用户: 张磊",
  "started_at": "2026-04-18T14:30:22Z",
  "steps": [
    {
      "step_id": 1,
      "agent": "data_modeling_agent",
      "action": "create_dataset",
      "input": {"tables": ["dwd_order", "dim_product"], "join_type": "LEFT"},
      "output": {"dataset_id": "ds_20260418_001", "status": "success"},
      "duration_ms": 342,
      "llm_tokens_used": 1240
    },
    {
      "step_id": 2,
      "agent": "metric_agent",
      "action": "define_metric",
      "input": {"name": "Q1销售额", "formula": "SUM(order_amount)"},
      "output": {"metric_id": "m_q1_sales", "status": "success"},
      "duration_ms": 189,
      "llm_tokens_used": 867
    },
    {
      "step_id": 3,
      "agent": "dashboard_agent",
      "action": "create_chart",
      "input": {"type": "line", "metrics": ["m_q1_sales"], "dims": ["week"]},
      "output": {"chart_id": "c_001", "status": "success"},
      "duration_ms": 512,
      "llm_tokens_used": 1563
    }
  ],
  "total_duration_ms": 1043,
  "total_llm_tokens": 3670,
  "result": {
    "dashboard_id": "dash_20260418_q1_sales",
    "status": "completed",
    "artifacts": ["ds_20260418_001", "m_q1_sales", "c_001"]
  }
}

五、企业级安全与治理：数据智能底座的地基

5.1 行列级权限管控的技术实现

企业数据安全的核心挑战是实现细粒度、高性能的行列级权限控制。在 Agentic BI 场景下，这一挑战被进一步放大，因为 Agent 的自主执行可能涉及大量跨数据集的访问操作。

行级安全（Row-Level Security）实现架构：

-- 权限策略定义
CREATE POLICY sales_region_policy ON dwd_order_detail
    USING (
        region IN (
            SELECT allowed_regions 
            FROM user_permission_mapping 
            WHERE user_id = CURRENT_USER_ID()
        )
    );

-- Agent 执行查询时，权限引擎自动注入过滤条件
-- 原始 Agent 查询
SELECT SUM(order_amount) FROM dwd_order_detail WHERE month = '2026-03';

-- 权限引擎转换后
SELECT SUM(order_amount) 
FROM dwd_order_detail 
WHERE month = '2026-03'
    AND region IN ('华东', '华南')  -- 自动注入，对 Agent 透明

列级脱敏（Column-Level Masking）：

class ColumnMaskingEngine:
    MASKING_RULES = {
        "phone_number": lambda x: x[:3] + "****" + x[-4:],
        "id_card": lambda x: x[:6] + "********" + x[-4:],
        "email": lambda x: x.split("@")[0][:2] + "***@" + x.split("@")[1],
        "salary": lambda x: "****",  # 完全遮盖
    }
    
    def apply_masking(self, column_name: str, value: str, user_role: str) -> str:
        if user_role in ["admin", "data_engineer"]:
            return value  # 高权限角色不脱敏
        
        column_sensitivity = self.get_column_sensitivity(column_name)
        if column_sensitivity in self.MASKING_RULES:
            return self.MASKING_RULES[column_sensitivity](value)
        return value

5.2 数据血缘与审计追踪

数据血缘图谱（Data Lineage Graph） 是企业数据治理的核心基础设施之一，它记录了数据从源头到消费端的完整流转路径：

数据血缘示例：

[业务系统 - OMS订单系统]
        │
        ▼
[ODS层 - ods_order_raw] (全量同步，T+1)
        │
        ▼
[DWD层 - dwd_order_detail] (清洗、标准化)
        │
    ┌───┴───────────────────────┐
    │                           │
    ▼                           ▼
[指标：月度GMV]          [指标：订单转化率]
    │                           │
    ▼                           ▼
[仪表盘：经营日报]       [仪表盘：漏斗分析]
    │                           │
    ▼                           ▼
[订阅：CEO 日报邮件]    [订阅：运营周报]

当数据血缘与 Agent 执行追踪相结合，企业可以实现端到端的数据可信度追溯——任何一张仪表盘上的数字，都可以一键追溯到其计算逻辑、数据来源和生成 Agent 的执行记录。

六、技术选型与工程实践指南

6.1 数据智能底座的技术栈选型参考

层次 开源方案 商业方案 选型建议
OLAP 查询引擎 ClickHouse / DuckDB / Doris Snowflake / BigQuery 中大型企业建议自建 ClickHouse 集群
语义层框架 Cube.js / dbt Semantic Layer 各 BI 厂商内置 优先选择与 BI 工具原生集成的方案
向量数据库 Milvus / Chroma / pgvector Pinecone / Weaviate 元数据规模 <1M 可用 pgvector
Agent 框架 LangChain / LlamaIndex 各云厂商 Agent 服务 企业自建建议 LangChain + LangGraph
工作流编排 Apache Airflow / Prefect 各平台内置 已有 Airflow 生态可继续使用
权限管控 Apache Ranger / OPA 各数仓内置 RLS 统一到数仓层做权限管控

6.2 数据智能底座的分阶段建设路径

第一阶段（0-3个月）：夯实语义层基础

  • 盘点核心业务指标，完成 Top 50 指标的口径统一
  • 建立指标命名规范和分类体系
  • 完成核心数据集的语义模型建设
  • 部署基础的指标集市，实现指标的统一检索

第二阶段（3-6个月）：引入 AI 辅助能力

  • 部署 NL2SQL 能力，支持自然语言查询核心指标
  • 建立 AI 生成 SQL 的校验与审核机制
  • 开始收集 AI 查询的准确率和失败模式数据
  • 基于失败数据，持续完善语义层和指标定义

第三阶段（6-12个月）：构建 Agentic 执行能力

  • 开发或集成 CLI-style 的数据操作工具集
  • 部署多 Agent 协同执行框架
  • 实现自动化的数据集和仪表盘创建能力
  • 建立 Agent 执行的完整可观测性基础设施

第四阶段（12个月+）：迈向自生长的数字大脑

  • Agent 自主完成指标迭代优化
  • 跨业务域的智能关联分析
  • 预测性数据基建（AI 主动识别潜在的数据需求并预先建设）

七、结语

企业级数据智能底座的建设，是一项系统性工程，不存在"一键 AI 化"的捷径。其核心技术支柱——统一语义层、指标本体治理、Agent 协同执行架构——每一项都需要扎实的数据工程积累和持续的迭代投入。

但这项投入的回报是清晰的：一旦企业建立起高质量的语义层和指标体系，AI Agent 就拥有了真正"理解业务"的能力，数据基础设施建设的边际成本将大幅下降，分析洞见的生成速度将指数级提升。

数据智能的终局，不是"AI 替代数据分析师"，而是"AI 承担数据基建的重复性工程，人类聚焦于业务判断和价值创造"——这才是数据智能底座应当指向的未来。

关键技术术语索引

  • Semantic Layer（语义层）：将物理数据模型抽象为业务概念模型的中间层
  • Headless BI：将语义层与展示层解耦的 BI 架构模式
  • Metric Ontology（指标本体论）：形式化表达企业指标定义和关系的知识体系
  • NL2SQL：自然语言到 SQL 的自动转换技术
  • ReAct：结合推理（Reasoning）和行动（Acting）的 Agent 范式
  • Row-Level Security（行级安全）：在数据库层面限制行级数据访问的安全机制
  • Data Lineage（数据血缘）：记录数据从生产到消费全链路流转关系的元数据体系
# 架构 # 人工智能 # 大数据
Logo
AtomGit开源社区

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

更多推荐

cover

本文档提供了GR-RL具身强化学习框架121-180项的底层技术参数，涵盖运动控制、视觉处理、模型校验、硬件交互等多个方面。主要内容包括：关节运动曲线标定参数、光流法运算设置、模型权重校验规则、离线回

avatar AtomGit开源社区
cover

企业级 Agent Runtime 实战

avatar AtomGit开源社区
cover

AI赋能跨境电商：图片与视频多语言处理的技术原理与应用

avatar AtomGit开源社区