检查已经报错，AI 为什么还记住了那句答案？
设想你正在和一个 AI 助手对话：答案写出来了，负责检查它的程序却出了错。
下一次提问时，你可能会默认，刚才那段没检查完的答案不会再被使用。但在我们的对照实验里，旧逻辑一边报错，一边把答案存了下来；下一轮，模型真的收到了它。
错误提示结束了眼前这一轮，却没有挡住那段答案进入下一轮。
AI 的“记住”，在这里是什么意思？
这里的记忆有一个很具体的含义：程序保存对话历史，下次提问时，把其中的内容再次发送给模型。本文没有测试模型训练，也没有测试某个聊天产品的长期记忆功能。
假如一段未经检查的回答被存进这份历史，后面的模型就可能把它当作已有上下文。比如，一个尚未确认的说法可能成为后续回答的前提。这是我们关心的后果；本次实验直接验证的是那段答案有没有被重新发送。
这个问题来自 jbeckwith-oai 提交的 OpenAI Agents JS #1938。它是帮助开发者连接模型、工具和多轮对话的程序库。开发者可以给回答安排检查：检查可能说“通过”，可能说“拒绝”，也可能自己出故障，没能给出结论。
这次修复吸引我们，是因为旧实现已经处理了“检查说不行”，却漏掉了“检查没能完成”。我们研究持续工作的 AI 助手，想知道这样的中断会不会留下一个影响下一轮的尾巴。
我们故意让检查出错，再问下一句
实验中，测试模型总是输出同一句容易识别的标记文本。我们分别让检查通过、明确拒绝、抛出异常，或让一项通过而另一项异常。随后再问下一句，直接查看模型实际收到的历史。
模型的回答由脚本提供，会话运行和保存则使用真实程序库代码。我们安排了四种运行与保存组合，分别对照修复前的判断和修复后的判断：
| 检查结果 | 旧判断：答案进入下一轮 | 修复后：答案进入下一轮 |
|---|---|---|
| 全部通过 | 4/4 | 4/4 |
| 明确拒绝 | 0/4 | 0/4 |
| 检查抛出异常 | 4/4 | 0/4 |
| 一项通过，另一项抛错 | 4/4 | 0/4 |
这里的 4，是“一次返回完整答案或逐步返回答案”与“两种会话保存方式”交叉得到的四种组合；表格不是线上故障率。两个版本共记录了 32 条观察。
最关键的是后两行：没有检查结论的答案，旧判断会继续传下去，修复后不会。 正常通过的答案仍然保留，之前已经保存的回答和本次用户问题也都没有被误删。
图 1：异常检查后的答案是否进入下一轮。来源：本轮固定源码实验与原始结果，由作者绘制；图中数字为设定场景的观察数量。
没检查完，不等于答案有错
一项检查失败，不能说明答案一定有问题。可能只是检查服务暂时不可用。同样，几项检查中有一项通过，也不能替另一项给出结论。
修复后的处理保留了这个区别：没有把答案判成“已证明错误”，也没有让它自动变成后续工作的依据。
这带来一个实用的设计启发：程序可以为了排查故障，记录“模型刚才说了什么”；同时决定，这份记录暂时不应进入下一轮对话。留存一次尝试，与接纳它作为后续上下文，需要各自的规则。
检查全部通过也只代表满足了这批检查的要求，不保证答案在现实世界一定正确。
检查恢复了，应该补查哪一版答案？
再向前想一步：检查服务恢复时，原答案可能已经被重新生成，用户也可能改过问题。一个迟到的“通过”，到底批准了哪段内容？
本次修复和我们的实验都没有实现补验流程。这个问题却是从对照结果自然延伸出来的：如果开发者要增加补验，就需要把答案内容、对话轮次和所用检查规则对应起来，避免把旧结论接到新答案上。
开发者可以先做一个小实验：让检查程序主动出错，再运行下一轮，查看实际发给模型的历史。普通使用者也能提供有价值的线索：一段刚被提示失败的回答，是否在后文又被当成“已经确认过的事”？保留前后对话和错误提示，会比一句“AI 记错了”更有助于复现。
给技术读者：版本、完整方法与复跑入口
来源作者 jbeckwith-oai；PR 于 2026-09-15 UTC 合入。候选为 457dfff8ce30d19ccbd4a3796ec482356dc19dfa，对照替换为 8ac97dfedd0395beeb38edb0a17b83a9b89c3354 中的原 runner/guardrails.ts，这是该 PR 唯一变更的生产模块，其余候选代码保持一致。
探针使用公共 run、ScriptedModel、内置内存会话 MemorySession 和只支持追加的会话；分别运行流式与非流式模式，检查保存内容及下一轮模型输入。四类检查结果 × 两种运行模式 × 两种会话 × 两个版本，共 32 条观察。部分通过场景验证整批有一项异常，没有控制各检查的完成先后。
另外实际运行了上游对应测试文件，71 项通过，覆盖工具输出等更多情况；该数量与自编观察分列，不相加为可靠性分数。没有调用真实模型服务或外部数据库，也未证明所有自定义存储均正确。
固定源码、原始结果和复跑脚本。本文没有据此认定 CodeFlowMu 存在同一缺陷。