零代码玩转多模型：Dify+Ollama本地部署DeepSeek开源模型的避坑指南

最近在折腾本地AI应用时，发现很多开发者都面临一个两难选择：既想享受云端大模型的强大能力，又担心数据隐私和API调用成本。我自己在几个项目中尝试了不同的方案，最终发现Dify + Ollama的组合可能是目前个人开发者和小团队最实用的解决方案。

这个方案的核心价值在于，你可以在自己的Mac或Windows电脑上，用零代码的方式搭建一个功能完整的AI应用平台，同时接入多个开源模型，根据不同的任务需求灵活切换。无论是写代码助手、文档分析工具，还是智能客服原型，都能在本地环境中快速搭建起来，完全不用担心数据泄露问题。

更重要的是，整个过程几乎不需要编写任何代码——Dify提供了可视化的应用编排界面，Ollama则让本地模型部署变得像安装普通软件一样简单。下面我就结合自己的实践经验，详细拆解整个部署流程，重点分享那些容易踩坑的环节和优化技巧。

1. 环境准备与核心工具选型

在开始之前，我们需要明确整个技术栈的构成。这个方案主要包含三个核心组件：Dify应用开发平台、Ollama本地模型服务，以及目标开源模型（这里以DeepSeek系列为例）。

1.1 硬件与系统要求

很多人误以为运行大模型必须要有高端显卡，其实对于7B参数级别的模型，现在的消费级硬件已经足够应付大多数场景。下面是我在不同设备上的实测数据：

设备配置内存存储实测可用模型推理速度（tokens/秒）
MacBook Pro M2 (16GB)16GB512GB SSDDeepSeek-Coder-7B, Llama3.2-3B15-25
Windows PC (i5-12400)32GB1TB NVMeDeepSeek-R1-7B, Qwen2.5-7B20-35
旧款Mac Mini M1 (8GB)8GB256GB SSDPhi-3-mini, TinyLlama8-15

注意：如果你的设备内存只有8GB，建议选择3B以下参数量的模型，或者使用量化版本（如GGUF格式）。32GB内存的设备可以比较流畅地运行7B模型，但如果要同时运行Dify和多个模型服务，建议至少有16GB可用内存。

从我的经验来看，Mac设备由于统一的ARM架构和优化的内存管理，在同等配置下通常比Windows设备表现更好。不过Windows的优势在于显卡选择更灵活，如果有NVIDIA显卡，可以通过CUDA加速大幅提升推理速度。

1.2 软件依赖安装

整个部署过程需要安装几个关键软件。我建议按照以下顺序进行，避免依赖冲突：

第一步：安装Docker Desktop

Dify官方推荐使用Docker部署，这确实是最简单稳定的方式。无论是Mac还是Windows，都建议下载Docker Desktop的稳定版。

# 验证Docker安装是否成功
docker --version
docker-compose --version

安装完成后，记得在设置中调整资源分配。对于16GB内存的设备，我通常这样配置：

  • 内存：分配8-12GB给Docker
  • CPU：分配4-6个核心
  • Swap：设置2-4GB（特别是Windows用户）

第二步：安装Ollama

Ollama的安装极其简单，官网提供了各平台的安装包。下载后直接运行即可。

# 安装后验证Ollama服务
ollama --version

# 查看已安装的模型
ollama list

这里有个小技巧：首次运行Ollama时，建议先拉取一个小模型测试，比如ollama pull llama3.2:3b。这样可以验证网络连接和基础环境是否正常，避免直接拉取大模型时遇到问题浪费时间。

第三步：准备模型文件

虽然Ollama支持在线拉取模型，但在国内网络环境下，直接下载几个GB的模型文件可能会很慢甚至失败。我推荐两种方案：

  1. 使用镜像源：修改Ollama的配置文件，使用国内镜像
  2. 手动下载GGUF文件：从Hugging Face等平台下载后，通过Ollama的Modelfile创建自定义模型

对于DeepSeek模型，我测试过几个版本，以下是性能对比：

模型名称参数量量化级别文件大小推荐场景
deepseek-coder-6.7b6.7BQ4_K_M4.2GB代码生成、技术问答
deepseek-r1-7b7BQ4_K_M4.5GB推理、数学问题
deepseek-llm-7b7BQ4_K_S3.8GB通用对话、文本生成

提示：Q4_K_M在精度和速度之间取得了很好的平衡，适合大多数应用场景。如果设备内存紧张，可以考虑Q4_K_S或Q3_K_S。

2. Ollama本地模型部署实战

Ollama的设计理念就是"简单"，但正是这种简单，让一些高级配置变得不那么直观。下面我分享几个实际部署中的关键步骤和避坑点。

2.1 基础模型部署

假设我们要部署DeepSeek-Coder-7B模型，最直接的方式是：

# 拉取模型（如果网络通畅）
ollama pull deepseek-coder:7b

# 如果拉取失败，可以尝试指定完整名称
ollama pull deepseek-coder:7b-q4_K_M

但实际情况是，你可能会遇到下载速度慢或连接超时的问题。这时可以改用手动方式：

  1. 从Hugging Face下载GGUF格式的模型文件
  2. 创建Modelfile文件
  3. 本地构建模型

这里给出一个完整的Modelfile示例：

FROM ./deepseek-coder-7b-q4_K_M.gguf

# 设置模型参数
PARAMETER temperature 0.7
PARAMETER top_p 0.9
PARAMETER top_k 40
PARAMETER num_ctx 4096

# 系统提示词（可选）
SYSTEM """你是一个专业的编程助手，擅长Python、JavaScript、Go等多种语言。
请用简洁明了的方式回答技术问题，并提供可运行的代码示例。"""

保存为DeepSeekCoder-7B.Modelfile，然后执行：

ollama create deepseek-coder-7b -f ./DeepSeekCoder-7B.Modelfile

2.2 性能优化配置

模型部署后，默认配置可能不是最优的。特别是对于内存有限的设备，需要调整一些参数来平衡性能和资源使用。

调整Ollama服务配置

Ollama的配置文件通常位于：

  • Mac/Linux: ~/.ollama/config.json
  • Windows: C:\Users\<用户名>\.ollama\config.json

可以添加或修改以下配置：

{
  "host": "0.0.0.0",
  "port": 11434,
  "num_parallel": 1,
  "num_gpu": 1,
  "num_thread": 4,
  "main_gpu": 0,
  "low_vram": false
}

关键参数说明：

  • num_parallel：同时处理的请求数，对于个人使用设置为1即可
  • num_thread：CPU线程数，建议设置为物理核心数的70-80%
  • low_vram：如果内存紧张，可以设置为true，但会影响性能

模型运行参数优化

启动模型时可以指定运行参数：

# 启动模型并指定参数
ollama run deepseek-coder:7b --num_ctx 8192 --temperature 0.8

对于长期运行的服务，我建议创建一个启动脚本：

#!/bin/bash
# start_models.sh

# 启动DeepSeek Coder模型
ollama run deepseek-coder:7b \
  --num_ctx 4096 \
  --temperature 0.7 \
  --top_p 0.9 \
  --top_k 40 \
  --repeat_penalty 1.1 &

# 等待5秒确保第一个模型启动
sleep 5

# 启动DeepSeek R1模型（如果内存足够）
ollama run deepseek-r1:7b \
  --num_ctx 2048 \
  --temperature 0.3 \
  --top_p 0.95 &

2.3 多模型管理与切换

在实际应用中，我们经常需要根据任务类型切换不同的模型。Ollama支持同时运行多个模型实例，但需要管理不同的端口。

方法一：使用不同端口

# 第一个模型使用默认端口11434
ollama serve

# 第二个模型使用不同端口（需要修改配置）
OLLAMA_HOST=0.0.0.0:11435 ollama serve

方法二：使用Ollama API动态加载

更灵活的方式是通过Ollama的API动态加载和卸载模型：

import requests
import time

class OllamaManager:
    def __init__(self, base_url="http://localhost:11434"):
        self.base_url = base_url
        
    def load_model(self, model_name):
        """加载模型到内存"""
        response = requests.post(
            f"{self.base_url}/api/generate",
            json={
                "model": model_name,
                "prompt": "test",
                "stream": False
            }
        )
        # 第一次调用会触发模型加载
        return response.status_code == 200
    
    def unload_model(self, model_name):
        """目前Ollama没有直接的卸载API
        可以通过停止Ollama服务或依赖系统内存管理"""
        # 替代方案：使用不同模型时，之前的模型会被自动换出
        pass
    
    def list_loaded_models(self):
        """查看当前运行的模型"""
        response = requests.get(f"{self.base_url}/api/tags")
        if response.status_code == 200:
            return response.json().get("models", [])
        return []

在实际使用中，我发现让Ollama自动管理模型加载是最省心的方式。当内存不足时，Ollama会自动将不活跃的模型换出，需要时再换入。虽然这会带来一些延迟，但对于个人使用场景来说是可以接受的。

3. Dify平台配置与模型接入

Dify的强大之处在于它提供了一个可视化的AI应用开发平台，但第一次配置可能会遇到一些障碍。下面是我总结的完整配置流程。

3.1 Dify Docker部署

Dify官方提供了docker-compose配置，但默认配置可能需要根据本地环境调整。

基础部署

首先下载官方docker-compose文件：

# 创建项目目录
mkdir dify-local && cd dify-local

# 下载docker-compose文件
curl -o docker-compose.yml https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml

关键配置修改

默认的docker-compose配置可能不适合所有环境，我通常做以下修改：

version: '3'
services:
  dify-api:
    image: langgenius/dify-api:latest
    container_name: dify-api
    ports:
      - "5001:5001"
    environment:
      # 修改数据库配置，使用更轻量的SQLite
      - DB_TYPE=sqlite
      - DB_FILE=/app/storage/dify.db
      # 限制内存使用
      - MEMORY_LIMIT=4096
    volumes:
      - ./storage:/app/storage
      - ./logs:/app/logs
    # 添加资源限制
    deploy:
      resources:
        limits:
          memory: 4G
        reservations:
          memory: 2G
  
  dify-web:
    image: langgenius/dify-web:latest
    container_name: dify-web
    ports:
      - "3000:3000"
    depends_on:
      - dify-api

注意：如果设备内存有限，可以将MEMORY_LIMIT设置为2048（2GB），并将Docker容器的内存限制相应调低。

启动服务

# 启动所有服务
docker-compose up -d

# 查看日志，确认服务正常
docker-compose logs -f dify-api

首次启动可能需要几分钟时间初始化数据库。当看到Application startup complete日志时，说明服务已就绪。

3.2 配置OpenAI-API-compatible插件

这是连接Dify和Ollama的关键步骤。Dify通过OpenAI兼容接口与各种模型服务通信。

安装插件

  1. 访问Dify控制台（通常是http://localhost:3000）
  2. 使用默认账号登录（首次登录需要注册）
  3. 进入"设置" → "模型供应商"
  4. 找到"OpenAI-API-compatible"并点击安装

配置模型参数

安装完成后，点击"添加模型"，需要填写以下关键信息：

参数项填写值说明
模型类型LLM大语言模型
模型名称deepseek-coder-7b与Ollama中的模型名一致
API Keyollama任意值（Ollama不需要鉴权）
API Endpoint URLhttp://host.docker.internal:11434/v1关键配置
上下文长度4096根据模型能力设置
最大Token数2048单次生成的最大长度

这里最容易出错的是API Endpoint URL。因为Dify运行在Docker容器内，需要特殊的主机名才能访问宿主机的服务：

  • Mac/Linux: http://host.docker.internal:11434/v1
  • Windows: http://host.docker.internal:11434/v1 或 http://172.17.0.1:11434/v1

如果遇到连接问题，可以进入Dify的Docker容器内测试连通性：

# 进入Dify API容器
docker exec -it dify-api bash

# 测试与Ollama的连接
curl http://host.docker.internal:11434/v1/models

高级配置技巧

对于需要特殊参数的模型，可以在"高级参数"中设置：

{
  "temperature": 0.7,
  "top_p": 0.9,
  "frequency_penalty": 0.1,
  "presence_penalty": 0.1,
  "stop": ["\n\n", "Human:", "Assistant:"]
}

3.3 多模型配置与测试

配置完一个模型后，可以用同样的方法添加其他模型。我通常建议至少配置两个模型：一个通用模型和一个专用模型。

模型配置对比表

特性DeepSeek-Coder-7BDeepSeek-R1-7BQwen2.5-7B
适用场景代码生成、调试逻辑推理、数学通用对话
上下文长度409640968192
Temperature0.70.30.8
Top P0.90.950.9
响应速度快中等快
内存占用中等中等中等

批量测试脚本

为了验证所有模型配置是否正确，我写了一个简单的测试脚本：

import requests
import json

def test_model(endpoint, model_name, prompt):
    """测试单个模型"""
    url = f"{endpoint}/chat/completions"
    headers = {
        "Content-Type": "application/json",
        "Authorization": "Bearer ollama"
    }
    
    payload = {
        "model": model_name,
        "messages": [
            {"role": "user", "content": prompt}
        ],
        "stream": False,
        "max_tokens": 100
    }
    
    try:
        response = requests.post(url, json=payload, headers=headers, timeout=30)
        if response.status_code == 200:
            result = response.json()
            return {
                "model": model_name,
                "status": "success",
                "response": result["choices"][0]["message"]["content"][:50] + "..."
            }
        else:
            return {
                "model": model_name,
                "status": f"error: {response.status_code}",
                "response": response.text[:100]
            }
    except Exception as e:
        return {
            "model": model_name,
            "status": f"exception: {str(e)}",
            "response": ""
        }

# 测试所有配置的模型
models = ["deepseek-coder-7b", "deepseek-r1-7b", "qwen2.5-7b"]
endpoint = "http://localhost:5001/v1"
prompt = "请用Python写一个快速排序算法"

print("开始模型连通性测试...")
for model in models:
    result = test_model(endpoint, model, prompt)
    print(f"{model}: {result['status']}")
    if result['status'] == 'success':
        print(f"  示例响应: {result['response']}")
    print()

4. 应用开发与性能优化

配置好模型只是第一步，真正发挥Dify威力的是应用开发。这里分享几个实用的应用模板和优化技巧。

4.1 创建第一个AI应用

让我们创建一个简单的代码审查助手，它可以自动分析代码并提供改进建议。

步骤1：创建新应用

在Dify工作室点击"创建空白应用"，选择"Agent"类型，命名为"代码审查助手"。

步骤2：配置提示词

提示词是AI应用的核心。对于代码审查场景，我使用这样的提示词：

你是一个经验丰富的代码审查专家，擅长发现代码中的潜在问题并提供改进建议。

审查规则：
1. 检查代码风格是否符合PEP8（Python）或相应语言规范
2. 识别潜在的性能瓶颈
3. 检查安全漏洞（如SQL注入、XSS等）
4. 建议更好的算法或数据结构
5. 指出可读性问题

输出格式：
## 问题总结
[列出主要问题]

## 详细分析
[对每个问题的详细解释]

## 改进建议
[具体的代码修改建议]

## 重构示例
[提供改进后的代码片段]

请严格按上述格式输出，保持专业但友好的语气。

步骤3：添加上下文和工具

为了让助手更专业，我们可以添加：

  • 知识库：上传Python最佳实践、安全编码指南等文档
  • 工具：启用代码执行环境（谨慎使用），让AI可以运行测试代码

步骤4：模型选择与配置

在应用设置中，选择我们之前配置的deepseek-coder-7b模型，并调整参数：

temperature: 0.3  # 较低的温度使输出更确定性
top_p: 0.9
max_tokens: 2048
stop_sequences: ["## 结束", "审查完成"]

4.2 工作流设计技巧

对于复杂的任务，Dify的工作流功能非常强大。以"多轮代码优化"工作流为例：

工作流结构

开始
  ↓
[输入] 接收用户代码
  ↓
[LLM节点] 初步代码审查（使用DeepSeek-Coder）
  ↓
[条件判断] 是否存在严重问题？
  ├─ 是 → [LLM节点] 生成紧急修复建议
  └─ 否 → [LLM节点] 生成优化建议
  ↓
[代码执行] 运行测试验证（可选）
  ↓
[LLM节点] 生成最终报告（使用DeepSeek-R1进行总结）
  ↓
[输出] 返回审查结果

关键节点配置

在LLM节点中，可以针对不同阶段选择不同的模型：

# 初步审查节点
model: deepseek-coder-7b
temperature: 0.2
system_prompt: "你是一个严格的代码审查员，专注于发现bug和安全问题"

# 优化建议节点  
model: deepseek-coder-7b
temperature: 0.7
system_prompt: "你是一个创意性的代码优化专家，提供可读性和性能改进建议"

# 总结报告节点
model: deepseek-r1-7b
temperature: 0.3
system_prompt: "你是一个技术文档作者，将技术分析转化为清晰的总结报告"

4.3 性能监控与优化

本地部署的AI应用需要特别关注性能问题。以下是我常用的监控和优化方法。

资源监控仪表板

创建一个简单的监控脚本，定期检查系统资源：

import psutil
import time
from datetime import datetime
import json

class ResourceMonitor:
    def __init__(self, log_file="resource_log.json"):
        self.log_file = log_file
        self.metrics = []
    
    def collect_metrics(self):
        """收集系统资源指标"""
        metrics = {
            "timestamp": datetime.now().isoformat(),
            "cpu_percent": psutil.cpu_percent(interval=1),
            "memory_percent": psutil.virtual_memory().percent,
            "memory_used_gb": psutil.virtual_memory().used / (1024**3),
            "disk_usage": psutil.disk_usage('/').percent,
            "ollama_processes": self._count_ollama_processes(),
            "dify_processes": self._count_dify_processes()
        }
        self.metrics.append(metrics)
        
        # 只保留最近100条记录
        if len(self.metrics) > 100:
            self.metrics = self.metrics[-100:]
        
        return metrics
    
    def _count_ollama_processes(self):
        count = 0
        for proc in psutil.process_iter(['name']):
            try:
                if 'ollama' in proc.info['name'].lower():
                    count += 1
            except (psutil.NoSuchProcess, psutil.AccessDenied):
                pass
        return count
    
    def _count_dify_processes(self):
        count = 0
        for proc in psutil.process_iter(['name']):
            try:
                if 'dify' in proc.info['name'].lower():
                    count += 1
            except (psutil.NoSuchProcess, psutil.AccessDenied):
                pass
        return count
    
    def save_logs(self):
        """保存日志到文件"""
        with open(self.log_file, 'w') as f:
            json.dump(self.metrics, f, indent=2)
    
    def generate_report(self):
        """生成性能报告"""
        if not self.metrics:
            return "No metrics collected"
        
        recent = self.metrics[-10:]  # 最近10次记录
        avg_cpu = sum(m['cpu_percent'] for m in recent) / len(recent)
        avg_mem = sum(m['memory_percent'] for m in recent) / len(recent)
        
        report = f"""
性能监控报告 ({datetime.now().strftime('%Y-%m-%d %H:%M')})
========================================
平均CPU使用率: {avg_cpu:.1f}%
平均内存使用率: {avg_mem:.1f}%
Ollama进程数: {recent[-1]['ollama_processes']}
Dify进程数: {recent[-1]['dify_processes']}

建议：
"""
        if avg_cpu > 80:
            report += "- CPU使用率过高，考虑减少并发请求或优化模型配置\n"
        if avg_mem > 85:
            report += "- 内存使用率过高，考虑使用更小的模型或增加Swap空间\n"
        if recent[-1]['ollama_processes'] > 3:
            report += "- Ollama进程过多，检查是否有未正确关闭的模型实例\n"
        
        return report

# 使用示例
monitor = ResourceMonitor()
for _ in range(5):  # 收集5次数据
    monitor.collect_metrics()
    time.sleep(2)

print(monitor.generate_report())
monitor.save_logs()

Dify配置优化

根据监控结果，可以调整Dify的配置：

  1. 调整工作线程数：在config.yaml中修改

    worker:
  count: 2  # 根据CPU核心数调整
  timeout: 300

  2. 启用响应缓存：对于重复查询，可以缓存结果

    cache:
  enabled: true
  ttl: 3600  # 缓存1小时
  max_size: 1000

  3. 限制并发请求：防止资源过载

    limits:
  max_requests_per_minute: 30
  max_tokens_per_minute: 10000

Ollama优化技巧

  1. 使用模型量化：GGUF格式的Q4量化可以在几乎不损失质量的情况下减少40%内存占用
  2. 批处理请求：如果有多个相似请求，可以合并处理
  3. 预热常用模型：在低峰期预先加载常用模型到内存
# 预热脚本
#!/bin/bash
# preload_models.sh

MODELS=("deepseek-coder:7b" "qwen2.5:7b")

for model in "${MODELS[@]}"; do
  echo "预热模型: $model"
  curl -X POST http://localhost:11434/api/generate \
    -H "Content-Type: application/json" \
    -d "{\"model\": \"$model\", \"prompt\": \"test\", \"stream\": false}" \
    -o /dev/null -s
  echo "完成: $model"
  sleep 2
done

4.4 故障排查与常见问题

在实际使用中，总会遇到各种问题。以下是我遇到的一些典型问题及解决方案。

问题1：Dify无法连接Ollama

症状：在Dify中测试模型时提示连接失败。

排查步骤：

  1. 检查Ollama服务是否运行
    curl http://localhost:11434/api/tags
  2. 检查Dify容器内是否能访问Ollama
    docker exec dify-api curl http://host.docker.internal:11434/api/tags
  3. 检查防火墙设置
  4. 尝试使用IP地址代替host.docker.internal

问题2：模型响应速度慢

症状：简单的查询也需要很长时间才能返回结果。

可能原因和解决方案：

  1. 模型未加载到内存：首次调用会加载模型，后续调用会快很多
  2. 硬件资源不足：检查CPU和内存使用情况
  3. 上下文过长：减少num_ctx参数值
  4. 使用量化版本：Q4_K_M比Q8_0快很多

问题3：内存不足导致崩溃

症状：系统变慢，然后Ollama或Dify服务崩溃。

解决方案：

  1. 使用内存更小的模型
  2. 增加Swap空间
    # Linux/Mac
sudo dd if=/dev/zero of=/swapfile bs=1G count=4
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
  3. 限制单个模型的内存使用
    # 启动Ollama时限制内存
OLLAMA_MAX_LOADED_MODELS=2 ollama serve

问题4：模型输出质量差

症状：模型回答不符合预期，或者胡言乱语。

调试方法：

  1. 检查温度参数：过高的temperature会导致输出随机
  2. 验证提示词：确保系统提示词清晰明确
  3. 测试不同模型：有些任务可能更适合其他模型
  4. 调整停止词：防止模型无限生成
# 调试脚本：测试不同参数对输出的影响
def test_model_parameters(model_name, prompt, temperature_values):
    results = {}
    for temp in temperature_values:
        response = requests.post(
            "http://localhost:11434/api/generate",
            json={
                "model": model_name,
                "prompt": prompt,
                "temperature": temp,
                "top_p": 0.9,
                "stream": False
            }
        )
        results[temp] = response.json()["response"]
    return results

# 测试不同temperature值
prompt = "解释什么是机器学习"
temps = [0.1, 0.3, 0.7, 1.0]
results = test_model_parameters("deepseek-r1:7b", prompt, temps)

经过几个月的实际使用，我发现Dify + Ollama + DeepSeek的组合确实能够满足大多数个人开发者的需求。虽然性能无法与云端GPU集群相比，但在数据隐私、定制灵活性和成本控制方面有着不可替代的优势。

最关键的是，这个方案让AI应用开发变得触手可及。你不需要是机器学习专家，也不需要大量的服务器预算，只需要一台普通的电脑，就能搭建属于自己的智能助手。随着开源模型的不断进步，我相信本地AI应用的潜力还会进一步释放。

# Ollama # DeepSeek
Logo
乐奇 Rokid 开放社区

更多推荐

Word Embedding ：从分布式假设到神经网络语言模型

Word Embedding（词嵌入）是一种将离散的词汇符号映射到连续的低维稠密向量空间的技术。在这个向量空间中，语义相似的词在几何距离上彼此接近，从而实现了从"符号匹配"到"语义计算"的跨越。核心定义词嵌入是将单词（或多词短语）表示为固定维度的实值向量，这些向量之间的距离（例如余弦相似度）反映了单词之间的相关性，这种相关性基于单词通常出现的上下文。分布式假设（1954）↓统计共现分析（LSA/S

avatar 乐奇 Rokid 开放社区

镜游小导：运行在 Rokid AR 眼镜上的景区实景讲解智能体

项目以 RokidAIUI 开放智能体形态交付：页面用.ink描述，运行在眼镜端智能体运行时，直接调用系统能力。AGENTS.md身份镜游小导v1.0.0，景区 AR 实景讲解智能体；权限（Capabilities）microphonenetworkaudiogyroscope；技能（Skills）。

avatar 乐奇 Rokid 开放社区
cover

AI 智能眼镜技术文档

avatar 乐奇 Rokid 开放社区