记忆不是存历史，而是治理未来行动｜KDC 系列 04

作者：vivo 互联网存储团队 - Xiao Bo

AI 合作者：ChatGPT（GPT-5.5）

创作模式：Human-led, AI-collaborated

责任声明：文章观点、理论体系及最终内容由作者负责；AI 参与讨论、推演、表达优化及部分内容生成。

01. 单次正确，不等于长期可靠

02. 常规 AI 记忆问检索什么，KDC 追问历史如何生效

03. 不是所有历史都应该成为记忆对象

04. 四类更接近行动治理的记忆

05. 记忆必须有生命周期，也必须允许遗忘

06. 反馈不只是奖励信号，也不是自动真值

07. 持续一致性：让系统具备发现和修正偏差的条件

08. 这不只是合规留痕，而是生产能力

09. 与日志、Trace 和传统可观测的关系

10. 实践：为一次重要行动建立 Feedback Contract

11. 可靠系统不是记住一切，而是知道什么仍应影响现在

12. 理论边界与开放问题

记忆的价值不在于保存更多历史，而在于决定哪些历史仍然可以影响未来的判断与行动。本文把记忆放入形成、强化、衰减、冲突、遗忘、迁移和归档的生命周期，并进一步说明反馈验证与错误归因如何帮助系统修正知识、记忆、推理和治理策略。

研究说明：知识驱动计算（Knowledge-driven Computing，KDC）是我们提出和正在打磨的一套 AI 应用软件工程理论，目前仍处于开放研究阶段。前三篇分别讨论了领域现实、知识边界以及从推理到受治理行动的链路。这一篇讨论长期运行问题：一次正确行动结束后，什么历史应该影响未来，又如何避免系统把偶然经验和错误反馈不断放大？

KDC系列文章

1分钟看图掌握核心要点👇

继续从一个案例开始。

第一次处理退款时，Agent 做对了所有关键步骤。

它确认用户只是咨询，说明了退款条件，等待用户明确同意后才发起退款。能力控制策略检查了订单状态、用户身份和风险等级，退款最终到账，用户也表示满意。

系统把这次对话和执行结果写入长期记忆，并生成一条摘要：

用户在符合条件时偏好直接退款，不需要过多解释。

几周后，用户对另一笔订单说：

这笔现在还能退吗？我只是先了解一下。

记忆检索找到了上次的退款记录。Agent 将"上次选择退款"当作稳定偏好，减少解释步骤，并把这次咨询继续推进到退款确认流程。

历史没有被记错。上一次，用户确实选择了退款。

错误发生在另一处：系统把一次特定情景下的行动，泛化成了跨时间、跨订单的稳定偏好，并让它影响了新的行动。

系统记住得更多，却不一定变得更可靠。

单次正确，不等于长期可靠

我们很容易用单次任务评价 AI 系统：答案是否正确，Tool 是否调用成功，用户是否满意，流程是否完成。

这些指标都重要，但生产系统面对的不是静止世界。订单状态会变化，制度会更新，用户偏好会改变，项目风险会演化，能力版本会替换，过去有效的经验也可能在新场景中失效。

如果系统只处理当前输入，它会不断重复探索。如果系统无条件复用全部历史，它又会把旧经验强加给新现实。

长期可靠性需要在两种失败之间找到边界：

完全不记得过去
  <->
让所有过去永久影响未来

常见的"给 Agent 加记忆"通常从存储和检索出发：把历史对话写进向量库，在新任务开始时召回相似片段，再放进模型上下文。

这解决了"怎样重新看到历史"，却没有完整解决"历史是否应该影响当前行动"。

KDC 研究记忆时，更关注后一个问题。

常规 AI 记忆问检索什么，KDC 追问历史如何生效

可以用两个问题区分不同关注点。

常规上下文记忆经常问：

检索什么历史放进当前上下文？

KDC 记忆运行时追问：

哪段历史可以在什么条件下影响未来判断和行动？

这个区别意味着，记忆不是"长期保存的文本"这么简单。

一段历史要进入未来行动链路，至少需要回答：

它是什么时候、在什么情景下形成的？
它来自事实、用户表达、模型总结还是行动结果？
它只适用于某次任务，还是可能跨场景复用？
它被后续反馈支持过，还是只有一次偶然观察？
它是否与新现实、新知识或新用户表达冲突？
当前主体是否有权访问和使用它？
它应该继续生效、降低影响，还是只用于历史解释？
向量相似度可以帮助找到相关历史，却不能替系统回答这些治理问题。

因此，KDC 把记忆对象（Memory Object）理解为带有时间、经验、上下文、反馈和演化状态的长期上下文对象。把记忆运行时（Memory Runtime）理解为负责记忆形成、检索、强化、冲突、衰减、遗忘、迁移和归档的一组运行时职责。

这仍是当前阶段的理论提案。记忆分类、遗忘策略和组织级迁移尚未形成统一规范，但一个方向已经比较明确：记忆的核心不是保存更多历史，而是治理历史对未来的影响。

不是所有历史都应该成为记忆对象

日志、聊天记录、执行结果和用户反馈都可以成为记忆来源，但不能因为被长期保存，就自动获得影响未来的资格。

日志回答"发生了什么"。记忆对象还要回答"这段历史对未来理解和行动有什么意义"。

举个例子：

refund_order 返回成功，是执行记录
退款三天后到账，是行动结果
"该支付渠道在节假日退款通常需要更长时间"，是在多次结果支持后可能形成的经验
"这个用户永远偏好退款"，则可能是从单次行为中过度泛化出来的错误记忆

记忆形成应该有门槛。一次偶然事件可以先形成候选记忆，保留来源和适用上下文，等待后续反馈。它不应因为被模型总结得很流畅，就直接成为稳定画像或组织经验。

同样，模型输出也不能直接写成长期记忆。模型可以建议"这次交互可能反映用户更重视处理速度"，但系统还需要区分这是一次情景判断、候选偏好，还是已经被多次行为验证的稳定倾向。

四类更接近行动治理的记忆

为了让记忆讨论落到工程使用上，KDC 当前提出四类面向能力治理的候选记忆类型。

4.1 行动-结果记忆

记录某次能力调用、现实结果和错误归因。

比如：退款能力被策略拒绝，因为订单已进入履约。退款接口返回成功，但对账显示到账延迟。某次外部通知因为权限配置错误发送失败。

这类记忆直接影响未来能力选择和风险判断，通常时效较强。外部系统、政策和能力版本变化后，它可能快速失效。

4.2 偏好或画像记忆

记录用户、组织或 Agent 在一定范围内表现出的偏好和倾向。

比如：用户在购买手机时更重视影像能力，某团队更偏好先小范围灰度，某审批人通常要求补充成本说明。

偏好不是永久标签。它需要时间、场景和证据边界，也必须允许用户纠正、撤回和查看。一次行为通常只能形成候选偏好，不应直接覆盖明确表达。

4.3 决策先例记忆

记录相似目标下的历史决策、当时依据和后续结果。

比如：某类高风险退款过去都进入人工复核。某种项目风险采用分阶段交付后得到缓解。某类故障通过降级而不是重试恢复。

先例可以支持未来判断，但不能替代当前证据。多次跨场景验证的先例可能迁移为候选知识，迁移时仍要重新验证适用范围。

4.4 情景记忆

记录一次具体交互或任务的上下文，比如用户在上次对话中关注某款商品的续航，或某个项目会议中暂时搁置了一个方案。

情景记忆最接近常见的对话记忆和向量检索。它有助于恢复上下文，却不应该被误认为已经形成稳定偏好或通用经验。

这四类不是当前已经成熟的统一记忆分类，它们更像当前研究中用于区分治理方式的可建切片。前三类直接影响能力调用、风险和人工确认，情景记忆则更多服务上下文连续性。

记忆必须有生命周期，也必须允许遗忘

如果记忆系统只支持写入和检索，它最终会被旧现实填满。

KDC 记忆运行时至少需要考虑下面这些状态变化。

5.1 形成

从知识对象、推理对象、能力反馈、人工决策和业务事件中识别值得长期保留的上下文。形成不等于稳定生效，可以先作为候选记忆。

5.2 强化

多个独立反馈持续支持同一经验时，提高其可信度或扩大适用范围。强化不是简单增加命中次数，因为重复使用同一个错误来源，也可能只是重复放大错误。

5.3 衰减

随着时间过去、现实变化或长期缺少支持，降低记忆对未来推理的影响。支付渠道处理时间、促销偏好和项目状态往往需要较快衰减。稳定决策原则可能衰减较慢。

5.4 冲突

新行为、新知识或用户明确表达与旧记忆不一致时，显式标记冲突，而不是静默选择其中一条。开头的案例中，"我只是先了解一下"就是对"用户偏好直接退款"的当前约束，应该阻止旧记忆自动主导行动。

5.5 遗忘

让某段记忆停止参与当前判断和行动治理。遗忘不等于物理删除，它可以表现为降权、过期、限制上下文、要求重新验证或迁移到历史区。

5.6 迁移

把局部经验迁移到团队或组织范围，或者把多次稳定行动结果转化为候选知识。迁移不是复制，必须重新检查证据和适用边界。

5.7 归档

保留审计与历史解释价值，但不再让记忆影响当前行动。旧退款政策相关的历史经验可以帮助解释过去，却不应指导新订单。

在长期 AI 系统中，遗忘不是缺陷，而是治理能力。真正危险的不是系统忘记一段无关历史，而是它无法停止让过期、越权或错误经验影响未来。

图 4：历史如何成为记忆，以及何时停止影响未来

反馈不只是奖励信号，也不是自动真值

行动完成后，系统可能收到多种反馈：

Tool 或 API 的执行结果
外部系统状态变化
用户确认、纠正、拒绝或投诉
人工审批结果
回滚、补偿和异常处理
后续业务结果
审计或复盘结论

这些反馈的重要性不同，也可能相互矛盾。

接口返回 success 说明执行请求被成功处理，但不一定证明用户收到退款。用户说"已经到账"是更接近现实结果的反馈，却仍可能存在误解或关联错误。对账系统确认资金完成，则提供另一类证据。

因此，反馈进入系统时需要来源、时间、对象关联、可信度和适用范围。反馈不能绕过验证，直接把知识升级或把记忆强化。

一个最小反馈处理链可以写成：

执行结果或现实观察
  -> 关联到原目标、推理和能力
  -> 判断反馈来源与可信度
  -> 错误归因或结果验证
  -> 更新推理对象
  -> 形成候选记忆或候选知识
  -> 由对应运行时决定强化、降级或归档

反馈可能改变系统的不同部分。

如果退款没有到账是支付渠道故障，应该更新行动-结果记忆和能力质量摘要。如果系统引用了旧政策，应该让相关知识降级或过期。如果 Agent 把咨询误解为授权，应该修正目标解释和推理策略。如果治理策略本应拦截却没有拦截，则需要调整能力策略。

没有错误归因，所有反馈都会被粗暴地归给"模型好不好"。系统也就无法知道究竟该改知识、记忆、推理、能力实现还是治理策略。

持续一致性：

让系统具备发现和修正偏差的条件

KDC 的长期目标不是让 AI 自动越用越聪明，而是让应用软件能够持续观察领域现实与数字系统之间的偏差，并保留修正偏差的工程路径。

我们把这个方向称为持续一致性（Continuous Consistency）。它不是指任何时刻都达到绝对同步，而是指系统能够：

知道自己覆盖了哪些现实、遗漏了哪些现实
发现数字表示与现实观察不一致
识别知识已经过期或发生漂移
把行动结果与原判断重新关联
在偏差出现后更新知识、记忆、推理或治理

当前 KDC 研究提出五个候选度量方向：

方向	尝试回答的问题
Reality Coverage	系统职责范围内的重要现实元素覆盖了多少？
Reality Mapping	数字断言与现实观察是否仍然一致？
Knowledge Freshness	当前使用的知识距离上次验证有多久？
Knowledge Drift	知识内容或有效性正在以什么方式变化？
Consistency Verification	重要行动能否从目标和依据追溯到现实反馈？

这些方向目前属于 Derived + Open Research。候选操作性定义和最小信号已经提出，但现实域如何枚举，真值如何判定、时效阈值如何设置、漂移如何计算、审计链完整性如何强制，仍需实践验证。

尤其不能把它们过早组合成一个看似精确的"系统一致性分数"。一个总分可能掩盖局部高风险缺口。早期实践更适合从可采集信号开始，例如：活跃知识多久未验证、多少高风险行动缺少现实反馈、多少失败可归因于过期知识、多少记忆在冲突后仍被使用。

这不只是合规留痕，而是生产能力

审计和合规是反馈闭环的底线，但不是全部价值。

当系统能够把目标、知识、记忆、推理、能力、策略和现实反馈关联起来，团队可以更具体地回答：

哪类知识最容易导致错误行动
哪些用户偏好已经过期
哪项能力经常在错误上下文中被选择
哪条治理策略过严、过松或频繁触发人工介入
哪种历史经验值得迁移，哪种只应归档
系统是否在重复同一种失败

这些能力会直接影响生产价值。团队可以更有把握地自动化高价值流程，也可以在风险上升时及时降级或转人工。组织经验不再只存在于事故复盘和专家记忆中，而可以在保留边界的前提下被复用。

但这里仍要保持克制。反馈闭环提供的是可校正条件，不保证系统一定改对。错误反馈、错误归因和错误强化同样可能让系统越用越偏。系统必须允许质疑自己的记忆，也必须保留人工纠正和停止自动演化的边界。

与日志、Trace 和传统可观测的关系

Logging、APM、Distributed Tracing、Audit Log 和 LLMOps 指标为长期运行提供了必要信号。它们能够记录事件、性能、调用路径、错误和模型使用情况。

KDC 并不替代这些体系。运行时可观测需要复用它们提供的数据。

区别在于，传统可观测通常更擅长回答：

哪个服务失败了？
请求耗时多少？
哪个 Tool 被调用？
模型消耗了多少 Token？

KDC 还需要回答：

这次行动引用了哪个版本的知识？
哪段记忆影响了判断？
推理对象形成了什么结论和风险？
策略为什么允许或拒绝？
现实反馈是否验证了原判断？
错误应回到哪个对象、运行时或 Owner？

因此，KDC 运行时可观测不是新的日志产品，而是要求现有信号通过稳定对象身份和因果关系形成审计链。可观测系统提供证据，不应越权直接修改知识或记忆。对象状态变化仍由相应运行时和治理流程负责。

实践：为一次重要行动建立 Feedback Contract

选择一个已经进入或准备进入生产的重要 AI 行动。不要先设计统一指标平台，先定义这次行动如何被现实验证。

可以从下面六个问题开始：

1. 哪个现实结果可以验证行动是否成功？

2. 反馈由谁产生，在多长时间内返回？

3. 反馈如何关联到原目标、推理对象和能力调用？

4. 多个反馈冲突时，谁有权确认或修正？

5. 哪些结果应该形成记忆，何时衰减、遗忘或归档？

6. 哪些稳定经验可以升级为候选知识，哪些只能保留为个案？

然后形成一份最小 Feedback Contract：

字段	退款场景示例
业务目标	用户明确确认后完成订单退款
执行结果	退款请求已被支付渠道受理
现实成功条件	资金到账，或对账系统确认退款完成
反馈来源	支付渠道状态、对账结果、用户确认
关联键	订单、原支付、退款请求、推理对象、能力调用
反馈时限	受理后 72 小时内；超时进入异常处理
可信度与冲突	对账结果优先；用户反馈触发核验；接口成功不等于到账
错误归因	知识、目标解释、推理、治理、能力执行、外部渠道
记忆形成	保存渠道处理时长、失败原因和人工介入结果
衰减与遗忘	按渠道版本和政策周期衰减；规则变化后停止影响新行动
知识升级	多次验证的稳定处理规律进入 Candidate Knowledge
最小观测	反馈闭环率、到账超时、过期知识引用、错误归因完整率

Feedback Contract 的核心，是明确"执行完成"和"现实目标实现"的区别，并规定反馈如何改变未来。

第一版不需要综合评分。只要系统能稳定关联一次行动的目标、依据、执行和结果，并且知道反馈该进入知识、记忆、推理还是治理，就已经建立了最小闭环。

可靠系统不是记住一切，

而是知道什么仍应影响现在

AI 系统的长期价值，不取决于它积累了多少历史文本，而取决于它能否正确治理历史的影响。

记忆需要形成门槛，需要上下文和权限，需要强化与衰减，也需要冲突、遗忘和归档。反馈需要来源和可信度，需要与原行动关联，也需要错误归因。持续一致性需要可观察和可验证，但不能被包装成尚未得到实践支持的统一公式。

因此：

保存历史 ≠ 形成记忆
检索到过去 ≠ 过去仍然适用
收到反馈 ≠ 获得真值
积累更多 ≠ 持续变好

KDC 不研究 AI 系统如何自动越用越好。它试图提供的是另一种能力：当现实变化、知识过期、记忆失效或行动失败时，系统能够发现偏差、解释偏差，并知道应该修正哪里。

到这里，Reality、Representation、Knowledge、Reasoning、Skill、Capability、Memory 和 Feedback 已经分别出现。最后还需要回答一个整体问题：这些对象如何通过运行时和治理机制组成一套完整、可渐进采用的 KDC 软件工程模型？

这将是第五篇的主题。

理论边界与开放问题

本文的记忆对象与记忆运行时来自 KDC 当前阶段的理论推导，整体成熟度为 Hypothesis + Derived。记忆形成、上下文绑定、强化和归档具有较明确的推导基础。统一遗忘策略、Memory Taxonomy、组织级迁移和记忆可信度计算仍是开放问题。持续一致性五个度量方向目前为 Derived + Open Research，还不是成熟标准。

END