为什么 AI 编程助手会重复固定错误：谁来接收结果？

一个固定的错误会卷土重来，因为承载它的那条记忆仍在被检索。把更正写下来，本身并不能阻止这件事：旧条目还留在存储里，仍然有资格被取用，下一次会话开始时，它又会出现在模型面前，紧挨着你的更正，两者之间没有任何东西把它们分开。存下一个错误，和从错误中学习，是两回事。存储意味着这个错误还能被再次读到。学习意味着系统接下来的行为因为那次结果不好而有所不同。在这份抱怨底下，有一个机械性的问题，可以拿去问这个类别里的每一款产品，包括我们的：当结果不好的时候，有什么东西改变了吗？ 不是当你写下新东西的时候。是当某件事失败的时候。

披露，而且在这一页上，它应该放在论证之前，而不是之后。我们做的是 Mnemoverse，一个面向 AI agent 的记忆层，所以这是一家厂商在拿自己和五个竞争对手作比较，而在这个特定问题上，我们胜出——这恰恰是你现在就该被告知、而不是在页脚里才看到的原因。我们发布了一个用于结果的输入，有文档，取值是从负一到正一的浮点数。我们自己那篇关于这个输入的公开文章报告说，在我们测量的流量里，它几乎从未被调用过，而这一页就到此为止。下面每一段引文都是你可以打开的页面里的一段连续子串，每一条查询都印了出来，你可以自己跑，而我们表现最差的那一节放在最后。

这一页源自 2026 年 9 月 8 日跑的一次扫描，它把同一个问题问给了同样的六个系统。它在那次扫描的基础上有两处挖得更深，有一处走得更远，这三处都在它们落地的位置做了标记。那次扫描在每个营销主机上找厂商的 changelog，并且只读了每棵文档树里的一页，结果这两点都太窄了。

这一页没有任何性能数字，我们的也好，别人的也好。数字是配方的产物，这一页没有展示配方，而没有配方的数字不是你能核对的东西。

这是视频《如何防止我的 AI 编程助手在不同会话中重复犯同样的错误？》的文字版。视频分七个章节，向同样的六个系统提出了同一个问题。以下章节在视频未能深入之处做了展开，其中出现的每一条引文和查询，都与视频中朗读的完全一致。

TL;DR

• 存下一个错误，和从它身上学到东西，是两回事。 市面上几乎所有打着 agent memory 旗号的东西，第一件事都做得不错。第二件事需要一份事后报告，说明回来的那个东西是错的。
• 另外五个系统里有四个公开了一种输入，可以给出明确的否定判定。 Cognee、Mem0、Letta 和 Supermemory，各自于 2026 年 9 月 10 日在其官方文档站点上查阅。在所查阅的界面上，只有 Zep 没有公开。
• 它们把这个输入挂到什么东西上，才是分歧所在。 一次召回的回答、一条记忆结果、一个执行步骤，或者引擎对某个事实做出的猜测。这是四种不同的对象，其中只有两种才是本文这个问题所问的东西。
• 更少有人公开这个输入会改变什么。 Cognee 说反馈会影响未来的检索，并点名了应用它的那个调用。Supermemory 说未经审核的猜测在搜索中会被降权。Mem0 的页面说的是它的 endpoint 接受什么，而不是排序上会有什么变化。Letta 的页面则对检索顺序只字未提。
• 表示否定方向的那个词的完整拼写，在五家厂商的代码组织里都返回零个文件，2026 年 9 月 10 日重新跑过，并带了一个在每一家都能返回文件的对照组，查询语句附在下面。
• 带连字符的拼写不是零，本页在你找到它之前就先说了。 Supermemory 在其审核文档里公开了 down-weight，Cognee 在一份指南里公开了它，而后者是一句关于他们搜索不做什么的话。
• 我们这一行：输入有文档，引擎是闭源的，信号在设计上就是自愿的。 你能读到 endpoint、取值范围和描述。你没法看它跑起来。
• 本页与 9 月 8 日那轮扫描不一致的地方，都在正文里标了出来。 那轮扫描的两条有边界的结论，对它读过的界面成立，对下面这些页面不成立；还有一条从中得出的结论超出了证据。三处都在它们落地的地方点了名。

披露，而且放在论证之前

本页讨论的六个系统中，有一个是我们自己做的。Mnemoverse 是面向 agent 的托管记忆层，而在这篇文章所追问的问题上，我们持有强烈立场——这反而比立场微弱更糟，因为它更让人有理由不信任我们。

所以，先把我们的立场连同它的边界一起摆出来。我们的 API 文档在参数表里记录了这个整篇文章所讨论的字段，而关键在于取值范围：“Outcome signal: -1.0 (failure) to +1.0 (success)”。同一页也写明了这个调用的用途：“Report outcome (success/failure) for memories.” 我们的机器可读索引对读取它的 agent 说的是同一件事，并补充了它会改变什么：上报结果“when a recalled memory was useful (+1) or wrong (-1)”，然后是三个词——“This tunes future recall.”

而这里正是我们失分的地方。 我们的引擎是闭源的。mnemoverse-core 不在我们的公开仓库之列，所以端点、取值范围和描述都可读，而真正能判定这一切是否奏效的东西不可读。端点需要账号和密钥，因此这里的“公开”指的是公开文档，而不是对任何人开放。这一页的结尾，是我们对自己做的一次测量：信号存在，但几乎从不被发送。

还有一件事，因为你在接触我们这边任何其他东西之前就会先碰到它。我们公开的 memory-server 仓库首页描述里，仍在宣传两条我们自己的 changelog 已经撤回的行为。两天前我们在本站点出了这件事，见 Cursor Memory Bank: what actually loads，而你现在读这段话的时候，它还在那里。

这篇文章里的每一条查询，既能用来查别人，也能用来查我们。先拿我们开刀。

把错误存下来，不等于从中学习

你修好过一次。你解释过原因。下一次会话，它又回来了。

这句话里的“记忆”其实是两件不同的事，把它们分开就完成了大半工作。一件是存储：错误或修正被写到某处，可以再被读到。另一件是学习：因为上一次的结果不好，系统接下来的行为有了不同。

几乎所有打着 agent memory 旗号卖的东西，做的都是第一件事，而且做得不错：一条笔记、一个文件、一张图、一个向量索引、一个托管存储。这些都是存储，存储确实有用。但它也是对称的——它记住错误建议的忠实程度，和记住修正的忠实程度一模一样，然后把两者以同样的置信度交还给你。

三个检查可以把两者区分开，而且这三个检查你自己就能全部跑一遍。

1. 到底有没有一个接收结果的输入口？ 不是让你写一条新笔记的地方，而是一份报告，告诉你刚才给你的东西是错的。
2. 如果有，它改变的是什么？ 记忆的文本、它的权重，还是东西返回的顺序。
3. 这种改变能扛过一次重启吗，你看得见它吗？

本页剩下的部分，就是把这三个检查套用到六个系统上：Cognee、Letta、Mem0、Supermemory、Zep 和 Mnemoverse。

要让一个错误不再回来，必须改变什么

先讲机制，再讲产品，因为机制决定了你该看什么。

编程助手查阅记忆的方式，和你翻一条笔记不一样。某个东西检索出一小撮条目，把它们摆到模型面前，模型写它写出来的东西。如果错误条目一直出现在这一小撮里，模型就会一直产生同样的坏想法——这不是它固执，是喂给它的东西有问题。

这就告诉了你杠杆必须放在哪里。删掉错误的记忆是一种答案，而且很粗暴。 你得知道检索出来的条目里哪一条是坏的，这意味着你要去读它们，而这正是你想躲开的那份工作。何况一条曾经错误的记忆，换个场景往往就是对的：关于部署路径的那条笔记，对某个服务是正确的，对下一个服务就是误导。删掉它，两个都丢了。

排序没有这两个问题。 什么都不用销毁，同一条目可以在某类问题里排低，在另一类问题里排高。但它需要一样写入路径提供不了的东西：一份事后的报告，说明返回的那个东西是错的。一个结果。

这就是为什么本文谈的是输入，而不是存储格式。这里每个系统都能存下一条修正。问题在于，坏结果下游的某个东西，能不能触达那个决定下次返回什么的东西。

保留有效的做法和纠正无效的做法，是两件不同的事

搜一下如何让 agent 从错误中学习，返回的结果里很大一部分讲的是问题的另一半：如何把跑通的工作流保留下来并重放。那确实是个真实的产品思路，很多地方都讲得很清楚，但它不是这里要问的问题。这两件事看起来相似，行为却完全不同，因为成功可以在发生的当下被捕获，失败通常不能。

厂商的页面也呈现出同样的分野。Letta 的快速上手文档告诉你 agent 出错时该怎么做，而它描述的动作是一次持久化写入：“当它犯错时，绝不该重蹈覆辙”，用 /remember 命令让这次纠正固定下来。这是存储，做得刻意，也做得不错，属于上一节里的第一类，而不是第二类。

Supermemory 的 review 端点看起来像第二类，结果又是第三种东西。它们让你对引擎推断出的记忆——而不是你明确陈述的记忆——做出批准、拒绝或撤销的决定，厂商自己的页面把效果写得很精确：一条记忆在被审核之前、处于推断状态时，“在搜索中被降权”；批准后，它的排序等同于一条明确陈述的事实；拒绝后，则“完全从搜索中移除”。这是对一条推导出的事实是否成立做出的裁决，不是对某次召回结果如何的汇报。两者都有用，但不能互换，而一张把二者都归入 feedback 的功能对照表，是在比较两种不同的机制。

这里到底有没有什么东西接收结果？

这一节是本页超出它所源自的那轮扫描的地方，所以先讲清楚差别。 那轮扫描运行于 2026 年 9 月 8 日，每家厂商覆盖六个面：文档树、changelog、release notes、GitHub 组织加关键词搜索、机器可读索引，以及论坛。Cognee、Supermemory 和 Mnemoverse 能从 changelog 得到答案，我们自己的则是在代码仓库里找到的，而不是某个独立地址；Letta、Mem0 和 Zep 这轮扫描根本没找到 changelog。扫描自身的结论有严格的边界，值得原样重复一遍，因为正是这个边界让下面的差别成为一次扩展，而不是一次更正：在凭据覆盖到的那些面上，六家中有三家没有描述任何因结果不佳而改变检索的输入，被点名的三家是 Mem0、Cognee 和 Zep。这个说法对那些面成立，对它们下面的页面并不成立——那些凭据里的文档面只是对每棵文档树抓取了一个页面，而描述这些反馈输入的页面在下面好几层。2026 年 9 月 10 日在文档主机上重新查看，三家中有两家发布了这样的输入。

以下是这五家各自公开了什么，每一行都取自旁边标明的页面，并在 2026 年 9 月 10 日重新读过一遍。

系统	公开的、可承载负面判定的输入	它附着在什么上	厂商对效果的公开说明
Cognee	cognee.session.add_feedback，可附带反馈文本和一到五分的评分	一次召回得到的答案，通过它在会话内的标识符	“要让反馈影响后续检索，请带上相关的 session_ids 运行 improve()。”
Mem0	POST /v1/feedback/，取值为 POSITIVE、NEGATIVE 和 VERY_NEGATIVE	一条记忆结果，通过 memory_id	页面说这个端点的用途是“对记忆结果提交正面或负面反馈”，对排序上会发生什么变化只字未提
Letta	PATCH /v1/steps/{step_id}/feedback，“该反馈是正面还是负面”	一个执行步骤	页面把该操作描述为“修改给定步骤的反馈。”，并未把它与任何检索顺序联系起来
Supermemory	审核端点，approve、decline 和 undo	引擎推断出的一条记忆，而不是你明确写下的	未经审核的推断记忆“在搜索中被降权”，被拒绝的则“完全从搜索中移除”
Zep	在所读的界面上没有找到
Mnemoverse	memory_feedback(atom_ids, outcome)，“结果信号：-1.0（失败）到 +1.0（成功）”	一次召回返回的那些记忆	“这会调整后续召回”，并在同一索引上写道，“无用的记忆会被排到后面，而不是被删除”

Cognee 是最清楚的一例，值得直说。 它的反馈指南写着“对召回答案的反馈通过 Sessions 处理”，随后一步步讲了如何记录这次交互、找到你想评分的那条答案的标识符、对它调用 add_feedback，最后是这里最关键的一句：“要让反馈影响后续检索，请带上相关的 session_ids 运行 improve()。” 这是一个作用在检索答案上的输入，并且有一条公开的路径，从它通回检索接下来会做什么。这正是那次排查没有触及的机制。

Mem0 也公开了一个输入。 该端点记录在 docs.mem0.ai/api-reference/memory/feedback，它接收一个记忆标识符和三个取值之一，而诚实的边界在于页面没说的部分：它只说明这个端点接受什么，不说之后排序会怎样。Mem0 另外在 changelog 里公开了一个搜索时的排序偏置，值得一读，恰恰因为它会改变结果顺序，却完全不接收任何判定。该条目描述了一个按项目生效的偏置，会提升最近被触碰过的记忆，指出“搜索中返回的每条记忆都会更新其访问历史”，写道“衰减可以重排候选，但从不删除它们”，并用厂商自己的话给出了默认值：“默认关闭；通过项目端点上的 decay 字段按项目选择启用”。频率和近因会改变那个排序。答案是否正确则不会。

Letta 的输入确实存在，只是挂在别的东西上。 step 是一个执行对象，给它标正或标负，对可观测性和评估都有用。它并不是在报告某条检索到的记忆有误——那一页和 quickstart 里，都没有任何地方说这两者会改变后续读取的顺序。

Zep 是本文唯一一处“不存在”的断言，而它的边界就写在同一段里。 在已读取的界面上，Zep 公开的内容没有任何一处描述过一种能对召回结果下判断的输入：getzep.com/llms.txt 的机器可读索引在 2026 年 9 月 10 日为 3,963 字节，其中 feedback、outcome、valence、rerank、reinforce、downweight 出现次数均为零，而该文件显然并非空文件；help.getzep.com/sitemap.xml 中列出的 324 个页面在同一天被逐一走过，其中 feedback 一词的每一次出现都是示例内容，而不是某种输入；对 getzep 这个组织做术语搜索，对照词能搜到文件，而本文讨论的那个词一个都没有。未覆盖的部分：help.getzep.com/changelog 的 changelog 是分页的，直接抓取只会渲染出页面顶部，本文没有任何结论依赖它；产品闭源的部分则完全无法从外部读取。

有一条边界适用于整篇文章。 这六家里有四家——包括我们——没有公开可读的引擎。扫一遍公开内容，不等于扫一遍实际运行的东西。本文说某样东西不存在时，指的是读取当天这里列出的那些页面和仓库，而不是某个产品的行为。其中两家厂商还运营着无法从外部读取的聊天社区；本次扫描没有覆盖它们，如果答案在那里，本文也没有。

扫描没找到的那些 changelog，以及为什么没找到。 扫描把 Mem0、Letta 和 Zep 的 changelog 记为未找到，这是关于扫描本身的真实陈述，而不是关于厂商的：它说明的是界面缺失，而不是厂商沉默。这三家的 changelog 都存在，而且都在文档域名而非营销域名下——而扫描查的是后者。2026 年 9 月 10 日，docs.letta.com/reference/changelog 返回 200，412,108 字节，约八万四千个字符的文本；同一域名下一个虚构路径返回 404，文本量约为前者的二十分之一；docs.mem0.ai/changelog 返回 200 并解析到 /changelog/highlights；help.getzep.com/changelog 返回 200 并解析到 /v3/changelog。第一个根本猜不到，因为 docs.letta.com/changelog 会解析到一个客户端 SDK 页面。扫描的宽度取决于它最窄的那个界面，而本文比扫描走得更深的两处，都源自同一种错误。

从上下文学习不等于从结果学习

五家里有两家明确写下了自己对学习机制应有的样子的立场，这两段都值得直接引用，而不是概括。两家都把学习放在上下文里。

Supermemory，谈它自己那套机器可读的索引。 句子的主语是他们的模型，而不是泛指的产品：“Our model, learner-1, extracts and dreams on the context of every user, task, and tenant”。同一份文件里有一个小节标题写着“Memory that keeps learning”。这就是学习，而且是从上下文学习：发生过的更多事情被喂进去，模型拿到更好的简报。这句话没有对上一次回答好不好做出任何判断，而前面提到的那些 review 接口判断的是猜测，不是结果。

Letta，谈它已发表的持续学习研究。 论点是学习应该发生在 token 空间里，句子里带的是“应该”而不是“已经”：“updates to learned context, not weights”，并称这是 agent 从经验中学习应当采用的首要机制。底层的框架是：已部署的模型无法像人们以为的那样学习，因为“their weights are frozen at deployment”。

那一页上那句关于人的话讲的是人，也是这里最容易被误引的一句。 Letta 拿人作对比：“Humans continually learn and improve over time”，习得新技能，更新自己的信念，并且“modify their behavior to correct for past mistakes”。这是在描述要模仿的对象，不是在说 Letta 的 agent 会做什么。抽掉主语去引用，就是替他们说话。

同一页还点出了一个例外，所以这里也点出来。 紧接着那句关于权重冻结的话，Letta 写道：“The one notable exception is Cursor's tab-completion model which uses online RL to continuously improve based on user feedback, but this form of continual learning operates at the population level, improving the model for everyone rather than enabling individual agents to learn from their own experience.” 他们补充说，“it is scoped to a narrow domain: short code completions, not general reasoning and actions”。所以确实存在一个已上线、被广泛使用的机制，在用户反馈上学习，就在一个编码工具里，而两条限制都是厂商自己说的：它改进的是所有人的模型，而不是修掉你项目里的那个错误；它覆盖的是补全，而不是推理和动作。如果你在哪里读到过——包括我们自己早先几版论证里——说这个领域没人从结果中学习，那句话就是反例，而且它就印在这篇文章为别的事引用的一页上。

这个词，以及它出现的两个地方

这套机制有自己的词汇，所以扫描是在每家厂商自己的组织里搜这些词。Feedback。Outcome。Valence。Rerank。Reinforce。还有一个：downweight——一个被检索出来、结果发现是错的条目，必须对它做的事，用的就是这个词。

查询本身不复杂，而且没有任何一处是我们自己的东西。就是把词加上引号，再接上组织名。

"downweight" org:topoteretes
"downweight" org:letta-ai
"downweight" org:mem0ai
"downweight" org:supermemoryai
"downweight" org:getzep

这些是 GitHub 代码搜索的查询，命令行形式是 gh api -X GET search/code -f q='"downweight" org:topoteretes' --jq .total_count。2026 年 9 月 10 日重新跑一遍，五个全部返回零。

这个零受三件事约束，而每一件都是不该过分依赖它的理由。

第一是单位。GitHub 代码搜索数的是文件，不是出现次数，那里的零是索引里的零，不是现实世界里的零。github.com 的网页界面跑的是另一套索引，同一个查询可能给出不同的数字。

第二是对照，没有对照，阴性结果什么都证明不了。同一套工具，同一天，同样这五家组织，搜 "rerank" 返回的文件数是：十三、三、一百四十四、二十八、一百六十三。索引对每一家都在作答。旁边还跑了第二套工具：2026 年 9 月 10 日直接下载各家旗舰仓库的默认分支并在本地搜索，连字符拼法在其中任何一个里都没有出现。这第二套工具有一个漏洞值得点名，因为它属于那种会悄悄返回零的漏洞。letta-ai/letta 的默认分支现在只有十六个文件，一个 README 加一组政策文档，代码已经不在上面了，搜它几乎证明不了什么；于是改搜 letta-ai/letta-code，两千一百九十二个文件，搜这个词同样返回零。

第三是拼写，而这是整轮扫描里唯一一处结论超出了证据的地方：说负面方向没人写下来。有人写，五家里面有两家写了，用的是连字符。 Supermemory 写在前文引用过的评审文档里，同一个查询加上连字符，在它的组织里返回一个文件。Cognee 写在一篇讲事实有效性的指南里，句子说的是他们的检索不做什么：「搜索和图补全既不过滤也不降权已关闭的节点，所以一个已被取代的事实仍可能出现在结果里。」那个页面不在他们的 GitHub 组织内，所以代码搜索对它返回零，而页面照样这么写着——这是这里最清楚的一个例子，说明单靠一套工具不足以断言某样东西不存在。

那么，这个零究竟说明了什么？ 它并不意味着这些产品内部什么都没发生。大量代码做了某件事，却从未给它起过名字；还有两家厂商用的拼写方式，普通查询根本匹配不到。它说明的是词汇分布的不对称。Rerank 随处可见。而那个表示“下降”的方向——基于糟糕结果的降级——在五家机构中只被写下来两次，其中一次还是一句话，专门解释这种情况不会发生。

为求完整，我们在同一天用同样的方式下载并检索了自己全部十五个公开仓库，这个词的四种拼写加在一起，返回结果为零。我们同样没有公开它。

我们自己这一行，以及我们搭建的通道

轮到我们了。在这个问题上我们做得更好，所以这一节是更长而不是更短，披露放在开头而不是这里。

我们在 API 参考文档和机器可读索引中公开了一个针对结果的输入，它取负值。参考文档在参数表中写明了范围：“结果信号：-1.0（失败）到 +1.0（成功）”。负一正是整篇文章讨论的情形：返回的东西是错的，而报告如实记录了这一点。

它挂在什么上面，是它与上面四个输入中的三个的区别所在。 这个调用接收 atom 标识符，也就是一次 recall 返回的记忆，因此判定落在真正被送到模型面前的条目上。不是落在某个执行步骤上，不是落在某条聊天回复上，也不是落在引擎对某个事实的猜测上。我们公开的信号定义说明了它报告的内容：“一条被召回的记忆是有帮助、有误导，还是用完后应当忽略”。

而它改变的是下一次读取的顺序，不是记忆的文本。 记忆留在原地。我们的索引用自己的话说明了效果：“This tunes future recall”，同一文件另一处则写道：“unhelpful memories are out-ranked rather than erased”以及“outcome feedback re-ranks what comes back next”。

所有这些的边界由我们自己划定，下面就是边界。 能够证明它的引擎是闭源的，另外五个中有三个也是如此。该端点需要账号和密钥。你能读到范围和描述，却无法看到排名如何变化。就读者能够验证的内容而言，我们并不比这里的任何人更有优势，而我们自己关于这一信号的文章也用一句话说明了我们自己的测量：“那是我们的做法，不是独立证据。”

没有任何机制能让 agent 承认自己错了

还有一点要说，而这一点正是本页存在、而不是写一篇关于我们自己功能的页面的原因。

输入是我们构建的。是我们写下来的。而我们自己发表的关于它的文章，The Feedback Dilemma，说显式结果反馈“在生产流量中几乎完全不存在，至少在我们测量的流量中是这样”。这句话的后半句是我们对自己发现的限定，所以整句照引：它说的是我们能够看到的流量，而不是所有生产流量。

原因就在同一篇文章里，而且它不是该端点的缺陷。报告结果需要 agent 在答案已经写完之后主动去做，而此时没有任何东西在看着。我们的指导是每次被采纳的召回对应一次反馈调用，文章也说明了这样做的收益和代价：“这使信号在账号层面保持自愿。”它让行为可审计，用同一篇文章的话说，“它避免了强行制造假标签”。自愿是诚实的说法，同时也是限制所在。拥有输入并不意味着错误不会再次出现。 没人调用的渠道和根本不存在的渠道会产生同样的重复错误，这是对这类方案现状最公允的总结，我们自己的方案也不例外。

这与本站发表过的关于规则文件的发现正好互为镜像。如果你把一条规则写下来，看着你的 agent 把它读回给你，然后又看着它照犯不误，那么从来就没有任何东西阻止它。而在这里，防止已修复错误再次出现的机制需要 agent 主动承认自己错了，而没有任何东西能让它这么做。

一分钟测试，用你手头已有的工具就能做

在相信任何对比结论之前——包括本文的——先做这件事。它不需要安装任何东西，对本文提到的任何工具都适用。

在你的工具里找一条你知道是错的记忆。问它一个那条记忆会回答的问题，看着错误的那条被返回。然后告诉工具它错了，用工具允许的任何方式：接口、审核操作、斜杠命令、在对话里发一条消息。接着开一个新会话，把同样的问题再问一遍，这样上下文窗口里不会留下任何东西替你做这件事。如果同一条仍然排在第一个返回，那说明这次上报没有改变本次的顶部结果。你看到的就这么多：它下面的条目可能已经重排，而一个小到不足以跨越名次的权重变化在这里同样不会留下痕迹。如果你的工具会展示完整列表，那就去比对完整列表。如果顶部结果变了，你得到的是一个变化，还不是一个原因。再读一遍对此毫无改变——存储已经收到过这次上报，所以第二次读取只能告诉你新的顺序是否稳定。真正能把上报单独隔离出来的，是一个它从未碰过的对照：挑第二条同类型的错误记忆，用同样的方式在新会话里提问，不发任何上报。如果被上报的那条动了、没被碰过的那条没动，那上报就是差异所在。到这一步，你才可以去读厂商声称它做了什么。

该问厂商什么

四个问题，按这个顺序问，在销售电话上和文档站点上同样管用。

1. 有没有一个接收结果的输入？ 不是让你写备注的地方。而是一个用来上报你返回的结果是错的入口。
2. 它挂在什么东西上？ 一个答案、一条记忆、一个步骤，还是一条存下来的猜测。只有前两个跟召回有关。
3. 它改变什么，这件事又写在哪里？ 文本、权重，还是下一次读取的顺序。
4. 谁得记得去发这个上报？ 如果答案是智能体，在工作做完之后，在没有东西盯着的时候——那么读其余所有内容时都带着这一点。我们的答案也是如此。