# The Skeleton of Remembering: Why Your Filesystem Is a Brain Waiting to Happen
**作者**: Ashwin Gopinath
**日期**: 2026-04-14T16:10:36.000Z
**来源**: [https://x.com/ashwingop/status/2044085923185602747](https://x.com/ashwingop/status/2044085923185602747)
---
TL;DR
- A designer sees the Golden Gate Bridge and remembers International Orange. An engineer sees cables. A biologist remembers a whale. Same object, three memories, because memory is not knowledge storage. It is a utility function.
- Karpathy's LLM Wiki and Garry Tan's GBrain are building knowledge bases, structured records of what is true. Memory is something else: it encodes why something matters, to whom, and manages how that changes over time. The difference matters at scale.
- Obsidian wikilinks create a graph, but one you cannot query programmatically, traverse multi-hop, or put access controls on. Flat markdown does not scale.
- SMF is our response: POSIX symlinks are the knowledge graph edges. ls -la reveals the graph. No separate graph database. Native access control. Scales to millions of entities without touching a context window. With Amazon S3 Files (April 2026) delivering native POSIX filesystem semantics on S3, the entire SMF architecture can now run on cloud-scale object storage with S3 durabilityand pricing.
- Structure over scale: on LoCoMo, a well-structured filesystem-native memory with BM25 + graph traversal achieves the same strict J-score as a much richer 14+ channel stack, and a 50× model scale increase only buys +0.081 J-score under a dedicated GPT‑4.1 judge. Architecture dominates scale.
- We are open-sourcing the core. Production goes further. https://github.com/dynamis-Labs/SMF
Memory is another meta problem with AI, and it is one that the field is approaching from the wrong direction.
The instinct is to build bigger knowledge bases. Index more documents. Store more facts. Embed everything. The assumption is that memory is a retrieval problem, that if you can find the right document when you need it, you have solved memory.
This is wrong, and we showed why in The Price of Meaning: any memory system that retrieves by semantic similarity will exhibit interference-driven forgetting and false recall as it grows. No architecture within the theorem class avoids this (the proof is in the paper). The theorem identified three exits: abandon semantics (kills usefulness), send effective dimensionality to infinity (impossible), or add an external symbolic verifier that provides exact episodic grounding. The same spectral concentration we exploited for compression in SpectralQuant and mapped to memory failure in The Geometry of Forgetting is what makes the problem inescapable.
External symbolic grounding was the only viable exit. And here is the empirical punchline: once you build the right retrieval structure around that grounding, a carefully structured filesystem-native memory backed by an 8B or 70B model can sit within a few points of a frontier model under strict judging, and a dramatically simplified retrieval stack (BM25 + graph + facts + temporal) matches a full 14+ channel stack on J-score.
Architecture dominates scale. SMF is that architecture.
Code is at https://github.com/dynamis-Labs/SMF
# Knowledge bases are not memory
Before we describe the architecture, we need to be precise about a distinction that the current conversation conflates.
In early April 2026, Andrej Karpathy shared his approach to building personal knowledge bases with LLMs. The system is elegant: drop raw sources into a raw/ folder, have an LLM compile them into a wiki of ~100 interlinked markdown articles (~400K words), use Obsidian as the IDE, and let the LLM auto-maintain index files and backlinks. No vector database. No embedding pipeline. Karpathy noted: “there is room here for an incredible product.” He was right, the approach works remarkably well at personal scale.
Days later, Garry Tan, CEO of Y Combinator, open-sourced GBrain: a TypeScript/Bun system backed by PostgreSQL + pgvector that indexes 10,000+ files, builds entity relationships and cross-references, and runs a nightly “dream cycle” that enriches the knowledge graph while you sleep. GBrain has entity types, cross-referencing, 30+ MCP tools, and a “compiled truth + timeline” pattern that separates current synthesis from append-only evidence.
Meanwhile, the Obsidian community has been building graph-structured knowledge systems using wikilinks ([[ ]]) to create bidirectional connections between notes. The graph view is beautiful. Tools like Cognee bolt on LLM-driven entity extraction and relationship mining. Developers are using Obsidian vaults as persistent memory for Claude Code, Cursor, and other AI agents.
These are all genuine contributions. We want to honor what they represent: a clear-eyed recognition that files beat vector databases, that human-readable formats outlast proprietary APIs, and that structure matters. Every engineer who has tried to debug a 1,024-dimensional embedding query understands viscerally why this movement exists.
But there is a distinction worth being precise about.
Karpathy's LLM Wiki is a knowledge base, and he positioned it as exactly that. The LLM compiles, organises, and interlinks facts. The output is a structured personal reference. The distinction we are drawing is not a critique of what he built, it is a clarification of where the broader conversation conflates knowledge bases with memory. The wiki solves knowledge management at personal scale. It does not model who needs what information and why. It does not weigh relevance against purpose. It does not forget. Memory requires something more.
GBrain is a richer knowledge base. The entity relationships and cross references bring it closer. The dream cycle adds temporal enrichment. But the architecture is fundamentally “compiled truth”, a running synthesis of what Garry Tan knows, stored in PostgreSQL with vector search bolted on. It depends on an external database service to function. It does not encode access control at the storage level. It does not model the purpose of remembering. It is a knowledge management system, and a good one. It is not memory.
Obsidian-based systems are graph-shaped knowledge bases. Wikilinks create connections, and the graph view visualises them. But you cannot query that graph programmatically. There is no multi-hop traversal. There are no typed relationships. There is no access control. And when the vault grows beyond what fits in a context window, the system degrades, which is exactly why OpenClaw bolted on SQLite and vector search: “A folder of linked markdown files is not a graph database.”
Structural comparison table: Karpathy Wiki vs GBrain vs Obsidian vs SMF (this work)
The distinction matters because memory is not about recording what is true. Memory is about encoding what matters, to whom, for what purpose, and managing how that encoding changes over time. A knowledge base answers: “What do I know?” Memory answers: “What will I need?”
This has a direct consequence for how we interpret benchmarks. Knowledge base systems are optimised for information retrieval: given a query, find the most relevant document. Their benchmarks measure retrieval accuracy, and that is appropriate. But memory systems have a broader mandate. Retrieval is necessary but not sufficient. A memory system must also maintain relationships, manage lifecycle, enforce access control, handle contradictions, and forget what no longer matters. None of these capabilities are captured by retrieval benchmarks. When we compare SMF's LoCoMo numbers against ByteRover's or Letta's, we are comparing retrieval accuracy, one dimension of a multi-dimensional problem. The dimensions where SMF's architecture pays its highest dividends (relational durability, access control, scalability, lifecycle management) are not measured by any current benchmark.
This is where SMF enters.
# Why memory is hard: the utility function problem
The retrieval gap is one dimension of the problem. But there is a deeper one that affects not just how we evaluate memory systems, but how we build them.
Memory depends on the observer's utility function.
Consider the Golden Gate Bridge. A designer looks at it and remembers International Orange, the colour Irving Morrow chose to complement the natural surroundings and maintain visibility in San Francisco's fog. A structural engineer looks at the same bridge and sees the cables: 80,000 miles of wire, 746-foot towers, the tensile forces that keep 894,500 tonnes of steel suspended across the strait. A marine biologist who was on a research vessel last Tuesday remembers a whale passing under it.
The utility function problem: same object, three observers, three memories
Same object. Three completely different memories. Not because anyone's memory is wrong, but because each observer has a different utility function, a different answer to the question: “What will I need to remember later?”
This creates a fundamental problem for benchmarking. If you ask all three observers about the Golden Gate Bridge and score their answers against a single gold reference, two of the three will appear to have “failed”, even though each remembered exactly what they needed to. Every memory benchmark implicitly bakes in a utility function: it decides which answers count as correct. When we score memory systems on LoCoMo or any other benchmark, we are not measuring memory quality in the abstract. We are measuring how well a system's utility function aligns with the benchmark's. This is not a grain of salt. It is the entire framing.
Memory is not about recording everything. It is purpose-driven compression. An organism (or an organisation, or an AI agent) that tries to remember everything about everything will drown in its own records. A system that knows what questions it will need to answer can be ruthlessly selective about what it stores and how it indexes it.
This has a direct and underappreciated consequence for memory systems. The narrower the memory's purpose, the easier it is to build the memory. An organisation's memory is easier than an individual's, because the utility function is more constrained: who is responsible, what was decided, what commitments were made, what the rationale was. An individual's memory is harder because the utility function is broader and less predictable. A general purpose AI agent's memory is hardest of all, because the utility function is essentially “anything the user might ask about anything that has ever happened.”
Karpathy's Wiki, GBrain, and Obsidian-based systems push the utility function into the LLM at query time: the model decides what matters when you ask. SMF encodes the utility function into the storage structure itself. The 8 entity types, the symlink schemas, the confidence scoring, the zone management, all of these are structural implementations of the claim that certain kinds of information matter more than others, and that relationships between those things matter most of all.
The strongest counterargument is that dynamic utility functions are more flexible. If the LLM decides at query time what matters, it can adapt to novel questions. This is true, and for personal tools it is the right tradeoff: your needs change constantly, re-reading is cheap, and a single user does not need access control. But for organisational memory, durability matters more than flexibility. Compliance, auditing, accountability, and multi-agent access all require that relationships survive model changes, employee turnover, and time. An organisation needs to know who decided what, when, why, and what was committed, and it needs those answers to be model-independent and permission-governed. That is where structural encoding wins.
We built SMF for organisational memory first because that is where the utility function is most constrained and therefore most encodable. But the architecture is not limited to this. The entity type system is a pluggable schema. A clinical memory might replace VCOs with diagnoses and rationale with treatment plans. A legal memory might track obligations, precedents, and jurisdictions. A research memory might track hypotheses, experiments, and evidence chains. The structural principle, encode your utility function
into typed entities connected by symlinks, is general. The specific entity types are the part you adapt to your domain.
# What SMF does differently: the filesystem IS the knowledge graph
The central architectural insight of SMF is that POSIX symlinks, the humble ln -s that every Unix system has supported for nearly half a century, are zero cost relational pointers. A symlink from /memory/actors/alice/related/collaborated_with/bob to /memory/actors/bob/ is a typed, directed edge in a knowledge graph. It costs almost nothing to create. It costs almost nothing to traverse. It requires no separate graph database. And ls -la reveals the relationship structure to any human or agent that looks.
This is, to our knowledge, something nobody else has done for POSIX-based agent memory. Not Karpathy's Wiki (no explicit filesystem-level relationships between entries). Not GBrain (relationships live in PostgreSQL, not the filesystem). Not Obsidian (wikilinks are text references in markdown, not
filesystem-level pointers).
The symlink approach is the design choice that makes everything else possible.
SMF organises memory into 8 entity types, each stored as a directory:
8‑type ontology table as in current blog
Why these 8 and not 6 or 12? Because they are the minimal set that closes the organisational utility function: who (actors), what happened (interactions, events), what was decided (decisions), why (rationale), what was committed (VCOs), when (time), and about what (topics). Remove any one and you lose a question type that organisations routinely need answered. Add more and you introduce categories that can be composed from these primitives. The taxonomy is opinionated, and deliberately so.
A single SMF entity on disk: metadata, abstract and typed symlinks forming the knowledge graph.
Each entity is a directory containing content.md (canonical content), meta.json (structured metadata), a related/ subdirectory containing symlinks to related entities, and .provenance.jsonl capturing how the entity was produced. The symlinks are typed: collaborated_with, decided_at, updates, contradicts, derives, extends. The filesystem itself encodes the knowledge graph. No external graph store. No separate schema DSL. No GraphQL endpoint. Just directories, files, and symlinks.
Think about what this means operationally. An agent that needs to understand the context around a decision can ls /memory/decisions/switch-to-postgres/related/ and immediately see every related entity: the actors involved, the rationale, the meeting where it was discussed, the commitment it fulfilled. No embedding lookup. No graph traversal engine. No LLM call. Just a directory listing. The graph is inspectable with tools that predate the internet.
# Where SMF surpasses knowledge base approaches: scalability and access control
This architectural choice, symlinks as graph edges, gives SMF two properties that no knowledge base approach can match natively.
Scalability without context window dependence. Karpathy's Wiki works at ~100 articles because the LLM can read index files and navigate. GBrain works at 10{,}000+ files because PostgreSQL handles the search. Obsidian based systems degrade when the vault outgrows the context window. SMF's symlink graph has no such ceiling. Traversal is readlink and ls, kernel-level operations that work at millions of entries. The graph does not need to fit in a context window to be navigable.
And as of April 7, 2026, scalability takes another leap. Amazon S3 Files delivers native POSIX filesystem semantics on S3 buckets: mount via NFS v4.2, perform standard file operations, with POSIX permissions preserved as S3 object metadata. This means SMF's entire symlink-based knowledge graph can run on S3: effectively infinite storage at $0.023$/GB-month, 11 nines of durability, concurrent access from up to 25,000 compute resources, and the same ls -la inspectability.
Practical grounding: what happens at real scale. Symlink creation on POSIX is atomic; there are no partial states and no write conflicts at the filesystem level. Stale symlinks are detected and pruned by the gardener cycle during META-REFLECT. Dangling symlinks are a feature of POSIX, not a bug: readlink
returns the target path whether or not the target exists, so traversal does not crash on a stale edge.
Native access control. Unix file permissions, chmod, chown, ACLs, apply to every entity directory and every symlink in SMF. An entity can be readable by one team and invisible to another. SMF implements 4 sensitivity levels (public, internal, confidential, restricted) with identity-based access and section-level redaction. This is not a feature bolted on top. It is a natural consequence of using the filesystem as the storage layer. POSIX gave us access control for free.
# How it works: brain-like, not by metaphor
The symlink web in SMF, with its confidence-weighted edges, shortcut creation, and zone-based forgetting, mirrors three well-documented properties of biological memory:
1. Synaptic strengthening. When two memories are accessed together, SMF can create or strengthen shortcut symlinks between them, reducing the hop count for future traversal. This is the filesystem equivalent of Hebbian learning: neurons that fire together wire together.
2. Memory consolidation and zones. SMF implements a zone-based lifecycle (hot → warm → cold) governed by Bjork's New Theory of Disuse, which models memory strength as two independent quantities: storage strength (how well something is encoded) and retrieval strength (how accessible it is right now). Retrieval strength decays with disuse; storage strength does not.
3. Pruning. SMF's gardener cycle prunes weak edges and demotes low confidence facts, analogous to synaptic pruning during sleep. Memories that have not been accessed for extended periods gradually become inaccessible without being destroyed. This is forgetting done right: not deletion, but deprioritisation.
Zone-based memory lifecycle: hot to warm to cold with dual-score model.
Knowledge bases do not forget. They should not; that is their job. But memory systems must, because unbounded accumulation without relevance decay is not memory. It is hoarding.
# The six-stage pipeline: from conversation to knowledge graph
SMF processes raw conversations through a 6-stage pipeline that progressively transforms unstructured text into a connected knowledge graph:
The 6-stage pipeline: fast models handle extraction, frontier models handle reasoning.
The pipeline is asymmetric by design. Stages 0–2 use fast, cost-effective models for high-throughput extraction and linking. Stages 3–5 use frontier models for reasoning-heavy enrichment and reflection. In the LoCoMo benchmark configuration, Stages 4 and 5 are disabled; the architecture is present, but the pipeline stops after Stage~3 for evaluation.
The LINK stage is the critical one: it resolves entity references (merge threshold ≥ 0.85, conflict range 0.40–0.84), creates typed bidirectional symlinks, and grows the knowledge graph with every ingested conversation. A 30-alias normalization layer handles the inevitable inconsistency in LLM-generated entity types.
# The retrieval architecture: 14 channels, not 4
This is where the open-source release goes substantially beyond the original four-channel story. The canonical pipeline began with BM25, embeddings, graph traversal, and temporal filtering. The actual system implements 14+ channels, all fused through Reciprocal Rank Fusion and routed by query mode:
Three-layer retrieval: parallel channels → RRF → agentic ReAct loop → Self-RAG validation.
The system detects query intent and routes to different channel weightings depending on the query type. Seven query modes, factual, temporal, counting, multi-session, preference, summarisation, contradiction, each have custom RRF weight profiles.
On top of the parallel retriever sits an agentic retriever: a ReAct loop with 9 tools that runs up to 5 iterations and short-circuits at 0.75 confidence. Post retrieval, Self-RAG validation can verify the generated answer claim-by-claim against retrieved sources.
# Why benchmarking memory is fundamentally hard
We return to the utility function problem, because it is the lens through which every number below must be read.
Every memory benchmark implicitly defines a utility function. LoCoMo asks questions about long-form conversations. These are good questions that test retrieval accuracy, one axis of memory quality. But retrieval accuracy is not the only axis. A memory system that retrieves perfectly but cannot enforce access control is unusable in an enterprise.
The Golden Gate Bridge problem from earlier applies directly: LoCoMo's utility function determines which answers count as correct. A benchmark that tested relational durability, access control, contradiction handling, or lifecycle management would produce a different ranking. No such benchmark exists yet.
With that stated clearly, here are the numbers, as we believe they should be reported.
# Benchmark results: structure over scale
Retrieval architecture and memory structure matter more than model scale.
We evaluate SMF on the LoCoMo benchmark with a dedicated GPT‑4.1 judge independent of the QA model, using strict prompts that require matching the same core fact and meaning, not just “touching the same topic”. Earlier self-judged runs (where the QA model graded its own answers) produced inflated J-scores and are omitted here except where noted as mechanical F1.
A representative slice (1 conversation, 199 QA pairs) looks like this:
A roughly 50× increase in model scale (8B → Sonnet) moves J-score by only 0.081 under a strict, dedicated judge. The architecture, the filesystem-native graph, temporal index, fact store, BM25, and retrieval pipeline, remains the same.
Even more striking is the retrieval ablation:
The baseline configuration disables dense embedding search, RAPTOR hierarchical summaries, hierarchical/agentic retrievers, the Retrieval Reflector, self-RAG validation, and cross-encoder reranking. It keeps only BM25 (entities and facts), graph traversal, and a temporal index. J-score and match counts are identical. There is a shared core of 149 questions where both configurations agree; the remaining questions are traded between them.
The structure-over-scale punchline: C4 (70B + rich retrieval) beats C1 (frontier + simple retrieval).
In other words: a deployment that \emph{only} uses BM25 + symlinks + temporal can match the aggregate strict J-score of a full 14+ channel stack. Organisations can choose retrieval complexity as a function of their workload: full stack for open-domain heavy workloads, baseline for precision-oriented multi-hop, or something in between.
## Comparison against the field
Let us be honest about where we stand.
Systems evaluated with LLM-as-Judge on LoCoMo
Systems evaluated with token-level F1 on LoCoMo
Systems not benchmarked on LoCoMo
ByteRover achieves higher raw benchmark scores. We are not going to pretend otherwise. But there is a distinction worth making between benchmark performance on one test and architectural properties that determine long-term behaviour.
SMF's relationships are explicit and non-parametric. The symlink from actors/alice/.rels/collaborated_with/bob to actors/bob/ exists on disk. It survives model changes. It is traversable without an LLM call. ByteRover's relational knowledge is parametric, reconstructed at inference time.
Under lenient judging, large systems report J-scores in the 88–96% range on LoCoMo. Under the strict judge we use, SMF lands around 70% J on the same tasks, and so do other systems when re-evaluated through safer prompts and stricter judges. We do not pretend that J=0.704 is the highest number in the ecosystem. We do claim that it is a more honest number.
The more important distinction, for us, is structural:
- SMF's relationships are explicit and non-parametric. The symlink from actors/alice/related/collaborated_with/bob to actors/bob/ exists on disk. It survives model changes. It is traversable without an LLM call.
- Many competing systems store relational structure parametrically inside model weights or in opaque graph stores. Their relations are reconstructed at inference time rather than inspected directly.
## What we are open-sourcing
The repository at https://github.com/dynamis-Labs/SMF contains the core of SMF:
- The full 6-stage pipeline (0-indexed: INGEST through META-REFLECT)
- All 8 entity types with Pydantic models, subtype schemas, and alias table
- The parallel retriever with 14+ channels and RRF fusion
- The agentic retriever (ReAct loop, 9 tools, max 5 iterations)
- 7 query modes with per-mode channel routing and weight profiles
- Self-RAG validation hooks for claim-by-claim checking
- The lifecycle subsystem: gardener, garbage collection, zone management with Bjork's New
Theory of Disuse (disabled in current benchmarks, implemented in code)
- Security and ACL: 4 sensitivity levels, identity-based access, section-level redaction
- An MCP server with 12 tools, 5 resources, and 4 prompts for agent integration
- Circuit-breaker inference routing across multiple providers (Groq, Cerebras, Claude, OpenAI,
Gemini, Modal)
We are not releasing everything. The production system adds capabilities specific to error correction, multi-tenant organisational deployment, cross-organisation memory isolation, advanced lifecycle tuning, and integrations with enterprise communication channels. The open-source release is the architecture and the core pipeline. The production system is where it becomes a product.
## What comes next
Forgetting and false recall are the price of meaning. SMF does not claim to have escaped that tradeoff. It claims to be a principled navigation of the frontier. The filesystem provides exact episodic storage. The semantic layer provides generalisation, analogy, and conceptual transfer. The symlinks bridge the two: they are simultaneously exact (a symlink either exists or it does not) and semantic (the relationship types encode meaning).
The brain does something similar. Fast hippocampal encoding creates episodic records. Slow neocortical consolidation extracts semantic structure. SMF's architecture mirrors this interplay, not as a metaphor, but as a structural implementation: rapid ingestion through the fast-model stages (0 2), slower enrichment and synthesis through the frontier-model stages (3–5), and continuous maintenance through the gardener and zone manager.
The question the field should be asking is not “How do we build a better knowledge base?” It is: “What does this agent need to remember, and why?” The answer to that question is a utility function. And the best memory systems are the ones that encode it structurally rather than leaving it to the model to figure out at inference time.
At Sentra, that utility function is the collective memory of a company: who decided what, when, why, and what was committed. The entity types, the symlink schemas, and the lifecycle management are all in service of that specific purpose, because an organisation that cannot remember what it committed to is an organisation that cannot be held accountable.
Code: https://github.com/dynamis-Labs/SMF
SpectralQuant: https://github.com/Dynamis-Labs/spectralquant
The Geometry of Forgetting: https://arxiv.org/abs/2604.06222
The Price of Meaning: https://arxiv.org/abs/2603.27116
This is the fifth in a series. SpectralQuant showed that 97% of dimensions are noise and exploited the spectral gap for compression gains. The Geometry of Forgetting showed the same spectral concentration governs memory failure. The Price of Meaning proved the failure is inescapable. SMF is the architectural response. Same eigenvalue spectrum, four different consequences: compression, attention, the mathematical limits of memory, and now the system that takes those limits seriously. All grew out of the research program at Sentra, where we are building enterprise general intelligence: a shared AI layer that sits on all communication channels and agent traces to understand how everyone in an organization actually works and how work actually gets done, constructing a living world model of the entire company in near real time.
## 相关链接
- [Ashwin Gopinath](https://x.com/ashwingop)
- [@ashwingop](https://x.com/ashwingop)
- [Amazon S3 Files (April 2026)](https://x.com/awscloud/status/2041611271565381968?s=20)
- [https://github.com/dynamis-Labs/SMF](https://github.com/dynamis-Labs/SMF)
- [https://github.com/dynamis-Labs/SMF](https://github.com/dynamis-Labs/SMF)
- [https://github.com/dynamis-Labs/SMF](https://github.com/dynamis-Labs/SMF)
- [https://github.com/dynamis-Labs/SMF](https://github.com/dynamis-Labs/SMF)
- [https://github.com/Dynamis-Labs/spectralquant](https://github.com/Dynamis-Labs/spectralquant)
- [https://arxiv.org/abs/2604.06222](https://arxiv.org/abs/2604.06222)
- [https://arxiv.org/abs/2603.27116](https://arxiv.org/abs/2603.27116)
- [Sentra](https://www.sentra.app/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:10 AM · Apr 15, 2026](https://x.com/ashwingop/status/2044085923185602747)
- [7,095 Views](https://x.com/ashwingop/status/2044085923185602747/analytics)
- [View quotes](https://x.com/ashwingop/status/2044085923185602747/quotes)
---
*导出时间: 2026/5/1 10:32:17*
---
## 中文翻译
# 记忆的骨架：为何你的文件系统是一个正在等待发生的大脑
**作者**: Ashwin Gopinath
**日期**: 2026-04-14T16:10:36.000Z
**来源**: [https://x.com/ashwingop/status/2044085923185602747](https://x.com/ashwingop/status/2044085923185602747)
---
TL;DR
- 设计师看金门大桥，记得“国际橙”；工程师看到的是缆绳；生物学家想起的是鲸鱼。同一个物体，三种记忆，因为记忆不是知识存储，而是一个效用函数。
- Karpathy 的 LLM Wiki 和 Garry Tan 的 GBrain 正在构建知识库，即关于“什么是真”的结构化记录。记忆则是另一回事：它编码的是“为什么某事重要”、“对谁重要”，并管理这种相关性如何随时间变化。在规模化场景下，这种区别至关重要。
- Obsidian 的 wikilink 能创建图谱，但你无法以编程方式查询、无法进行多跳遍历，也无法设置访问权限。扁平式的 markdown 无法扩展。
- SMF 是我们的回应：POSIX 软链接就是知识图谱的边。`ls -la` 即可揭示图谱。无需独立的图数据库。原生访问控制。可扩展至数百万个实体，且无需触及上下文窗口。随着 Amazon S3 Files（2026年4月）在 S3 上提供原生 POSIX 文件系统语义，整个 SMF 架构现在可以在云规模的对象存储上运行，并享有 S3 的持久性和定价。
- 结构重于规模：在 LoCoMo 上，一个结构良好的、基于文件系统的原生记忆（配合 BM25 + 图遍历）就能达到与丰富得多的 14+ 通道堆栈相当的严格 J-score，而在专用 GPT‑4.1 评判下，模型规模增加 50 倍仅能带来 +0.081 的 J-score 提升。架构胜过规模。
- 我们正在开源核心部分。生产环境的应用更进一步。https://github.com/dynamis-Labs/SMF
记忆是人工智能面临的另一个元问题，而该领域正从错误的方向着手解决。
直觉驱使我们要构建更大的知识库。索引更多文档。存储更多事实。向量化所有内容。其假设是记忆是一个检索问题，只要你在需要时能找到正确的文档，就解决了记忆问题。
这是错误的，我们在《意义的代价》中展示了原因：任何通过语义相似性进行检索的记忆系统，在增长过程中都会表现出干扰驱动的遗忘和虚假回忆。在该定理类范围内，没有任何架构能避免这一点（证明在论文中）。该定理指出了三条出路：放弃语义（扼杀实用性）、将有效维度推至无穷（不可能），或添加一个外部符号验证器以提供精确的情境基础。我们在 SpectralQuant 中利用来进行压缩并在《遗忘的几何学》中映射到记忆失败的同一频谱集中现象，正是使这个问题无法回避的原因。
外部符号基础是唯一可行的出路。这里的实证结论是：一旦围绕该基础构建了正确的检索结构，一个由精心设计的、基于文件系统的原生记忆（由 8B 或 70B 模型支持）在严格评判下可以紧逼前沿模型的表现，而一个极度简化的检索堆栈（BM25 + 图 + 事实 + 时间）在 J-score 上能与完整的 14+ 通道堆栈相媲美。
架构胜过规模。SMF 就是那个架构。
代码位于 https://github.com/dynamis-Labs/SMF
# 知识库不是记忆
在描述架构之前，我们需要精确区分当前讨论中混为一谈的一个概念。
2026年4月初，Andrej Karpathy 分享了他利用 LLM 构建个人知识库的方法。该系统很优雅：将原始资源放入 `raw/` 文件夹，让 LLM 将其编译为一个包含约 100 个相互链接的 markdown 文章（约 40 万词）的 wiki，使用 Obsidian 作为 IDE，并让 LLM 自动维护索引文件和反向链接。没有向量数据库。没有嵌入流水线。Karpathy 指出：“这里有着打造一款不可思议产品的空间。”他是对的，这种方法在个人规模下效果惊人。
几天后，Y Combinator CEO Garry Tan 开源了 GBrain：一个基于 TypeScript/Bun 的系统，后端采用 PostgreSQL + pgvector，可索引 10,000 多个文件，构建实体关系和交叉引用，并运行一个每晚的“梦境周期”，在你睡觉时丰富知识图谱。GBrain 拥有实体类型、交叉引用、30 多个 MCP 工具，以及一种将当前综合分析与仅追加证据分离开来的“编译真理 + 时间线”模式。
与此同时，Obsidian 社区一直利用 wikilink (`[[ ]]`) 构建图结构的知识系统，在笔记之间创建双向连接。图谱视图很美。像 Cognee 这样的工具额外增加了由 LLM 驱动的实体提取和关系挖掘功能。开发者们正将 Obsidian vault 用作 Claude Code、Cursor 和其他 AI 代理的持久记忆。
这些都是真正的贡献。我们想要致敬它们所代表的精神：清醒地认识到文件优于向量数据库，人类可读格式比专有 API 更持久，以及结构很重要。每个尝试调试过 1,024 维嵌入查询的工程师都能直观地理解这一运动存在的原因。
但有一个区别值得精确探讨。
Karpathy 的 LLM Wiki 是一个知识库，他也正是这样定位的。LLM 编译、组织和链接事实。其输出是一个结构化的个人参考资料。我们要做的区分不是对他所构建内容的批评，而是对当前广泛讨论中将知识库与记忆混为一谈现象的澄清。wiki 解决了个人规模的知识管理问题。它没有建模谁需要什么信息以及为什么。它不根据目的权衡相关性。它不会遗忘。记忆需要更多东西。
GBrain 是一个更丰富的知识库。实体关系和交叉引用使其更接近一步。梦境周期增加了时间层面的丰富度。但其架构从根本上说是“编译真理”，是 Garry Tan 所知内容的运行综合，存储在 PostgreSQL 中并额外挂载了向量搜索。它依赖外部数据库服务才能运行。它没有在存储层面编码访问控制。它没有建模记忆的目的。它是一个知识管理系统，而且是一个不错的系统。但它不是记忆。
基于 Obsidian 的系统是图形状的知识库。Wikilink 创建连接，图谱视图将其可视化。但你无法以编程方式查询该图谱。没有多跳遍历。没有类型化关系。没有访问控制。而且当 vault 增长到超出上下文窗口容量时，系统性能会下降，这正是 OpenClaw 加上 SQLite 和向量搜索的原因：“一个包含链接 markdown 文件的文件夹不是图数据库。”
结构对比表：Karpathy Wiki vs GBrain vs Obsidian vs SMF（本文）
这种区别之所以重要，是因为记忆不是关于记录什么是真的。记忆是关于编码什么重要、对谁重要、为了什么目的，并管理这种编码如何随时间变化。知识库回答：“我知道什么？”记忆回答：“我会需要什么？”
这直接影响了我们解释基准测试的方式。知识库系统针对信息检索进行了优化：给定查询，找到最相关的文档。它们的基准测试衡量检索准确性，这是恰当的。但记忆系统有更广泛的使命。检索是必要的，但不是充分的。记忆系统还必须维护关系、管理生命周期、执行访问控制、处理矛盾，并遗忘不再重要的事情。这些能力都没有被检索基准测试所捕捉。当我们比较 SMF 的 LoCoMo 数据与 ByteRover 或 Letta 的数据时，我们是在比较检索准确性，这只是一个多维问题中的一维。SMF 架构带来最高回报的维度（关系持久性、访问控制、可扩展性、生命周期管理）是目前任何基准测试都未衡量的。
这正是 SMF 登场的地方。
# 为何记忆很难：效用函数问题
检索差距只是问题的一个维度。但还有一个更深层的问题，不仅影响我们评估记忆系统的方式，还影响我们构建它们的方式。
记忆取决于观察者的效用函数。
以金门大桥为例。设计师看着它，记得“国际橙”，那是 Irving Morrow 选择的颜色，以配合自然环境并在旧金山的雾中保持可见度。结构工程师看着同一座桥，看到的是缆绳：80,000 英里的钢丝、746 英尺高的塔楼、让 894,500 吨钢铁悬跨海峡的拉力。一位上周二在科考船上的海洋生物学家记得有一头鲸鱼从桥下穿过。
效用函数问题：同一物体，三个观察者，三种记忆
同一个物体。三种完全不同的记忆。不是因为任何人的记忆错了，而是因为每个观察者都有不同的效用函数，对“我以后需要记住什么？”这个问题有不同的答案。
这给基准测试带来了根本性的问题。如果你问所有三个观察者关于金门大桥的情况，并根据单一的黄金标准来给他们打分，三个人中有两个会显得“失败”，即使每个人都准确地记住了他们需要的内容。每个记忆基准测试都隐含地内置了一个效用函数：它决定哪些答案算作正确。当我们在 LoCoMo 或任何其他基准测试上给记忆系统打分时，我们衡量的不是抽象的记忆质量。我们衡量的是系统的效用函数与基准测试的效用函数的一致程度。这不仅仅是需要打个折的问题。这完全是框架问题。
记忆不是关于记录一切。它是目的驱动的压缩。一个试图记住一切关于一切事物的有机体（或组织，或 AI 代理）将淹没在自己的记录中。一个知道自己需要回答什么问题的系统，可以极其无情地选择它存储的内容以及索引的方式。
这对记忆系统有一个直接且被低估的后果。记忆的目的越窄，构建记忆就越容易。组织的记忆比个人的记忆更容易，因为效用函数受到更多限制：谁负责、决定了什么、做出了什么承诺、理由是什么。个人的记忆更难，因为效用函数更广泛且更不可预测。通用的 AI 代理的记忆是最难的，因为效用函数本质上是“用户可能会问及过去发生的任何事情”。
Karpathy 的 Wiki、GBrain 和基于 Obsidian 的系统将效用函数推到了查询时的 LLM 中：模型在你提问时决定什么重要。SMF 将效用函数编码到了存储结构本身中。8 种实体类型、软链接模式、置信度评分、区域管理，所有这些都是对某些类型的信息比其他信息更重要以及这些信息之间的关系最重要的结构化实现。
最有力的反驳是动态效用函数更灵活。如果 LLM 在查询时决定什么重要，它可以适应新颖的问题。确实如此，对于个人工具来说，这是正确的权衡：你的需求不断变化，重读很便宜，而且单个用户不需要访问控制。但对于组织记忆，持久性比灵活性更重要。合规性、审计、问责制和多代理访问都要求关系必须在模型变更、员工更替和时间流逝中存续。组织需要知道谁决定、何时、为什么以及做出了什么承诺，并且需要这些答案独立于模型且受权限管理。这就是结构编码获胜的地方。
我们首先为组织记忆构建 SMF，因为那里的效用函数受到的约束最多，因此最容易编码。但该架构并不限于此。实体类型系统是一个可插拔的模式。临床记忆可能会用诊断替换 VCO，用治疗方案替换理由。法律记忆可能会跟踪义务、先例和管辖权。研究记忆可能会跟踪假设、实验和证据链。结构原则，即通过软链接连接的实体将你的效用函数编码进去，是通用的。具体的实体类型是你适应领域的那部分。
# SMF 的不同之处：文件系统即是知识图谱
SMF 的核心架构洞察是，POSIX 软链接——每个 Unix 系统支持了近半个世纪的那条不起眼的 `ln -s` 命令——是零成本的关系指针。从 `/memory/actors/alice/related/collaborated_with/bob` 到 `/memory/actors/bob/` 的软链接是知识图谱中的一条类型化的、有向的边。创建它几乎没有成本。遍历它几乎没有成本。它不需要单独的图数据库。而且 `ls -la` 向任何查看的人类或代理揭示关系结构。
据我们所知，这是没有其他人基于 POSIX 的代理记忆做过的。Karpathy 的 Wiki 没有（条目之间没有明确的文件系统级关系）。GBrain 没有（关系存在于 PostgreSQL 中，而非文件系统）。Obsidian 没有（wikilink 是 markdown 中的文本引用，而非文件系统级指针）。
软链接方法使其他一切成为可能的设计选择。
SMF 将记忆组织为 8 种实体类型，每种都存储为一个目录：
当前博文中的 8 类型本体表
为什么是这 8 个，而不是 6 个或 12 个？因为它们是封闭组织效用函数的最小集合：谁、发生了什么、决定了什么、为什么、承诺了什么、何时以及关于什么。移除任何一个，你就会失去组织通常需要回答的问题类型。增加更多，你就会引入可以由这些原始组合而成的类别。这种分类是鲜明的，并且是故意的。
磁盘上的单个 SMF 实体：元数据、摘要和形成知识图谱的类型化软链接。
每个实体都是一个目录，包含 `content.md`（规范内容）、`meta.json`（结构化元数据）、一个包含指向相关实体的软链接的 `related/` 子目录，以及捕获实体如何生成的 `.provenance.jsonl`。软链接是类型化的：`collaborated_with`（协作过）、`decided_at`（决定于）、`updates`（更新）、`contradicts`（矛盾）、`derives`（衍生）、`extends`（扩展）。文件系统本身编码了知识图谱。没有外部图存储。没有单独的模式 DSL。没有 GraphQL 端点。只有目录、文件和软链接。
想想这在操作上意味着什么。一个需要理解围绕某个决策的上下文的代理可以 `ls /memory/decisions/switch-to-postgres/related/` 并立即看到每个相关实体：涉及的参与者、理由、讨论该决策的会议、它履行的承诺。无需嵌入查找。无需图遍历引擎。无需 LLM 调用。只需一个目录列表。该图谱可以用互联网出现之前的工具进行检查。
# SMF 超越知识库方法的地方：可扩展性和访问控制
这种架构选择，即作为图谱边的软链接，赋予了 SMF 两个任何知识库方法都无法原生匹配的特性。
不依赖上下文窗口的可扩展性。Karpathy 的 Wiki 在大约 100 篇文章的规模下有效，因为 LLM 可以读取索引文件并导航。GBrain 在 10,000 多个文件的规模下有效，因为 PostgreSQL 处理搜索。基于 Obsidian 的系统在 vault 增长超出上下文窗口时会降级。SMF 的软链接图谱没有这样的上限。遍历