Agent 查记忆，为什么不该调大模型？

多数人给 Agent 加记忆的第一反应是：把原文存进向量库，查的时候捞出来，再让大模型读一遍、判断哪句有用。能用，但每查一次就付一次模型的钱，而且它分不清这句话是谁说的、什么时候说的，「上周」存进去，半年后查出来还是「上周」。

Hindsight 反过来做：贵的活全放在写入那一刻，查的时候一分模型钱都不花。我们在一台没有 GPU 的机器上把它跑了一遍，检索 0.06 秒返回，Reflect 要 70 秒。两个数差了一千多倍，这个差距不是缺陷，正是它的设计。

![Hindsight 设计拆解主图](https://developer.qcloudimg.com/http-save/yehe-12798805/f927d0cc1591f591d2ba0eb7578e90a2.png)
*[实测] 主图：两个数字分别是本文实测的 recall 接口耗时和一次 Reflect 的耗时*

Hindsight 是 vectorize-io 开源的 Agent 记忆层，MIT 协议，Python 写的，截至 2026-10-03 07:50（北京时间）有 44689 个 Star、5869 个 Fork，最新版本是 9 月 29 日发布的 v0.10.2。下面一层层拆。

## 贵的活放在写入时

先看两种做法的账怎么算。

![两种记忆做法的成本分布](https://developer.qcloudimg.com/http-save/yehe-12798805/f575c0e4b38e24afe6155d6af637eec4.png)
*[框架示意] 同样是记住一句话、以后查出来：常见做法每次查询都要大模型参与，Hindsight 把大模型集中在写入和后台归并，检索不调模型*

Hindsight 的 API 只有三个核心操作：

- **retain（写入）**：调大模型从文本里抽事实、实体和时间，在事实之间建语义、时间、实体链接；后台再把多条事实归并成「观察」。
- **recall（检索）**：语义向量、BM25 关键词、关系图、时间四路并行，融合排序，不调大模型。
- **reflect（反思）**：一个带工具调用的 Agent 循环，基于记忆推理出回答。

Agent 记忆是典型的读多写少：一句偏好写进去一次，后面几百次对话都要查。把成本压在写这一头，账就算对了。这是整个项目最值得抄的一个决定。

## 写入一刻发生了什么：5 条事实、9 条观察

我们写了两条演示用的编辑部纪要：一位叫小林的编辑负责开源栏目，喜欢先在沙箱里跑通再写稿、不喜欢只翻译 README；截图统一用 1440×900；团队主要用 Postgres，不想额外维护向量库；还有一条下周的选题安排。这里交代一句口径：下文所有抽出的事实、观察和 Reflect 的回答，都是经第三方中转调用的 gpt-6.1-sol 生成的，不是项目默认模型，Hindsight 本身不绑定模型。

retain 用了 19 秒，从两段话里抽出 5 条事实，并建了 46 条链接：语义 25 条、时间 20 条、实体 1 条。紧接着后台归并任务又跑了 30 秒，生成 9 条观察。

![记忆库首页](https://developer.qcloudimg.com/http-save/yehe-12798805/dc845d8e50833256df96f2b8c3aa5700.png)
*[实测] 记忆库概览：14 条记忆（5 条事实加 9 条观察）、46 条链接，左上是记忆星座图（抽取与归并由经第三方中转调用的 gpt-6.1-sol 完成，写入的纪要是演示文本）*

观察是比事实高一层的认识，比如「团队主要使用 Postgres」「团队不希望为了一个记忆服务额外维护向量数据库」，每条都挂着实体、标签和来源事实。

![观察列表](https://developer.qcloudimg.com/http-save/yehe-12798805/a165e5756403ba25dc4fbc53bf72ae71.png)
*[实测] 9 条观察：后台归并任务从事实中提炼出的高层认识（由经第三方中转调用的 gpt-6.1-sol 生成）*

最见功力的是时间处理。纪要里写的是「上周那篇」，存进去的事实里已经换算成了「2026 年 9 月 21 日至 9 月 27 日」。抽取模块的文件头说得清楚，它要同时抽事实、实体和时间（`hindsight-api-slim/hindsight_api/engine/retain/fact_extraction.py:1-6`）。相对时间在写入时落成绝对日期，以后按时间检索才靠得住，这件事放到查询时再做就晚了，那时候已经不知道「上周」是哪周。

19 秒加 30 秒，听着慢，但这是一次性的。用户说完一句话，Agent 后台写进去就行，没人在等它。

## 不靠大模型，检索凭什么够准

在控制台的 Recall 页输入「小林写开源稿件有什么要求？」，接口 0.06 秒返回 5 条结果（控制台显示 0.05 秒）。第一条正是「先在沙箱里跑通再写稿；不喜欢只翻译 README」，第二条是截图尺寸。

![召回结果](https://developer.qcloudimg.com/http-save/yehe-12798805/545ffef9717b8992d79f25bc8ead28fe.png)
*[实测] Recall：一句自然语言提问，0.06 秒返回 5 条按相关度排序的事实；检索本身走本地 ONNX 向量和 RRF 融合，不调大模型（事实内容由经第三方中转调用的 gpt-6.1-sol 抽取）*

准，靠的是两件事。

第一，**存进去的东西已经干净了**。检索的对象不是原文碎片，而是写入时整理好的一条条事实，每条只说一件事、带着人物和日期。查询本身就简单了。

第二，**四路互补，再用排名融合**。语义向量管「意思相近」，BM25 管「关键词命中」，关系图管「和谁有关」，时间管「什么时候」（`engine/search/__init__.py:1-8`）。四路结果不比分数，只比排名：

```python
# hindsight-api-slim/hindsight_api/engine/search/fusion.py:29-56（节选）
def reciprocal_rank_fusion(result_lists: list[list[RetrievalResult]], k: int = 60) -> list[MergedCandidate]:
    """
    Merge multiple ranked result lists using Reciprocal Rank Fusion.

    RRF formula: score(d) = sum_over_lists(1 / (k + rank(d)))
    ...
    source_names = ["semantic", "bm25", "graph", "temporal"]
```

倒数排名融合（RRF）的好处是不用调权重：四路的分数尺度完全不同，它只看每条结果在各路里排第几，在多路都靠前的自然胜出。整个过程是数据库查询加一次本地向量计算，所以是毫秒级。

向量用的也不是云端接口，默认就是本地小模型：

```python
# hindsight-api-slim/hindsight_api/config.py:1211-1215
DEFAULT_EMBEDDINGS_PROVIDER = "local"
DEFAULT_EMBEDDINGS_LOCAL_MODEL = "BAAI/bge-small-en-v1.5"
DEFAULT_EMBEDDINGS_LOCAL_FORCE_CPU = False  # Force CPU mode for local embeddings
DEFAULT_EMBEDDINGS_LOCAL_TRUST_REMOTE_CODE = False  # Security: disabled by default, required for some models
DEFAULT_EMBEDDINGS_ONNX_MODEL_ID = "intfloat/multilingual-e5-small"
```

我们启动时日志显示，嵌入跑的是 `intfloat/multilingual-e5-small`，384 维，在 `CPUExecutionProvider` 上；重排用 RRF，不跑神经网络。全程没用 GPU。

![API 启动日志](https://developer.qcloudimg.com/http-save/yehe-12798805/6c62b4cf4873ef2dddcb676df769631b.png)
*[实测] API 启动：嵌入走本地 ONNX（multilingual-e5-small，CPUExecutionProvider），重排用 RRF，连通性校验通过（模型为经第三方中转调用的 gpt-6.1-sol）*

## Reflect 慢，但用在对的地方

检索只负责把相关事实找出来。要综合判断，比如「给小林写 Hindsight 稿件时要注意什么」，就轮到 Reflect。它跑了 2 轮、1 次工具调用、3 次大模型调用，约 70 秒，把几条记忆串成了一段建议：先实际跑通再写，截图用 1440×900，命令和退出码以运行日志为准，技术选型考虑团队已有的 Postgres。

![Reflect 回答](https://developer.qcloudimg.com/http-save/yehe-12798805/59c7329c5618fb90270f0670896b1c0f.png)
*[实测] Reflect：基于记忆库回答「给小林写 Hindsight 稿件时要注意什么？」，2 轮、1 次工具调用、3 次大模型调用，约 70 秒（回答由经第三方中转调用的 gpt-6.1-sol 生成）*

它的检索是分层的：

```python
# hindsight-api-slim/hindsight_api/engine/reflect/agent.py:1-8
"""
Reflect agent - agentic loop for reflection with native tool calling.

Uses hierarchical retrieval:
1. search_mental_models - User-curated summaries (highest quality)
2. search_observations - Consolidated knowledge with freshness
3. recall - Raw facts as ground truth
"""
```

先查人工整理的知识页，再查归并后的观察，最后用原始事实兜底，默认最多 10 轮（`agent.py:149`）。这和写入时的分层是对上的：写入时做好的观察，在 Reflect 里成了第二层检索的原料，前面花的钱在这里又用了一次。

70 秒放在聊天框里不可接受，放在后台任务里完全没问题：每晚给 Agent 生成一份「这个用户该注意什么」，或者写稿前先出一份要点。面向用户的实时路径交给 recall，需要想一想的交给 Reflect，项目把这两条路分得很清楚。

控制台里每次调用的账都记着，我们把这次各步的耗时画成一张图：

![每个操作的耗时与模型调用](https://developer.qcloudimg.com/http-save/yehe-12798805/51073d4b23d4b377059880dd1f375628.png)
*[实测] 每个操作的耗时和是否调用大模型：retain、归并、reflect 取自控制台 LLM 调用记录，recall 为接口实测耗时（模型为经第三方中转调用的 gpt-6.1-sol）*

![LLM 调用记录](https://developer.qcloudimg.com/http-save/yehe-12798805/a090386fd831fff8f08c250a5bde117b.png)
*[实测] 控制台的 LLM 调用记录原图：这个记忆库共 9 次成功调用，每次的 Token 和耗时都列出；输入 Token 含中转站每次约 4200 的附加计费，直连会更低（模型为经第三方中转调用的 gpt-6.1-sol）*

## 一个 Postgres 加一个 Key 就能跑

设计上省钱，部署上也省事。存储只要一个 PostgreSQL 加 pgvector 扩展，事实、链接、向量、全文索引都在一个库里，我们用的是 `pgvector/pgvector:pg17` 镜像。

服务装的是精简版 `hindsight-api-slim`，选 `local-onnx` 扩展，不装 PyTorch。`uv` 解析出 231 个包，12 秒装完。

![源码构建](https://developer.qcloudimg.com/http-save/yehe-12798805/12b05d0e7d812bed2ac2211d94d50d8f.png)
*[实测] 源码安装 hindsight-api-slim（带 local-onnx 扩展），退出码 0，12 秒*

大模型只认四个环境变量，默认 provider 是 `openai`，任何兼容接口都能接：

```python
# hindsight-api-slim/hindsight_api/config.py:159-162
ENV_LLM_PROVIDER = "HINDSIGHT_API_LLM_PROVIDER"
ENV_LLM_API_KEY = "HINDSIGHT_API_LLM_API_KEY"
ENV_LLM_MODEL = "HINDSIGHT_API_LLM_MODEL"
ENV_LLM_BASE_URL = "HINDSIGHT_API_LLM_BASE_URL"
```

我们把 `BASE_URL` 指向中转站、`MODEL` 填 `gpt-6.1-sol`，没改一行源码。嵌入和重排都在本地，不需要第二个 Key。接入方面，`hindsight-clients/` 下有 Python、TypeScript、Go、Rust 四种客户端，`hindsight-integrations/` 下列了 56 个框架的接入，也能当 MCP 工具用。

![Hindsight 运行架构](https://developer.qcloudimg.com/http-save/yehe-12798805/d0080ef41f270de15013a19c1c3a0798.png)
*[源码推导] Hindsight 运行架构：retain、recall、reflect 三条路径，大模型与本地 CPU 嵌入，PostgreSQL + pgvector 与控制台，节点职责根据 config.py、engine/retain、engine/search、engine/reflect 整理*

## 谁该现在用，谁再等等

**适合现在就用：**

- 在做 Agent 产品、需要跨会话记住用户偏好和团队约定的开发者。retain 加 recall 就够，检索不花钱。
- 团队已经在用 Postgres 的。不用另起一套向量库，加个 pgvector 扩展就行。
- 想要基于历史做综合建议、能接受后台异步的。Reflect 放进定时任务里跑。

**再等等，或者不适合：**

- 要求每次回答都实时综合推理的场景。Reflect 是分钟级的，单次模型调用默认超时 30 秒（`config.py:1197`），这类需求先别用 Reflect，用 recall 拼上下文更合适。
- 只想在一次对话里记住前几轮内容。模型的上下文窗口就够了，用不上一个记忆层。

使用前提一句话：需要一个大模型 Key 来抽事实和 Reflect；不配也能跑，provider 设成 `none` 后只存原文块、能检索（`config.py:4068-4075`）。MIT 协议，可以商用。

---

## 结语

![RuoyiOffice 企业管理一体化平台](https://developer.qcloudimg.com/http-save/yehe-12798805/55a6e2cd4b3bffda41f3747c59fda9f3.png)

RuoyiOffice 是一套面向中小企业的企业管理一体化平台，思路是「一个平台管好整个企业」：不用再分别采购 OA、人事、客户管理、进销存好几套系统，数据在一个平台里打通。


多数人给 Agent 加记忆的第一反应是：把原文存进向量库，查的时候捞出来，再让大模型读一遍、判断哪句有用。能用，但每查一次就付一次模型的钱，而且它分不清这句话是谁说的、什么时候说的，「上周」存进去，半年后查出来还是「上周」。

检索 0.06 秒，反思 70 秒：Hindsight 把记忆的成本挪到了写入时

拆解 vectorize-io 开源的 Agent 记忆层 Hindsight：写入时抽事实、归并观察，检索四路并行不调模型，Reflect 分层推理。附 CPU 部署实测的各步耗时。

架构设计

向量数据库

代码解释

PostgreSQL

TypeScript 

数据库

Python

Agent

2026上云采购 | AI焕新·智启新局

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

检索 0.06 秒，反思 70 秒：Hindsight 把记忆的成本挪到了写入时-腾讯云开发者社区-腾讯云

检索 0.06 秒，反思 70 秒：Hindsight 把记忆的成本挪到了写入时

检索 0.06 秒，反思 70 秒：Hindsight 把记忆的成本挪到了写入时

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐