30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度Dify 是一个开源的 AI 应用开发平台由 LangGenius 团队打造核心目标是让开发者、产品经理甚至业务人员都能快速构建和部署生产级的 AI 应用。它不是一个单一的模型而是一个集成了大模型编排、RAG检索增强生成、Agentic 工作流、可视化构建和可观测性的一站式平台。简单说你可以把它理解为一个“AI 应用的操作系统”通过拖拽和配置就能把想法变成可运行的 AI 服务。这篇文章不讲虚的直接看它能解决什么实际问题如果你需要快速搭建一个企业知识库问答机器人、一个自动化的内容生成流水线或者一个复杂的多步骤 AI 决策 Agent但又不想从零开始写大量胶水代码、处理复杂的部署和监控那么 Dify 就是为你准备的。它的核心优势在于将 AI 应用的构思、开发、部署和监控流程标准化、可视化大幅降低了 AI 应用工程化的门槛。根据官方资料Dify 的最新版本如 v1.9.2已经支持了双向集成 MCPModel Context ProtocolServer这意味着你不仅可以在 Dify 里调用外部工具还能把在 Dify 里构建的 AI 应用本身发布为 MCP 服务被其他平台如 Claude Desktop、Cursor 等直接调用极大地扩展了其连接和集成能力。接下来我会带你从零开始完成 Dify 的本地部署、核心功能上手、企业级工作流搭建并深入探讨其 API 集成、性能表现和最佳实践。无论你是想快速验证一个 AI 想法还是需要为团队搭建一个稳定、可扩展的 AI 中台这篇文章都能提供一条清晰的路径。1. 核心能力速览在深入细节之前我们先通过一个表格快速了解 Dify 的核心特性和技术门槛让你判断它是否适合你的场景。能力项说明项目类型开源 AI 应用开发与部署平台 (LLM Orchestration Platform)开源团队LangGenius, Inc.核心功能1.可视化工作流构建拖拽式创建复杂 AI Agent 流程。2.RAG Pipeline一站式文档处理、向量化、检索增强生成。3.模型与工具集成无缝接入 OpenAI、Azure、 Anthropic、本地模型如通过 Ollama、文心一言、通义千问等。4.应用发布与监控一键发布为 Web App 或 API并提供使用量、性能监控。5.MCP 支持可作为 MCP Server 被外部调用也可连接外部 MCP 服务。推荐硬件开发/测试4核 CPU8GB 内存50GB 磁盘。生产环境根据并发量和模型需求通常需要 8核 CPU16GB 内存建议使用独立 GPU 以加速嵌入模型和本地大模型推理。显存占用平台本身不直接消耗大量显存。显存占用主要取决于你集成的本地大模型如 Llama 3、Qwen 等和嵌入模型如 BGE、text2vec。例如运行一个 7B 参数的量化模型可能需要 4-8GB 显存。支持平台支持 Docker 部署可在Windows (WSL2)、macOS、Linux上运行。也支持 Kubernetes 云原生部署。启动方式一键启动通过 Docker Compose 命令快速拉起所有服务Web 前端、后端 API、数据库等。源码启动适合深度定制开发。是否支持 API是。提供完整的 RESTful API可用于管理应用、发起对话、上传文档等。构建的应用本身也提供 API 端点。是否支持批量任务是。通过工作流可以轻松设计批量处理逻辑也支持通过 API 进行批量调用。适合场景企业知识库问答、智能客服、内容生成流水线、数据分析 Agent、内部工具自动化、快速 AI 应用原型验证。2. 适用场景与使用边界Dify 的强大在于其“一站式”和“生产就绪”的特性但它并非万能钥匙。理解其适用边界能帮你更好地决策。它非常适合以下场景快速原型验证产品经理或创业者有一个 AI 应用创意希望快速做出可交互的 Demo验证市场反馈。企业级 AI 中台为整个技术或业务团队提供统一的 AI 能力接入、管理和监控平台避免重复造轮子。知识库与智能问答需要将公司内部文档、手册、代码库转化为一个能准确回答问题的智能助手。自动化工作流需要串联多个 AI 步骤和外部工具如查询数据库、发送邮件、生成报告的复杂业务流程。无代码/低代码 AI 开发非技术人员如运营、市场也能通过配置创建简单的文本生成、分类或翻译应用。它可能不是最佳选择如果你需要极致的单模型推理性能如果你的核心需求仅仅是部署一个模型并提供最高效的推理 API如纯文本生成那么专门的服务框架如 vLLM, TGI可能更直接。你对底层代码有绝对控制需求Dify 抽象了底层细节虽然支持插件和代码扩展但如果你需要对模型推理、请求处理的每一个环节进行深度定制和 hack直接使用框架如 LangChain, LlamaIndex编码会更灵活。资源极度受限Dify 本身由多个微服务构成Web Server, API Server, 数据库 向量数据库等对内存和磁盘有一定基础要求。在资源极其有限的边缘设备上运行可能比较吃力。合规与安全边界提醒数据安全在接入企业敏感数据时务必部署在私有环境并配置好网络访问控制和数据加密。Dify 支持私有化部署这是其企业级特性的重要一环。模型合规确保你接入的大模型服务无论是云端 API 还是本地模型符合相关法律法规和数据出境要求。内容审核对于生成式 AI 应用特别是对公开放的场景务必在 Dify 的工作流中或后续环节加入内容安全审核机制避免产生有害或违规内容。版权与授权使用 RAG 功能时确保上传的文档数据拥有合法的使用权。生成内容时注意避免侵犯他人知识产权。3. 环境准备与前置条件开始部署前请确保你的环境满足以下要求。这里我们以最常用的Docker Compose部署方式为例。3.1 系统要求操作系统Linux (Ubuntu 20.04/CentOS 7), macOS, Windows 10/11 (需安装 WSL2 并启用 Linux 发行版如 Ubuntu)。Docker版本 20.10.0 或更高。这是必须的。Docker Compose版本 v2.0.0 或更高。通常安装 Docker Desktop 时会包含。CPU 与内存最低 2 核 CPU4GB 内存。推荐 4 核 CPU8GB 内存以上以获得流畅体验。内存不足会导致服务启动失败或运行缓慢。磁盘空间至少 20GB 可用空间用于存放 Docker 镜像、数据库和可能的模型缓存。网络能够访问 Docker Hub 和 GitHub 以下载镜像和源码。如果需要接入 OpenAI 等云端 API则需要相应的网络条件。3.2 环境检查在终端中执行以下命令确认 Docker 和 Docker Compose 已正确安装# 检查 Docker 版本 docker --version # 检查 Docker Compose 版本 docker compose version如果命令成功执行并输出版本号说明环境基本就绪。3.3 端口占用检查Dify 默认会占用几个端口请确保它们没有被其他程序占用3000前端 Web 界面。5001后端 API 服务。6379Redis 服务用于缓存和消息队列。5432PostgreSQL 数据库。9000MinIO 对象存储用于存放文件。你可以使用netstat或lsof命令检查端口占用情况Linux/macOS# Linux/macOS 检查端口占用示例 sudo lsof -i :3000 sudo lsof -i :5001如果端口被占用你需要在后续的部署配置中修改映射端口。4. 安装部署与启动方式Dify 官方推荐使用 Docker Compose 进行一键部署这是最快、最不容易出错的方式。4.1 获取部署文件首先创建一个工作目录并下载官方提供的docker-compose.yaml文件。# 创建一个目录用于存放 Dify 相关文件 mkdir dify cd dify # 下载最新的 docker-compose 配置文件 curl -Lo docker-compose.yaml https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml # 下载环境变量配置文件示例 curl -Lo .env.example https://raw.githubusercontent.com/langgenius/dify/main/.env.example cp .env.example .envdocker-compose.yaml文件定义了所有需要运行的服务App、API、数据库等。.env文件用于配置关键参数如加密密钥、外部模型 API Key 等。4.2 配置环境变量编辑.env文件设置必要的参数。以下是最关键的几项# 使用你喜欢的文本编辑器如 vim 或 nano vim .env找到并修改以下配置至少需要设置密钥# 用于加密的密钥务必修改为随机字符串 SECRET_KEYyour-very-strong-secret-key-change-this # 外部模型 API 配置例如如果你想使用 OpenAI # OPENAI_API_KEYsk-your-openai-api-key-here # OPENAI_API_BASEhttps://api.openai.com/v1 # 数据库密码建议修改 DB_PASSWORDdifyai123456初次体验时可以暂时不配置外部模型 API KeyDify 内置了一个用于测试的模拟模型。但为了使用真正的 GPT、Claude 或本地模型后续需要配置。4.3 一键启动服务在包含docker-compose.yaml和.env文件的目录下执行启动命令# 在后台启动所有服务 docker compose up -d这个命令会从 Docker Hub 拉取所需的镜像包括 PostgreSQL, Redis, MinIO, Nginx 以及 Dify 自身的服务并启动所有容器。首次运行可能需要几分钟时间下载镜像。4.4 验证服务状态启动完成后使用以下命令检查容器是否都在正常运行docker compose ps你应该看到所有服务dify-app,dify-api,dify-db,dify-redis,dify-minio等的状态都是Up。4.5 访问 Web 界面在浏览器中打开http://你的服务器IP:3000。如果是在本地电脑上部署直接访问http://localhost:3000。 首次访问会进入初始化页面按照提示设置管理员账号和密码并配置初始的模型供应商可以先跳过后续在设置中配置。至此Dify 平台就已经成功部署并运行起来了。整个过程如果网络通畅通常在 5-10 分钟内可以完成。5. 功能测试与效果验证平台跑起来后我们通过几个核心功能来验证它是否工作正常并感受其能力。5.1 基础对话应用测试这是最简单的测试创建一个基于纯文本对话的 AI 应用。登录后台使用你设置的管理员账号登录http://localhost:3000。创建应用点击“创建应用”选择“对话型应用”输入应用名称如“我的第一个AI助手”。配置模型在应用构建界面点击左侧“模型供应商”。点击“添加模型供应商”选择“OpenAI”如果你有 API Key填入名称和 API Key。保存后在“模型”下拉框中就能选择gpt-3.5-turbo或gpt-4。如果没有 OpenAI KeyDify 内置了一个“模拟”模型供应商用于测试流程。你可以选择它但生成的回复是固定的。对话测试在界面中间的“预览”区域输入一个问题例如“用 Python 写一个简单的 HTTP 服务器”。点击发送查看 AI 的回复是否正常。成功标志能收到连贯、符合逻辑的文本回复。失败排查如果报错“模型不可用”请检查模型供应商配置是否正确网络是否通畅API Key 是否有余额或权限。5.2 RAG 知识库功能测试这是 Dify 的杀手锏功能测试将本地文档转化为知识并问答。创建知识库在左侧导航栏点击“知识库”然后“创建知识库”命名为“测试文档”。上传文档进入知识库点击“上传文件”。准备一个 TXT 或 PDF 格式的文档例如一篇技术文章或产品说明书。上传后Dify 会自动进行文本提取、分块、向量化处理。创建应用并关联知识库新建一个“对话型应用”。在应用编排页面的“提示词”区域下方找到“上下文”部分点击“添加”。选择“知识库”然后选中你刚创建的“测试文档”。进行检索问答测试在预览窗口提问一个文档中明确包含答案的问题。例如如果你的文档是关于“Dify 安装”的可以问“如何安装 Dify”。成功标志AI 的回答不仅基于其通用知识还精准引用了你上传文档中的内容回答中会显示引用的文档片段。失败排查如果回答未引用文档检查a) 知识库处理状态是否为“已完成”b) 在“上下文”设置中是否勾选了“启用检索”c) 提问是否足够具体。5.3 可视化工作流Agentic Workflow测试这是构建复杂 AI 应用的核心。我们创建一个简单的“多格式内容生成器”工作流。创建工作流点击“创建应用”这次选择“工作流”。命名为“多格式内容生成”。拖拽节点从左侧节点库中拖拽以下节点到画布开始节点。LLM节点用于生成文章大纲。LLM节点用于根据大纲生成博客正文。LLM节点用于根据大纲生成社交媒体推文。结束节点。连接节点将开始连接到第一个LLM节点。然后将第一个LLM节点的输出同时连接到第二个和第三个LLM节点的输入。最后将这两个节点的输出都连接到结束节点。配置节点点击第一个LLM节点在右侧面板设置系统提示词为“你是一个专业的编辑请根据用户主题生成一个详细的文章大纲。”点击第二个LLM节点系统提示词设为“你是一名技术博主请根据提供的大纲撰写一篇详细的博客文章。”点击第三个LLM节点系统提示词设为“你是一名社交媒体运营请根据提供的大纲创作三条吸引人的推文。”为每个节点选择合适的模型如 GPT-3.5-Turbo。运行测试点击右上角的“运行”。在弹出窗口的“用户输入”中输入主题例如“AI 在软件开发中的未来”。成功标志工作流依次执行最终在“运行记录”中你能看到三个 LLM 节点的输出结果——一份大纲、一篇博客草稿和三条推文。这证明工作流能并行或串行执行多个 AI 任务。失败排查如果某个节点执行失败检查该节点的模型配置和连接线是否正确。查看运行日志中的具体错误信息。6. 接口 API 与批量任务Dify 不仅是 Web 界面更是一个强大的 API 服务平台。你构建的任何应用都可以通过 API 对外提供服务。6.1 获取应用 API 密钥与端点在 Dify 控制台进入你创建的应用比如之前建的对话应用。点击顶部导航栏的“发布”。在“API 访问”部分你会看到API 密钥需要创建一个新的 API Key。API 地址通常是http://你的服务器IP:5001/v1后端 API 地址。应用访问端点每个应用有独立的 Endpoint格式如{API地址}/chat-messages(对话) 或{API地址}/workflows/run(工作流)。6.2 通过 API 调用对话应用以下是一个使用 Pythonrequests库调用对话型应用的示例import requests import json # 配置参数 api_key “你的应用 API Key” api_base “http://localhost:5001/v1” # 替换为你的实际地址 app_endpoint f“{api_base}/chat-messages” # 请求头 headers { “Authorization”: f“Bearer {api_key}”, “Content-Type”: “application/json” } # 请求体 payload { “inputs”: {}, # 传入的变量如果提示词中有 {{variable}} 则需要 “query”: “你好请介绍一下你自己”, # 用户问题 “response_mode”: “streaming”, # 或 “blocking”阻塞式等待完整返回 “conversation_id”: “”, # 可选用于多轮对话 “user”: “test_user_001” # 用户标识用于审计 } # 发送请求 (流式响应示例) response requests.post(app_endpoint, jsonpayload, headersheaders, streamTrue) if response.status_code 200: for line in response.iter_lines(): if line: decoded_line line.decode(‘utf-8’) if decoded_line.startswith(‘data: ‘): data json.loads(decoded_line[6:]) # 去掉 ‘data: ‘ 前缀 if data[‘event’] ‘message’: # 打印流式返回的文本片段 print(data[‘answer’], end‘’, flushTrue) elif data[‘event’] ‘message_end’: print(“\n--- 回答结束 ---“) else: print(f“请求失败状态码{response.status_code}“) print(response.text)6.3 通过 API 调用工作流应用并实现批量任务工作流应用的 API 调用与对话应用类似但 endpoint 和参数不同。批量任务的核心是循环调用此 API。import requests import json api_key “你的工作流应用 API Key” api_base “http://localhost:5001/v1” workflow_endpoint f“{api_base}/workflows/run” headers { “Authorization”: f“Bearer {api_key}”, “Content-Type”: “application/json” } # 假设你的工作流需要一个输入变量叫 topic batch_topics [“云计算的优势”, “机器学习的应用”, “区块链技术简介”] for topic in batch_topics: print(f“处理主题{topic}“) payload { “inputs”: {“topic”: topic}, # 对应工作流的输入变量 “response_mode”: “blocking” # 批量处理建议用阻塞模式 } try: response requests.post(workflow_endpoint, jsonpayload, headersheaders, timeout120) if response.status_code 200: result response.json() # 根据你的工作流输出结构解析结果 # 例如如果输出变量叫 output则 result.get(‘data’, {}).get(‘outputs’, {}).get(‘output’) print(f“结果{result}“) else: print(f“处理 ‘{topic}’ 失败: {response.status_code} - {response.text}“) except requests.exceptions.RequestException as e: print(f“请求异常 ‘{topic}’: {e}“) # 可选添加延迟以避免触发速率限制 # time.sleep(1)6.4 高级批量与异步任务对于大规模批量任务建议使用消息队列将任务发布到 Redis 或 RabbitMQ 队列由后台 Worker 消费并调用 Dify API。利用 Dify 的异步端点某些调用模式支持异步返回一个任务 ID随后可轮询获取结果。监控与重试在批量脚本中加入日志记录和错误重试机制。7. 资源占用与性能观察了解 Dify 运行时的资源消耗对于规划生产环境配置至关重要。7.1 基础服务资源占用使用docker stats命令可以实时查看各容器的资源使用情况docker stats --format “table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}”典型的内存占用情况空载时dify-web/dify-app约 200-400 MBdify-api约 300-600 MBpostgres约 100-200 MBredis约 50-100 MBminio约 100-200 MB总计在未处理任何请求时整体内存占用约为1GB - 1.5GB。这是平台本身的基础开销。7.2 模型推理资源占用关键平台本身不直接消耗大量 GPU 显存。显存占用来自于嵌入模型当你使用知识库功能时Dify 会使用嵌入模型如BGE-M3,text-embedding-3-small将文本转换为向量。如果使用本地嵌入模型通过 Ollama 或 Hugging Face 部署它会占用显存。一个常见的bge-m3模型加载后可能占用 1-2GB 显存。本地大语言模型如果你在 Dify 中配置了本地的 LLM如通过 Ollama 部署的qwen2.5:7b那么该模型的显存占用将叠加。一个 7B 的量化模型可能需要 4-8GB 显存。监控建议使用nvidia-smiNVIDIA GPU或radeontopAMD GPU监控显存。在 Dify 后台的“日志与统计”中可以查看 API 调用耗时、Token 消耗等这是评估性能的直接依据。7.3 性能优化方向分离部署对于高并发生产环境可以考虑将dify-api承担主要计算与其他服务数据库、Redis部署在不同服务器上。使用云服务模型优先使用 OpenAI、Azure、Anthropic 等云端 API将计算压力转移到云端减轻本地资源负担。缓存策略利用 Redis 缓存频繁访问的提示词模板、知识库检索结果等。向量数据库优化如果知识库文档量巨大百万级以上考虑使用性能更高的专业向量数据库如 Qdrant, Weaviate替代 Dify 内置的 PGVector并对其进行独立部署和优化。8. 常见问题与排查方法部署和使用过程中你可能会遇到一些问题。下表列出了常见问题及其解决方法。问题现象可能原因排查方式解决方案访问localhost:3000无法连接1. 服务未成功启动。2. 端口被占用。3. 防火墙/安全组阻止。1.docker compose ps查看容器状态。2.docker compose logs dify-app查看前端日志。3.netstat -tlnp | grep :3000检查端口。1. 重启服务docker compose restart。2. 修改docker-compose.yaml中前端端口映射如”3001:3000″。3. 关闭防火墙或放行端口。启动时数据库连接错误1. 数据库容器启动慢。2..env中DB_PASSWORD配置错误。3. 磁盘空间不足。1.docker compose logs dify-db查看数据库日志。2. 检查.env文件与docker-compose.yaml中密码是否一致。1. 增加depends_on等待时间高级。2. 确保密码一致无特殊字符。3. 清理磁盘空间。知识库文档处理失败1. 文档格式不支持或损坏。2. 嵌入模型服务未就绪或配置错误。3. 文本分块参数不合理。1. 查看知识库处理详情页的错误信息。2. 检查“模型供应商”中嵌入模型配置。3. 尝试上传一个简单的.txt文件测试。1. 确保文档为 PDF、DOCX、TXT、MD 等支持格式。2. 正确配置嵌入模型 API如 OpenAI 或本地 Ollama。3. 调整知识库的文本分割器设置。调用 API 返回 401/403 错误1. API Key 错误或过期。2. 请求头Authorization格式错误。3. 应用未发布或 API 访问未启用。1. 检查 API Key 是否复制正确是否包含空格。2. 核对请求头格式是否为Bearer api_key。3. 在 Dify 控制台确认应用已“发布”。1. 在 Dify 中重新生成 API Key。2. 修正代码中的请求头。3. 在应用“发布”页面启用 API 访问。工作流运行卡住或报错1. 某个节点如 LLM 调用超时或失败。2. 节点间变量连接错误。3. 循环依赖导致死循环。1. 查看工作流运行记录的详细日志。2. 检查每个节点的输入输出变量名是否匹配。3. 简化工作流逐步调试。1. 检查模型供应商网络和配置。2. 重新连接节点确保变量传递正确。3. 为可能耗时的节点设置超时时间。上传大文件失败1. Nginx 或服务端有文件大小限制。2. 客户端网络不稳定。1. 查看浏览器开发者工具 Network 标签。2. 查看dify-api容器日志。1. 修改 Docker 部署中 Nginx 的client_max_body_size配置默认可能较小。2. 分拆大文件或通过其他方式导入。内存/CPU 占用过高1. 并发请求过多。2. 本地模型LLM/Embedding资源消耗大。3. 存在内存泄漏旧版本可能。1. 使用docker stats和top命令监控。2. 观察哪个容器占用最高。1. 升级服务器配置。2. 将本地模型替换为云端 API。3. 考虑升级到最新稳定版 Dify。9. 最佳实践与使用建议基于大量实践遵循以下建议可以让你更高效、更稳定地使用 Dify。从简单开始迭代复杂不要一开始就设计包含几十个节点的巨型工作流。先构建一个最小可行产品MVP例如一个简单的问答机器人然后逐步添加知识库、条件分支、外部工具调用等复杂功能。善用变量与提示词模板在工作流中将可复用的文本如系统指令、固定格式设置为“变量”或“知识库片段”。在提示词中通过{{variable_name}}引用提高可维护性。为生产环境做好配置修改默认密码务必修改.env中的SECRET_KEY、DB_PASSWORD等默认密码。启用 HTTPS通过反向代理如 Nginx为 Dify 配置 SSL 证书。数据备份定期备份 PostgreSQL 数据库和 MinIO 存储桶中的数据。Docker 卷通常位于/var/lib/docker/volumes/下。监控与告警配置对服务器资源CPU、内存、磁盘、Docker 容器状态以及 Dify 自身 API 健康度的监控。模型供应商管理为不同用途开发、测试、生产创建不同的模型供应商配置。对于付费 API如 OpenAI在 Dify 中设置用量限制避免意外消耗。积极尝试本地模型通过 Ollama、OpenAI-Compatible API降低成本并提升数据隐私性。版本控制你的应用Dify 支持应用的导出和导入。在做出重大更改前导出应用配置作为备份。考虑使用 Git 来管理导出的 JSON 配置文件实现应用配置的版本控制。深入理解“上下文”与“记忆”对话上下文在对话型应用中合理设置“上下文长度”和“记忆”规则以平衡效果与成本。知识库检索调整检索的“相似度阈值”和“返回数量”以优化答案的相关性和准确性。对于专业领域使用领域相关的嵌入模型效果更佳。加入社区Dify 拥有活跃的 GitHub 和 Discord 社区。遇到棘手问题时搜索 Issues 或提问往往能快速找到解决方案或灵感。10. 总结与下一步Dify 通过将 AI 应用开发中繁琐的工程部分——模型集成、流程编排、状态管理、部署监控——进行封装和可视化真正做到了“开箱即用”。它降低了 AI 应用的门槛让开发者能更专注于业务逻辑和创新本身。通过本文你应该已经完成了从零部署、核心功能验证到 API 调用的全过程。最值得你立即尝试的下一步是动手构建你的第一个“端到端”应用选择一个你熟悉的业务场景比如“周报生成器”、“竞品分析助手”、“内部知识问答”使用 Dify 的工作流和知识库功能在 1 小时内搭建出一个可用的原型。这个过程会让你深刻体会到其效率。最容易踩的坑通常集中在网络模型 API 无法连接、配置环境变量错误和资源内存不足上。按照第 8 部分的排查方法大部分问题都能快速解决。后续深入方向探索插件市场集成 GitHub、Google Search、Notion 等外部工具让你的 AI Agent 能力更强。研究 MCP 集成将 Dify 应用发布为 MCP Server在 Claude Desktop 或 Cursor 中直接调用创造无缝的 AI 体验。性能调优与高可用部署学习如何将 Dify 部署到 Kubernetes配置负载均衡和自动扩缩容以满足企业级的高并发需求。Dify 的生态正在快速演进保持关注其 GitHub 仓库的更新你会发现更多强大的新特性。现在关闭这篇教程打开你的浏览器访问localhost:3000开始构建吧。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度