Statewave：Agent记忆字节级确定性的开源解法

向一个 Mem0 或 Zep 部署提出关于同一个用户的同一个问题两次，你可能得到两个不同的答案。原因并非底层事实发生了变化——而是因为两个系统都在查询时检索记忆，而基于嵌入向量的查询时检索本质上是一个排序问题，而非查找。重新排序的阈值会漂移，最近邻的 ties 会以不同方式打破，大语言模型总结器会用两种不同方式改述相同的事实。对于一个基本无害的聊天机器人来说，这没什么大不了的。但对于一个你会 later 必须向审计员、监管机构或者凌晨三点值班工程师解释其决策的智能体来说，这就是一个真正的问题。

Statewave 本月在 Product Hunt 上线，针对这个问题给出了一个狭窄但近乎固执的答案：不要再在查询时检索记忆。一次性编译，deterministically 编译，让智能体每次在相同时间点对相同主题提出相同问题时获得相同的字节。它是开源的（Apache-2.0），自托管在带有 pgvector 的 Postgres 上，而且——对于一个 2026 年的开发者工具发布来说很不寻常——它并不打算向你推销托管方案。没有 SaaS 层级。如果你想要它，你就自己运行它。

这才是真正值得关注的故事，它比"又一个 AI 智能体的记忆层"有趣得多。让我们深入了解它做了什么、如何构建的，以及这个确定性赌注是否值得你关心。

Statewave 在 Product Hunt 上线，作为一个 AI 智能体的开源"记忆运行时"发布——这是项目自己的定位，不是营销废话，因为代码支撑了这一点。它与 Mem0 和 Zep 处于相同的概念位置：给予基于大语言模型的智能体跨会话的持久化、结构化记忆，而不是把原始聊天历史塞进上下文窗口。截至撰写本文时，GitHub 仓库（smaramwbc/statewave）有 214 颗星——很小、 hype 之前的状态，这类项目还没有被营销团队重新包装成 Series A 融资演讲稿。这也是为什么现在值得仔细阅读，而不是等它被重新定位之后再读。

它实际做什么

Statewave 围绕主题（subject）组织记忆——一个用户、一个账户、一个智能体、一个仓库，无论你的应用需要持久化上下文的任何实体。所有发生在某个主题上的事件都被记录为 episodes：一条原始事件，比如一张工单消息、一次代码审查评论、一次工具调用结果。Episodes 本身还不是记忆——它们是原材料。

系统随后会将 episodes 编译成带置信度分数的 typed memories，在主题变更时而非每次查询时进行。当你的应用需要获取提示的上下文时，它调用 /v1/context 并返回一个针对该主题最相关编译记忆的排名化、token 有上限的 bundle——大小适配你的提示预算，而非对所有历史记录的原始倾倒。

用项目自己的话来概括这个定位："大多数记忆层存储孤立的事实并在每次查询时检索它们……Statewave 在每次主题变更时编译一次上下文，并附带溯源——这才是购买更高多跳准确率的真正原因。"这个具体准确率声明在独立基准测试下是否成立尚属未知领域——该项目不发布第三方评估数字——但架构声明（compile-once vs. retrieve-per-query）是真实的，在代码中可验证。

管道是一个清晰的三阶段设计：

Ingest — 原始事件作为与主题绑定的 episodes 入库。

Compile — episodes 被处理成带置信度分数的 typed memories，通过启发式编译器或 LLM 后端编译器（STATEWAVE_COMPILER_TYPE=heuristic|llm）。

Assemble — 上下文 bundle 按需构建：带排名、token 上限和溯源标签。

确定性保证来自于中间步骤在每次主题变更时执行一次，而非每次查询时执行。因为编译后的记忆状态在下一次变更前是固定的，相同的 /v1/context 调用在相同时间点对相同主题产生相同的字节——没有重新嵌入、重新排序或重新总结带来的采样噪声。

溯源（Provenance） 是另一个支撑点。每个 bundle 都附带一个内容哈希的、ULID 可寻址的收据，显示哪些源 episodes 对其有贡献，使用 HMAC-SHA256 签名，并在收据中嵌入 assembly 时生效的策略快照。如果你需要在事后回答"智能体为什么这么说"，这是一个真正有用的原语——你不是在逆向工程向量搜索，而是在阅读一份签名清单。

底层技术栈相当普通：

• 数据库：PostgreSQL 14+ 配合 pgvector ≥ 0.4.2 处理向量侧
• SDK：Python（pip install statewave）和 TypeScript（@statewavedev/sdk via npm）
• LLM 抽象：LiteLLM，因此 LLM 后端编译器可以通过配置指向 OpenAI、Anthropic、Bedrock、Ollama 或 100+ 其他提供商
• 部署：Docker、Docker Compose，以及 Kubernetes 的 Helm chart；支持 linux/amd64 和 linux/arm64 镜像

运行起来确实只需要一条命令。有两条支持的路径，取决于你想要托管式本地进程还是对技术栈的完全控制：

# Quick local install
npx @statewavedev/statewave
# or
curl -fsSL https://www.statewave.ai/install | sh

# Self-hosted with Docker Compose
git clone https://github.com/smaramwbc/statewave && cd statewave
docker compose up -d

Compose 路径启动带有 pgvector 的 Postgres 加上 API 运行在 localhost:8100，包含迁移，用"演示模式"运行——使用 stub 嵌入向量——意味着你可以在没有 API key 的情况下试用。要获得真正的语义检索，你需要将 STATEWAVE_EMBEDDING_PROVIDER 指向 litellm（或者如果你纯粹依赖启发式编译器则设为 none）并提供提供商凭证。这是一条合理的入门路径，不过值得明确标注：零配置的演示体验与正确嵌入的、LLM 编译的部署不是同一个产品，两者之间的差距才是大部分真实设置工作所在——配置一个真正的嵌入提供商、在启发式和 LLM 编译之间选择、为你的提示大小调整 token 预算，以及决定对于你的特定写入模式应该在何时触发重新编译。

配置遵循一致的 STATEWAVE_ 前缀环境变量方案，这是一个小但有说服力的细节：它读起来像是为集成到现有运维工具链而设计的软件（config-as-env-vars、Helm-chart-ready、Docker-first），而不是围绕托管控制台设计的软件。这种一致性比听起来应该的重要得多——一个只通过仪表盘暴露其旋钮的记忆层，是一个你无法在 CI 中进行版本控制或重现的记忆层，而可重现性正是这个项目的全部意义。

连接器生态系统——GitHub、Slack、Discord、Notion、Zendesk、Gmail——也值得再看一眼，因为它定义了真实部署中 episodes 的实际来源。没有连接器的情况下，"引入一个 episode" 意味着你的应用代码必须在每次有值得记住的事情发生时显式调用引入 API，这对于专门构建的智能体来说没问题，但对于在现有产品上改造记忆来说就很繁琐。连接器把这变成了配置：指向一个 Slack workspace 或 GitHub org，工单、PR 评论或客户对话就开始作为 episodes 流入，无需自定义胶水代码。这与 Zapier 或 Segment 将第三方事件转换为标准化流量的方式相同——不华丽，但通常是记忆层被采用还是停留在演示阶段的区别所在。

除了核心循环之外，v0.9 还增加了多租户支持，每个租户有独立的策略 bundle 和区域固定——如果你在此基础上构建产品而非为单个内部智能体运行，这相关——加上一个带有敏感度标签的策略引擎，用于标记 PII、财务数据或 secrets，以及覆盖 GitHub、Slack、Discord、Notion、Zendesk 和 Gmail 的连接器生态系统，用于从实际事件发生的地方拉取 episodes。

与现有方案的对比

2026 年的 AI 智能体记忆领域实际上有两个占主导地位的托管玩家，而 Statewave 被定位为两者的刻意对立面。

Mem0 将向量存储与可选的知识图谱相结合，并在每次查询时检索。它以托管为优先：有一个免费层级，现在覆盖真实的原型设计（10,000 条记忆，不是玩具演示），然后随着用量扩展有每月 19 美元、79 美元和 249 美元的付费层级。合规认证位于 Pro 层级之后。价值主张是快速实现"能记住事情的智能体"，同时减少运维工作。

Zep 基于 Graphiti 构建，后者是一个时间知识图谱，其中时间是第一维度的概念——它的设计目的是回答"我们何时知道这件事，以及这个认知是何时变化的"，而不仅仅回答"我们现在知道什么"。Zep Cloud 为你处理 Neo4j 操作，并具备 SOC 2 Type 2 和 HIPAA 认证，如果你身处受监管行业且不想自己承担合规风险，这些认证非常重要。它的 Flex 套餐每月约 125 美元——值得注意，网上流传的 25 美元实际上是信用充值金额，而非套餐价格，所以在做预算前请直接查看当前定价。

Statewave 不在这两个维度上竞争。它没有托管服务来转移运维负担，也没有时间知识图谱——它不会像 Graphiti 那样声称能够对事实如何随时间演变进行推理。它提供的是确定性作为一等属性、可审计性，以及真正宽松的开源许可证（Apache-2.0，明确的专利授权，可用于专有或托管产品而无需单独协议），同时支持模式是"自己运行"，企业授权可通过邮件购买，适合那些想要支持合同但不想依赖 SaaS 的团队。

这是一个真正的战略差异，而非功能清单的差异：Mem0 和 Zep 卖给你的是一个运维团队。Statewave 卖给你的是一份规格说明和参考实现。

为什么开发者应该真正关注

成本。没有按使用量计价的溢价——你只需为 Postgres 计算和存储付费（以及如果你使用 LLM 编译器的话，加上可选的 LLM 调用费用），仅此而已。对于位于每个 AI 智能体回合热路径上的记忆层，在大规模场景下这可能非常重要，但这也意味着你现在需要自己为有状态数据库做容量规划，而不是让供应商在 API 计量器背后替你处理。

延迟和过期，不是一回事。每个主题变更编译一次意味着大多数 /v1/context 调用是在读取预计算状态，而不是重新运行检索和重排序——这应该很快。但这同时也意味着记忆的新鲜度受上次编译运行时间的约束。如果一个事件发生，但在 AI 智能体请求上下文之前没有触发重新编译，AI 智能体获取的就是之前的、过期的数据包。Mem0 和 Zep 的查询时方法每次调用较慢，但始终反映最新摄入的状态。这是一个真正的权衡，不是严格的改进——根据你的 AI 智能体是需要"快但略有落后"还是"成本一致且始终最新"来选择。

锁定。Apache-2.0 加自托管加 REST API 意味着基本上零锁定——你可以 fork 它、审计它，或者无需任何人许可即可迁移出去。这与 Mem0/Zep 的托管便利性形成对比，后者的迁移意味着要导出 embeddings 并针对新的 API 表面对检索调用进行重新架构。

安全和合规。这是 Statewave 设计发挥价值的地方。带有签名、内容哈希的溯源收据以及嵌入的策略快照，正是合规团队在质疑 AI 智能体决策时想要的产物——"告诉我它知道什么以及这些知识来自哪里"变成了一次数据库读取，而非一次调查。敏感度标签和 PII/财务/密钥数据的策略引擎在检索上游增加了治理控制，而不是事后追加。所有这些都没有 SOC 2 或 HIPAA 认证标志——认证责任完全由你这位运营商承担，这与向 Zep 付费购买其认证是一个有意义的成本差异。

可维护性。你运行的是带有 pgvector 的 Postgres、迁移脚本，以及（如果你想要真正的语义）LLM 编译器管道。对于大多数已经在运行 Postgres 的后端团队来说，这些都是普通的基础设施，比 Zep 的 Neo4j 支持图引擎要普通得多。然而，这确实是一个需要保持健康、备份和扩展的有状态服务——这是 Mem0 和 Zep Cloud 为你吸收的成本。

适用场景

受监管行业的支持或顾问 AI 智能体（医疗、金融、法律），你需要精确重建 AI 智能体在给出答案时知道什么，并附有加密签名轨迹——而不是尽力而为的日志。

AI 智能体评估和 CI 管道，其中可复现性是核心要点：你希望相同的测试输入每次运行产生相同的上下文包，这样 AI 智能体行为的回归就归因于模型或提示变更，而非检索噪声。

多租户 SaaS 产品，每个客户嵌入 AI 智能体记忆，使用 v0.9 的每租户策略包和区域锁定来满足数据驻留要求——这是事后才想到要附加到托管第三方记忆 API 上的尴尬功能。

内部编码 AI 智能体，需要在会话之间持久记忆仓库或团队约定，而你根本不想把那些上下文发送给第三方托管记忆服务。

事件和事后复盘工具，其中 AI 智能体对值班频道或 Slack 事件线程的编译记忆需要在数月后可以重建，并附带收据证明哪些消息构成了特定摘要——更像是审计日志而非聊天记录。

成本敏感的高容量 AI 智能体产品，其中来自托管供应商的按查询检索定价在经济上不可扩展，你更愿意为可以控制的 Postgres 容量付费，而非按记忆或按调用计费。

值得将其放在整个领域背景下审视

Mem0 和 Zep 不是 AI 智能体记忆领域的唯一名字。Letta（前身是 MemGPT）采取了另一种方法，将记忆管理视为 AI 智能体本身通过函数调用编辑的东西，而非外部编译器。LangChain 的 LangMem 库为已经标准化在 LangChain/LangGraph 上的团队提供了一个更轻量级、框架原生的层。这些都没有直接与 Statewave 的特定主张竞争——确定性的、溯源签名的编译——这在这个领域仍然是最具差异化的领域，否则这个领域在某种程度上都聚集在查询时检索上。

发布材料没有深入讨论的局限性

没有托管层意味着运维负担完全由你承担——可靠地运行 Postgres、调整 pgvector 索引、处理备份和故障转移。这是 Mem0/Zep 定价页隐含为你隐藏的真正成本。

214 个 GitHub stars 说明项目还很早期。这是一个没有长期生产跟踪记录的新项目；将架构视为有前景的，在将其用于任何受监管场景之前自行审计实际行为。

确定性/新鲜度的权衡是双刃剑——重新编译时机成为你现在必须推理和调优的东西，而查询时检索系统设计上永远不会有"重新编译前过期"的状态。

演示模式使用桩 embeddings。一键 Docker 体验并不能证明检索质量——只有在连接了真实的 embedding 提供商后，才能测试质量，理想情况下还需要针对自己的评估集运行测试。

没有独立基准数据来支持"更高的多跳准确性"这一说法。这是一个看似合理的架构论证，而非（目前）已证实的结论。

没有自身的合规认证——审计跟踪工具是有的，但 SOC 2/HIPAA 认证是你需要自己完成的工作，而不是采用这个项目就能继承的。

综合来看，诚实的结论是这三个产品并非真正在为同一个买家竞争。Mem0 是快速入门之选，适用于"AI 智能体需要记忆东西，这周就发货"的场景。Zep 是正确选择当你的产品真正需要推理事实如何随时间演变，并且你想让别人来管理图数据库和合规文书工作。Statewave 是正确选择当 AI 智能体知道的可复现性和可审计性是硬性要求、你乐于运行 Postgres、以及你宁愿拥有整个技术栈而非依赖供应商的正常运行时间和路线图。

确定性这个赌注是合法的工程，而非营销包装——在每个主题变更时编译一次记忆并为每个包附带签名溯源是一个真正可验证的架构选择，而且它解决了一个真正存在的问题：查询时检索系统在合规官面前难以解释的不确定性。这值得认真对待。

让我持怀疑态度的是，这个方案面向的目标用户群体究竟有多大。如今大多数构建 AI 智能体记忆功能的团队，他们调试的是"错误的检索"而非"不一致的检索"——他们实际遇到的失败模式是"AI 智能体遗漏了某些相关内容"，而不是"AI 智能体对同一个问题给出了两种不同答案"。确定性作为一个特性，在你拥有它之后意义重大，而在你最需要它之前几乎毫无价值——这使得它很难推销给一个尚未被坑过的团队。在一个两大竞品靠剥离运维来竞争的市场中，没有任何托管方案就直接发货，也是一笔实实在在的采用税：它把受众筛选到"只想自托管"的团队，这个圈子比"需要 AI 智能体记忆功能"的团队要小得多。

以上这些都不是说这个项目方向错了。它只是尚处早期、目标明确——对于一个上线一周、仅有 214 颗星的 GitHub 仓库来说，为一个特定痛点（合规、审计、可复现的评估）而构建，而不是追逐最广泛的市场，正是你所能预期的。

谁现在该试、该等、该跳过

如果你的 AI 智能体工作流处于受监管领域，需要用比日志行更严格的方式来回答"AI 智能体在什么时候知道什么"——或者你正在运行 AI 智能体评估，而上下文的可复现性正是目前导致结果飘、无法解释的原因——那就现在试试。

如果你的需求只是让 AI 智能体跨会话记住用户偏好，想要最快的实现路径——先从 Mem0 的免费套餐开始，只有当你产生了对溯源或确定性的切实需求，而托管方案无法满足时，再来看 Statewave。

如果你实际的需求是对不断演变的事实进行时间推理——"关于这个实体，我们上个月相信的是什么 vs. 现在相信的是什么"——那就跳过，因为那是 Graphiti 的专属优势，不是 Statewave "一次编译"架构设计用来处理的事情。如果你对在生产环境运营另一个有状态的 Postgres 服务没有兴趣，也跳过。

考虑到这个项目还处于如此早期的阶段，如果这个架构让你感兴趣，最有用的做法是自己去读编译器代码，而不是盲目相信其准确性声明——这个项目足够小，真正的代码审计用不了三个月，一个周末就够。

如果你曾在生产环境中构建或评估过 AI 智能体记忆层：你有没有被非确定性检索严重坑过，以至于愿意用它换取一个自托管、一次编译的架构——还是在你的团队里，"错误"记忆始终比"不一致"记忆是更大的问题？