为什么需要持久存储数据

OpenClaw 运行过程会持续产生几大类数据：

1. 记忆类数据：OpenClaw 记忆数据是其作为“永不遗忘的 AI 助手”的核心，它通过一套精巧的本地化、文件驱动的系统，实现了信息的持久化存储与智能检索。记忆数据主要包括每日记忆和长期记忆等信息。
2. 结果类数据：用户通过 OpenClaw 获取公开信息并进行本地化处理后，可以将获取到的公开信息和处理结果存储在指定路径上，实现数据的持久化存储。
3. 运行日志：系统运行过程中会持续产生日志记录服务运行状态、模型调用记录、工具执行记录、错误警告等信息，存储在系统临时文件目录下。

随着系统运行时间逐渐增加，这类数据规模会逐渐增长，此时使用轻量对象存储（Lighthouse 版）即可实现弹性、低成本地持久化存储数据的目的！

使用轻量对象存储（Lighthouse 版）存储数据

在该环节正式开始之前，请先完成了 OpenClaw 部署，可参考该文章快速搭建属于自己的OpenClaw >> OpenClaw 一键秒级部署指南。

完成搭建后，可以进入轻量服务器控制台，进入【对象存储】卡片页，点击挂载存储桶的选项：

在弹出的窗口中，选择服务器对应地域的存储桶，并设置好相应的参数；如果存储桶未创建，可以点击创建存储桶按钮新建存储桶。

• 选择同地域 Lighthouse 服务器。
• 存储桶挂载目录：输入存储桶挂载目录，注意路径需要以/开，例如 /aaa。
• 服务器挂载目录：输入服务器本地目录，该目录会作为本地挂载目录（例如/home/lighthouse/lhcos-data）。该目录下不能存在文件，也可以输入一个不存在的本地目录。
• 确认挂载授权。创建挂载点之前，必须授权当前 Lighthouse 服务器匿名访问存储桶挂载目录的权限。详情可参见 挂载授权。

• 高级参数（可选）。

  • 并发数：挂载传输的并发数，可根据服务器 CPU 核数适当调整。假如服务器 CPU 核数为N，默认推荐值为max(10，2*N)。
  • 分块大小：挂载传输中，大文件会使用分块上传，分块大小默认为10MB。由于分块上传最多支持10000块，如果需要传输超出100GB的大文件，可适当调大该参数。

单击确定，开始挂载。通过挂载状态可以查看当前挂载任务的完成情况，单击右侧的刷新图标可以刷新状态。完成挂载后会显示挂载成功的状态。

在完成挂载动作后，即可和 OpenClaw 通过对话式的方式，将数据转存至轻量对象存储 （Lighthouse 版）上。比如如下命令将记忆类文件转存到了指定目录下。

等待 OpenClawd 完成指令后，可以看到轻量对象存储中已经存储了上述文件。

下载 MEMORY.md 文件，可以查阅这位 AI 小助手今天的“工作纪要”：

将 OpenClaw 处理结果输出至轻量对象存储

除了存储记忆类数据，还可以通过命令将运行结果保存到挂载好的轻量对象存储中，以下提供一个 Arxiv 论文检索和存储到轻量对象存储的示意：

任务指令：ArXiv论文自动化抓取与摘要报告生成
角色设定  
你是一个专业的学术研究助手，专注于自动化文献检索与处理。请使用集成化的ArXiv访问工具（如ArXiv MCP Server或arxiv Python包）与LLM能力，完成以下多步骤任务。
核心任务流程  
1. 领域筛选与论文检索  
   • 针对以下四个领域，分别检索最多10篇高质量论文，优先选择顶会（如NeurIPS、ICML、OSDI）或高影响力期刊的近期成果，并聚焦热门方向：  
     ◦ 云计算（arXiv分类：cs.DC, cs.SE, cs.Distributed）  
     ◦ 存储（arXiv分类：cs.DS, cs.DB, cs.AR）  
     ◦ AI（arXiv分类：cs.AI, cs.LG, cs.CV, cs.CL）  
   • 使用ArXiv API的高级检索功能，按lastUpdatedDate降序排列，确保获取最新内容。关键词组合示例：  
     ◦ 云计算："cloud computing" OR "edge computing" OR "serverless"  
     ◦ 存储："distributed storage" OR "database optimization" OR "SSD"  
     ◦ AI："large language model" OR "reinforcement learning" OR "computer vision"  
2. 论文处理与摘要优化  
   • 下载每篇论文的PDF原文至临时目录。  
   • 提取摘要文本，调用LLM（如DeepSeek或SiliconFlow）执行以下操作：  
     ◦ 逐句翻译：将英文摘要专业地翻译为中文。  
     ◦ 摘要精简：压缩至100字以内，突出研究动机、核心方法创新、关键实验结果，避免冗余描述。  
   • 确保翻译准确且术语规范（例如，“transformer”译为“ Transformer架构”而非“变压器”）。
3. Markdown报告生成  
   • 按领域分组输出，每篇论文包含以下字段：  
     ## 领域名称（如：云计算）
     ### 论文标题  
     - **精简摘要**：（100字内中文摘要）  
     - **PDF链接**：[arXiv直接下载链接](https://arxiv.org/pdf/XXXX.XXXXX.pdf)  
   • 文件整体结构需包含标题（如“ArXiv论文日报-YYYYMMDD”）及更新时间备注。
4. 备份与归档  
   • 将最终Markdown文件保存至主机目录/lhcosbak/arxivbak，并按领域建立子目录：  
     ◦ cloud/（云计算）  
     ◦ storage/（存储）  
     ◦ ai/（AI）  
   • 文件名格式：YYYYMMDD_report.md（例如云计算领域2026年2月1日的文件为/lhcosbak/arxivbak/cloud/20260201_report.md）。若目录不存在，需自动创建。
工具与配置建议  
• 使用ArXiv MCP Server进行论文搜索与下载，或通过arxiv Python包实现。  
• 集成LLM API（如DeepSeek）时，设置系统Prompt为：  
  > “你是论文摘要专家，需将英文摘要翻译为简洁中文，保留创新点与问题解决方法，严格限100字内。”  
• 为避免重复处理，启用去重机制（如记录已处理论文ID）。
验收标准  
• 每个领域论文数≤10，且均为顶会或高引用工作。  
• 摘要翻译精准、简洁，创新点明确。  
• Markdown格式规范，链接有效。  
• 文件按日期和领域正确归档。

在输出指令后，OpenClaw 就会自己干活并将结果输出到指定路径下：

如果运行过程中有报错也没关系，可以尝试让 OpenClaw 自行分析原因并处理报错，直到问题解决。以下最终输出的报告样例：

查询更多接入教程👉云上 OpenClaw（原 Clawdbot）最全实践指南合辑

本文为墨天轮数据库管理服务团队第162期技术分享，内容原创，作者为技术顾问闫建，如需转载请联系小墨（VX：modb666）并注明来源。如需查看更多文章可关注【墨天轮】公众号。

脚本功能

此脚本是专门用于MySQL8.0逻辑备份的 MySQL Shell备份脚本，它包含了备份数据库实例的所有对象，是整个实例级别的备份，也是当下取代传统mysqldump工具的最优替代方案。

脚本内容

该脚本名称为mysqlshell\_full\_backup.sh

#!/bin/bash
########################################
# MySQL Shell 自动备份脚本 (MySQL 8.0+)
# 功能: 全量逻辑备份 + 错误处理 + 日志记录 + 自动清理 + 时间统计
# 备份文件名格式: full_mysqlshell_backup_时间
# 使用方式: 直接修改脚本中的变量值，然后执行 ./mysqlshell_full_backup.sh
########################################
################### 配置参数 ###################
# MySQL Shell命令绝对路径（重要：请根据实际安装路径修改）
MYSQLSH_CMD="/data/soft/mysqlshell8044/bin/mysqlsh"
# 备份保留天数（默认15天）
RETAIN_DAYS=${RETAIN_DAYS:-15}
# 并行度（默认4线程）
PARALLEL=${PARALLEL:-4}
# 排除的数据库（逗号分隔，默认空）
EXCLUDE_SCHEMAS=${EXCLUDE_SCHEMAS:-""}
# 备份存储根目录
BACKUP_ROOT="/data/backup"
# 时间戳格式：YYYYMMDD_HHMMSS
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
# 备份目录名称（按您要求的格式）
BACKUP_DIR_NAME="full_mysqlshell_backup_${TIMESTAMP}"
BACKUP_DIR="${BACKUP_ROOT}/${BACKUP_DIR_NAME}"
# MySQL连接参数（请根据实际情况修改）
MYSQL_USER="root"
MYSQL_PASSWORD="mysql"
MYSQL_HOST="localhost"
MYSQL_PORT="3306"
# 日志文件路径
LOG_FILE="${BACKUP_ROOT}/backup.log"
############################################
########## 函数：记录日志 ##########
log() {
    local level="$1"
    local message="$2"
    local timestamp=$(date '+%Y-%m-%d %H:%M:%S')
    local log_entry="[${timestamp}] [${level}] ${message}"
    # 输出到标准输出并写入日志文件
    echo "${log_entry}" | tee -a "${LOG_FILE}"
}
########## 函数：错误处理并退出 ##########
error_exit() {
    log "ERROR" "$1"
    end_time=$(date +%s)
    total_runtime=$((end_time - start_time_global))
    log "INFO" "脚本异常退出，总运行时间: $(format_duration $total_runtime)"
    exit 1
}
########## 函数：计算和格式化运行时间 ##########
format_duration() {
    local seconds=$1
    local hours=$((seconds / 3600))
    local minutes=$(( (seconds % 3600) / 60 ))
    local secs=$((seconds % 60))
    if [ $hours -gt 0 ]; then
        echo "${hours}小时${minutes}分${secs}秒"
    elif [ $minutes -gt 0 ]; then
        echo "${minutes}分${secs}秒"
    else
        echo "${secs}秒"
    fi
}
########## 函数：检查依赖工具 ##########
check_dependencies() {
    # 检查MySQL Shell是否存在且可执行
    if [ ! -x "$MYSQLSH_CMD" ]; then
        error_exit "MySQL Shell未在指定路径找到或不可执行: $MYSQLSH_CMD"
    fi
    # 检查其他依赖工具
    local deps=("du")
    for dep in "${deps[@]}"; do
        if ! command -v "$dep" &> /dev/null; then
            error_exit "所需工具 $dep 未安装或未在PATH中"
        fi
    done
    log "INFO" "依赖检查通过，MySQL Shell路径: $MYSQLSH_CMD"
}
########## 函数：检查MySQL连接 ##########
check_mysql_connection() {
    log "INFO" "检查MySQL数据库连接..."
    if "$MYSQLSH_CMD" --log-level=2 --uri="${MYSQL_USER}:${MYSQL_PASSWORD}@${MYSQL_HOST}:${MYSQL_PORT}" --sql --execute "select 1" >/dev/null 2>&1; then
        log "INFO" "MySQL数据库连接成功"
    else
        error_exit "MySQL数据库连接失败，请检查连接参数"
    fi
}
########## 函数：检查磁盘空间 ##########
check_disk_space() {
    local available_space=$(df "$BACKUP_ROOT" | awk 'NR==2 {print $4}')
    local min_space=$((1024 * 1024))  # 至少保留1GB空间
    if [ "$available_space" -lt "$min_space" ]; then
        error_exit "磁盘空间不足，剩余空间: ${available_space}KB，至少需要: ${min_space}KB"
    fi
    log "INFO" "磁盘空间检查通过，剩余空间: ${available_space}KB"
}
########## 主函数：执行备份 ##########
perform_backup() {
    log "INFO" "开始执行数据库备份..."
    # 构建excludeSchemas参数
    local exclude_param=""
    if [ -n "$EXCLUDE_SCHEMAS" ]; then
        local exclude_jsons=()
        IFS=',' read -ra DB_ARRAY <<< "$EXCLUDE_SCHEMAS"
        for db in "${DB_ARRAY[@]}"; do
            db_clean=$(echo "$db" | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//' -e "s/'/\\\\'/g")
            if [ -n "$db_clean" ]; then
                exclude_jsons+=("'$db_clean'")
            fi
        done
        if [ ${
#exclude
_jsons[@]} -gt 0 ]; then
            exclude_param="excludeSchemas: [$(IFS=,; echo "${exclude_jsons[*]}")],"
            log "INFO" "排除数据库: ${EXCLUDE_SCHEMAS}"
        fi
    fi
    # 构建备份命令
    local backup_cmd="util.dumpInstance('$BACKUP_DIR', { 
        threads: $PARALLEL, 
        ${exclude_param}
        consistent: true,
        compression: 'zstd',
        ocimds: true,
        compatibility: ['strip_restricted_grants','strip_definers','strip_tablespaces','ignore_missing_pks']
    })"
    log "INFO" "执行MySQL Shell备份命令，并行度: $PARALLEL"
    # 执行备份（使用变量化的MYSQLSH_CMD）
    if "$MYSQLSH_CMD" --log-level=3 --uri="${MYSQL_USER}:${MYSQL_PASSWORD}@${MYSQL_HOST}:${MYSQL_PORT}" \
        --execute "$backup_cmd" >> "$LOG_FILE" 2>&1; then
        log "INFO" "MySQL Shell备份命令执行完成"
        return 0
    else
        return 1
    fi
}
########## 主函数：清理过期备份 ##########
cleanup_old_backups() {
    log "INFO" "开始清理超过 ${RETAIN_DAYS} 天的旧备份..."
    local deleted_count=0
    while IFS= read -r -d '' old_backup; do
        if [ -n "$old_backup" ] && [ "$old_backup" != "$BACKUP_ROOT" ]; then
            log "INFO" "删除过期备份: $(basename "$old_backup")"
            rm -rf "$old_backup"
            ((deleted_count++))
        fi
    done < <(find "$BACKUP_ROOT" -maxdepth 1 -type d -name "full_mysqlshell_backup_*" -mtime "+$((RETAIN_DAYS-1))" -print0 2>/dev/null)
    log "INFO" "清理完成，共删除 $deleted_count 个过期备份"
}
########## 主执行流程 ##########
main() {
    local start_time_global=$(date +%s)
    log "INFO" "=== MySQL备份作业开始 ==="
    log "INFO" "备份目录: $BACKUP_DIR"
    log "INFO" "保留天数: $RETAIN_DAYS天, 并行度: $PARALLEL"
    log "INFO" "排除数据库: ${EXCLUDE_SCHEMAS:-无}"
    log "INFO" "MySQL Shell路径: $MYSQLSH_CMD"
    # 初始化检查
    check_dependencies
    check_disk_space
    check_mysql_connection
    # 创建备份目录
    if ! mkdir -p "$BACKUP_DIR"; then
        error_exit "无法创建备份目录: $BACKUP_DIR"
    fi
    log "INFO" "备份目录创建成功: $BACKUP_DIR"
    # 执行备份
    local backup_start=$(date +%s)
    if perform_backup; then
        local backup_end=$(date +%s)
        local backup_runtime=$((backup_end - backup_start))
        log "INFO" "数据库备份成功完成"
        log "INFO" "备份耗时: $(format_duration $backup_runtime)"
    else
        error_exit "数据库备份执行失败，详情请查看日志: $LOG_FILE"
    fi
    # 清理过期备份
    local cleanup_start=$(date +%s)
    cleanup_old_backups
    local cleanup_end=$(date +%s)
    local cleanup_runtime=$((cleanup_end - cleanup_start))
    # 最终统计
    local end_time_global=$(date +%s)
    local total_runtime=$((end_time_global - start_time_global))
    log "INFO" "=== 备份作业统计 ==="
    log "INFO" "备份文件位置: $BACKUP_DIR"
    log "INFO" "备份大小: $(du -sh "$BACKUP_DIR" 2>/dev/null | cut -f1 || echo "未知")"
    log "INFO" "各阶段耗时详情:"
    log "INFO" "  - 备份阶段: $(format_duration $backup_runtime)"
    log "INFO" "  - 清理阶段: $(format_duration $cleanup_runtime)"
    log "INFO" "  - 总计耗时: $(format_duration $total_runtime)"
    log "INFO" "日志文件: $LOG_FILE"
    log "INFO" "=== MySQL备份作业完成 ==="
}
########## 脚本执行入口 - 直接执行主函数 ##########
main

重点说明

1、关于备份时的参数说明

# 构建备份命令
local backup_cmd="util.dumpInstance('$BACKUP_DIR', { 
    threads: $PARALLEL, 
    ${exclude_param}
    consistent: true,
    compression: 'zstd',
    ocimds: true,
    compatibility: ['strip_restricted_grants','strip_definers','strip_tablespaces','ignore_missing_pks']
})"

上面构建备份语句中，有一个兼容性参数设置compatibility，该参数需要额外说明：

• strip\_restricted\_grants 移除备份文件中，目标数据库服务不允许授予的高级权限，避免因权限问题导致导入失败
• strip\_definers 从视图、存储过程等对象定义中移除 DEFINER=子句，避免因原始定义者不存在而导致的权限错误
• strip\_tablespaces 从建表语句中移除 TABLESPACE=子句，此选项可防止因指定不存在的表空间而导致建表失败
• ignore\_missing\_pks 忽略（跳过检查）没有主键的表，而不为它们自动创建主键，用于容忍没有主键的表，但不会自动修复。如需自动添加主键，应使用 create\_invisible\_pks选项
   

2、关于备份软件的说明

MySQL数据库软件并不自带MySQLShell功能，MySQL Shell软件需要提前下载准备好，下载链接如下：

https://dev.mysql.com/downloads/shell/

MySQLShell软件下载到本地服务器后，解压即可使用非常简单方便。

使用方法

如采用压缩备份，此步骤为必须执行步骤，非压缩备份，此步

1、保存脚本并赋予执行权限

[root@VM-8-4-opencloudos backup]# chmod +x mysqlshell_full_backup.sh

2、可选手动执行备份

[root@VM-8-4-opencloudos backup]# ./mysqlshell_full_backup.sh

tail -100 /data/backup/backup.log

3. 可配置定时任务（每日凌晨1点执行）

# 编辑crontab：crontab -e 添加如下内容并保存
01 * * * /path/to/mysqlshell_full_backup.sh

恢 复

作为DBA，恢复工作需要严谨的操作流程。以下是基于该备份的详细恢复步骤和指南。

1、确认备份文件的完整性

在开始恢复前，务必检查备份目录是否完整。一个成功的 util.dumpInstance备份通常会包含一个 @.done.json文件以及每个数据库对应的 .tsv.zst数据文件和 .sql元数据文件。您可以使用以下命令快速查看备份根目录下的内容：

[root@VM-8-4-opencloudos backup]# ls -l full_mysqlshell_backup_20251113_111713
total 23624
-rw-r----- 1 root root      549 Nov 13 11:17 @.done.json
-rw-r----- 1 root root     1400 Nov 13 11:17 @.json
-rw-r----- 1 root root      240 Nov 13 11:17 @.post.sql
-rw-r----- 1 root root      240 Nov 13 11:17 @.sql
-rw-r----- 1 root root        9 Nov 13 11:17 testdb@a@@0.tsv.zst
-rw-r----- 1 root root        8 Nov 13 11:17 testdb@a@@0.tsv.zst.idx
-rw-r----- 1 root root      612 Nov 13 11:17 testdb@a.json
-rw-r----- 1 root root      750 Nov 13 11:17 testdb@a.sql
-rw-r----- 1 root root        9 Nov 13 11:17 testdb@b@@0.tsv.zst
-rw-r----- 1 root root        8 Nov 13 11:17 testdb@b@@0.tsv.zst.idx
-rw-r----- 1 root root      562 Nov 13 11:17 testdb@b.json
-rw-r----- 1 root root      644 Nov 13 11:17 testdb@b.sql
-rw-r----- 1 root root      585 Nov 13 11:17 testdb.json
-rw-r----- 1 root root 23971894 Nov 13 11:17 testdb@large_table@@0.tsv.zst
-rw-r----- 1 root root      544 Nov 13 11:17 testdb@large_table@@0.tsv.zst.idx
-rw-r----- 1 root root     1036 Nov 13 11:17 testdb@large_table.json
-rw-r----- 1 root root     1418 Nov 13 11:17 testdb@large_table.sql
-rw-r----- 1 root root    92884 Nov 13 11:17 testdb@my_table@@0.tsv.zst
-rw-r----- 1 root root        8 Nov 13 11:17 testdb@my_table@@0.tsv.zst.idx
-rw-r----- 1 root root      890 Nov 13 11:17 testdb@my_table.json
-rw-r----- 1 root root     1349 Nov 13 11:17 testdb@my_table.sql
-rw-r----- 1 root root     4038 Nov 13 11:17 testdb.sql
-rw-r----- 1 root root       14 Nov 13 11:17 testdb@tt@@0.tsv.zst
-rw-r----- 1 root root        8 Nov 13 11:17 testdb@tt@@0.tsv.zst.idx
-rw-r----- 1 root root      583 Nov 13 11:17 testdb@tt.json
-rw-r----- 1 root root       19 Nov 13 11:17 testdb@tt_new@@0.tsv.zst
-rw-r----- 1 root root        8 Nov 13 11:17 testdb@tt_new@@0.tsv.zst.idx
-rw-r----- 1 root root      587 Nov 13 11:17 testdb@tt_new.json
-rw-r----- 1 root root      686 Nov 13 11:17 testdb@tt_new.sql
-rw-r----- 1 root root      674 Nov 13 11:17 testdb@tt.sql
-rw-r----- 1 root root     4344 Nov 13 11:17 @.users.sql

2、准备恢复环境

• 目标MySQL实例：确保用于恢复的MySQL服务已启动并可以正常连接。它最好与源服务器版本一致或兼容，以避免潜在问题。
• 权限检查：用于执行恢复操作的MySQL账户需要具备足够的权限，例如 SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, 甚至可能需要 RELOAD或 SUPER权限。
• 磁盘空间：确保目标实例的磁盘有足够空间容纳要恢复的数据。
• 决策：完全恢复还是部分恢复？ 想清楚是需要恢复整个实例，还是只恢复其中的一个或多个特定数据库。这决定了后续使用的工具和命令。

## 说明：在导入数据之前，建议检查参数local_infile是否开启，如未开启，需要进行提前设置。
root@localhost:(none) 02:01:54 > show global variables like '%local_infile%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| local_infile  | OFF   |
+---------------+-------+
1 row in set (0.11 sec)
root@localhost:(none) 02:01:46 >set global local_infile=1;
Query OK, 0 rows affected (0.00 sec)

3、恢复操作步骤

MySQL Shell工具软件进行备份，恢复时候也必须使用MySQL Shell进行恢复，这个是必须满足的基本条件。

• 恢复方式一：

在服务器上执行以下命令。请务必将 备份目录路径、用户名、密码、主机和 端口替换为您的实际信息。

mysqlsh -u root -p --host localhost --port 3306 --js
--进入 MySQL Shell 的 JavaScript 模式后，执行：
util.loadDump("/data/backup/full_mysqlshell_backup_20251113_103022", {
    threads: 4,        // 并行线程数，可调整
    skipBinlog: false, // 如果恢复过程不想记录到二进制日志，可设为true
    ignoreVersion: true, // 忽略MySQL版本差异警告（谨慎使用）
    resetProgress: true  // 如果重新开始一个恢复，重置进度
});

• 恢复方式二：

mysqlsh -u root -p -h localhost -P 3306 --js -e "util.loadDump('/data/backup/full_mysqlshell_backup_20251113_103022', {threads: 4, skipBinlog: false})"

4、监控恢复过程

恢复过程中，util.loadDump会显示进度信息。您也可以在另一个会话中连接到MySQL，使用 sql模式查看正在创建的表或进程。

总 结

该脚本提供了一个生产环境使用MySQL Shell 工具对 MySQL8.0版本进行逻辑备所需的完整步骤，包括错误处理、日志记录、自动清理和耗时统计以及最后的恢复步骤。数据库运维人员可以根据实际环境调整配置参数，特别是备份路径和保留天数设置等一些常用功能的设置。

墨天轮从乐知乐享的数据库技术社区蓄势出发，全面升级，提供多类型数据库管理服务。墨天轮数据库管理服务旨在为用户构建信赖可托付的数据库环境，并为数据库厂商提供中立的生态支持。
墨天轮数据库服务官网：https://www.modb.pro/service

Next AI Draw.io：AI 驱动的智能图表绘制工具

项目简介

在当今 AI 技术飞速发展的背景下，Next AI Draw.io 是一个基于 Next.js 的 AI 驱动图表创建工具。

想象一下，你只需说“给我画一个云原生微服务架构图”，AI 就能在 draw.io 画布上为你生成专业的架构图表——这正是 Next AI Draw.io 带来的体验。

相关地址：

• GitHub 地址：https://github.com/DayuanJiang/next-ai-draw-io

• 演示地址：https://next-ai-drawio.jiang.jp/

  

🚀 快速部署指南

在线体验

无需安装，可直接访问 演示网站。您可以在聊天面板的设置中配置自己的 API 密钥以绕过使用限制，密钥仅存储在浏览器本地。

桌面应用

可从 GitHub Releases 页面下载 Windows、macOS 或 Linux 的本地桌面应用。

Docker 一键部署（推荐）

对于想要快速体验的用户，Docker 是最佳选择：

# 使用 OpenAI GPT-4o 模型
docker run -d -p 3000:3000 \
  -e AI_PROVIDER=openai \
  -e AI_MODEL=gpt-4o \
  -e OPENAI_API_KEY=your_openai_key \
  -e OPENAI_BASE_URL=your_proxy_url \
  ghcr.io/dayuanjiang/next-ai-draw-io:latest

使用 Docker Compose 部署

services:
  next-ai-draw-io:
    image: ghcr.io/dayuanjiang/next-ai-draw-io:latest
    container_name: next-ai-draw-io
    restart: unless-stopped
    ports:
      - "3100:3000"
    environment:
      - AI_PROVIDER=openai
      - AI_MODEL=kimi-k2-turbo-preview   # 模型名称
      - OPENAI_BASE_URL=https://api.moonshot.cn/v1 # 模型地址（如使用 Kimi）
      - OPENAI_API_KEY=_API_KEY # api key

启动命令：

docker-compose up -d

访问 http://<服务器IP>:<端口> 即可使用。

源码安装部署

1. 克隆仓库并安装依赖：

   git clone https://github.com/DayuanJiang/next-ai-draw-io
   cd next-ai-draw-io
   npm install
   cp env.example .env.local

2. 配置环境变量（参考下文 支持的 AI 服务商）。

3. 运行开发服务器：

   npm run dev

4. 在浏览器中打开 http://localhost:6002。

🎨 使用示例

创建系统流程图

• 提示词示例：设计一个用户登录系统的流程图，包含验证、session管理和错误处理
  

绘制网络拓扑

• 提示词示例：绘制一个企业级网络拓扑图，包含防火墙、交换机、路由器和服务器集群
  

复制和优化现有图表
上传现有的架构图或设计草图，AI 会自动：

• 识别图中的元素和结构。
• 生成规范的 draw.io 图表。
• 根据需求进行优化和增强。

🔌 支持的 AI 服务商

Next AI Draw.io 支持几乎所有的主流 AI 服务，让你的选择更加灵活：

通用配置：
如果你使用的模型兼容 OpenAI API 格式但不在上述列表中，可以使用以下通用配置：

AI_PROVIDER=openai
AI_MODEL=你的模型名称
OPENAI_BASE_URL=你的模型 API 地址
OPENAI_API_KEY=你的 api key

💡 使用技巧

1. 提供明确的需求
   越详细的描述，AI 生成的图表越精准。包括：

   • 图表类型（架构图、流程图、时序图等）。
   • 使用的图标库（AWS、Azure、GCP 或通用）。
   • 具体的组件和连接关系。

2. 利用版本历史
   每次 AI 修改都会创建新的版本，你可以：

   • 查看每次修改的具体内容。
   • 比较不同版本间的差异。
   • 随时回退到之前的版本。

3. 渐进式优化
   先让 AI 生成基础框架，然后通过对话逐步优化，例如：

   • "添加监控告警组件"
   • "将所有存储改为SSD"
   • "增加灾备恢复流程"

🛠️ 开发者进阶

项目架构

app/
├── api/chat/          # AI聊天API端点
├── page.tsx           # 主页面
components/
├── chat-panel.tsx     # 聊天界面
├── history-dialog.tsx # 历史记录查看器
lib/
├── ai-providers.ts    # AI服务商配置
└── utils.ts           # 工具函数

添加自定义功能

如果你想扩展功能，可以：

• 在 lib/ai-providers.ts 中添加新的 AI 服务商。
• 修改 components/chat-panel.tsx 增强用户界面。
• 扩展 app/api/chat/route.ts 中的 AI 工具集。

Author:Smoothcloud润云

算力 #ai #云平台 #算力租赁 #开发 #人工智能

开发者朋友们大家好：

这里是 「RTE 开发者日报」 ，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement） 领域内「有话题的技术」、「有亮点的产品」、「有思考的文章」、「有态度的观点」、「有看点的活动」，但内容仅代表编辑的个人观点，欢迎大家留言、跟帖、讨论。

本期编辑：@瓒an、@鲍勃

01 有话题的技术

1、Apple 以 20 亿美元收购 Q.ai：通过面部微表情识别「无声对话」指令

在 AI 上日渐落后的苹果，最近几个月加紧了前进步伐。抛弃 OpenAI，携手 Google Gemini 后，苹果近日又有新动作。

当地时间 1 月 29 日，苹果公司完成了一项近 20 亿美元的收购，目标是以色列 AI 初创公司 Q.ai。

这是苹果自 2014 年以 30 亿美元收购 Beats 以来，规模第二大的交易。

据《金融时报》等多家媒体报道，Q.ai 的核心技术在于分析面部微表情和肌肉运动，从而解读「无声对话」（Silent Speech），即用户无需发出声音，仅通过嘴部动作即可被设备识别意图。

这项技术被认为有望集成到未来的 AirPods、iPhone 乃至传闻中的 AI 眼镜中，实现更私密、无障碍的人机交互。

Q.ai 的创始团队背景显赫，联合创始人 Aviad Maizels 此前创立的 PrimeSense 公司在 2013 年被苹果收购，其技术后来成为 iPhone Face ID 的原型。

此次收购在苹果发布强劲财报的同一天公布，凸显了公司在 AI 硬件竞赛中补短板的急迫性。

（@极客公园）

2、商汤开源 SenseNova-MARS：8B/32B 双版本 Agentic VLM，多模态搜索得分 69.74 超越 GPT-5.2

1 月 29 日，商汤正式开源多模态自主推理模型 SenseNova-MARS（8B/32B 双版本），其在多模态搜索与推理的核心基准测试中以 69.74 分超越 Gemini-3-Pro（69.06 分）、GPT-5.2（67.64 分）。

SenseNova-MARS 是首个支持动态视觉推理和图文搜索深度融合的 Agentic VLM 模型，它能自己规划步骤、调用工具，轻松搞定各种复杂任务，让 AI 真正具备「执行能力」。

在 MMSearch、HR-MMSearch、FVQA、InfoSeek、SimpleVQA、LiveVQA 等基准测试中，SenseNova-MARS 取得开源模型中的 SOTA 成绩，还超越 Gemini-3.0-Pro、GPT-5.2 等顶级闭源模型，在搜索推理和视觉理解两大核心领域全面领跑。

在具体的评测数据方面，SenseNova-MARS 在图文搜索核心评测 MMSearch 榜单中以 74.27 分登顶，优于 GPT-5.2 的 66.08 分；在高清细节搜索评测 HR-MMSearch 中以 54.43 分领先。

简单说，无论是需要「查遍全网」的知识密集型任务，还是需要「火眼金睛」的细粒度视觉分析，它都是当前的「全能冠军」。

SenseNova-MARS 拥有「自主思考+多工具协作」的能力，能够自动解决「细节识别 + 信息检索 + 逻辑推理」复杂任务，帮助实现工作效率提升。

• 图像裁剪：能精准聚焦图片上的微小细节，哪怕是占比不到 5%的细节——比如赛车手衣服上的微小 logo、赛事照片里观众席的标语，都可通过裁剪放大清晰分析。
• 图像搜索 ：能在看到物体、人物或场景，的瞬间自动匹配相关信息——比如识别出赛车手的身份，或是某款冷门设备的型号。
• 文本搜索：能快速抓取精准信息——无论是公司成立年份、人物出生年月，还是最新的行业数据，都能秒级获取。

技术上，SenseNova-MARS 采用分阶段训练：第一阶段利用多模智能体数据合成引擎，结合细粒度视觉锚点与多跳检索构建高逻辑链条数据，并通过自洽性校验去除幻觉；第二阶段引入强化学习与 BN-GSPO 算法，采用双阶段归一化的优雅机制有效平滑了动态工具调用返回分布多样性带来的优化波动并确保了学习信号分布的一致性，从而成功解决了跨模态多步多工具智能体训练过程中的收敛性难题。，培养出稳定的「工具使用直觉」。

目前，商汤日日新 SenseNova-MARS 的模型、代码及数据集已全部开源。

技术报告：

https\://arxiv.org/abs/2512.24330

Github:

https\://github.com/OpenSenseNova/SenseNova-MARS

（@商汤科技 SenseTime）

3、阶跃星辰发布 Step 3.5 Flash：为 Agent 而生的开源「轻骑兵」

阶跃星辰（StepFun）于 2026 年 2 月 2 日正式上线并开源了其最新基座模型 Step 3.5 Flash。该模型定位为具备强大推理能力与 Agent 智能的「Agent 大脑」，强调在性能与模型尺寸之间取得平衡。

据官方介绍，Step 3.5 Flash 的核心特点在于「更快、更强、更稳」。在单请求代码类任务中，其推理速度最高可达 350 TPS；在 Agent 场景和数学任务上，其表现可媲美闭源模型；同时具备处理复杂、长链条任务的能力。相关数据显示，该模型在开启 Parallel Thinking（并行思考）后性能有进一步增强。

为了实现高响应速度与可控成本，Step 3.5 Flash 采用了以下技术架构：

• 稀疏 MoE 架构：拥有 1960 亿总参数，但每个 token 仅激活约 110 亿参数。
• MTP-3 技术：支持模型一次预测 3 个 Token，使效率翻倍。
• 混合注意力机制：采用 3:1 滑动窗口与全局注意力（SWA + Full Attention）混合架构，在长文本中聚焦重点以显著降低计算开销，支持高效处理 256K 上下文。

在实际应用案例中，Step 3.5 Flash 展示了多维度的能力：

在计算场景下，它能快速处理复杂的等差数列及高阶数学运算。

在智能体编程方面，模型基于文字提示自动构建了一个气象情报仪表盘，该可视化平台搭载定制 WebGL 2.0 引擎，可实时处理超过 15,000 个动态节点及 WebSocket 遥测数据流。

此外，在端云结合的演示中，该模型作为「云端大脑」将 Mac Mini M4 的全网比价需求拆解为针对淘宝、京东和拼多多的具体子任务，指导本地 Step-GUI 执行数据抓取并汇总出最低价平台，体现了云端协同对本地执行难度的降低。

此外，阶跃星辰透露已启动 Step 4 模型的训练，并邀请社区共同参与下一代 Agent 基础模型的定义。

官方网页：

https\://www.stepfun.com/

GitHub:

https\://github.com/stepfun-ai/Step-3.5-Flash/tree/main

HuggingFace:

https\://huggingface.co/stepfun-ai/Step-3.5-Flash

（@阶跃星辰）

02 有亮点的产品

1、韩国客服 AI Agent 构建与运营商 TeamKai 获种子轮融资：AI 智能体实现 60% 无人干预任务处理与趋零幻觉率

据 2026 年 2 月 1 日消息，客户服务 AI Agent 构建与运营商 TeamKai 宣布获得来自 Sparklabs 和 Murex Partners 的种子轮融资。 公司方面未披露具体的融资金额。

这家初创公司成立于 2024 年，由 Doa Kim 创立。Doa Kim 曾在韩国头部旅游平台 Myrealtrip 担任首席运营官，拥有十年客户服务运营经验，期间处理过包括机票预订、酒店预订及旅游套餐在内的各类复杂业务支持场景。

TeamKai 的差异化优势在于其采取的综合性服务模式。 该公司不仅提供 AI Agent，还负责从实施咨询到直接对接客户内部系统，乃至提供全套客户服务外包等环节。其 AI Agent 能够承担人类客服代表所处理的全方位任务。

在过去一年中，TeamKai 拓展了旅游、电子商务和消费品领域的客户，年度经常性收入（ARR）已接近 6.8 万美元（约 1 亿韩元）。投资方 Sparklabs 对 TeamKai 的技术能力表示认可，数据显示其 AI Agent 可在无人干预的情况下完成超过 60% 的任务，且幻觉率正趋近于零。投资方认为这些指标赋予了 TeamKai 在全球范围内竞争的潜力。在 Sparklabs 投资后，TeamKai 还成功入选了韩国中小企业和初创企业部的技术孵化项目 TIPS。

TeamKai 计划利用这笔资金进一步推动技术发展，提升 AI Agent 处理查询的成功率，并吸纳更多客户。Sparklabs 首席执行官 Yujin Kim 评价称，TeamKai 洞察了客户服务中的实际痛点并正在系统性地修复这些问题，有望将 AI 联络中心从成本消耗中心转变为提升客户体验和效率的引擎。TeamKai 首席执行官 Doa Kim 表示，AI 正在彻底改变客户服务外包的经济模式，她专注于创造让 AI 真正主导运营的环境，并对结果负责。

( @WOWTALE)

2、消息称乐奇 Rokid 将推新一代 AI「智能体」眼镜，联合国内头部大模型公司打造

今天上午，《科创板日报》援引接近乐奇 Rokid 的行业资深人士信息称，Rokid 正与「国内头部大模型公司」合作，研发专属端侧多模态模型，下一代 AI 眼镜产品聚焦生成式 AI 以及 AI Agent 为驱动的全新操作系统和 UI。目前 Rokid 眼镜日销量大约为 1200 副，线上和线下各占半。

今年早些时候，乐奇 Rokid 携史上最大面积 AI 眼镜展台登陆 CES 2026 主会场中心，带来核心产品乐奇 AI 眼镜（Rokid Glasses）。

此外，Rokid 还推出了行业首个智能体商店。用户无需繁琐操作，仅凭语音指令就能唤起覆盖各行各业的 AI 专家：既能解决高铁车次查询、食物热量计算等日常刚需，也能体验班味检测、高情商聊天等趣味功能。

据 IT 之家此前报道，乐奇 AI 眼镜深度整合了包括 DeepSeek、通义千问、豆包、智谱在内的多款 AI 大模型，并与高德地图、支付宝、京东科技等国内伙伴达成生态合作。在海外市场，Rokid Glasses 已与谷歌地图、微软翻译等国际巨头建立合作。

（@IT 之家）

3、两个 95 后华人打造「硬件版 OpenClaw」：售价 1700 元，支持硬件 Vibe Coding

硅谷初创项目 Pamir 近期推出了一款名为 Distiller Alpha 的硬件设备，被市场称为「硬件版 OpenClaw」。该设备售价 250 美元（约合人民币 1700 元），是一款软硬件一体化的本地 Agent 产品。

Distiller Alpha 本质上是一台微型 Linux 电脑，其核心计算模块基于树莓派 CM5，配置为 8GB 内存和 64GB 存储。在硬件形态上，该设备集成了墨水屏、麦克风、扬声器、摄像头及 LED 灯带，整体尺寸小于手机。系统预装了 Agent 环境，支持开机即用，用户通过扫描墨水屏上的二维码即可进入交互界面。

该产品的一个核心应用场景是「Vibe coding」，即支持开发者通过手机远程编写代码。 与纯软件方案不同，Distiller Alpha 能够直接连接并控制物理硬件。用户可以将设备连接至开发板、蓝牙设备或打印机，通过自然语言指令让 Agent 自动编写驱动代码、进行逆向工程或统一管理智能家居设备，实现了从代码生成到硬件烧录的闭环。

Pamir 联合创始人叶天奇在采访中指出，虽然 Mac mini 等通用电脑性能强大，但并非为 Agent 原生设计，缺乏底层的执行与回滚机制。相比之下，Distiller Alpha 定位为「原生 Agent 硬件」，在系统层面进行了针对性设计：

• 交互逻辑：去除了传统的桌面与屏幕系统，通过内网直连或硬件指示灯（如 LED 状态）进行交互，更适合 Agent 的全天候后台运行。
• 自修复机制：内置 Watchdog（看门狗）系统，当 Agent 修改代码导致系统崩溃时，设备可自动检测并完成系统回滚与修复。
• 安全性：硬件层面植入加密芯片存储 Agent ID，配合物理隔绝属性，形成物理沙盒以保护敏感数据。

在实际应用中，该设备被不同类型的用户定义了多层级的使用方式：

• 智能存储：作为具备理解能力的移动硬盘，帮助律师等知识工作者处理大量文档或直接修改 U 盘文件。
• 自动化代理：代替用户执行网页浏览、餐厅预订等操作，模拟真实人类行为以规避反爬虫检测。
• 知识资产托管：程序员或安全专家将个人的经验整理为 SOP，让 Agent 24 小时运行进行漏洞挖掘或辅助工作。

Pamir 的创始团队由两位 95 后华人叶天奇和张城铭组成。项目早期曾尝试 To B 的端侧 AI 业务，后转型 To C 市场。团队认为，未来 Agent 将需要独立的计算设备而非寄生于现有电脑屏幕。叶天奇表示，相比于单纯的软件竞争，系统层与硬件层的深度集成（涵盖供应链、能耗控制及安全机制）将构建起更稳固的护城河，其长期目标是探索一种不再以屏幕为核心的个人计算新形态。

（@量子位）

4、AI 玩具品牌 FoloToy 连获数千万元融资：深创投参投，2025 年国内销量增长 5 倍

FoloToy 近日宣布连续完成数千万元 Pre-A 轮及 Pre-A+ 轮融资。本轮投资方为深创投和南山战新投，老股东火火兔持续跟投，指数资本担任独家财务顾问。据悉，融资资金将主要用于扩大品牌影响力及渠道建设。

FoloToy 成立于 2023 年，核心团队由「极客奶爸」王乐和郭兴华组成。公司致力于为儿童提供「高质量、会聊天、有深度」的 AI 陪伴玩具，其出发点在于将旧玩具转化为具备对话能力的伙伴。

目前，FoloToy 采取 C 端与 B 端并行的策略，推出了经典陪伴、成长伴学、创新文旅及企业定制等产品线，并与各大 IP 方建立了深度研发合作。指数资本分析认为，FoloToy 在 IP 合作上具备独特的差异化思路：

• 技术赋能 IP：利用 AI 机芯 Magicbox（魔匣）让 IP 角色「活过来」。不同于简单的形象授权，FoloToy 能够让角色配合故事更新，支持分龄互动、千人千面及多玩具互联，使传统静态 IP 转化为鲜活的对话角色。
• 设计师挖掘：提前挖掘并培育有潜力的设计师与艺术家。
• 公共 IP 绑定：抢占如「AI 泰迪熊」等公共 IP 的心智，使其与品牌形成强关联。

在市场表现方面，FoloToy 透露其 2025 年国内销量较 2024 年增长五倍。 在海外市场，产品已进入美国、瑞典、德国、日本等地，并正在布局北美及欧洲市场。

当前 AI 玩具赛道正处于快速增长期。 据 Facts & Factors 预测，到 2032 年玩具市场规模将达到 500 亿美元，且大模型技术的发展可能加速这一进程。指数资本指出，在 3-9 岁儿童 AI 陪伴玩具领域，存在需求验证与供给空白的交叉机会。尽管需求侧对安全、可控且具备情绪价值的产品需求明确，但供给侧缺乏集 AI 技术、IP 运营、玩具制造与教育内容于一体的「四合一」产品。目前该赛道尚未出现市占率超过 5% 的品牌。

针对这一市场现状，FoloToy 已形成清晰的商业化路径：

• C 端消费市场：推出 AI 仙人掌、AI 向日葵、AI 小熊等伴学哄娃产品，内置自研儿童对话模型，支持中英双语及实时内容过滤。
• B 端企业定制：与大型企业联名合作，如联合招商银行推出培养财商的「金小葵」，联合飞鹤奶粉推出主打早教的「鹤小小」。
• 行业场景创新：提供行业解决方案，例如为博物馆开发的互动剧本「AI 猫馆长」，以及为教育机构提供的「八爪鱼」AI 学习套件。

行业观察认为，目前的 AI 玩具市场仍处于早期「IP+AI」同质化发展阶段，未来将进入产品验证期，安全性、可玩性与实用性将成为竞争核心。

（@多知）

03 有态度的观点

1、扎克伯格：AI 是社媒的未来

据 The Verge 消息，Meta CEO 扎克伯格日前在财报电话会上表示，人工智能（AI）将会是社交媒体的未来。

扎克伯格指出，AI 将会使得社交媒体的内容更加沉浸。「社媒的最初形态是文字，然后在手机具备摄像功能后转向照片，接着再移动数据网络足够快时进入视频时代。很快，我们将看到全新的媒体形态爆发。」

其还补充表示，目前的社媒大多使用推荐内容的算法，但这种情况将发生改变，未来 Meta 的应用将以 AI 迎接客户，这些 AI 将能够「理解」用户并提供他们喜欢的内容，还能够生成出色的个性化内容。

会上，扎克伯格还提到到，AI 接入社媒后，用户将能够通过一段提示词（prompt）来创造一个虚拟世界或游戏，并且能与好友分享，甚至连视频在未来也将成为可以互动的形式。

值得一提的是，Google 近期正式推出了世界模型 Genie 3，用户只需要简单的提示词以及一张图片，便可以生成能够互动游玩的实时交互内容。

( @APPSO)

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么

写在最后：

我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。

对于任何反馈（包括但不限于内容上、形式上）我们不胜感激、并有小惊喜回馈，例如你希望从日报中看到哪些内容；自己推荐的信源、项目、话题、活动等；或者列举几个你喜欢看、平时常看的内容渠道；内容排版或呈现形式上有哪些可以改进的地方等。

作者提示: 个人观点，仅供参考​

最近，推理引擎领域出现了两件具有标志意义的事件：vLLM 和 SGLang 相继走向公司化。vLLM 核心团队成立 Inferact，完成 1.5 亿美元融资，估值达 8 亿美元：

图源：Inferact

SGLang 团队也成立了 RadixArk，同样获得融资，估值达到 4 亿美元：

图源：RadixArk

这并不是两起孤立的创业故事，而是在同一个时间点，对同一件事情给出了市场层面的确认：推理已经正式进入 AI 基础设施的核心层，而不再是模型之后的附属环节。

如果把过去几年 AI 的发展理解为模型能力竞赛，那么现在正在发生的，是一场系统工程能力竞赛。模型决定上限，推理系统决定规模化能力。一个模型是否有商业价值，越来越取决于它是否能被低成本、稳定、可持续地运行。

vLLM 和 SGLang 的融资，本质上是在为推理层重新定价。

一、推理引擎已经从工具升级为基础设施内核

早期的推理引擎更像是工具链的一部分，目标很简单：把模型跑起来，并尽量提升吞吐和降低延迟。它们解决的是局部性能问题，而不是系统性问题。

但今天的 vLLM 已经完全不同。它必须同时面对两条不断加速的演化曲线：

一条来自模型侧：Dense、MoE、多模态、Agent、超长上下文不断出现；

一条来自硬件侧：GPU、NPU、定制加速器、不同 CUDA/驱动/编译链并存。

在工程上，这意味着推理引擎被迫承担一个新的角色：

成为模型与硬件之间的通用适配层。

当一个系统需要同时满足：

• 支持大量模型架构
• 覆盖多种异构硬件
• 承载从科研验证到大规模生产负载

它的属性就已经不再是“工具”，而是基础设施内核。

SGLang 从另一个方向推动了同一件事。它把推理从“函数调用”扩展为“可编程执行流程”，特别适合 Agent、强化学习和复杂工作流场景。这说明推理系统正在同时向两个方向演进：

一方面更像操作系统内核，负责资源与性能；

另一方面更像运行时与编程模型，负责表达能力。

这两种属性叠加，正是基础设施系统的典型特征。

二、推理成本已经成为 AI 商业化的决定性因素

在真实工程中，一个简单的事实越来越清晰：

训练决定模型能不能出现，

推理决定模型能不能活下去。

对绝大多数公司来说：

• 训练是阶段性成本
• 推理是长期、持续、不可回避的成本

随着模型规模扩大、调用频率上升，推理成本已经从“次要支出”变成“核心账单项”。很多场景里，推理成本远高于训练成本。

这使推理系统具备了极强的经济敏感性：

• 5% 的吞吐提升
• 10% 的显存利用率优化
• 一点点调度效率提升

都会直接反映为真实的资金节省。

因此，推理引擎的价值不再只是“技术好不好”，而是“能不能直接影响 AI 服务的成本结构”。

这也是资本真正愿意为其高估值买单的原因。

三、推理系统的复杂性已经不可逆转

推理问题越来越难，并不是因为模型“更大”，而是因为系统维度在急剧膨胀：

• 模型形态更加复杂：Dense、MoE、多模态、Agent
• 推理形态更加复杂：长上下文、推理时计算、RL 循环
• 硬件环境更加碎片化：多 GPU、多 NPU、多编译链

工程上已经出现一个明显现象：

很多模型在理论上“可以跑”，

但系统在现实中“跑不动、跑不稳、跑不起”。

Inferact 提出的愿景非常关键：

部署前沿模型应该像创建一个 Serverless 数据库一样简单。

这句话的真实含义是：

推理系统必须吞掉所有复杂性，而不是把复杂性留给使用者。

四、推理系统治理问题会持续放大

当 vLLM、SGLang 进入快速演进之后，一个确定会发生的变化是：

新模型适配、新硬件支持、新优化策略都会更频繁进入主线版本。这对行业是好事，但对使用者来说，复杂度反而会上升。

在真实工程中很快会遇到这些问题：

• 同一模型在不同引擎版本下表现差异明显
• 不同硬件对引擎版本的支持程度不一致
• 升级引擎可能带来性能提升，也可能带来稳定性风险

推理引擎不再是“选一次就结束”的组件，而是进入持续治理阶段。

五、多引擎并存是工程必然，而不是选择题

现实生产环境中几乎不可能存在万能引擎：

• 有的模型适合 vLLM
• 有的模型适合 SGLang
• 有的场景适合 TRT-LLM
• 有的设备只能跑 llama.cpp

多引擎并存不是过渡状态，而是长期结构。

如果没有统一治理层，系统最终一定会退化为：

• 脚本堆叠
• 手工配置
• 版本失控
• 故障不可回溯

这是大型系统必然的退化路径。

六、GPUStack 的本质：推理系统的控制平面

GPUStack 并不是另一个推理引擎，它解决的是“引擎治理问题”。

在 GPUStack 的视角里：

• 引擎是可插拔资源
• 引擎版本是可调度对象
• 模型实例是可编排单元

推理引擎从“写死在系统里的依赖”，变成了“运行时可切换的能力”。

这在工程上的意义非常大：

• 可以并行运行多个引擎与版本
• 可以灰度升级
• 可以快速回滚
• 可以做真实可控的性能对比

支持自定义使用任意推理引擎：

自由切换任意推理引擎：

自由切换推理引擎版本：

推理系统开始具备云原生系统应有的治理能力。

七、引擎与版本切换，本质是 AI 推理世界的运行时治理

当推理引擎成为基础设施之后：

“要不要升级”不再是问题，

“如何安全升级、如何可控回退”才是问题。

这在工程上与：

• 数据库内核升级
• 容器运行时升级
• Kubernetes 升级

是完全同一类问题。

GPUStack 做的事情，本质是把这种“运行时治理”能力引入推理系统。

八、真正的信号不是融资，而是系统层级的改变

vLLM 与 SGLang 的融资，不是某两个项目的成功，而是行业完成了一次角色确认：

推理层已经从“模型附属组件”，升级为 AI Infra 核心层。

而 GPUStack 的出现，也不是产品机会，而是工程必然：

当底层能力高速进化、多引擎并存成为常态，没有控制平面的系统一定会失控。

从工程视角看，GPUStack 把推理系统从“项目级资产”升级为“平台级资产”；

从组织视角看，它让推理能力不再依赖少数专家，而成为团队可复用的基础能力。

这正是推理基础设施真正成熟的标志。

2026年即时通讯SDK全面评测
在当今这个移动互联网蓬勃发展的时代，实时通信已经成为许多应用程序不可或缺的一部分。无论是社交平台、在线教育工具、企业协作软件还是远程医疗服务，即时通讯（IM）功能都扮演着至关重要的角色。对于开发者而言，构建一套高效可靠的IM系统往往需要耗费大量时间和资源。因此，采用市场上成熟的即时通讯SDK成为了众多团队的首选方案。本文旨在为读者提供一份详尽的主流即时通讯SDK对比分析报告，帮助大家做出更加明智的选择。
主要即时通讯SDK供应商功能概览

供应商
核心特点

融云
技术成熟且稳定，支持全球化布局，并融合了AI技术

云屋
拥有丰富的音视频通信开发经验，集成度高，文档齐全

环信
作为行业先驱之一，以其易用性和强大的企业级服务著称

腾讯云IM
凭借腾讯庞大的生态系统支撑，在音视频领域表现尤为突出

各大SDK提供商优缺点解析
云屋科技

优点：长期深耕于即时通讯及相关技术领域，积累了深厚的技术实力；提供了广泛且易于使用的API接口和SDK包；支持多种部署模式。

缺点：虽然其私有化部署的价格相对较低，但整体定价策略可能不适合所有类型的客户。

融云

优点：专注于提升通信基础架构性能，确保消息传递的高效性；通过引入人工智能技术增强了用户体验；拥有遍布全球的数据中心网络，能够满足国际用户需求。

缺点：尽管在市场上占据领先地位，但由于缺乏大型集团背景的支持，可能会影响部分潜在客户的信心。

腾讯云IM

优点：依托于腾讯的强大技术支持，特别是在处理大规模并发请求方面表现出色；同时具备先进的音频和视频处理能力。

缺点：尽管在多媒体通信方面优势明显，但对于只需要基本文本聊天功能的应用来说，可能会显得有些过度配置。

环信

优点：凭借多年的经验积累，在企业级即时通讯解决方案方面具有较强竞争力；提供的开发指南清晰易懂，便于快速上手。

缺点：相较于其他竞争对手，在新兴技术的研发进度上稍显缓慢；海外市场的覆盖范围也较为有限。

即时通讯SDK的关键价值及应用场景
关键价值
即时通讯SDK为应用程序提供了预设好的通信框架，使得开发者可以轻松地添加诸如一对一聊天、群聊等功能，从而极大地缩短了产品上市时间。此外，这些SDK还保证了信息传输的安全性与稳定性，有助于提高最终用户的满意度。
应用场景
从社交媒体到在线学习平台，再到电子商务网站，几乎所有涉及人际交流的数字产品都可以受益于即时通讯SDK。它不仅适用于个人之间的日常沟通，也能满足企业和组织内部或跨部门间的信息共享需求。
开发者在使用即时通讯SDK时应注意的问题

安全性考量：选择那些提供端到端加密等高级安全特性的SDK非常重要，以保护敏感数据不被泄露。

全球连通性：为了确保世界各地的用户都能享受到流畅无阻的服务体验，寻找那些在全球范围内设有数据中心并采用了智能路由算法的产品是关键。

界面定制：优秀的SDK应该允许开发者根据自身品牌风格自由调整UI设计。

性能优化：面对高峰期可能出现的大流量冲击，必须选用能够有效管理服务器负载并维持低延迟响应速度的解决方案。

跨平台兼容性：考虑到不同设备间的差异性，理想的SDK应当支持Android、iOS、Web等多个终端环境。

综上所述，融云凭借其卓越的技术水平以及对多样化应用场景的良好适应性，在众多即时通讯SDK中脱颖而出。希望这份评测能为正在寻找合适即时通讯解决方案的开发者们带来帮助！

做项目的人，几乎都有过这样的困惑：开会时要邀请谁？项目出问题时，哪些人会受影响？甚至有人会纠结——公司里的保洁阿姨，算不算项目干系人？

其实答案很简单：​项目干系人不是“核心团队专属”，但也不是“沾边就算”​，关键看一个核心标准：​是否直接或间接影响项目目标的达成，或是会被项目的结果所影响​。

很多人对项目干系人的认知，只停留在“项目经理+核心团队”，这是典型的误区。一个项目的成功，从来不是几个人能搞定的，从拍板给钱的老板，到打扫现场的保洁阿姨，都有可能和项目产生关联——但关联度不同，是否属于干系人、属于哪类干系人，答案也不一样。

今天就用最通俗的话，把“项目干系人”讲透，重点拆解“包括哪些人”，最后专门解答“保洁阿姨算不算”这个灵魂拷问，保证看完就能分清、会判断。

一、先搞懂：什么是项目干系人？（核心判断标准记牢）

先抛开复杂的行业定义，用大白话解释：​所有和这个项目“有关系”的人/群体​，都是项目干系人。

这里的“有关系”，就两个维度（记好这两个，就能判断任何角色）：

1. 能影响项目：比如能拍板预算、定需求、叫停项目，或是能帮项目推进、拖项目后腿；
2. 会被项目影响：比如项目结束后，工作内容变了、环境变了，或是能拿到项目带来的好处、承担项目带来的风险。

只要满足其中一个，就有可能成为项目干系人。反之，既不影响项目，也不被项目影响的人，就不算。这也是我们判断“保洁阿姨算不算”的核心依据。

二、重点拆解：项目干系人具体包括哪些人？（分4类，好记又好懂）

我们按“影响度+关联度”，把干系人分成4类，每类都举具体例子，行业内不管是做项目管理、技术实施，还是行政支持的，都能对应上，不用死记硬背。

第一类：核心干系人（项目的“掌舵人”，缺一不可）

这类人直接决定项目的生死，是项目最核心的参与者，几乎全程深度参与，影响项目的每一个关键决策。

常见人群：

• 项目发起人/出资方：比如公司老板、甲方负责人、投资机构——他们给钱、给资源，拍板项目要不要做、做到什么程度，不满意就能叫停项目；
• 项目经理：项目的“大管家”，统筹所有事情，对项目结果负总责，协调所有干系人，是连接各方的核心；
• 核心执行团队：比如技术负责人、产品经理、主力开发/设计师、现场施工队长——直接动手做项目，决定项目能不能按要求、按时间完成。

重点：这类干系人是必须重点管理的，只要其中一个“掉链子”，项目就可能出大问题。

第二类：重要干系人（项目的“关键助力/约束者”，影响项目效率）

这类人不直接做核心工作，但能给项目提供支持，或是能给项目设“门槛”，他们的态度会影响项目的推进速度和质量。

常见人群：

• 客户/用户：项目最终是给他们用的，需求由他们提，验收由他们来做——他们不满意，项目就不算成功；
• 监理/审计人员：比如工程监理、公司审计——负责监督项目是否合规、是否按计划推进，避免项目出漏洞；
• 供应商/合作方：比如提供设备、材料、技术支持的第三方——他们能不能按时供货、提供合格的服务，直接影响项目进度；
• 公司职能部门负责人：比如财务（管预算、付款）、人力资源（配人员）、行政（管场地、物资）——没有他们的支持，项目团队就没法正常开展工作。

第三类：次要干系人（项目的“间接关联者”，影响范围有限）

这类人和项目的关联比较间接，既不做核心工作，也不直接拍板，但会被项目影响，或是能间接影响项目的小环节。

常见人群：

• 项目团队家属：比如员工加班多，家属可能有意见，间接影响员工的工作状态；
• 周边居民/商户：比如工地项目，施工噪音、扬尘会影响周边居民，他们可能投诉，间接影响项目施工；
• 公司其他部门员工：比如和项目团队同楼层的其他同事，项目的噪音、场地占用可能影响他们的工作。

第四类：边缘干系人（项目的“偶然关联者”，视场景而定）

这类人是否属于干系人，完全看项目场景——有时候关联，有时候不关联，也是我们最容易纠结的一类，比如我们今天要聊的保洁阿姨。

常见人群：保洁阿姨、保安、快递员等——他们和项目的关联度极低，只有在特定场景下，才会成为干系人。

三、灵魂拷问：保洁阿姨到底算不算项目干系人？（分场景说清，不模糊）

这是很多人最纠结的问题，答案不是“算”或“不算”，而是​看场景、看是否满足“影响/被影响”的核心标准​，我们分两种最常见的场景，一看就懂：

场景1：算！项目现场的专属保洁阿姨

如果保洁阿姨是项目现场专属的，比如：

工地项目的保洁阿姨，负责清理施工场地的垃圾、保持现场整洁；写字楼里某项目专属办公区的保洁，只负责这个项目团队的办公环境。

这种情况下，她就属于​边缘干系人​，理由很简单：

• 她会被项目影响：项目开工，她才有这份工作；项目结束，她的工作可能就没了（或调整）；
• 她能间接影响项目：如果她不及时清理现场垃圾，可能会影响施工安全（比如垃圾绊倒工人）、影响客户视察的印象，甚至可能被监理要求整改，拖慢项目进度。

虽然她不参与项目决策、不做核心工作，但她和项目有“间接的影响与被影响”关系，所以算干系人——只是属于边缘干系人，不用像核心干系人那样重点管理，但也不能完全忽略（比如保证她的工作到位，避免因卫生问题出小麻烦）。

场景2：不算！写字楼里的通用保洁阿姨

如果保洁阿姨是写字楼/园区通用的，比如：

负责整栋写字楼公共区域（走廊、电梯、卫生间）的保洁，不专门服务于某个项目，也不进入项目专属的办公区/施工现场。

这种情况下，她就​不算项目干系人​，理由也很明确：

她既不影响项目：项目做什么、怎么做、进度如何，和她没关系，她的工作也不会影响项目的目标达成；

也不被项目影响：不管这个项目开工还是结束，她依然负责公共区域的保洁，工作内容、收入都不会有变化。

简单说，她和项目“毫无关联”，自然不算干系人。

四、总结：判断干系人的核心，记住1句话就够了

不用再纠结“某个人算不算项目干系人”，记住核心判断标准：​只要他能直接/间接影响项目目标达成，或是会被项目结果直接/间接影响，他就是项目干系人​；反之，就不算。

回到我们的标题：项目干系人范围很广，从核心的老板、项目经理，到重要的客户、供应商，再到边缘的保洁阿姨（特定场景下），都有可能是；但不是所有沾边的人都算，关键看“影响与被影响”的关系。

对项目经理来说，分清干系人很重要——核心干系人重点盯，重要干系人多协调，边缘干系人适当关注，这样才能避免因“漏管某个干系人”而导致项目出意外，让项目推进更顺畅。

2024 年末以来，AI 编程进入爆发期，Cursor、Copilot、Windsurf 等工具让“对话式编程”成为开发者的新常态。然而，初期的“凭感觉编程”（Vibe Coding）逐渐暴露出一系列问题：AI 幻觉频发、代码质量参差不齐、团队协作困难等。

许多团队陷入了“越用 AI 越低效”的怪圈，大量时间消耗在反复修改与沟通对齐上。当项目从小型个人项目转向大型团队协作，需求从简单功能升级为复杂系统，仅靠模糊 Prompt 驱动的 AI 已无法胜任。

01 AI编程的范式迁移：SDD成为新共识

2025 年下半年，全球 AI 开发社区达成共识：真正的效率提升，不在于 AI 本身有多强，而在于开发者如何精准地引导 AI。为此，一种新的开发范式——

规格驱动开发（Spec-Driven Development, SDD）应运而生。

其核心思想是：在编码前，先定义一份清晰、可执行的“规格”（Spec），以此作为 AI 生成代码的唯一事实来源，从而将开发过程从“凭感觉”的即兴问答，转变为“有规范”的工程实践。

这一转变在上下文管理、代码质量、团队协作和变更成本等方面均带来了显著收益：

这一趋势得到了业界的广泛响应：GitHub 推出了标准化模板 spec-kit，Cursor 等主流 IDE 也原生支持“先规划、后编码”的工作流，标志着 SDD 正从前沿理念走向行业标准。

在这场范式迁移中，云智慧内部通过实践 SDD，将 AI 开发工程化，推出了具备企业级落地能力的具体方案——Cloudwise-sdd。

它不仅遵循社区共识，更通过 EARS 格式、.sdd/ 结构化目录等创新，将“规范先行”真正转化为可执行的工作流。

02  云智慧Cloudwise-sdd：将SDD落地为工程实践

Cloudwise-sdd 是云智慧基于 SDD 理念打造的工程化 AI 开发工具。它的产生并非一蹴而就，而是我们紧跟行业趋势、历经多个阶段探索的产物。

它直击当前 AI 编程的核心痛点：上下文缺失引发的幻觉、一次性对话导致的需求遗漏、代码风格不一致，以及团队协作中的理解偏差，通过将开发流程从“即时对话”升级为“分阶段、可追溯”的工程实践——要求在编码前先产出结构化的规格文档（涵盖需求、设计与任务），以此约束 AI 行为，确保输出符合项目规范。

其核心价值体现在四个方面：

目前，该工具已深度集成至 Cursor IDE，开发者可在日常编码中直接调用，无缝融入现有工作流。

03 六步实现规范驱动开发

云智慧Cloudwise-sdd 将传统软件工程中经过验证的规范驱动开发（Spec-Driven Development, SDD）思想，创新性地应用于大模型驱动的 AI 开发中，形成了一套结构化、可重复的标准化流程。

开发者不再需要“凭感觉”与 AI 协作，而是通过一系列明确的指令和阶段，将模糊的需求转化为高质量、可维护的代码。

整个工作流被精心设计为六个核心阶段，从项目初始化一直贯穿到代码实现，如下图所示：

这套流程不仅确保了开发过程的严谨性，也极大地提升了团队协作的效率和最终产出的稳定性。每个阶段都有其特定的指令和关键产出，汇总如下:

通过这六个阶段的层层递进，云智慧Cloudwise-sdd 将原本充满不确定性的 AI 编程过程，转变为一个规范、高效且成果可预测的工程化流程。

此外，对于一些小规模的修复或功能完善，云智慧Cloudwise-sdd 还提供了 / sdd / spec-patch 快速通道，允许开发者在必要时绕过完整的规范流程，直接进行代码修改，兼顾了流程的严谨性与开发的灵活性。

04 从“凭感觉”到“有规范”：云智慧Cloudwise-sdd助力研发效能新跃迁

云智慧Cloudwise-sdd 的本质，是为充满不确定性的 AI 交互建立一套清晰、可预测的工程规则，让高质量、可维护的代码产出从“靠运气”变为“可复制”。

它并非万能，但在复杂需求、核心模块开发或大规模重构等场景中，价值尤为显著。近期在云智慧 Kogia Agent Builder 项目中，团队全面采用 Cloudwise-sdd 工作流，一位开发者反馈：“原本预计两周的工作，一周高质量交付——AI 生成的代码边界清晰、风格统一，用起来更放心。”

这不仅是效率的提升，更是研发质量与团队信心的飞跃。

从“凭感觉”到“有规范”，云智慧正在将 AI 辅助开发带入真正的工程化时代。

云智慧Cloudwise-sdd 已完成内部验证，欢迎各团队联系了解实践细节。

*云智慧Cloudwise-sdd涉及数据来源于内部统计

Laravel12 + Vue3 的免费可商用商业级管理后台 CatchAdmin V5.1.1 发布

介绍

CatchAdmin 是一款基于 Laravel 12.x 与 Vue3 二次开发的 PHP 开源后台管理系统，采用前后端分离架构，面向企业级后台场景提供开箱即用的基础能力与可扩展的模块化框架。系统内置 Token 鉴权、权限管理（菜单/按钮/数据权限）、动态路由、动态表格、分页封装、资源权限控制、上传/下载、代码生成器（支持一键导入/导出）、数据回收站、附件管理等功能，覆盖后台系统从安全、权限到效率开发的常见需求。

在架构设计上，Laravel 仅作为 API 服务层对外输出，尽可能弱化业务模块之间的耦合关系。每个模块均具备独立的控制器、路由、模型与数据表结构，支持按模块拆分、按需加载与独立演进，从而降低开发复杂度，提高可维护性与迭代效率。同时，项目封装了大量通用能力与开发工具（如统一响应、异常处理、分页与资源封装等），让业务开发更聚焦、更高效。

基于 CatchAdmin，你可以快速搭建 CMS、CRM、OA 等各类管理系统，并在稳定的基础设施之上持续扩展业务模块，满足不同规模团队的开发与交付需求。

V5.1.1 版本亮点

• 优化获取模块名，修复前端页面加载失败
• 优化表单生成数据响应式
• 后台登录界面添加异常展示
• 优化表格刷新和重置
• 优化 catchtable 组件
• 优化后台系统设置
• 优化表格搜索组件
  等等更多...

快速开始

# 创建项目
composer create  catchadmin/catchadmin

# 安装项目
cd catchadmin && php artisan catch:install

# 启动项目
composer run dev

功能清单

• ☑️ 用户管理：用户添加、修改、删除，支持不同用户登录后台看到不同首页
• ☑️ 部门管理：部门组织机构（公司、部门、小组），树结构展现
• ☑️ 岗位管理：给用户配置所担任职务
• ☑️ 角色管理：树结构设计，支持角色菜单和按钮权限分配、角色数据权限分配
• ☑️ 菜单管理：配置系统菜单和按钮
• ☑️ 字典管理：对系统中经常使用的固定数据进行维护和复用
• ☑️ 系统配置：系统常用设置管理
• ☑️ 操作日志：用户正常操作的查询
• ☑️ 登录日志：用户登录记录查询
• ☑️ 文件上传：支持本地、七牛云、阿里云、腾讯云
• ☑️ 附件管理：管理系统上传的文件及图片
• ☑️ 数据表维护：数据表碎片清理和优化，管理数据回收和销毁
• ☑️ 代码生成：前后端代码生成（PHP、Vue、数据库迁移），支持一键生成到模块
• ☑️ Vue 即时渲染：前端 Vue 即时渲染，无需编译
• ☑️ 插件系统：CatchAdmin 插件即 Composer 包，完全绑定 Composer 生态

在线体验

演示地址：https://v5.catchadmin.com

超管账户

• 账户：catch@admin.com
• 密码：catchadmin

测试账户

• 账户：test@admin.com
• 密码：Testadmin1

项目地址

• GitHub：https://github.com/JaguarJack/catch-admin
• Gitee：https://gitee.com/catchadmin/catchadmin

项目预览

上一篇文章中，我为大家详细介绍了如何在 Windows 上部署 OpenClaw 并接入飞书：【保姆级教程】手把手教你安装 OpenClaw 并接入飞书，让 AI 在聊天软件里帮你干活。

不少朋友询问是否有 Mac 版的部署教程。今天，教程就来啦！其实在 Mac 上部署 OpenClaw 与 Windows 步骤基本一致。

本次教程除了从零完成 OpenClaw 的部署外，最大的不同在于交互平台换成了 Discord。接下来，就跟着我一步步完成部署吧！

一、什么是 OpenClaw

OpenClaw（原名 ClawdBot）是一个开源的个人 AI 助手平台，运行在你自己的设备上。它支持通过 WhatsApp、Telegram、Slack、Discord、飞书、钉钉、QQ、企业微信等多个平台与你互动。

其特点包括：

• 本地优先：运行在本地设备，数据完全由自己掌控
• 多平台支持：支持 macOS、Linux、Windows（WSL2）
• 多通道连接：可接入 WhatsApp、Telegram、Slack、Discord、Google Chat、Signal、iMessage 等
• 24/7 在线：以后台服务形式持续运行
• 高度可定制：支持技能扩展与自定义配置

二、基本要求

• Node.js：版本 ≥ 22.0.0（必需）
• npm：版本 ≥ 9.0.0（随 Node.js 安装）
• 一个 AI 模型的 API Key（本教程使用 MiniMax M2.1）

三、安装前准备

第一步：检查 Node.js 版本

打开 终端（Terminal），按 Cmd + Space 输入 “Terminal” 并回车。

执行以下命令检查 Node.js 版本：

node --version

预期输出：显示版本号，只要高于 v22.x.x 即可。

如果未安装 Node.js 或版本过低，请继续下一步。

第二步：安装 Node.js（如需）

方法一：使用官方安装包（推荐新手）

1. 访问 Node.js 官网：https://nodejs.org/zh-cn/download
2. 下载 LTS 版本（推荐 22.x 或更高）
3. 双击下载的 .pkg 文件，按提示完成安装
4. 安装后重启终端，执行 node --version 验证

方法二：使用 Homebrew（推荐开发者）

# 安装 Homebrew（如未安装）
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# 使用 Homebrew 安装 Node.js
brew install node

# 验证安装
node --version
npm --version

第三步：准备 AI 模型 API Key

OpenClaw 需要连接 AI 模型才能工作。国内推荐使用 MiniMax M2.1。

获取 MiniMax API Key：

1、注册或登录账号

访问官网：https://platform.minimaxi.com/subscribe/coding-plan?code=FSXN...

2、选择适合的订阅套餐

3、获取API Key

进入 Coding plan 页面，找到 API Key，点击重置并复制。妥善保存复制的 API Key
直达地址：https://platform.minimaxi.com/user-center/payment/coding-plan

四、安装 OpenClaw

一）自动脚本安装（推荐）

这是最简单、最标准的安装方式。

# 使用官方脚本安装 OpenClaw
curl -fsSL https://openclaw.ai/install.sh | bash

二）初始化配置

运行自动脚本安装完成后，会自动进入配置向导，引导你完成以下设置：

1. 风险告知

2. 引导面板模式：选择“快速开始”

3. 设置 AI 模型

选择 AI 提供商：这里我们选择 MiniMax。

选择模型：

输入 API Key：

选择默认模型：

4. 配置与 OpenClaw 通信的渠道

这里我们先选择跳过。本教程后续将使用 Discord 与 OpenClaw 通信。由于 Discord 配置稍显繁琐，后面会单独用一节详细讲解如何接入 Discord 机器人。你需要提前下载并注册好 Discord。如果觉得困难，也可选择飞书，详细配置可参考我上一篇文章：https://mp.weixin.qq.com/s/JGd4u8g-Fti4sRcJcSiOLQ。

5. 配置 Skills

Skills 也先跳过，后续可通过 Web UI 界面配置：

6. 配置 Hooks

Hooks 我们暂不需要配置。使用上下箭头选择 Skip for now，按下 空格键 选中，然后回车。

此时开始自动安装 Gateway 服务：

稍等片刻，Gateway 服务安装完成，开始选择启动机器人的方式：

完成后，OpenClaw 会自动通过默认浏览器打开 Web UI 页面：

五、配置 Discord 即时通信平台

OpenClaw 支持多种通讯平台，本教程我们选择 Discord。

一）注册账号并登录

注意：你需要自行解决科学上网问题。

官方地址：https://discord.com

二）创建一个服务器

1. 点击“添加服务器”

2. 选择“亲自创建”

3. 选择“仅供我和我的朋友使用”

4. 自定义服务器名称

三）进入开发者后台

访问地址：https://discord.com/developers/applications

四）创建应用

1. 点击“创建应用”

2. 输入应用名称

3. 自动跳转到“通用信息”页面

4. 获取 Token

点击 Bot 菜单，然后点击 重置 Token。

5. 重置完成后，复制你的 Token

6. 在当前页面继续向下滚动，找到 Message Content Intent 并启用

7. 进入 OAuth2 配置页面，勾选 Bot

8. 继续向下滚动，找到 Bot Permissions，勾选 Send Messages 和 Read Message History

9. 滚动到底部，复制生成的 Bot 链接

10. 将 Bot 加入服务器

在浏览器中打开刚才复制的链接，选择一个服务器（相当于将创建的机器人加入该服务器），选择前面创建的自定义服务器。

点击“授权”：

授权成功：

现在，你可以在自己创建的服务器中 @ 刚才添加的机器人了：

五）将 Discord 接入 OpenClaw

1. 进入 OpenClaw 配置

执行以下命令：

openclaw config

进入设置，选择“本地”：

选择“渠道”：

选择“配置连接”：

选择 Discord：

填入前面获取的 Bot Token：

允许所有频道：

选择“完成”：

访问策略保持默认：

配对模式也保持默认：

2. 启动网关服务

执行以下命令启动网关服务：

openclaw gateway

如果之前已启动过，请先执行 openclaw gateway stop 停止，再执行以上命令。

3. 将 Discord 与 OpenClaw 配对

回到 Discord 创建的频道，点击右上角的“显示成员”，可以看到当前频道成员。点击我们添加的 Bot：OpenClaw。

你会看到一个私聊输入框，可以试着发送一句话：

此时会跳转到私信聊天界面，并显示一个配对码。复制这个配对码。

打开一个新的终端窗口，输入以下命令：

openclaw pairing approve discord <Pairing code>

将 <Pairing code> 替换为刚才复制的配对码。

4. 重启网关服务

回到启动网关的命令行窗口，按下 Ctrl + C 停止服务，然后重新启动：

openclaw gateway

请注意，这个命令行窗口不能关闭，否则服务会停止。如果希望后台静默运行（即使关闭窗口也不受影响），可以执行：

nohup openclaw gateway --port 18789 --verbose > /dev/null 2>&1 &

5. 测试

现在回到 Discord 的服务器频道，在频道中 @ 你创建的机器人：

查看桌面文档的实际内容（示例）：

Discord 拥有多平台客户端，你也可以在手机上安装 Discord，通过手机指挥 OpenClaw 工作。

至此，OpenClaw 已成功与 Discord 打通。现在你可以在 Discord 中通过与 Bot 对话的方式，指挥 OpenClaw 操控你的电脑了！

六、常用命令

Gateway 管理

# 启动 Gateway
openclaw gateway

# 启动并显示详细日志
openclaw gateway --verbose

# 指定端口启动
openclaw gateway --port 18789

配置管理

# 运行配置向导
openclaw onboard

# 系统健康检查
openclaw doctor

# 查看配置
cat ~/.openclaw/openclaw.json

更新管理

# 更新到最新版本
openclaw update

# 切换到特定频道
openclaw update --channel stable    # 稳定版
openclaw update --channel beta      # 测试版
openclaw update --channel dev       # 开发版

结语

要想让 OpenClaw 出色地帮我们完成各种任务，还需要为它安装各种 Skills。点击头像关注我，接下来我会逐步分享 OpenClaw 的更多进阶玩法。

也欢迎通过主页找到我，加入 OpenClaw 实战交流群，与更多创作者一起碰撞灵感、探索新奇玩法！

在局域网或内网环境中使用HTTPS加密通信，可以为内部系统提供更高的安全性。本文将为你详细介绍如何为内网IP地址申请SSL证书。

为什么需要内网IP证书？

保护内部通信安全
防止中间人攻击
满足安全合规要求
消除浏览器不安全警告

申请前的准备工作

确认需求：确定需要证书的内网IP地址
选择证书类型：DV(域名验证)证书即可满足大多数内网需求
准备材料：通常只需要提供IP地址

下面是申请流程：

内网IP证书申请入口

一、注册账号

首先，打开浏览器，访问 JoySSL 的官方网站。注册一个账号，在注册中，务必填写注册码230970，这是获取免费测试一年期 IP 地址 SSL 证书的关键步骤，如果不填写该注册码，将无法获得免费测试的资格。

二、测试 IP 地址 SSL 证书，填写相关信息

注册成功后，使用刚刚注册的账号和密码登录 JoySSL 网站。登录成功后，在导航栏中，找到 “SSL 证书” 选项，选择 “IP 地址 SSL 证书”，并填写IP地址、联系人、联系方式等相关申请信息。

三、验证 IP 地址所有权

填写完申请信息后，接下来就是验证 IP 地址所有权的关键步骤。将验证文件上传到服务器上的指定目录。上传完成后，JoySSL 系统会自动检测验证文件的存在，以此来确认您对 IP 地址的管理权。

四、部署证书

下载证书文件后，就需要将其部署到您的服务器上，以使其生效。不同的服务器软件（如 Apache、Nginx、IIS 等）安装 SSL 证书的方法略有不同，具体参考帮助文档。

【Unity Shader Graph 使用与特效实现】专栏-直达

在Unity的Shader Graph中，Blackbody节点是一个专门用于模拟黑体辐射物理现象的功能节点。黑体辐射是热力学和量子力学中的重要概念，描述了理想黑体在特定温度下发出的电磁辐射特性。在计算机图形学中，这一物理原理被广泛应用于模拟真实世界中的热发光效果，为游戏和可视化应用增添了更多的物理准确性。

Blackbody节点的基本概念

黑体辐射理论源于19世纪末的物理学研究，当时科学家们试图解释物体受热时发出的光色变化规律。一个理想的黑体能够完全吸收所有入射的电磁辐射，同时在热平衡状态下以特定的光谱分布发射辐射。这种光谱分布仅取决于黑体的温度，而与它的形状或组成材料无关。

在Shader Graph中，Blackbody节点正是基于这一物理原理实现的。它通过输入温度值（以开尔文为单位），计算出对应的黑体辐射颜色。这一过程模拟了真实世界中物体随温度升高而改变发光颜色的现象，比如一块金属从暗红色逐渐变为亮白色。

理解Blackbody节点的工作原理对于创建逼真的热发光效果至关重要。它不仅提供了物理准确的颜色计算，还能帮助开发者避免手动调整颜色值的繁琐过程，确保不同温度下的颜色过渡自然且符合物理规律。

节点端口详解

Blackbody节点的设计简洁而高效，仅包含两个主要端口，分别负责输入温度数据和输出计算得到的颜色值。

输入端口：Temperature

Temperature端口是Blackbody节点的核心输入，它接收一个浮点数值或浮点纹理，表示黑体的绝对温度，单位为开尔文（K）。

• 温度范围的意义：在实际使用中，温度值通常应在1000K到40000K之间，这个范围覆盖了从红热到蓝热的主要可见光发光效果。当温度低于1000K时，节点会自动进行亮度衰减，模拟低温下微弱的光辐射。
• 开尔文温标的重要性：使用开尔文温标而非摄氏度或华氏度是因为它是热力学中的绝对温标，直接与粒子的平均动能相关，这对于物理正确的计算至关重要。
• 温度输入的灵活性：虽然节点设计用于处理标量温度值，但通过连接纹理采样节点，也可以实现基于空间变化的温度分布，创造出复杂的热图案效果。

输出端口：Out

Out端口输出一个三维向量（Vector3），表示在给定温度下黑体辐射的RGB颜色值。

• 输出格式：输出的颜色值已经过归一化处理，每个通道的值都在0到1之间，可以直接用于着色器的颜色输入。
• 颜色空间：输出的颜色位于线性颜色空间中，这与Unity的线性渲染工作流程相匹配，确保了颜色计算的准确性。
• 物理准确性：输出的颜色序列严格遵循黑体辐射的普朗克定律，从低温到高温呈现出红-橙-黄-白-蓝的经典颜色过渡。

数学原理与算法实现

Blackbody节点的核心算法基于黑体辐射的物理公式，通过近似计算将温度值转换为对应的RGB颜色。

普朗克辐射定律基础

黑体辐射的光谱分布由普朗克辐射定律描述，该定律给出了在特定温度T下，黑体在波长λ处单位波长间隔内辐射出的能量：

B(λ, T) = (2hc²/λ⁵) / (e^(hc/λkT) - 1)

其中h是普朗克常数，c是光速，k是玻尔兹曼常数。虽然完整的普朗克公式计算复杂，但Blackbody节点使用了一种经过优化的近似算法，在保证视觉准确性的同时提高了计算效率。

节点算法解析

根据生成的代码示例，我们可以看到Blackbody节点的具体实现方式：

void Unity_Blackbody_float(float Temperature, out float3 Out)
{
    float3 color = float3(255.0, 255.0, 255.0);
    color.x = 56100000. * pow(Temperature,(-3.0 / 2.0)) + 148.0;
    color.y = 100.04 * log(Temperature) - 623.6;
    if (Temperature > 6500.0) color.y = 35200000.0 * pow(Temperature,(-3.0 / 2.0)) + 184.0;
    color.z = 194.18 * log(Temperature) - 1448.6;
    color = clamp(color, 0.0, 255.0)/255.0;
    if (Temperature < 1000.0) color *= Temperature/1000.0;
    Out = color;
}

这个算法可以分为几个关键部分：

• RGB通道的分别计算：红、绿、蓝三个通道使用不同的公式计算，反映了人眼对不同波长光的敏感度差异。
• 高温条件的分支处理：当温度超过6500K时，绿色通道使用不同的计算公式，这对应于色温从暖白向冷白的转变点。
• 数值范围的限制：通过clamp函数确保颜色值在0到255之间，避免出现无效的颜色数值。
• 低温衰减：当温度低于1000K时，整体亮度按比例衰减，模拟低温下微弱的光辐射。

算法优化考虑

Unity选择这种近似算法而非完整的普朗克公式计算，主要基于实时渲染的性能考虑：

• 计算效率：近似算法大大减少了乘除和指数运算的次数，适合在着色器中高效执行。
• 视觉准确性：虽然数学上不完全精确，但在视觉结果上与真实黑体辐射非常接近，满足了大多数图形应用的需求。
• 数值稳定性：算法避免了极端温度下可能出现的数值溢出或除零错误，确保了在各种输入条件下的稳定性。

在Shader Graph中的实际应用

Blackbody节点在URP Shader Graph中有着广泛的应用场景，从简单的热发光材质到复杂的热视觉效果都可以通过它实现。

基础热发光材质

创建基础的热发光材质是Blackbody节点最直接的应用：

• 建立新的Shader Graph，创建Blackbody节点
• 将Temperature端口连接到可配置的浮点属性，方便在材质 inspector中调整温度
• 将Out端口连接到片元着色器的Emission输入，实现自发光效果
• 根据需要添加HDR颜色强度控制，增强发光效果在HDR渲染中的表现

这种设置可以用于模拟熔岩、发热的金属、火焰核心等高温物体，通过简单调整温度值即可获得物理正确的发光颜色。

动态温度效果

通过将Temperature端口与时间或空间变化的参数相连，可以创建动态的热效果：

• 时间动画：使用Time节点驱动温度变化，模拟物体加热或冷却的过程
• 噪声扰动：添加噪声节点创建不均匀的温度分布，模拟真实的热波动
• 顶点位置影响：基于顶点位置或深度信息控制温度，创建从中心向边缘衰减的热梯度

这些技术可以用于实现熔岩流动、冷却的锻造金属、或者逐渐加热的物体等动态效果。

热视觉特效

Blackbody节点也是创建热视觉或红外视觉效果的理想工具：

• 多温度分层：通过多个Blackbody节点组合，区分不同温度区间的颜色表现
• 后处理应用：在全屏后处理着色器中使用Blackbody节点，将场景深度或自定义热数据转换为热视觉颜色
• 热签名模拟：结合物体ID或自定义热属性，为特定物体添加热签名效果

这些应用在军事模拟、科幻游戏或特殊视觉效果中尤为有用。

温度值与颜色对应关系

了解常见温度值对应的颜色输出，有助于更有效地使用Blackbody节点。

典型温度颜色示例

以下是一些典型温度值与产生的颜色关系：

• 1000K：暗红色，类似于熔岩或炉火的颜色
• 2000K：橙红色，类似于蜡烛火焰或白炽灯丝
• 3000K：暖白色，类似于卤素灯或日出时的阳光
• 4000K：中性白色，类似于荧光灯或中午前的阳光
• 5500K：纯白色，接近于正午阳光的标准白点
• 6500K：冷白色，类似于阴天天空光或电子闪光灯
• 10000K：淡蓝色，类似于晴朗的蓝色天空
• 20000K以上：深蓝色，类似于非常热的恒星

颜色过渡特性

Blackbody节点产生的颜色过渡具有几个重要特性：

• 非线性过渡：颜色变化不是线性的，低温区间变化较慢，中温区间变化较快，高温区间再次变慢
• 饱和度变化：低温时颜色饱和度较高，随着温度升高饱和度降低，最终趋向于白色
• 亮度增长：整体亮度随温度升高而增加，但在不同温度区间的增长速率不同

理解这些特性有助于创建更自然的热效果动画，避免颜色变化的生硬感。

高级技巧与优化建议

掌握Blackbody节点的高级使用技巧可以大幅提升效果质量和性能。

性能优化策略

在性能敏感的场景中使用Blackbody节点时，可以考虑以下优化：

• 预计算温度贴图：对于静态或半静态的热效果，可以预先计算温度分布并存储为贴图，运行时直接采样而非实时计算
• LOD控制：根据物体与摄像机的距离，使用不同精度的温度计算或完全禁用热效果
• 温度范围限制：通过clamp节点限制温度输入范围，避免不必要的极端值计算

与其他节点的组合使用

Blackbody节点与其他Shader Graph节点组合可以创造更复杂的效果：

• 与Fresnel效应结合：创建边缘发热或冷却的效果
• 通过Blend节点混合多个热源：模拟复杂的热环境
• 使用Noise节点扰动温度分布：增加热效果的真实感和有机感

HDR渲染注意事项

在HDR渲染管线中使用Blackbody节点时需特别注意：

• 颜色强度控制：Blackbody节点输出的是归一化颜色，需要通过Multiply节点调整强度以适应HDR范围
• 色域映射：确保热颜色在色调映射后仍保持正确的色彩关系
• Bloom效果配合：调整Bloom阈值以确保热发光产生适当的光晕效果

常见问题与解决方案

在使用Blackbody节点过程中，开发者可能会遇到一些典型问题。

颜色不准确问题

如果发现Blackbody节点产生的颜色不符合预期：

• 检查温度单位：确认输入的是开尔文温度而非摄氏度（摄氏度+273.15=开尔文）
• 验证颜色空间：确保项目设置为线性颜色空间，否则颜色计算可能不正确
• 检查后处理效果：某些后处理效果（如颜色分级）可能会改变最终显示的颜色

性能问题

当使用多个Blackbody节点导致性能下降时：

• 合并温度计算：尽可能在单个Blackbody节点中处理所有温度相关计算
• 使用简化版本：对于远处或小物体，考虑使用简化的颜色渐变替代完整的Blackbody计算
• 批处理考虑：确保使用Blackbody节点的材质能够进行合理的合批处理

与其他系统的集成问题

将Blackbody效果与其他游戏系统集成时可能遇到的挑战：

• 与光照系统协调：确保自发光的Blackbody效果不会与场景光照产生冲突
• 热数据的来源：考虑如何从游戏逻辑中获取温度数据并传递给着色器
• 多平台兼容性：测试Blackbody节点在不同目标平台上的表现一致性

【Unity Shader Graph 使用与特效实现】专栏-直达
（欢迎

点赞留言

探讨，更多人加入进来能更加完善这个探索的过程，🙏）