存储抽象五后端降级链与 Credit 计费

存储抽象五后端降级链与 Credit 计费

本节摘要:第 8 章的收束节,讲横跨整个代理层的两个机制——存储抽象与计费。代理层有自己的存储需求(会话状态、缓存、临时数据),抽象为 ProxyStorage,支持 cos/sqlite/fs/memory 四种后端,按优先级降级保可用。计费(Credit)则基于 token 消耗上报,让成本可追溯。这两个机制让代理层「存得下、用得起」,是生产级运行的横切保障。

一、代理层为什么需要自己的存储

代理层除了转发,还要存一些自己的东西——会话状态、sessionInit 记录的三元组、缓存等:

代理层的存储需求
  ├─ 会话状态(当前 team/agent/task 三元组)
  ├─ sessionInit 记录(避免每次重新选)
  ├─ 临时缓存(如某些计算结果)
  └─ 会话历史片段(供 extract 用)
  
  → 这些不该都堆在核心服务(那是长期记忆)
  → 代理层需要一个「自己的、灵活的」存储
​

这些存储需求与核心服务的「长期记忆」不同——它们更临时、更灵活,所以代理层有自己的存储抽象,而非全用核心服务。

二、ProxyStorage:五后端降级链

代理层的存储抽象为 ProxyStorage,实现多种后端,按优先级降级:

五后端降级链(从主到备)
  cos(对象存储)     ← 生产首选,持久、可共享
    ↓ (不可用)
  sqlite(本地数据库) ← 单机持久
    ↓ (不可用)
  fs(本地文件)       ← 简单兜底
    ↓ (不可用)
  memory(内存)       ← 最末兜底,重启丢
    
  → 主后端故障,自动落到备选,保证可用
​

关键概念:降级链的核心思想是「可用性优先于持久性」。cos 挂了落 sqlite,sqlite 挂了落 fs……即使最坏情况落 memory(丢持久性),至少系统还能跑(保可用性)。这种「逐级降级」让代理层在不同环境、不同故障下都能继续工作,是面向「各种部署环境」的弹性设计。

三、降级链的工作方式

降级不是「手动切换」,而是自动探测+回退:

降级的自动机制(概念)
  写入时:
    尝试主后端(cos)
      ├─ 成功 → 写入完成
      └─ 失败 → 尝试下一后端(sqlite)...
      
  读取时:
    按写入时的后端读(或遍历找)
    
  周期性:
    探测主后端是否恢复
      ├─ 恢复 → 回迁到主后端
      └─ 未恢复 → 继续用降级后端
​

这种自动降级+回迁,让运维不必「守着切换」——系统自己应对后端波动。当然,降级期间可能丢失部分持久性(如落在 memory 的数据重启会丢),这是「保可用性」的代价。

⚠️ 注意:降级链是「兜底机制」,不是「常态用法」。生产环境应配好主后端(cos),让常态走持久后端;降级只在故障时触发。如果你发现系统「常态就跑在 memory」,说明主后端配置有问题,要排查——常态跑 memory 会导致重启丢数据。

四、Credit 计费:基于 token 的成本追溯

代理层的另一个横切机制是 Credit 计费——基于 token 消耗上报,让成本可追溯:

Credit 计费机制
  forward 转发请求给 LLM
    ↓
  LLM 返回答复(含 token 消耗)
    ↓
  代理层统计:
    ├─ 输入 token(含注入的记忆)
    ├─ 输出 token(答复)
    └─ 总消耗
    ↓
  上报 Credit(关联到 team/agent/user)
    ↓
  成本可按团队/Agent/用户追溯
​

Credit 计费与第 8 步 report(可观测上报)相关——它是成本维度的观测。第 12 章会讲三路可观测(Langfuse/Opik/ClickHouse),其中 ClickHouse 常用来统计这类成本数据。

五、横切机制的价值:生产级的弹性与可追溯

存储降级链与 Credit 计费,都是「横切」整个代理层的机制——它们不是某一步,而是贯穿所有步骤的保障:

横切机制的贯穿
  八步管道的每一步
    ├─ 都可能用存储(状态/缓存)→ ProxyStorage 降级链保障
    └─ forward 消耗 token → Credit 计费追溯
    
  → 横切 = 「每一步都需要的基础能力」
​

这两个机制让代理层具备「生产级」的两个特征:① 弹性(存储降级,故障能扛),② 可追溯(计费,成本可控)。没有它们,代理层只是个「能跑的 demo」;有了它们,才是「能上生产的系统」。这就是为什么第 12 章生产部署会重点讲这些横切机制的配置。

💡 技巧:理解「横切」概念,你看系统的视角会更立体。八步管道是「主流程」(纵向),存储/计费/可观测是「横切」(横向)。主流程管「把事做完」,横切管「做得稳、做得明白」。成熟的系统两者都全——本系统在横切上(存储降级、Credit、三路可观测)做得很完整,这是它「生产级」的体现。

本节要点回顾

1. 代理层需要自己的存储:会话状态/三元组/缓存,与核心服务的长期记忆不同,更临时灵活。
2. 五后端降级链:cos→sqlite→fs→memory,逐级降级保可用性——可用性优先于持久性。
3. 自动降级+回迁:故障自动落备选,恢复自动回迁,运维不必手动切换。
4. Credit 计费:基于 token 上报,按 team/agent/user 追溯成本——与 report 步骤相关。
5. 横切价值:存储与计费贯穿所有步骤,是生产级的弹性与可追溯保障——第 12 章配置重点。

第 8 章到此完成——从透明代理定位、八步全景、身份三连、injection 双策略、限流转发回写、到存储计费,整套代理层讲透了。下一章转向代码接入——SDK 四步法。