Repository navigation
Replies: 4 comments 2 replies
1. 源码文件总览当前一共 7 个主要文件： facade.mjs
filters.mjs
index.mjs
merge.mjs
recall.mjs
service.mjs
test.mjs可以把它理解成四层：
2. 文件职责说明2.1
|
0 replies
|
我去这么复杂。等我阅读一下。。。 |
2 replies
抱歉，前面的路线有点复杂了，这个是整理后的 1. 唯一技术路线首版固定技术栈：
2. 组件职责2.1 memory-service负责统一对外接口。 固定职责：
2.2 memory-core负责核心业务逻辑。 固定职责：
2.3 PostgreSQL 主写库负责正式数据底座。 固定职责：
2.4 PostgreSQL 搜索节点负责检索。 固定职责：
2.5 embedding-worker负责向量处理。 固定职责：
2.6 RRF 融合层负责混合召回合并。 固定职责：
3. 首版固定数据对象3.1 memory_item主记忆表。 固定字段组：
3.2 memory_embedding向量表。 固定字段组：
3.3 memory_search_doc检索文档表。 固定字段组：
3.4 memory_audit_log审计表。 固定字段组：
4. 首版固定分区策略首版即分区，不允许后补。 固定规则：
固定要求：
5. 首版固定写入链路写入链路固定输出：
6. 首版固定检索链路首版固定支持：
首版固定过滤维度：
7. 首版固定生命周期链路7.1 删除
7.2 归档
7.3 embedding 重建
8. 首版固定部署结构8.1 服务层
8.2 数据层
8.3 同步层
9. 首版固定实施顺序M1建库与扩展：
M2建表与分区：
M3建索引：
M4搭主写链路：
M5搭 embedding 链路：
M6搭检索链路：
M7搭生命周期链路：
10. 当前下一步当前直接进入： 下一步 1输出正式 DDL：
下一步 2输出正式 migration：
下一步 3输出 recall API 草案：
|
我最新的路线，预计下周一会有结果。 |
|
好歹自己写下吧，一眼全是AI写的，表述太冗余了 |
0 replies
|
有相关 PR 么？没有的话请创建一个，可以 draft，以便我们审阅。在 PR 介绍中重新写一下你的想法和代码概述。 |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
这是我最近自己在试的一套 AIRI 记忆机制思路，目前还只是初步整理，不是定稿。
这两天边接边想，发现原来一些直觉上的做法可能不太对，所以想把现在想到的方向整理出来，听听大家有没有更合理的拆法、边界提醒，或者觉得哪些地方会有坑。
1. 当前链路的构思
1.1 已经确认打通的链路
当前
remember主链已经不是“没接上”，而是已经到达插件并拿到返回结果：memoryAlayaRememberapps/stage-tamagotchi/src/main/index.ts已能收到ipcMain.handle('memory-alaya:remember', ...)memory-alaya-plugin已导出：remembersearchrecalllistpluginInstance.remember(payload)[memory-alaya-plugin] remember called[memory-alaya-main] plugin remember result ...这说明：
remember 调用链路已经通了。
1.2 当前真正的问题
当前问题已经不再是“接不上插件”，而是以下 3 个更深层问题：
问题 A：当前主写入源是 assistant 回复，不是 user 原话
日志显示当前传给
remember的大量内容仍然是：role: 'assistant'kind: 'conversation'content: '记住啦，明天要去练车...'这会导致：
问题 B：当前 remember 仍由本地规则决定是否入库
现有 facade / filters / merge 仍然是“规则驱动”：
detectMemoryKind()shouldRemember()findMergeCandidate()rememberPreference()/rememberProject()这与当前重构目标冲突。
问题 C：当前 recall / search 还没有真正挂进“回答前的默认流程”
现在“记忆能力”虽然可调用，但还没有真正成为模型的默认工作流。
当前更像：
而不是：
2. 架构方向已经明确：去规则化，改成“模型决策 + 后端执行”
最终方向已经收敛，不再走“后端策略写死”的设计。
2.1 不再采用的旧思路
以下思路应视为淘汰：
shouldRemember()决定记不记detectMemoryKind()决定 preference/projectfindMergeCandidate()决定 merge2.2 现阶段确认的新思路
统一记忆池
不再拆“短期 / 长期”两个桶。
统一采用一个 memory store，核心依赖以下属性：
priority：服务于候选池排序tags：服务于检索time：服务于时间相关衰减status：控制 active / archived / deletedsource_role：区分 user / assistant / systemmetadata：附加信息标签的职责
标签不是分类展示用，而是检索入口。
例如：
scheduletomorrowdriving优先级的职责
优先级不是“长期 / 短期”的替代字段，而是：
谁更应该先进入候选池。
例如：
时间语义的职责
时间不是分桶字段，而是：
决定是否自然衰减。
3. 最终责任分工
3.1 大模型负责什么
大模型负责“决策”。
具体包括：
也就是说：
模型负责判断和选择。
3.2 后端负责什么
后端不再替模型做业务判断，只负责执行与数据能力。
具体包括：
也就是说：
后端负责执行，不负责拍板。
4. 必须新增的一层：Memory Bridge / 能力桥梁层
本轮确认的最关键结论之一：
大模型不会天然知道自己“可以记忆、怎么记忆、存什么格式、调用哪个接口”。
因此必须新增一个中间层，明确告诉模型：
这层不应该是一个写死函数，而应该是：
5. 模块能力层最终方案
5.1 能力层必须目录化
指定一个固定能力目录，例如：
每个能力模块一个子目录。
例如：
5.2 初始化规则
初始化时必须：
enabled: true，则模块必须能成功加载建议 manifest 结构：
{ "name": "memory", "enabled": true, "modulePath": "./index.mjs", "modelInstructionPath": "./model.md", "toolsPath": "./tools.json" }5.3 仅加载模块还不够，还要动态通知模型
程序 import 模块 ≠ 模型知道这些能力存在。
因此运行时必须额外做：
model.mdtools.json也就是说：
缺一不可。
6. 最关键的运行问题：如何让模型“主动用”这些能力
光告诉模型“你有 memory 能力”还不够。
真正的问题是：
为什么模型要主动用这个功能，而不是等用户显式触发？
本轮结论是：
6.1 不能把 memory 仅作为可选插件
必须把 memory 变成模型默认工作流的一部分。
不是：
而是：
6.2 必须增加“规划阶段”
在最终生成回答前，模型先输出一个动作判断。
示例：
{ "needMemorySearch": true, "needMemoryWrite": false, "needMemoryUpdate": false, "reason": "The current question likely depends on prior stored arrangements." }或者：
{ "needMemorySearch": false, "needMemoryWrite": true, "memoryCandidate": { "summary": "用户喜欢喝牛奶", "content": "用户偏好：喜欢喝牛奶。", "tags": ["preference", "drink", "milk"], "priority": 1 } }这一步由运行时拿来决定是否真正调用 memory 模块。
6.3 主动触发来源，不只靠用户显式要求
应至少支持以下触发源：
用户显式触发
语义自动触发
价值自动触发
流程自动触发
因此最终不是“用户触发 memory”，而是：
模型在规划阶段主动判断 memory 是否该参与。
7. 当前代码里哪些应该改：源码 vs 后端规则
下面按“文件层级”整理。
7.1 已经完成且暂时不要回退的源码
packages/stage-ui/src/stores/mods/api/context-bridge.ts当前已验证：
after-send能拿到完整文本当前建议：
apps/stage-tamagotchi/src/preload/index.ts当前已验证：
当前建议：
apps/stage-tamagotchi/src/main/index.ts当前已完成：
ipcMain.handle('memory-alaya:remember', ...)已能真实调用插件 remember但后续需要继续改：
remember7.2 需要重构的后端规则层（这是这次的重点）
这些文件才是本轮重构主战场。
facade.mjs当前问题：
detectMemoryKind()：写死 preference/projectbuildSummary()：本地规则摘要pickRowsForSystemPrompt()：按 kind 取 memoryrememberFromMessage()：本地直接判断是否 worth remember结论：
这层要从“规则层”改成“编排层”。
需要改成：
不应再自己拍板“记不记、是什么 kind、怎么 merge”。
filters.mjs当前问题：
shouldRemember()仍在本地决定“值得记忆”结论：
保留最小校验，删除业务策略。
建议改成：
validateMemoryInput()不要再判断：
merge.mjs当前问题：
isPreferenceMatch()isProjectMatch()findMergeCandidate()仍在使用硬编码规则决定 merge。
结论：
改成候选检索辅助层，不再自动 merge。
建议改成：
findMemoryCandidatesForDecision()index.mjs当前问题：
remember()中直接跑：shouldRemember()findMergeCandidate()inserted / merged / skipped结论：
要从“决策型入口”改成“执行型入口”。
建议把后端 API 重心改成：
createMemory(fragment)updateMemory(id, patch)archiveMemory(id)deleteMemory(id)searchCandidates(query, options)applyDecision(decision)不要再让
remember()自己替模型判断业务动作。service.mjs当前问题：
rememberFromUserMessage()仍然直接走 facade 规则判断recallMemoryContext()仍偏向“规则拼 prompt”结论：
改成 service orchestration layer。
建议职责：
recall.mjs当前问题：
结论：
这层可以保留为“候选池召回层”，但不要再冒充最终相关性判断。
建议改法：
prioritytagstime decay8. 数据模型怎么改
当前
memories表仍偏向旧设计：kindsummarytagsemotional_impactaccess_countis_archived建议逐步改造成统一记忆结构，至少增加或替换为：
priority REAL DEFAULT 0 status TEXT DEFAULT 'active' source_role TEXT source_type TEXT confidence REAL DEFAULT 0 metadata TEXT DEFAULT '{}' time_context TEXT DEFAULT '{}'说明：
priority候选池排序核心字段。
status例如：
activearchiveddeletedsource_role区分：
source_type区分：
confidence记录模型这次判断的可信度。
metadata扩展信息。
time_context存储时间语义，例如：
说明：
kind可以保留一段时间做兼容，但不建议再作为核心逻辑入口9. 新增文件建议
9.1 能力模块层
建议新增目录：
其中至少包含：
module.json声明：
model.md给大模型看的运行规则。
tools.json给运行时和模型看的工具 schema。
index.mjs真正的能力实现。
9.2 能力加载与注入层
建议新增：
module-loader.mjs职责：
capabilities/module-registry.mjs职责：
model-context-builder.mjs职责：
9.3 memory 编排层
建议新增：
memory-orchestrator.mjs职责：
memory-decision-schema.json定义模型输出结构，例如：
10. 建议的最终对话流程
10.1 写入流程
用户发消息
→ runtime 进入 planner 阶段
→ 模型判断是否要写 memory
→ 如需写入，先拿候选旧记忆
→ 模型输出 decision
→ 后端执行 insert / update / archive / delete / ignore
10.2 读取流程
用户发新问题
→ runtime 进入 planner 阶段
→ 判断是否需要 memory search
→ 后端返回候选池
→ 模型从候选池中筛选高相关记忆
→ 模型基于筛选结果生成最终回答
10.3 打开窗口时
打开窗口时不要全库加载。
建议只做：
其余内容按 query 实时检索。
11. 下一阶段执行顺序（建议照这个顺序做）
阶段 1：冻结旧链路，确认当前 remember 主链可回滚可保留
目标：
重点：
context-bridge.tspreload/index.tsmain/index.ts结论：
这三处当前先稳住，不再大改业务策略。
阶段 2：先改后端核心，不要先改 UI
目标：
优先修改：
filters.mjsmerge.mjsfacade.mjsservice.mjsindex.mjsrecall.mjs重点不是“修补规则”，而是“降级成执行层 + 检索层 + 编排层”。
阶段 3：补能力层
新增：
capabilities/module-loader.mjsmodule-registry.mjsmodel-context-builder.mjs让模块不仅能被程序加载，还能被动态通知给模型。
阶段 4：补 planner / orchestrator
新增：
memory-orchestrator.mjsmemory-decision-schema.json将 memory 真正挂入回答前默认流程。
阶段 5：再回头处理 user / assistant 写入源
最终应改成：
这一步不能忘，但建议放在新 orchestrator 成型后再落地。
12. 明确结论：这次主要改的是哪里
12.1 主要是后端规则与中间层，不是先改前端表现
这次的主战场不是 UI，而是：
也就是：
先改后端规则与中间层。
12.2 源码要改，但不是先去大量改聊天 UI
源码改动主要集中在：
facade.mjsfilters.mjsmerge.mjsindex.mjsservice.mjsrecall.mjscontext-bridge.ts/preload/index.ts/main/index.ts当前链路先保留，后续仅做接入升级。当前 remember 主链已打通到插件，不再是接线问题；真正要做的是把 memory-alaya 从“本地规则驱动记忆”重构成“模型决策、后端执行、统一记忆池、候选池检索、动态模块能力注入、回答前规划触发”的新架构。
All reactions