oh-my-pi memory_edit 工具:按 id 更新、遗忘与失效 Mnemopi 长期记忆
发布时间:2026/9/10 13:02:45 锦皓数字建站

oh-my-pi memory_edit 工具按 id 更新、遗忘与失效 Mnemopi 长期记忆【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pimemory_edit是 oh-my-pi 中 Mnemopi 记忆后端的写路径工具当 Agent 通过recall拿到一条记忆并发现其内容过期、错误或不再需要时可以用它按id精确地更新update、硬删除forget或软失效invalidate这条记忆。读完本文你将掌握该工具的注册条件、输入输出契约、三种操作的适用边界、与memory://id全量读取的配合流程以及它在源码中跨银行去重查找的实现机制从而避免把被截断的召回预览误当作完整内容而覆盖掉记忆尾部。工具定位与注册条件memory_edit的实现在 MemoryEditTool面向模型的提示词定义在 prompts/tools/memory-edit.md底层写操作由 MnemopiSessionState.editScopedMemory 完成。注册与可见性有几个关键约束仅在后端为 Mnemopi 时注册MemoryEditTool.createIf(session)读取session.settings.get(memory.backend)只有值恰好为mnemopi时才构造工具否则返回null。也就是说当memory.backend为off、local、hindsight以及sharpshooter时该工具根本不存在于工具列表里。这个后端选择器在 settings-schema.ts 中定义默认值为off可在 Settings → Memory 页或~/.omp/config.yml中修改。元数据approval read、strict true、loadMode discoverable——注意它虽然标记为 read 级别的审批但成功的调用确实会修改本地记忆库。工具列表中的呈现在无限制的会话里显式列出工具时注册流程会自动为 Mnemopi 补上memory_edit受限的工具列表则不会被扩宽。在普通的tools.xdev会话中可发现的内置工具可能以xd://memory_edit形式呈现而显式请求的工具保持顶层形式。执行模型执行是同步、单次的没有进度回调或取消参数。在工具注册表中它与其他记忆工具并列注册于 tools/index.tsretain、recall、reflect等同样只在对应后端下可用。输入参数工具的参数 schemamemory-edit.ts如下字段类型必填说明opupdate \| forget \| invalidate是要应用的编辑操作。idstring是recall返回的记忆 id。contentstring否update时用于替换的记忆文本。importancenumber否update时用于替换的重要性会被钳制到0..1。replacement_idstring否invalidate时记录的接替者记忆 id。两个在调用前就需要注意的校验点源码中在真正触达后端之前抛出update必须至少提供content或importance之一否则直接抛错memory_edit update requires content or importance.importance若在0..1之外不会被拒绝而是先钳制再传入后端Math.max(0, Math.min(1, params.importance))。另一个重要限制id必须直接给出该工具不支持按内容搜索。要找到 id应先使用recall工具召回结果的内容预览默认截断在 500 字符以内尾部…表示截断full_length给出原始长度。输出契约返回结果为标准的AgentToolResultcontent[0].type textdetails原样透传后端结果{ status, bank?, store? }成功变更渲染为Memory id updated|deleted|invalidated in bank bank (store).未找到或操作不适用渲染为Memory id was not found...这是正常结果status 为not_found不是抛错**fact 行只读事实**渲染为Memory id is a read-only fact...; it cannot be edited. Read it with memory://id.同样是正常结果status 为not_editable。details.status的取值为updated | deleted | invalidated | not_found | not_editable当解析到具体行时还会带上storeworking | episodic | fact和bank。因此程序化处理该工具结果时应当检查details.status而不是依赖文本措辞。执行流程与底层查找机制源码层面state.ts的执行链路为MemoryEditTool.createIf(...)仅在memory.backend mnemopi时暴露工具execute(...)通过session.getMnemopiSessionState()获取本会话的 Mnemopi 状态若后端未初始化则抛错Mnemopi backend is not initialised for this session.——这处理的是工具被暴露但会话状态缺失的边界情况对update做content/importance非空校验并对importance钳制到0..1调用state.editScopedMemory(op, id, { content, importance, replacementId })。editScopedMemory的核心逻辑是按顺序跨多个目标银行查找同一 id先构造去重后的目标序列——retain 目标、各 recall 目标、可选的 global 目标retain 与 global 可能指向同一库实例因此用 dedupeScopedTargets 按 bank 去重然后逐个库memory.get(id)查找返回值遵循三级优先级返回第一个成功且可编辑的结果updated/deleted/invalidated否则返回第一个解析到但不可操作的结果如 fact 行 →not_editable或 episodic 行碰上update/forget→ 带 bank/store 定位信息的not_found全部未命中则返回无定位信息的not_found。各操作在后端的实际落点也不同update调memory.update(id, content, importance)forget调memory.forget(id)invalidate调memory.beam.invalidate(id, replacementId)。行属于哪个 store 由库表中的memory_store字段判定episodic或fact保留原值其余一律视为working。三种操作的语义边界操作作用范围语义update仅 working 记忆整体替换文本和/或重要性是整体替换而非打补丁。forget仅 working 记忆永久硬删除该行。invalidateworking 与 episodic 记忆软失效/被接替可记录replacement_id指向新记忆。由此产生的边界行为对 episodic id 执行update或forget会返回not_found且附带 bank/store 位置信息——因为这两种操作只支持 working 记忆fact 行对所有操作一律返回not_editablefact 行是事实抽取的只读投影源码注释标注 issue #4725可以被解析和读取但memory_edit的任何操作都不会改动 facts 表。recall结果中标记[facts]的就是这类 id应改用read memory://id检视策略建议同样写在模型提示词中对于历史仍有价值但内容已过期的 working/episodic 记忆优先invalidate只有当一行 working 记忆确实需要硬删除时才用forget。副作用文件系统会修改本地 Mnemopi SQLite 数据库中解析到的那一行命中的可能是 retain、recall、shared或安全发现的 legacy 银行。网络无。编辑操作不调用任何 embedding 或抽取服务——即使 Mnemopi 后端配置了本地 embedding 子进程memory_edit也不经过它。会话状态只读取当前会话作用域内的 Mnemopi 状态不会重写已经注入上下文的memories内容——已注入的上下文在下一轮召回时才会反映变更。与memory://id读取的配合关键工作流这是文档中最强调的一点也是防止数据损坏的核心规范每次update之前必须先read memory://id读取完整行。把被截断的召回预览复制进content会把未见过的尾部内容删掉。其原理链是recall的预览会截断内容500 字符上限truncated: truefull_length标记原长而update是整体替换。若直接把预览文本当content传进去等价于用前 500 字符覆盖整条记忆尾部全部丢失源码注释中对应 issue #4443。memory://idURL 正是为此设计的读取通道它由 internal-urls/memory-protocol.ts 处理最终走 MnemopiSessionState.getScopedMemory——与editScopedMemory完全同序地跨 retain/recall/global 目标查找保证读到的行就是编辑将触及的行返回完整content、importance、source、timestamp、created_at等全字段。正确流程是recall搜索得到目标 id 与截断预览read memory://id获取完整行将新内容 原尾部中仍需保留的部分合并成完整文本以合并后的全文作为content调用memory_edit update。两个补充限制行必须存在于当前会话作用域的银行中若某行只被另一个活动会话持有则不可达read memory://id会抛Mnemopi memory id not found in the calling sessions scoped bank在memory.backendhindsight下memory://寻址不可用Hindsight 记忆在服务端该协议处理器会返回指向recall/reflect的纠正提示。错误行为速查场景行为工具已暴露但会话未初始化 Mnemopi 状态抛错Mnemopi backend is not initialised for this session.update未带content也未带importance抛错memory_edit update requires content or importance.在任何后端写入之前id 不存在正常结果details.status not_found无 bankupdate/forget命中 episodic 行正常结果not_found bank/store 定位命中 fact 行任意操作正常结果details.status not_editableimportance超出0..1不报错钳制后生效总结memory_edit是一个刻意保持窄而精确的维护工具它只接受recall给出的 id、只做单行变更、绝不搜索、绝不联网并且把找不到和不可编辑都表达为带诊断信息的正常返回而非异常方便 Agent 在同一轮内自纠。理解它的三个前提能覆盖绝大多数使用问题注册依赖memory.backend mnemopiupdate/forget只作用于 working 行任何update之前先read memory://id取全文再整体替换。配套源码入口为 packages/coding-agent/src/tools/memory-edit.ts 与 packages/coding-agent/src/mnemopi/state.ts提示词全文在 packages/coding-agent/src/prompts/tools/memory-edit.md。【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
锦
锦皓数字建站
深耕本土企业品牌数字化升级,专注原创端正雅致商务官网,从视觉设计到稳定运维全程保驾护航。