关于AI 记忆（ Agent Memory）的一些想法（二）
- 内容介绍
- 文章标签
- 相关推荐
本文所有的图，全都是Gpt生成的。
书接上文，当我们在谈论 Agent Memory 的时候，我们在谈论什么？这里会有很多问题，但是最为主要的可能是记忆在 Agent 系统里到底是什么？
因为在自己研究这一领域的时候，会遇到很多相关讨论的名词，像是向量库会被认为是记忆，摘要缓存、用户画像（SOUL.md 文件一类）、技能库（Memskills）、时间图谱都被称之为记忆，但它们其实都只是表达的对记忆问题的某一特性的表征，所以我在想的时候，还是觉得可能要先把问题摆回到更本质的位置。而对我来说，Memory 的第一问题不是"怎么做"，而是"它到底是什么"。一旦这个问题没有被说清，系统就会在实现中不断滑移：本来只是派生视图的东西，慢慢冒充了真相；本来只是当前轮的控制件，慢慢变成了长期规则；本来只是一次性的临时提醒，后来却在后台被固化成了长期约束。如何为记忆的合法性立宪，去把握它的边界，我觉得是首要去解决的。
我个人倾向的判断是：Memory 是过去进入当前决策的通道。从这里我们可以分出三个命题（这三个命题并非我独创的，也是我看了别人的总结出来的，可供参考）。
第一，Memory 不是"存储"，而是可被当前决策利用的外部状态。换句话说，能力不来自"历史存在"，而来自"历史是否能够以某种形式影响当前决策分布"。Memory 的价值，不在于存了多少，而在于从历史到当前决策之间的这条通道是否有效。
第二，Memory 的最小闭包至少需要三样东西：Raw Ledger（权威记录）、Derived Views（派生视图）、Policy（控制策略）。Ledger 存原始事实，Views 负责把历史变成可检索、可压缩、可技能化的形态，Policy 决定何时读、读多少、何时写、怎么更新、怎么遗忘。三者缺一，系统要么不可溯源，要么不可用，要么不可控。
第三，Memory 的基本单位更接近 event / action 序列，而不是静态知识块。因为只有把事件闭包作为一阶真相，provenance、rollback、replay 才真正成立。但 event 流本身并不等于可用的记忆能力；真正把历史变成能力的是 views 和 policy。event 是 Ledger 的数据形态，views/policy 才是能力形态。
image1448×1086 216 KB
这三条命题的作用在于，把 Memory 从像是"组件"一样的形态，推进到"系统"的概念。其不是也不应该是一个外挂数据库，而可能就一条结构化的回路去理解它：Raw Ledger → Derived Views → Policy → Commit → Provenance。
但缺陷在于，这只回答了"Memory 至少由什么组成"，却还没有充分回答：过去凭什么影响现在？
现有工作走到哪了
Belike我在写文献综述，我们还是从头看一下这个问题是怎样一步步被逼出来的，以下综述的内容，靠的是Gpt 5.4-Pro和Claude 4.7 Opus（查证），如有疏忽，怪我没看全部论文。
最早的一批工作，核心贡献是让 Agent 拥有持续性。Generative Agents (Park et al., UIST 2023) 做了 memory stream + reflection + planning 的完整架构；MemoryBank (Zhong et al., AAAI 2024) 引入了基于遗忘曲线的记忆更新机制；Voyager (Wang et al., 2023) 用 skill library 存可复用的程序性行为；MemGPT (Packer et al., 2023) 把 OS 虚拟内存的思路搬到了上下文管理。这些工作各自侧重点不同，但共同完成了一件事：记忆第一次从模型的隐含能力变成了显式的系统部件（其实也可以说是产生了内外的区别，从模型本身的注意力系统中剥离出来，成为外部可控的部件）。在这之前，历史只是被丢弃的聊天记录（甚至是历史噪音）；在这之后，历史成了后续行为的资源。
接下来，问题从"有没有记忆"转向了"记忆是否真的可用"。一批 benchmark 和长程评测开始考虑并暴露出一个事实：能存不等于能记，有长上下文也不等于有长期记忆。记忆的概念更为明确的开始脱落出来，其包含至少有：多 session 一致性、时间推理、知识更新、该拒答时是否能拒答。这些问题说明，把更多文本堆到模型面前不会自动产生记忆能力。历史可以被召回，但如果召回的东西没有正确的时间边界、作用域和证据状态，它反而会污染当前推理。
再往后，Memory 开始被做成系统层面的东西（这也是最近时新的爱马仕在做的，包括claude mem等在做的事情，也和claude code这样的“引擎”的兴起，密切相关）。时间知识图、Memory OS (Kang et al., EMNLP 2025)、memory layer、manager、timeline、skill pool——这些方向说明Memory 已不再被当成一个简单外挂，而是开始把它视为一种长期外部状态系统。有综述把这个架构表述为 System 1（通用 Agent 能力）和 System 2（记忆的写入、检索、更新与控制）的分工。这一步比较重要，因为它第一次比较清楚地把记忆从"模型内部能力"与"模型外部状态"之间分开了。
现在，问题又往前推了一步。AgeMem (Xu et al., 2026) 把存、取、更新、总结、丢弃都纳入强化学习策略，让记忆控制本身成为动作空间的一部分；InfMem (Wang et al., 2026) 引入了 PreThink-Retrieve-Write 协议和自适应早停，显式模拟检索前的预思考；程序性记忆方向（Memp 等, 2025）进一步指出，系统不只要记住"发生过什么"，还要记住"以后怎么做"。
从而Memory 的讨论已经不再是"要不要接一个记忆层"的问题了，而是"如何让一个外部状态系统稳定、持续、低损耗地参与决策"。前面说的三条命题——Ledger、Views、Policy——基本上就是对这个演化方向的抽象。
当然，我开始考虑这些问题，是在2月初的时候，这些工作已经很好地回答了"Memory 至少由什么组成"，但对于"过去以什么资格进入当前执行"，给出的回答还不够充分，至少在我考虑的时候，还没有很充分，也行现在已经开始出现很多别的我没有看到的架构了。
image1448×1086 268 KB
四个问题
具体来说，可以总结为四个缺口。（再次感谢Chat老师的总结能力）
第一个问题关于是对象层。 很多系统已经能存很多东西，但"存了什么"和"什么算一个长期对象"之间仍然是模糊的。文本、摘要、用户偏好、事实、规则、候选结论、技能、图谱边，常常都收进一个笼统的 memory layer（另一个问题是，有的分类也显得非常的粗糙，其实并不能比较好的去把这个问题分清楚，或是在运行过程中，由于模型本身的缺陷，会出现阔约边界的问题）。但这些东西的存在方式完全不同：有些只是证据，有些只是派生视图，有些只是候选判断，有些一旦进入执行就会变成约束未来行动的规则。如果不把对象的地位分清楚，后面的治理就一定会漂移。一条"用户偏好"和一条"项目级硬约束"如果住在同一个 memory store 里、用同样的方式被召回和投影，那系统迟早会把一个当成另一个。
第二个问题是关于权威记录和派生视图。 前面提到 Ledger / Views / Policy 的抽象，这个逻辑是很清楚的。但在实际运行中，真正参与当前推理的往往是 views——摘要、索引、embedding 近邻、知识图子图、技能条目。它们会越来越像"系统真正知道的东西"。时间一长，views 就会冒充真相，系统慢慢活在自己的压缩和投影里，而不是活在证据链里。而这一问题不在于 views 不该存在——它们必须存在，因为 raw ledger 不能直接参与推理——而在于它们不能失去回指权威记录的义务（抽象和证据直接的关系非常重要，这是一大治理问题）。一旦一条摘要丢失了"这是从哪来的"和"原始证据是否还成立"的信息，它就不再是派生视图，而是一条没有来源的断言。
第三个问题是关于路径层。 现在很多系统已经很擅长建图、连边、找邻接、做 timeline、做 multi-hop 检索。但多数情况下，所谓的 path 仍然更像 recall edge 或者 topology convenience。它们能回答"这两个东西有关"，却没有真正回答：为什么这条联系成立？它何时生效？它会施加什么影响？它什么时候应该退场？它凭什么被系统承认？如果一条联系真的要影响执行，它就不能只是方便检索的边，而必须是一个被规定过存在方式和作用边界的结构。
第四个问题在于治理层。 Policy的含义落在在讲何时写入、何时检索、何时更新，现在已经有用 RL 来训练这种控制策略的系统出现了。但多数 policy 仍然主要聚焦在操作层面：什么时候读、什么时候写、读多少、怎么压缩。而我觉得可能还有一些也是需要关注的：谁能进入执行？谁只能提供证据？谁只能停留在候选状态？谁能影响当前姿态？谁能进入上下文？谁会在未来约束行动？也就是"执行资格"这个问题的真正展开。
把这四个问题放在一起看，我觉得可能我真正关心的，不是过去如何被组织起来，而是过去如何获得进入当前执行的资格。
一旦 Agent 开始长期工作，过去就不再是中性的历史。它会改变当前判断，改变工具选择，改变风险评估，改变默认姿态，改变哪些行为应当继续、暂停、确认或阻断。过去不是背景材料，而是一种会施加现实后果的力量。所以问题就不再是"过去有没有被保存"，而是"过去以什么身份发言"。
有些过去只是证据。有些只是候选结论。有些只能影响当前姿态。有些可以进入当前上下文。有些一旦进入执行就会变成规则。还有一些，即使被记住了，也不该直接发言。
这就是 Do-What Soul 的出发点：不是让系统更会记住过去（当然这也很重要，只是我精力有限），而是让过去以一种受约束、可校验、可纠错、可退场的方式，重新进入当前执行。
关于我的设计和架构概要
以下内容基本上是我在和AI去battle一些更形而上的问题之后，去落地工程实现的时候，慢慢搞清楚的。可能很快就没有价值了，所以先写一下和大家分享。
Soul 在我这里的定义是：一个让过去在当前以受治理、可校验、可投影、可收束的方式重新发言的长期执行记忆系统。
基本结构
三层：
- 记忆本体层回答：什么被长期承认
- 结构注册层回答：这些对象如何被定位、绑定、挂接到治理结构
- 运行控制面回答：这一轮如何装配、投影、核验、熔断与执行
四个正交轴：对象、路径、证据、治理。相互不可替代，不得互相冒充真源。
四条总纪律：
- 只有记忆对象属于本体；控制面对象不属于记忆本体
- Synthesis 负责组织理解，不直接立法
- ContextLens 只负责投影，不形成第二记忆层
- 后台只能产候选，不能静默产法
这个设计最重要的一点是关于边界的清楚划分，这对我后续写项目代码，真的非常重要。哪些东西可以存在但不能升格，哪些东西可以在运行时参与但不能被固化，都是被显式规定的。这也利于进行review，而不会出现大的偏差。
对象轴：先规定存在方式，再谈收纳
SOUL 的核心对象四类：
- EvidenceCapsule：可证明性来源。它不是默认显影内容，而是把长期对象与可核验来源绑定起来的东西。
- MemoryEntry：长期记忆的主承载体。维度是闭集：preference / constraint / decision / procedure / fact / hazard / glossary / episode。
- SynthesisCapsule：工作综合层，保存阶段总结、对比表、争议图、候选结论。它有稳定的哲学地位，但没有独立规范力——可以组织理解，不能直接立法。
- ClaimForm：把真正需要长期治理的判断投影成可比较、可仲裁、可审计的规则对象。Claim 不是"再保存一份正文"，而是把执行后果明确化。
这里有一个决策是fact 和 factual_policy 的硬边界。两者的区别不在于语言形式，而在于是否承担 durable execution consequence。只是描述项目、环境、工具或用户状态的，留在 fact；而如果一旦漏掉它会持续改变工具选择、写入许可、核验要求或冲突裁决，就必须升级为 factual_policy，进入更强的治理对象。这里的划分灵感来自于，我看《还原与无限》的时候，想到关于“目的”和“行为”的概念。我觉得所知能知和能动还是必须区分开的。
4月中旬的时候，我进一步把对象理解为"带分面的稳定语义单元"，也就是我觉得对象本身可以有更丰富的遗憾，而并非是固定不变的。也就是说，time、situation、risk、obligation 这些东西很多时候不是外挂标签，而是对象语义本身的一部分。一个未完成事项的 unfinishedness 是它之所以仍然需要发言的核心原因；某条风险记忆的情境适用性，是它之所以应该在某些时刻被唤起的理由。它们不是后缀说明，而是构成性的。
证据轴：从断言回到支撑关系
这一轴要解决的问题是：一条记忆凭什么还算数？
在很多现有系统里，memory 就是模型在某个时刻说过一句什么话，或者从某次交互中提取了一个 fact。但"它曾经被记录过"不等于"它现在仍然成立"。我觉得记忆不是断言，而是支撑关系——系统必须能够说明：这条东西为什么还算数。
EvidenceCapsule 因此包含了 semantic anchor（语义锚）、event anchor（事件锚）、physical anchor（物理锚）、provenance、stable digest、evidence health 等结构。证据健康的优先级是：语义锚 > 事件锚 > 物理锚。这意味着，文件路径失效（物理锚腐烂）不应自动让一条记忆蒸发——因为语义锚和事件锚可能仍然有效。但反过来，如果语义锚被击穿、事件不可审计，那这条记忆就必须进入真正的失稳区。
路径轴：这是我觉得现在工作最可以深挖的部分
前面说过，现有系统的 path 大多还是 recall edge 或 graph edge。我的努力是试图把 path 推进成可学习的条件联系结构。这也和我本人的毕业论文息息相关（感谢毕业论文，除了带给我痛苦外，还给我了一些灵感）。
一个最小的 PathRelation 在定义下必须至少回答六件事：
- anchors — 它联系的是什么
- constitution — 为什么这条联系成立（不是"它们 embedding 相近"，而是有没有语义上的理由）
- effect_vector — 一旦命中，会施加什么影响（是改变姿态？是提醒？是进入上下文？）
- plasticity_state — 它如何被强化、削弱、改向
- lifecycle — 它什么时候退场
- legitimacy — 它凭什么被系统承认
这里有一个重要的派生问题：condition 到底归谁管？我的设置是 condition 是跨三层的——有些 condition 属于 object facet（比如"这条记忆只在 Python 项目中适用"），有些属于 path constitution（比如"这条联系在用户主动要求时才成立"），有些属于 runtime evaluation（比如"当前 budget 是否允许"）。如果把它们都写成 path 上的一个字段，系统最后只会得到一堆临时 if-else。
故而我对路径的可塑性做了四种分类：reinforcement（重复支持，strength 上升）、weakening（忽略或失配，strength 下降）、redirection（方向系统性偏移）、retirement（因完成、否认、过窗、反证而退出活跃结构）。
同时，可塑性有热路径和整合循环的职责边界：热路径只允许轻量的即时记账（strength 微增、support_events_count 递增、时间戳更新）；任何涉及 anchors、relation_kind、why_this_relation_exists、governance_class 的变化，都必须走整合循环（Consolidation Loop），不得在热路径即时改写。
治理轴：谁有资格进入执行秩序
这一轴不是"让系统更谨慎"，而是明确回答"谁有资格参与执行"。
几个核心机制：
Slot 不是内容对象，而是治理席位。生成公式固定：governance_subject × claim_kind × scope_class。Winner 不是逐轮 argmax，而是带迟滞的席位秩序——incumbent 默认享有粘性，challenger 只有在新证据显著增强、显式 review 通过、连续多轮稳定压制、用户显式切换或原 winner 失效时，才允许翻盘。
用户纠错不是简单覆盖。系统先通过 session_override 修正当前轮，再通过 Promotion Gate 决定是否持久化。这意味着"用户说了一句话"不会自动变成长期规则——它先解决当前轮的问题，然后才有可能被承认为长期事实。
Green 生命周期不是"存进去就一直算数"。一条记忆进入 Green 之后，仍然会被 contest（新证据挑战）、verification fail（核验失败）、external invalidation（外部失效）、surface detach（绑定脱落）、mapping revoked（映射撤销）击穿。Green 是一种有条件的、可被逆转的执行许可，不是永久身份。
过去如何在当前轮发言
到这里，四个轴已经规定了对象的存在方式、证据的支撑关系、路径的联系结构、治理的资格秩序。但还差最后一步：这些东西如何在当前轮具体参与？
我的方案是：prediction 不是独立模块，而是 learned path 在当前轮的受治理显现。
具体来说，一条 path 在当前轮被命中后，不是立刻把关联对象塞进上下文，而是先进入一个叫 ActivationCandidate 的运行时控制对象。ActivationCandidate 是 turn-scoped 的，不持久化，不属于记忆本体。它结构化地记录了：命中了哪条 path、关联哪些 anchor、why_now、当前 effect_vector 快照、pressure/confidence、governance ceiling、默认显影偏好。
然后由显影层级决定它到底以什么方式参与当前轮：
- stance_bias（最弱显影）：作用于执行姿态和默认保守/激进倾向，不直接进入 ContextLens，也不一定在对话流中显式出现
- dialogue_nudge（中等显影）：一条流内提醒或受治理的 hint，不是把对象正文整块塞进 prompt
- lens_entry（最强显影）：只有在激活足够强、与当前任务强耦合、governance ceiling 允许、manifestation budget 允许时，才可升级
一个关键约束：ContextLens 仍然只做 current-turn selection。它不是第二记忆层，不应吞掉 reminder / hint / stance / projection 的全部职责。不要把 prediction 退化成"更早再 recall 一次"。
image1448×1086 318 KB
合法性的判断
所以总结来说，我做的事情是在 Ledger / Views / Policy 这种 Memory 系统闭环之上，继续追问一组更具体的问题，以期望去建立更为完整的系统合法性：
- 什么被承认为对象？什么只是证据？什么只是候选？
- 什么构成路径？这条路径凭什么成立，凭什么退场？
- 什么能影响执行？什么只能在当前轮发言？
- 什么可以被强化、削弱、改向？什么可以在后台整理？什么绝不能在后台静默立法？
同昨天，不知道说的清不清楚，但是目前是这样。
网友解答：--【壹】--：
btw，文字看出来应该大量GPT生成的，所以看起来很累，如果是AI生成的内容需要截图哦，不能直接copy，我个人建议佬可以做个博客一类的，或者github wiki，然后在LinuxDo这边丢简介 原文挂其他地方？
--【贰】--：
感谢佬的长文，就是看到一半注意力不够了看不太下去，佬下次发可以多一点图片嘛
--【叁】--：
就是实际上我这个架构已经落地完了，还在小修小补，最近在考虑怎么比较好的复述，和做测试。所以没有想好具体一个清晰的概念，去引导叙述逻辑。所以还在探索期。感谢评论，我这个也还得研究研究，我打算是先写了再看。
--【肆】--：
好的，让gpt多搞一点图片。感谢感谢，我也是摸索期，还没有完全搞清楚。
--【伍】--：
文字实际上我还大面积改写了一下，笑死。没有AI原文。我有一个自己博客，就是我自己区分了一些，东西发在哪里。这个是结合我项目的spec的内容写的。
本文所有的图，全都是Gpt生成的。
书接上文，当我们在谈论 Agent Memory 的时候，我们在谈论什么？这里会有很多问题，但是最为主要的可能是记忆在 Agent 系统里到底是什么？
因为在自己研究这一领域的时候，会遇到很多相关讨论的名词，像是向量库会被认为是记忆，摘要缓存、用户画像（SOUL.md 文件一类）、技能库（Memskills）、时间图谱都被称之为记忆，但它们其实都只是表达的对记忆问题的某一特性的表征，所以我在想的时候，还是觉得可能要先把问题摆回到更本质的位置。而对我来说，Memory 的第一问题不是"怎么做"，而是"它到底是什么"。一旦这个问题没有被说清，系统就会在实现中不断滑移：本来只是派生视图的东西，慢慢冒充了真相；本来只是当前轮的控制件，慢慢变成了长期规则；本来只是一次性的临时提醒，后来却在后台被固化成了长期约束。如何为记忆的合法性立宪，去把握它的边界，我觉得是首要去解决的。
我个人倾向的判断是：Memory 是过去进入当前决策的通道。从这里我们可以分出三个命题（这三个命题并非我独创的，也是我看了别人的总结出来的，可供参考）。
第一，Memory 不是"存储"，而是可被当前决策利用的外部状态。换句话说，能力不来自"历史存在"，而来自"历史是否能够以某种形式影响当前决策分布"。Memory 的价值，不在于存了多少，而在于从历史到当前决策之间的这条通道是否有效。
第二，Memory 的最小闭包至少需要三样东西：Raw Ledger（权威记录）、Derived Views（派生视图）、Policy（控制策略）。Ledger 存原始事实，Views 负责把历史变成可检索、可压缩、可技能化的形态，Policy 决定何时读、读多少、何时写、怎么更新、怎么遗忘。三者缺一，系统要么不可溯源，要么不可用，要么不可控。
第三，Memory 的基本单位更接近 event / action 序列，而不是静态知识块。因为只有把事件闭包作为一阶真相，provenance、rollback、replay 才真正成立。但 event 流本身并不等于可用的记忆能力；真正把历史变成能力的是 views 和 policy。event 是 Ledger 的数据形态，views/policy 才是能力形态。
image1448×1086 216 KB
这三条命题的作用在于，把 Memory 从像是"组件"一样的形态，推进到"系统"的概念。其不是也不应该是一个外挂数据库，而可能就一条结构化的回路去理解它：Raw Ledger → Derived Views → Policy → Commit → Provenance。
但缺陷在于，这只回答了"Memory 至少由什么组成"，却还没有充分回答：过去凭什么影响现在？
现有工作走到哪了
Belike我在写文献综述，我们还是从头看一下这个问题是怎样一步步被逼出来的，以下综述的内容，靠的是Gpt 5.4-Pro和Claude 4.7 Opus（查证），如有疏忽，怪我没看全部论文。
最早的一批工作，核心贡献是让 Agent 拥有持续性。Generative Agents (Park et al., UIST 2023) 做了 memory stream + reflection + planning 的完整架构；MemoryBank (Zhong et al., AAAI 2024) 引入了基于遗忘曲线的记忆更新机制；Voyager (Wang et al., 2023) 用 skill library 存可复用的程序性行为；MemGPT (Packer et al., 2023) 把 OS 虚拟内存的思路搬到了上下文管理。这些工作各自侧重点不同，但共同完成了一件事：记忆第一次从模型的隐含能力变成了显式的系统部件（其实也可以说是产生了内外的区别，从模型本身的注意力系统中剥离出来，成为外部可控的部件）。在这之前，历史只是被丢弃的聊天记录（甚至是历史噪音）；在这之后，历史成了后续行为的资源。
接下来，问题从"有没有记忆"转向了"记忆是否真的可用"。一批 benchmark 和长程评测开始考虑并暴露出一个事实：能存不等于能记，有长上下文也不等于有长期记忆。记忆的概念更为明确的开始脱落出来，其包含至少有：多 session 一致性、时间推理、知识更新、该拒答时是否能拒答。这些问题说明，把更多文本堆到模型面前不会自动产生记忆能力。历史可以被召回，但如果召回的东西没有正确的时间边界、作用域和证据状态，它反而会污染当前推理。
再往后，Memory 开始被做成系统层面的东西（这也是最近时新的爱马仕在做的，包括claude mem等在做的事情，也和claude code这样的“引擎”的兴起，密切相关）。时间知识图、Memory OS (Kang et al., EMNLP 2025)、memory layer、manager、timeline、skill pool——这些方向说明Memory 已不再被当成一个简单外挂，而是开始把它视为一种长期外部状态系统。有综述把这个架构表述为 System 1（通用 Agent 能力）和 System 2（记忆的写入、检索、更新与控制）的分工。这一步比较重要，因为它第一次比较清楚地把记忆从"模型内部能力"与"模型外部状态"之间分开了。
现在，问题又往前推了一步。AgeMem (Xu et al., 2026) 把存、取、更新、总结、丢弃都纳入强化学习策略，让记忆控制本身成为动作空间的一部分；InfMem (Wang et al., 2026) 引入了 PreThink-Retrieve-Write 协议和自适应早停，显式模拟检索前的预思考；程序性记忆方向（Memp 等, 2025）进一步指出，系统不只要记住"发生过什么"，还要记住"以后怎么做"。
从而Memory 的讨论已经不再是"要不要接一个记忆层"的问题了，而是"如何让一个外部状态系统稳定、持续、低损耗地参与决策"。前面说的三条命题——Ledger、Views、Policy——基本上就是对这个演化方向的抽象。
当然，我开始考虑这些问题，是在2月初的时候，这些工作已经很好地回答了"Memory 至少由什么组成"，但对于"过去以什么资格进入当前执行"，给出的回答还不够充分，至少在我考虑的时候，还没有很充分，也行现在已经开始出现很多别的我没有看到的架构了。
image1448×1086 268 KB
四个问题
具体来说，可以总结为四个缺口。（再次感谢Chat老师的总结能力）
第一个问题关于是对象层。 很多系统已经能存很多东西，但"存了什么"和"什么算一个长期对象"之间仍然是模糊的。文本、摘要、用户偏好、事实、规则、候选结论、技能、图谱边，常常都收进一个笼统的 memory layer（另一个问题是，有的分类也显得非常的粗糙，其实并不能比较好的去把这个问题分清楚，或是在运行过程中，由于模型本身的缺陷，会出现阔约边界的问题）。但这些东西的存在方式完全不同：有些只是证据，有些只是派生视图，有些只是候选判断，有些一旦进入执行就会变成约束未来行动的规则。如果不把对象的地位分清楚，后面的治理就一定会漂移。一条"用户偏好"和一条"项目级硬约束"如果住在同一个 memory store 里、用同样的方式被召回和投影，那系统迟早会把一个当成另一个。
第二个问题是关于权威记录和派生视图。 前面提到 Ledger / Views / Policy 的抽象，这个逻辑是很清楚的。但在实际运行中，真正参与当前推理的往往是 views——摘要、索引、embedding 近邻、知识图子图、技能条目。它们会越来越像"系统真正知道的东西"。时间一长，views 就会冒充真相，系统慢慢活在自己的压缩和投影里，而不是活在证据链里。而这一问题不在于 views 不该存在——它们必须存在，因为 raw ledger 不能直接参与推理——而在于它们不能失去回指权威记录的义务（抽象和证据直接的关系非常重要，这是一大治理问题）。一旦一条摘要丢失了"这是从哪来的"和"原始证据是否还成立"的信息，它就不再是派生视图，而是一条没有来源的断言。
第三个问题是关于路径层。 现在很多系统已经很擅长建图、连边、找邻接、做 timeline、做 multi-hop 检索。但多数情况下，所谓的 path 仍然更像 recall edge 或者 topology convenience。它们能回答"这两个东西有关"，却没有真正回答：为什么这条联系成立？它何时生效？它会施加什么影响？它什么时候应该退场？它凭什么被系统承认？如果一条联系真的要影响执行，它就不能只是方便检索的边，而必须是一个被规定过存在方式和作用边界的结构。
第四个问题在于治理层。 Policy的含义落在在讲何时写入、何时检索、何时更新，现在已经有用 RL 来训练这种控制策略的系统出现了。但多数 policy 仍然主要聚焦在操作层面：什么时候读、什么时候写、读多少、怎么压缩。而我觉得可能还有一些也是需要关注的：谁能进入执行？谁只能提供证据？谁只能停留在候选状态？谁能影响当前姿态？谁能进入上下文？谁会在未来约束行动？也就是"执行资格"这个问题的真正展开。
把这四个问题放在一起看，我觉得可能我真正关心的，不是过去如何被组织起来，而是过去如何获得进入当前执行的资格。
一旦 Agent 开始长期工作，过去就不再是中性的历史。它会改变当前判断，改变工具选择，改变风险评估，改变默认姿态，改变哪些行为应当继续、暂停、确认或阻断。过去不是背景材料，而是一种会施加现实后果的力量。所以问题就不再是"过去有没有被保存"，而是"过去以什么身份发言"。
有些过去只是证据。有些只是候选结论。有些只能影响当前姿态。有些可以进入当前上下文。有些一旦进入执行就会变成规则。还有一些，即使被记住了，也不该直接发言。
这就是 Do-What Soul 的出发点：不是让系统更会记住过去（当然这也很重要，只是我精力有限），而是让过去以一种受约束、可校验、可纠错、可退场的方式，重新进入当前执行。
关于我的设计和架构概要
以下内容基本上是我在和AI去battle一些更形而上的问题之后，去落地工程实现的时候，慢慢搞清楚的。可能很快就没有价值了，所以先写一下和大家分享。
Soul 在我这里的定义是：一个让过去在当前以受治理、可校验、可投影、可收束的方式重新发言的长期执行记忆系统。
基本结构
三层：
- 记忆本体层回答：什么被长期承认
- 结构注册层回答：这些对象如何被定位、绑定、挂接到治理结构
- 运行控制面回答：这一轮如何装配、投影、核验、熔断与执行
四个正交轴：对象、路径、证据、治理。相互不可替代，不得互相冒充真源。
四条总纪律：
- 只有记忆对象属于本体；控制面对象不属于记忆本体
- Synthesis 负责组织理解，不直接立法
- ContextLens 只负责投影，不形成第二记忆层
- 后台只能产候选，不能静默产法
这个设计最重要的一点是关于边界的清楚划分，这对我后续写项目代码，真的非常重要。哪些东西可以存在但不能升格，哪些东西可以在运行时参与但不能被固化，都是被显式规定的。这也利于进行review，而不会出现大的偏差。
对象轴：先规定存在方式，再谈收纳
SOUL 的核心对象四类：
- EvidenceCapsule：可证明性来源。它不是默认显影内容，而是把长期对象与可核验来源绑定起来的东西。
- MemoryEntry：长期记忆的主承载体。维度是闭集：preference / constraint / decision / procedure / fact / hazard / glossary / episode。
- SynthesisCapsule：工作综合层，保存阶段总结、对比表、争议图、候选结论。它有稳定的哲学地位，但没有独立规范力——可以组织理解，不能直接立法。
- ClaimForm：把真正需要长期治理的判断投影成可比较、可仲裁、可审计的规则对象。Claim 不是"再保存一份正文"，而是把执行后果明确化。
这里有一个决策是fact 和 factual_policy 的硬边界。两者的区别不在于语言形式，而在于是否承担 durable execution consequence。只是描述项目、环境、工具或用户状态的，留在 fact；而如果一旦漏掉它会持续改变工具选择、写入许可、核验要求或冲突裁决，就必须升级为 factual_policy，进入更强的治理对象。这里的划分灵感来自于，我看《还原与无限》的时候，想到关于“目的”和“行为”的概念。我觉得所知能知和能动还是必须区分开的。
4月中旬的时候，我进一步把对象理解为"带分面的稳定语义单元"，也就是我觉得对象本身可以有更丰富的遗憾，而并非是固定不变的。也就是说，time、situation、risk、obligation 这些东西很多时候不是外挂标签，而是对象语义本身的一部分。一个未完成事项的 unfinishedness 是它之所以仍然需要发言的核心原因；某条风险记忆的情境适用性，是它之所以应该在某些时刻被唤起的理由。它们不是后缀说明，而是构成性的。
证据轴：从断言回到支撑关系
这一轴要解决的问题是：一条记忆凭什么还算数？
在很多现有系统里，memory 就是模型在某个时刻说过一句什么话，或者从某次交互中提取了一个 fact。但"它曾经被记录过"不等于"它现在仍然成立"。我觉得记忆不是断言，而是支撑关系——系统必须能够说明：这条东西为什么还算数。
EvidenceCapsule 因此包含了 semantic anchor（语义锚）、event anchor（事件锚）、physical anchor（物理锚）、provenance、stable digest、evidence health 等结构。证据健康的优先级是：语义锚 > 事件锚 > 物理锚。这意味着，文件路径失效（物理锚腐烂）不应自动让一条记忆蒸发——因为语义锚和事件锚可能仍然有效。但反过来，如果语义锚被击穿、事件不可审计，那这条记忆就必须进入真正的失稳区。
路径轴：这是我觉得现在工作最可以深挖的部分
前面说过，现有系统的 path 大多还是 recall edge 或 graph edge。我的努力是试图把 path 推进成可学习的条件联系结构。这也和我本人的毕业论文息息相关（感谢毕业论文，除了带给我痛苦外，还给我了一些灵感）。
一个最小的 PathRelation 在定义下必须至少回答六件事：
- anchors — 它联系的是什么
- constitution — 为什么这条联系成立（不是"它们 embedding 相近"，而是有没有语义上的理由）
- effect_vector — 一旦命中，会施加什么影响（是改变姿态？是提醒？是进入上下文？）
- plasticity_state — 它如何被强化、削弱、改向
- lifecycle — 它什么时候退场
- legitimacy — 它凭什么被系统承认
这里有一个重要的派生问题：condition 到底归谁管？我的设置是 condition 是跨三层的——有些 condition 属于 object facet（比如"这条记忆只在 Python 项目中适用"），有些属于 path constitution（比如"这条联系在用户主动要求时才成立"），有些属于 runtime evaluation（比如"当前 budget 是否允许"）。如果把它们都写成 path 上的一个字段，系统最后只会得到一堆临时 if-else。
故而我对路径的可塑性做了四种分类：reinforcement（重复支持，strength 上升）、weakening（忽略或失配，strength 下降）、redirection（方向系统性偏移）、retirement（因完成、否认、过窗、反证而退出活跃结构）。
同时，可塑性有热路径和整合循环的职责边界：热路径只允许轻量的即时记账（strength 微增、support_events_count 递增、时间戳更新）；任何涉及 anchors、relation_kind、why_this_relation_exists、governance_class 的变化，都必须走整合循环（Consolidation Loop），不得在热路径即时改写。
治理轴：谁有资格进入执行秩序
这一轴不是"让系统更谨慎"，而是明确回答"谁有资格参与执行"。
几个核心机制：
Slot 不是内容对象，而是治理席位。生成公式固定：governance_subject × claim_kind × scope_class。Winner 不是逐轮 argmax，而是带迟滞的席位秩序——incumbent 默认享有粘性，challenger 只有在新证据显著增强、显式 review 通过、连续多轮稳定压制、用户显式切换或原 winner 失效时，才允许翻盘。
用户纠错不是简单覆盖。系统先通过 session_override 修正当前轮，再通过 Promotion Gate 决定是否持久化。这意味着"用户说了一句话"不会自动变成长期规则——它先解决当前轮的问题，然后才有可能被承认为长期事实。
Green 生命周期不是"存进去就一直算数"。一条记忆进入 Green 之后，仍然会被 contest（新证据挑战）、verification fail（核验失败）、external invalidation（外部失效）、surface detach（绑定脱落）、mapping revoked（映射撤销）击穿。Green 是一种有条件的、可被逆转的执行许可，不是永久身份。
过去如何在当前轮发言
到这里，四个轴已经规定了对象的存在方式、证据的支撑关系、路径的联系结构、治理的资格秩序。但还差最后一步：这些东西如何在当前轮具体参与？
我的方案是：prediction 不是独立模块，而是 learned path 在当前轮的受治理显现。
具体来说，一条 path 在当前轮被命中后，不是立刻把关联对象塞进上下文，而是先进入一个叫 ActivationCandidate 的运行时控制对象。ActivationCandidate 是 turn-scoped 的，不持久化，不属于记忆本体。它结构化地记录了：命中了哪条 path、关联哪些 anchor、why_now、当前 effect_vector 快照、pressure/confidence、governance ceiling、默认显影偏好。
然后由显影层级决定它到底以什么方式参与当前轮：
- stance_bias（最弱显影）：作用于执行姿态和默认保守/激进倾向，不直接进入 ContextLens，也不一定在对话流中显式出现
- dialogue_nudge（中等显影）：一条流内提醒或受治理的 hint，不是把对象正文整块塞进 prompt
- lens_entry（最强显影）：只有在激活足够强、与当前任务强耦合、governance ceiling 允许、manifestation budget 允许时，才可升级
一个关键约束：ContextLens 仍然只做 current-turn selection。它不是第二记忆层，不应吞掉 reminder / hint / stance / projection 的全部职责。不要把 prediction 退化成"更早再 recall 一次"。
image1448×1086 318 KB
合法性的判断
所以总结来说，我做的事情是在 Ledger / Views / Policy 这种 Memory 系统闭环之上，继续追问一组更具体的问题，以期望去建立更为完整的系统合法性：
- 什么被承认为对象？什么只是证据？什么只是候选？
- 什么构成路径？这条路径凭什么成立，凭什么退场？
- 什么能影响执行？什么只能在当前轮发言？
- 什么可以被强化、削弱、改向？什么可以在后台整理？什么绝不能在后台静默立法？
同昨天，不知道说的清不清楚，但是目前是这样。
网友解答：--【壹】--：
btw，文字看出来应该大量GPT生成的，所以看起来很累，如果是AI生成的内容需要截图哦，不能直接copy，我个人建议佬可以做个博客一类的，或者github wiki，然后在LinuxDo这边丢简介 原文挂其他地方？
--【贰】--：
感谢佬的长文，就是看到一半注意力不够了看不太下去，佬下次发可以多一点图片嘛
--【叁】--：
就是实际上我这个架构已经落地完了，还在小修小补，最近在考虑怎么比较好的复述，和做测试。所以没有想好具体一个清晰的概念，去引导叙述逻辑。所以还在探索期。感谢评论，我这个也还得研究研究，我打算是先写了再看。
--【肆】--：
好的，让gpt多搞一点图片。感谢感谢，我也是摸索期，还没有完全搞清楚。
--【伍】--：
文字实际上我还大面积改写了一下，笑死。没有AI原文。我有一个自己博客，就是我自己区分了一些，东西发在哪里。这个是结合我项目的spec的内容写的。