Agent 的数据面概念扫盲-建立技术侧认知体系 ✍ MateMatt🕐 2026-07-12📦 15.2 KB 🟢 已读 𝕏 文章列表 本文深入解析了 Agent 数据面的核心概念,将其比作操作系统的内存管理单元。文章详细阐述了 Context Engineering 的演变、Session/Thread/Profile 的架构差异,以及 Session Memory 与 Long-term Memory 的区别。作者还重点介绍了 Hermes 中的 Memory 设计方案、SQLite FTS5 与 BM25 算法原理,以及向量检索与关键词检索在 RAG 中的混合应用,旨在为开发者建立一套完整的 Agent 数据面技术认知体系。 AgentContext EngineeringRAGMemoryBM25SQLite FTS5向量检索HermesLong-term MemoryLLM # Agent 的数据面概念扫盲-建立技术侧(Context Memory RAG) 认知体系(上) **作者**: MateMatt **日期**: 2026-07-07T02:04:41.000Z **来源**: [https://x.com/mate_mattt/status/2075171293029179866](https://x.com/mate_mattt/status/2075171293029179866) ---  Agent 的控制平面 (Runtime、事件调度、状态机) 和数据平面 (Prompt、Context、RAG、Memory)是相辅相成的。如果控制平面是操作系统的“进程调度与安全外壳”,那么数据平面就是操作系统的“内存管理单元 (MMU) 与虚拟内存寻址”。 > 为了架构讲解清晰,这里的控制面,和数据面,是我个人定义的,并不是领域术语。 之前写过 3 篇文章介绍 Agent Runtime 架构体系: > **MateMatt@mate_mattt**: [原文链接](https://x.com/mate_mattt/status/2074313623523271010) > 感兴趣,可以进去阅读。从这篇开始,我会陆续写 Agent 数据面相关的文章。 数据面是近几年 Agent 的重点研究方向,特别是 Context Engineering,知识库检索、召回,长期记忆的处理,RAG 技术等等。这部分知识点非常多,我的思路是先建立宏观的知识结构体系,把术语、专有名词、工作路径捋清楚。后续再逐个深入。 ## LLM 大语言模型特点-背景知识补充 由于整个上下文工程的核心是围绕 LLM 提示词来构建的,所以很有必要了解 LLM 的基本特性。LLM 比较重要的 7 大特性,这里我直接放一张图:  篇幅有限,这里就不做 7 大特性细节展开;但是这部分很重要,不能不提,LLM 的 7 大特性就是 Agent Context 工程第一性原理的起点, 是为什么要做 Context Engineering 的事实基础。 ## Context Engineering 上下文工程 Context Engineering 的前身是 Prompt Engineering,Prompt Engineering 研究的是每一轮发给 Agent 的对话如何写更好;当 Agent 从单轮回答变成多轮行动系统时,模型在推理时看到的输入越来越复杂,就变成了 Context; 上下文 (Context) 这个词,在编程领域经常看见,例如各种开发框架下的绘图引擎(canvas),经常都需要先创建一个绘图上下文,方便后续把笔触、路径、颜色、坐标系,图形、动画路径等等绘图相关的信息注入进去,统一管理起来。 关于 Agent 领域的上下文工程的定义,OpenAI 的 Prompt Caching 文章里有一句很实用的定义 > context engineering 本质上是决定每次请求中哪些内容进入模型输入,并有意识地管理固定 context window 带来的成本、延迟、注意力分散和截断风险。 来自 OpenAI Cookbook Context 包括但不限于用户输入、工具集合、Memory 记忆,本地环境,Profile 模版,历史对话逐字稿 ,文件内容、网页观察,知识库 RAG 等等; 之所以叫工程 (Engineering),原因是所有这些数据来源,不是无脑塞入到提示词中,需要检索,匹配,召回,重复判断等等工作,是个较为琐碎和复杂的独立工程。 ## Session / Thread / Profile / Workspace 概念 如果你长期玩各种 Agent,例如 OpenClaw,LangGraph,Hermes 等会经常看到这些词。不同的实现中大家叫法也不同,导致学习 Agent 开发一头雾水。 这里的 thread 不是编程里的线程。通俗的说,当你使用 codex 这类产品,每次点击新建对话,就是一个 session,或者叫一个 thread (LangGraph 中喜欢这么叫)。创建 session 后,后台通过 session id 来管理,实现工作流串联。 前一篇 Hermes Runtime 架构文章中,可以看到 session key 串联每一层的工作流,是个关键的 identifier:  不同的 Agent 设计,对 session 的归属也不同,例如 codex 的 session 可以归属于某个项目,也可以是不属于任何项目的顶层 session:  Hermes 的 session 表示某个从外部聊天入口进来,关联一个具体 Profile (可以设定一个身份模版) 的完整路径。 默认情况下 session 之间的历史对话都是隔离的,工具列表、skill 等可以根据 session 隔离,也可以共享,这个要看具体的设计。 例如 OpenClaw 的 Workspace 、Hermes 的 Profile 设计,本质是就是定义一套身份模版,来隔离不同 session 的背景,工具列表,Skill,User.md 偏好等。 创建 Profile 模版后,可以把这些 Profile 挂载关联到某个 session 上。尽管产品层面,OpenClaw 和 Hermes 都把这个叫做不同的智能体。但是作为开发者,你应该知道,底层只不过是用一个文件夹和一些静态 md 文件,定义了一套身份模版,挂载给某个 session,然后每一轮 session 对话都固定注入给 LLM。来实现表现层上他们是不同的智能体。  Codex 没有像 Hermes/OpenClaw 那样显式命名为 Profile 的模板系统,但它通过 workspace、AGENTS.md、session instructions、skills/tool 配置等机制,实现了类似的上下文注入能力。 总结,OpenClaw / Hermes 通过 workspace 显化,让用户可以自定义一些轻量级的身份定义,记忆,工具集,skill 集。codex 则是通过 LLM 对话来隐式实现这些能力。 ## session-scoped 记忆和长期记忆 (long-term memory) 一般说 Agent Memory 时,通常会隐含两类:session-scoped memory 和 long-term memory。LangGraph 中常用 thread 表示一次会话或任务上下文,因此也叫 thread-scoped memory。session-scoped memory / thread-scoped memory 通常对应 short-term memory,指当前会话内的历史消息、状态和 checkpoint;long-term memory 则指跨 session / thread 持久保存、可复用的记忆。 session-scoped memory 通常指的是“当前 session 能继续运行所依赖的短期上下文/工作状态”: ``` 1. Transcript 当前 session 的 user / assistant / tool / observation 历史 2. Checkpoint / Runtime State 当前执行到哪一步、pending tool call、interrupt 点、graph state 3. Compressed Summary transcript 太长时,对旧上下文做摘要压缩 4. Temporary Session Vars 当前任务状态、cwd、临时选择、当前文件、运行中工具状态 5. 当前可用工具/身份配置的引用 注意:工具列表、身份定义本身通常属于 profile/agent config; 但当前 session 会“引用/加载”它们,成为本 session 的运行上下文。 ``` 这些数据会参与每轮 prompt construction,但不一定全部以原文形式注入给 LLM。 long-term memory 是跨 session 的长期共享记忆 一般来说,长期记忆,才是研究的重点,因为它是跨 session 共享的,会真正影响 Agent 的持续人格、用户理解、项目知识和未来行为 长期记忆重点研究的是以下问题: > 沉淀什么 ? > 什么时候写入 ? > 如何结构化 ? > 归属到谁 ? > 如何检索 ? > 如何召回 ? > 如何重排 ? > 如何注入 ? > 如何更新/删除 ? 也是现阶段 agent 能力提升的重点。 ## Hermes 中的 long-term memory 设计 1、Profile 模版 (Built-in Curated Memory) 如果你使用过 Hermes 的自定义 Profile 功能 (或者 OpenClaw 的 workspace),就会看到里边经常包含: > USER.md > = 用户偏好、沟通风格、工作习惯 > MEMORY.md > = Agent 对环境、项目、工具、长期经验的笔记 这些是一些快捷的,可用户输入的记忆模版文件,以 Profile 为视角,可以绑定给不同的 session。这一部分,也经常被称作:Built-in Curated Memory 2、Main Agent Inline Write 主 Agent 在正常 ReAct loop 里发现值得记的内容,直接调用 memory tool 来保存 memory,这里说的主 Agent 是包含了 ReAct loop 实现的实际工作 Agent。 特点:实时、显式、当前任务内完成。 3、Background Review Agent 主回复结束后,Hermes fork 一个后台 review agent,复盘 conversation snapshot,用专用 prompt 判断是否应该保存。通常这个 review agent 是个独立的,有自己的 system prompt,并且不为用户感知的后台 agent。 特点:不阻塞主对话,更适合“事后沉淀”。 4、MemoryProvider Lifecycle / Tools 外部长期记忆 provider,这是 Hermes 长期记忆工具的核心插件,工程实现和 memory 重心都在这个 Provider 插件里。内部使用了:mem0 / supermemory / honcho / hindsight / holographic 等工具。  MemoryProvider 是 Hermes 记忆系统的核心插件模块,用来对接不同形态的长期记忆后端,包括本地事实库、语义检索服务、用户建模系统和知识图谱记忆引擎。它可以承接检索、召回、抽取、重排、写入和上下文注入等能力。其内部概念较多,我会分为上下两篇逐步拆解。 ## Agent Memory 工具箱 Memory 是个概念,实现 Memory 通常需要借助各种工具,Agent Memory 领域的常用概念和工具如下: 写入层:fact extraction / summarization / explicit save 存储层:SQLite / Postgres / vector DB / cloud memory service 索引层:FTS5 / embedding / KG / metadata index 检索层:keyword search / semantic search / graph traversal 排序层:rank / rerank / trust / recency / filters 注入层:把召回内容放进 prompt ## RAG (Retrival-Augumented Generation) 增强检索生成 RAG 可以简单分为两个阶段: 1、存储阶段:文档/记忆 -> chunk -> embedding/索引 -> 存储 2、检索阶段:user query -> 检索相关内容 -> 排序/重排 -> 注入 prompt 现代知识库通常都采用混合检索: 向量检索(密文检索 / Dense Retrieval):管语义理解。用户搜“如何让代码更安全”,它能捞出包含“数据加密”、“权限防范”的文档(即使文档里没有“安全”这个词)。 向量检索的直观理解: > **MateMatt@mate_mattt**: [原文链接](https://x.com/mate_mattt/status/2074479762257682917) > > 向量数据库最直观的理解,向量的夹角余弦值: > 完全相同(方向完全一致):夹角 = 0。所以点乘结果越大(接近 1),说明越相似。 > 完全正交(毫无关系):夹角 = 90。也就是说,乘积为 0 表示它们垂直、无关,而不是同向。 > 完全相反(背道而驰):夹角 = 180。 > >  BM25 检索(稀疏检索 / Sparse Retrieval):管精准匹配。用户搜“AES-256”,它能一字不差地把包含这个精准型号的文档全部揪出来。 ## BM25(Best Matching 25)算法 BM25 是知识库和搜索领域中最经典、最核心的“文本匹配相关性得分算法”。在做知识库或 RAG 时,如果你只用向量检索,有时会遇到一个尴尬的情况:用户输入了一个非常精确的专有名词(比如一个特定的错误码 ERR_404_AUTH),向量数据库因为算的是“语义相似度”,可能会觉得它和“认证失败”差不多,反而把带有精准错误码的文档排到了后面。这时候,就需要 BM25 算法 来撑场子。 BM25 的核心任务是:BM25 计算一个 query 和一篇 document 的相关性。 query 里可以有多个词,每个词贡献一部分分数。得分越高,说明文档和用户想找的内容越相关。为了给出这个得分,BM25 融合了三个聪明的设计(你可以类比为前端在做多重条件权重过滤): - 词频(TF - Term Frequency):用户搜“加密”,文档 A 里出现了 10 次,文档 B 里出现了 1 次,那文档 A 胜出。但 BM25 会做词频饱和,避免关键词堆砌无限加分。 - 逆文档频率(IDF - Inverse Document Frequency):如果用户搜“的加密逻辑”,其中“的”这个词在所有文档里都存在(俗称停用词),那它的权重就很低;而“加密逻辑”非常罕见,它的权重就极高。 - 文档长度惩罚(Document Length Optimization):如果文档 C 只有 50 个字,里面出现了 2 次“加密”;文档 D 有 5000 个字,里面也出现了 2 次“加密”。那显然文档 C 的纯度更高,得分应该更高。 ## 向量检索和 BM25 匹配协同作战 用户输入一个问题,检索层会同时发出两个检索匹配请求: 1、一个让向量检索引擎去算几何距离,拿到前 10 条(向量结果)。 2、一个让本地 SQLite(利用 FTS5 插件,底层就是 BM25 算法)去查关键词,拿到前 10 条(BM25 结果)。 3、把两份结果合并,再通过 RRF、加权融合或 Rerank 模型重新排序,筛选出最无敌的上下文喂给大模型。 ## SQLite FTS5 FTS5 是 SQLite 的全文搜索模块,用来给大量文本做 full-text search,支持 tokenizer、MATCH 查询、支持 tokenizer、MATCH 查询、rank等能力,特点是低成本、离线、可控。 官方定义是:SQLite 的 virtual table module,具体见官方文档,注意它不是向量库。 BM25 是 FTS5 常用/内置的相关性排名函数之一,用来对命中的结果打分排序。 FTS5 工作流程可以简单分为: 1、写入时建立索引 > 文本 -> tokenizer 分词 -> 建倒排索引 2、搜索分词查询 > query -> tokenizer 分词 > -> 查倒排索引,快速找到候选 rows > -> 计算 BM25 / rank > -> 按相关性返回 可以把它想象成实体书后边的索引: > memory -> 第 3 页、第 8 页、第 20 页 > agent -> 第 8 页、第 15 页 这样,搜索的时候,不用从第一页开始读,而是直接通过索引找到相关页。找到相关页后,BM25 开始工作: > 这个词在当前文档出现多少次? > 这个词在所有文档里稀不稀有? > 当前文档是不是太长,导致词频虚高? 总结:FTS5 靠倒排索引避免全表扫描,BM25 基于索引统计信息对命中的文档做相关性评分。 ## 总结 Context 上下文工程里概念非常多,知识体系复杂,零碎,所以本篇介绍一些基础概念。下一篇我计划重点分析 Hermes 的 HRR (Holographic Reduced Representations) 等技术来整体串联碎片知识。 关注我,我会持续更新 Agent Memory 相关技术分析文档。 ## 相关链接 - [MateMatt](https://x.com/mate_mattt) - [@mate_mattt](https://x.com/mate_mattt) - [12K](https://x.com/mate_mattt/status/2075171293029179866/analytics) - [Jul 7](https://x.com/mate_mattt/status/2074313623523271010) - [9.4K](https://x.com/mate_mattt/status/2074313623523271010/analytics) - [OpenAI Cookbook](https://developers.openai.com/cookbook/examples/prompt_caching_201) - [Hermes Runtime 架构文章](https://x.com/mate_mattt/status/2074313623523271010) - [Jul 7](https://x.com/mate_mattt/status/2074479762257682917) - [1.2K](https://x.com/mate_mattt/status/2074479762257682917/analytics) - [官方文档](https://www.sqlite.org/fts5.html) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [6:52 PM · Jul 9, 2026](https://x.com/mate_mattt/status/2075171293029179866) - [12K Views](https://x.com/mate_mattt/status/2075171293029179866/analytics) --- *导出时间: 2026/7/12 19:57:04*
A Agent Memory Engineering 文章探讨了 AI Agent 的记忆机制,解释了为何不同 Agent(如 Claude Code 和 Codex)之间无法直接通过复制文件来迁移记忆。作者指出,这是因为模型在后期训练时与特定的记忆层“融合”了。文章对比了 Hermes、Codex CLI 和 Claude Code 三种实现,并得出结论:最聪明的架构(如向量数据库、知识图谱)输给了最简单的方案(LLM + Markdown + Bash 工具)。核心在于 Agent 遵循的读写规范,而非数据结构本身。 技术 › Agent ✍ Nicolas Bustamante🕐 2026-05-02 AgentMemoryLLMEngineeringClaude CodeCodexRAGPost TrainingMarkdownHermes
T The Hermes Agent Memory Guidebook 这是一份关于 Hermes Agent 记忆系统的终极指南。文章深入解析了 Hermes 的三层记忆架构:开箱即用的原生层、可选的插件层以及社区扩展层。作者详细说明了本地数据库与 Markdown 文件的协同工作机制,澄清了关于记忆合并的常见误区,并强调了记忆在 Agent 从无状态聊天机器人转变为具备技能累积和个性化能力的智能体过程中的关键作用。 技术 › Agent ✍ Kevin Simback🕐 2026-05-28 HermesAgentMemoryArchitectureNous ResearchTutorialMemory ManagementLLM
A Agent Memory Framework: Remember, Cite, Forget 本文提出了一个智能体记忆系统的可靠框架,该框架需同时完成三个核心任务:记住该记的、引用可信的、遗忘过期的。文章详细介绍了记忆的六个层级(如会话状态、项目记忆、索引检索等),阐述了如何通过权威排序解决冲突,并强调了通过硬过期、双时序或软衰减等机制让旧记忆失效的重要性。 技术 › Agent ✍ Vox🕐 2026-05-23 AgentMemoryRAGLangGraphMem0ZepGBrainLLM系统架构工程实践
A Agent 记忆架构指南:为什么你需要 Wiki 和 录音 文章探讨了 AI Agent 开发中的记忆瓶颈,指出单纯扩大上下文窗口并不足以解决遗忘问题。作者提出了 GBrain 和 Lossless 两个核心模式:GBrain 像公司 Wiki,用于跨会话查询事实和决策;Lossless 像会议录音,允许在长对话中无损检索原始细节。文章详细解释了二者的区别、应用场景以及如何在 OpenClaw 和 Hermes 运行时中集成。 技术 › Agent ✍ Vox🕐 2026-05-18 AgentGBrainLosslessOpenClawHermes上下文管理记忆架构RAGLLM开发指南
A Agentic Memory: 详解 Agent 记忆系统的架构与实现 文章通过生动的类比,指出缺乏记忆是当前 LLM Agent 的主要短板。作者详细拆解了 Agent 记忆系统的三个核心功能:连续性、上下文和学习。文章重点介绍了四种记忆类型:上下文记忆、外部记忆、情景记忆和参数记忆,并深入探讨了如何通过检索增强(RAG)和反思循环来构建持久的智能。 技术 › Agent ✍ Ramakrishna (techwith_ram)🕐 2026-05-17 AgentLLMMemoryArchitectureRAGVectorStoreContextEpisodic向量数据库系统设计
C Context engineering: 构建卓越 Agent 的关键 文章探讨了“Context engineering(上下文工程)”作为构建优秀 AI Agent 的核心挑战与解决方案。相比于传统的 IVR 和预设流程,Context engineering 通过“渐进式披露”和条件逻辑,确保 Agent 在对话的每一个时刻都能获得最相关且最少量的信息。这不仅解决了模型处理大量 Token 时的性能下降和幻觉问题,还能让 Agent 充分利用大模型的推理能力,适应复杂的现实场景,并随着模型升级而自然进化。 技术 › Agent ✍ Neil Rahilly🕐 2026-05-06 AgentContext EngineeringLLMSierraAI架构Prompt设计渐进式披露自然语言处理RAG系统设计
W Why Karpathy’s Second Brain Breaks at Agent Scale. How Mercury Solves It. 本文探讨了 Andrej Karpathy 的 LLM Wiki 工作流在人类“第二大脑”场景下的优势,指出其在处理 AI Agent 时的局限性。文章强调,人类记忆优先考虑可读性和反思,而 Agent 记忆系统则需要快速检索、低 Token 成本和冲突解决。Mercury 提出的混合架构方案,主张使用 Markdown 作为人类界面,同时采用结构化内存作为 Agent 的底层设施,以实现上下文的持续累积和可靠运行。 技术 › Agent ✍ Zaid🕐 2026-04-29 AgentMemoryLLMKarpathyRAGMercuryArchitectureSecond BrainDesign
M Memory Transfer Learning for Coding Agents 技术解析 本文深入探讨了一篇关于编码智能体的 Memory Transfer Learning (MTL) 论文。文章解释了如何将过往编码任务的“记忆”复用到新任务中,比较了 Trajectory、Workflow、Summary 和 Insight 四种记忆格式的效果。研究通过在多个基准测试中复用异构记忆池,证明了提取的元知识能有效提升智能体解决新问题的能力。 技术 › Agent ✍ AVB🕐 2026-04-21 AgentLLMMemoryTransfer LearningCoding AgentRAGReinforcement Learning论文解读
A Agents Are Stuck in a Loop: Memory Growth and Propagation 文章深入探讨了 AI Agent 面临的记忆系统瓶颈:无限记忆增长(UMG)导致检索效率低下和噪声干扰,以及虚假记忆传播(FMP)利用思维链错误放大幻觉。作者指出现有的 RAG 系统因读写混合而加剧了该问题,并提出可以借鉴强化学习(RL)机制,根据任务验证结果对记忆进行奖惩打分,从而过滤无效记忆。 技术 › Agent ✍ Siddharth🕐 2026-04-20 AgentLLMMemoryRAGReinforcement LearningHallucinationMemGPTCoT
A AI 记忆工具两大阵营:Memory Backends 与 Context Substrates 文章深入分析了 GitHub 上的 AI Agent 记忆工具,将其分为两大阵营:一是“记忆后端”,如 Mem0 和 Supermemory,主要提取事实并存储于向量数据库;二是“上下文基底”,如 OpenClaw,通过人类可读的结构化文件让会话在上下文中累积。作者指出,虽然 Camp 1 主导了市场,但 Camp 2 的架构才是支持连续、多会话工作的未来方向,例如 Zep 已开始从“记忆”转型为“上下文工程”。 技术 › Agent ✍ witcheer🕐 2026-04-17 AgentOpenClawMem0ContextMemoryRAGLLM向量数据库知识图谱
构 构建永不遗忘的智能体:从基础到向量与图谱混合记忆方案 文章深入探讨了LLM智能体的“记忆”难题,指出单纯增加上下文窗口无法解决“迷失在中间”效应及会话遗忘问题。作者基于认知科学框架,分析了从Python列表、Markdown文件到向量检索各阶段的局限性,强调构建兼具持久化、语义理解和关系推理能力的记忆层至关重要,最终引入了一个能够整合向量、图谱和关系存储的开源解决方案。 技术 › Agent ✍ Akshay🕐 2026-04-14 AgentMemoryLLMVector SearchGraph RAGLong-term MemoryContext WindowCognitive ScienceOpen Source
本 本周顶级 AI 论文精选 文章精选了本周 6 篇顶级 AI 论文,涵盖 Harness Handbook、MSCE 记忆技能框架、PRO-LONG 长程记忆机制、Anthropic 全局工作空间解释性研究、Meta 的 GAMUT 完整性基准测试以及渐进式披露模式。 技术 › LLM ✍ DAIR.AI🕐 2026-07-27 AI论文AgentMemoryInterpretabilityAnthropicMetaLLMResearch