AI Agent 缺的是记忆而非上下文

我们在让 AI 模型变得更强推理能力。

我们给它们更大的上下文窗口。

我们让它们连接工具。

我们让它们搜索文件、浏览代码库、调用 API、执行代码、操作越来越复杂的工作流。

然而一个问题反复出现：

并不是因为模型不够好。

而是因为大多数 Agent 系统仍然把记忆当作事后才考虑的事情。

我思考这个问题已经有一段时间了，最终让我开始构建 BaseMyAI：一个面向 AI Agent 的本地优先记忆基础设施层。

这是第一篇文章，我想记录我在构建什么、为什么我认为这个问题很重要，以及我在过程中学到的东西。

上下文不是记忆

一种常见的 Agent 记忆方案大致是这样的：

存储对话或文档。

把它们放进向量数据库。

为下一个 prompt 检索最相似的片段。

但我不认为这是记忆。

一个真正的记忆系统必须回答更难的问题。

Agent 目前相信什么？

哪些信息已经过时了？

哪个事实替换了另一个事实？

哪些记忆属于这个 Agent？

哪些记忆是临时的？

哪些必须存活数月？

某个决定之前发生了什么？

哪些信息实际上与当前任务相关？

同样重要的是：

什么应该被遗忘？

一旦 Agent 开始运行数天、数周或数月，这些问题就变得比简单地找到最近邻嵌入重要得多。

更大的上下文窗口解决不了这个问题

长上下文窗口非常强大。

但把所有东西都塞进 prompt 并没有很好的扩展性。

想象一个在同一个代码库上工作了六个月的工程 Agent。

在此期间它见过：

数千次提交；

架构决策；

被废弃的实现；

临时假设；

从技术上讲，你可以不断把更多信息重新喂给模型。

但最终你要为大量无关的上下文付费。

更糟糕的是：旧信息可能与新信息冲突。

问题变得不再是：

“模型能读取多少上下文？”

而是：

“模型此刻需要的最少正确上下文是什么？”

这是一个记忆问题。

我发现有一个概念特别重要：时间记忆。

考虑这两个事实：

Database: PostgreSQL
Database: native embedded engine

一个基础的检索系统可能同时返回这两个。

但它们不一定矛盾。

也许 PostgreSQL 是三个月前使用的，后来项目迁移到了原生引擎。

缺失的维度是时间。

系统应该理解更接近于：

2026-04 Database = PostgreSQL
2026-07 Database = native embedded engine

现在 Agent 可以推理项目的演进，而不是把每个存储的事实都当作同等时效的。

在长期运行的软件项目中，这种区别变得极其重要。

记忆需要边界

另一个问题出现在多个 Agent 参与时。

coding-agent
research-agent
support-agent
marketing-agent

它们可能共享一些知识。

但不应该自动共享一切。

一个 Agent 的记忆需要一个身份和一个边界。

这就引出了关于以下方面的有趣架构问题：

对于 BaseMyAI 来说，Agent 隔离是基本原语之一，而不是后来才添加的东西。

本地优先改变了架构

我关心的另一个需求是：记忆应该能够生活在离用户近的地方。

Agent 记忆可能包含机器上最敏感的一些信息：

源代码、对话、文档、产品策略、凭证元数据、个人偏好，以及数月积累的上下文。

把所有这些都发送到另一个托管数据库不应该是唯一可用的架构。

所以 BaseMyAI 正在围绕本地优先和加密模型进行设计。

这个决定让工程变得相当有意思。

我目前正在用 Rust 构建一个原生存储引擎，包含持久化索引、有限内存管理、WAL 耐久性、快照、压缩和并发控制等功能。

目标不是为了基础设施而建基础设施。

目标是让长期 Agent 记忆变得足够可预测，以至于开发者能够真正信任它。

向量数据库仍然有用

这一切并不意味着向量搜索不好。

向量搜索非常有用。

BaseMyAI 本身也使用向量检索作为记忆的一部分。

我做的区分是架构层面的：

Vector search
      ↓
is a component of
      ↓
Agent memory

而不是：

Vector database = Agent memory

记忆还需要结构、生命周期、时间顺序、身份、耐久性和上下文选择。

这才是我感兴趣的层。

我正在探索的方向

我目前的思维模型大致是这样的：

                    ┌─────────────────┐
                    │    AI Agent     │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │ Context Compiler│
                    └────────┬────────┘
                             │
             ┌───────────────┼───────────────┐
             ▼               ▼               ▼
        Semantic          Temporal        Structured
         Recall            Memory          Relations
             │               │               │
             └───────────────┼───────────────┘
                             ▼
                    ┌─────────────────┐
                    │ Durable Memory  │
                    └─────────────────┘

这里重要的组件可能实际上是上下文编译器。

存储引擎可以知道数百万件事。

但模型不应该收到数百万件事。

上下文编译器的工作是把长期记忆转换为针对特定请求的小而相关、时效准确的表示。

我越来越相信这一层对严肃的自主 Agent 至关重要。

公开构建

BaseMyAI 仍在构建中。

目前很多工作都是底层基础设施工作，而不是成熟的产品工作。

而且可能很多设计决策在六个月后我会发现是错误的。

这正是我想在这里写下来的原因。

不是等所有东西都看起来完成了才发布 BaseMyAI，而是想在工程决策、实验、失败、基准测试和架构问题的发生时就把它们记录下来。

我接下来想探索的一些主题包括 Agent 记忆模型、时间检索、用 Rust 设计存储引擎、上下文编译、Agent 之间的记忆隔离，以及为什么 BaseMyAI 故意不设计成另一个向量数据库。

如果你正在做 Agent、检索系统、Rust 基础设施、知识图谱或长期 AI 记忆方面的工作，我真心希望能比较一下彼此的方法。

这个领域仍然感觉非常早期。

而且我认为我们才刚刚开始理解软件 Agent 的记忆实际上应该是什么样子。