Funes HOT

Funes是什么？

Funes 是 Hugging Face 开源的 agent 会话记忆库，用 Rust 写的。说白了，它给 agent 补上了「跨会话记忆」这块基础设施。

用过 agent 的人应该都有体会：单次对话里它挺聪明，窗口一关，下次再来就完全不记得你了。上下文窗口再长，撑死的也只是这一次会话。Funes 干的事情就是把过往的会话持久化存下来，而且能检索——让 agent 在多次对话之间记住之前发生过什么。

名字大概取自博尔赫斯那篇《博闻强记的富内斯》，讲一个记忆力强到无法遗忘的人，用在这里挺贴切。

有一点得先说清楚：它是库，不是产品。你没法打开一个网页就开始用，得自己把它集成进现有的 agent 框架或工作流里。这也是它最容易被误解的地方。

核心功能

1. 为过往会话提供持久化记忆存储 把 agent 每次会话的内容落到存储里，而不是随着会话结束就丢掉。这是整个项目的地基。实际使用中，这一步的价值不在于「存」，而在于存下来的东西之后真的能被用上——很多记忆方案的问题就出在只存不取。

2. 对历史会话做可检索查询 存了还得找得到。Funes 支持对历史会话进行检索，为 agent 提供长期上下文。检索质量很大程度上取决于你写入时怎么切分和结构化，这部分得自己设计，不是接上就灵。

3. 跨会话记忆补齐 这是它最核心的卖点。让 agent 在第二次、第十次对话时，仍然带着之前积累的上下文。据了解，很多团队在做 agent 产品时都卡在这一环——单轮体验做得不错，但用户回访后一切归零，产品就很难形成粘性。

4. 基于 Rust 实现 Rust 在性能和内存安全上的优势是天然的，对有高并发、低延迟要求的场景比较友好。如果你的 agent 服务本身就在意这些指标，用 Rust 写的记忆层不会成为拖后腿的那一环。

5. 开源可自托管，可作独立记忆层集成 代码开源，可以私有化部署和二次开发，也能作为一层独立组件嵌进现有技术栈。对数据敏感、不方便把会话历史交给第三方托管的团队，这点比较关键。代价是运维成本得自己扛。

版本/套餐对比

目前官方只开源了代码仓库，没有公开的托管服务和定价信息，所以这里能客观列出的东西不多：

一句话：现阶段它就是一个自托管的开源库，没有商业套餐这回事。团队要上生产，得自己评估部署和长期维护的成本。

值不值得用？

优点：

• Hugging Face 开源维护，来源可靠，社区关注度也还行——GitHub 周榜涨了 67 星（数据来源：GitHub Trending），对一个刚起步的底层库来说不算差。
• Rust 实现，性能和内存安全上有先天优势。
• 直击「agent 跨会话失忆」这个真实痛点，而且定位很清晰，就是做记忆这一层。
• 开源可自托管，适合有私有化需求的场景，也方便按自己的业务改。

缺点：

• 太新了。2026 年 7 月发布首个正式版 v1.0.0，生态和周边工具都还在完善中，文档、示例、社区问答这些短期内别指望很丰富。
• 是底层记忆库，不是开箱即用的成品。开发者得自己集成、自己部署，没有现成界面给你点。
• 没有公开的托管服务和定价，团队用起来要自己算运维这笔账。

总体结论： 如果你正在做 agent，并且确实被跨会话记忆这个问题卡住了，那这个项目值得花半小时翻一下仓库，看看它的设计思路和接口是不是合你的路子。但如果你想要的是「装上就能用」的记忆功能，它现在还不是那个答案。它是块砖，不是套房。

使用建议

• 先想清楚要记什么。 是存原始对话、存摘要，还是存结构化的事实？这三种的存储成本和检索效果差别很大，别一上来就全量存原始文本。
• 检索策略比存储更重要。 记忆层的实际体验取决于「能不能在对的时候取到对的东西」，写入时的切分方式、检索时的召回策略，这些都得针对自己的场景调。
• 注意隐私与访问控制。 会话历史里往往会有敏感信息，自托管时存储加密、权限隔离这些要提前规划，别等出问题再补。
• 别一次性全量接入。 项目还年轻，先在一个非核心链路或者内部工具上跑一跑，摸清它的稳定性和接口风格，再考虑往主线推。
• 当记忆层用，别当替代品。 它不负责规划、不负责工具调用，只是把记忆这块单独拆出来。跟你现有的 agent 框架是配合关系。
• 关注仓库动态。 早期项目 API 变动是常事，接入前最好确认一下最近的提交和 issue 情况。

适合谁用？

推荐：

• 正在自建 agent 记忆层、又不想从零造轮子的开发团队。
• 有私有化部署要求、数据不能出内网的场景。
• 对性能敏感、技术栈本身偏系统级语言的工程团队。

可考虑：

• 已经有一套记忆方案，想横向对比一下设计思路的。
• 想研究 agent 记忆架构怎么落地的开发者，读代码本身就有收获。
• 有开发资源、但还没确定要不要长期投入的小团队，可以先做原型验证。

不推荐：

• 想找一个开箱即用记忆 App 的普通用户，这个方向完全不对。
• 没有开发人力、指望买来就能上生产的小团队。
• 需要成熟商业支持、SLA 和现成托管服务的场景——现阶段它给不了这些。

版本记录

以下按时间倒序收录历次版本更新的完整说明（页面顶部简介只保留最新一版要点）。

最新版 v1.9.1（2026-10-20，GitHub 标记 Latest）：官方明确这是小维护版，只有内部清理与轻度重构，无新增功能、无破坏性变更。小改动——recall 未命中时在回复末尾给出可尝试的做法；recall 新增 --repo 参数。修复——funes add 把 refresh 暂存到它自己的 setup 即将运行时；funes bind 给没有本地记忆的主机套用被绑定记忆的模型；funes bind 在 setups 运行前先忘掉旧的 notes；recall 改为流式折叠会话，不再逐批收集全部结果。

前一版 v1.9.0（2026-10-14，GitHub 标记 Latest）：新增 GPU 索引与主机绑定——在 macOS 15 及以上，funes index 通过 Metal 在 GPU 上嵌入（无 GPU 时回落 CPU，recall 查询仍在 CPU）；funes bind 把本机绑定到一条记忆（所有已安装 agent 都从它召回并向它发布，funes bind local 解绑；funes add 会先绑定主机，不带记忆名的 funes add 装到主机记忆上）；不带记忆名的读取（CLI 或工具调用）读绑定记忆加上本机未推送的轮次，带记忆名的读取按记忆原样读取。从 1.8.x 升级无需重建索引：funes update 会把主机绑定到各 agent 原先绑定的记忆（若它们本就在同一条上），否则列出它们并由 funes bind 选定。另含在 macOS 上跑 CI、Hub 请求带上 funes 版本、安装脚本加 user-agent、会话按最后索引轮次的时间戳关闭行等。

前一版 v1.8.0（2026-10-08）：新增多语言嵌入模型（multilingual embedder）——首次 funes add 会询问你的会话是英文还是多语言（当 LC_ALL、LC_MESSAGES、LANG 之一不是英文时默认多语言；非终端环境下直接采用该默认值而不询问）；funes index --multilingual 可在尚未索引任何内容前手工建立多语言本地记忆；每条记忆会记住它创建时所用的模型，之后所有命令都跟随它——recall 用所检索记忆的模型嵌入查询，index / scrub / push 从不在同一条记忆里混用两个模型；当 funes add 绑定的记忆已有模型时，本地记忆直接采用它而不再询问；若某条记忆用的是与本地记忆不同的模型，funes add 会在安装任何东西之前拒绝它。从 1.7.x 升级无需重建索引：既有记忆都用英文模型建立并保持该模型，共享记忆只持有一个模型，绑定它的每台主机都用该模型嵌入。

前一版 v1.7.0（2026-10-07，GitHub 标记 Latest）：记忆会自我压缩（compaction）——每次写入都会给记忆追加碎片，逐轮写出的记忆会累积上千个碎片，recall 随之变慢、远程记忆还会逼近 Hub 单目录 1 万文件的上限；funes 现在会压缩记忆：合并小碎片、把它们的行加入搜索索引、删除旧版本。funes index 在每次写入运行的末尾压缩本地记忆并删除十分钟前的版本，已索引的小碎片超过 256 个时整体重写；funes push 在远程有 500 行未索引时压缩远程并删除所有旧版本（真实 Hub 记忆首次压缩从 1,111 个 manifest 降到 2 个、从 1,534 个数据文件降到 293 个）；funes compact [memory] 可对本地记忆、本地路径或远程记忆（需写权限）按需执行同样的步骤，funes push --compact 强制压缩（旧名 --force-reindex 仍可用）。另新增 funes recall --role 与 MCP 的 role 参数，把检索限制到单一角色（如 Claude 会话里工具输出落在 user 轮，用户自己的话用 --role user --type text）；写锁移入记忆内部（/store.lock），同一记忆的写入者无论从哪个 funes home 运行都会互斥。从 1.6.x 升级无需重建索引：用 funes update 更新（1.6 从 funes home 锁记忆，若其索引运行仍在进行，更新会等它结束）；升级后首次索引（钩子或手动）在逐轮增长的记忆上可能更久，因为首次压缩会重写每个碎片，远程记忆则在下次 push 超过 500 行未索引时压缩，要立即执行可运行 funes compact /（超过 10 GB 的远程先用 hf download 拉到缓存再压缩）。

前一版 v1.6.0（2026-10-02，GitHub 标记 Latest）：recall 只在候选池至少为 -k 的四倍时才重排（--candidates ≥ 4k），否则直接返回融合顺序——默认参数（8 / 30）下不再加载重排器，一次 recall 只需不到一秒，而此前每次调用都要重排、每进程加载 1.1 GB 权重；funes ask 遵循同一规则。移除时效半衰期：recall 不再按命中时间加权（基准测试显示 30 天半衰期对每条臂都是净成本），排序只看相关性，要最新内容请用 --since/--until 限定范围（CLI 与 MCP 工具均支持）。破坏性变更：--half-life 已移除，MCP 的 half_life 参数被忽略。另新增 migrate_schema，可把 project→workdir 改名之前的记忆就地升级到当前 schema；bench_recall 默认改用 huggingface/funes-memory，bench_index 退役。从 1.5.x 升级无需重建索引，脚本里删掉 --half-life 即可；--candidates 32 或以上可恢复默认 recall 此前的重排行为。

前一版 v1.5.0（2026-10-01，GitHub 标记 Latest）引入浅层索引（shallow indexing）：funes index 先写入 chunk 行、嵌入向量随后补齐，大 spool 由整轮嵌入完成后才可检索变为几分钟内即可按词检索（语义搜索随后续运行或 per-turn hook 追平）；funes status 区分「待嵌入 chunk」与「未索引会话」两类工作；只有已嵌入 chunk 才会发布——funes push 暂扣未嵌入部分、向量补齐后随下次 push 带出，远程记忆不会出现没有向量的行；recall 修复绑定远程记忆后读不到本机刚索引轮次的问题（现在合并远程记忆与本机未推送的本地轮次）；funes update 现在会把已安装集成同步到其源码最新并重跑 setup（--from 安装的保持原样）；bge-reranker-base 加载峰值内存 2.07 GiB 降至 1.04 GiB（#188）；破坏性变更：funes status 用法改为 funes status；升级：从 1.4.x 升级无需重建索引，Hub 上已有内容不变。

前一版 v1.4.0（2026-09-26）把集成移出主程序：funes add 改为从目录安装集成，官方维护的 claude/codex/hermes/pi 四个集成独立存放于 funes-integrations 仓库并按各自节奏发布，社区集成可从目录或发布归档安装；对非官方发布的集成运行前先确认，记录安装内容与来源，并在每次 funes add 时把目录集成升到最新版。索引批量扫描让 funes index 与 --check 在大量文件时明显更快；修复 lance 向量索引构建时塞满 $TMPDIR 的问题；funes mcp 改为协商客户端请求的协议版本。升级注意：装完 1.4.0 需对每个已添加的 agent 重新执行 funes add 完成替换，否则旧钩子停止捕获。

上一版 v1.3.3（2026-09-24）聚焦 BLAS 推理性能优化。更早的 v1.3.2（2026-09-20）引入通用索引契约：在既有 indexable source 之外，可直接解析标准化 JSONL turns 会话文件建立索引，后续索引代码将逐步从主程序外移为各来源/harness 的专用插件。