大语言模型正在从一次性问答工具逐渐走向长期运行、持续交互、跨任务协作的 Agent 系统。在这个过程中，一个越来越关键的问题浮现出来：模型如何记住过去？如何更新知识？如何在不同任务、用户和平台之间复用经验？
论文《MemOS: A Memory OS for AI System》正是围绕这个问题展开。它提出，未来的大模型系统不能只依赖模型参数和上下文窗口，也不能把 RAG 当作完整的记忆方案，真正面向长期 Agent 的 AI 系统，需要一个类似操作系统的“记忆操作系统”，把记忆作为一等系统资源进行建模、调度、治理和演化。
本文主要围绕 MemOS 提出的背景、设计哲学、记忆建模方式，以及整体架构设计对论文进行解读。
AI memory is not merely static storage, but a dynamic cognitive substrate critical for continuous learning and adaptation.
大语言模型（LLMs）已经展现出强大的理解、生成和推理能力，但它们默认仍更像一次性推理引擎：上下文窗口决定了“当前能看到什么”，模型参数承载的是训练阶段沉淀的通用知识，而跨会话、跨任务、跨环境的历史经验并不会自然沉淀下来。对 Agent 系统而言，这意味着它可以完成一次任务，却未必能记住用户偏好、复用过往轨迹、纠正旧信息，或在长期协作中持续成长。
AI 记忆（AI Memory）试图补上这块能力拼图。本文基于综述文章《Survey on AI Memory: Theories, Taxonomies, Evaluations, and Emerging Trends》，围绕几个核心问题展开：首先区分 LLM Memory、Agent Memory 与 AI Memory 三个层次，并澄清 Memory 与 Knowledge、Context、Experience 的边界；随后介绍论文提出的 4W 分类法，从生命周期、内容类型、存储形式和模态维度理解记忆；接着讨论单 Agent 记忆系统的主流架构、基础流程与高阶能力，以及多 Agent 场景下的共享记忆、协作一致性和治理问题；最后整理记忆系统的评估维度与典型基准，说明如何判断一个 Agent 是否真正记得住、找得准、能更新、会遗忘、用得好。
故事从某客户的一次吐槽 Daft 执行性能讲起。话说某一天，一个用户突然在群里吐槽说自己以分布式模式运行的 Daft 任务，只有一个 Worker 节点在参与计算，剩余节点都在旁边吃瓜围观。
在 DATA + AI 数据科学领域，Pandas 无疑是数据科学家和开发者们的“瑞士军刀”。凭借相对完善的 DataFrame API 和丰富的生态，Pandas 极大简化了在中小型数据集上的数据清洗、分析和探索性工作。然而，随着数据集规模的增长，Pandas 在执行效率和资源开销层面的短板也逐渐凸显，因此诞生了 Polars、Dask 一类的产品：
Polars 采取纵向优化策略，通过 Rust 语言对引擎内核进行重新设计和实现，并引入查询优化器、向量化执行引擎等手段以进一步提升执行性能，但开源版本仅提供单机运行模式。
Dask 则采用横向优化策略，可以将其看作是 Pandas 的分布式实现。
Daft 则融合了 Polars 和 Dask 二者的优势，在内核层面采用 Rust 语言实现，并提供 Python DataFrame 和 SQL 接入 API，同时提供单机和分布式两套执行引擎，并支持无缝切换运行模式。重要的是，Daft 内置多模态类型和算子，并依托于 Ray 实现异构资源管理，从而将应用领域由传统结构化数据处理拓展至多模态数据处理场景。
Daft 是一款面向 DATA + AI 多模态数据处理与分析场景的计算引擎，支持单机和分布式两种运行模式，内核采用 Rust 语言编写，并提供 SQL 和 Python DataFrame 两种交互方式。
在文章《Processing 300K Images Without OOM: A Streaming Solution》中，作者介绍了基于 Daft 能够轻松实现对大规模图片数据集进行流式处理。那么，Daft 在幕后是如何执行用户输入的 SQL 或 DataFrame 的呢？在本文中，我们将继续以图片处理场景为切入点，通过一个典型的图片分类任务 DataFrame 示例，引领你深入探寻 Daft 单机执行引擎的运行机制。
本文英文版本已发布至 Daft 官网：“Exploring Daft’s Local Execution: The Swordfish Engine”
Triton Inference Server（下文简称 Triton）是 Nvidia 推出的高性能推理服务器，支持多种模型框架和硬件平台，关于 Triton 的更多内容可以参考 官方文档。Triton 与 Ray Serve 在功能定位方面存在相同之处，不过二者也各有优势：
关于线性一致性读的定义，简单而言就是在 T 时刻执行写入操作，那么在 T 时刻之后一定能够读取到之前写入的值。Raft 算法能够至少保证集群节点数据的最终一致性，也就说就某一特定时刻而言各个节点之间的数据状态允许存在滞后。在分布式场景下如果允许各个节点随机响应用户的读请求，则可能会读取到脏数据。如果希望基于 Raft 算法实现线性一致性读语义，最简单的方式就是将读操作作为一个指令提交给 Raft 集群，由于 Raft 算法能够保证指令执行的顺序性，所以该读操作指令一定能够读取到在此之前写入的值（本文将此类线性一致性读策略命名为 RaftLog Read）。然而，RaftLog Read 的缺点也是显而易见的，每次读操作都需要走一遍完整的 Raft 算法流程势必效率低下，并且大部分的应用场景都具备读多写少的特征，所以该策略势必会让 Raft 集群产生大量的日志文件，增加磁盘和网络的开销。
换一个角度思考，在 Raft 算法中更新操作都由 Leader 节点负责响应，那么极端一点每次都从 Leader 节点读数据是不是就万事大吉了呢？先不说这种方式将一个分布式系统退化成了单机系统，我们还需要考虑下面两个问题：
上一篇我们介绍了 JRaft 关于日志复制机制的设计与实现，其中提到了快照机制本质上也是一种对日志数据复制的优化手段，本文我们就对 JRaft 关于快照机制的设计与实现展开分析。在开始之前我们先聊聊为什么需要引入快照机制，思考以下两个问题：
对于一个生产级别的 Raft 算法库而言必须能够解决好上述问题，而 Raft 算法也为解决上述问题提供了思路，即快照机制。该机制通过定期为本地的数据状态生成对应的快照文件，并删除对应的日志文件，从而降低对于磁盘空间的容量消耗。当一个新的节点加入集群时，不同于从 Leader 节点复制集群在此之前的所有日志文件，基于快照机制该节点只需要从 Leader 节点下载安装最新的快照文件即可。由于快照文件是对某一时刻数据状态的备份，相对于原生日志数据而言在容量上要小很多，所以既降低了本地磁盘空间占用，也降低了新加入节点从 Leader 节点同步历史数据的时间和网络开销，很好的解决了上面抛出的两个问题。
与上一篇介绍的主节点选举一样，日志复制（Log Replication）同样是 Raft 算法的核心组成部分，是支撑 Raft 节点达成共识的基础。Raft 中的日志主要可以分为两类：一类是协议自身运行所生成的日志，例如集群节点配置变更信息；另外一类就是用户向集群提交的指令所生成的日志。为了让集群中的各个节点达成共识，Leader 节点需要将日志数据复制给集群中的各个节点，并采用投票机制让这些节点决定是否许可日志对应的操作。对于被许可的操作日志，各个节点会严格按照相同的顺序在本地进行存储，并重放日志对应的操作，以此实现节点之间的共识。
JRaft 在设计和实现层面为每个 Follower 和 Learner 节点都绑定了一个复制器 Replicator 实例，由 Replicator 负责向目标节点复制日志数据，Replicator 实例之间彼此相互隔离，互不影响，并由 ReplicatorGroup 进行统一管理。日志复制需要涉及到集群中节点之间的频繁通信和数据传输，所以需要保证复制操作的高性能，并且不允许出现乱序和断层。为此，JRaft 引入了多种优化策略，包括：Follower 节点之间并发复制、批量发送，以及 Pipeline 机制等。
主节点选举（Leader Election）是 Raft 算法的核心组成部分，也是 Raft 算法库的主要应用场景之一。Raft 算法设计了 term 和 logIndex 两个属性，分别用于表示 Leader 节点的任期，以及集群运行期间接收到的指令对应的日志条目的 ID，这两个属性都是单调递增的。一个 Leader 节点在任期内会始终向其管理的所有 Follower 节点宣示主权，以避免这些 Follower 节点发动革命，推翻自己的政权，成为新的 Leader 节点。然而，世事无常，如果 Leader 节点因为某些原因不能或未能即时向某些 Follower 节点宣示自己的主权，则这些 Follower 节点在等待一段随机的时间之后就会尝试竞选成为新的 Leader 节点。
之所以这里采用随机化的等待时间，是为了避免两个或多个 Follower 节点同时发起选举进程，进而出现这些节点都没有赢得过半数的选票。于是，这些节点又在同一时间发起下一轮选举进程，延长了集群无 Leader 节点的时间，而通过随机化各个 Follower 节点等待的时间则能够很好的解决此类问题。