本地多智能体记忆库提炼模型动态路由与配额防漏实践¶

在多智能体（如 Hermes Agent 与 ZCode）与本地知识库（如 OpenViking）协同的日常开发中，开发者通常会在多个大模型（如 Google Gemini、WorkBuddy/GLM、Claude、DeepSeek 等）之间灵活切换。然而，若底层记忆库的语义提炼（VLM/LLM）采用静态硬编码配置，极易导致用户明明已切换至轻量/免费模型聊天，而后台记忆系统却仍在源源不断地偷跑高阶商业模型额度。

本文以实际排查与工程改造为例，解构本地记忆提炼链路的生命周期瓶颈，并记录一种零常驻额外进程、跟随当前聊天模型动态切换提炼端点的轻量化工程实践。

1. 现象与根因：商业配额为何“没用也在掉”？¶

1.1 账本核对与两类流量指纹辨析¶

当发现 Google Antigravity / Gemini 订阅额度异常缩减时，切忌凭主观感觉猜测，应直接调取网关中立账本（如 EasyCLIProxyAPI 的 usage.db）按客户端与时间段聚合统计：

累积上下文型流量（主会话聊天）：
指纹：请求间隔与人工交互频次相近（几秒至几分钟），单次 output_tokens 正常，而 input_tokens 呈阶梯式单调暴增（如从 1.8 万迅速滚至 12 万+）。
成因：由于 Agent 每轮对话均全量回传历史 Context，一个数小时的长会话即便仅有几十次交互，累积发送的输入 Token 即可轻松破亿（单日 1 亿~2 亿属于典型高阶会话特征）。
后台自动化型流量（记忆抽取与提炼）：
指纹：特定 User-Agent（如 OpenViking 的 AsyncOpenAI/Python）、多并发秒级连发、单次输入极小（数百至数千 Token）、输出主要为结构化摘要。
成因：记忆库在会话结束或产生新知识时，自动调用底层 VLM 生成 L0 摘要与 L1 大纲。若该链路独立绑定了商业网关，便会在后台持续“慢漏”。

1.2 OpenViking 的静态 VLM 配置陷阱¶

OpenViking 的核心配置文件 ov.conf 采用静态字段定义：

{
  "embedding": {
    "dense": {
      "provider": "openai",
      "api_base": "http://127.0.0.1:18082/v1",
      "model": "bge-m3",
      "dimension": 1024
    }
  },
  "vlm": {
    "provider": "openai",
    "api_base": "http://127.0.0.1:18080/v1",
    "api_key": "your-api-key",
    "model": "gemini-3.8-flash"
  }
}

向量化检索（Embedding）：通常已接入本地 CUDA BGE-M3，完全属于本地硬件驱动，不消耗网络配额；
摘要提炼（VLM）：被直接钉死在 18080 端口的 gemini-3.8-flash 上。即便客户端 UI 将聊天模型切为本地 WorkBuddy 或其他渠道，提炼动作依然单向轰炸 Gemini。

2. 动态路由的生命周期突破口¶

2.1 源码级单例缓存限制¶

查阅 OpenViking 核心配置模块（vlm_config.py）可见：

def get_vlm_instance(self) -> Any:
    """Get VLM instance with multi-credential failover support."""
    if self._vlm_instance is None:
        # 读取 self.credentials 或配置字典
        self._vlm_instance = VLMFactory.create(config_dict)
    return self._vlm_instance

_vlm_instance 首次创建后即常驻于内存单例。这意味着直接修改运行中 OpenViking 进程的配置无法实现热生效。

2.2 借助 Serverless 懒网关实现“零侵入”动态生效¶

在成熟的本地多智能体架构中，OpenViking 通常挂载在按需唤醒的懒网关（如 openviking_lazy_gateway.py，端口 1933）之后： - 真实 OpenViking 核心（端口 1934）与本地 llama-server（端口 18082）在无请求 2 分钟后自动终止进程释放显存与内存； - 当新请求穿透 1933 时，网关重新执行 openviking-server.exe。

关键结论：

只要在 OpenViking 休眠期间（或改写后主动终止当前 1934 实例），配置文件 ov.conf 的改动将在下一次自动唤醒时被全量重新载入。 因此，改写配置文件 + 终止 1934 即可完成 100% 干净的热切换，完全无需常驻监控进程，也无需对 upstream 开源包打侵入式补丁。

3. 工程落地：内嵌化路由与配额看板联动¶

为了践行“无黑框终端、无常驻冗余守护进程”的极客桌面原则，将该动态跟随逻辑直接整合入 Hermes Agent 自带的 token-stats 用户插件中。

3.1 提取聊天模型真实真源（State DB）¶

切忌将 config.yaml 中的静态 model.default 视为当前模型。在图形客户端中，用户切模型只记录于本地状态库： - 真源位置：~/.hermes/state.db 中的 sessions 表； - 定位逻辑：按 last_activity_at DESC 提取最新活跃行的 model 与 billing_provider； - 名称映射：billing_provider 通常格式为 custom:<slug>（如 custom:workbuddy-(127.0.0.1:8787)），通过正则匹配 config.yaml 内 custom_providers 列表，精准反查对应的 base_url 与 api_key。

3.2 插件后端 API 扩展（`plugin_api.py`）¶

在 /api/plugins/token-stats/ 下扩展 /ovlm 路由，并与原生 /quota 刷新机制合流：

@router.get("/quota")
async def quota(force: str = Query("", description="force=1 bypasses the 30s cache")):
    # 顺路执行提炼模型自动跟随（模型无变动时为零开销幂等判断）
    _auto_ovlm_follow()
    data = fetch_google_quota(force=force in ("1", "true", "yes"))
    return data

自动跟随安全机制（_auto_ovlm_follow）： 1. 非阻塞线程锁与 30s 冷却：避免桌面多组件（状态栏 Chip、看板页面、导航徽标）并发轮询导致频繁写盘； 2. 会话静默窗口保护：当聊天会话已停止超过 90 秒时，不再主动切换，避免旧上下文干扰； 3. 安全回退保护：当模型非 custom 本地凭据或缺少可用密钥时，拒绝写入，保持上一版安全配置。

3.3 前端全景看板卡片（`OvlmCard`）¶

在桌面端全景配额页面中嵌入状态卡片： - 当前提炼端点：展示当前加载的模型名称、端点端口与密钥指纹，并用动态圆点指示 1934 后端是“运行中”还是“休眠中”； - 目标模型展示：实时映射当前聊天会话使用的模型与网关地址； - 微交互操作：支持一键翻转“跟随开关”、提供“仅写入配置”与“立即同步并生效（踢掉 1934）”按钮，操作即时触发系统 Haptic 振动反馈与 Toast 通知。

4. 实战排障与端到端验证避坑指南¶

4.1 异步写入 vs 网关超时假 502¶

踩坑：调用 POST /api/v1/content/write 时，若设置 wait: true，由于文档提炼需要 LLM 处理时间，耗时极易超过懒网关内置的 60 秒转发超时（ProxyHandler timeout=60.0），导致客户端收到 502，误判写入失败；
规避：自动化写入或大文档提炼，务必显式指定 wait: false（异步提炼），由 OpenViking 后台事件队列静默完成。

4.2 WebDAV PUT 与语义提炼的机制差异¶

踩坑：使用 WebDAV 协议（PUT /webdav/resources/...）可直接以二进制流保存文档且性能极高（HTTP 204），但该接口属于纯粹的文件系统写入，不会触发任何后置的 VLM 提炼与摘要计算；
规避：若要验证提炼链路，必须走标准 REST API 规范（POST /api/v1/content/write）。

4.3 统计日志中的时间戳解析盲区¶

踩坑：反代服务（如 codebuddy2openai）输出的 usage.jsonl 中，时间字段通常采用 Epoch 毫秒整数（如 {"ts": 1788683809637}），若用 grep "16:35" 等字符串时间比对，会呈现“全量无调用”的假阴性统计；
规避：日志解析一律将当前 time.time() * 1000 换算后进行绝对时间窗口过滤。

4.4 端到端验收基准¶

经过上述治理后，执行端到端写入测试： 1. 切至 WorkBuddy (glm-5.3-flash) 聊天并写入临时测试文档； 2. 查看 usage.jsonl：16:36~16:37 出现输入 1041 / 输出 2707 的提炼日志，模型为 glm-5.3-flash； 3. 查看 EasyCLIProxyAPI usage.db：近 20 分钟内 Gemini 商业接口保持 0 调用； 4. 验证完成后立即调用 DELETE 彻底抹除临时数据，确保知识库一尘不染。