召回 vs 反思：搜索你的 Agent 记忆，还是直接问它

recall vs reflect：搜索你代理的记忆，还是直接问它 2026 年 7 月 24 日 · 7 分钟阅读 · 查看原文 ↗ AI Loops 你的代理用 retain 把内容写入代理记忆。但把它读回来有两种方式，而它们一直被混淆，因为两者都接受一个查询并返回有用的东西。recall 和 reflect 不是同一个东西的两个名字。一个搜索引擎。另一个是分析师。选错了一个，你要么为一次根本不需要的 LLM 调用付费，要么在想要一个答案时得到一堆原始事实。 把它们区分开的最干净方式是一个问题，而这恰好也正是代码描述它们的方式：用 recall 处理"关于 X 我说过什么？"，用 reflect 处理"关于 X 我该做什么？" TL;DR - recall 检索。它找到与查询相关的记忆，并把它们作为一个排序过的事实列表返回。没有 LLM。亚秒级。便宜。 - reflect 推理。它是一个代理，在多个层级上搜索你的记忆，并用一个 LLM 来综合出一个答案。更慢。消耗一次模型调用。 问问你自己：你要的是事实，还是从事实中得出的结论？这就是整个决策。 它们不是对手。reflect 在底层使用 recall 作为它的真相基础。 recall：你记忆的搜索引擎 recall 是纯粹的检索。你交给它一个查询，它返回相关的记忆，排好序。它不做的是思考它们。 在底层，它不只是向量搜索。对每一种事实类型，Hindsight 并行运行几种检索策略：语义向量搜索、BM25 关键词搜索，以及基于关联实体的图谱激活，再加上当查询含时间要素时的一次时间性遍历。它用 Reciprocal Rank Fusion（倒数排名融合）把它们融合，用一个交叉编码器（默认本地）对幸存者重新排序，然后裁到你的 token 预算。结果是一个排序过的事实列表，每个都带有它的类型、时间戳和实体。 在两种操作之间做选择时，最重要的点是：recall 从不调用 LLM。整条管道是嵌入加一个重排器，默认都是本地。这就是为什么它远不到一秒就返回，而且几乎不花成本。它是你可以负担得起的、在每个回合都跑一遍的操作。 两个旋钮塑造它： - budget（low、mid、high）控制搜索的深度，默认大约是 100、300 或 1000 个单位的图谱遍历。更高的预算找到更多，但要多一点工作量。 - max_tokens 限制返回多少。Hindsight 返回事实直到预算被触达，并在溢出之前停下来。 你还能得到查询时过滤器：tags 和 tags_match 用来按标签限定范围，以及一个 query_timestamp 用来锚定"上周"这类相对日期并偏向近期。完整参数列表在 recall API reference 里。 当你想在模型回答之前把相关上下文加载进提示词，或者当你想向用户展示实际存储的事实，就伸手去拿 recall。它回答"关于这个我知道什么？"，并把原始材料交给你。 reflect：一个替你阅读记忆的分析师 reflect 是另一种动物。它不只是检索，它推理。给它一个问题，它就运行一个代理循环：它决定要去找什么，在多个层级上搜索你的记忆，然后一个 LLM 写出一份扎根于它找到内容的综合答案。 它做的检索是分层级的，最好的来源优先： - Mental models（心智模型）：用户策划的、自我刷新的、关于你的代理经常问到的话题的总结。 - Observations（观察）：从许多原始事实中蒸馏出的、有证据支撑的整合知识。 - Raw facts（原始事实）：通过 recall 拉取，作为当更高层级过时时要核对的真相基础。 所以 reflect 不是 recall 的竞争者。它建在 recall 之上。recall 是让 reflect 保持诚实的那一层。 因为循环里有 LLM，reflect 能做 recall 在结构上做不到的事： - 综合。它返回一份写好的答案，而不是一个列表。"关于 X 我该做什么""总结一下这个月我们学到了什么""这个用户的总体偏好是什么"。 - 结构化输出。传入一个 response_schema，它就返回一个符合你 JSON schema 的、经过验证的对象，这样你可以把结论直接喂进代码。 - 引用来源。设置 include_based_on，它就返回一个 based_on 块，指名它实际用到的确切记忆、心智模型和指令。那些引用会针对检索到的东西做验证，所以它无法凭空编造一个来源。 它的旋钮含义也不同。这里的 budget 控制代理能拿到多少次迭代，也就是它在回答前探索得多彻底（high 更深，成本也更高）。max_tokens 只限制最终写好的答案长度，而不是沿途检索的量。 权衡才是重点：reflect 要发起一次或多次模型调用，所以更慢，并且消耗真实的 token。Hindsight 在循环中缓存稳定的提示词前缀来缓解这一点，但一次 reflection 从根本上就比一次查找更贵。你不会在每一次敲键上都跑它。每个选项都记录在 reflect API reference 里。 一张表里的区别 如何实际做选择 决策几乎总是这样：你要的是事实，还是从事实中得出的结论？ 在以下情况用 recall： - 你正在组装要放在模型面前、让它回答之前的上下文。这是常见场景，应该便宜而频繁。 - 你想把原始记忆展示给用户，或把确切的事实喂进确定性逻辑。 - 延迟和成本很重要，而在每个回合的热路径上，它们总是很重要。 在以下情况用 reflect： - 你要的是一个答案，而不是证据。一份总结、一份分析、一条建议、一份简报。 - 你需要通过 response_schema 把输出塑造成代码可用的形状。 - 你要的是横跨整个记忆的、可引用、可验证的推理，而不只是最匹配的那几条事实。 这个调用是偶发的，不是每个回合都来。一份每日摘要、一份入门总结、一个"关于这个账户我们知道什么"的面板。 一个健康的代理两者都用。recall 持续而廉价地为普通回合打底。当你真正需要综合时，reflect 再介入，而且它在介入时靠 recall 保持接地。想要事实就搜索。想要答案就问。 常见问题 recall 会用到 LLM 吗？不会。检索是嵌入加一个交叉编码器重排器，默认都是本地，这就是为什么它远不到一秒就返回，而且几乎不花成本。 reflect 比 recall 慢吗？是的。reflect 运行一个带一次或多次 LLM 调用的代理循环，所以更慢，消耗真实 token。recall 是一次查找。在你需要综合时用 reflect，而不是每个回合都跑。 reflect 能返回结构化输出吗？能。传入一个 response_schema，它就返回一个针对你的 JSON schema 验证过的对象，可以直接喂进代码。 reflect 会引用它的来源吗？会。设置 include_based_on，它就返回它实际用到的确切记忆、心智模型和指令，并针对实际检索到的东西做验证，所以它无法凭空捏造一条引用。 延伸阅读 - Inside retain()：那些事实一开始是如何被写入和整合的。 - One bank or many?：recall 和 reflect 都在其中运作的那条边界。 - Your 1M-token context window is not memory：为什么你检索一小片，而不是把所有东西都粘进去。 标签：# X # AI # Loops # Guide 相关文章 如何打造一家 AI 原生公司：招聘、标准与节奏 *我们花了一年跑黑客马拉松、AI 培训和办公时间。但直到我们把 AI 能力变成一项要求，什么都没改变。* AI Loops Claude Marketing