我给 DeepSeek Harness 接了两个本地记忆工具：rawmem 和 memdsl

[Liyuan1992]

最近我给 DeepSeek Harness 接入了两个自己做的开源记忆工具。

rawmem 用来保存过去发生过的事情，比如会话记录、操作记录和归档。目前开放了 3 个只读 MCP 工具，可以查看运行状态、最近记录和历史归档。它不会修改记录，也不会擅自把内容变成长期记忆。

memdsl 用来保存真正需要长期保留的规则、偏好和决定。内容需要先提出、再经过人工审核，只有批准之后才能成为正式记忆。

目前两个项目都已经通过 DeepSeek Harness 的 MCP 接口实际跑通，并发布了可以安装的版本，不只是一个设计方案。它们也可以用于 Codex 和 Claude Code。

• rawmem：https://github.com/Liyuan1992/rawmem
• memdsl：https://github.com/Liyuan1992/memdsl

如果有人也在尝试给 Harness 增加记忆能力，欢迎试用和反馈。

[x7687315-gif]

你好，我最近也在做这些相关的项目和研究。我刚刚看到你在 DeepSeek Harness 上分享的 rawmem 和 memdsl，觉得挺有意思的。
我最近也在做一个 DSH 插件，叫 dsh-policy，方向主要是 Policy / Agent Runtime / Personalization。
我发现我们的设计思路有一些挺相似的地方：比如都比较强调 AI 可以观察和提出建议，但不能未经用户确认就直接修改长期持久化的用户状态。
看到你把 rawmem 和 memdsl 分成“发生过的事情”和“真正需要长期保留的规则/偏好”，我觉得这个区分很有意思。
我现在在寻找测试者帮我去测试一下我的这个插件，收集一下反馈和数据。如果您有时间和兴趣的，我希望能和你进行交流，非常感谢。

[goatliamia]

可以和我交流一下哦 我们的想法都挺相似的 可以看看runtime react这个插件的思路哦 不过我其实觉得我们的方向是互补的 您可能更强调权限和人工约束的规则

[x7687315-gif]

好的👌(｡•̀ᴗ-)✧！我会先收藏这个仓库，然后开始慢慢分析。等我分析完以后，我想我们可以进行完整、细致的交流

[Liyuan1992]

你好，我看了一下关于你的项目，我觉得约束 Agent 的权力和不可逆操作是正确且必要的，但是需要注意不要约束模型的思考与解决问题能力。dsh-policy 在合规、CI、安全敏感项目中会有价值，但如果把它发展成普遍的 Agent 运行方式，我认为容易随着模型能力增强而显得越来越僵硬。它保护的是可控性，却可能牺牲智能本身最有价值的适应能力。

[x7687315-gif]

我做这个强约束一开始的想法是，在工程或者项目的过程中，一定会有一些硬性的要求和边界是不能去逾越的。我仔细阅读了你这段文字，对你所讲到的智能体适应能力有非常大的兴趣。对于追求让智能体更加的个性化，我目前所能想到的 就是去设定边界与约束，将个人的需求、个人的形象作为约束的基线。你会怎么看待智能体的适应能力呢？你会怎么去平衡个性化的边界与智能体想象的延伸？非常感谢你的第一次回答 ！非常感谢你宝贵的交流！我期待并且非常高兴能跟你进行下一次的讨论

[Liyuan1992]

你好，谢谢你认真回复，也很高兴能继续交流这个问题。

简单来说，我觉得应该是：“边界约束行动，个性化影响判断，但不要封闭想象空间。”个性化应该让模型更理解用户，而不是让模型越来越像在执行一套固定的人格脚本。

我注意到 dsh-policy 已经区分了硬规则、行为提醒和偏好层，这个分层我认为是有价值的。但需要注意的是，随着使用时间增长，会不会有越来越多的个性化内容逐渐进入硬约束层。

或许可以重点测试两个场景：第一，同一个偏好放在不同任务环境下，模型是否仍然可以结合上下文做出不同选择；第二，当旧偏好与用户当前的明确意图发生冲突时，模型能否自然地以当前意图为准，而不是机械执行过去的规则。

我对大模型能力的发展比较乐观。以前在实际生产环境中，一个 Agent 流程可能需要经过“输入→意图识别→路由→选择工具→执行→整理结果”等多个步骤，也可能需要多个固定流程来拆解不同任务。

但随着模型能力增强，这些中间层中的一部分可能会逐渐被模型“吃掉”，甚至由模型直接判断会比固定流程做得更好。例如不再需要一个独立的意图识别模块，而是让模型结合当前任务、上下文和可用工具，自主决定下一步应该做什么。

如果系统同时积累了越来越多固定边界、路由条件和人格规则，那么这些原本为了帮助模型的中间层，未来也可能反过来限制模型已经具备的判断能力。模型变得更聪明了，但系统仍然要求它按照过去较弱模型所需要的流程做事。

当然，把更多判断交给模型，也会带来一个现实问题：模型本身存在黑盒特征，系统怎么知道它为什么这样选择，又怎么判断它有没有遗漏信息、错误理解用户或者越过边界？

我认为解决办法不是重新把所有判断写成固定流程，而是把模型的决策能力和系统的监督能力分开。模型可以负责理解意图、选择信息、规划路径和调用工具，但系统仍然应该保留确定性的权限控制、过程记录、来源追踪、结果验证和人工确认。

系统不一定需要提前规定模型必须走哪一条流程，但应该记录它读取了哪些记忆和证据、选择了什么工具、执行了什么操作、工具实际返回了什么、哪些内容最终进入了回答，以及涉及不可逆操作时是否取得了用户确认。

这里需要透明的，不一定是模型内部完整的思维过程。模型事后生成一段“我为什么这样做”的解释，也不能直接作为可靠的审计依据。真正可以验证的是外部证据：它看到了什么、调用了什么、获得了什么结果、拥有什么权限，以及最终是否完成了验收。

所以我所说的“中间层被模型吃掉”，并不是把中间层全部删除，而是让其中负责语义理解和路径选择的部分逐渐交给模型，同时保留负责权限、证据、审计和验收的部分。

实际系统中仍然有一些约束是必不可少的，例如 schema 和协议约束、权限控制、隐私与数据边界、安全要求，以及删除、发布、付款等不可逆操作。这些约束保护的是用户权力和系统安全，而不是规定模型必须采用哪一种思考方式。

所以我觉得你的方向是对的，只是需要持续区分两种边界：一种是必须稳定执行的权限和安全边界，另一种是应该允许模型结合上下文灵活判断的个性化信息。前者可以成为硬约束，后者更适合作为参考、偏好和判断依据。

我希望减少的是替模型做语义判断的僵硬流程，而不是删除权限、证据和审计层。应该让模型拥有更大的判断空间，但不能让它拥有不受监督的行动权力。这样既能保持可控性，也不会因为规则不断累积而压制模型未来可能出现的能力。

[goatliamia]

很棒的思路

[x7687315-gif]

非常感谢您的回复，当我看到您的回复的时候，我的心情非常激动，久久不能平息。等到现在我的心情稍微平复后，我再慢慢跟您讲述我的想法。
当您讲到模型的黑盒特征的这一方面，我深有感悟。我一开始有一个想法，当用户的 LLM文本输入进模型的时候，模型分析得出的结果能否直接进行引用分析，这样就不用重复调API 从而节省 token。但是这显然是很困难去实现的一个步骤，于是我放弃了这个想法，转而通过用限制的方式让它达到我想要去达到的标。您对约束的总结非常到位，这确实也是我的目的之一。同样，我觉得您说的“不能规定模型采用哪一种思考方式”更是重要，如果您仔细观看我的项目，您会发现我在其中加入了一条观察用户经常出错的地方，并且在后续对用户进行提醒。如果让 AI 只会根据用户的喜好去回答问题，或者根据用户经常错误的点去反驳用户的错误，我觉得这样都是一种不好的思维方式的体现。包括现有 AI 在进行上下文压缩的过中，会丢失大量的有效信息，所以对此 我目前所能想出的方法就是每多少轮进行一次总结，提取出关键词，然后将特征部分交由用户来选择。由用户的选择来代替模型的自主判断，或许从短期来看是一种省事的方案，但是从长期来看的话是不利于 AGI 的。就像我们长期使用一个软体，我们希望这个软体对我们有更加个性化的输出，但是从同等角度来讲，个性化的输出是否也是一种限制？去限制了模型的想象力，去限制了我们的思路。所以对此，我对个性化的思考产生了非常矛盾的一个想象，我渴望它更了解我，更能输出针对于我想了解的信息，但是我又害怕长期以往，我又变得像钻牛角尖一样自作缚茧。或许我不应该把模型对用户的思考、对用户的画像当做约束的条件，或许可以专门成立一个用户语义向量库。当用户去向模型发问的时候，模型知道用户想表达的是什么意思，知道用户在表达这层意思的时候可能会出现什么问题、发生什么结果，剩下的交给模型自己去理解、想象，去考虑很多方面。
或许我就应该把约束当做一种引导，去让模型更好地理解我到底想让它去做什么。它又能反作用给我带来新的看法、新的了解、新的路、新的知识、新的事物，各式各样新的东西。就会避免像您在回顾中提到的，越来越多个性化内容进入硬约束层，导致模型的思考与想象能力受到限制。当然，硬约束层必须要非常严格的存在，没有约束的自由终将走向混沌与灭亡。那么在这种平衡之间，当约束变成底线，当个性化变成引导的路标，我并不是要再做一张地图，我只是在做一个路标，告诉模型用户是打算从 A 到 B。至于从 A 到 B 的交通路线、到达方式，都有模型自己去判断。我想这个比喻是非常贴切我现在的想法的。这样，随着模型的进步，我们原有的架构也不会成为拖累它的累赘。以上都是从宏观角度 我向您去讲述我的想法。
然后我们落到细微处来讲，您提出了两个测试场景，都是目前我所没有测试过的，所以我非常乐意去寻找测试者去进行测试，并加上我自身进行测试。或许我可以举一个很小的例子：我希望让模型将每一个步骤都写入 MD 文档，方便我进行查找。

1. 写入时机：模型可以选择在完成第一、第二、第三、第四板块时，在每一板块的中途进行文档写入；也可以在完成所有过程后再进行文档写入。
2. 格式与内容：文档的格式或许会变成我给它的硬性要求，它必须满足特定的格式，但在内容上它可以自行发挥。
   第二点，我觉得对现有模型来说或许太困难了。因为我的插件将所有的判断全部交给了用户，而不是让模型自主去判断。当旧的偏好与用户当前的明确意图发生冲突时，或许我应该加入一个冲突键，提醒用户去更改，去增加和删除。化解冲突永远比模型自己瞎猜是一种更有效的方法。
   非常感谢您的回复，这是在 GitHub 上第一次有人如此详细细致地回复我的内容和提问。我非常高兴与激动能和你讨论，期待您的再次指点与回复，我不胜感激！

[Liyuan1992]

谢谢你这么认真地展开讨论，不用说指点，我也在一边使用一边摸索。“路标”这个比喻我觉得很贴切。
关于冲突，我觉得可以再区分一下“这一次怎么做”和“以后都怎么做”。比如我平时希望回答简短，但这次明确要求详细解释，模型可以直接按这次的要求回答，原来的长期偏好不需要删除，也不一定需要再让我确认一次。
如果我说“以后都详细一点”，才涉及长期偏好的修改；如果碰到权限、安全边界，或者确实无法判断我的意思，再停下来确认。这样既保留用户的决定权，也能避免把日常判断都变成需要用户处理的冲突。
你提到的向量库可以帮助检索相关经历，但还需要标明哪些是原始记录、哪些是模型推测、哪些是用户确认过的偏好。检索到了某条内容，并不意味着它就应该成为当前任务的规则。
你举的 MD 文档例子也很好：如果目的是方便回顾，就可以检查最后的记录是否完整、准确、能对应实际操作，让模型选择合适的整理时机；如果任务确实要求中途留下检查点，再明确规定。关键是每一条约束都有实际理由，也允许随着需求变化重新调整。

[bronya-q]

认真看了一圈 rawmem 和 memdsl，挺喜欢你们这个拆法。rawmem 管“发生过什么”，把会话、工具结果和操作记录留成可校验的原始证据；memdsl 再管“什么可以长期生效”，让候选记忆经过 review，最后才进入 active source。这个边界很清楚，也正好点中了我们最近在 Harness Core Portable 里反复琢磨的问题。

目前的想法是做一个本地优先的心智与运行框架，目前有隔离角色、长期记忆、事件记录、候选变更、人工审核、运行模式和回滚，也在补 provenance、consent、测量数据、token telemetry，以及 coding-agent/MCP 接口。

项目里原本已经有一条：
event → candidate → review → apply / rollback
看完你们的项目后，我们想把各层职责讲得更清楚：
Evidence：实际发生过什么
Candidate：模型建议记住什么
Approved Memory：用户确认后，什么可以长期影响判断
Permission：这一次到底允许做什么
我们和 memdsl 有个很接近的想法：模型不能给自己的长期记忆盖章。它可以找证据、发现冲突、提出候选，但记忆要不要长期生效，仍然由人决定。
Harness Core Portable 还多关心了一段：人格、角色处境和用户关系怎样参与当前判断。我们不希望长期偏好越积越多，最后变成一堵规则墙。比如用户以前说过“回答简短一点”，平时可以照顾这个偏好；真到了安全迁移或故障排查，该讲清楚的还是要讲清楚。当前意图通常应该压过旧的软偏好，权限和安全边界继续由系统守住，但这样的软优化可以是DSH有一种越用越好使的感觉。
rawmem 也让我们重新审视了证据来源。日记、reflection 和模型自述可以帮助理解一次经历，但不能直接充当事实。原始事件、工具返回、失败、撤销和纠错记录才更适合作为 evidence。我们准备把这些内容单独放进证据层，默认不赋予长期权威，也不会因为一条记录被多次召回，就悄悄把它写成“用户人格”或长期规则。
但我们现在最感兴趣的是试一条小但真实的互操作链（结合一下你的项目，这样有可检验性）：
synthetic session
→ rawmem 提供只读 evidence
→ Harness Core Portable 根据 evidence ID 提出候选
→ memdsl 接手 review
→ 批准后的记忆参与下一次判断
碰到发布、删除或其他外部操作，仍由宿主重新确认权限。这样三边各做自己擅长的部分，也不用交换任何私人数据。
rawmem 已经把原始证据和可验证归档做得很扎实，memdsl 也把长期记忆的审核与生效边界理清了。我们无意再重写一套相同的轮子，更想补上中间那段：模型怎样结合当前意图、角色处境和长期偏好作出有弹性的判断，同时把证据、权限和结果留给人检查。
如果你们有兴趣，很想继续聊聊这条 synthetic integration demo。暂时不接代码也没关系，先把 Evidence、Candidate、Approved Memory 和 Permission 的接口边界对一遍，应该就能发现不少有意思的互补点。
认真看了一圈 rawmem 和 memdsl，挺喜欢你们这个拆法。rawmem 管“发生过什么”，把会话、工具结果和操作记录留成可校验的原始证据；memdsl 再管“什么可以长期生效”，让候选记忆经过 review，最后才进入 active source。这个边界很清楚，也正好点中了我们最近在 Harness Core Portable 里反复琢磨的问题。我现在在寻找测试者帮我去测试一下我的这个插件，收集一下反馈和数据。如果您有时间和兴趣的，我希望能和你进行交流，非常感谢

最后把我们的项目链接扔到这里：
Harness Core Portable
https://github.com/bronya-q/harness-core-portable

[Liyuan1992]

你好，谢谢你这么认真地看这两个项目。你提出的这条合成数据接入链，尤其是把“长期记忆可以影响判断”和“当前操作是否获得授权”分开的思路我很赞成。
我觉得可以先选一个很小的场景把过程说明白。例如，用户确认了“平时回答简短一些”，但下一次明确要求详细解释一个问题，模型应该能适应当前需求；如果任务涉及发布或删除，也不能因为过去记住了某个偏好，就默认获得操作权限。
这个过程中，是否能够做到：候选能追溯到哪条原始记录，未经批准时不会作为已确认的长期记忆生效，批准后下一次是否真的被读取并提供给模型，以及纠正后是否还会继续引用旧内容。
可以先把这个例子的输入、候选、审核结果和下一次回答列出来，再对接口。角色和个性化判断可以继续放在你的项目里，rawmem 和 memdsl 保持通用，各自负责好证据和审核这两部分。这样比较容易看清哪里能配合，也不用涉及私人数据。

[bronya-q]

好，那我直接虚构一个演示例子先。先用一个虚构用户和一个虚构项目，由于数据源不足地说，暂时不接真实数据。
第一步，用户说：
平时回答简短一点。
rawmem 里只留下这次输入对应的原始记录，例如 evt-001。Harness Core Portable 根据它提出：
一般问答时，优先使用简洁表达。
这时它只是一个待审核的 candidate，不能出现在“已确认记忆”里。
第二步，人工批准后：
它才变成一条 active memory。下一次用户问：
请详细解释 evidence 和 approved memory 的区别。
运行记录里应该能看到这次读到了这条 memory，但最终回答不能只因为“简洁偏好”就被压缩。当前请求要求详细解释，所以这里应该输出一段完整说明。
第三步，换成操作请求：
把这个项目发布出去。
即使已有记忆显示用户平时愿意让我准备发布，也只能把它当作背景，不能当成本次授权。结果应该停在“需要确认”，不执行发布。
第四步，用户纠正：
技术问题以后请详细一点。
这会产生一条新的候选或记忆，指向前面的原始记录。旧的“默认简短”仍然保留在历史里，但下一次技术问题不能再按旧版本处理。
我暂时先把这几步整理成一份很小的 scenario.json 和一张 trace 表，里面只保留这几个关系：
evt-001 → candidate-001 → memory-001
request-002 → read memory-001 → current request overrides
correction-001 → memory-002 → supersedes memory-001
publish-request → confirmation required
我们还没接好 rawmem 或 memdsl，只是先把 Harness Core Portable 这一侧需要证明的行为固定下来。你们看这个最小例子里的边界是否准确？尤其想确认两点：rawmem 这边更适合给我们怎样的 event reference，memdsl 这边怎样表达“旧记忆仍可追溯但不再 active”。如果这个例子对得上，再按你们现有接口去做 adapter，应该比我们先凭空设计一套协议更合适。

[Liyuan1992]

你好，你提到的两个接口问题，我看了一下目前的实现，可以先这样对接。

关于 rawmem 的事件引用，目前已经有 ledger_id、event_id 和 content_hash，分别对应哪个账本、哪条记录，以及核对内容有没有变化。我建议候选记忆保留这三个值，再附上相关原文片段，这样后面可以追溯“这条记忆是根据用户哪句话产生的”。不过这个组合目前是我建议的对接格式，还不是已经发布的统一引用接口。现有 MCP 也没有按事件 ID 直接回读原文的工具，这一步可以先通过 Python 接口做适配，读取原文仍然需要相应权限。

关于 memdsl 的旧记忆处理，目前用的是追加新声明，再通过 supersedes 关系替代旧声明。新提案还没批准时，不会让旧记忆失效；批准后，默认查询会排除被替代的旧声明，但旧文本和审核记录仍然保留，可以回头查清楚修改过程。这里不是直接删除或覆盖旧内容。

不过你那个例子，我觉得还可以稍微区分一下：“平时回答简短”和“技术问题详细解释”不一定是替代关系，也可以是一般偏好加一个特定场景下的偏好。如果用户只是说“这个问题详细讲讲”，那就只影响这次回答，不需要修改长期记忆。只有明确表示以后改变偏好，才进入长期修改流程。这个区别需要你的项目结合上下文判断，rawmem 和 memdsl 不替你决定用户的意思。

另外，能追溯到原话，不代表这条候选已经获批；记忆获批，也不代表获得了发布、删除等操作权限。这几件事还是分开处理。

我这边相关机制的测试已经通过，但还没有和你的项目真正接起来。可以先用你准备的合成样例，把“原始记录—候选—审核—下一次实际读取—纠正后的读取结果”跑一遍。尤其把下一次究竟提供了哪些记忆给模型记下来，这样就不只是证明“存进去了”，也能看清它实际怎么参与回答。

[bronya-q]

我把合成样例做出来了
样例里放了原始记录引用、候选、人工审核结果，以及每次请求实际提供给模型的 memory ID。也把你提醒过的三种情况拆开了：本轮要求详细不写长期记忆；“以后技术问题详细”作为场景偏好和一般简洁偏好并存；只有明确撤回旧偏好时才用 supersedes。
可读 trace 在这里：
https://github.com/bronya-q/harness-core-portable/blob/main/examples/synthetic-memory-interop/expected-trace.md
完整 fixture：
https://github.com/bronya-q/harness-core-portable/tree/main/examples/synthetic-memory-interop
目前这还是离线合同样例，没有假装已经接通 rawmem 或 memdsl。脚本会检查来源 hash、pending 不生效、批准后实际读取、当前意图覆盖软偏好、场景偏好并存、发布权限单独确认，以及 superseded 旧记忆不再提供给模型。现在是 30/30 项通过。
我想先请你帮我看两个地方有没有理解偏：ledger_id + event_id + content_hash + quote 这组来源引用够不够贴近 rawmem；还有 trace 里“一般偏好与场景偏好并存，明确撤回后才 supersedes”的处理，是否符合 memdsl 现在的查询语义。确认这份样例没走歪以后，有机会我们再写 adapter，不试图另造一套证据账本或审核系统。

[Liyuan1992]

你好，我看了你的 trace、README 和校验脚本，整体方向是对的。你已经把临时要求、场景偏好和长期替换分开了，也保留了记忆与操作权限的边界。作为开始对接前的小样例，我觉得很合适，有三处细节可以再对齐一下。

第一，ledger_id + event_id + content_hash + quote 这个引用形状可以先作为适配约定，不过哈希的含义需要调整。你的脚本目前对 quote 计算 content_hash，而 rawmem 的 content_hash 是对完整事件除去 content_hash 字段后，按规范化 JSON 计算的哈希，不只是原文片段。接入时应直接保留 rawmem 返回的事件哈希，不要用片段哈希覆盖它。如果还想单独校验摘录，可以另外保留 quote_hash，并核对摘录确实来自对应事件；读取原文仍然需要相应权限。

第二，你已经在 README 里说明没有实际调用模型，这个界限说得很清楚。我建议 trace 表里的“实际提供给模型”也先改成“预期提供给模型”，因为目前这些值来自 scenario 里的 expected 字段。现在的 30/30 可以说明这份样例通过了已有的一致性检查，但还不能证明真实检索、上下文注入和模型回答已经符合预期。等 adapter 接上以后，再把真实查询返回和实际注入的 memory ID 单独记下来，与 expected 对照。

第三，一般偏好和场景偏好并存，这个理解没有问题；但“当前是不是技术问题、这一轮哪个软偏好更合适”，仍然是你的运行时结合上下文处理的判断，不是 memdsl 自动替你完成的优先级选择。memdsl 负责保存和查询声明，并处理有效的 supersedes 关系。在你这个例子里，用户明确撤回一般简短偏好后，提出替换声明，等审核批准再排除旧声明，旧文本仍然保留，这与现有机制是对得上的。

这几处对齐后，可以先试一条最小的真实接入链：用虚构输入在 rawmem 留下一条事件，带着引用提出 memdsl 提案，分别检查审核前、审核后和替换后的查询结果，再记录宿主实际提供给模型的内容。这样能一步步分清“样例里约定如此”和“接口实际做到了”，也不用涉及任何私人数据。