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 在功能定位方面存在相同之处，不过二者也各有优势：

• Ray Serve 原生支持以分布式模式运行，可在单一应用中编排并部署多个模型，以满足复杂推理场景的需求。同时，其内置的弹性伸缩特性能够有效平衡用户请求与资源开销。
• Triton 主要专注于单机推理场景，兼容多种硬件平台。通过引入动态批处理、多 GPU 并行推理等技术以提升模型推理性能，同时支持以 Backend 插件形式集成多种模型框架，并对外提供统一的接入 API。

关于线性一致性读的定义，简单而言就是在 T 时刻执行写入操作，那么在 T 时刻之后一定能够读取到之前写入的值。Raft 算法能够至少保证集群节点数据的最终一致性，也就说就某一特定时刻而言各个节点之间的数据状态允许存在滞后。在分布式场景下如果允许各个节点随机响应用户的读请求，则可能会读取到脏数据。如果希望基于 Raft 算法实现线性一致性读语义，最简单的方式就是将读操作作为一个指令提交给 Raft 集群，由于 Raft 算法能够保证指令执行的顺序性，所以该读操作指令一定能够读取到在此之前写入的值（本文将此类线性一致性读策略命名为 RaftLog Read）。然而，RaftLog Read 的缺点也是显而易见的，每次读操作都需要走一遍完整的 Raft 算法流程势必效率低下，并且大部分的应用场景都具备读多写少的特征，所以该策略势必会让 Raft 集群产生大量的日志文件，增加磁盘和网络的开销。

换一个角度思考，在 Raft 算法中更新操作都由 Leader 节点负责响应，那么极端一点每次都从 Leader 节点读数据是不是就万事大吉了呢？先不说这种方式将一个分布式系统退化成了单机系统，我们还需要考虑下面两个问题：

• 日志数据从提交到被业务状态机所应用这中间存在一定的时间滞后性，所以直接执行读操作不一定能够读取到最新的数据。
• 当前 Leader 节点不一定是有效的，因为 Leader 节点的变更通常有一个时间差，而这中间存在导致脏读的可能性。

上一篇我们介绍了 JRaft 关于日志复制机制的设计与实现，其中提到了快照机制本质上也是一种对日志数据复制的优化手段，本文我们就对 JRaft 关于快照机制的设计与实现展开分析。在开始之前我们先聊聊为什么需要引入快照机制，思考以下两个问题：

1. 因为日志数据需要落盘存储，当日志数据量大到磁盘空间无法容纳时，除了扩容是否还有其它的优化手段？
2. 当一个新的节点加入 Raft 集群时需要重放集群之前接收到的所有指令以追赶上集群的数据状态，这一过程往往比较耗时和消费带宽，如何进行优化？

对于一个生产级别的 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 节点等待的时间则能够很好的解决此类问题。

在《理解 Raft 分布式共识算法》一文中，我们对于 Raft 算法的理论进行了介绍。过去几年，围绕 Raft 算法涌现出了一系列各类语言的实现（参考 Raft 算法官网），这也充分证明了该算法相对于 Paxos 算法在理解和实现层面的友好性。从本文开始，我就以 SOFA-JRaft 为例，用多篇文章来分析一个生产级别的 Raft 算法应该如何实现。

SOFA-JRaft 是一个基于 Raft 算法的 java 语言实现算法库，提供生产级别的稳定性、容错性，以及高性能，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。