DEV Community: VinsonChen

Protect Your Memory Assets

VinsonChen — Tue, 15 Sep 2026 17:47:41 +0000

Every Agent ships with memory now. It's just assumed.

So let me ask: what are you actually trying to solve by adding it?

Is the core of recall accuracy, or usefulness?

Where does your memory live, who controls it, can you take it with you?

Is it just a database that gets queried, or does it participate in understanding the user?

Is what the user said what the user actually wants?

Should a user's memory belong to the user?

Those questions all point me one direction: build a local, vector-free memory.

Local, because memory is an asset — and assets stay in your hands.

No vectors, because I want useful, not accurate.

Why It's an Asset

Everything you talk about with an AI — your preferences, your habits, the mistakes you've made, the context you've explained three times over — that's an asset.

Lose a cache, who cares. Lose an asset, that's a real loss.

So where does it live? Most memory systems keep it on someone else's server. Your conversations get extracted into facts, vectorized, pushed to the cloud. You can't see it, can't change it, switch platforms and it's gone. And anything involving work or client information — once it leaves your machine, you've lost control of it.

So the first thing a memory system should figure out isn't how to recall better. It's who owns these memories, who holds them, and whether you can take them with you.

1. Usefulness

Everyone's racing on recall precision right now. RAG, vector stores, rerankers — each generation better than the last.

But is the core of recall accuracy, or usefulness?

No matter how precise, it's still search. You ask something, the system dumps everything "relevant" into context and burns a pile of tokens.

Say you're chatting and ask, "hey, what happened with that thing?"

What you want is: "That review last Wednesday, right? Option A went through."

What a recall-optimized system does is dump the entire event record for that review. The cause, the process, the conclusion, who was there, how you felt, the follow-up discussion. All of it.

It's accurate. 100% relevant. But do you actually need it?

Think about how people remember.

It's perception-driven. First you sense what the other person needs, then you decide which layer of memory to pull. When you recall something, what surfaces is the outline, not the full text. Details only come out when the conversation goes deeper.

So: three layers. Shallow gives a cognitive summary. Medium gives an overview. Deep gives the full content.

People don't retrieve then answer. They perceive, then respond.

And I don't use vectors.

There's no cosine similarity in your head. Recall happens through features — a sound, a face, a smell, and then "oh, right."

Feature tags are explainable, editable, lightweight. You know why something was recalled, and you can fix it directly. When vectors go wrong you tune parameters and hope. When tags go wrong you can see exactly which two got connected.

But no vectors doesn't mean it's simpler.

Tags are alive. The same idea, and the LLM outputs "tag pool," "tag pool management," "tag library" — three different names. What do you do?

My first instinct was to merge them. That was wrong.

The goal of a tag pool isn't cleanliness. It's full recall.

Merging means deleting an entry point. The next time the user says exactly the word you deleted, that memory is unreachable. So I switched to relational coexistence — don't eliminate tags, link them so they can find each other.

And that's just one problem.

Generic words like "issue" or "handle" only pollute recall, so they need to retire. But when the filter was only in the database layer and not the in-memory cache, they were still being recalled in the same process. Deduplication was worse: retired tags still occupy their name and ID, so if the dedup query filters them out, the system thinks "this doesn't exist," creates a new one, and hits a UNIQUE constraint violation.

All of that I ran into myself. A vector approach won't hit these, but it hits its own set: black box, not editable, can't tune it.

Nothing's free. Just different tradeoffs.

2. Security

This is the one I won't compromise on.

All data stays local. No cloud dependency. Just SQLite and JSON files on your own disk. No embedding service, no sending conversations to a third party, works offline.

Data doesn't leave. Work content, client information, personal habits — not a single line leaves your machine.

White box. Memory is plain JSON. Open it and see exactly what it recorded about you.

Explainable. No vectors, so every recall can explain itself: which tag matched, how it spread to related tags, why this card ranked higher.

Lightweight. Only SQLite and System.Text.Json. No GPU.

Your memory, your custody.

3. Asset Growth

After each conversation, the C-line settles things asynchronously: records the event, writes the overview, completes tags and scene, corrects preferences. The longer you use it, the richer the pool, the more precise the injection.

More importantly, it understands you — not just the conversation content. Your preferences, your habits.

So what exactly is the "digital twin" part?

Layer	Capability	Example
One	Remember facts	"He hates long replies"
Two	Understand preferences	"Conclusions at work, can ramble when chatting"
Three	Read unspoken intent	"He's asking if the plan works, but he's actually hesitating"

The first two are remembering. The third is what makes it like him.

What users say and what users want often aren't the same thing. "What happened with that thing" might mean "I don't remember the details, just give me a summary." "Does this plan work" might mean "I'm on the fence, give me a verdict."

Only memory can fill that gap. With memory, it knows you said last time "don't give me a list of options, just tell me the answer" — so this time it gives you the answer.

That's why memory shouldn't just be a component that gets queried. It participates in understanding the user.

And the twin is portable. Open formats, so switching models or machines — your assets come with you.

In the End

	My Choice
Memory unit	Feature tags, not fact triples
Retrieval	Feature matching + relation spread, not vector similarity
Injection	Perception-driven, shallow/medium/deep, not dump-everything
Role	Participates in understanding the user, not just a database
Storage	Local SQLite + JSON, not cloud
Goal	Useful, not accurate

Recall accuracy still matters. It's the foundation. I just think two layers get discussed far too little: whether to inject at all, how much, and at what granularity — and who these memories belong to, who holds them.

Memory is ultimately the core asset humans accumulate.

Open source: VinsonWild/Wangdefa.Memory

保护你的记忆资产

VinsonChen — Tue, 15 Sep 2026 17:46:55 +0000

现在凡做 Agent 必有记忆体。

我且问一句：你加它，想解决什么？

召回的核心，是准确，还是有用？

你的记忆存在哪，归谁管，能不能带走？

它只是被查的资料库，还是参与理解用户的一部分？

用户说的，就是他想要的吗？

用户的记忆，是不是应该属于他自己？

基于这几个问题，我的思路是：做本地化的无向量记忆。

本地化，因为记忆是资产，得在自己手里。

无向量，因为我要的是有用，不是更准。

为什么是资产

你每天跟 AI 聊的东西，你的偏好、你的习惯、你踩过的坑、你解释过三遍的背景，都是资产。

缓存丢了无所谓，资产丢了是损失。

可这些资产存哪。多数方案存别人服务器上，抽成事实、向量化、进云端。你看不到，改不动，换个平台归零，涉及工作内容和客户信息的，出域就控制不了。

所以记忆体第一件要想清楚的，不是怎么召得更准，是这些记忆归谁、谁保管、能不能带走。

一、有效性

现在都在卷召回精确。RAG、向量库、重排模型，一代比一代强。

可召回的核心，是准确，还是有用？

搜得再准，也是搜索。你问一句，系统把"相关"的全塞进来，烧一堆 token。

比如你闲聊问"上次那个事怎么样了"。

你要的是"上周三那场评审吧，方案 A 过了"。

而追求召回准确率的系统，会把那场评审的完整记录全塞进去。召得没错，百分之百相关。可你需要吗。

人怎么回忆的。

感知驱动。先知道对方要什么，再决定调哪层记忆。回忆一件事，脑子里先出轮廓，不是全文，聊深了才调细节。

所以分三层：浅给认知摘要，中给概要和概览，深给完整内容。

人不是先检索再回答，是先感知再驱动。

还有，我不用向量。

人脑子里没有余弦相似度。想起一件事都是特征触发的，一个声音、一张脸、一个味道，"想起来了"。

特征标签可解释、可编辑、轻量。你知道它为什么召回，错了直接改。向量出问题只能调参看运气，标签出问题你能看到是哪两个连上了。

不过不用向量不代表更简单。

标签是活的。同一件事，LLM 会输出"标签池"、"标签池管理"、"标签库"三种，你怎么办。

我一开始合并，后来发现错了。

标签池的目标不是干净，是召回全。

合并等于删掉一个入口，用户下次说的恰好是删掉那个词，就再也找不到。改成关联式共存，建关联让它们互相能找到。

这只是个坑。泛用词像"问题"、"处理"，放池子里只污染召回，得让它们退场。可过滤只做在数据库层、内存缓存漏了，同一进程内还在被召回。判重更麻烦，退场的标签还占着名字和编号，判重查询把它过滤掉，系统以为"不存在"，重新建一个，撞唯一约束报错。

都是我自己踩出来的。向量方案不会遇到这些，但会遇到黑盒、不可编辑、调不动。

没有免费方案，只有取舍。

二、安全性

数据全在本地，不依赖云端。就是 SQLite + JSON，存你自己磁盘上。不用 Embedding 服务，不把对话发给第三方，断网也能跑。

数据不出域。 工作内容、客户信息、个人习惯，一行都不离开你的机器。

白盒可控。 JSON 明文，打开就能看记了你什么。

可解释。 不用向量，每次召回都能说清：哪个标签命中的、怎么扩散的、为什么排前面。

轻量。 只依赖 SQLite 和 System.Text.Json，不要 GPU。

你的记忆，你自己保管。

三、资产增值

每次对话结束，C 线异步沉淀：记录事件、写概览、补全标签与场景、修正偏好。用得越久，池子越丰富，注入越准。

更关键的是，它理解的是你这个人，不只是对话内容——你的偏好、你的习惯。

分身分的是什么。

层次	能力	例子
一	记住事实	"他讨厌冗长的回复"
二	理解偏好	"工作要结论，闲聊可以铺开"
三	解读潜在意图	"他问方案行不行，其实在犹豫"

前两层是记住，第三层才是像他。

用户说的和用户要的，经常不是一回事。"上次那个事怎么样了"，可能是"我记不清了，给我个摘要"；"这个方案行不行"，可能是"我在犹豫，想要个判断"。

这层只有记忆能补上。有记忆，它知道你上次说过"别给我一堆选项，直接说结论"，这句就直接给判断。

所以记忆体不该只做被查询的组件，它参与理解用户。

另外分身可迁移，格式开放，换模型、换机器，资产都跟着你走。

最后

|---|---|
| 记忆单元 | 特征标签，不是事实三元组 |
| 检索方式 | 特征匹配 + 关联扩散，不是向量相似度 |
| 注入策略 | 感知驱动，浅/中/深三层，不是全量塞入 |
| 角色定位 | 参与理解用户，不只是资料库 |
| 存储位置 | 本地 SQLite + JSON，不是云端 |
| 优化目标 | 有效，不是更准 |

召回准确度该卷还是要卷。我只是觉得还有两层不能被忽略：召回之后给不给、给多少、给什么粒度；以及这些记忆归谁、谁保管。

记忆终还是人类可累计的核心资产。

项目开源：VinsonWild/Wangdefa.Memory

Wangdefa.Memory — 本地优先的 Agent 五层记忆体组件

VinsonChen — Mon, 10 Aug 2026 10:20:51 +0000

我改了下

title: "Wangdefa.Memory — 本地优先的 Agent 五层记忆体组件"
published: true
description: "我们做了一个无向量、无云端依赖的 Agent 记忆体，想试试\"像人一样记住事情\"这条路能不能走通。"

tags: showdev, dotnet, ai, opensource

人类最需要的 Agent，不是理解明面上的指令，而是能洞察未表达的需求。

我们认为人类对于记忆力的感知关系永远不应该通过向量计算而得出，所以我们避开了当前主流RAG实现方式，尝试使用无向量技术路线进行了一次技术探索。

希望让Agent获得更贴近人类记忆索的运行机制。

人类是怎么记住事情的

你还记得十年前的某个下午和谁聊过什么吗？当时的场景、天气、氛围又是如何的呢？

比如十年前的一次对话，我能记得的是：当时跟谁、在哪、大概聊了什么、对方当时的语气、我当时的情绪。具体说了哪些字，早就忘了。

但那些记忆还在，只是被压缩了。

等某个场景触发，我能重新想起来，而且想起来的内容是"整块的"，不是碎片。

人不会一下子记住所有细节，而是会通过对现在场景的需求进行浅、中、深不同程度的回忆。

基于认知的快速回应，
基于事件的开阔性描述，
基于细节的全盘回忆探索。

——这套机制跟关键词检索、向量匹配完全不是一回事。

一个人记住事情，通常是这样几个步骤：

感知：发生了什么
特征提取：什么值得记
近义关联：跟已有的记忆连上
压缩存储：只保留关键信息
遗忘：时间久了权重下降
重新激活：被触发时整段调出

所以，人类实际的记忆感知与 RAG 应该是大相径庭的。

而实现类人的Agent记忆，就需要找到人类与机器之间的共性存在，什么是他们的共性？

记忆特征，人类对画面对事件的所有细节特征，转化成机器语言就是【特征标签】。

而机器又是比人类更适合处理大量特征标签的存在。

基于上述内容做了这个东西

Wangdefa.Memory 是按照这套"人类记忆模型"来设计的五层记忆体组件。

五层对应的是：

认知层：记录发生了什么
特征推演层：从记录里提取特征，建标签
思考层：把当前对话跟已有记忆做关联
阅历层：存完整事件和知识
传递层：控制记忆怎么被读取

核心不是关键词匹配，是特征推演。

它通过标签池、密码簿、特征统计三者配合，实现精准匹配、近义扩展、多轮循环匹配，最后按时间衰减排序。

你不需要教 Agent 怎么搜索——它会自己沿着特征关联找到相关记忆。

它的设计选择

无向量：不做向量检索
无云端：全部本地存储，SQLite + JSON
无依赖：只需要 .NET 10 和两个基础包
只为记忆：它不是一个 Agent 框架，只是一个记忆组件

你可以接入现有的 Agent 系统，也可以单独测试。

代码和示例

Repo 里有一份完整的 README 和 ConsoleDemo，三分钟可以跑通整套写入-查询流程。

GitHub: https://github.com/VinsonWild/Wangdefa.Memory

目前是 Apache 2.0，.NET 10。

最后

我做的这件事，出发点其实很简单——人是怎么记住事情的，能不能让 Agent 也这样记住。

现在还在很早期的阶段，但它已经能跑了。如果你也在做 Agent 方向，欢迎试，欢迎提 Issue，欢迎指出我理解不对的地方。