Hugging Face 推出 funes：让编程代理记住过去，但把记忆交还给用户

Hugging Face 发布开源工具 funes，为编程代理提供本地优先的记忆层，把代理会话日志转为可检索的记忆并可选发布为用户拥有的 Hugging Face 数据集，保留原始证据并支持跨代理、跨设备的接力与查询。funes 以单一二进制发布，结合向量搜索与 BM25、交叉编码器重排，并提供 recall 和 ask 两类接口，强调本地处理与数据所有权，同时提醒共享记忆需谨慎处理敏感信息。

Hugging Face 员工 David Corvoysier 于 2026 年 9 月 3 日发布开源工具 funes，试图解决编程代理在跨会话、跨设备和跨工具工作时“每次都从零开始”的问题。该工具会把 Claude Code、Codex、pi 和 Hermes 等代理已经生成的会话记录，整理为可检索的本地记忆；用户也可以选择将这份记忆发布为自己拥有的 Hugging Face 数据集，供另一台机器或另一名代理继续使用。

这不是一个要求开发者更换模型的新代理产品，而是一层附加在现有代理之上的记忆基础设施。Hugging Face 在 官方文章 中将其概括为：代理已经产生了记忆所需的原始材料，问题在于这些材料通常只是存放在个人电脑上的 JSONL 会话日志，缺少索引、检索、排序和可追溯性。

从会话日志到可检索记忆

编程代理在查找代码、尝试方案、遇到错误和阅读文档的过程中，往往会留下比提交信息更完整的工作记录。提交信息可以说明改动是什么，却未必能回答“为什么放弃了原来的流式解析器”这类问题。

funes 的做法不是在写入时把每段会话压缩成一条事实，而是将不同代理的记录解析成统一的“回合—区块”结构，再进行切分、嵌入和索引。根据 Hugging Face 的说明，它在查询时结合向量搜索与 BM25 搜索，融合结果后再用交叉编码器重排，并按照新近程度调整结果，同时附带相邻内容。

这种设计的一个重点是保留原始证据。recall 返回的是原始文本而非单独生成的摘要，并会标出来源代理、时间戳、会话和回合；每条结果还带有 get 命令，方便用户打开完整回合及其上下文。理论上，这使代理能够在引用过去决定时回到产生该决定的原始记录，而不是只依赖一份可能已经失真的总结。

一条命令接入现有代理

funes 以单一二进制文件发布。安装命令为：

curl -fsSL https://huggingface.co/buckets/huggingface/funes/resolve/install.sh | sh

随后，用户可以运行：

funes add claude
# 或：codex、pi、hermes

按照项目说明，add 命令会建立初始索引，为代理提供 recall 和 get 工具，并为 Claude Code、Codex 和 Hermes 安装在每轮完成后更新索引的自动化机制。索引采用增量方式，新会话只加入新增回合；较早的历史记录则可以分批回填，而不必每次重新处理整个历史。

这意味着记忆层不必替代原有的编码代理。代理仍然负责理解问题、调用工具和作出判断，funes 主要负责把过去的工作记录找回来。Hugging Face 也强调，默认情况下嵌入和重排都在本机完成，不需要额外的机器学习运行时，推理模型本身也不会通过托管服务处理用户的会话。

这一点与企业软件中常见的集中式记忆服务不同。类似的长期记忆方案也可以通过数据库和向量搜索实现，例如微软曾展示过用 Cosmos DB 为 eve 代理添加语义记忆的做法；funes 则把重点放在本地优先、跨代理和保留原始会话证据上。

“记忆是数据集”，而不是另一个账号

当用户需要在不同机器之间共享记忆时，可以在接入代理时绑定一个 Hugging Face 数据集：

funes add codex acme/funes-memory

在这一模式下，本地记忆仍然是 Lance 数据集，共享版本则是用户拥有的 Hugging Face 数据集，默认保持私有。funes 会在本地索引每轮新会话，并在会话边界发布更新；另一台机器运行同样的绑定命令后，就可以继续读取这份记忆。

Hugging Face 表示，发布前会在索引阶段对凭据进行脱敏，发布时还会再次扫描区块，拦截仍然看起来像秘密的信息。项目的 GitHub 仓库 同时提醒，安全扫描有覆盖范围限制，不能把自动检测当成泄露风险已经消失。因此，是否发布包含源代码、内部决策或敏感项的会话，仍然需要用户自行判断。

这种“把记忆当作数据集”的安排，也让记忆拥有了数据集的访问控制、版本管理和分发方式。它可以被个人跨设备使用，也可以服务于团队协作，甚至让开源项目维护者发布与某次版本发布相关的工作过程。不过，公开记忆会让原本属于开发环境的推理路径、失败尝试和项目背景暴露给任何能够访问数据集的人。

从 recall 到 ask：代理使用和人工查询分开

funes 为两种场景提供了不同入口。代理在正常工作过程中使用 recall，由它自行决定何时检索过去的会话；用户如果只是想向记忆提一个问题，则可以使用 ask：

funes ask claude "what did we decide about the streaming parser"

也可以直接查询公开的共享记忆：

funes ask claude "why is funes append-only" --memory huggingface/funes-memory

Hugging Face 将 ask 描述为只读、单问题的入口。它会检索相关段落，将这些段落交给编码代理，并返回带来源的回答；如果检索到的材料不足以支持答案，代理应当明确表示无法确认，而不是用一般性回答填补空白。

这类设计试图把“记忆”和“推理”分开：funes 负责提供证据，代理负责解释证据。对于开发工作而言，这种边界有助于减少一份过度概括的长期摘要在多个项目和多台机器之间不断传播。

跨代理连续性仍有实际边界

funes 的目标不仅是让同一代理跨会话记住过去，也包括让不同代理接力完成工作。例如，开发者可以先在 Claude Code 中作出架构决定，几天后在 Codex 中继续任务，再由后者从同一份记忆中找回前一个代理的理由。项目也支持在本地模型或其他服务支持的模型之间切换，而不把记忆绑定到某个推理模型。

但“能检索到”并不等于“必然理解正确”。会话记录可能包含试错、过时信息、错误假设和不同阶段的相互矛盾决定。funes 通过来源、邻近上下文和原文回溯降低了误读风险，却没有消除代理对检索结果进行判断的需要。用户仍应确认命中的决定是否已经被后续提交、文档或团队讨论推翻。

Hugging Face 文章还介绍了一项 handoff-vs-recall benchmark。按其公布的结果，在两个依赖既有会话知识的任务中，recall 的成本分别约为书面交接的八分之一和四分之一；压缩方案在其中一个任务上没有成功复原结果。这个数字是项目方自己的实验结果，测试范围有限，不能直接推导出所有代码库、代理或团队都会获得相同收益。

编程代理竞争开始延伸到上下文层

过去，编程代理的竞争主要围绕模型能力、工具调用、上下文窗口和执行权限展开。funes 关注的则是另一个越来越明显的瓶颈：代理做过的工作很多，但这些工作无法被下一次任务有效利用。

这也是 Hugging Face 此前发布 “Software Forgets: Agent Traces Are the Memory” 一文所提出的问题。那篇文章认为，代理会话已经是记录软件决策过程最密集的材料，只是缺少一个稳定的存放位置。funes 现在把这个判断落实为一个本地工具，并将 Hugging Face 数据集作为可选的共享层。

对个人开发者而言，最直接的价值可能是减少重新解释背景和重复排查的时间；对团队而言，价值则取决于是否愿意把代理会话纳入项目知识管理，并建立明确的隐私、权限和删除规则。对于拥有多个代理、多个工作目录或多个开发环境的用户，跨工具的统一记忆可能比单个代理增加一个更大的上下文窗口更有实际意义。

然而，funes 是否能成为普遍的编码基础设施，还要看它在更大规模会话、更多代理格式和真实团队协作中的稳定性。它目前解决的是“记录找不到”的问题，至于哪些记录值得长期保留、哪些决定已经失效，以及代理应当在多大程度上信任过去的自己，仍然是需要持续验证的工程和治理问题。