How to Build Agent Memory: Where Does Knowledge Live? Devin Stein 2026-09-01 11.3 KB 5.9K 86 ☆ 收藏 𝕏 文章列表 本文是 Agent 记忆系列文章的第二篇，探讨知识的存储位置与表示形式。作者将记忆拆解为表示与存储、提取、检索、维护四个环节，重点讨论第一个问题：知识存放在哪里。文章指出表示（知识形态）与物理存储是两个独立决策，文件系统因编程代理擅长 bash 而成为极佳起点。作者提出应区分“产物”（发生过的记录）与“知识”（当前应相信的事实），知识应像物化视图一样回指来源产物。知识会过时，需要版本控制、分支与合并机制；且知识应被视为缓存而非全量存储，因为维护成本高昂。 Agent MemoryLLM知识表示RAG向量数据库Git知识缓存DosuClaude存储架构 81 强烈推荐 ▶ 发布于前一天，观点新颖且有深度（artifacts vs knowledge、知识版本控制、缓存模型），概念框架清晰可操作，但缺少具体代码与落地步骤。 # How to Build Agent Memory: Where Does Knowledge Live? **作者**: Devin Stein **日期**: 2026-08-31T15:03:04.000Z **来源**: [https://x.com/devstein64/status/2094440843595706863](https://x.com/devstein64/status/2094440843595706863) ---  In the first post in this series, we broke agent memory into four pieces: representation and storage, extraction, retrieval, and maintenance. If you're familiar with databases, you can think of these roughly as CRUD. How is knowledge stored? How do you write it? How do you find it again? And how do you keep it up to date? This post is about the first question: where does an agent's knowledge actually live? The obvious answer is "in a database." But that's jumping ahead. Before deciding where to put knowledge, we first need to decide what that knowledge actually looks like. ## What does a memory look like? There are two separate decisions hiding inside "storage." The first is representation: the shape of the knowledge itself. The second is physical storage: the system that holds it. A memory could be a paragraph of markdown, a collection of facts, a hierarchy of topics, or a graph connecting entities and relationships. Any of those could live in files, Postgres, a vector database, or something more specialized. That distinction matters because storage is relatively easy to swap. The representation you choose determines how your agent understands and interacts with the knowledge. At the simplest end of the spectrum, memory is just text. That's AGENTS.md, CLAUDE.md, transcripts from previous sessions, or a list of extracted facts. From there, you can start adding relationships: a product has features, a GitHub issue is closed by a pull request, a fact belongs to a topic. Those relationships can form simple trees or much richer graphs. In practice, most memory systems eventually use some combination of these approaches. There is no single representation that wins everywhere. ## You can get surprisingly far with files There are plenty of places to put agent memory. You can inject small amounts directly into the context window, embed information into a vector database and retrieve it by semantic search, put relationships in a graph database, or give the agent SQLite or Postgres and let it query its memories with SQL. Or you can put the knowledge in a directory. That last option sounds almost too simple, but it has become one of the more useful patterns in agent systems. The first generation of LLM applications treated retrieval as synonymous with RAG: embed everything, put it in a vector database, and search by semantic similarity. Then coding agents got really good at bash. They can navigate directories, run grep and rg, follow links, inspect filenames, and read many files in parallel. Filesystems are not just a convenient place to store information. They're also an interface that today's coding agents already understand extremely well. That's why, if you're building agent memory from scratch, files are often a very good place to start. But the harder question isn't where the files live. It's what you put in them. ## Separate what happened from what is true At Dosu, we find it useful to separate memory into two broad categories: artifacts and knowledge. Artifacts are records of what happened. A Slack thread is an artifact. So is a pull request, a Linear ticket, a meeting transcript, a design document, or an agent session trace. They're useful because they're high fidelity and preserve the original context, but they're not necessarily true. A design document can describe an architecture that was never implemented. A Slack conversation can explain how something worked a year ago. A ticket can tell you why a feature was created without telling you how that feature works today. Artifacts are evidence. Knowledge is what your agent should currently believe to be true. That distinction is important because useful memory almost always involves abstraction. We don't want an agent to reread six months of Slack every time it needs to understand why a system works the way it does. We want to turn all that history into something concise and useful. Borrowing the database analogy, you can think of knowledge as a materialized view over your artifacts. The artifacts preserve what happened; the knowledge captures what matters now. The important part is keeping the connection between the two. Any time you ask an LLM to summarize a conversation, extract a fact, or combine several sources, you're performing a lossy transformation. Some information disappears. That's okay. Losing information is often exactly what makes the abstraction useful. The problem comes when you throw away the source. Instead, knowledge should point back to the artifacts that created it. Most of the time, the agent can take the fast path: here's what we currently believe. But when the exact details matter, it can go deeper and answer questions like: Why do we believe this? When did this change? What was the original discussion? That gives you the efficiency of abstraction without sacrificing the fidelity of the underlying history. And once you make knowledge canonical, another problem immediately appears: it can go stale. ## Knowledge needs version control Artifacts are historical. Once something happened, it happened. Knowledge is different. It represents the current state of the world, and the world keeps changing. If your memory says authentication uses API keys today, and the team migrates to OAuth tomorrow, the old memory isn't just less useful. It's wrong. This is one reason Git is such an appealing mental model for knowledge. Git doesn't just tell you what a file looks like now. It tells you how it changed. You can inspect history, see diffs, and reconstruct what was true at an earlier point in time. But there's another Git concept that may be even more important for agent memory: branching. Imagine an agent is implementing OAuth on a feature branch. The organization's current knowledge says authentication uses API keys, but halfway through the task the agent has changed the system and, within its working branch, OAuth is now supported. Both statements are correct depending on which version of the world you're looking at. The second fact shouldn't become organizational knowledge until the feature actually merges. What the agent really needs is shared organizational knowledge plus a temporary, task-specific overlay representing the world it's currently operating in. Then, when the code merges, the knowledge can merge too. As agents take on longer-running and more autonomous work, I think this becomes an increasingly important requirement. We won't just need to update memory. We'll need to branch, merge, and reconcile knowledge. Of course, that sounds like even more knowledge to maintain, which raises the next question: how much should we actually store? ## Knowledge is a cache It's tempting to imagine the ideal agent memory system as one that remembers everything. I think that's the wrong goal. Artifacts are relatively cheap to keep. A Slack message happened, so store it. An agent session happened, so store it. There's no need to continually update the historical record. Knowledge has carrying costs. The moment you create a canonical explanation of how your authentication system works, you have created something that needs to stay synchronized with your authentication system. Multiply that across every feature, service, customer workflow, decision, convention, and internal process in a large organization and you've built a very expensive maintenance problem. A better way to think about much of agent knowledge is as a cache. Caches exist because some information is expensive to recompute, and agent knowledge is similar. Imagine an agent spends twenty minutes tracing calls across twelve services to understand how your billing architecture works. That's expensive context to acquire. If the next twenty agents are going to repeat that same investigation, save the result. Now imagine the agent needs to know which port one service runs on and the answer is sitting in an obvious config file. Just read the file. Creating and maintaining a second representation of that fact may be more expensive than recomputing it. This gives us a useful framework for what belongs in memory. Some knowledge is irreplaceable: a human says, "We can't remove this behavior because our largest customer depends on it." That fact probably doesn't exist anywhere else. If you don't capture it, it's gone. Some knowledge is expensive to recompute: an agent has to search across twenty files, three services, and six historical discussions to understand something. That's a good candidate to materialize. And some knowledge is simply used all the time. Even if it isn't particularly expensive to discover once, repeatedly rediscovering it creates unnecessary cost. Everything else can be a cache miss. The goal isn't for your agents to remember everything. It's for them to remember the things where remembering is cheaper than rediscovering. ## Start simple It's easy to look at the agent memory space today and conclude that you need a graph database, vector search, temporal relationships, an ontology, and a new set of infrastructure before you can get started. You probably don't. If I were building an internal memory system from scratch today, I would start with files in Git. Agents already know how to use them. Humans already know how to inspect them. You get history and diffs for free, and you don't have to predict every future requirement before you've learned what actually matters. Then watch where it breaks. If agents struggle to find the right information, improve retrieval. If relationships become important, add more structure. If agents repeatedly perform the same expensive research, materialize the result. If canonical knowledge changes too quickly to maintain manually, build a better maintenance system. And if you don't feel like thinking about all of this, just use Dosu. This is exactly the problem we spend our time on. The agent memory industry has gone through an interesting cycle here. We started with increasingly sophisticated retrieval and graph architectures, then rediscovered that putting a bunch of well-organized markdown files in a repository works surprisingly well. I don't think that means markdown is the final form of agent memory. It means complexity should be earned. Start with the simplest representation that works. Keep the underlying artifacts. Materialize the knowledge that's worth maintaining. And let the failures in your system tell you what sophistication to add next. Of course, deciding what knowledge should look like and where it should live is only half the problem. Somehow, that knowledge has to get there in the first place. That's what we'll dig into next: how agents capture and write knowledge into memory. [dosu.dev](//dosu.dev) ## 相关链接 - [Devin Stein](https://x.com/devstein64) - [@devstein64](https://x.com/devstein64) - [3.3K](https://x.com/devstein64/status/2094440843595706863/analytics) - [dosu.dev](https://dosu.dev/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [11:03 PM · Aug 31, 2026](https://x.com/devstein64/status/2094440843595706863) - [3,315 Views](https://x.com/devstein64/status/2094440843595706863/analytics) --- *导出时间: 2026/9/1 09:10:43* --- ## 中文翻译 # 如何构建智能体记忆：知识存放在哪里？ **作者**： Devin Stein **日期**： 2026-08-31T15:03:04.000Z **来源**： [https://x.com/devstein64/status/2094440843595706863](https://x.com/devstein64/status/2094440843595706863) ---  在本系列的第一篇文章中，我们将智能体记忆拆分为四个部分：表示与存储、提取、检索和维护。如果你熟悉数据库，可以粗略地把它们对应为 CRUD。知识如何存储？如何写入？如何检索？如何保持更新？ 这篇文章讨论第一个问题：智能体的知识究竟存放在哪里？ 显而易见的答案是“存在数据库里”。但这就太快跳到结论了。在决定把知识放在哪里之前，我们首先需要确定这些知识究竟是什么样子。 ## 一条记忆是什么样子的？ “存储”这个词里其实藏着两个独立的决策。第一个是表示：知识本身的形态。第二个是物理存储：承载它的系统。 一条记忆可以是一段 Markdown 文本、一组事实、一个主题层级结构，或者一个连接实体和关系的图。这些形式中的任何一种都可以存放在文件、Postgres、向量数据库或更专门的系统中。这个区分很重要，因为存储层相对容易替换，而你选择的表示方式决定了智能体如何理解和与知识交互。 在最简单的一端，记忆就是纯文本。比如 AGENTS.md、CLAUDE.md、之前会话的记录，或者一组提取出来的事实。在此基础上，你可以开始添加关系：一个产品拥有若干功能，一个 GitHub issue 被一个 pull request 关闭，一个事实属于某个主题。这些关系可以构成简单的树，也可以构成丰富得多的图。 在实践中，大多数记忆系统最终都会使用这些方法的某种组合。没有任何一种表示方式能在所有场景下胜出。 ## 仅靠文件就能走得很远 智能体记忆有很多存放的地方。你可以把少量内容直接注入上下文窗口，把信息嵌入向量数据库并通过语义搜索检索，把关系放进图数据库，或者给智能体一个 SQLite 或 Postgres，让它用 SQL 查询自己的记忆。 或者，你可以把知识放进一个目录里。 最后一个选项听起来简单得近乎可笑，但它已经成为智能体系统中最有用的模式之一。第一代 LLM 应用把检索等同于 RAG：把所有东西嵌入向量数据库，然后按语义相似度搜索。 后来，编程智能体把 bash 用得炉火纯青。 它们可以浏览目录、运行 grep 和 rg、跟踪链接、查看文件名，并并行读取大量文件。文件系统不只是存放信息的便利场所，它还是当今编程智能体已经非常熟悉的一种接口。 这就是为什么，如果你要从零开始构建智能体记忆，文件通常是一个非常好的起点。但更难的问题不是文件放在哪里，而是往里面放什么。 ## 区分“发生了什么”和“什么是真的” 在 Dosu，我们发现把记忆分为两大类很有用：工件和知识。 工件是“发生了什么”的记录。一个 Slack 讨论串是工件。pull request、Linear 工单、会议记录、设计文档、智能体会话轨迹也都是工件。它们很有用，因为保真度高、保留了原始上下文，但它们不一定反映真实情况。 一份设计文档可能描述了一个从未实现的架构。一段 Slack 对话可能解释的是一年前某个东西的工作方式。一张工单能告诉你一个功能为何被创建，却不能告诉你这个功能今天是如何运作的。 工件是证据。知识是你的智能体当前应当相信为真的东西。 这个区分很重要，因为有用的记忆几乎总是涉及抽象。我们不希望智能体每次需要理解一个系统为何如此运作时，都重新阅读六个月的 Slack 记录。我们想把所有那些历史转化为简洁有用的东西。 借用数据库的类比，你可以把知识看作工件之上的物化视图。工件保存发生了什么；知识捕捉现在重要的是什么。 关键在于保持两者之间的联系。每当你让 LLM 总结一段对话、提取一个事实，或者合并多个来源时，你都在执行一次有损转换。有些信息会丢失。这没关系——丢失信息往往正是抽象有用的原因。 问题出现在你把原始来源扔掉的时候。知识应当回指产生它的工件。大多数时候，智能体可以走快速路径：这是我们当前相信的内容。但当确切的细节变得重要时，它可以深入探究并回答这样的问题：我们为什么相信这个？这是什么时候变的？最初的讨论是什么？ 这样你就既获得了抽象的效率，又不牺牲底层历史的保真度。 而一旦你把知识变成权威版本，另一个问题立刻浮现：它会过时。 ## 知识需要版本控制 工件是历史性的。事情一旦发生了，就是发生了。知识则不同。它代表世界的当前状态，而世界在不断变化。 如果你的记忆说身份验证目前使用 API key，而团队明天迁移到 OAuth，那么旧的记忆不仅仅是没那么有用了——它是错的。 这是 Git 之所以成为如此有吸引力的知识心智模型的原因之一。Git 不仅告诉你文件现在长什么样，还告诉你它是如何变化的。你可以查看历史、看到 diff，并重建过去某个时间点的真实状态。 但 Git 还有另一个概念对智能体记忆可能更为重要：分支。 想象一个智能体正在一个功能分支上实现 OAuth。组织的当前知识说身份验证使用 API key，但任务进行到一半时，智能体已经改变了系统，在它的工作分支内，OAuth 现在是受支持的。两种说法都是正确的，取决于你看的是哪个版本的世界。 第二个事实不应该在功能真正合并之前成为组织知识。智能体真正需要的是共享的组织知识，外加一个临时的、特定于任务的覆盖层，代表它当前所运作的世界。 然后，当代码合并时，知识也一并合并。 随着智能体承担运行时间更长、更自主的工作，我认为这会成为一个越来越重要的需求。我们不仅需要更新记忆，还需要对知识进行分支、合并和调和。 当然，这意味着需要维护的知识更多了，这就引出了下一个问题：我们到底应该存储多少？ ## 知识是一种缓存 人们很容易把理想的智能体记忆系统想象成一个记住所有东西的系统。我认为这是错误的目标。 工件的保留成本相对较低。一条 Slack 消息发生了，就存下来。一次智能体会话发生了，就存下来。历史记录无需持续更新。 知识则持有维护成本。一旦你创建了一个关于身份验证系统如何工作的权威解释，你就创造了一个需要与你的身份验证系统保持同步的东西。在一个大型组织中，把这个成本乘以每个功能、服务、客户工作流、决策、规范和内部流程，你就制造了一个非常昂贵的维护难题。 对于大部分智能体知识，更好的思考方式是把它当作缓存。缓存之所以存在，是因为某些信息重新计算的代价很高，智能体知识与此类似。 想象一个智能体花了二十分钟跨十二个服务追踪调用，以理解你的计费架构是如何工作的。这是获取成本很高的上下文。如果接下来二十个智能体都要重复同样的调查，那就把结果保存下来。 现在想象智能体需要知道某个服务运行在哪个端口，而答案就在一个显而易见的配置文件里。那就直接读文件。为这个事实创建并维护第二份表示，可能比重新计算它的成本更高。 这给了我们一个有用的框架，用来判断什么该放进记忆。有些知识是不可替代的：一个人说，“我们不能移除这个行为，因为我们最大的客户依赖它。”这个事实可能不存在于其他任何地方。如果你不捕获它，它就消失了。 有些知识重新计算的代价很高：智能体必须搜索二十个文件、三个服务和六次历史讨论才能理解某件事。这就是适合物化的对象。还有些知识是被频繁使用的。即使它被发现一次的成本并不高，反复重新发现它也会带来不必要的开销。 其余的一切，都可以当作缓存未命中。 目标不是让你的智能体记住所有东西，而是让它们记住那些“记住比重新发现更划算”的东西。 ## 从简单开始 看着今天的智能体记忆领域，人们很容易得出结论：你需要图数据库、向量搜索、时序关系、本体论，以及一套全新的基础设施才能入门。 你很可能不需要。 如果今天让我从零开始构建一个内部记忆系统，我会从 Git 中的文件开始。智能体已经知道怎么用它们，人类已经知道怎么检查它们。历史和 diff 是免费提供的，而你也不必在弄清楚什么真正重要之前，就预测未来所有的需求。 然后观察它在哪儿出问题。如果智能体难以找到正确的信息，就改进检索。如果关系变得重要，就添加更多结构。如果智能体反复进行同样昂贵的研究，就把结果物化下来。如果权威知识变化太快以至于无法手动维护，就构建更好的维护系统。 如果你不想费心思考这一切，直接用 Dosu 就好。这正是我们花费全部时间研究的问题。 智能体记忆行业在这里经历了一个有趣的循环。我们从日益复杂的检索和图架构起步，然后重新发现：把一堆组织良好的 markdown 文件放进仓库，效果出奇地好。 我认为这并不意味着 markdown 就是智能体记忆的最终形态。它意味着复杂性应当是被“挣来”的。 从可行的最简单表示开始。保留底层的工件。把值得维护的知识物化下来。让你系统中的失败告诉你，下一步该增加什么复杂性。 当然，确定知识应该长什么样、应该存放在哪里，只是问题的一半。这些知识总得有办法被写入才行。 这就是我们接下来要深入探讨的：智能体如何捕获知识并将其写入记忆。 [dosu.dev](//dosu.dev) ## 相关链接 - [Devin Stein](https://x.com/devstein64) - [@devstein64](https://x.com/devstein64) - [3.3K](https://x.com/devstein64/status/2094440843595706863/analytics) - [dosu.dev](https://dosu.dev/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [11:03 PM · Aug 31, 2026](https://x.com/devstein64/status/2094440843595706863) - [3,315 Views](https://x.com/devstein64/status/2094440843595706863/analytics) --- *导出时间： 2026/9/1 09:10:43*
K Karpathy 最新分享：用 LLM 搭建个人知识库，告别 RAG 的低效循环 文章介绍了 Karpathy 提出的 LLM Wiki 方法，旨在解决传统 RAG 检索缺乏知识沉淀的问题。作者详细演示了如何在 Obsidian 中落地该方案，包括使用插件采集素材、配置图片本地化、利用图谱视图发现盲区、结合 Dataview 生成报表、使用 Marp 制作幻灯片，以及通过 Git 进行版本管理。核心思想是让 AI 承担繁琐的整理与维护工作，人类专注于思考与决策，从而构建持久增殖的个人知识库。 技术 › LLM 老张来了 2026-04-05 LLM知识库ObsidianRAGKarpathy个人管理GitClaude工作流效率工具
H How to Build Agent Memory: Search & Retrieval 本文是构建 Agent 记忆系统系列的第四篇，聚焦读取路径：如何检索已保存的知识并加以利用。文章首先强调根据问题类型选择检索方式——精确查找、相似案例识别或项目概览各有不同需求。接着对比了四种搜索方法：关键词匹配、语义搜索、图遍历和 Agentic 检索，指出 Agentic 检索能综合运用其他方法并随信息获取调整调查策略。文章还强调检索结果应具备可操作性，一条包含复现步骤和验证方式的笔记远比泛泛的描述更有价值。最后提醒要注重精确度，避免给 Agent 返回过多无关信息造成干扰，因为它可能将小问题扩大成大改动。 技术 › Agent Devin Stein 2026-09-15 AgentAgent MemoryRAG检索语义搜索Agentic RetrievalEmbeddingsLLM
M Memory Is a Compiler：记忆是一个编译器 作者通过一次融资会议记忆被重新解读的经历，指出记忆的本质不是固定表示，而是一个持久系统：保留过去的证据，并随新证据不断重新编译其意义。文章批评将向量数据库、知识图谱、上下文窗口等当作记忆的常见误解，认为它们只是从记忆编译出的临时表示。作者提出记忆编译产生三类产物：状态（按序折叠事件得到）、检索（查找相关证据的工具）和上下文（为单次调用组装的有界视图），并类比编译器的中间表示（IR），指出每种表示只适合特定操作，记忆本身应是唯一不可丢弃的持久层。 技术 › LLM Ashwin Gopinath 2026-09-01 AI记忆RAG向量数据库知识图谱上下文窗口AgentLLM系统设计
R RAG架构详解：检索、增强与生成 本文深入解析了生产级RAG（检索增强生成）系统的完整架构。文章首先指出LLM的局限性——无法访问私有数据，而RAG通过外部知识检索来弥补这一缺陷。然后详细介绍了系统的两大核心平面：知识平面（离线索引）和运行时平面（在线问答）。知识平面涵盖数据源、解析-分块-嵌入流水线以及向量索引；运行时平面则描述了用户查询、检索重排、LLM生成和答案引用的完整流程。文章还逐步拆解了查询生命周期，包括查询嵌入、Top-K检索、重排增强和生成，并强调了监控指标的重要性。 技术 › LLM Vikas gupta 2026-08-20 RAGLLM向量数据库嵌入检索架构知识管理AI
私 私有知识库实战：查询改写、混合检索与重排优化 RAG 本文是私有知识库构建系列的第 3 篇，旨在解决基础 RAG 系统在短问题召回、关键词匹配及结果排序上的缺陷。作者详细介绍了通过 LLM 进行查询改写以补全上下文，利用 PostgreSQL 结合 Jieba 实现混合检索（向量+BM25），以及使用 RRF 算法融合检索结果，从而显著提升知识库的日常可用性。 技术 › LLM A Ando 2026-07-08 RAG混合检索查询改写向量数据库PostgreSQLBM25搜索优化知识库LLMPython
阿 阿里开源 Zvec：像 SQLite 一样极简的嵌入式向量数据库 阿里开源了一款名为 Zvec 的向量数据库项目，主打“纯本地、内嵌式”极简体验，号称向量界的 SQLite。该项目基于 C++ 编写，支持零配置安装，性能强悍（毫秒级搜索数十亿向量），同时兼容稠密、稀疏向量及全文检索。它非常适合本地大模型、RAG 和个人知识库开发，彻底免去了部署繁琐的后端向量服务。 技术 › 后端 智享 2026-07-08 向量数据库阿里ZvecRAG本地大模型开源LLMAgent数据库工具
P Pydantic fixed my Agent's Memory 文章探讨了如何解决 AI Agent 记忆系统的多跳推理问题。传统的向量数据库在处理跨块事实连接时失效，而通用知识图谱常因缺乏结构导致查询噪音。作者提出的解决方案是使用 Pydantic 提前定义本体（Schema），明确实体类型、关系和属性。通过 Zep 框架强制执行这些约束，可以显著提升提取的准确性和数据的可查询性，从而实现有效的多跳推理。 技术 › Agent Akshay 2026-05-26 AgentPydantic知识图谱RAGLLMSchema多跳推理Zep向量数据库Ontology
Y Your Agent Needs a Wiki and a Recording 文章指出仅依靠扩大上下文窗口无法解决 Agent 的遗忘问题，并提出了 GBrain 和 Lossless 两个解决方案。GBrain 是基于 Wiki 的知识检索层，解决跨对话的长期记忆（如项目背景、决策历史）；Lossless 则像会议录音，通过保留原始消息记录，解决长对话中的细节检索与回溯问题。二者结合能让 Agent 拥有类似查阅文档和回溯记录的能力，从而更智能地处理复杂任务。 技术 › Agent Vox 2026-05-18 GBrainLosslessAgent MemoryOpenClawHermesRAGLLMContext Window
A Agentic Memory: 详解 Agent 记忆系统的架构与实现 文章通过生动的类比，指出缺乏记忆是当前 LLM Agent 的主要短板。作者详细拆解了 Agent 记忆系统的三个核心功能：连续性、上下文和学习。文章重点介绍了四种记忆类型：上下文记忆、外部记忆、情景记忆和参数记忆，并深入探讨了如何通过检索增强（RAG）和反思循环来构建持久的智能。 技术 › Agent Ramakrishna (techwith_ram) 2026-05-17 AgentLLMMemoryArchitectureRAGVectorStoreContextEpisodic向量数据库系统设计
A AI Agent 记忆机制原理与实战解析 文章深入浅出地讲解了 AI Agent 记忆系统的工作原理，从基础的单会话与多会话记忆保持切入，引出 Google 提出的情景、语义与程序性记忆三分法。通过对比 OpenClaw 的实现方式与存在的问题，重点剖析了企业级方案 EverOS 的架构。EverOS 将记忆细分为六大类，并通过语义巩固、主动上下文重建等技术优化记忆的抽取、更新与检索。文章还包含 EverOS 的 API 调用示例及 20 个真实落地场景，为开发者提供了 Agent 记忆系统的全景指南。 技术 › Agent 铁锤人 2026-05-14 AI Agent记忆系统OpenClawEverOSRAG向量数据库长上下文自进化LLM实战案例
非 非向量 RAG 框架 PageIndex：用 LLM 推理替代 Embedding 文章介绍了 VectifyAI 开源的 PageIndex 框架，这是一种不使用向量嵌入的 RAG（检索增强生成）方法。它通过构建文档的层次树结构，利用 LLM 的推理能力来精确定位答案页面。该框架在 GitHub 获得了超过 2.9 万星，其构建的 Mafin 2.5 在金融问答基准测试中取得了 98.7% 的高准确率。 技术 › LLM AlphaSignal AI 2026-05-08 RAGLLMPageIndex向量数据库开源项目检索增强生成AI应用
如 如何精通 RAG 并构建拥有完美记忆的 AI Agent (全流程教程) 本文是一篇关于检索增强生成（RAG）技术的完整教程。文章指出，大多数 AI Agent 难以落地的原因在于模型无法获取企业私有数据。RAG 通过将外部知识库与大模型结合，解决了这一痛点。作者详细拆解了构建 RAG 系统的五个核心阶段：文档摄取与分块、文本嵌入、向量存储、信息检索以及最终生成，并提供了关于分块策略、嵌入模型选择及混合检索的实战建议。 技术 › LLM Khairallah AL-Awady 2026-05-01 RAGAgent教程向量数据库Embedding知识库ClaudeOpenAI大模型开发指南
