Files
wiki/sources/2026-04-10.md
2026-04-10 20:14:25 +00:00

273 lines
11 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
pageType: source
id: source.2026-04-10
title: 2026 04 10
sourceType: local-file
sourcePath: /home/node/.openclaw/workspace/memory/2026-04-10.md
ingestedAt: 2026-04-10T15:43:24.102Z
updatedAt: 2026-04-10T15:43:24.102Z
status: active
---
# 2026 04 10
## Source
- Type: `local-file`
- Path: `/home/node/.openclaw/workspace/memory/2026-04-10.md`
- Bytes: 10904
- Updated: 2026-04-10T15:43:24.102Z
## Content
````text
# 2026-04-10 — Настройка Memory Wiki + QMD
## Что делали
Полный аудит и реконфигурация системы памяти OpenClaw. Сессия ~5 часов (07:0512:57 UTC) через webchat.
---
## Memory Wiki (memory-wiki plugin)
### Диагноз bridge mode
Обнаружили что `openclaw wiki bridge import` всегда возвращает 0 артефактов. Провели глубокое расследование:
- Bridge mode требует что memory-core зарегистрировал capability через `api.registerMemoryCapability()`
- `listActiveMemoryPublicArtifacts()` читает из `memoryPluginState` в `memory-state-BqTSwHeB.js`
- **Root cause:** OpenClaw использует jiti vm-контексты для изоляции плагинов. memory-core и memory-wiki загружаются в разных jiti-контекстах → их `memoryPluginState` — разные объекты → capability не видна
- CLI-команда дополнительно запускается в новом процессе без gateway-контекста
- **Вывод:** bridge mode в 2026.4.9 для bundled plugins не работает — архитектурная проблема, не баг конфига
### Что настроили в openclaw.json
```json
// plugins.entries.memory-wiki.config:
"bridge": {
"enabled": true,
"readMemoryArtifacts": true,
"indexDailyNotes": true,
"indexMemoryRoot": true,
"indexDreamReports": true, // добавлено
"followMemoryEvents": true // добавлено
},
"context": {
"includeCompiledDigestPrompt": true // добавлено — wiki digest в промптах
}
// agents.list[main].tools.allow — добавлены:
"wiki_status", "wiki_search", "wiki_get", "wiki_apply", "wiki_lint"
```
### Текущий статус wiki
- Vault: `/home/node/.openclaw/wiki/main`
- Mode: bridge (формально), фактически работает через manual ingest
- Sources: 6 (MEMORY.md, PROJECT.md файлы)
- Entities/Concepts/Syntheses: 0 (не наполнено)
- `openclaw wiki compile` и `openclaw wiki lint` работают
- `wiki_*` инструменты добавлены в allowed tools main агента
---
## QMD — установка и настройка
### Конфиг (добавлен корневой ключ `memory` в openclaw.json)
```json
"memory": {
"backend": "qmd",
"qmd": {
"command": "/home/node/.local/bin/qmd",
"paths": [
{ "name": "tasks", "path": "~/.openclaw/workspace/tasks", "pattern": "**/*.md" },
{ "name": "skills", "path": "~/.openclaw/workspace/skills", "pattern": "**/*.md" }
],
"sessions": { "enabled": true }
}
}
```
Ключевой момент: `memory` — корневой ключ, НЕ под `agents.defaults`. `agents.defaults.memory` — невалидный ключ (проверено).
### Проблема с коллекциями
QMD создавал `memory-root-main` с паттерном `**/*.md`, хотя OpenClaw ожидает `MEMORY.md`. Затем не мог создать `memory-alt-main` для того же пути.
**Фикс:** вручную добавить `memory-alt-main` в `~/.openclaw/agents/main/qmd/xdg-config/qmd/index.yml`:
```yaml
memory-alt-main:
path: /home/node/.openclaw/workspace
pattern: "memory.md"
```
После этого удалить sqlite и переиндексировать:
```bash
rm ~/.openclaw/agents/main/qmd/xdg-cache/qmd/index.sqlite*
openclaw memory index --force
```
### Эмбеддинги
- Модель: `embeddinggemma-300M-Q8_0.gguf` (~328MB, скачана)
- Только CPU, без GPU → embed одного батча занимает 30+ минут
- OpenClaw таймаутит на 120 сек и помечает Vector: unavailable, но фоновый процесс продолжает
- После завершения: Vector: ready автоматически
### Итоговые коллекции (main агент)
| Коллекция | Путь | Документов |
|---|---|---|
| memory-root-main | workspace/ | 159 |
| sessions-main | agents/main/qmd/sessions/ | 111 |
| tasks-main | workspace/tasks/ | 104 |
| memory-dir-main | workspace/memory/ | 33 |
| skills-main | workspace/skills/ | 10 |
| memory-alt-main | workspace/ (memory.md) | 0 (Linux, нет файла) |
Итого: 417 документов, 448+ векторов (>100% — чанкинг больших файлов)
### Статус всех агентов
- main: Vector ready ✅
- dev: Vector ready ✅
- legal: Vector ready ✅
- feda: Vector ready ✅
### Тест поиска (результат)
```
openclaw memory search --query "vprok интернет заказы relay"
→ 0.96 tasks/internet-orders/project.md ✅
memory_search (через инструмент) "vprok интернет заказы relay"
→ provider: qmd, score: 0.96 ✅
```
---
## Итог дня
### До
- builtin SQLite, 33 файла, 101 чанк
- Только BM25 + vector (OpenAI API)
- Нет sessions, нет tasks/, нет skills/
- Нет wiki инструментов
### После
- QMD sidecar, 417 документов, 448+ векторов
- BM25 + Gemma-300M (локально) + reranking
- Sessions, tasks/, skills/ проиндексированы
- wiki_* инструменты подключены
- includeCompiledDigestPrompt включён
### Открытые вопросы
- Bridge mode не работает (jiti-изоляция) — ждём фикса в OpenClaw или переходим на unsafe-local
- Wiki не наполнена (0 entities/concepts) — следующий шаг
- Dreaming отключён — можно включить
- embed медленный на CPU — при следующем полном сбросе индекса ждать 30-60 мин
---
## Сессия вечер: Прозрачный прокси (Wi-Fi + HA Telegram) — 13:0015:00 UTC
### Задача #1: Wi-Fi homenet-vpn (192.168.4.0/24) через VLESS tproxy
**Статус:** НЕ ЗАВЕРШЕНА. TCP через tproxy не работает.
**Причина проблемы:**
- Ключевой конфликт: `flow: "xtls-rprx-vision"` несовместим с redirect/tproxy mode на принятых сокетах
- Без flow — VLESS не соединяется (сервер требует xtls-rprx-vision)
- С flow — Xray падает `failed to set IP_TRANSPARENT` для redirect mode
- **Итог:** tproxy redirect mode + xtls-rprx-vision = incompatible
**Текущее состояние iptables на vpn-srv:**
- `TV_REDIRECT` в nat PREROUTING — REDIRECT src 192.168.4.0/24 tcp → port 12345
- `REDSOCKS_HA` в nat PREROUTING — REDIRECT src 192.168.2.0/24 tcp → port 12350 (redsocks → SOCKS5 1080)
- `MASQUERADE` для 192.168.2.0/24 и 192.168.4.0/24 в POSTROUTING
**Xray config текущий:**
- flow: `xtls-rprx-vision` (ВОССТАНОВЛЕН)
- loglevel: debug
- tproxy-in: port 12345, mode redirect
- HTTP proxy: 8888, SOCKS5: 1080
**Что работает:** HTTP proxy (8888) и SOCKS5 (1080) через Xray → VLESS → работают (проверено curl 200)
---
### Задача #2: HA Telegram через SOCKS5 прокси
**HA:** `ha.homenet542.keenetic.pro`, IP 192.168.2.139, HAOS 17.1, gateway → Keenetic (192.168.2.1)
**SSH доступ к HA:** через vpn-srv → HA SSH add-on
```
ssh -i /tmp/ha_key -o StrictHostKeyChecking=no root@192.168.2.139
```
(ha_ssh_key скопирован на vpn-srv как /tmp/ha_key)
**Что сделали:**
- Добавили в `/homeassistant/configuration.yaml` блок telegram_bot с `proxy_url: socks5://192.168.2.200:1080`
- Удалили UI-configured config entry (01K6SDHYX559FSXC1M25ATSSYE)
- Перезапустили HA Core
- `notify.telegram_notifier` появился, `telegram_bot/send_message` → HTTP 200 ✅
**Бот:** `ha542_bot`, token: `8251509944:AAGkRr_5ZIIQNd4XrlI5QI9DYZS8JUPhcxY`
**❗ ЗАМЕЧАНИЕ Славы (голосовое, 14:44 UTC):**
- Через прокси должен ходить ТОЛЬКО Telegram, не весь трафик HA
- Прокси для Telegram настраивается через UI интеграции в HA (не через кастомные компоненты)
- Нужно найти proxy_url настройку в UI telegram_bot интеграции
- Текущая YAML-конфигурация может быть корректной (proxy_url только для telegram_bot), но нужно проверить
**Статус на 15:00 UTC:** Telegram работает через SOCKS5, но Слава указал что подход должен быть через UI. Нужно уточнить.
---
### SSH доступ к инфраструктуре (актуально)
- **vpn-srv:** `ssh -i /home/node/.openclaw/ha_ssh_key -o StrictHostKeyChecking=no -p 3322 vpn@185.130.212.192`
- **HA (через vpn-srv):** `ssh -i /tmp/ha_key root@192.168.2.139` (с vpn-srv)
- **mva154:** `ssh -i /home/node/.openclaw/ha_ssh_key slin@82.22.50.71`
### Конфиги
- Xray: `/etc/xray/config.json` (bak5 = последний бэкап до удаления flow, bak3/bak4 старые)
- iptables: `/etc/iptables/rules.v4` (outdated — не пересохранены после сегодняшних изменений!)
- HA config: `/homeassistant/configuration.yaml` (бэкап: `.bak-20260410-XXXXXX`)
### TODO
- [ ] Сохранить текущие iptables rules.v4 (сегодняшние изменения не сохранены!)
- [ ] Проверить как настраивается proxy в UI telegram_bot интеграции
- [ ] Либо оставить YAML-config с proxy_url (только Telegram через прокси), либо вернуть UI с proxy
- [ ] Задача Wi-Fi tproxy для 192.168.4.0/24 — остаётся незакрытой
---
## Задача #2 ЗАВЕРШЕНА — 15:25 UTC
**HA Telegram через VLESS работает!** Слава подтвердил получение сообщений.
**Финальная конфигурация:**
- UI-интеграция telegram_bot с `proxy_url: socks5://192.168.2.200:1080`
- Только Telegram через прокси, остальное напрямую
- Config entry ID: `01KNVZDDM3ZNJS1WX309K7E1EN`
- Notify entity: `notify.telegram_bot_8251509944_126472752`
**Задокументировано в:** `tasks/proxy-vm/PROJECT.md`
**Задача #1** (Wi-Fi transparent proxy) продолжится когда Слава вернётся домой.
````
## Notes
<!-- openclaw:human:start -->
<!-- openclaw:human:end -->
## Related
<!-- openclaw:wiki:related:start -->
- No related pages yet.
<!-- openclaw:wiki:related:end -->