Claude记住Alice批了预算：他用SQLite干掉了Pin

200K上下文窗口普及后，向量数据库正在变成"用大炮打蚊子"的典型。一位开发者用SQLite+Claude Haiku 4.5重建了Google的Memory Agent模式，把个人笔记系统的记忆成本压到了接近零。

他的Obsidian助手曾经是个重度失忆患者。每次问"Alice上周批了Q3预算没"，系统都要调用Obsidian MCP（模型上下文协议）翻遍整个知识库。慢、错、烦。

传统解法是上Pinecone或Redis：嵌入、存储、相似性搜索。但这位开发者算了笔账——250K上下文窗口的Haiku 4.5，直接把"检索"变成了"通读"。

Google的野路子：别搜索，让模型自己读

Google Cloud开源了一个叫always-on-memory-agent的项目。核心逻辑粗暴有效：不给LLM做向量检索，直接把近期记忆塞进提示词，让它自己推理。

开发者ccrngd1把这个模式搬到了AWS Bedrock。他的实现叫ProtoGensis，GitHub已开源。

具体结构：每条记忆包含摘要、实体、主题、重要性评分，约300 tokens。250K窗口能塞800条以上。对个人笔记场景，这相当于两年以上的高频记忆。

查询时系统不做相似度计算，而是按时间倒序+重要性筛选，把记忆列表直接喂给模型。Claude自己判断哪些相关。

这绕过了RAG（检索增强生成）的两个老毛病：嵌入模型理解不了"2月1号发生了什么"这种时间查询，也搞不定"上次和这人开会"这种关系型问题。LLM直接读原文，反而能答。

SQLite vs 向量数据库：一场不对称战争

ccrngd1的堆栈极简：SQLite存记忆，Bedrock调Haiku 4.5，无嵌入管道、无向量服务。

对比传统方案：Pinecone按存储+查询量计费，Redis需要运维，Chroma要本地部署。个人用户的时间成本被严重低估——"管道代码的调试时间，够我写三个月笔记"。

他的系统增加了几个实用设计：记忆自动总结（防止膨胀）、实体提取（方便按人/项目过滤）、重要性衰减（旧记忆自动降权）。

一个细节：重要性评分不是预设的。每次交互后，模型会重新评估这条记忆对未来对话的价值，0-10分动态调整。这比固定权重更符合实际使用模式。

上下文窗口的通胀，正在改写架构假设

2023年的模型还在4K-8K tokens挣扎，嵌入是刚需。2025年的Haiku 4.5给到250K，Claude 3 Opus冲到200K，Gemini 1.5 Pro摸到2M。

这个数量级变化让"全部读进去"从不可能变成可行。ccrngd1的测试显示，800条结构化记忆对日常查询足够覆盖——毕竟人脑也不会同时想起两千件事。

但边界清晰可见：企业级知识库、多用户场景、实时协作，向量数据库仍有优势。ProtoGensis的定位是个人工具，"够用就好"的哲学。

另一个隐藏收益：调试简单。向量检索出问题，你要查嵌入质量、分块策略、相似度阈值。LLM直接读，出错了看提示词就行。

ccrngd1在GitHub备注里写了一句："This is a prototype, not a product"。他没做持久化优化，没上并发控制，测试覆盖约等于零。但对他来说，Claude记住Alice批了预算，就够了。

向量数据库厂商会因此焦虑吗？短期不会。Pinecone的营收大头在企业RAG，个人开发者从来不是主战场。但信号明确：上下文窗口的军备竞赛，正在吃掉一部分"中间件"的生存空间。

下一步他会试什么？把记忆结构从SQLite换成纯文本文件，看能不能连数据库也省掉——反正LLM读文本比读SQL更顺手。