|
|
# 技术文档：`xiaozhi-esp32-server`
|
|
|
|
|
|
**目录：**
|
|
|
|
|
|
1. [引言](#1-引言)
|
|
|
2. [整体架构](#2-整体架构)
|
|
|
3. [核心组件深度剖析](#3-核心组件深度剖析)
|
|
|
* [3.1. `xiaozhi-server` (核心AI引擎 - Python实现)](#31-xiaozhi-server-核心ai引擎---python实现)
|
|
|
* [3.2. `manager-api` (管理后端 - Java Spring Boot实现)](#32-manager-api-管理后端---java-spring-boot实现)
|
|
|
* [3.3. `manager-web` (Web管理前端 - Vue.js实现)](#33-manager-web-web管理前端---vuejs实现)
|
|
|
4. [数据流与交互机制](#4-数据流与交互机制)
|
|
|
5. [核心功能概要](#5-核心功能概要)
|
|
|
6. [部署与配置概述](#6-部署与配置概述)
|
|
|
---
|
|
|
|
|
|
## 1. 引言
|
|
|
|
|
|
`xiaozhi-esp32-server` 项目是一个专为基于ESP32的智能硬件提供支持的**综合性后端系统**。其核心目标是使开发人员能够快速构建一个强大的服务器基础设施，该设施不仅能够理解自然语言指令，还能与多种AI服务（用于语音识别、自然语言理解及语音合成）进行高效交互、管理物联网（IoT）设备，并提供一个基于Web的用户界面以进行系统配置和管理。通过将多种尖端技术整合到一个高内聚且可扩展的平台中，本项目旨在简化和加速可定制化语音助手及智能控制系统的开发进程。它不仅仅是一个简单的服务器，更是一个连接硬件、AI能力与用户管理的桥梁。
|
|
|
|
|
|
---
|
|
|
|
|
|
## 2. 整体架构
|
|
|
|
|
|
`xiaozhi-esp32-server` 系统采用了一种**分布式、多组件协作**的架构设计，确保了系统的模块化、可维护性和可扩展性。各个核心组件各司其职，协同工作。主要组件包括：
|
|
|
|
|
|
1. **ESP32 硬件 (客户端设备):**
|
|
|
这是终端用户直接与之交互的物理智能硬件设备。其主要职责包括：
|
|
|
* 捕捉用户的语音指令。
|
|
|
* 将捕捉到的原始音频数据安全地发送至 `xiaozhi-server` 进行处理。
|
|
|
* 接收来自 `xiaozhi-server` 合成的语音回复，并通过扬声器播放给用户。
|
|
|
* 根据从 `xiaozhi-server` 收到的指令，控制与之连接的其他外围设备或IoT设备（例如智能灯泡、传感器等）。
|
|
|
|
|
|
2. **`xiaozhi-server` (核心AI引擎 - Python实现):**
|
|
|
这个基于Python的服务器是整个系统的“大脑”，负责处理所有语音相关的逻辑和AI交互。其关键职责细化如下：
|
|
|
* 通过WebSocket协议与ESP32设备建立**稳定、低延迟的实时双向通信链路**。
|
|
|
* 接收来自ESP32的音频流，并利用语音活动检测（VAD）技术精确切分有效的语音片段。
|
|
|
* 集成并调用自动语音识别（ASR）服务（可配置本地或云端），将语音片段转换为文本。
|
|
|
* 通过与大型语言模型（LLM）的交互来解析用户意图、生成智能回复，并支持复杂的自然语言理解任务。
|
|
|
* 管理多轮对话中的上下文信息和用户记忆，以提供连贯的交互体验。
|
|
|
* 调用文本转语音（TTS）服务，将LLM生成的文本回复合成为自然流畅的语音。
|
|
|
* 通过一个灵活的**插件系统**执行自定义命令，包括对IoT设备的控制逻辑。
|
|
|
* 从 `manager-api` 服务获取其详细的运行时操作配置。
|
|
|
|
|
|
3. **`manager-api` (管理后端 - Java实现):**
|
|
|
这是一个基于Java Spring Boot框架构建的应用程序，它为整个系统的管理和配置提供了一套安全的RESTful API。它不仅是 `manager-web` 控制台的后端支撑，也是 `xiaozhi-server` 的配置数据来源。其核心功能包括：
|
|
|
* 为Web控制台提供用户认证（登录、权限验证）和用户账户管理功能。
|
|
|
* ESP32设备的注册、信息管理以及设备特定配置的维护。
|
|
|
* 在**MySQL数据库**中持久化存储系统配置，例如用户选择的AI服务提供商、API密钥、设备参数、插件设置等。
|
|
|
* 提供特定的API端点，供 `xiaozhi-server` 拉取其所需的最新配置。
|
|
|
* 管理TTS音色选项、处理OTA（Over-The-Air）固件更新流程及相关元数据。
|
|
|
* 利用 **Redis** 作为高速缓存，存储热点数据（如会话信息、频繁访问的配置），以提升API响应速度和系统整体性能。
|
|
|
|
|
|
4. **`manager-web` (Web控制面板 - Vue.js实现):**
|
|
|
这是一个基于Vue.js构建的单页应用（SPA），为系统管理员提供了一个图形化、用户友好的操作界面。其主要能力包括：
|
|
|
* 便捷地配置 `xiaozhi-server` 所使用的各项AI服务（如ASR、LLM、TTS的提供商切换、参数调整）。
|
|
|
* 管理平台用户账户、角色分配及权限控制。
|
|
|
* 管理已注册的ESP32设备及其相关设置。
|
|
|
* （潜在功能）监控系统运行状态、查看日志、进行故障排查等。
|
|
|
* 与 `manager-api` 提供的所有后端管理功能进行全面的交互。
|
|
|
|
|
|
**高层交互流程概述:**
|
|
|
|
|
|
* **语音交互主线:** **ESP32设备**捕捉到用户语音后，通过**WebSocket**将音频数据实时传输给**`xiaozhi-server`**。`xiaozhi-server`完成一系列AI处理（VAD、ASR、LLM交互、TTS）后，再通过WebSocket将合成的语音回复发送回ESP32设备进行播放。所有与语音直接相关的实时交互均在此链路完成。
|
|
|
* **管理配置主线:** 管理员通过浏览器访问**`manager-web`**控制台。`manager-web`通过调用**`manager-api`**提供的**RESTful HTTP接口**来执行各种管理操作（如修改配置、管理用户或设备）。数据以JSON格式在两者间传递。
|
|
|
* **配置同步:** **`xiaozhi-server`**在启动或特定更新机制触发时，会主动通过HTTP请求从**`manager-api`**拉取其最新的操作配置。这确保了管理员在Web界面上所做的配置更改能够及时有效地应用到核心AI引擎的运行中。
|
|
|
|
|
|
这种**前后端分离、核心服务与管理服务分离**的架构设计，使得 `xiaozhi-server`能够专注于高效的实时AI处理任务，而 `manager-api` 和 `manager-web` 则共同提供了一个功能强大且易于使用的管理和配置平台。各组件职责清晰，有利于独立开发、测试、部署和扩展。
|
|
|
|
|
|
```
|
|
|
xiaozhi-esp32-server
|
|
|
├─ xiaozhi-server 8000 端口 Python语言开发 负责与esp32通信
|
|
|
├─ manager-web 8001 端口 Node.js+Vue开发 负责提供控制台的web界面
|
|
|
├─ manager-api 8002 端口 Java语言开发 负责提供控制台的api
|
|
|
```
|
|
|
|
|
|
---
|
|
|
|
|
|
## 3. 核心组件深度剖析
|
|
|
|
|
|
### 3.1. `xiaozhi-server` (核心AI引擎 - Python实现)
|
|
|
|
|
|
`xiaozhi-server` 作为系统的智能核心，全权负责处理语音交互、对接各类AI服务以及管理与ESP32设备间的通信。其设计目标是实现高效、灵活且可扩展的语音AI处理能力。
|
|
|
|
|
|
* **核心目标:**
|
|
|
* 为ESP32设备提供实时的语音指令处理服务。
|
|
|
* 深度集成各类AI服务，包括：自动语音识别 (ASR)、大型语言模型 (LLM) 进行自然语言理解 (NLU)、文本转语音 (TTS)、语音活动检测 (VAD)、意图识别 (Intent Recognition) 及对话记忆 (Memory)。
|
|
|
* 精细管理用户与设备间的对话流程及上下文状态。
|
|
|
* 基于用户指令，通过插件化机制执行自定义函数及控制物联网 (IoT) 设备。
|
|
|
* 支持通过 `manager-api`进行动态配置加载与更新。
|
|
|
|
|
|
* **核心技术栈:**
|
|
|
* **Python 3:** 作为主要编程语言，Python以其丰富的AI/ML生态库和快速开发特性被选用。
|
|
|
* **Asyncio:** Python的异步编程框架，是`xiaozhi-server`高性能的关键。它被广泛用于高效处理来自大量ESP32设备的并发WebSocket连接，以及执行与外部AI服务API通信时的非阻塞I/O操作，确保服务器在高并发下的响应能力。
|
|
|
* **`websockets` 库:** 提供WebSocket服务器的具体实现，支持与ESP32客户端进行全双工实时通信。
|
|
|
* **HTTP客户端 (如 `aiohttp`, `httpx`):** 用于异步执行HTTP请求，主要目的是从`manager-api`获取配置信息，以及与云端AI服务的API进行交互。
|
|
|
* **YAML (通常通过 PyYAML 库):** 用于解析本地的 `config.yaml` 配置文件。
|
|
|
* **FFmpeg (外部依赖):** 在 `app.py` 启动时会进行检查 (`check_ffmpeg_installed()`)。FFmpeg通常用于音频处理和格式转换，例如，确保音频数据符合特定AI服务的要求或进行内部处理。
|
|
|
|
|
|
* **关键实现细节:**
|
|
|
|
|
|
1. **AI服务提供者模式 (Provider Pattern - `core/providers/`):**
|
|
|
* **设计思想:** 这是`xiaozhi-server`集成不同AI服务的核心设计模式，极大地增强了系统的灵活性和可扩展性。针对每一种AI服务类型（ASR, TTS, LLM, VAD, Intent, Memory, VLLM），都在其对应子目录下定义了一个抽象基类 (ABC, Abstract Base Class)，例如 `core/providers/asr/base.py`。这个基类规定了该类型服务必须实现的通用接口方法（如ASR的 `async def transcribe(self, audio_chunk: bytes) -> str: pass`）。
|
|
|
* **具体实现:** 各种具体的AI服务提供商或本地模型的实现，则以独立的Python类形式存在（例如 `core/providers/asr/fun_local.py` 实现了本地FunASR的逻辑，`core/providers/llm/openai.py` 实现了与OpenAI GPT模型的对接）。这些具体类继承自相应的抽象基类，并实现其定义的接口。部分提供者还使用DTOs (Data Transfer Objects, 存在于各自的 `dto/` 目录) 来结构化与外部服务交换的数据。
|
|
|
* **优势:** 使得核心业务逻辑能够以统一的方式调用不同的AI服务，而无需关心其底层具体实现。用户可以通过配置文件轻松切换AI服务后端。添加对新AI服务的支持也变得相对简单，只需实现对应的Provider接口。
|
|
|
* **动态加载与初始化:** `core/utils/modules_initialize.py` 脚本扮演了工厂的角色。它在服务器启动时，或在接收到配置更新指令时，会根据配置文件中 `selected_module` 及各项服务的具体provider设置，动态地导入并实例化相应的Provider类。
|
|
|
|
|
|
2. **WebSocket通信与连接处理 (`app.py`, `core/websocket_server.py`, `core/connection.py`):**
|
|
|
* **服务器启动与入口 (`app.py`):**
|
|
|
* `app.py` 作为主入口，负责初始化应用环境（如检查FFmpeg、加载配置、设置日志）。
|
|
|
* 它会生成或加载一个 `auth_key` (JWT密钥)，用于保护特定的HTTP接口（如视觉分析接口 `/mcp/vision/explain`）。若配置中 `manager-api.secret` 为空，则会生成一个UUID作为 `auth_key`。
|
|
|
* 使用 `asyncio.create_task()` 并发启动 `WebSocketServer` (监听如 `ws://0.0.0.0:8000/xiaozhi/v1/`) 和 `SimpleHttpServer` (监听如 `http://0.0.0.0:8003/xiaozhi/ota/`)。
|
|
|
* 包含一个 `monitor_stdin()` 协程，用于在某些环境下保持应用存活或处理终端输入。
|
|
|
* **WebSocket服务器核心 (`core/websocket_server.py`):**
|
|
|
* `WebSocketServer` 类使用 `websockets` 库监听来自ESP32设备的连接请求。
|
|
|
* 对于每一个成功的WebSocket连接，它都会创建一个**独立的 `ConnectionHandler` 实例** (推测定义于 `core/connection.py`)。这种每个连接一个处理程序实例的设计模式，是实现多设备状态隔离和并发处理的关键，确保每个设备的对话流程和上下文信息互不干扰。
|
|
|
* 该服务器还提供一个 `_http_response` 方法，允许在同一端口上对非WebSocket升级的HTTP GET请求做出简单响应（例如返回 "Server is running"），便于进行健康检查。
|
|
|
* **动态配置更新:** `WebSocketServer` 包含一个 `update_config()` 异步方法。此方法使用 `config_lock` (一个 `asyncio.Lock`) 保证配置更新的原子性。它调用 `get_config_from_api()` (可能在 `config_loader.py` 中实现，通过 `manage_api_client.py` 与 `manager-api` 通信) 来获取新的配置。通过 `check_vad_update()` 和 `check_asr_update()` 等辅助函数判断是否需要重新初始化特定的AI模块，避免不必要的开销。更新后的配置会用于重新调用 `initialize_modules()`，从而实现AI服务提供者的热切换。
|
|
|
|
|
|
3. **消息处理与对话流程控制 (`core/handle/` 和 `ConnectionHandler`):**
|
|
|
* `ConnectionHandler` (推测) 作为每个连接的控制中心，负责接收来自ESP32的消息，并根据消息类型或当前对话状态，将其分发给 `core/handle/` 目录下的相应处理模块。这种模块化的处理器设计使得 `ConnectionHandler` 逻辑更清晰，易于扩展。
|
|
|
* **主要处理模块及其职责:**
|
|
|
* `helloHandle.py`: 处理与ESP32初次连接时的握手协议、设备认证或初始化信息交换。
|
|
|
* `receiveAudioHandle.py`: 接收音频流数据，调用VAD Provider进行语音活动检测，并将有效的音频片段传递给ASR Provider进行识别。
|
|
|
* `textHandle.py` / `intentHandler.py`: 获取ASR识别出的文本后，与Intent Provider (可能利用LLM进行意图识别) 和LLM Provider交互，以理解用户意图并生成初步回复或决策。
|
|
|
* `functionHandler.py`: 当LLM的响应包含执行特定“函数调用”的指令时，此模块负责从插件注册表中查找并执行对应的插件函数。
|
|
|
* `sendAudioHandle.py`: 将LLM最终生成的文本回复交给TTS Provider合成语音，并将音频流通过WebSocket发送回ESP32。
|
|
|
* `abortHandle.py`: 处理来自ESP32的中断请求，例如停止当前的TTS播报。
|
|
|
* `iotHandle.py`, `mcpHandle.py`: 处理与IoT设备控制相关的特定指令或更复杂的模块通信协议 (MCP)。
|
|
|
|
|
|
4. **插件化功能扩展系统 (`plugins_func/`):**
|
|
|
* **设计目的:** 提供一种标准化的方式来扩展语音助手的功能和“技能”，而无需修改核心代码。
|
|
|
* **实现机制:**
|
|
|
* 各个具体功能以独立的Python脚本形式存在于 `plugins_func/functions/` 目录中（例如 `get_weather.py`, `hass_set_state.py` 用于Home Assistant集成）。
|
|
|
* `loadplugins.py` 在服务器启动时负责扫描并加载这些插件模块。
|
|
|
* `register.py` (或插件模块内部的特定装饰器/函数) 可能用于定义每个插件函数的元数据，包括：
|
|
|
* **函数名称 (Function Name):** LLM调用时使用的标识符。
|
|
|
* **功能描述 (Description):** 供LLM理解此函数的作用。
|
|
|
* **参数模式 (Parameters Schema):** 通常是一个JSON Schema，详细定义了函数所需的参数、类型、是否必需以及描述。这是LLM能够正确生成函数调用参数的关键。
|
|
|
* **执行流程:** 当LLM在其思考过程中决定需要调用某个外部工具或函数来获取信息或执行操作时，它会依据预先提供的函数模式生成一个结构化的“函数调用”请求。`xiaozhi-server`中的`functionHandler.py`捕获此请求，从插件注册表中找到对应的Python函数并执行，然后将执行结果返回给LLM，LLM再基于此结果生成最终给用户的自然语言回复。
|
|
|
|
|
|
5. **配置管理 (`config/`):**
|
|
|
* **加载机制:** `config_loader.py` (通过 `settings.py` 被调用) 负责从根目录的 `config.yaml` 文件加载基础配置。
|
|
|
* **远程配置与合并:** 通过 `manage_api_client.py` (使用如`aiohttp`的库与`manager-api`通信) 可以从`manager-api`服务拉取配置。远程配置通常会覆盖本地 `config.yaml` 中的同名设置，从而实现通过Web界面动态调整服务器行为。
|
|
|
* **日志系统:** `logger.py` 初始化应用日志系统（可能使用 `loguru` 或对标准 `logging` 模块进行封装，支持通过 `logger.bind(tag=TAG)` 添加标签，便于追踪和过滤）。
|
|
|
* **静态资源:** `config/assets/` 目录下存放了用于系统提示音的静态音频文件（如设备绑定提示音 `bind_code.wav`、错误提示音等）。
|
|
|
|
|
|
6. **辅助HTTP服务 (`core/http_server.py`):**
|
|
|
* 与WebSocket服务并行运行一个简单的HTTP服务器，用于处理特定的HTTP请求。最主要的功能是为ESP32设备提供OTA (Over-The-Air) 固件更新的下载服务 (通过 `/xiaozhi/ota/` 端点)。此外，也可能承载其他如 `/mcp/vision/explain` (视觉分析) 等工具性HTTP接口。
|
|
|
|
|
|
综上所述，`xiaozhi-server` 是一个采用现代Python异步编程模型构建的、高度模块化、配置驱动的AI应用服务器。其精心设计的Provider模式和插件架构赋予了它强大的适应性和扩展性，能够灵活接入不同的AI能力并支持日益增长的功能需求。
|
|
|
|
|
|
---
|
|
|
|
|
|
### 3.2. `manager-api` (管理后端 - Java Spring Boot实现)
|
|
|
|
|
|
`manager-api` 组件是使用Java和Spring Boot框架构建的强大后端服务，作为整个`xiaozhi-esp32-server`生态系统的中央行政管理和配置中枢。
|
|
|
|
|
|
* **核心目标:**
|
|
|
* 为`manager-web`（Vue.js前端）提供一套安全、稳定、符合RESTful规范的API接口，使得管理员能够便捷地管理用户、设备、系统配置及其他相关资源。
|
|
|
* 充当`xiaozhi-server`（Python核心AI引擎）的集中化配置数据提供者，允许`xiaozhi-server`实例在启动或运行时获取其最新的操作参数。
|
|
|
* 持久化存储关键数据，例如：用户账户信息、设备注册详情、AI服务提供商配置（包括API密钥、选定的服务模型等）、TTS音色参数，以及OTA固件版本信息等。
|
|
|
|
|
|
* **核心技术栈:**
|
|
|
* **Java 21:** 项目采用的JDK版本，确保了对现代Java特性的支持。
|
|
|
* **Spring Boot 3:** 作为核心开发框架，极大地简化了独立、生产级别的Spring应用的创建和部署。它提供了自动配置、内嵌Web服务器（默认为Tomcat）、依赖管理等关键功能。
|
|
|
* **Spring MVC:** Spring框架中用于构建Web应用和RESTful API的模块。
|
|
|
* **MyBatis-Plus:** 一个对MyBatis进行功能增强的ORM（对象关系映射）框架。它简化了数据库操作，提供了强大的CRUD（增删改查）功能、条件构造器、代码生成器等，并能很好地与Spring Boot集成。
|
|
|
* **MySQL:** 作为主要的后端关系型数据库，用于存储所有需要持久化的管理数据和配置信息。
|
|
|
* **Druid (Alibaba Druid):** 一个功能强大的JDBC连接池实现，提供了丰富的监控功能和优秀的性能，用于高效管理数据库连接。
|
|
|
* **Redis (通过 Spring Data Redis):** 一个高性能的内存数据结构存储，常用于实现数据缓存（例如缓存热点配置数据、用户会话信息），以显著提升API的响应速度。
|
|
|
* **Apache Shiro:** 一个成熟且易用的Java安全框架，负责处理应用的认证（用户身份验证）和授权（API访问权限控制）需求。
|
|
|
* **Liquibase:** 一个用于跟踪、管理和应用数据库 schéma（模式）变更的开源工具。它允许开发者以数据库无关的方式定义和版本化数据库结构变更。
|
|
|
* **Knife4j:** 一个集成了Swagger并增强了UI的API文档生成工具，专为Java MVC框架（尤其是Spring Boot）设计。它能生成美观且易于交互的API文档界面（通常通过 `/xiaozhi/doc.html` 访问）。
|
|
|
* **Maven:** 用于项目的构建自动化和依赖项管理。
|
|
|
* **Lombok:** 一个Java库，通过注解自动生成构造函数、getter/setter、equals/hashCode、toString等样板代码，减少冗余。
|
|
|
* **HuTool / Google Guava:** 提供大量实用工具类，简化常见编程任务。
|
|
|
* **Aliyun Dysmsapi:** 阿里云短信服务SDK，用于集成发送短信功能（如验证码、通知）。
|
|
|
|
|
|
* **关键实现细节:**
|
|
|
|
|
|
1. **模块化项目结构 (`modules/` 包):**
|
|
|
* `manager-api` 的核心业务逻辑被清晰地划分到 `src/main/java/xiaozhi/modules/` 目录下的不同模块中。这种按功能领域划分模块的方式（例如 `sys` 负责系统管理，`agent` 负责智能体配置，`device` 负责设备管理，`config` 负责为`xiaozhi-server`提供配置，`security` 负责安全，`timbre` 负责音色管理，`ota` 负责固件升级）极大地提高了代码的可维护性和可扩展性。
|
|
|
* **各模块内部结构:** 每个业务模块通常遵循经典的三层架构或其变体：
|
|
|
* **Controller (控制层):** 位于 `xiaozhi.modules.[模块名].controller`。
|
|
|
* **Service (服务层):** 位于 `xiaozhi.modules.[模块名].service`。
|
|
|
* **DAO/Mapper (数据访问层):** 位于 `xiaozhi.modules.[模块名].dao`。
|
|
|
* **Entity (实体类):** 位于 `xiaozhi.modules.[模块名].entity`。
|
|
|
* **DTO (数据传输对象):** 位于 `xiaozhi.modules.[模块名].dto`。
|
|
|
|
|
|
2. **分层架构实现:**
|
|
|
* **Controller层 (`@RestController`):** 这些类使用Spring MVC注解（如 `@GetMapping`, `@PostMapping` 等）来定义API的端点(endpoints)。它们负责接收HTTP请求，将请求体中的JSON数据反序列化为DTO对象，调用相应的Service层方法处理业务逻辑，最后将Service层的返回结果序列化为JSON并作为HTTP响应返回给客户端。
|
|
|
* **Service层 (`@Service`):** 这些类（通常是接口及其实现类的组合）封装了核心的业务规则和操作流程。它们可能会调用一个或多个DAO/Mapper对象来与数据库交互，并常常使用 `@Transactional` 注解来管理数据库事务的原子性。
|
|
|
* **Data Access (DAO/Mapper) 层 (MyBatis-Plus Mappers):** 这些是Java接口，继承自MyBatis-Plus提供的 `BaseMapper<Entity>` 接口。MyBatis-Plus会为这些接口自动提供标准的CRUD方法。对于更复杂的数据库查询，开发者可以通过在Mapper接口中定义方法并使用注解（如 `@Select`, `@Update`）或编写对应的XML映射文件来实现。例如，`UserMapper.selectById(userId)` 会被MyBatis-Plus自动实现。
|
|
|
* **Entity层 (`@TableName`, `@TableId` 等MyBatis-Plus注解):** 这些POJO（Plain Old Java Objects）类直接映射到数据库中的表结构。Lombok的 `@Data` 注解常用于自动生成getter/setter等。
|
|
|
* **DTO层:** 用于在各层之间，特别是Controller层与Service层之间，以及API的请求/响应体中传递数据。使用DTO有助于解耦API接口的数据结构与数据库实体的数据结构，使API更稳定。
|
|
|
|
|
|
3. **通用功能与配置 (`common/` 包):**
|
|
|
* `src/main/java/xiaozhi/common/` 包提供了一系列跨模块共享的通用组件和配置：
|
|
|
* **基类:** 如 `BaseDao`, `BaseEntity`, `BaseService`, `CrudService`，为各模块的相应组件提供通用的属性或方法。
|
|
|
* **全局配置:** 包括 `MybatisPlusConfig` (MyBatis-Plus的配置，如分页插件、数据权限插件等)、`RedisConfig` (Redis连接及序列化配置)、`SwaggerConfig` (Knife4j的配置)、`AsyncConfig` (异步任务执行器配置)。
|
|
|
* **自定义注解:** 例如 `@LogOperation` 用于通过AOP记录操作日志，`@DataFilter` 可能用于实现数据范围过滤。
|
|
|
* **AOP切面:** 如 `RedisAspect` 可能用于实现方法级别的缓存逻辑。
|
|
|
* **全局异常处理:** `RenExceptionHandler` (使用 `@ControllerAdvice` 注解) 捕获应用中抛出的特定或所有异常 (如自定义的 `RenException`)，并返回统一格式的JSON错误响应给客户端。`ErrorCode` 定义了标准化的错误码。
|
|
|
* **工具类:** 提供了日期转换、JSON处理(Jackson)、IP地址获取、HTTP上下文操作、统一结果封装 (`Result` 类)等多种实用工具。
|
|
|
* **校验工具:** `ValidatorUtils` 和 `AssertUtils` 用于简化参数校验逻辑。
|
|
|
* **XSS防护:** `XssFilter` 等组件用于防止跨站脚本攻击。
|
|
|
* **MyBatis-Plus自动填充:** `FieldMetaObjectHandler` 用于在执行插入或更新数据库操作时，自动填充如 `createTime`, `updateTime` 等公共字段。
|
|
|
|
|
|
4. **安全机制 (Apache Shiro):**
|
|
|
* Shiro的配置（通常在 `modules/security/config/` 或 `common/config/` 下）定义了如何进行用户认证和授权。
|
|
|
* **Realms (域):** 自定义的Shiro Realm类负责从数据库中查询用户信息（用户名、密码、盐值）进行身份验证，以及获取用户的角色和权限信息用于授权决策。
|
|
|
* **Filters (过滤器):** Shiro过滤器链被应用于保护API端点，确保只有经过认证且拥有足够权限的用户才能访问特定资源。
|
|
|
* **Session/Token Management:** Shiro管理用户会话。对于RESTful API，可能结合OAuth2或JWT等令牌机制实现无状态认证。
|
|
|
|
|
|
5. **数据库版本控制 (Liquibase):**
|
|
|
* 数据库的表结构、索引、初始数据等变更，都通过Liquibase的 `changelog` 文件（通常是XML格式）进行定义和版本化管理。当应用启动时，Liquibase会自动检查并应用必要的数据库结构更新，确保开发、测试和生产环境数据库结构的一致性。
|
|
|
|
|
|
6. **API文档:**
|
|
|
* 完整的API接口文档可通过以下地址访问: https://2662r3426b.vicp.fun/xiaozhi/doc.html
|
|
|
* 该文档使用Knife4j生成,提供了所有RESTful API端点的详细说明、请求/响应示例以及在线测试功能。
|
|
|
|
|
|
`manager-api` 通过这些精心选择的技术和设计模式，构建了一个功能全面、结构清晰、安全可靠且易于维护和扩展的Java后端服务。其模块化的设计特别适合处理具有多种管理功能需求的复杂系统。
|
|
|
|
|
|
---
|
|
|
|
|
|
### 3.3. `manager-web` (Web管理前端 - Vue.js实现)
|
|
|
|
|
|
`manager-web` 组件是一个采用 Vue.js 2 框架构建的单页应用 (SPA - Single Page Application)。它为系统管理员提供了一个功能丰富、交互友好的图形用户界面，用于全面管理和配置 `xiaozhi-esp32-server` 生态系统。
|
|
|
|
|
|
* **核心目标:**
|
|
|
* 提供一个基于Web的集中式控制面板，供管理员进行系统操作与监控。
|
|
|
* 实现对 `xiaozhi-server` 中AI服务提供商（ASR、LLM、TTS等）及其相关API密钥或许可配置的便捷管理。
|
|
|
* 支持用户账户、角色及权限的精细化管理。
|
|
|
* 提供ESP32设备的注册、配置及状态查看功能。
|
|
|
* 允许管理员自定义TTS音色、管理OTA固件更新流程、调整系统级参数及字典数据等。
|
|
|
* 作为 `manager-api` 所暴露各项功能的图形化交互前端。
|
|
|
|
|
|
* **核心技术栈:**
|
|
|
* **Vue.js 2:** 一个渐进式的JavaScript框架，用于构建用户界面。其核心特性包括声明式渲染、组件化系统、数据绑定等，非常适合构建复杂的SPA。
|
|
|
* **Vue CLI (`@vue/cli-service`):** Vue.js的官方命令行工具，用于项目的快速搭建、开发服务器的运行（支持热模块替换HMR）、以及生产环境构建打包（内部集成并配置了Webpack）。
|
|
|
* **Vue Router (`vue-router`):** Vue.js官方的路由管理器。它负责在SPA内部实现不同“页面”或视图组件之间的导航切换，而无需重新加载整个HTML页面，提供了流畅的用户体验。
|
|
|
* **Vuex (`vuex`):** Vue.js官方的状态管理模式和库。它充当了应用中所有组件的“中央数据存储”，用于管理全局共享状态（例如当前登录用户信息、设备列表、应用配置等），特别适用于大型复杂应用。
|
|
|
* **Element UI (`element-ui`):** 一个广受欢迎的基于Vue 2.0的桌面端UI组件库。它提供了大量预先设计和实现的组件（如表单、表格、对话框、导航菜单、按钮、提示等），帮助开发者快速构建出专业且一致的用户界面。
|
|
|
* **JavaScript (ES6+):** 前端逻辑实现的主要编程语言，利用其现代特性进行开发。
|
|
|
* **SCSS (Sassy CSS):** 一种CSS预处理器，它为CSS增加了变量、嵌套规则、混合(Mixin)、继承等高级特性，使得CSS代码更易于组织、维护和复用。
|
|
|
* **HTTP客户端 (Flyio 或 Axios 通过 `vue-axios`):** 用于在浏览器端向 `manager-api` 后端发起异步HTTP（AJAX）请求，以获取数据或提交操作。
|
|
|
* **Webpack:** 一个强大的模块打包工具（由Vue CLI在底层管理和配置）。它将项目中的各种资源（JavaScript文件、CSS、图片、字体等）视为模块，并将它们打包成浏览器可识别的静态文件。
|
|
|
* **Workbox (通过 `workbox-webpack-plugin`):** Google开发的一个库，用于简化Service Worker的编写和PWA（Progressive Web App - 渐进式Web应用）的实现。它可以帮助生成Service Worker脚本，实现资源缓存、离线访问等功能。
|
|
|
* **Opus库 (`opus-decoder`, `opus-recorder`):** 这些音频处理库表明前端可能具备一些直接在浏览器中处理Opus格式音频的能力，例如：用于测试麦克风输入、允许管理员录制自定义音频片段（可能用于TTS音色样本或语音指令测试），或播放在管理界面中预览的Opus编码音频。
|
|
|
|
|
|
* **关键实现细节:**
|
|
|
|
|
|
1. **单页应用 (SPA) 结构:**
|
|
|
* 整个前端应用加载一个主HTML文件 (`public/index.html`)。后续的所有页面切换和内容更新都在客户端由Vue Router动态完成，无需每次都从服务器请求新的HTML页面。这种模式能提供更快的页面加载速度和更流畅的交互体验。
|
|
|
|
|
|
2. **组件化架构 (Component-Based Architecture):**
|
|
|
* 用户界面由一系列可复用的Vue组件 (`.vue` 单文件组件) 构成，形成一个组件树。这种方式提高了代码的模块化程度、可维护性和复用性。
|
|
|
* **`src/main.js`:** 应用的入口JS文件。它负责创建和初始化根Vue实例，注册全局插件（如Vue Router, Vuex, Element UI），并把根Vue实例挂载到 `public/index.html` 中的某个DOM元素上（通常是 `#app`）。
|
|
|
* **`src/App.vue`:** 应用的根组件。它通常定义了应用的基础布局结构（如包含导航栏、侧边栏、主内容区），并通过 `<router-view></router-view>` 标签来显示当前路由匹配到的视图组件。
|
|
|
* **视图组件 (`src/views/`):** 这些组件代表了应用中的各个“页面”或主要功能区（例如 `Login.vue` 登录页, `DeviceManagement.vue` 设备管理页, `UserManagement.vue` 用户管理页, `ModelConfig.vue` 模型配置页）。它们通常由Vue Router直接映射。
|
|
|
* **可复用UI组件 (`src/components/`):** 包含了在不同视图之间共享的、更小粒度的UI组件（例如 `HeaderBar.vue` 顶部导航栏, `AddDeviceDialog.vue` 添加设备对话框, `AudioPlayer.vue` 音频播放器组件）。
|
|
|
|
|
|
3. **客户端路由 (`src/router/index.js`):**
|
|
|
* Vue Router在此文件中进行配置，定义了应用的路由表。每个路由规则将一个特定的URL路径映射到一个视图组件。
|
|
|
* 常常包含**导航守卫 (Navigation Guards)**，例如 `beforeEach` 守卫，用于在路由跳转前执行逻辑，如检查用户是否已登录，如果未登录则重定向到登录页面，从而保护需要认证才能访问的页面。
|
|
|
|
|
|
4. **状态管理 (`src/store/index.js`):**
|
|
|
* Vuex被用来构建一个集中的状态管理中心（Store）。这个Store包含了：
|
|
|
* **State:** 存储应用级别的共享数据（例如，当前登录用户的详细信息、从API获取的设备列表、系统配置等）。
|
|
|
* **Getters:** 类似于Vue组件中的计算属性，用于从State派生出一些状态值，方便组件使用。
|
|
|
* **Mutations:** **唯一**可以同步修改State中数据的方法。它们必须是同步函数。
|
|
|
* **Actions:** 用于处理异步操作（如API调用）或封装多个Mutation提交。Actions会调用API，获取数据后，通过 `commit` 一个或多个Mutation来更新State。
|
|
|
* 例如，用户登录时，一个名为 `login` 的Action可能会被调用，它会向后端API发送登录请求，成功后获取到用户信息和token，然后 `commit` 一个名为 `SET_USER_INFO` 的Mutation来更新State中的用户信息和token。
|
|
|
|
|
|
5. **API通信 (`src/apis/`):**
|
|
|
* 与 `manager-api` 后端的所有HTTP通信逻辑被封装在 `src/apis/` 目录下，通常会按照后端API的模块进行组织（例如 `src/apis/module/agent.js`, `src/apis/module/device.js`）。
|
|
|
* 每个模块导出一系列函数，每个函数对应一个具体的API请求。这些函数内部使用配置好的HTTP客户端实例 (例如，在 `src/apis/api.js` 或 `src/apis/httpRequest.js` 中统一配置Axios或Flyio实例，可能包含设置请求基地址、请求/响应拦截器等)。
|
|
|
* **拦截器 (Interceptors):** HTTP客户端的请求拦截器常用于在每个请求发送前自动添加认证令牌（如JWT）；响应拦截器则可用于全局处理API错误（如权限不足、服务器错误）或对响应数据进行预处理。
|
|
|
|
|
|
6. **样式与资源 (`src/styles/`, `src/assets/`):**
|
|
|
* `Element UI` 提供了基础的组件样式。
|
|
|
* `src/styles/global.scss` 文件用于定义全局共享的SCSS样式、变量、混合(Mixin)等。
|
|
|
* Vue单文件组件内部的 `<style scoped>` 标签允许编写只作用于当前组件的局部样式。
|
|
|
* `src/assets/` 目录存放图片、字体等静态资源。
|
|
|
|
|
|
7. **构建与PWA特性:**
|
|
|
* Vue CLI通过Webpack将所有代码和资源打包成优化的静态文件，用于生产部署。
|
|
|
* `workbox-webpack-plugin` 的使用（体现在 `service-worker.js` 和 `registerServiceWorker.js` 文件）表明项目集成了Service Worker技术。Service Worker可以拦截网络请求，实现前端资源的智能缓存（从而加快后续访问速度），甚至在网络断开时提供一定的离线访问能力，是PWA的核心技术之一。
|
|
|
|
|
|
8. **环境配置 (`.env`系列文件):**
|
|
|
* 项目根目录下的 `.env` (以及 `.env.development`, `.env.production` 等) 文件用于定义环境变量。这些变量（例如 `VUE_APP_API_BASE_URL` 来指定 `manager-api` 的基础URL）可以在应用代码中通过 `process.env.VUE_APP_XXX` 的形式访问，从而允许为不同构建环境（开发、测试、生产）配置不同的参数。
|
|
|
|
|
|
`manager-web` 通过这些技术的综合运用，构建了一个功能强大、易于维护且用户体验良好的管理界面，为 `xiaozhi-esp32-server` 系统的配置和监控提供了坚实的前端支持。
|
|
|
|
|
|
---
|
|
|
|
|
|
## 4. 数据流与交互机制
|
|
|
|
|
|
`xiaozhi-esp32-server` 系统通过各组件间定义清晰的数据流和交互协议来协同工作。主要的通信方式依赖于针对实时交互优化的WebSocket协议和适用于客户端-服务器请求的RESTful API。
|
|
|
|
|
|
**4.1.核心语音交互流程 (ESP32设备 <-> `xiaozhi-server`)**
|
|
|
|
|
|
此流程是实时的，主要通过WebSocket进行低延迟、双向的数据交换。
|
|
|
|
|
|
* **通讯协议文档:**
|
|
|
* 详细的通讯协议说明文档可通过以下地址访问: https://ccnphfhqs21z.feishu.cn/wiki/M0XiwldO9iJwHikpXD5cEx71nKh
|
|
|
* 该文档详细描述了ESP32设备与`xiaozhi-server`之间的WebSocket通信协议,包括:
|
|
|
* 连接建立与握手流程
|
|
|
* 音频数据传输格式
|
|
|
* 控制命令格式
|
|
|
* 状态报告格式
|
|
|
* 错误处理机制
|
|
|
|
|
|
* **连接建立与握手:**
|
|
|
* ESP32设备作为客户端，主动向`xiaozhi-server`的指定端点（例如 `ws://<服务器IP>:<WebSocket端口>/xiaozhi/v1/`）发起WebSocket连接请求。
|
|
|
* `xiaozhi-server` (`core/websocket_server.py`) 接收连接，并为每个成功连接的ESP32设备实例化一个独立的`ConnectionHandler`对象来管理该会话的整个生命周期。
|
|
|
* 连接建立后，可能会执行一个初始握手流程（由`core/handle/helloHandle.py`处理），用于交换设备标识、认证信息、协议版本或基本状态。
|
|
|
|
|
|
* **音频上行传输 (ESP32 -> `xiaozhi-server`):**
|
|
|
* 用户对ESP32设备讲话后，设备上的麦克风捕捉原始音频数据（通常是PCM或经过压缩如Opus的格式）。
|
|
|
* ESP32将这些音频数据块（chunks）作为WebSocket的**二进制消息 (binary messages)** 实时推送到`xiaozhi-server`对应的`ConnectionHandler`。
|
|
|
* 服务器端的`core/handle/receiveAudioHandle.py`模块负责接收、缓冲并处理这些音频数据。
|
|
|
|
|
|
* **AI核心处理 (在`xiaozhi-server`内部):**
|
|
|
* **VAD (语音活动检测):** `receiveAudioHandle.py`利用配置的VAD提供者（如SileroVAD）分析音频流，以准确识别语音的起始和结束点，滤除静默或噪声片段。
|
|
|
* **ASR (自动语音识别):** 检测到的有效语音片段被送往配置的ASR提供者（本地如FunASR，或云端服务）。ASR引擎将音频信号转换为文本字符串。
|
|
|
* **NLU/LLM (自然语言理解/大型语言模型):** ASR输出的文本，连同从Memory提供者获取的当前对话上下文历史，以及从`plugins_func/`加载的可用函数（工具）的描述模式，一同被传递给配置的LLM提供者。
|
|
|
* **函数调用执行 (若LLM决策需要):** 如果LLM分析后认为需要调用外部函数（例如查询天气、控制家电），它会生成一个结构化的函数调用请求。`core/handle/functionHandler.py`接收此请求，查找并执行在`plugins_func/`中定义的相应Python函数，并将函数的执行结果返回给LLM。LLM随后基于此结果生成最终的自然语言回复。
|
|
|
* **回复生成:** LLM综合所有信息（用户输入、上下文、函数调用结果等）生成最终的文本回复。
|
|
|
* **记忆更新:** 当前轮次的交互（用户问题、LLM回复、可能的功能调用）会被Memory提供者处理，以更新对话历史，供后续交互使用。
|
|
|
* **TTS (文本转语音):** LLM生成的最终文本回复被送往配置的TTS提供者，后者将文本合成为语音数据流（例如MP3或WAV格式）。
|
|
|
|
|
|
* **音频下行响应 (`xiaozhi-server` -> ESP32):**
|
|
|
* 由TTS提供者合成的语音数据流，通过`core/handle/sendAudioHandle.py`模块，作为WebSocket的**二进制消息**实时发送回ESP32设备。
|
|
|
* ESP32设备接收这些音频数据块并立即通过扬声器播放给用户。
|
|
|
|
|
|
* **控制与状态消息 (双向):**
|
|
|
* 除了音频流，ESP32与`xiaozhi-server`之间也通过WebSocket交换**文本消息 (text messages)**，这些消息通常采用JSON格式封装。
|
|
|
* **ESP32 -> Server:** 设备可能发送状态报告（如网络状况、麦克风状态）、错误代码、或特定的控制命令（例如用户按键触发的“停止TTS播报”）。
|
|
|
* **Server -> ESP32:** 服务器可能发送控制指令给设备（如“开始监听”、“停止监听”、调整灵敏度、下发特定配置参数）。
|
|
|
* `core/handle/abortHandle.py`（处理中断请求）、`core/handle/reportHandle.py`（处理设备报告）等模块负责解析和响应这些控制/状态消息。
|
|
|
|
|
|
**4.2.管理与配置流程 (`manager-web` <-> `manager-api` <-> `xiaozhi-server`)**
|
|
|
|
|
|
此流程主要依赖于基于HTTP/HTTPS的RESTful API进行请求-响应式的交互。
|
|
|
|
|
|
* **管理员UI后端交互 (`manager-web` -> `manager-api`):**
|
|
|
* 当管理员在`manager-web`界面执行操作时（例如保存一项配置、添加一个新用户、注册一台ESP32设备）：
|
|
|
* Vue.js前端应用 (`manager-web`) 会通过其API封装模块（位于`src/apis/module/`）向`manager-api`的对应REST API端点发起异步HTTP请求（通常是GET, POST, PUT, DELETE）。
|
|
|
* 请求体和响应体通常使用JSON格式。
|
|
|
* `manager-api`中的`@RestController`类接收这些请求。**Apache Shiro**框架会首先对请求进行认证和授权检查。
|
|
|
* 通过验证后，Controller将请求分发给相应的Service层处理业务逻辑。Service层可能会与MySQL数据库（通过MyBatis-Plus）交互，并可能利用Redis进行数据缓存。
|
|
|
* 处理完成后，`manager-api`向`manager-web`返回一个JSON格式的HTTP响应。
|
|
|
* `manager-web`根据响应结果更新其Vuex状态存储和用户界面显示。
|
|
|
|
|
|
* **配置同步 (`manager-api` -> `xiaozhi-server`):**
|
|
|
* `xiaozhi-server`的运行依赖于从`manager-api`获取的动态配置（例如当前选用的AI服务提供商及其API密钥）。
|
|
|
* **拉取机制 (Pull Mechanism):** `xiaozhi-server`内部的`config/manage_api_client.py`模块，在服务器启动时或通过特定更新触发器（例如`WebSocketServer.update_config()`被调用），会向`manager-api`的一个指定端点（例如由`modules/config/controller/`中的某个Controller提供）发起HTTP GET请求。
|
|
|
* `manager-api`响应该请求，返回`xiaozhi-server`所需的配置数据（JSON格式）。
|
|
|
* `xiaozhi-server`接收到配置后，会更新其内部状态，并可能重新初始化相关的AI服务模块，以使新配置生效。
|
|
|
|
|
|
* **OTA固件更新流程 (概念性描述):**
|
|
|
* 管理员通过`manager-web`界面上传新的ESP32固件包到`manager-api`的特定端点。
|
|
|
* `manager-api`将固件文件存储起来，并记录相关元数据（版本号、适用设备型号等）。
|
|
|
* 当管理员触发对特定设备的OTA更新时：
|
|
|
* `manager-api`可能会通知`xiaozhi-server`（具体通知机制可能是一个轮询检查点，或`xiaozhi-server`暴露一个接收更新通知的API，或者更松耦合的如消息队列）。
|
|
|
* `xiaozhi-server`随后可以通过WebSocket向目标ESP32设备发送一条包含固件下载URL的指令消息。
|
|
|
* ESP32设备收到指令后，通过HTTP GET请求从该URL下载固件。此URL可能指向`xiaozhi-server`自身运行的`SimpleHttpServer`所服务的路径（如`/xiaozhi/ota/`），或者在某些架构中，也可能直接指向`manager-api`或专用的文件服务器。
|
|
|
|
|
|
**4.3. 主要协议总结:**
|
|
|
|
|
|
* **WebSocket:** 被选用于ESP32与`xiaozhi-server`之间的通信链路，因为它非常适合实时、低延迟、双向的数据流传输（尤其是音频），以及异步控制消息的传递。
|
|
|
* **RESTful APIs (基于HTTP/HTTPS，通常使用JSON作为数据交换格式):** 这是Web服务间通信的标准方式。用于`manager-web`（客户端）与`manager-api`（服务器）之间的请求-响应交互，也用于`xiaozhi-server`（作为客户端）从`manager-api`（作为服务器）拉取配置信息。其无状态特性、广泛的库支持和易于理解的语义使其成为此类交互的理想选择。
|
|
|
|
|
|
这种多协议并用的通信策略，确保了系统内不同类型的交互需求都能得到高效和恰当的处理，兼顾了实时性和标准化的请求-响应模式。
|
|
|
|
|
|
---
|
|
|
|
|
|
## 5. 核心功能概要
|
|
|
|
|
|
`xiaozhi-esp32-server` 系统提供了一系列丰富的功能，旨在支持开发者构建先进的语音控制应用：
|
|
|
|
|
|
1. **全面的语音交互后端:** 提供从语音捕获指导到响应生成和动作执行的端到端解决方案。
|
|
|
2. **模块化和可插拔的AI服务:**
|
|
|
* 支持广泛的ASR（自动语音识别）、LLM（大型语言模型）、TTS（文本转语音）、VAD（语音活动检测）、意图识别和记忆提供商。
|
|
|
* 允许动态选择和配置这些服务（包括基于云的API和本地模型），以平衡成本、性能、隐私和语言需求。
|
|
|
3. **高级对话管理:**
|
|
|
* 支持自然交互，具有唤醒词启动对话、手动（按键说话式）对话以及对系统响应的实时打断等功能。
|
|
|
* 包含上下文记忆，以在多轮对话中保持连贯性。
|
|
|
* 在一段时间不活动后具有自动休眠模式。
|
|
|
4. **多语言能力:**
|
|
|
* 支持多种语言的识别和合成，包括普通话、粤语、英语、日语和韩语（具体取决于所选的ASR/LLM/TTS提供商）。
|
|
|
5. **通过插件实现的可扩展功能:**
|
|
|
* 强大的插件系统允许开发人员添加自定义“技能”或函数（例如，获取天气、控制智能家居设备、访问新闻）。
|
|
|
* 这些函数可以由LLM使用其函数调用能力，根据提供的模式来触发。
|
|
|
* 内置对Home Assistant集成的支持。
|
|
|
6. **物联网设备控制:**
|
|
|
* 设计用于通过语音命令管理和控制智能家居设备及其他物联网硬件，并利用插件系统。
|
|
|
7. **基于Web的管理控制台 (`manager-web` & `manager-api`):**
|
|
|
* 提供全面的图形界面，用于：
|
|
|
* 系统配置（AI服务选择、API密钥、操作参数）。
|
|
|
* 基于角色的访问控制的用户管理。
|
|
|
* ESP32设备注册和管理。
|
|
|
* 语音音色/TTS语音定制。
|
|
|
* ESP32设备的OTA（空中下载）固件更新管理。
|
|
|
* 系统参数和字典的管理。
|
|
|
8. **灵活的部署选项:**
|
|
|
* 支持通过Docker容器（用于简化的仅服务器或全栈设置）和直接从源代码部署，以适应各种环境和用户专业知识。
|
|
|
9. **动态远程配置:**
|
|
|
* `xiaozhi-server`可以从`manager-api`获取其配置，允许实时更新AI提供商和设置，而无需重新启动服务器。
|
|
|
10. **开源和社区驱动:**
|
|
|
* 根据MIT许可证授权，鼓励透明、协作和社区贡献。
|
|
|
11. **经济高效的解决方案:**
|
|
|
* 提供“入门全免费设置”路径，利用AI服务的免费套餐或本地模型，使其易于进行实验和个人项目。
|
|
|
12. **渐进式Web应用 (PWA) 特性:**
|
|
|
* `manager-web`控制面板包含Service Worker集成，以增强缓存和潜在的离线访问能力。
|
|
|
13. **详细的API文档:**
|
|
|
* `manager-api`通过Knife4j提供OpenAPI (Swagger) 文档，以便清晰理解和测试其RESTful端点。
|
|
|
|
|
|
这些功能共同使`xiaozhi-esp32-server`成为一个强大、适应性强且用户友好的平台，用于构建复杂的语音交互应用程序。
|
|
|
|
|
|
---
|
|
|
|
|
|
## 6. 部署与配置概述
|
|
|
|
|
|
`xiaozhi-esp32-server`系统在设计上充分考虑了灵活性，提供了多种部署方法和全面的配置选项，以适应不同的使用场景和需求。
|
|
|
|
|
|
**部署选项:**
|
|
|
|
|
|
项目可以通过多种方式部署，主要包括使用Docker简化安装过程，或直接从源代码部署以获得更大的控制权和进行开发。
|
|
|
|
|
|
1. **基于Docker的部署:**
|
|
|
* **简化安装 (仅`xiaozhi-server`):** 此选项仅部署核心的基于Python的`xiaozhi-server`。它适用于主要需要语音AI处理能力和IoT控制，而不需要完整Web管理界面和数据库支持功能（如OTA）的用户。在此模式下，配置通常通过本地文件（`config.yaml`）管理，但如果需要，仍可将其指向一个已存在的`manager-api`实例。
|
|
|
* **全模块安装 (所有组件):** 此方案部署所有核心组件：`xiaozhi-server`、基于Java的`manager-api`、以及基于Vue.js的`manager-web`，同时还包括所需的数据库服务（MySQL和Redis）。这提供了完整的系统体验，包括用于全面配置和管理的Web控制面板。
|
|
|
* 项目为每个服务提供了`Dockerfile`定义，并使用`docker-compose.yml`文件（例如`docker-compose.yml`用于基础版，`docker-compose_all.yml`用于全功能版）来编排和管理多容器的部署。此外，还可能提供一个`docker-setup.sh`脚本来辅助自动化部分Docker环境的搭建工作。
|
|
|
|
|
|
2. **源代码部署:**
|
|
|
* 这种方法需要为每个组件手动设置相应的开发环境：Python环境用于`xiaozhi-server`，Java/Maven环境用于`manager-api`，Node.js/Vue CLI环境用于`manager-web`。
|
|
|
* 对于全模块安装，还需要手动安装和配置MySQL及Redis数据库服务。
|
|
|
* 这种方式通常用于项目开发、深度定制、调试，或者在对环境有特殊要求的生产场景中。
|
|
|
|
|
|
**配置管理:**
|
|
|
|
|
|
配置是定制系统行为的关键，尤其是在选择AI服务提供商和管理API密钥方面。
|
|
|
|
|
|
1. **`xiaozhi-server` 配置:**
|
|
|
* **本地`config.yaml`:** 位于`xiaozhi-server`根目录下的一个主要的YAML格式配置文件。它定义了服务器端口、选定的AI服务提供商（ASR、LLM、TTS、VAD、意图识别、记忆模块等）、它们各自的API密钥或模型路径、插件配置以及日志级别等。
|
|
|
* **通过`manager-api`进行远程配置:** `xiaozhi-server`被设计为可以从`manager-api`获取其运行配置。从`manager-api`获取的设置通常会覆盖本地`config.yaml`中的同名设置。这带来了两大好处：
|
|
|
* **集中管理:** 所有配置都可以通过`manager-web`界面进行统一管理。
|
|
|
* **动态更新:** `xiaozhi-server`可以刷新其配置并重新初始化AI模块，而无需完全重启服务。
|
|
|
* `xiaozhi-server`中的`config/config_loader.py`和`config/manage_api_client.py`负责处理配置的加载、合并及从`manager-api`拉取的逻辑。
|
|
|
|
|
|
2. **`manager-api` 配置:**
|
|
|
* 作为一个Spring Boot应用，其配置主要通过位于`src/main/resources`目录下的`application.properties`或`application.yml`文件进行管理。
|
|
|
* 关键配置项包括：数据库连接信息（MySQL的URL、用户名、密码）、Redis服务器地址和端口、应用服务端口（默认为8002）、Apache Shiro安全相关的设置，以及任何集成的第三方服务（如阿里云短信）的配置参数。
|
|
|
|
|
|
3. **`manager-web` 配置:**
|
|
|
* Vue.js前端应用的环境特定设置通过项目根目录下的`.env`系列文件（例如`.env`, `.env.development`, `.env.production`）进行管理。
|
|
|
* 这里最关键的配置通常是`manager-api`后端的API基础URL地址 (例如 `VUE_APP_API_BASE_URL`)，前端应用将向此地址发送所有API请求。
|
|
|
|
|
|
4. **预定义的配置方案:**
|
|
|
* 项目文档（通常是README）中会推荐一些常见的配置组合，例如：
|
|
|
* **“入门全免费设置”:** 该方案旨在利用云AI服务的免费套餐额度或完全免费的本地模型，以最大程度地降低用户的初始使用成本和运营费用。
|
|
|
* **“全流式配置”:** 该方案优先考虑系统的响应速度和交互的流畅性，通常会选用支持流式处理的（可能付费的）AI服务。
|
|
|
* 这些预定义方案为用户在`xiaozhi-server`中配置AI服务提供商（通过`manager-web`界面或直接修改`config.yaml`）提供了指导。
|
|
|
|
|
|
在全模块部署的情况下，推荐使用`manager-web`控制面板作为大多数配置任务的主要操作界面，因为它提供了一种用户友好的方式来管理由`manager-api`持久化并最终由`xiaozhi-server`使用的各项设置。
|
|
|
|
|
|
---
|
