你的 AI 助手,还在每次对话都失忆吗?今日 AI 最前线深度拆解(2026.03.26)

如果你的 AI 助手忘了你昨天说的话，忘了你的技术偏好，每次对话都要从头介绍自己——如果你的多模态 Agent 越调用工具、速度越慢，串行等待让延迟飙升——如果你想问 AI：”这段形式化证明对不对？”，但模型根本没有定理证明的能力——

今天这期，我们聊的正是这些问题。

今天 GitHub Trending 上最受关注的 AI 项目，有一个共同的方向：让 AI 真正”记住”东西，并且越用越好用。与此同时，arXiv 上两篇刷新 benchmark 的论文，一篇让多模态 Agent 的推理速度提升 3.35 倍，另一篇让 560B 参数的大模型在数学竞赛级定理证明上达到了 97% 的正确率。

我们一篇一篇来拆解。

一、Hermes-Agent：会自我进化的个人 AI 助手

解决了什么问题

你有没有这种体验：你告诉 ChatGPT “我的项目用 TypeScript，不要用 any“，它这次听了，下次对话又忘了。你给它讲了你们团队的代码规范，它每隔几周就需要重新喂一遍。

这就是现有 AI 助手的根本缺陷——它们是”失忆的聊天机器人”，没有跨会话记忆，没有学习能力，每次对话都是一张白纸。

Hermes-Agent 由 Nous Research 开发，GitHub 今日新增 850 Stars，总计 13,211 Stars，正在解决这个问题。它的目标是：让 AI 助手越用越懂你，而不是永远保持零状态。

技术/产品原理

理解 Hermes-Agent，最好的类比是：把它想象成一个拥有”日记本 + 工作手册 + 自学能力”的助手，而不是每天清空记忆的聊天机器人。

它有三个核心机制：

第一，闭环学习架构。每次你和它完成一次任务，它不是简单结束对话，而是自动把这次任务的经验提炼成一个”技能程序”，存入本地记忆库。下次遇到同类任务，它会先检索自己之前积累的技能。这个过程完全自动，不需要你手动告诉它”记住这个”。

第二，持久化记忆系统。它使用 SQLite FTS5 全文检索 + LLM 摘要压缩来存储跨会话记忆，同时通过 Honcho 用户建模框架构建你的”数字画像”——你的技术偏好、工作习惯、常用工具，都会逐渐沉淀下来，成为它回答问题的隐性背景。

第三，多平台消息网关。它支持 Telegram、Discord、Slack、WhatsApp 接入，你可以随时随地发一条消息给它，它知道这是你、知道你的上下文、知道你想要什么。

安装只需一行命令：

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

支持 Linux、macOS、WSL2，安装后运行 hermes，首次配置选择 LLM 提供商（支持 OpenRouter 200+ 模型），然后就可以开始和它建立”长期关系”了。

适合谁用 / 不适合谁用

最适合：需要 AI 长期记住工作上下文的开发者、研究者，以及希望在 Telegram/Discord 等平台随时调用 AI 的人。它尤其适合那些已经厌倦了”每次对话都要重新介绍项目背景”的人。

不适合：只需要一次性问答、不在意会话连续性的场景；完全不懂命令行的非技术用户；对企业合规部署有严格要求的团队（目前无官方企业版）。

与 AutoGPT、LangChain 的核心区别在于：LangChain 是”乐高积木”，你来决定怎么搭；Hermes-Agent 是”会学习的机器人助手”，它自己进化。前者给你工具，后者给你成长。

项目地址：https://github.com/NousResearch/Hermes-Agent

二、Supermemory：给所有 AI 应用装上”海马体”

解决了什么问题

很多开发者给自己的 AI 应用做了 RAG（检索增强生成），以为这就是”记忆”了。但 RAG 只是”图书馆”——你去查什么，它就找什么文档给你，对所有用户返回一样的结果，不知道用户上次说了什么，不会主动更新旧信息，也不知道”这条信息已经过时了”。

真正的记忆系统，应该像大脑的海马体：自动提取重要事实、当有新信息和旧信息矛盾时主动更新、旧的不重要的信息自动遗忘、还要维护一个关于用户的”长期画像”。

Supermemory 就是在做这件事。今日新增 810 Stars，总计 19,194 Stars，它提供一套 API，让任何 AI 应用都能拥有这样的记忆引擎。

技术/产品原理

RAG 和 Supermemory 的区别，可以用一个场景来说明：你用一个 AI 编程助手，第一天告诉它”我们团队用函数式风格，避免类继承”，用了两个月后你改口说”新项目用 OOP，之前说的不适用了”。

RAG 的处理方式：两条信息都保存着，查询时两条都可能被检索出来，你不知道哪条是最新的，模型也不知道。

Supermemory 的处理方式：检测到矛盾，自动用新信息覆盖旧信息，标记变更时间，维护一个”当前有效”的用户画像。

这套机制在三个权威 benchmark 上都拿了第一名：LongMemEval 得分 81.6%、LoCoMo 第一、ConvoMem 第一。它还提供统一的混合检索——一次 API 调用同时返回用户画像和相关记忆片段，不需要你自己拼接。

开发者接入非常简单：

import Supermemory from "supermemory";const client = new Supermemory();// 存入记忆（支持多用户隔离）await client.add({  content: "用户偏好 TypeScript 和函数式编程",  containerTag: "user_alice_123",});// 检索用户画像 + 相关记忆const { profile, searchResults } = await client.profile({  containerTag: "user_alice_123",  q: "推荐适合的前端框架",});

它还支持通过 MCP 协议快速接入 Claude Desktop、Cursor 等工具，以及 Google Drive、GitHub 等数据连接器。

适合谁用 / 不适合谁用

最适合：构建需要”记住用户”的 AI 产品的开发者，特别是多用户场景（需要用户级别记忆隔离）；想给自己的 AI 应用增加跨会话记忆能力的团队；已经在用 RAG 但发现不够用的开发者。

不适合：只做静态知识库问答（直接用 RAG 反而更简单）；对数据完全自托管要求极严格的企业（核心是 SaaS 服务）；预算非常有限的个人项目。

和 Mem0、Zep 的区别在于：Mem0/Zep 做的是”更好的记忆存储”，Supermemory 做的是”更像人脑的记忆系统”——不只是存，还会主动整理、更新和遗忘。

项目地址：https://github.com/supermemoryai/supermemory

三、论文：SpecEyes——让多模态 Agent 加速 3.35 倍，还更准了

解决了什么问题

OpenAI o3、Gemini Agentic Vision 这类最新的多模态 AI，它们为什么那么强？很大程度上是因为它们可以迭代调用视觉工具：看一眼图片、想一想、再调用 OCR 工具、再想一想、再调用目标检测工具……这个循环可以持续好多轮，每一轮都让推理更准确。

但这个方式有一个严重问题：每一轮都是串行等待，工具链越长，延迟越高。如果同时有很多用户请求，系统的并发能力会被严重拖累——这是当前 Agentic AI 部署面临的最大瓶颈之一。

来自厦门大学 MAC-AutoML 组和罗切斯特大学的研究者，今天在 arXiv 上发表了 SpecEyes（2603.23483），提出了一套系统性的解决方案。

提出了什么方法 / 核心创新点

SpecEyes 的核心思想，可以用”聪明的猜测员”来理解。

你的公司有一个全能顾问（大模型），他的建议很准，但每次咨询都要花很长时间排队。SpecEyes 的解法是：雇一个轻量级的”预测员”，先快速猜一个答案，如果猜得有把握，就直接用这个答案，不用等全能顾问；如果猜得没把握，才去排队找全能顾问确认。

具体实现分三步：

推测规划器：一个轻量级的多模态模型，不调用任何工具，直接预测完整的工具调用链应该给出什么结果。如果它给出的答案置信度够高，就直接用，跳过昂贵的工具链。

认知门控机制：基于”答案可分离性”来量化置信度——简单说就是，如果这个问题有一个非常明显的唯一答案，那置信度就高；如果模型觉得可能是好几个答案，就低。这个机制不需要任何真实标签，完全自验证。

异构并行漏斗：让多个轻量级小模型并发跑，来掩盖大模型串行执行的延迟，最大化系统吞吐量。

实验结果：在 V* Bench、HR-Bench、POPE 三个标准测试集上，SpecEyes 实现了 1.1 至 3.35 倍的加速，同时精度最高还提升了 6.7%——精度不降反升是因为认知门控过滤了大模型”过度思考”产生的噪声。

对工程落地有何指导意义

这篇论文对工程师来说有两个直接的应用价值：

第一，如果你在维护一个有工具调用的 Agentic AI 系统，SpecEyes 的框架可以作为前置层接入，不需要重新训练大模型，就能获得显著的速度提升和成本降低（工具调用次数减少 = API 费用降低）。

第二，认知门控中”答案可分离性”这个概念，可以推广到任何 Tool-Calling 系统的”是否需要调用工具”判断逻辑，是一个值得借鉴的设计范式。

代码已在 GitHub 开源：https://github.com/MAC-AutoML/SpecEyes

论文链接：https://arxiv.org/abs/2603.23483

四、论文：LongCat-Flash-Prover——5600 亿参数模型挑战数学竞赛级定理证明

解决了什么问题

让 AI 写代码、回答问题，大家都见过了。但有一类任务，现有 AI 几乎没法做到：形式化数学证明——不是”给我解释一下勾股定理”，而是”用 Lean4 定理证明器，写出一段可以被机器严格验证的完整证明”。

这件事为什么难？因为它要求模型同时具备三种能力：把人类语言描述的数学问题翻译成形式化语言（自动形式化），规划证明思路（草图生成），以及执行完整的逐步证明（证明生成）。这三个能力都需要极深的逻辑推理，任何一步出错，证明器就会拒绝。

美团 LongCat 团队联合多个研究机构，发布了 LongCat-Flash-Prover（arXiv:2603.21065），一个 5600 亿参数的开源混合专家（MoE）模型，专门攻克这个问题。

提出了什么方法 / 核心创新点

这个模型最值得关注的不是参数量，而是它的训练方法。

HisPO 算法（分层重要性采样策略优化）：这是整篇论文最核心的技术贡献。普通的强化学习算法用在超大规模 MoE 模型上，在长序列任务中会非常不稳定——想象一下你让 560B 参数的模型反复尝试证明同一道数学题，梯度更新可能会让它”忘掉”已经学会的技能。HisPO 通过序列级和 Token 级的梯度掩码，专门解决了这个不稳定性问题。

定理一致性和合法性检测：强化学习中有一个众所周知的问题叫”奖励黑客”——模型可能通过找漏洞、走捷径来获得高分，而不是真正解决问题。在定理证明中，这意味着模型可能生成”看起来对但逻辑有缺陷”的证明。这篇论文引入了专门的一致性检测机制，从根本上杜绝了这类欺骗。

实验结果非常亮眼：在 MiniF2F-Test 上，每道题只用 72 次推理预算就达到了 97.1% 的通过率；在更难的 PutnamBench（普特南数学竞赛级别）上解决了 41.5% 的问题，显著超越已有开源模型。

对工程落地有何指导意义

这篇论文的工程意义主要在两个层面：

短期：如果你在构建需要形式化验证的系统（如代码自动验证、硬件设计验证、安全协议验证），LongCat-Flash-Prover 的方法提供了一套完整的可复现流水线，从数据生成到 RL 训练，都是开放的。

长期：HisPO 算法解决的”大型 MoE 模型在长序列交互任务上的训练不稳定性”，是一个通用问题——不只适用于定理证明，任何需要长程推理和工具交互的 Agent 训练都可以借鉴这个思路。

论文链接：https://arxiv.org/abs/2603.21065

本期新增项目全局解决方案映射表

每日 AI 最前线，深度解读不灌水。如有具体项目想深挖，欢迎留言。