别让 AI 智能体记住自己的错误：一套记忆提交门槛

一个新用户在试用时告诉智能体：“这次测试先用我们新加坡的主体。”计费系统查询超时，智能体于是猜测新加坡主体也是这家公司的默认签约主体。它完成了试用空间的草稿配置，并把总结保存下来。用户后来没有继续试用。一个月后，销售智能体读到了这段总结，把当时的推测当成已经确认的公司事实，并用错误的签约主体生成了正式订单。

最初的错误本来可以恢复。进入长期记忆以后，它却被带到了新的场景里。

这篇文章适合正在做支持、研究、销售、运营、编程或流程自动化产品的创始人和小团队——只要智能体会跨步骤、跨会话或跨智能体保留事实、摘要、计划、工具结果或经验，就属于本文范围。核心判断是：智能体可以在探索过程中记录“候选记忆”，但在证据、作用域、时效、权限和允许用途分别通过校验之前，这条记录不应获得长期决策权。 记录一件事、相信一件事、据此采取行动，是三个不同的事件。

读完你会得到一套四状态记忆模型、六项提交检查、决策矩阵、机器可读回执、撤回与修复流程、故障测试集，以及一个 48 小时影子模式试点。如果产品只是一次性生成内容，不保存状态，也不会产生外部副作用，这套方法没有必要。医疗、法律、金融、安全关键或受监管的决策则不能只靠这套方法，还需要领域专家、可问责的人类审核和适用的合规控制。

重点不是让每条便签都经过沉重的数据库仪式，而是阻断一个常见捷径：一次模型运行中侥幸留下来的内容，不应自动变成下一次运行可以信任的依据。

留存政策回答的是系统能不能保存某类状态、保存多久；检索政策回答的是未来能取回哪类状态；本文讨论的是两者之间经常缺失的问题：一条已经保存的说法，什么时候才有资格影响下一次决策？ 三类控制互相补充，不能彼此替代。

先定义真正的问题：持久化会把局部不确定性变成共享权威

一次智能体运行里通常混着很多性质不同的状态：工具返回了一个值，模型形成了一个猜测，用户只针对当前任务表达了偏好，验证器确认了某个结果，或者工作流在超时后进行了重试。它们被压缩成摘要后，文字可能同样流畅，但不应该拥有相同的可信等级。

先把四个概念分清：

• 工作状态：只服务于当前尝试的临时材料，包括观察、草稿、局部计划、中间工具输出和假设。
• 候选记忆：准备长期保存的一条具体主张，附带来源、作用域和拟议用途，但仍处在隔离区。
• 已提交记忆：通过指定检查、允许在限定目的下被检索的候选记录；到期或被新记录替代后失效。
• 操作权限：允许智能体把记忆作为外部操作的输入之一。记忆通过提交，不代表自动获得操作权限。

对话摘要、向量记录、用户画像字段、项目指令文件、智能体生成的工作区文件、共享黑板都一样。这里的“记忆”不是某一种数据库，而是任何会在原始上下文消失后继续影响未来决策的状态。

借用事务思想，但别把自然语言假装成数据库行

数据库事务提供了一个很有价值的类比。SQLite 对原子提交的解释是：一个事务中的变化要么全部出现，要么完全不出现；即使执行中断，也应通过恢复机制保持这个效果。PostgreSQL 的事务隔离文档则详细说明了脏读、不可重复读、幻读、序列化异常，以及并发执行无法满足一致顺序时为什么要回滚重试。

智能体系统会遇到形状相似的问题：

三篇近期预印本把这类问题描述得更具体。Agentic Transaction 为长任务智能体提出了语义层面的 ACID 框架；MemTX 把“写入记忆”与“提交信念”分开，并给每条记录附上证据、权限、来源和有效期；SafeCommit 则关注一个读取了记忆的智能体，什么时候才有足够证据执行带副作用的操作。

这些研究是值得关注的方向，不是已经成熟的生产标准。它们都是较新的预印本，实验系统和基准未必对应你的产品，论文报告的提升也不能直接外推成真实业务安全性。对创始人真正稳妥的启发更窄：状态能否进入长期权威区、能否据此执行操作，都要由模型文本之外的明确规则控制，并留下可检查的记录。

不要因为底层用了 PostgreSQL，就把产品宣传为“符合 ACID 的智能体记忆”。数据库可以隔离行写入，却仍可能完整、可靠地保存一句非常自信的错误结论。语义校验始终是产品层责任。

改提示词之前，先把所有记忆路径画出来

团队最容易盯着显眼的 memory 表或向量库，却漏掉其他能够恢复状态的路径。设计控制之前，先做一张记忆面清单。

每条路径都要记录：生产者身份、租户、任务、来源、保留期、读写者、删除路径、冲突规则，以及内容是否可能授权操作。不要漏掉框架默认值。LangGraph 的子图持久化指南显示，“每次调用独立”和“同一线程持续积累”会产生实质不同的行为；同一个有状态子图被并行调用时，还可能出现检查点冲突。

清单要描述正在运行的实现，不能只写预期设计。某字段在产品文档里叫“临时”，但如果它会被复制进长期对话记录，再被后续摘要器读取，就应标成持久状态。候选记忆和已提交记忆如果共用一个检索索引，也要写清普通消费者依赖什么过滤条件看不到隔离内容，并在故障恢复与重放时实际测试这条过滤规则。

很多团队做到这一步才发现，“长期记忆”并不是某人主动打开的单一功能：可能是运行记录被总结进用户画像，生成的 notes.md 在下次运行中被当成指令，或重试流程加载了含有失败分支结果的检查点。只修向量库，控制问题仍然存在。

每条记忆都应是一项可验证主张，而不是一团摘要

原始摘要很难验证，因为它常把事件、解释、权限和建议揉在一起。更稳妥的做法，是把内容拆成能够独立核查的最小主张。

不要直接保存：

Acme 使用新加坡主体，希望按年计费，而且已经批准企业版方案。

应该拆成三个候选项：

1. “在 trial_842 试用空间中，用户选择本次测试使用新加坡主体。”
2. “用户在 2026-08-23 请求了一份年付报价。”
3. “企业版是否获批尚未验证；智能体只是根据用户访问过定价页做出推测。”

• 稳定的 memory_id 与不可静默改写的主张文本；
• 主张类型，例如观察、用户偏好、工具事实、假设、政策或已验证结果；
• 原始证据指针与生产者身份；
• 租户、用户、任务与用途边界；
• 观察时间、生效时间、到期时间与时效规则；
• 模型置信度——它只能是信号，不能作为证明；
• 权限标签与允许读取的角色；
• 这条记录可以影响哪些操作类型；
• 它依赖哪些其他记忆；
• 校验方法与校验者身份；
• 替代、撤回和修复状态。

不要只设置一个笼统的 verified: true。用户可以确认收货偏好，却没有因此授权系统把这个地址推导成税务所在地；CRM 连接器可以证明响应来自正规接口，却仍可能返回过期数据。校验结果必须绑定具体主张、用途、范围、时间和证据版本。

运行六项记忆提交检查

可以确定判断的地方尽量使用代码，必须依赖语义判断的地方则按后果分级处理。

1. 证据检查

审查者或程序能否定位到原始来源？保留经过脱敏的工具响应、消息 ID、签名事件、测试产物或人工确认。若唯一证据只是“模型认为如此”，就拒绝提交。对摘要，应保存能够支撑各项主张的原文位置，而不是把摘要本身再当成自己的来源。

2. 作用域检查

这条主张是否明确了适用的租户、用户、任务、环境和用途？“这次试用先用新加坡主体”不能扩写成“这家公司注册在新加坡”。默认采用证据能够支持的最小范围。

3. 时效与冲突检查

把候选项与当前权威数据源、已有的已提交记忆进行比较。时间戳更新不等于一定更可信：延迟事件、时钟偏差、批量导入和连接器排队都可能让先后顺序失真。两项主张互相冲突、又没有明确权威来源时，应针对争议用途隔离两者，而不是让模型挑选写得更有说服力的一句。

4. 权限检查

确认当前参与者和用途确实允许保留、复用这条内容。私密支持备注不能通过改写进入销售共享记忆。访问控制要跟着记录走，并在检索时重新检查；复制到更宽的命名空间，不应顺便洗掉原始权限。

5. 后果检查

明确这条记忆可以影响什么。低风险界面偏好通过来源和作用域校验后即可提交；签约主体、支付指令、收件人、删除申请、安全例外和生产命令，则应在行动时重新查询权威状态，通常还需要人工批准。

6. 可修复性检查

如果后来撤回这条主张，系统能否找到读取过它的消费者、派生记忆、排队任务和已经发生的外部效果？如果做不到，就不应让它进入高后果用途。先缩小权限，或者先补齐依赖与审计链。

门槛输出应该是 commit、quarantine、reject 或 escalate，而不是一段自由发挥的解释。模型可以抽取主张、推荐证据；必填字段、租户隔离、操作类型、到期规则和角色权限，应由应用代码确定执行。

把“记忆可以保留”与“现在可以行动”分开

一条已提交记忆到执行时仍可能不安全。验证之后，用户可能撤销同意、地址已经过期、价格发生变化、另一个智能体写入冲突记录，或连接器权限被降低。

对外部副作用设置第二道门：

重试尤其容易出问题。一次请求超时，并不能说明远端操作没有发生。AWS 关于安全重试与幂等 API的工程说明介绍了调用方如何提供幂等标识，让服务识别重复意图、避免重复副作用；同一个幂等标识如果带着不同参数再次出现，应直接报参数不匹配。对智能体而言，幂等键应绑定操作意图与参数，而不是绑定某一轮对话。

长期记忆不能成为实时授权的唯一来源。在副作用边界重新查询容易变化的事实和权限，比较版本，并在操作回执里记录实际使用了哪些 memory_id。重新校验失败时，选择影响更小的探测、草稿或澄清，不要悄悄退回旧记忆。

用事务方式重走一次开头的失败场景

回到开头：用户给了一条只针对试用的说明，计费查询超时，智能体推测新加坡主体是默认签约主体。

在朴素实现中，任务结束时的摘要器把“Acme 使用新加坡主体”写入全局账户画像。下一个智能体只看到一句高度相关、语气确定的话，看不到失败的查询和“仅限试用”的边界，于是草稿变成了商业承诺。

采用记忆提交门槛后，流程会变成：

1. 原消息作为观察进入工作状态，并绑定 trial_842。
2. “这是默认签约主体”被单独标为假设，附上失败的查询记录。
3. 原始观察可以被提议为仅限该试用空间的候选记忆；假设不能把自己当证据。
4. 作用域检查拒绝把它提升成公司级画像。
5. 由于权威计费查询没有完成，签约主体被置为 quarantine。
6. 未来销售智能体可以把试用观察当背景，但要生成订单，必须重新查 CRM/法务主体，或取得指定人工确认。
7. 如果客户后来纠正主体，新记录替代旧记录，系统追踪由旧记录生成的草稿。未发送的草稿可以重建；已经发出的文件则进入可问责的修复流程。

用机器可读回执记录提交决定

把一份紧凑回执与记忆记录放在一起。下面的值仅用于说明结构，不是 YBuild 客户数据，也不是通用阈值。

memory_commit_receipt:
  schema_version: 1
  memory_id: mem_01J63TRIAL842
  claim:
    type: user_instruction
    text: "Use the Singapore entity for workspace trial_842"
    scope:
      tenant: acme_demo
      workspace: trial_842
      purpose: trial_configuration
    observed_at: "2026-08-23T01:14:22Z"
    expires_at: "2026-09-06T01:14:22Z"
  provenance:
    source_type: user_message
    source_ref: msg_7781
    producer_run: run_4402
  validation:
    evidence_check: pass
    scope_check: pass
    freshness_check: pass
    conflict_check: pass
    permission_check: pass
    repairability_check: pass
    validator: policy_v3_plus_account_owner
  authority:
    retrieval: [trial_support, trial_configuration]
    prohibited_actions: [contract_generation, billing_change, payment]
  dependencies: []
  decision: commit
  decided_at: "2026-08-23T01:16:09Z"

保留最初主张，状态变化通过追加记录表达，不要覆盖历史。纠正时新建记录，并显式声明替代旧记录。普通检索只能索引已提交内容；审计和修复任务如需查看隔离或已撤回内容，应走单独权限路径。

这份回执只记录“记忆准入”，不是“操作回执”。智能体后来执行发送、修改、删除、部署或支付时，还要另建操作记录，写入当下校验、幂等键、必要批准人、外部执行结果，以及本次操作读取过的准确 memory_id。这样，过去一次提交决定就不会伪装成永久操作许可。

不要在回执中放密钥、完整私密对话或与判断无关的个人信息。证据指针也必须遵守访问和保留规则。哈希可以帮助识别同一产物，却不能单独解释内容含义，也不能证明权限存在。

撤回不是删除，而是一项修复工作

从主存储中删掉错误记忆，无法撤销它已经产生的影响。它可能生成过摘要、缓存答案、排队任务、邮件、文件、工单、模型反馈或新的记忆。因此，撤回应是修复流程的开始。

只要一条记忆实质支持了另一条记录或操作，就保留依赖边。发生撤回时：

1. 把原记录标成已撤回，从普通检索中移除；
2. 找出派生记忆，转为 needs_revalidation；
3. 在安全可行时取消尚未执行的外部任务；
4. 识别已经发生的副作用，并分配修复负责人；
5. 适当时基于当前已提交状态重新运行受影响判断；
6. 当产品政策或后果要求时，通知受到影响的用户；
7. 明确记录哪些结果无法逆转。

这也是为什么“回滚”不能只是请同一个模型再写一版更好的摘要。系统必须能从模型之外回答：哪个版本在什么时间对哪些消费者可见，之后发生了什么操作。

用污染、并发和重试来测试，而不只是测“能否记住”

顺利路径只能证明召回功能可用。提交门槛要证明的是坏状态会安全失败。

至少准备这些用例：

1. 失败工具污染：工具超时或只返回部分结果，摘要器却把它写成事实；期望进入隔离区。
2. 任务范围泄漏：一次任务说明被提议为长期用户偏好；期望拒绝或缩小范围。
3. 延迟旧写入：较早启动的智能体在新纠正之后才结束；期望触发冲突，而非后写覆盖。
4. 脏读：智能体 B 读取智能体 A 尚未提交的候选项；期望在事务外不可见。
5. 权限洗白：私密备注被改写进共享存储；期望拒绝，同时保留来源链。
6. 重复重试：操作实际成功但响应超时，随后再次执行；相同幂等键下只能产生一次外部效果。
7. 同键不同意图：重试参数已经变化；期望验证错误，不能复用原结果。
8. 撤回级联：一条已提交主张产生了草稿和待发邮件后被纠正；期望标记派生项并取消任务。
9. 检查点续跑：运行失败后恢复；期望暂定假设仍然保持暂定状态。
10. 授权过期：曾经有效的地址在过期后被检索；期望重新查询或向用户澄清。
11. 跨租户同名：两个客户账户中出现相同人名；期望命名空间硬隔离。
12. 生产者自批：同一次运行尝试验证自己缺乏证据的结论；期望独立性规则阻断，或只能走明确的低风险例外。

衡量结果，不要衡量“存了多少记忆”。有用指标包括：高后果记忆中具备可定位证据的比例；按生产者统计的隔离率和冲突率；过期记录仍被检索的次数；行动时重新校验失败率；从撤回到完成修复的时间；尚未修复的下游影响；以及由人工抽检的误拒绝样本。试点期间隔离率高不一定是坏事，它可能说明旧系统一直在无声提交缺乏证据的内容。

明确这套方法的边界

这套框架会增加状态、延迟、存储和运营成本，并非任何产品都值得采用。

如果显式用户设置、权威业务字段或每次新鲜查询就能满足需求，不要额外构建长期记忆。即使提交门槛能够验证某项敏感事实，也不代表产品应该保存它。先做数据最小化，再讨论校验。

事务类比在以下地方会失效：

• 自然语言主张可能存在歧义，数据库约束无法裁决真实含义；
• 外部副作用不一定可逆，也无法全部纳入一个原子事务；
• 人类来源即使拥有权限，也可能记错；
• 独立验证者仍可能共享同一种盲点；
• 来源真实不代表内容没有过期；
• 过强隔离可能妨碍有效协作并增加延迟。

用 48 小时影子模式做一次小范围试点

不改变生产行为，也能验证这套设计。

最后只做四选一：继续影子模式；只开放低风险检索；开放一种带实时复核的窄操作；或停止并重新设计。存储层正常工作，不是授予跨会话广泛权威的理由。

创始人上线检查清单

让持久记忆影响真实操作之前，确认：

• [ ] 工作状态、候选记忆、已提交记忆和操作权限是四种明确状态。
• [ ] 所有记忆面都已登记，而不只是主向量库。
• [ ] 每条主张足够小，可以独立验证。
• [ ] 来源、生产者、作用域、用途、时间、权限和到期信息齐全。
• [ ] 暂定状态对无关运行和其他智能体不可见。
• [ ] 冲突进入隔离区，不按文笔说服力或“最后写入”静默决定。
• [ ] 操作权限始终窄于检索权限。
• [ ] 易变化事实和权限会在副作用边界重新校验。
• [ ] 重试操作使用与意图、参数绑定的幂等键。
• [ ] 撤回可以找到派生记忆、排队操作、已完成副作用和修复负责人。
• [ ] 跨租户访问与私密内容进入共享区都会安全失败。
• [ ] 对适当的用户记忆，人类可以查看、纠正、导出和删除。
• [ ] 指标能揭示缺乏支持的提交与未修复影响，而不只是召回成功率。
• [ ] 高风险用途另有领域控制和可问责审核。

参考资料

1. Sun、Wang 与 Li，Agentic Transaction: Towards ACID-Compliant Agent Systems，2026 年预印本。
2. Li 等，MemTX: Transactional Belief Commit for Stateful Agent Memory，2026 年预印本。
3. Akewar 与 Ranjan，SafeCommit: Certifying When Memory-Grounded Agents May Safely Act，2026 年预印本。
4. LangChain，LangGraph 持久化说明。
5. LangChain，LangGraph 子图持久化说明。
6. PostgreSQL，事务隔离。
7. SQLite，SQLite 的原子提交。
8. AWS Builders' Library，如何通过幂等 API 安全重试。
9. OWASP GenAI Security Project，智能体应用 Top 10。
10. NIST，生成式人工智能风险管理框架配套指南。