Illya·Lily·Iris·Alice

Hermes Memory System：从 MEMORY.md 到认知记忆治理层的 10 版演化

Sat, 01 Aug 2026 00:00:00 GMT

Hermes Memory System：从 MEMORY.md 到认知记忆治理层的 10 版演化

前言

这是 Hermes Agent 系列的第四篇文章。

第一篇：构建个人 AI 工程知识操作系统 — 记忆分层架构
第二篇：多模型路由架构演化 — v1→v3 路由
第三篇：可观测 AI 系统 — task-memory + trace + 经验闭环
第四篇（本文）：Memory System v1.0→v1.41 演化 — 冲突解决 + 权限治理 + 实体图谱 + 检索引擎

本文记录 Hermes Agent 的记忆系统从简单的 MEMORY.md 文件，经过 10 个版本迭代，演化为一个带权限治理、来源链审计、时间版本、实体图谱和意图感知检索的认知记忆层的过程。

起点：为什么需要 Memory System

Hermes Agent 原来使用 MEMORY.md 存储用户事实，存在五个核心问题：

无时间戳 — 无法判断过期
无可信度标记 — 事实和推测混在一起
无冲突解决 — 多来源矛盾时无裁决依据
无过期机制 — 老旧条目永久占空间
无冷冻机制 — 关键条目可能被意外覆盖

演化路线

v1.0  能记东西
 ↓
v1.1  会冲突检测
 ↓
v1.2  会生命周期管理（持久化 + decay）
 ↓
v1.3  会排序（Memory Ranking Engine）
 ↓
v1.35 会权限和实体（authority + entity/field）
 ↓
v1.36 会不可变保护（IMMUTABLE_TYPES）
 ↓
v1.37 会混合评分（authority_gate × 加权和）
 ↓
v1.38 会来源审计（provenance + scope 隔离）
 ↓
v1.39 会时间记忆（valid_from/until + memory_layer）
 ↓
v1.40 会检索（Query Planner + GC + EntityGraph）
 ↓
v1.41 会意图感知 + 预算管理（Intent Detection + Budget）

核心架构（v1.41 最终状态）

MemoryEntry 数据模型

class MemoryEntry:
    value              # 内容
    memory_type        # IDENTITY / FACT / PREFERENCE / SKILL / PROJECT / TEMP
    memory_layer       # EPISODIC / SEMANTIC / PROCEDURAL / IDENTITY / TEMPORARY
    authority          # user=1.0 / tool=0.6 / agent=0.3
    source             # 来源（与 authority 分离）
    confidence         # 0.0-1.0
    explicitness       # 0.0-1.0
    freshness          # 基于 decay_days 自动衰减
    retention          # freshness×0.5 + usage×0.3 + confidence×0.2
    provenance[]       # 来源链审计（可追溯用户原始陈述）
    valid_from         # 记忆生效时间
    valid_until        # 记忆失效时间（supersede 时自动关闭）
    entity             # 实体名（如 NAS、GPU、OS）
    field              # 属性名（如 ip、model、system）
    scope              # 范围隔离（如 main_pc、laptop）
    relation           # 实体关系（如 located_at）
    target             # 关系目标（如 home_network）
    relation_confidence
    identity_status    # ACTIVE / CONFIRMED / CHANGED / ARCHIVED
    usage_count        # 被引用次数（影响 retention）
    change_reason      # 变更原因
    supersedes         # 前任 memory_id
    superseded_by      # 继任者
    conflict_with      # 冲突条目

评分公式

score = authority_gate × (
    0.4 × confidence
  + 0.2 × freshness
  + 0.2 × explicitness
  + 0.1 × retention
  + 0.1 × usage_frequency
)

authority_gate 是一个门控函数：

权限级别	权重	gate
user	1.0	1.0
tool	0.6	0.7
agent	0.3	0.4
unknown	0.0	0.1

这确保了：外部信息（网页、模型推理）永远无法覆盖用户确认的事实，即使外部信息的 confidence/freshness 全部为 1.0。

冲突解决管道

用户输入
  ↓
Assertion Parser（解析断言类型）
  ├── CONFIRMED    → 明确事实
  ├── HYPOTHETICAL → 假设，不写入
  ├── UNCERTAIN    → 可能/应该/觉得
  ├── RECALL       → 我记得
  ├── QUERY        → 提问，不产生 memory
  └── REFERENCE    → 保持，不改变
  ↓
Intent Detection（是否为更新意图）
  ↓
Authority Check（权限检查）
  ├── IDENTITY 保护：非 user 权限不可修改
  └── authority_gate 评分门控
  ↓
Conflict Detection（冲突检测）
  ├── scope 隔离：main_pc vs laptop 不冲突
  ├── score 比较：新分数 > 旧分数才允许覆盖
  └── 权限门控：agent 永远无法超越 user
  ↓
Decision（决策）
  ├── supersede        → 新值替代旧值，保留历史链
  ├── supersede_frozen → 用户确认覆盖 FROZEN
  ├── flag_conflict    → 保留双方，请求用户确认
  ├── reject           → 拒绝写入
  └── no_op            → 无操作
  ↓
Memory Write（写入）
  ├── provenance 自动传播（继承旧链 + 追加新条目）
  ├── memory_layer/scope/entity 继承
  └── valid_until 自动关闭旧版本

记忆生命周期

ACTIVE → STALE → COMPRESSED → ARCHIVED
  ↑                        ↓
  └── TEMP 高频使用 → EPISODIC（自动升级）

关键设计：从不删除。TEMPORARY 如果被高频引用，自动升级为 EPISODIC。

意图感知检索

class MemoryQueryPlanner:
    # 检测查询意图
    intents = {
        "WHOAMI":      "我是/我的"       → IDENTITY 层权重提升
        "HOWTO":       "怎么/如何/安装"   → PROCEDURAL 层权重提升
        "FACT_LOOKUP": "是什么/是多少"    → SEMANTIC 层权重提升
        "DIAGNOSE":    "为什么/报错/失败" → EPISODIC 层权重提升
        "TEMPORAL":    "什么时候/历史/之前" → EPISODIC 层权重提升
    }

    # 检索评分
    retrieval_score = (
        0.35 × keyword_match
      + 0.25 × authority
      + 0.15 × freshness
      + 0.15 × scope_match
      + 0.10 × layer_priority
    )

    # Token 预算控制
    budget = {
        IDENTITY: 1000, SEMANTIC: 3000,
        PROCEDURAL: 2000, EPISODIC: 1000, TEMPORARY: 500
    }
    # 按意图动态调整

关键设计决策

1. 来源与权限分离

信息来源（source）和修改权限（authority）是两个独立维度：

source	authority
用户输入	user
FTS5 检索	tool
OpenViking	tool
传感器	tool
网页搜索	agent
模型推理	agent

这样设计的好处：用户提供的网址（source=web）仍然是 user 权限，不会被降级。

2. IDENTITY 不可变保护

IDENTITY 类型的记忆（如”用户使用 Debian”）不能被网页或模型推理覆盖。只有 user 权限的明确修改意图才能 supersede。

这防止了 Agent 最容易犯的错误：自己推理出来的信息污染用户画像。

3. Provenance 自动传播

每次 supersede 时，新记忆自动继承旧记忆的 provenance 链，并追加当前变更记录。调用者不传 provenance 也不会断链。

Arch (ACTIVE)
  ├── provenance[0]: user said "I use Debian" (2026-07-01)
  └── provenance[1]: user changed OS to Arch (2026-07-31)

这使 Agent 可以回答：“为什么认为你使用 Arch？” → “因为你在 2026-07-31 明确说 OS 改成 Arch”。

4. Scope 隔离

GPU.model = 7650GRE  (scope=main_pc)
GPU.model = RTX3060  (scope=laptop)

不再冲突。find_active(entity, field, scope) 支持范围过滤。

5. 时间版本

Debian  valid_from=2025-01  valid_until=2026-07-31
  ↓ supersede
Arch    valid_from=2026-07-31  valid_until=NULL

可以回答：“我什么时候开始用 Arch？” → “2026-07-31”。

6. Memory Layer 分类

Layer	用途	例子
IDENTITY	长期身份	我使用 Debian 13
SEMANTIC	事实知识	7650GRE 参数
PROCEDURAL	技能流程	Docker 安装步骤
EPISODIC	事件	昨天修复 grub
TEMPORARY	短期状态	正在测试 OTA

测试验证

15 个测试案例，覆盖：

批次	案例	场景
第一批 A-E	用户确认/假设/FROZEN/冲突/FTS5覆盖	基础冲突解决
第二批 F-J	不确定/提问/确认/废弃/保持	语义压力测试
第三批 K-N	重启恢复/示例误写入/重复确认/过期decay	生命周期测试
第四批 O	CONFIRMED 无 update_intent 不覆盖 FROZEN	权限安全

全部 15/15 PASS。

与普通 RAG 的区别

普通 RAG：

文档 → Embedding → Search → Answer

Hermes Memory System：

观察
  → Assertion Parser（断言分类）
  → Authority Check（权限检查）
  → Conflict Resolver（冲突解决）
  → Ranking（评分排序）
  → Consolidation（记忆合并）
  → Entity Graph（实体图谱）
  → Intent-aware Retrieval（意图感知检索）
  → Token Budget（预算控制）
  → Context Injection（上下文注入）
  → Reasoning（推理）

下一阶段：v1.42 Hybrid Retrieval

v1.41 已冻结为基线。下一步不是继续堆字段，而是：

Entity Normalization（最高优先级）— “显卡” = “GPU” = “7650GRE”
Hybrid Retrieval — keyword + vector + entity graph
多标签 Intent — 一个查询可以同时是 FACT_LOOKUP + WHOAMI
value_per_token — relevance × authority × freshness ÷ token_cost
模块化拆分 — 1020 行单文件拆为 memory/ 包

策略：先让 Memory System 在真实任务中运行，收集 retrieval_success / retrieval_failure 数据，用真实失败样本驱动 v1.42 迭代。

文件清单

文件	说明
`~/.hermes/lib/memory_conflict_resolver.py`	核心引擎（~1020 行）
`~/.hermes/scripts/memory_lifecycle_v1.2_test.py`	15 个测试案例
`~/.hermes/plugins/experience-recorder/`	Hook 自动记录插件
`~/.hermes/skills/meta/experience-recorder/`	分类规则 Skill
`~/.hermes/skills/meta/memory-lifecycle-rules/`	生命周期规则 Skill
`~/.hermes/task-memory/raw/*.jsonl`	任务记忆原始日志
`~/.hermes/failure-memory.md`	失败记录
`~/.hermes/traces/`	完整 trace 文件

总结

从 v1.0 到 v1.41，Hermes Memory System 经历了：

v1.0：能记东西
v1.2：会生命周期管理
v1.3：会排序
v1.37：会混合评分（authority gate）
v1.39：会时间记忆和来源审计
v1.41：会意图感知检索和预算控制

已经从一个简单的 MEMORY.md 文件，演化为一个接近认知科学记忆模型的长期记忆治理层。

下一步的重点不是继续增加规则，而是让系统在真实任务中产生数据，用失败案例驱动迭代。这比理论优化更重要。

Hermes 个人 AI 工程系统 v1.0：从零搭建到可观测认知架构的完整记录

Sat, 01 Aug 2026 00:00:00 GMT

Hermes 个人 AI 工程系统 v1.0

这不是一篇配置教程，而是一个关于如何让 AI 记住你、理解你、并越用越聪明的工程记录。

前言

我日常使用 Hermes Agent 处理系统架构设计、NAS 运维、家庭能源系统规划、代码编写等任务。但几个月下来，暴露了一个核心问题：AI 没有长期记忆。每次问同一个问题，它都从零开始推理。不会记住我的设备参数，不会记住之前的决策，不会从历史经验中学习。

解决这个问题需要一套完整的工程系统，而不是单一工具。经过连续多日的迭代，这套系统从”配置多个模型”正式进入 v1.0 阶段。

本文是对四篇系列文章的完整整合，一次性呈现这套系统的全貌。

系统总览

┌─────────────────────────────────────────────────────────────┐
│                    Hermes 个人 AI 工程系统 v1.0               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Layer 1: 行为准则 (SOUL.md)                         │   │
│  │  实事求是、调查研究、矛盾分析、系统思维、控制论        │   │
│  │  反馈闭环、假设验证、工程优先                         │   │
│  └─────────────────────────────────────────────────────┘   │
│                            │                                 │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Layer 2: 专业技能 (Skills)                          │   │
│  │  knowledge-retrieval-evidence-policy                 │   │
│  │  decision-memory / model-router v3                   │   │
│  │  memory-lifecycle-rules / experience-recorder        │   │
│  └─────────────────────────────────────────────────────┘   │
│                            │                                 │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Layer 3: 持久事实 (MEMORY.md + USER.md)             │   │
│  │  用户偏好、设备参数、环境信息、已验证的长期经验        │   │
│  └─────────────────────────────────────────────────────┘   │
│                            │                                 │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Layer 4: 知识库 (OpenViking)                        │   │
│  │  resources: 工程控制论/系统科学/软件工程/方法论       │   │
│  │  memories: 决策记录/历史案例/架构模式                │   │
│  └─────────────────────────────────────────────────────┘   │
│                            │                                 │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Layer 5: 多模型路由 (Model Router)                  │   │
│  │  Flash(主控制器) + Pro(审查) + GLM(专家) + Doubao(视觉)│   │
│  └─────────────────────────────────────────────────────┘   │
│                            │                                 │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Layer 6: 可观测性 (Observability)                   │   │
│  │  task-memory / failure-memory / trace / batch test  │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

第一章：为什么需要记忆系统

起点

Hermes Agent 原本只靠 MEMORY.md 存储用户事实，存在五个核心问题：

问题	后果
无时间戳	无法判断过期
无可信度标记	事实和推测混在一起
无冲突解决	多来源矛盾时无裁决依据
无过期机制	老旧条目永久占空间
无冷冻机制	关键条目可能被意外覆盖

关键问题：AI 没有长期记忆

举一个典型例子：测试中 AI 把”三电压逆变器”理解成”48V DC + 220V AC + 电网”，但实际是电池侧兼容 48V/60V/72V 三种电压。原因是模型用通用知识推测，没有优先尊重用户 memory 中已记录的设备事实。

这说明：再强的模型，如果不尊重用户已有事实，输出也是错的。

第二章：知识库搭建（OpenViking）

选型对比

方案	优势	劣势
Supermemory	自带 OCR、Gemini 提取	太重（PyTorch ~2GB），ARM64 慢
knowledge-base-mcp	MCP 协议，Claude 兼容	同样太重，ARM64 1 chunk/s
OpenViking 0.4.11	轻量 Go 二进制，FTS5 全文搜索，ARM64 飞快	无 OCR，需手动组织知识

最终选择 OpenViking。纯 Go 编译，无 Python 依赖，在 ARM64 上毫秒级响应。

知识分类

viking://resources/rag/
├── engineering_control/    — 《工程控制论》上下册
├── history_politics/       — 毛选等（方法论层）
├── software_engineering/   — 《人月神话》等
└── systems_thinking/       — 《一般系统论》《系统科学方法概论》

知识检索策略

创建 knowledge-retrieval-evidence-policy skill，强制规则：

事实优先于推测 — 用户 memory 中的设备参数 > 模型通用知识
未知参数必须标记 — 不允许自行补全，列出条件分支
检索在推理之前 — 复杂问题先查知识库，再推理

优先级链：

当前用户明确提供的事实 > 用户已验证的长期事实 > 当前环境实际检测结果
> 官方文档与可靠资料 > 知识库专业知识 > 一般经验 > 推测与假设

第三章：记忆系统从 v1.0 到 v1.41 的演化

演化路线

v1.0  能记东西
 ↓
v1.1  会冲突检测
 ↓
v1.2  会生命周期管理（持久化 + decay）
 ↓
v1.3  会排序（Memory Ranking Engine）
 ↓
v1.35 会权限和实体（authority + entity/field）
 ↓
v1.36 会不可变保护（IMMUTABLE_TYPES）
 ↓
v1.37 会混合评分（authority_gate × 加权和）
 ↓
v1.38 会来源审计（provenance + scope 隔离）
 ↓
v1.39 会时间记忆（valid_from/until + memory_layer）
 ↓
v1.40 会检索（Query Planner + GC + EntityGraph）
 ↓
v1.41 会意图感知 + 预算管理（Intent Detection + Budget）

v1.41 核心架构

MemoryEntry 数据模型 — 20+ 维度，包括：value、entity、field、scope、authority、confidence、provenance、valid_from/until、memory_layer、identity_status 等。

评分公式：

score = authority_gate × (
    0.4 × confidence
  + 0.2 × freshness
  + 0.2 × explicitness
  + 0.1 × retention
  + 0.1 × usage_frequency
)

权限门控：

权限级别	权重	gate
user	1.0	1.0
tool	0.6	0.7
agent	0.3	0.4
unknown	0.0	0.1

外部信息（网页、模型推理）永远无法覆盖用户确认的事实。

冲突解决管道：用户输入 → Assertion Parser（CONFIRMED/HYPOTHETICAL/UNCERTAIN/RECALL/QUERY/REFERENCE）→ Intent Detection → Authority Check → Conflict Detection → Decision（supersede/flag_conflict/reject）→ Memory Write

记忆生命周期：ACTIVE → STALE → COMPRESSED → ARCHIVED。从不删除，TEMPORARY 高频使用自动升级为 EPISODIC。

意图感知检索：根据查询意图（WHOAMI/HOWTO/FACT_LOOKUP/DIAGNOSE/TEMPORAL）动态调整各记忆层权重，以匹配度 × 权限 × 新鲜度 × 范围匹配 × 层优先级综合评分。

关键设计决策

来源与权限分离 — 信息来源（source）和修改权限（authority）是两个独立维度。用户提供的网址（source=web）仍然是 user 权限，不会被降级。
IDENTITY 不可变保护 — 用户身份/偏好不能被网页或模型推理覆盖。
Provenance 自动传播 — 每次 supersede 自动继承旧链并追加新记录。
Scope 隔离 — main_pc 和 laptop 的同属性不同值不冲突。
时间版本 — 每次变更保留 valid_from/valid_until 历史链。

测试验证

15 个测试案例，覆盖基础冲突解决、语义压力测试、生命周期测试、权限安全测试，全部 15/15 PASS。

第四章：多模型路由架构

问题

Hermes 只有一个主模型，但日常问答、复杂架构设计、图片识别对模型能力要求不同。

可用模型池

模型	角色	资源等级
DeepSeek V4 Flash	主模型 + Router + 整合者	快速
DeepSeek V4 Pro	审查 + 增强	增强
GLM-5.2	深度推理专家	深度
Doubao Seed 2.0 Pro	视觉	专用

架构演化（v1 → v2 → v3）

v1（关键词触发）：看到”架构”→ delegate，看到”状态机”→ delegate。问题：误触发，过拟合。

v2（三级任务分级）：Level 0（Flash）→ Level 1（Flash+Pro）→ Level 2（GLM）。改进：从关键词升级为按复杂度分级。遗留：GLM 直接输出给用户，无用户覆盖。

v3（三级路由 + 专家回流 + 用户覆盖） — 当前冻结版本：

                User Request
                     │
                     ▼
          DeepSeek V4 Flash
          Router + Orchestrator
                     │
        ┌────────────┼────────────┐
        │            │            │
        ▼            ▼            ▼
     Level 0      Level 1      Level 2
     Flash       Flash+Pro      GLM-5.2
        │            │            │
        │            │            │
        ▼            ▼            ▼
    简单任务      审查增强      专家设计
                     │
                     ▼
              Flash 整合输出

核心规则：

GLM 是专家，不直接面对用户，输出必须回流 Flash 验证+整合
用户明确指定模型时覆盖自动路由
先查 OpenViking 知识库，再决定是否 delegate
预估 <1000 tokens 且无架构/安全需求时不 delegate
资源等级替代成本等级（避免 API Plan 价格变化导致错误）

完整决策树

Step 1: 用户指定了模型？ → 尊重用户选择
Step 2: 包含图片？ → Doubao Vision（自动）
Step 3: 有 OpenViking 知识？ → 先检索
Step 4: 复杂度评估
Step 5: 路由（Level 0/1/2）

配置实现

model:
  default: deepseek-v4-flash
  provider: custom

delegation:
  model: glm-5.2
  provider: custom

auxiliary:
  vision:
    model: doubao-seed-2-0-pro-260215
    base_url: "https://ark.cn-beijing.volces.com/api/coding/v3"
    timeout: 120
  compression:
    model: deepseek-v4-pro
  background_review:
    model: deepseek-v4-pro
  curator:
    model: deepseek-v4-pro

第五章：可观测 AI 系统

三个阶段

阶段1: 工具调用 Agent → 能调用工具，但每次独立决策，无记忆
阶段2: 多模型 Agent → 多模型分工，规则路由，有记忆分层
阶段3: 可观测 AI 系统 → 有日志，有版本，有实验，有回滚，有失败分析
阶段4: 经验驱动 AI 系统（未来）→ 基于积累数据自动优化路由

内存生命周期规则

7 类可信度标记：

标记	含义	TTL
CONFIRMED ✅	用户确认的事实	30-90 天
OBSERVED 📋	自动探测的信息	30 天
DERIVED 🔄	推理得出的结论	14 天
SPECULATIVE ❓	猜测，未验证	1 天
STALE ⌛	已过期	保留 7 天后移除
CONFLICTED ⚠️	多个来源不一致	待裁决
FROZEN 🧊	用户锁定，永不覆盖	永久

冲突优先级：来源可信度 > 存储位置。用户今天说的 CONFIRMED 事实，优先级高于旧 MEMORY.md 记录。

三层记忆职责边界

层	存储	职责
MEMORY.md / USER.md	高频事实	系统 prompt 自动注入，零延迟
OpenViking	语义知识	长期知识、决策、经验、架构模式
FTS5 (session_search)	原始对话	全文检索历史对话，兜底

交叉检索策略：先查 MEMORY → 再查 OpenViking → 最后查 FTS5。

Task-Memory 和 Failure-Memory

Task-Memory 记录每次路由决策的完整信息：任务类型、复杂度评分、路由判断、使用模型、耗时、token、结果摘要。

Failure-Memory 记录每次失败的根本原因和修复方案：

ID	类型	原因	修复
F001	CONFIG	delegation.provider 指向不存在的 provider	修复为 volcengine-coding-plan
F002	TOOL	GLM 子任务执行过多环境探测，600s 超时	Flash 在 delegate 前完成检索
F003	TOOL	web_search 依赖缺失，子任务花时间安装	delegate context 预装依赖
F004	CONFIG	auxiliary.provider 同样指向不存在的 provider	统一切换 provider

Batch Test v1

任务	等级	模型	耗时	结果
什么是 MQTT broker	Level 0	Flash	0.5s	正确路由
查 NAS IP	Level 0	Flash	0.5s	正确路由
写光伏效率函数	Level 1	Flash	0.5s	正确路由
审查 HA MQTT 配置	Level 1	Pro	52s	正确路由，发现 9 项风险
设计 15 状态机	Level 2	GLM	419s	正确路由，36KB 设计文档
对比 MQTT vs Modbus	Level 2	GLM	102s	正确路由，18K 字符深度分析

路由正确率：6/6。样本量小，需扩充到 20-50。

关键发现

配置错误导致静默失败 — delegation.provider 未配置 API key，所有 delegate 任务静默失败
GLM 子任务执行过剩环境探测 — 600 秒中大部分时间花在 session_search、execute_code 等环境探测上
1000-token 阈值无数据支撑 — 拍脑袋的，需要更多样本
Flash 同时作为路由器和审查者是循环依赖 — v4 目标：引入 Pro 作为独立审查者

第六章：经验教训

架构原则

分层比堆叠重要 — 把行为准则、知识、事实、技能分开，比往一个文件里塞更多内容有效
事实约束比模型能力重要 — 再强的模型，如果不尊重用户已有事实，输出也是错的
轻量方案优先 — ARM64 上跑 PyTorch 是不归路，FTS5 全文搜索足够快
AI Agent 需要反馈闭环 — 一次回答不够，需要设计验证、修正、迭代的机制

路由设计教训

不要用关键词触发路由 — 容易误触发，趋向过拟合
Flash 是大脑，不是最低级模型 — 它负责判断和整合，不是替代品
GLM 不直接面对用户 — 专家输出必须经过主模型验证和整合
成本等级不要硬编码 — 不同 API Plan 价格不同，用资源等级替代
先查知识库再 delegate — 充分利用已有知识，避免不必要的专家调用
规则路由是起点，经验路由是终点 — 先跑数据，再做自适应

第七章：当前状态与下一阶段

v1.0 冻结清单

model-router v3 (frozen-baseline)
  ├── 三级路由：Level 0 (Flash) / Level 1 (Flash/Pro) / Level 2 (GLM)
  ├── 固定分工：视觉 → Doubao，审查 → Pro，压缩 → Pro
  └── 用户覆盖：用户指定模型时跳过自动路由

memory-lifecycle-rules v1
  ├── 7 类可信度标记
  ├── 5 类生命周期规则
  ├── 三层记忆职责边界
  └── 冲突优先级：来源可信度 > 存储位置

memory_conflict_resolver v1.41
  ├── ~1020 行 Python 核心引擎
  ├── 15/15 测试通过
  ├── 意图感知检索 + Token 预算控制
  └── 冻结，等待真实数据驱动迭代

task-memory / failure-memory (observation only)
  └── 不自动影响路由，仅收集数据

experience-recorder (Python plugin)
  └── hook 自动触发，不依赖模型遵守规则

4 个观察指标

指标	目标	说明
路由准确率	逐步提升	任务→路由→结果质量评分
GLM 调用比例	5-15%	超过 30% 说明 Router 太激进
升级失败案例	重点收集	Flash 不足→用户追问→GLM 解决的案例
决策稳定性	同类任务一致	避免同类型任务反复切换模型

理想模型分配

Flash:  70-85%
Pro:    10-20%
GLM:     5-15%
Doubao: 按需

下一阶段方向

v1.42 Memory System（不急着写，先收集真实数据）：

Entity Normalization（最高优先级）— “显卡” = “GPU” = “7650GRE”
Hybrid Retrieval — keyword + vector + entity graph
多标签 Intent
value_per_token budget
模块化拆分（1020 行单文件拆为 memory/ 包）

v4 路由（暂不实现）：

Flash = Orchestrator
GLM = Design Expert
Pro = Independent Reviewer
Doubao = Vision
经验驱动路由替代规则驱动

文件清单

文件	说明
`~/.hermes/lib/memory_conflict_resolver.py`	核心引擎（~1020 行）
`~/.hermes/scripts/memory_lifecycle_v1.2_test.py`	15 个测试案例
`~/.hermes/plugins/experience-recorder/`	Hook 自动记录插件
`~/.hermes/skills/meta/model-router/`	三级路由规则
`~/.hermes/skills/meta/experience-recorder/`	分类规则 Skill
`~/.hermes/skills/meta/memory-lifecycle-rules/`	生命周期规则 Skill
`~/.hermes/skills/meta/knowledge-retrieval-evidence-policy/`	事实约束规则
`~/.hermes/task-memory/raw/*.jsonl`	任务记忆原始日志
`~/.hermes/failure-memory.md`	失败记录
`~/.hermes/traces/`	完整 trace 文件

结语

这套系统现在已经从”配置多个模型”进入”个人 AI 工程系统”的阶段。

当前阶段的成功标准不是路由更复杂，而是：

每一次决策都有记录
每一次失败都有原因
每一次改进都有依据

下一步的重点不是继续增加规则，而是让系统在真实任务中产生数据，用失败案例驱动迭代。这比理论优化更重要。

已从”配置 AI”进入”培养 AI”阶段。

构建个人 AI 工程知识操作系统：Hermes + OpenViking 多层记忆架构实践

Fri, 31 Jul 2026 00:00:00 GMT

构建个人 AI 工程知识操作系统：Hermes + OpenViking 多层记忆架构实践

背景

我日常使用 Hermes Agent（Nous Research 开源）作为 AI 助手，处理系统架构设计、NAS 运维、家庭能源系统规划、代码编写等任务。但几个月下来，暴露了一个核心问题：AI 没有长期记忆。

每次问同一个问题，它都从零开始推理。不会记住我的设备参数、不会记住之前的决策、不会从历史经验中学习。

解决这个问题需要一套完整的记忆架构，而不是单一工具。这篇博客记录了过去几天的优化过程。

一、知识库搭建：OpenViking

选型

对比了几个方案：

方案	优势	劣势
Supermemory	自带 OCR、Gemini 提取	太重（PyTorch ~2GB），ARM64 慢，需自建服务
knowledge-base-mcp	MCP 协议，Claude 兼容	同样太重（PyTorch + BGE-M3 ~4GB），ARM64 1 chunk/s
OpenViking	轻量（Go 二进制），本地文件系统索引，FTS5 全文搜索	无 OCR，需要手动组织知识

最终选择 OpenViking 0.4.11。原因：纯 Go 编译，无 Python 依赖，在 ARM64 上跑得飞快，FTS5 搜索毫秒级响应。

知识分类

将知识库按领域划分：

viking://resources/rag/
├── engineering_control/    — 《工程控制论》上下册
├── history_politics/       — 毛选等（方法论层）
├── software_engineering/   — 《人月神话》等
└── systems_thinking/       — 《一般系统论》《系统科学方法概论》

核心是 工程控制论 + 系统科学，作为解决复杂工程问题时的知识来源。

Hermes 集成

配置 Hermes 的 memory provider 为 OpenViking，并启用 OPENVIKING_RECALL_RESOURCES=true，让 Hermes 在遇到复杂问题时自动检索知识库：

memory:
  provider: openviking

二、多层记忆架构

Hermes 的长期记忆系统设计为四层，各司其职：

Layer 1: SOUL.md（行为准则）
  ├── 实事求是、调查研究、矛盾分析
  ├── 系统思维、控制论、工程优先
  └── 反馈闭环、假设验证

Layer 2: Skills（怎么做）
  ├── knowledge-retrieval-evidence-policy
  ├── decision-memory
  └── 各领域专业技能

Layer 3: USER.md + MEMORY.md（事实）
  ├── 用户偏好、设备参数、环境信息
  └── 已验证的长期经验

Layer 4: OpenViking（知识 + 经验）
  ├── 工程控制论、系统科学
  ├── 软件工程、项目管理
  └── 决策记录、历史案例

关键原则：不要把知识往 SOUL.md 里堆。SOUL.md 是行为准则，不是知识库。知识归知识库，事实归 memory，做法归 skills。

三、知识检索策略优化

发现的问题

测试中暴露了一个典型错误：AI 把”三电压逆变器”理解成”48V DC + 220V AC + 电网”，但实际是电池侧兼容 48V/60V/72V 三种电压。

原因是：模型用通用知识推测，没有优先尊重用户 memory 中已记录的设备事实。

解决方案

创建 knowledge-retrieval-evidence-policy skill，强制以下规则：

事实优先于推测 — 用户 memory 中的设备参数 > 模型通用知识
未知参数必须标记 — 不允许自行补全，列出条件分支
检索在推理之前 — 复杂问题先查知识库，再推理

结果：下次测试时，Hermes 正确识别了三电压逆变器的含义，并主动询问未知参数，而不是自行假设。

四、家庭能源系统设计

跨领域测试

作为知识库效果验证，设计了一套家庭能源管理系统。Hermes 在这个过程中主动调用了 OpenViking 中的工程控制论和系统科学知识，完成了跨领域综合。

四层架构

L4: 米家智能家居层 — 非关键负载控制
L3: HA 能源管理层 — 状态机、能量调度、SOC 管理
L2: 逆变器控制层 — MPPT、EPS 切换、电池检测
L1: 硬件保护层 — 断路器、SPD、熔断器（纯物理）

15 状态机

覆盖无电池、电池怠速、PV 充电、PV 自用、余电上网、电网充电、削峰放电、多级停电、换电池、故障、手动接管等场景。

租赁电池的特殊性

用户电池不是固定购买，而是临时租赁。这意味着系统必须支持：

无电池状态：PV 自发自用，余电上网
电池接入检测：自动识别 48V/60V/72V，无需 BMS 通信
换电池不停机：热插拔支持

停电备用

电气切换由逆变器硬件 EPS 完成（<20ms），HA 负责 30s 后管理非关键负载，不承担毫秒级安全切换。

五、多模型路由配置

问题

Hermes 只有一个主模型。但日常问答、复杂架构设计、图片识别对模型能力要求不同。全部用最强模型浪费 token，全部用最便宜模型质量不够。

方案

利用 Hermes 的 auxiliary 和 delegation 机制，实现多模型分工：

                    Hermes
                       │
           DeepSeek V4 Flash（主模型）
           日常对话、RAG、工具调用、记忆管理
                       │
          ┌──────────────┼──────────────┐
          │              │              │
          ▼              ▼              ▼
       GLM-5.2      DeepSeek V4 Pro  Doubao Seed 2.0 Pro
       ─────────     ─────────────     ─────────────────
       子任务         压缩             vision_analyze
       delegate      后台审查          OCR/截图/电路图
                     策展

配置

model:
  default: deepseek-v4-flash
  provider: custom

delegation:
  model: glm-5.2          # 子任务自动走 GLM
  provider: custom

auxiliary:
  vision:
    model: doubao-seed-2-0-pro-260215
    base_url: "https://ark.cn-beijing.volces.com/api/coding/v3"
    timeout: 120
  compression:
    model: deepseek-v4-pro   # 压缩质量优先，不丢关键约束
  background_review:
    model: deepseek-v4-pro
  curator:
    model: deepseek-v4-pro

限制：delegation.model 是”所有子任务固定走 GLM”，不是智能路由。Hermes 目前没有内置根据任务难度自动切换模型的能力。

六、清理与取舍

放弃的方案

过去几个月尝试过的一些路线，最终都放弃了：

项目	放弃原因	替代方案
knowledge-base-mcp	PyTorch ~2GB + BGE-M3 ~2.2GB，ARM64 极慢	OpenViking FTS5
Supermemory	同样太重，Gemini 配额限制每天 20 次	直接放弃，改为 OpenViking
lottery-agent（彩票分析）	不再需要	已删除

清理命令

rm -rf ~/knowledge-base-mcp ~/kb-mcp-server
rm -rf ~/lottery-agent

七、三层系统整合

NAS、AI Agent、家庭能源系统形成三层架构：

Layer A: AI Agent（智能决策层）
  ├── HA API 读取能源状态
  ├── SSH 管理 NAS 服务
  ├── cron 定时任务（日报/异常检测）
  └── OpenViking 知识库

Layer B: NAS（基础设施层）
  ├── 数据存储（InfluxDB/SQLite）
  ├── Grafana 可视化
  ├── nginx 反向代理
  └── Ghost 博客

Layer C: HA 能源管理层
  ├── 状态机执行
  ├── 逆变器 Modbus 通信
  ├── 米家设备集成
  └── SOC 管理 / 负载调度

总结

当前状态

组件	评分
SOUL.md（行为准则）	8.5/10
OpenViking 知识库	8/10
知识分类	8/10
知识调用策略	7/10
多模型路由	已完成

经验教训

分层比堆叠重要 — 把行为准则、知识、事实、技能分开，比往一个文件里塞更多内容有效
事实约束比模型能力重要 — 再强的模型，如果不尊重用户已有事实，输出也是错的
轻量方案优先 — ARM64 上跑 PyTorch 是不归路，FTS5 全文搜索足够快
AI Agent 需要反馈闭环 — 一次回答不够，需要设计验证、修正、迭代的机制

下一步

做一个 delegate 触发规则 skill，让 Hermes 能自动判断什么时候需要走 GLM-5.2 子任务，接近真正的多模型智能路由。

Hermes 多模型路由架构：从单模型到三级专家协作的演化之路

Fri, 31 Jul 2026 00:00:00 GMT

Hermes 多模型路由架构：从单模型到三级专家协作的演化之路

背景

在上一篇《构建个人 AI 工程知识操作系统》中，我记录了 Hermes Agent 多层记忆架构的搭建过程。但解决了”记住什么”之后，下一个问题是——“用什么模型来思考”。

日常对话、RAG 检索、简单脚本用 Flash 就够，但系统架构设计、硬件安全分析、多方案权衡需要更强的推理能力。全部用最强模型浪费 token，全部用最便宜模型质量不够。

本文记录从单模型到多模型路由的完整演化过程。

问题定义

可用模型池

模型	能力特征	资源消耗
DeepSeek V4 Flash	快速响应，工具调用稳定	低
DeepSeek V4 Pro	代码能力中等，适合审查	中
GLM-5.2	深度推理，架构设计强	高
Doubao Seed 2.0 Pro	视觉理解，OCR	专用

核心矛盾

单一模型无法同时兼顾速度、成本、复杂推理质量
Hermes 没有内置”根据任务难度自动切换模型”的能力
主模型只能有一个，但任务类型多种多样

设计目标

简单任务不浪费 GLM
复杂任务 Flash 能判断出来交给专家
视觉不走主模型
用户明确指定时覆盖自动路由
路由决策可追溯、可优化

架构演化

v1：关键词触发（跳过）

第一版简单粗暴——用关键词匹配判断是否 delegate：

看到"架构" → delegate
看到"状态机" → delegate
看到"电路图" → delegate

问题：

用户问”什么是状态机？“也会误触发
简单问题被升级，浪费 token
规则越来越复杂，趋向过拟合

v2：三级任务分级

将任务分为三个等级：

等级	描述	路由目标
Level 0	单步问答、查询、配置	Flash 直接回答
Level 1	需要分析，不需要重新设计系统	Flash 或 Pro
Level 2	系统设计、架构、多方案权衡	delegate → GLM-5.2

改进：从”关键词触发”升级为”按复杂度分级”，误触发减少。

遗留问题：

GLM 直接输出给用户，没有经过 Flash 验证
没有用户覆盖机制
成本等级标注不准确（不同 API Plan 价格不同）

v3：三级路由 + 专家回流 + 用户覆盖（当前版本）

最终架构：

                User Request
                     │
                     ▼
          DeepSeek V4 Flash
          Router + Orchestrator
                     │
        ┌────────────┼────────────┐
        │            │            │
        ▼            ▼            ▼
     Level 0      Level 1      Level 2
     Flash       Flash+Pro      GLM-5.2
        │            │            │
        │            │            │
        ▼            ▼            ▼
    简单任务      审查增强      专家设计
                     │
                     ▼
              Flash 整合输出

核心改进 1：GLM 输出回流

GLM 是专家，不直接面对用户。

Flash
  ↓
delegate_task → GLM-5.2（深度推理）
  ↓
GLM 结果返回 Flash
  ↓
Flash 职责：
  ├── 验证结果合理性
  ├── 合并 memory 上下文（用户偏好、设备参数）
  ├── 检查已知/未知约束
  ├── 补充 OpenViking 知识
  └── 输出最终答案给用户

核心改进 2：用户覆盖

如果用户明确指定模型，始终尊重，跳过路由判断。

"用 GLM-5.2 分析这个架构" → 走 GLM
"用 DeepSeek Pro 审查代码"  → 走 Pro

核心改进 3：资源等级替代成本等级

避免不同 API Plan 下价格标注不准确：

模型	资源等级
Flash	快速
Pro	增强
GLM	深度

核心改进 4：RAG 优先

先查 OpenViking 知识库，再决定是否 delegate。

问题
  ↓
有 OpenViking 知识可用？
  ↓ YES → 先检索，看能否直接回答
  ↓ NO  → 继续复杂度判断

核心改进 5：Token 预算判断

delegate 前先预估：

如果预计回答 < 1000 tokens
  AND 无架构设计
  AND 无多方案比较
  AND 无硬件安全
→ 不要 delegate，Flash 足够

完整路由决策树

Step 1: 用户指定了模型？
  YES → 尊重用户选择，跳过路由

Step 2: 包含图片？
  YES → Doubao Vision（自动，无需操作）

Step 3: 有 OpenViking 知识可用？
  YES → 先检索，看能否直接回答

Step 4: 复杂度评估
  预计回答长度、模块数、是否含方案比较、
  是否涉及硬件安全、是否需要架构图

Step 5: 路由
  Level 0 → Flash 直接回答
  Level 1 → Flash 或 Pro（代码审查走 Pro）
  Level 2 → delegate → GLM-5.2 → 回流 Flash 整合

辅助链（自动路由，无需操作）

图片/截图/OCR
        │
        ▼
Doubao Seed 2.0 Pro

后台任务（压缩、策展、background_review）
        │
        ▼
DeepSeek V4 Pro

为什么 Flash 是”大脑”而不是”最低级模型”

很多多模型方案的结构是：

便宜模型 → 判断 → 贵模型

这种方案的问题：便宜模型判断不准，路由错误率高。

我们的方案：

Flash → 理解上下文 → 决定是否调用专家 → 整合输出

Flash 不是”便宜替代品”，而是主控制器。它负责：

理解用户完整意图
调用 memory 和知识库
判断是否需要专家介入
整合专家输出为最终答案

配置实现

model:
  default: deepseek-v4-flash
  provider: custom

delegation:
  model: glm-5.2          # 子任务自动走 GLM
  provider: custom

auxiliary:
  vision:
    model: doubao-seed-2-0-pro-260215
    base_url: "https://ark.cn-beijing.volces.com/api/coding/v3"
    timeout: 120
  compression:
    model: deepseek-v4-pro
  background_review:
    model: deepseek-v4-pro
  curator:
    model: deepseek-v4-pro

当前状态：冻结 v3，进入数据收集

现在不做更多规则调整，让真实使用数据跑出来。

4 个观察指标

指标	目标	说明
路由准确率	逐步提升	任务→路由→结果质量评分
GLM 调用比例	5-15%	超过 30% 说明 Router 太激进
升级失败案例	重点收集	Flash 不足→用户追问→GLM 解决的案例
决策稳定性	同类任务一致	避免同类型任务反复切换模型

理想分配

Flash:  70-85%
Pro:    10-20%
GLM:     5-15%
Doubao: 按需

未来方向

v4.1：task-memory（经验驱动路由）

记录每次路由决策的效果，积累经验数据：

task-memory/
├── energy/EMS设计
│     ├── model: GLM-5.2
│     ├── success: true
│     └── pattern: state-machine
├── software/docker迁移
│     ├── model: Flash
│     └── success: true
└── hardware/BMS分析
      ├── model: GLM-5.2
      └── success: true

以后遇到类似任务，直接查询历史，自动选择最佳模型。

v4.2：failure-memory（失败升级）

Flash 尝试解决 → 检测到多次工具失败/不确定性 → 自动升级到 GLM。

最终形态

                  Hermes
                    │
             Model Router
                    │
        ┌───────────┼───────────┐
     Rules       Memory       Feedback
       │            │             │
   当前规则     历史决策      成功率
        └───────────┼───────────┘
                    ▼
            自适应模型选择

架构模式总结

当前 Hermes 已经形成 4 层知识体系：

层级	内容	回答的问题
Resource Memory	专业知识库	“这个领域有什么知识？”
Event/Experience Memory	历史经验	“以前发生过什么？”
Decision Memory	设计决策	“为什么选择这个方案？”
Pattern Memory	架构模式	“以后类似问题怎么处理？”

模型链形成 Planner → Specialist → Reviewer → Integrator 结构：

创造能力 = GLM-5.2
执行能力 = DeepSeek V4 Flash
审查能力 = DeepSeek V4 Pro
经验能力 = OpenViking

经验教训

不要用关键词触发路由 — 容易误触发，趋向过拟合
Flash 是大脑，不是最低级模型 — 它负责判断和整合，不是替代品
GLM 不直接面对用户 — 专家输出必须经过主模型验证和整合
成本等级不要硬编码 — 不同 API Plan 价格不同，用资源等级替代
先查知识库再 delegate — 充分利用已有知识，避免不必要的专家调用
规则路由是起点，经验路由是终点 — 先跑数据，再做自适应

关联阅读

构建个人 AI 工程知识操作系统：Hermes + OpenViking 多层记忆架构实践 — 记忆架构搭建
model-router skill：~/.hermes/skills/meta/model-router/SKILL.md
决策记录：OpenViking viking://user/memories/events/

Hermes 可观测 AI 系统：从规则驱动到数据驱动的工程闭环

Fri, 31 Jul 2026 00:00:00 GMT

Hermes 可观测 AI 系统：从规则驱动到数据驱动的工程闭环

前情提要

前两篇记录了 Hermes Agent 的搭建过程：

《构建个人 AI 工程知识操作系统》 —— 多层记忆架构（OpenViking + 分层记忆 + 知识检索）
《Hermes 多模型路由架构》 —— 三级专家协作路由（v1→v2→v3 演化）

本篇文章是系列的第三篇，也是阶段总结篇。经过八小时连续的架构设计、规则编写、测试验证和故障修复，这套系统从”配置多个模型”正式进入”个人 AI 工程系统”的第三阶段——可观测 AI 系统。

三个阶段

阶段1: 工具调用 Agent
  → 能调用工具，但每次独立决策，无记忆

阶段2: 多模型 Agent
  → 多模型分工，规则路由，有记忆分层

阶段3: 可观测 AI 系统  ← 现在这里
  → 有日志，有版本，有实验，有回滚，有失败分析

阶段4: 经验驱动 AI 系统（未来）
  → 基于积累数据自动优化路由

本次构建的核心成果

1. 内存生命周期规则

解决了”记忆污染”问题——Agent 不再把旧事实当新事实，也不再不分来源地混用记忆。

7 类可信度标记：

标记	含义	TTL
CONFIRMED ✅	用户确认的事实	30-90 天
OBSERVED 📋	自动探测的信息	30 天
DERIVED 🔄	推理得出的结论	14 天
SPECULATIVE ❓	猜测，未验证	1 天
STALE ⌛	已过期	保留 7 天后移除
CONFLICTED ⚠️	多个来源不一致	待裁决
FROZEN 🧊	用户锁定，永不覆盖	永久

5 类生命周期规则：写入规则、冲突解决、过期管理、回滚机制、冷冻保护。

冲突优先级修正：核心原则改为”来源可信度 > 存储位置”。用户今天说的 CONFIRMED 事实，优先级高于旧 MEMORY.md 记录。不再因为”存在 MEMORY 里”就自动压过新输入。

2. 三层记忆职责边界

层	存储	职责
MEMORY.md / USER.md	高频事实	系统 prompt 自动注入，零延迟
OpenViking	语义知识	长期知识、决策、经验、架构模式
FTS5 (session_search)	原始对话	全文检索历史对话，兜底

三层的交叉检索策略：先查 MEMORY（高频事实）→ 再查 OpenViking（语义知识）→ 最后查 FTS5（原始对话）。

3. 真实请求 Trace 系统

建立完整链路追踪：用户输入 → 检索 → 路由 → delegate → 模型执行 → 整合结果

每次请求记录：

输入任务和复杂度评分
路由判断依据
检索来源（哪些知识库命中）
使用模型
输出结果摘要
用户反馈（待收集）

4. Task-Memory 和 Failure-Memory 观察数据库

Task-Memory 记录每次路由决策的完整信息：

task_id: T6
task: 对比 MQTT vs Modbus TCP
complexity: { modules: 1, safety: true, arch: false, tradeoff: true, scale: large }
routing: { decision: Level 2, model: GLM-5.2 }
evaluation:
  latency_seconds: 102
  input_tokens: 19590
  output_tokens: 2414
  human_rating: (待收集)

Failure-Memory 记录每次失败的根本原因和修复方案：

ID	类型	原因	修复
F001	CONFIG	delegation.provider 指向不存在的 provider	修复为 volcengine-coding-plan
F002	TOOL	GLM 子任务执行过多环境探测，600s 超时	Flash 在 delegate 前完成检索
F003	TOOL	web_search 依赖缺失，子任务花时间安装	delegate context 预装依赖
F004	CONFIG	auxiliary.provider 同样指向不存在的 provider	统一切换 provider

分类：CONFIG / ROUTING / RETRIEVAL / MODEL / TOOL / MEMORY

5. Batch Test v1：6 个测试用例 × 3 个模型

任务	等级	模型	耗时	结果
什么是 MQTT broker	Level 0	Flash	0.5s	正确路由
查 NAS IP	Level 0	Flash	0.5s	正确路由
写光伏效率函数	Level 1	Flash	0.5s	正确路由
审查 HA MQTT 配置	Level 1	Pro	52s	正确路由，发现 9 项风险
设计 15 状态机	Level 2	GLM	419s	正确路由，36KB 设计文档
对比 MQTT vs Modbus	Level 2	GLM	102s	正确路由，18K 字符深度分析

路由正确率：6/6。但样本量小，需要扩充到 20-50 个。

当前冻结的架构 v3

model-router v3 (frozen-baseline)
  ├── 三级路由：Level 0 (Flash) / Level 1 (Flash/Pro) / Level 2 (GLM)
  ├── 固定分工：视觉 → Doubao，审查 → Pro，压缩 → Pro
  ├── 复杂度评分维度：模块数、安全风险、架构设计、方案权衡、输出规模
  └── 用户覆盖：用户指定模型时跳过自动路由

memory-lifecycle-rules v1
  ├── 7 类可信度标记
  ├── 5 类生命周期规则
  ├── 三层记忆职责边界
  └── 冲突优先级：来源可信度 > 存储位置

task-memory / failure-memory (observation only)
  └── 不自动影响路由，仅收集数据

关键发现

1. 配置错误导致静默失败

delegation.provider 设为 “custom” 但未配置 API key，所有 delegate 任务静默失败。同样问题存在于 auxiliary.compression 和 auxiliary.curator。修复后管道畅通。

教训：配置必须验证，不能假设”看起来对”。

2. GLM 子任务执行过剩环境探测

GLM 在推理前做了 session_search、execute_code、skill_view 等 15 次探测操作，消耗了 600 秒中的大部分时间。这些应该在 Flash 阶段完成，只传递精简 context 给 GLM。

教训：delegate 是推理增强，不是环境探测增强。环境探测是 orchestrator 的职责。

3. 1000-token 阈值无数据支撑

路由规则中的 1000-token 阈值是拍脑袋的。本次 batch test 第一次收集了实际数据（T6 实际输出 22,004 tokens）。需要更多样本才能确定合理阈值。

教训：路由参数必须有数据支撑，不能凭感觉设。

4. Flash 同时作为路由器和审查者是循环依赖

当前架构中，Flash 负责判断”这是 Level 2”→ delegate 给 GLM → GLM 返回 → Flash 审查 GLM 输出。如果 Flash 无法识别 GLM 的错误，坏答案直接交付。

v4 目标：引入 Pro 作为独立审查者，形成 Flash → GLM → Pro → Flash 管道。

下一阶段策略

当前策略：
  规则驱动 > 经验驱动
  经验库只观察，不控制

下一阶段目标：
  不是让 Hermes 更聪明
  而是让 Hermes 的每一次决策都有证据、有反馈、可优化

需要积累：
  - 20-50 条真实任务 trace
  - 不同难度边界案例
  - 用户反馈质量标签
  - 模型耗时/token/成功率

v4 设计目标（暂不实现）：
  Flash = Orchestrator
  GLM = Design Expert
  Pro = Independent Reviewer
  Doubao = Vision

成功标准

当前阶段的成功标准不是路由更复杂，而是：

每一次决策都有记录
每一次失败都有原因
每一次改进都有依据

这套系统现在已经从”配置多个模型”进入”个人 AI 工程系统”的阶段。下一步是收集数据，而不是继续堆规则。

相关文章：

AutoBangumi TMDB 被墙？不用代理，一行 sed 搞定

Fri, 12 Jun 2026 00:00:00 GMT

AutoBangumi TMDB 被墙？不用代理，一行 sed 搞定

问题

AutoBangumi（AB）用 TMDB 获取番剧元数据。默认请求的是 api.themoviedb.org，但这个域名在国内很多网络环境下丢包严重甚至完全不通，导致元数据查询持续超时。

AB 虽然支持 HTTP 代理（proxy.enable），但不是所有人都能搭代理。有没有更简单的办法？

答案

api.themoviedb.org 的短域名 api.tmdb.org 在很多国内网络下是通的。只需把容器里的硬编码 URL 换掉就行。

方法

第一步：找到要改的文件

AB 容器里硬编码 TMDB URL 的文件：

文件	硬编码 URL
`/app/module/parser/analyser/tmdb_parser.py`	`https://api.themoviedb.org`
`/app/module/parser/analyser/tmdb_parser.py`	`https://image.tmdb.org/t/p/w780`
`/app/module/bgmi_calendar.py`	`https://api.bgm.tv/calendar`

一般只需要改第一个。image.tmdb.org 和 api.bgm.tv 通常能通。

第二步：进容器改

docker exec -it AutoBangumi bash

# 替换 TMDB API 域名
sed -i 's|https://api.themoviedb.org|https://api.tmdb.org|g' /app/module/parser/analyser/tmdb_parser.py

# 退出容器后重启
exit
docker restart AutoBangumi

改完立刻生效，AB 会用 api.tmdb.org 请求 TMDB。

第三步：持久化（关键）

容器重建（更新镜像、docker-compose down && up）后改动会丢失。两种方式持久化：

方式一：crontab 脚本（推荐）

写一个脚本，NAS 启动时自动 patch：

#!/bin/bash
# /vol1/1000/Mikan/autobangumi/patch_tmdb.sh

sleep 10  # 等容器启动

FILE=/app/module/parser/analyser/tmdb_parser.py
CONTAINER=AutoBangumi

if docker exec $CONTAINER grep -q 'api.themoviedb.org' "$FILE" 2>/dev/null; then
    docker exec $CONTAINER sed -i 's|https://api.themoviedb.org|https://api.tmdb.org|g' "$FILE"
    docker restart $CONTAINER
    echo "$(date): TMDB patched" >> /vol1/1000/Mikan/autobangumi/patch.log
fi

加到 crontab：

crontab -e
# 加入：
@reboot /vol1/1000/Mikan/autobangumi/patch_tmdb.sh

脚本有判断逻辑：只有 URL 还没被改过才执行 patch，避免重复重启。

方式二：Dockerfile 继承（更规范）

FROM ghcr.io/estrellaxd/auto_bangumi:latest
RUN sed -i 's|https://api.themoviedb.org|https://api.tmdb.org|g' \
    /app/module/parser/analyser/tmdb_parser.py

然后用这个自定义镜像代替官方镜像。缺点是每次 AB 更新要重新 build。

验证

改完后查看 AB 日志，TMDB 请求应该不再超时：

docker logs AutoBangumi --tail 50 | grep -i tmdb

如果看到正常的元数据返回而不是 timeout，就成功了。

总结

方案	优点	缺点
`sed` + crontab	简单，一行命令	容器重建要等脚本触发
Dockerfile 继承	更新时自动生效	每次 AB 更新要重新 build
HTTP 代理	AB 原生支持	需要搭代理服务器

对于不想折腾代理的用户，sed 替换是最快的方案。

我已向 AB 开发者提交了 Feature Request #1042，建议在配置中增加自定义 API Base URL 的选项。如果被采纳，以后就不需要手动 patch 了。

SQLite FTS5 跨架构迁移踩坑记：从 x86 到 ARM64

Wed, 10 Jun 2026 00:00:00 GMT

SQLite FTS5 跨架构迁移踩坑记：从 x86 到 ARM64

背景

最近将 Hermes Agent（一个基于 SQLite 的 AI 聊天代理）从一台 x86_64 Arch Linux 服务器迁移到一台 ARM64 Armbian 开发板上。数据量不大：约 111MB 的 state.db，包含 9786 条消息、186 个会话。

迁移数据库嘛，听起来很简单对吧？然而这次踩了一个大坑。

迁移方案的选择

方案一：`.dump` / `.reload`（我选的，后来证明是错的）

# 在源机器上导出
sqlite3 state.db ".dump" > dump.sql

# 在目标机器上导入
sqlite3 state.db < dump.sql

看起来很标准对吧？SQLite 官方文档也推荐这个方法来做版本升级或格式转换。但问题是——当数据库包含 FTS5 虚拟表时，这个方法有严重的隐患。

方案二：直接复制 `.db` 文件（正确方案）

# 直接拷贝
scp user@source-server:/path/to/state.db ./state.db

没错，就这么简单。SQLite 的 .db 文件是二进制跨架构兼容的——x86 和 ARM64 使用相同的字节序（小端），SQLite 文件格式不依赖任何平台特定的结构。直接复制就行。

问题现象

使用 .dump / .reload 导入后，数据库看起来正常，表和数据都在。但当 Agent 尝试写入新消息时：

RuntimeError: constraint failed

具体报错指向 FTS5 虚拟表的插入操作。进一步测试：

-- 查询没问题
SELECT COUNT(*) FROM messages;  -- 9786，正常

-- 插入就报错
INSERT INTO messages (session_id, role, content, timestamp)
VALUES ('test', 'user', 'hello', datetime('now'));
-- Error: constraint failed

诊断过程

1. 标准完整性检查——没用

PRAGMA integrity_check;
-- ok

PRAGMA integrity_check 返回正常！但它不会检查 FTS5 shadow 表的完整性。这是一个容易被忽略的坑。

2. FTS5 专用完整性检查——发现问题

FTS5 提供了内置的完整性检查命令：

SELECT * FROM messages_fts('integrity-check');

如果 FTS5 索引完好，这条语句返回空结果集
如果索引损坏，会返回错误描述

在我的案例中，它返回了不一致的错误信息，确认 FTS5 索引已损坏。

3. 检查 shadow 表

FTS5 虚拟表会在底层创建一组 “shadow 表”（以 _data、_idx、_content、_docsize、_config 为后缀）。你可以直接查看：

-- 查看有哪些 shadow 表
SELECT name FROM sqlite_master
WHERE type='table' AND name LIKE 'messages_%';

这些表的状态在 dump/reload 后可能不一致。

根因分析

问题出在 .dump 导出的 SQL 语句顺序上。

.dump 会导出：

CREATE VIRTUAL TABLE messages_fts USING fts5(...) — 创建 FTS5 表
各种 INSERT 语句填充主表
可能还有触发器（用于自动同步主表和 FTS5 索引）

但在 reload 时，触发器可能会在插入主表时同时触发 FTS5 索引更新，而这些更新与后续的 shadow 表数据发生冲突。在不同架构间，SQLite 内部的某些排序或序列化行为可能有微小差异，进一步加剧了这种不一致。

另外还发现 sqlite_sequence 表的值严重异常——autoincrement 计数器显示约 3 万亿，而实际只有不到 15000 行。这也是 dump/reload 过程中的副作用。

修复方案

完整修复脚本

以下是一个通用的 FTS5 索引修复脚本：

#!/usr/bin/env bash
# repair_fts.sh - 修复 FTS5 索引
# 用法: bash repair_fts.sh <数据库路径> <FTS表名> <主表名> <内容列>

set -euo pipefail

DB="${1:?用法: bash repair_fts.sh <db_path> <fts_table> <main_table> <content_columns>}"
FTS_TABLE="${2:?请指定 FTS5 虚拟表名}"
MAIN_TABLE="${3:?请指定主表名}"
CONTENT_COLS="${4:?请指定内容列名，如 'role, content'}"

BACKUP="${DB}.bak.$(date +%Y%m%d%H%M%S)"

echo "=== SQLite FTS5 索引修复工具 ==="
echo ""
echo "数据库: $DB"
echo "FTS表:  $FTS_TABLE"
echo "主表:   $MAIN_TABLE"
echo "列:     $CONTENT_COLS"
echo ""

# 1. 备份
echo "[1/5] 备份数据库..."
cp "$DB" "$BACKUP"
echo "  备份已保存到: $BACKUP"
echo ""

# 2. 诊断
echo "[2/5] 诊断当前状态..."
echo "  主表行数:"
sqlite3 "$DB" "SELECT COUNT(*) FROM $MAIN_TABLE;"
echo "  FTS5 完整性检查:"
RESULT=$(sqlite3 "$DB" "SELECT * FROM ${FTS_TABLE}('integrity-check');")
if [ -z "$RESULT" ]; then
    echo "  ✓ FTS5 索引完好"
    read -p "  索引看起来正常，是否仍要继续？(y/N) " -n 1 -r
    echo
    [[ $REPLY =~ ^[Yy]$ ]] || exit 0
else
    echo "  ✗ 发现问题: $RESULT"
fi
echo ""

# 3. 删除旧 FTS 表及其相关对象
echo "[3/5] 删除旧的 FTS 表..."
sqlite3 "$DB" <<SQL
-- 删除触发器（如果存在）
SELECT 'DROP TRIGGER IF EXISTS ' || name || ';'
FROM sqlite_master WHERE type='trigger' AND tbl_name='$MAIN_TABLE'
AND (name LIKE '%fts%' OR name LIKE '%ai%' OR name LIKE '%ad%' OR name LIKE '%au%');

-- 列出将被删除的相关表
SELECT '  将删除: ' || name FROM sqlite_master
WHERE type='table' AND name LIKE '${FTS_TABLE}%';
SQL

sqlite3 "$DB" <<SQL
DROP TABLE IF EXISTS $FTS_TABLE;
DROP TABLE IF EXISTS ${FTS_TABLE}_data;
DROP TABLE IF EXISTS ${FTS_TABLE}_idx;
DROP TABLE IF EXISTS ${FTS_TABLE}_content;
DROP TABLE IF EXISTS ${FTS_TABLE}_docsize;
DROP TABLE IF EXISTS ${FTS_TABLE}_config;
SQL
echo "  ✓ 已删除"
echo ""

# 4. 重建 FTS 表和索引
echo "[4/5] 重建 FTS 表..."
sqlite3 "$DB" <<SQL
CREATE VIRTUAL TABLE IF NOT EXISTS ${FTS_TABLE} USING fts5($CONTENT_COLS, content='$MAIN_TABLE', content_rowid='id');
INSERT INTO ${FTS_TABLE}(${FTS_TABLE}) VALUES('rebuild');
SQL
echo "  ✓ 已重建"
echo ""

# 5. 验证
echo "[5/5] 验证..."
RESULT=$(sqlite3 "$DB" "SELECT * FROM ${FTS_TABLE}('integrity-check');")
if [ -z "$RESULT" ]; then
    echo "  ✓ FTS5 索引已修复！"
    COUNT=$(sqlite3 "$DB" "SELECT COUNT(*) FROM $MAIN_TABLE;")
    echo "  ✓ 索引覆盖 $COUNT 条记录"
else
    echo "  ✗ 仍有问题: $RESULT"
    echo "  请从备份恢复: cp $BACKUP $DB"
    exit 1
fi

echo ""
echo "=== 修复完成 ==="

使用方法

# 赋予执行权限
chmod +x repair_fts.sh

# 针对 messages 表修复
bash repair_fts.sh ./state.db messages_fts messages "role, content"

关键步骤解释

步骤	说明
备份	修复前必须备份，万一出问题可以回退
诊断	用 FTS5 的 `integrity-check` 确认问题
删除	彻底清除损坏的 FTS5 表和 shadow 表
重建	用 `content=` 参数关联主表，`rebuild` 命令重建索引
验证	再次运行 integrity-check 确认修复成功

修复 `sqlite_sequence`

如果 autoincrement 计数器也异常了：

-- 查看当前值
SELECT * FROM sqlite_sequence;

-- 重置为实际最大值
UPDATE sqlite_sequence SET seq = (SELECT MAX(id) FROM messages) WHERE name = 'messages';

-- 或者直接删除，下次插入时会自动重新生成
DELETE FROM sqlite_sequence WHERE name = 'messages';

最终状态

修复完成后，数据库恢复正常：

数据库大小:  111.4 MB
消息总数:    9786
会话数:      186
FTS5 索引:   ✓ 健康
完整性检查:  ok

经验总结

核心教训

SQLite + FTS5 跨架构迁移，永远不要用 .dump / .reload。直接复制 .db 文件。

SQLite 数据库文件是二进制兼容的（前提是字节序相同，x86 和 ARM64 都是小端）。直接 scp 或 rsync 就行，不需要转成 SQL 文本再导入。

如果你必须用 `.dump`

有时候你确实需要文本格式（比如要合并两个数据库、或者要跨字节序迁移），那么：

导出时排除 FTS5 表：先 dump 除 FTS 相关表以外的所有内容
导入主表数据
在目标数据库上重新创建 FTS5 虚拟表
运行 INSERT INTO fts_table(fts_table) VALUES('rebuild'); 重建索引
用 SELECT * FROM fts_table('integrity-check'); 验证

FTS5 完整性检查速查

-- 常规检查（不检查 FTS5！）
PRAGMA integrity_check;

-- FTS5 专用检查（这才是正确的）
SELECT * FROM your_fts_table('integrity-check');
-- 返回空 = 正常
-- 返回内容 = 有问题

迁移前检查清单

备份原始数据库
确认迁移方式（推荐直接复制文件）
迁移后运行 PRAGMA integrity_check;
如果有 FTS5，运行 SELECT * FROM fts_table('integrity-check');
测试读写操作
检查 sqlite_sequence 值是否合理

本文记录于 2026-06-11，基于 Hermes Agent 从 x86_64 Arch Linux 迁移到 ARM64 Armbian 的实际经历。希望对遇到类似问题的朋友有所帮助。