Elric's Desk

背景

大疆 4G 图传模块有两种芯片方案：早期批次使用 移远 EG25-G，后期批次换用了 百望 QDC507。两种模块的默认 USB VID:PID 都是大疆私有的 2ca3:4006，通用 Linux 驱动无法直接识别。

VoHive 平台原生支持 Quectel 系列模块（VID:PID 2c7c:0125），通过 AT 命令改写 USB 身份后，百望模块也能无缝接入。

本文记录百望 QDC507 芯片模块的 VID:PID 改写过程与踩坑记录。移远 EG25 的改写方法可参考 之前的文章。

硬件信息

操作步骤

第一步：加载驱动并绑定设备

1
2
3
4
5
6

# 加载 usb-serial 和 option 驱动
sudo modprobe usbserial
sudo modprobe option

# 将 DJI 的 VID:PID 注册到 option 驱动
echo "2ca3 4006" | sudo tee /sys/bus/usb-serial/drivers/option1/new_id

此时系统会生成 /dev/ttyUSB0 ~ /dev/ttyUSB4 串口设备。

第二步：发送 AT 命令改写 USB 身份

1
2
3
4
5

# 写入新 VID:PID（永久生效，存入 NVRAM）
echo 'AT+QCFG="usbcfg",0x2C7C,0x0125,1,1,1,1,1,0,0' | sudo socat -t 3 - /dev/ttyUSB2,b115200,crnl

# 重启模块使更改生效
echo 'AT+CFUN=1,1' | sudo socat -t 3 - /dev/ttyUSB2,b115200,crnl

两个命令都应返回 OK。

第三步：验证改写结果

1
2
3

# 等待 5 秒后查看
lsusb | grep 2c7c
# 应显示: ID 2c7c:0125 Quectel Wireless Solutions Co., Ltd. EC25 LTE modem

踩坑记录

坑1：socat 参数必须用 crnl

最初我用的参数是 raw,echo=0：

1
2
3
4

# ❌ 无效 — AT 命令无响应
sudo socat - /dev/ttyUSB2,b115200,raw,echo=0 <<'EOF'
AT+QCFG="usbcfg",0x2C7C,0x0125,1,1,1,1,1,0,0
EOF

百望 QDC507 对终端模式有要求，必须使用 crnl 参数（自动处理 CRLF 换行）：

1
2

# ✅ 正确
echo 'AT+QCFG="usbcfg",0x2C7C,0x0125,1,1,1,1,1,0,0' | sudo socat -t 3 - /dev/ttyUSB2,b115200,crnl

坑2：AT 查询走 QMI 通道

百望 QDC507 与移远 EG25 的一个区别是：标准串口上的 AT 命令查询全部返回 ERROR。百望芯片将 AT 查询路由到了 QMI 通道，而非传统的 /dev/ttyUSB* 串口。

这意味着：

• 写入命令（如 AT+QCFG 改写 VID:PID）在 /dev/ttyUSB2 上有效
• 查询命令（如 AT+CGSN 查 IMEI）在串口上无效，需通过 QMI 协议读取

VoHive 走的是 QMI 通道，所以不受影响——设备注册、短信、网络状态等功能全部正常。

坑3：qmi_wwan 驱动未自动绑定

改写后模块重新枚举为 2c7c:0125，但 qmi_wwan 驱动可能没有自动绑定到网卡接口。需要手动注入：

1

echo "2c7c 0125" | sudo tee /sys/bus/usb/drivers/qmi_wwan/new_id

绑定成功后会看到 /dev/cdc-wdm0 设备。

VoHive 配置

VoHive 检测到新设备后，在 Web UI 添加即可。配置中 modem_type 保持 quectel，device_backend 使用 qmi。

VoHive 日志确认：

1
2

QMI: modem 支持 27 个 QMI 服务
[baiwang] 收到新短信通知 (QMI)

总结

两种芯片改写 VID:PID 的核心步骤相同，只是百望对 socat 终端参数更敏感。改写后永久生效，下次插入任何 Linux 设备都会直接识别为 Quectel EC25。

大疆 1 代 4G 模块本质是移远 Quectel EG25-G 公版模组，只是 USB VID/PID 被写成了大疆私有值。VoHive 平台只认标准 EC25 身份，不改就用不了。本文记录完整的改写和部署过程，包括踩过的坑。

背景

手头有一个大疆 1 代 4G 模块（Type-C 口），想用来跑 VoHive 平台——一个面向高通 4G/LTE 模组的综合管理与代理服务平台。

但大疆给这个模块写了一个私有的 USB 身份标识（VID:PID = 2ca3:4006），而 VoHive 只认标准的 Quectel EC25 (2c7c:0125)。插上 Linux 后虽然能识别，但 VoHive 不会搭理它。

解决方案： 通过 AT 命令把 USB 身份永久改写为标准 EC25，然后部署 VoHive 的 Docker 版。

VoHive 能做什么？

VoHive 由 Go 后端（Gin + GORM + SQLite）和 Vue 3 前端组成，把 4G 模组的管理能力打包成一个开箱即用的 Web 服务。以下是它的核心能力：

📡 多模组并发管理

• USB 热插拔自动发现，多设备实时状态监控
• 支持 Quectel EC20/EC25/EC21/EG25/EM20 等主流高通模组
• 同时管理多张 SIM 卡 / eSIM，互不干扰

🌐 轻量级代理引擎

• 内建 SOCKS5 / HTTP 代理，每个模组可独立开一个代理实例
• 基于 SO_BINDTODEVICE 严格绑定出站流量到指定网卡
• 典型场景：一张卡一个代理 IP，组成私有移动代理池

💬 短信收发中心

• Web 界面统一收发短信，支持会话和联系人管理
• 历史短信自动落库（SQLite），可搜索可导出
• USSD 交互（查询余额、套餐等）
• ⭐ 实用场景：多卡接码、验证码统一管理

📱 eSIM 全生命周期管理

• 通过 AT 指令通道直接管理 eSIM 芯片
• Profile 下载、启用、停用、重命名、删除
• 配合多 eSIM 卡，无需插拔物理卡即可切换运营商

🔔 多渠道通知推送

• 重要短信和系统告警可推送至：
  • Telegram、Email、PushPlus、Bark、飞书、QQ
• 不漏掉任何关键短信

📞 VoWiFi (IMS 通话)

• 通过宽带网络隧道建立 IMS 连接
• 地下室、弱覆盖场景下保证通话不掉线（本文暂未启用）

🏗️ 多架构支持

• 原生编译 amd64 / arm64 / armv7
• 可在路由器、树莓派、小主机上跑，部署灵活

VoHive 的 License 是 PolyForm Noncommercial 1.0.0，个人学习研究免费，商用需联系作者。

第一步：硬件识别与驱动加载

模块插到 Linux 机器上后，第一步是加载 USB 串口驱动：

1
2

sudo modprobe usbserial
sudo modprobe option

然后注入大疆的 VID/PID，让 option 驱动绑定这个设备：

1

echo "2ca3 4006" | sudo tee /sys/bus/usb-serial/drivers/option1/new_id

绑定成功后，/dev/ttyUSB0 ~ /dev/ttyUSB3 四个串口设备出现。其中 /dev/ttyUSB2 是 AT 命令通道。

⚠️ 注意：模块需要插入 SIM 卡才能正常枚举 USB，无 SIM 卡只亮红灯、不出现 ttyUSB 设备。

第二步：USB 身份改写（关键）

使用 socat 向模块发送 AT 命令，将 VID/PID 永久写入 NVRAM：

1
2
3
4

sudo socat - /dev/ttyUSB2,b115200,raw,echo=0,crnl <<'EOF'
AT+QCFG="usbcfg",2c7c,0125,0,0,8100,40E4,6300
AT+CFUN=1,1
EOF

参数解析：

• 2c7c,0125 — 目标 VID:PID，即 Quectel EC25
• 8100,40E4,6300 — 其他配置参数（厂商保留字段）

AT+CFUN=1,1 触发模块软复位。约 10 秒后模块重新枚举，lsusb 显示：

1

ID 2c7c:0125  Quectel Wireless Solutions Co., Ltd. 

改写成功！以后这模块插任何 Linux 机器都直接认成 EC25，无需重复操作。

踩坑 1：AT 命令语法

第一次发送 AT+QCFG 时返回 ERROR，经排查是 socat 需要 crnl 标志将 \n 转为 \r\n，否则模块不认识换行符。

踩坑 2：云内核没有 option 驱动

踩了个大坑——Docker VM 跑的 cloud kernel (linux-image-cloud-amd64) 不包含 usb-serial 和 option 驱动。lsusb 能看到设备，但 /dev/ttyUSB* 一个都没有。

解决： 切换到 Debian 标准内核：

1
2
3
4
5
6
7

# 查看 grub 菜单项
grep menuentry /boot/grub/grub.cfg

# 切换到标准内核 6.1.0-50-amd64
sed -i 's/^GRUB_DEFAULT=.*/GRUB_DEFAULT="1>2"/' /etc/default/grub
update-grub
reboot

Debian 12 在 ESXi VM 上 grub-reboot 不生效，必须直接改 /etc/default/grub。

第三步：VoHive 平台部署

准备配置目录

1

mkdir -p /opt/vohive/{config,data,logs}

创建配置文件

首次部署必须提供配置文件，否则容器反复重启。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

server:
  debug: false
  port: 7575

web:
  username: admin
  password: admin

devices:
  - name: DJI-4G
    port: /dev/ttyUSB2
    modem_type: quectel

vowifi:
  enabled: false

webhook:
  enabled: false

Docker Compose 部署

1
2
3
4
5
6
7
8
9
10
11
12
13
14

services:
  vohive:
    image: iniwex/vohive:latest
    container_name: vohive
    restart: unless-stopped
    network_mode: "host"
    privileged: true
    volumes:
      - ./config:/app/config
      - ./data:/app/data
      - ./logs:/app/logs
      - /dev:/dev
    environment:
      - TZ=Asia/Shanghai

关键点：

• network_mode: "host" — 模块通过 AT 串口通信，不需要端口映射，host 模式最直接
• privileged: true — 访问 /dev/ttyUSB* 需要特权模式
• 挂载 /dev — 让容器内能访问串口设备

启动：

1
2
3

cd /opt/vohive
docker compose -f docker-compose.custom.yml pull
docker compose -f docker-compose.custom.yml up -d

验证

1
2
3
4

curl -s -o /dev/null -w '%{http_code}' http://localhost:7575/
# 返回 200

docker logs vohive | tail -5

VoHive Web Dashboard 访问：http://<服务器IP>:7575，默认账号 admin/admin（首次登录后务必修改密码）。

第四步：SIM 卡状态确认

部署完成后通过 AT 命令查询模块和网络状态：

附录：关于原作者删库

就在部署完成不久后，VoHive 原作者 iniwex5 宣布「无限期停止维护」，清空了源码仓库。vohive-release 仓库（含预编译二进制）仍公开，但需注意后续独立部署的可能性。

建议做法：

• Fork 备份：将关键仓库 fork 到自己的 GitHub，确保后续可用
• 保留 Docker Hub 镜像：iniwex/vohive:latest 是现成的，优先使用
• 社区备份：hzlmy2002/vohive-collection 备份了完整源码 + 所有 Go 依赖（netlink、qqbot、euicc-go、quectel-qmi-go 等）

总结

整个过程不算复杂，但有几个关键注意点：

1. ✅ USB 身份改写一次，永久生效 — 以后再也不用管了
2. ⚠️ 必须用标准内核 — cloud kernel 没有 usb-serial 驱动
3. 🔑 crnl 参数 — socat 发 AT 命令必须加，否则 ERROR
4. 🐳 Docker host 网络 + privileged — 串口设备访问必备
5. 📡 模块需要 SIM 卡才能正常枚举 — 无 SIM 只亮红灯

VoHive 的 Web 界面可以发短信、管理 eSIM、开代理、接推送通知，作为 4G 模块的管理平台非常实用。下一步可以探索它的 VoWiFi 和代理池功能。

在 AI 大模型的时代，”数据隐私”和”响应速度”越来越成为关注点。与其把敏感信息发送到云端 API，不如在自家局域网里跑一个本地模型。

本文记录我在 ai-server 上部署 Qwen 3.6 27B 的全过程 —— 从硬件选型、ROCm 环境搭建、llama.cpp 编译，到 systemd 守护和性能调优。希望给同样想在消费级 AMD 显卡上跑大模型的朋友一些参考。

🛠 一、硬件清单

为什么选 AMD 显卡？

RX 7900 XTX 拥有 24GB GDDR6 显存。在消费级显卡里，24GB 这个价位段的选择并不多 —— NVIDIA 这边要 RTX 4090 才能达到 24GB，而 AMD 的 7900 XTX 价格更友好，性价比明显。配合 ROCm 7 的日益成熟，在消费级 AMD GPU 上跑 LLM 已经是一条完全可行的路。

⚠️ 注意： B460 主板的 PCIe 3.0 x16 带宽约为 16 GB/s，而 GDDR6 显存带宽超过 600 GB/s，两者相差 40 倍。这意味着当 KV cache 溢出到系统内存时，PCIe 带宽会成为非常明显的瓶颈。如果你要装机，建议至少选 PCIe 4.0 的主板。

🐳 二、ROCm 环境搭建

ROCm 是 AMD 的 GPU 计算平台，类似于 NVIDIA 的 CUDA。在 Ubuntu 24.04 上安装 ROCm 比想象中要顺利。

安装步骤

Ubuntu 24.04 的官方源已经包含了 ROCm 7 系列的软件包，直接通过 apt 安装即可：

1
2
3

# 添加 ROCm 仓库并安装
sudo apt update
sudo apt install rocm-hip-libraries rocm-device-libs rocm-smi-lib

安装完成后，确认 ROCm 版本：

1
2
3

# 查看 ROCm 信息
rocm-smi
hipcc --version

输出结果：

1
2

HIP version: 7.2.53211-97f5574fe2
AMD clang version 22.0.0git

1
2

Device  Node  IDs              Temp    Power  Partitions          SCLK  MCLK    Fan    Perf  PwrCap  VRAM%  GPU%
0       1     0x744c,   5113   67.0°C  61.0W  N/A, N/A, 0         0Mhz  772Mhz  60.0%  auto  303.0W  86%    0%

GPU 被正确识别为 gfx1100（Navi 31 架构），ROCm 运行正常。

安装过程中的注意点

内核模块：amdgpu 内核模块是 Ubuntu 24.04 自带的，安装完 ROCm 后会自动加载：

1
2
3

lsmod | grep amd
# amdgpu              17166336  3
# amdxcp                 12288  1 amdgpu

GPU 目标架构：RX 7900 XTX 对应的是 gfx1100。编译 llama.cpp 时需要指定这个目标，否则 GPU 加速无法生效。如果你的显卡型号不同，可以在 AMD GPU 列表 中查到对应的 gfx 代号。

用户权限：确保运行推理服务的用户在 video 用户组中，这样才有权限访问 GPU 设备：

1

sudo usermod -aG video elric

🔨 三、编译 llama.cpp

llama.cpp 是一个用纯 C/C++ 编写的 LLM 推理框架，支持 GGUF 格式的模型文件，对 AMD GPU 通过 ROCm/HIP 提供了良好的支持。

源码克隆与构建

1
2
3
4
5

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
mkdir build && cd build
cmake .. -DGGML_HIP=ON -DGPU_BUILD_TARGETS=gfx1100 -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)

关键构建参数说明

构建结果确认

编译完成后，可以通过 cmake -LH .. 查看配置摘要，确认关键项：

1
2
3
4
5

GGML_HIP:BOOL=ON
GGML_HIP_GRAPHS:BOOL=ON
GGML_HIP_MMQ_MFMA:BOOL=ON
GPU_BUILD_TARGETS:STRING=gfx1100
CMAKE_BUILD_TYPE:STRING=Release

• GGML_HIP_GRAPHS=ON 表示 GPU 计算图优化已启用，可以提升推理效率
• GGML_HIP_MMQ_MFMA=ON 表示使用了 AMD 的矩阵乘法加速指令
• GGML_AVX、GGML_AVX2、GGML_AVX512 全部为 OFF —— 因为 GPU 承担了主要计算，CPU 指令集优化的收益不大

经验之谈： 编译时间取决于 CPU 核心数。i5-10400F（6 核）大约需要 15-20 分钟。如果用的是更多核心的 CPU，可以进一步缩短。

📦 四、模型选择

模型是本次部署的核心选择。我选用了 Qwen 3.6 27B 的 abliterated 版本：

1
2
3

模型文件: huihui-qwen3.6-27b-abliterated-q4_k_m.gguf
大小: 16.5GB
量化: Q4_K_M（4-bit 混合精度）

为什么是 abliterated 版本？

abliterated（去拒绝化）版本是通过 OBLITERATUS 工具处理过的模型。它去除了模型的安全拒绝机制，让输出更加自由灵活。

对于本地私有部署来说，这个特性非常实用：

• ✅ 不会无缘无故拒绝回答问题 —— 云端模型经常因为安全策略拒绝回答一些完全正常的问题，本地部署的 abliterated 版本则直接给出答案
• ✅ 输出更直接 —— 不需要绕过安全过滤，回答更自然
• ✅ 更适合个人使用和开发调试 —— 没有安全层的干扰，方便测试和迭代

为什么选 Qwen 3.6 27B？

27B 参数规模是一个甜蜜点 —— 比 7B/8B 强一个档次，同时 24GB 显存用 Q4_K_M 量化（约 16.5GB）后可以装下，还留有显存给 KV cache 和系统开销。

如果你显存更大（48GB+），可以考虑 Qwen 3.6 更大参数的版本。如果显存更小（12GB 左右），7B/8B 的模型会更合适。

⚙️ 五、systemd 守护进程

为了让模型服务持续运行，配置了 systemd 服务。这样即使 SSH 断开，服务也不会停止。

服务文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# /etc/systemd/system/llama.service
[Unit]
Description=Llama CPP Server with ROCm Acceleration (64K + Continuous Batching)
After=network.target

[Service]
Type=simple
User=elric
ExecStart=/home/elric/llama.cpp/build/bin/llama-server \
  -m /home/elric/llama.cpp/models/huihui-qwen3.6-27b-abliterated-q4_k_m.gguf \
  --alias qwen3.6-27b \
  --host 0.0.0.0 \
  --port 1234 \
  -ngl 99 \
  --flash-attn on \
  -np 1 \
  -b 4096 \
  -ub 1024 \
  --ctx-size 65536 \
  -ctk q8_0 \
  -ctv q8_0 \
  --threads 6 \
  --jinja
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

然后启用服务：

1
2

sudo systemctl enable llama.service
sudo systemctl start llama.service

启动参数详解

显存预算：为什么是 q8_0 + 64K？

这部分值得多花点篇幅，因为这是整个配置最关键的决策。

KV cache 存储了对话历史中的注意力信息。它越大，能记住的上下文就越长，但也越占显存。量化策略需要在精度和显存之间做权衡。

24GB 显存的账本：

q8_0 + 128K 会溢出 24GB 显存。 之前配置就是这样，VRAM 占用达到 86%，KV cache 溢出走 PCIe 3.0（仅 16 GB/s），生成速度直接从 25 t/s 掉到 10 t/s 以下。

最终方案：q8_0 + 64K

• ✅ 显存安全（~22 GB，留了 ~2 GB 余量）
• ✅ q8_0 高精度 KV cache，长对话不丢失上下文精度
• ✅ 64K 上下文对日常使用完全够用（约 4-5 万汉字）
• ✅ 速度稳定在 ~25 t/s，不波动

如果你选择 q4_0 KV cache： 每个 token 只需约 32KB，128K 上下文占用约 3.8GB，显存压力更小。适合想要更大上下文窗口的情况。

q8_0 的优势： 精度更高，长对话中缓存命中率更好，减少不必要的重算。实测下来，在显存够用的前提下，q8_0 带来的稳定性提升是值得的。

📊 六、性能实测

以下是实际运行中的数据，全部从服务日志直接抓取（journalctl -u llama.service）：

生成速度（Decoding）

~25 tokens/s 的持续生成速度意味着一段 200 词的英文回复大约需要 8 秒完成，完全满足实时对话的需求。

Prompt 处理速度（Prefill）

FlashAttention 的加速效果非常明显。

系统资源

💡 七、调优心得

1. 显存预算是第一要务

最开始用了 q8_0 + 128K 上下文，显存压到 86%，KV cache 溢出走 PCIe 3.0，速度直接腰斩。将 --ctx-size 降到 64K 后，显存降到 ~76%，速度稳定在 25 t/s，问题彻底解决。

教训： 24GB 显存不是无限的，q8_0 精度虽好，但 128K KV cache 会吃掉 7.5GB，加上 16.5GB 模型就 24GB+，一定会溢出。先算账，再调参。

2. PCIe 3.0 是隐形的瓶颈

B460 主板的 PCIe 3.0 带宽只有 ~16 GB/s。当显存不足、KV cache 被 offload 到系统内存时，每次 token 生成都要通过 PCIe 总线搬运数据，延迟显著增加。

实际体验： 当 KV cache 溢出到 CPU 内存时，生成速度能从 25 t/s 掉到 10 t/s 以下。确保 KV cache 完全留在显存里是提升性能的第一要务。

如果你要装机： 尽量选 PCIe 4.0 以上的主板。PCIe 3.0 在显存溢出时拖累严重。

3. 批次参数影响很大

将 -b 从 2048 提升到 4096、-ub 从 512 提升到 1024 后，GPU 利用率更高，生成速度从 ~21 tokens/s 提升到了 ~25 tokens/s。更大的批次意味着 GPU 的计算单元能更好地并行工作，减少等待。

建议： 如果你的显卡显存充裕，可以把 -b 设得更大（8192），看看效果。

4. KV cache 量化策略

早期配置使用 q4_0 KV cache，后来调整为 q8_0。虽然显存占用从 ~65% 上升到了 ~76%，但长对话场景下的生成速度更加稳定。原因是 KV cache 精度更高，减少了缓存失效带来的重算 —— 每次不用重新处理之前的上下文。

结论： 在显存预算内，优先给 KV cache 更高的量化精度。但前提是 总显存不溢出 —— 如果 q8_0 会溢出，那就果断用 q4_0。

5. 16GB 内存偏紧

系统原只有 16GB 内存，llama 进程本身就要占用约 6GB。加上系统和后台进程，可用内存比较紧张。在高负载时，系统会用到 Swap，影响响应速度。

已升级到 24GB，计划最终升级到 128GB M.2，不仅给 llama.cpp 更多余量，还能彻底解决内存瓶颈。

🔗 八、接入 Hermes Agent

部署完成后，模型通过 OpenAI 兼容 API 提供服务。Hermes Agent 通过自定义 provider 连接到本地端点：

1

http://localhost:1234/v1

这意味着：

• 数据不出局域网 —— 所有对话内容完全私有
• 无 API 调用费用 —— 一次部署，长期使用
• 低延迟 —— 局域网内响应，没有公网往返

我的日常使用场景是：通过 Telegram 发消息给 Hermes，Hermes 调本地模型推理，整个流程在局域网内完成。写文章、查资料、调试代码……完全不需要把数据送到云端。

📝 九、总结

在消费级硬件上部署 27B 参数的本地大模型是完全可行的。RX 7900 XTX 的 24GB 显存是一个甜蜜点，配合 ROCm 7 和 llama.cpp，可以实现稳定的推理服务。

核心经验：

1. 显存预算是硬约束 —— 24GB 要精确计算：模型 + KV cache + ROCm 开销，超出就会溢出
2. q8_0 + 64K 是 24GB 显存的甜点配置 —— 高精度 KV cache + 安全显存余量 + 稳定速度
3. PCIe 带宽不容忽视 —— 尽量让数据留在显存内，装机时选 PCIe 4.0 主板
4. abliterated 版本更适合本地私有部署 —— 没有安全层的干扰，输出更自由
5. systemd 守护 + OpenAI API 兼容 = 即插即用的服务 —— 任何支持 OpenAI API 的客户端都能直接接入

下一步： 内存升级到 128GB M.2，移除 Windows 11，让这台机器纯粹为 AI 推理服务。

本文中的性能数据来自 2026 年 7 月的实际运行日志，测试环境为局域网内部。llama.cpp 版本为 v9873（commit a4107133a）。

背景：为什么在有了 Telegram 后还需要 Matrix？

在使用 AI 助理（OpenClaw）的过程中，我最初主要依赖 Telegram 进行交互。但由于网络波动和节点稳定性问题，Telegram 偶尔会出现指令断连或响应延迟。为了建立更稳健的通讯冗余，我部署了私有化的 Matrix (Synapse) 服务。

为了确保与 AI 助理对话的绝对私密性，开启 端到端加密 (E2EE) 是必不可少的一步。以下是基于 OpenClaw 与 Synapse 的实战配置流程。

1. Matrix 的核心优势

• 自托管控制：所有聊天记录存储在自己的服务器上。
• 高可用性：作为 Telegram 的互补通道，即使公网代理波动，通过隧道加密的 Matrix 依然能保持高可用。
• 安全性：原生支持端到端加密，确保只有发送者和接收者（你和 AI）能解密消息。

2. 开启步骤

2.1 修改 OpenClaw 配置

在 OpenClaw 的 openclaw.json 配置文件中，找到 channels.matrix 部分，添加 "encryption": true 配置项。

1
2
3
4
5
6
7
8
9
10
11

{
  "channels": {
    "matrix": {
      "enabled": true,
      "provider": "matrix",
      "homeserverUrl": "https://matrix.yourdomain.com",
      "accessToken": "your_access_token",
      "encryption": true  // 关键配置：开启加密
    }
  }
}

2.2 应用配置与重启

修改完成后，需要重启 OpenClaw 以加载新的加密模块。

1
2

# 执行热重启 (SIGUSR1)
openclaw gateway restart

3. 关键：设备验证 (Manual Verification)

开启加密后，你的 Matrix 客户端（如 Element）会提示「未经验证的设备」。这是 E2EE 的核心机制——你需要手动信任 AI 助理这个「新设备」。

• 操作提示：在 Element 中打开与助理的私聊窗口，点击助理的头像进入个人信息，选择「验证 (Verify)」。
• 完成握手：按照提示完成对比图表或确认，一旦显示绿色小盾牌，即表示加密链路正式建立。

4. 推荐客户端 (Multi-platform Clients)

为了获得最佳的 E2EE 体验，建议选择对加密支持完善的客户端：

1. Element X (iOS / Android) —— 强烈推荐

   • 官方最新旗舰版，底层使用 Rust 重新编写。响应极快，UI 更加现代化。针对 E2EE 进行了大幅优化，验证流程更顺滑。

2. Cinny (Web / Desktop)

   • 极简主义风格，非常轻量。如果你喜欢类似 Slack 或 Discord 的多频道布局，Cinny 是最佳选择。

3. SchildiChat (Android / Desktop)

   • 基于 Element 修改的社区版，结合了 Element 的功能和更传统的即时通讯布局（如气泡对话框）。

4. FluffyChat (Linux / Android / iOS / Web)

   • 界面非常可爱、清新，操作门槛极低，跨平台一致性好。

5. 常见问题：联邦路由

如果你的助理需要跨服务器通讯（联邦），请确保通过 Cloudflare Tunnel 或反代正确暴露了 /.well-known/matrix/server 接口，否则加密握手包可能会在联邦链路上解析失败。

总结

通过 Matrix + E2EE 的组合，不仅解决了 Telegram 在特殊网络环境下的连通性痛点，还实现了金融级的对话隐私保护。现在，我可以放心地在任何网络环境下调教我的助理了。

本文由 Elric 的 不太聪明智能助理「小龍蝦 🦞」协助整理与发布。

在家庭宽带环境下部署 Matrix Synapse，最头疼的莫过于公网 IP 暴露和联邦通讯（Federation）不通。通过 RB5009 开启端口转发不仅不安全，还容易被运营商“喝茶”。

今天记录一套基于 Cloudflare Tunnel + Worker 的全隔离部署方案，实现真正的“隐身”运行。

在复杂的家庭网络环境中，双路由（主路+旁路）协作是许多发烧友的选择。本文将记录一次针对 MikroTik RB5009 与 ImmortalWrt 的深度联合调优过程，涵盖 DNS 闭环构建、加密解析精修以及 Xray 性能压榨。

HP LaserJet P1505n 是一款基于 Host-based 协议的经典打印机。本文将分享一套通过 Docker 容器化技术，为该打印机提供完美 AirPrint 支持的方案。

本方案解决了 iOS 预览显示、Web 管理权限、多余打印机名称以及物理关机后自动显示离线等核心问题。

在长期将 RouterOS 运行在 ESXi 8.0 虚拟机后，笔者最近终于入手了实体“神机”—— MikroTik RB5009UG+S+。实体硬件带来的 L3 硬件加速（HW Offloading）与 10G SFP+ 扩展性是虚拟环境无法比拟的。本文将从迁移背景、基础拨号、进阶分流到 RustDesk 深度优化，全面记录这台设备的配置精华。

在建立个人博客时，如何实现“写完即发布”的无感体验？本文将详细介绍一套专业的静态网站架构：通过 GitHub 私有仓库 存放源代码，利用 GitHub Actions 自动构建，并最终经由 Vercel 全球加速分发。

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start

Create a new post

1

$ hexo new "My New Post"

More info: Writing

Run server

1

$ hexo server

More info: Server

Generate static files

1

$ hexo generate

More info: Generating

Deploy to remote sites

1

$ hexo deploy

More info: Deployment