AIClaw 3.7.12：桌面端Agent记忆可检查可编辑

记忆中的偏好可能早已过时，项目换了测试框架、格式约定变了，旧的笔记反而误导 Agent。用户需要一个直接检查并修正记忆的入口。

AIClaw 在 v3.7.12 版本中把这份控制权交还给了用户：桌面设置的 Memory 页面支持全文编辑、单条目编辑和带确认的删除。这个功能面向 Electron 桌面应用及其文件型记忆，代码实现全部锚定在 v3.7.12 标签上。

两种记忆，两个作用域

Settings → Memory 展示两类保存内容：全局记忆（通常位于 ~/.aiclaw/memory.md）承载跨工作区的偏好与约定；工作区记忆（工作目录下的 .aiclaw/memory.md）保存项目专属笔记。

工作区选择器由已知会话填充并按工作目录去重，也可以只查看全局记忆。每份文档都显示来源路径和字节占用，让每一次编辑都有可见的落点。MemoryView 组件刻意把“文件不存在”和“读取失败”区分开——缺失的记忆文件可以通过编辑创建，读取错误则如实显示为错误，而不是伪装成空记忆。这个区分在排查“偏好为什么好像丢了”时很关键：不可读的文件和从未存在的文件，需要采取的行动完全不同。

小修小补，不破坏上下文

编辑器支持整篇文档修改，也支持单条目修改。条目边界规则刻意保持简单：以连字符或星号开头的行启动一个新条目，后续行归入该条目。这是文本分组，不是完整的 Markdown 文档模型。共享辅助函数在条目重新拼接时会保留原始文本。

举个例子：某条关于已废弃命令的项目笔记可以单独修正，前后的日期和多行笔记保持原样。删除条目会要求确认；删除最后一个条目会保存一个空文件，而不是删除记忆文件本身。

容量按 UTF-8 字节计算，单文档保存上限为 32 KiB，与桌面内核的记忆加载上限一致。多字节字符每个字符占用不止一个字节，所以界面会在启用保存按钮前计算完整候选文档的大小，宿主端还会再检查一次。这些文件是为短小的保留事实设计的，内核记忆实现中记录了这一用途和加载限制。

写入路径留在宿主端

渲染进程发送的是作用域、选定会话、新内容，以及它最初读到的内容/存在状态——它不负责选择任意目标文件名。主进程的 IPC 处理器从应用配置解析全局路径；工作区编辑则从归属的非归档会话解析工作目录，再拼接固定的记忆路径。非法作用域和缺失会话归属都会被拒绝。

这对桌面编辑器是一个值得借鉴的模式：把路径解析放在文件系统访问旁边，才能一致地做校验。

IPC（进程间通信） 是 Electron 架构中渲染进程（负责 UI）与主进程（负责系统级操作）之间的通信机制。渲染进程运行在沙箱化的浏览器环境中，出于安全考虑不能直接访问文件系统、网络套接字等系统资源；主进程则拥有完整的 Node.js 能力。因此，当用户在 Memory 页面点击保存时，渲染进程通过 ipcRenderer.invoke 把作用域、会话标识和新内容发送给主进程，主进程的 ipcMain.handle 处理器完成路径解析和文件写入后再返回结果。这种分工不仅满足安全边界要求，也让路径解析、快照校验、符号链接拒绝等逻辑集中在一处，避免渲染层被注入任意路径。文章强调“渲染进程不负责选择任意目标文件名”，正是这一架构约束的体现：目标文件路径只能由主进程根据可信的应用配置和会话归属推导出来，从而杜绝路径穿越类攻击。

替换文件前先发现过期编辑

记忆也可能在设置页面之外被改动。保存实现会把当前内容与编辑器提供的快照对比，不一致就保存失败并提示刷新。界面会保留草稿，让用户在取消、刷新、协调变更之前先复制出来。

写入之前，宿主还会检查受保护位置和规范化目录边界，拒绝符号链接形式的记忆文件，拒绝空字符和超限内容。它先在目标旁边临时目录写入临时文件，再次检查快照，然后把新文件重命名到位，最后清理临时目录。这是乐观并发检查，不是文件系统级锁或版本历史系统。重命名避免了暴露写了一半的替换文件，快照检查则捕获替换前观察到的变更。

乐观并发控制 是一种不加锁的并发策略：读取数据时记录一个快照（版本、时间戳或内容本身），写入前再比对当前值是否仍与快照一致，一致才允许提交，否则拒绝并让调用方处理冲突。它假设冲突不常发生，因而省去了文件锁的持有开销和死锁风险，代价是冲突发生时需要用户介入。文章中的实现正是这一模式：编辑器保存时携带“最初读到的内容”，宿主写入前重新读取文件并比对，不一致就返回冲突错误，界面保留草稿供用户复制。与之相对的悲观并发（如文件锁）会阻止其他进程在编辑期间修改文件，但在桌面应用中难以覆盖用户在外部编辑器中改动文件的场景。需要注意的是，乐观检查与“临时文件加重命名”解决的是不同问题：前者保证不覆盖他人已做的修改，后者保证替换动作本身原子、不会让读者看到半写状态。

保存状态不等于当前对话状态

设置页保存成功只更新磁盘上的文件，不会直接重建当前对话的系统提示词。按照文档化的桌面工作流，记忆是在打开或恢复会话时加载的。Memory 页面上的刷新是重新读取已保存文件，不是把记忆重新注入正在运行的对话。

实用流程是：检查正确的作用域，编辑或删除过期笔记，保存，然后打开或恢复应该使用新记忆的对话。这个页面描述的是已保存状态，而不是声称展示每个活跃会话当前加载的精确记忆快照。

系统提示词（system prompt） 是每次调用大语言模型时随对话一同发送的指令性文本，用于设定 Agent 的角色、行为准则和可用上下文。记忆文件的内容通常会被拼接进系统提示词，从而影响模型后续的每一次回复。关键在于，系统提示词是在会话建立或恢复时组装的，一旦对话正在进行，其上下文已经固定在模型侧；磁盘上的记忆文件发生变化，并不会自动改写已加载的提示词。这就是为什么设置页保存后需要“打开或恢复会话”才能让新记忆生效——恢复会话会触发一次重新组装，把最新的记忆文件读入新的系统提示词。理解这一点可以避免一个常见误解：用户以为在 Memory 页面保存后当前对话中的 Agent 会立刻改变行为，实际上它仍在使用旧快照，直到会话被重新加载。

验证覆盖了什么

公开的文件系统测试覆盖了缺失文件、读取错误、文本保留、UTF-8 容量、冲突、空文件保存和受保护路径；符号链接测试在 Windows 上被显式跳过。工作界面冒烟检查覆盖了作用域选择、刷新、纯文本显示、条目编辑、超限保存拦截、冲突后保留草稿、取消删除，以及工作区专属创建——它们使用真实的 Vue/preload 层配合模拟宿主响应。

标签化发布工作流已成功完成，包括测试、打包和发布任务；其工作流定义在 Linux 虚拟显示下运行桌面冒烟检查。这是有用的自动化证据，但并不能证明每个平台的本地文件系统行为都经过了人工测试。

对用户来说，改进是具体的：一条过时的记忆规则，现在有了可检查的来源、明确的作用域，以及桌面设置里直接的编辑路径。