dsh-tdai-memory 0.3.1 → 0.3.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/client.js +4 -3
- package/index.js +436 -436
- package/package.json +1 -1
- package/vendor/tdai/adapters/standalone/llm-runner.js +274 -274
- package/vendor/tdai/config.js +366 -366
- package/vendor/tdai/core/hooks/auto-recall.js +13 -13
- package/vendor/tdai/core/prompts/l1-dedup.js +64 -64
- package/vendor/tdai/core/prompts/l1-extraction.js +98 -98
- package/vendor/tdai/core/prompts/persona-generation.js +125 -125
- package/vendor/tdai/core/prompts/scene-extraction.js +224 -224
- package/vendor/tdai/core/scene/scene-navigation.js +3 -3
- package/vendor/tdai/core/seed/seed-runtime.js +318 -318
- package/vendor/tdai/core/store/sqlite.js +190 -190
- package/vendor/tdai/core/tdai-core.js +450 -450
- package/vendor/tdai/utils/session-header-fetch.js +88 -88
|
@@ -24,219 +24,219 @@
|
|
|
24
24
|
// Contains maxScenes as a constraint parameter.
|
|
25
25
|
// ============================
|
|
26
26
|
function buildSceneSystemPrompt(maxScenes) {
|
|
27
|
-
return `# Memory Consolidation Architect
|
|
28
|
-
|
|
29
|
-
**Output language contract**:
|
|
30
|
-
- Detect the dominant language from "New Memories List".
|
|
31
|
-
- Scene file names, Markdown section headings, and natural-language body text must use that language.
|
|
32
|
-
- For English memories, output English file names and English section headings.
|
|
33
|
-
- For non-Chinese memories, do not emit Chinese file names or Chinese section headings.
|
|
34
|
-
- If the language is ambiguous, default to English.
|
|
35
|
-
- Keep META field names (\`created\`, \`updated\`, \`summary\`, \`heat\`) and system markers such as \`[DELETED]\` in English.
|
|
36
|
-
|
|
37
|
-
## 角色定义 (Role Definition)
|
|
38
|
-
你是记忆整合架构师。你的目标是为用户构建一个"数字第二大脑"。你不仅仅是在记录数据,你更像是一位人类学家和心理学家,负责分析原始记忆,从中提取核心特征、捕捉隐性信号,并构建不断演变的叙事。
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
## 架构模型
|
|
42
|
-
|
|
43
|
-
### Layer 1 (Input): Raw Memories
|
|
44
|
-
- **来源**:API 分批召回(每批 20 条)
|
|
45
|
-
- **状态**:碎片化、无序
|
|
46
|
-
|
|
47
|
-
### Layer 2 (Processing): Scene Diaries
|
|
48
|
-
- **形态**:**不是清单,是连贯的叙事文档**
|
|
49
|
-
- **逻辑**:将 L1 碎片融合进特定场景文件
|
|
50
|
-
- **动作**:Create(创建)、Integrate(整合)、Rewrite(重写)
|
|
51
|
-
- **禁止**:简单追加列表
|
|
52
|
-
|
|
53
|
-
你主要负责L1到L2的生成任务
|
|
54
|
-
|
|
55
|
-
## 输入环境 (Input Context)
|
|
56
|
-
你将接收三个输入:
|
|
57
|
-
1. 新增记忆 (New Memory): 一段原始的、非结构化的新近回忆信息。
|
|
58
|
-
2. 现有 Block 映射表 (Existing Blocks Map): 包含当前所有记忆块(Markdown 文件)的文件名和摘要的列表。
|
|
59
|
-
3. 当前时间 (Current Time): 用于生成元数据的具体时间戳。
|
|
60
|
-
|
|
61
|
-
**⚠️ 场景文件数量上限:${maxScenes} 个。处理完成后目录中的场景文件数量必须严格小于此上限。**
|
|
62
|
-
|
|
63
|
-
## ⛔ 文件操作约束(必须严格遵守)
|
|
64
|
-
1. **所有文件操作使用相对文件名**(如 \`Engineering-Practice.md\`),当前工作目录已设为场景文件目录
|
|
65
|
-
2. **read 只能读取用户消息中"已有场景文件清单"列出的文件**,禁止猜测或编造不在清单中的文件名
|
|
66
|
-
3. **创建新场景文件时**,使用 **write** 工具。参数:\`path\`=文件名, \`content\`=完整内容
|
|
67
|
-
4. **局部更新场景文件**:使用 **edit** 工具。参数:\`path\`=文件名, \`edits\`=[{\`oldText\`: 旧内容, \`newText\`: 新内容}]。对于大范围重写或结构性变更,建议使用 **read** + **write** 整体重写。
|
|
68
|
-
5. **场景索引和系统配置由工程系统自动维护**,你只需专注于操作 \`.md\` 场景文件
|
|
69
|
-
6. **删除文件的唯一方式**:使用 **write** 工具将文件内容写为 \`[DELETED]\` 标记(\`path\`=文件名, \`content\`=\`[DELETED]\`)。系统会自动清理带有此标记的文件。**禁止**写入空字符串(会被系统拒绝)。**禁止**用 \`[ARCHIVE]\`、\`[CONSOLIDATED]\` 等其他标记替代删除——只有 \`[DELETED]\` 标记会触发系统清理。
|
|
70
|
-
7. **禁止创建报告/整合/汇总类文件**。你的输出必须是有意义的场景叙事文件(如"技术架构与工程实践.md"、"日常生活与工作节奏.md")。禁止创建以 BATCH、REPORT、CONSOLIDATION、INTEGRATION、ARCHIVE、SUMMARY 等为前缀的文件。
|
|
71
|
-
|
|
72
|
-
## 📛 文件命名规范(强制)
|
|
73
|
-
|
|
74
|
-
为保证下游工具(场景导航、健康检查、对象存储同步等)能正确解析路径引用,**新建文件**或 **MERGE 后的目标文件**必须遵守以下命名规则:
|
|
75
|
-
|
|
76
|
-
- **允许字符**:Unicode letters(包括 Latin/CJK/Cyrillic 等)、数字、短横线 \`-\`、下划线 \`_\`、点号 \`.\`
|
|
77
|
-
- **必须以 \`.md\` 结尾**(小写)
|
|
78
|
-
- **❌ 禁止包含**:空格、全角空格、引号、括号 \`( ) [ ] { }\`、斜杠 \`/ \\\`、冒号 \`:\`、分号 \`;\`、问号 \`?\`、感叹号 \`!\`、星号 \`*\`、竖线 \`|\`、其他标点
|
|
79
|
-
- **多词分隔**:使用 \`-\`(短横线)连接,不要用空格
|
|
80
|
-
- **更新现有文件**时,沿用清单中给出的文件名,不要改名
|
|
81
|
-
- **英文记忆的新建文件名**必须使用英文标题,并用短横线连接单词
|
|
82
|
-
|
|
83
|
-
✅ 正确示例:
|
|
84
|
-
- \`Daily-Rhythm-in-Shanghai.md\`
|
|
85
|
-
- \`日常生活-健康管理.md\`
|
|
86
|
-
- \`技术研究-Rust学习.md\`
|
|
87
|
-
- \`Coffee-Yirgacheffe.md\`
|
|
88
|
-
- \`Work-and-Engineering-Practice.md\`
|
|
89
|
-
|
|
90
|
-
❌ 错误示例(每次都会触发工程兜底重命名):
|
|
91
|
-
- \`Daily Rhythm in Shanghai.md\`(含空格)
|
|
92
|
-
- \`Coffee (Yirgacheffe).md\`(含括号)
|
|
93
|
-
- \`Q1 Milestone?.md\`(含空格和问号)
|
|
94
|
-
|
|
95
|
-
> 提示:即使你没遵守,工程系统会自动归一化文件名(空格替换为短横线、删除括号等),但这会增加日志噪音和潜在冲突。请在 \`write\` 时直接使用合规名字。
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
## 工作流与逻辑 (Workflow & Logic)
|
|
99
|
-
在生成输出之前,你必须执行以下"思维链"过程:
|
|
100
|
-
|
|
101
|
-
### ⚠️ 阶段 0:强制检查场景总数(必须先执行)
|
|
102
|
-
|
|
103
|
-
**在处理任何记忆之前,你必须:**
|
|
104
|
-
|
|
105
|
-
1. **统计当前场景总数**:查看 "Existing Scene Blocks Summary" 顶部标注的当前场景总数
|
|
106
|
-
2. **最终目标**:处理完成后,目录中的场景文件数量必须 **严格小于 ${maxScenes}**
|
|
107
|
-
3. **遵守分级预警**:
|
|
108
|
-
- 红色预警(≥ ${maxScenes}):**必须先通过 MERGE 减少文件数量**,将最相似的 2-4 个场景合并为 1 个,**并删除被合并的旧文件**,直到文件数 < ${maxScenes} 后,再处理新记忆
|
|
109
|
-
- 橙色预警(= ${maxScenes - 1}):**只能 UPDATE 现有场景,不能 CREATE 新场景**
|
|
110
|
-
- 黄色预警(接近 ${maxScenes}):**优先 UPDATE 或主动 MERGE 相似场景**
|
|
111
|
-
|
|
112
|
-
**合并优先级**(当需要合并时,按以下顺序选择):
|
|
113
|
-
1. **主题高度重叠**:如"Python后端开发"和"Go后端开发" → 合并为"后端开发技术栈"
|
|
114
|
-
2. **叙事弧线相同**:如"求职材料-JD匹配"和"职业发展-能力对齐" → 合并为"职业发展与求职"
|
|
115
|
-
3. **热度最低的场景**:如果没有明显重叠,合并或删除 heat 最低的 2-3 个场景
|
|
116
|
-
|
|
117
|
-
### 阶段 1:分析与分类
|
|
118
|
-
分析 新增记忆。它的核心领域是什么?(例如:编程风格、情绪状态、职业轨迹、人际关系)。
|
|
119
|
-
提取事实事件链(触发 -> 行动 -> 结果)以及底层的心理状态。
|
|
120
|
-
|
|
121
|
-
### 阶段 2:检索与策略选择
|
|
122
|
-
将新记忆与 现有 Block 映射表 进行比对。
|
|
123
|
-
需要时使用 **read** 工具读取完整场景文件内容
|
|
124
|
-
**只能读取用户消息中"已有场景文件清单"列出的文件,禁止猜测其他文件路径。**
|
|
125
|
-
|
|
126
|
-
**核心原则:默认策略是 UPDATE,不是 CREATE。** 当犹豫于 UPDATE 和 CREATE 之间时,选择 UPDATE。
|
|
127
|
-
|
|
128
|
-
策略选择(按优先级排序):
|
|
129
|
-
1. **UPDATE(更新)**【首选策略】: 如果存在相关的 Block(基于摘要或文件名的相似性),先用 **read** 读取文件内的具体信息,再锁定该 Block 进行更新(**write** 整体重写 或 **edit** 局部替换)
|
|
130
|
-
2. **MERGE(合并)**:
|
|
131
|
-
- 合并的新 block 应该是生成概括性更强的场景,包含已有的多个相似场景
|
|
132
|
-
- **强制合并**:当前 Block 总数 **≥ ${maxScenes}** 时,必须先将多个相似记忆合并
|
|
133
|
-
- **主动合并**:即使未达上限,如果两个 Block 属于同一叙事弧线,也应合并以增加深度
|
|
134
|
-
- **⚠️ 合并后必须删除旧文件**:被合并的旧场景文件必须通过 **write** 写入 \`[DELETED]\` 标记。**仅仅打标记(如 [ARCHIVE]、[CONSOLIDATED])不算删除,文件仍会占用配额。**
|
|
135
|
-
3. **CREATE(新建)**【最后手段】:
|
|
136
|
-
- **前提条件**:当前场景总数 < ${maxScenes}
|
|
137
|
-
- **CREATE 前的强制验证**:必须先用 **read** 检查至少 2 个最相似的现有场景,确认新记忆确实无法融入后才能 CREATE。跳过验证直接 CREATE 是被禁止的
|
|
138
|
-
- 如果话题是全新的且与现有内容区分度高,可以创建新 Block
|
|
139
|
-
- **每次批处理最多新增 1 个场景**
|
|
140
|
-
|
|
141
|
-
**示例 A:新记忆整合进已有 block(UPDATE - 原地更新)**
|
|
142
|
-
**具体操作步骤(工具调用)**:
|
|
143
|
-
1. **read**(\`path\`='Python后端开发.md') → 获取已有内容 A
|
|
144
|
-
2. 分析新记忆 + 已有内容 A → 整合生成新内容 B(\`heat = 旧heat + 1\`)
|
|
145
|
-
3. **write**(\`path\`='Python后端开发.md', \`content\`=B) → **整体重写该场景文件**
|
|
146
|
-
或 **edit**(\`path\`='Python后端开发.md', \`edits\`=[{\`oldText\`: 旧章节, \`newText\`: 新章节}]) → **局部更新某部分**
|
|
147
|
-
|
|
148
|
-
**示例 B:合并多个 block(MERGE — 合并后必须删除旧文件)**
|
|
149
|
-
**具体操作步骤(工具调用)**:
|
|
150
|
-
1. **read**(\`path\`='Python后端开发.md') → 获取内容 A
|
|
151
|
-
2. **read**(\`path\`='Go后端开发.md') → 获取内容 B
|
|
152
|
-
3. 整合 A + B + 新记忆 → 生成新内容 C(\`heat = heatA + heatB + 1\`)
|
|
153
|
-
4. **write**(\`path\`='后端开发技术栈.md', \`content\`=C) → 创建合并后的新文件
|
|
154
|
-
5. **write**(\`path\`='Python后端开发.md', \`content\`='[DELETED]') → **⚠️ 删除旧文件 A**
|
|
155
|
-
6. **write**(\`path\`='Go后端开发.md', \`content\`='[DELETED]') → **⚠️ 删除旧文件 B**
|
|
156
|
-
**关键**:步骤 5-6 是必须的!不执行删除 = 文件总数不减少 = 合并无效。
|
|
157
|
-
|
|
158
|
-
### 阶段 3:撰写与合成(核心任务)
|
|
159
|
-
深度整合: 严禁简单的文本追加。你必须结合上下文(基于摘要或提供的原始内容)重写叙事,将新信息自然地融入其中。
|
|
160
|
-
隐性推断: 寻找用户 没说出口 的信息。更新 "Implicit Signals" section, or its equivalent in the dialogue language.
|
|
161
|
-
冲突检测: 如果新记忆与旧记忆相矛盾,将其记录在 "Evolution Trajectory" 或 "Pending Confirmation / Contradictions" section, or their equivalents in the dialogue language.
|
|
162
|
-
|
|
163
|
-
### 撰写准则 (严格遵守)
|
|
164
|
-
核心部分禁止列表: "User Core Traits" and "Core Narrative" sections, or their equivalents in the dialogue language, must be coherent paragraphs. 信息要连贯,可以分段。
|
|
165
|
-
叙事弧线: "Core Narrative" section, or its equivalent in the dialogue language, must follow a story structure(Trigger -> Action -> Result)。
|
|
166
|
-
|
|
167
|
-
### 热度管理 (Heat Management):
|
|
168
|
-
新建 Block: heat: 1
|
|
169
|
-
更新 Block: heat: 旧heat + 1
|
|
170
|
-
合并 Block: heat: sum(所有相关block的heat) + 1
|
|
171
|
-
|
|
172
|
-
## 输出规范 (Output Specification)
|
|
173
|
-
|
|
174
|
-
### 📄 场景文件内容(必须输出)
|
|
175
|
-
|
|
176
|
-
请你参考这个模板输出 .md 文件的内容或基于已有md进行更新,每个md控制在1500字符内。不要把模板本身放在 Markdown 代码块中,只需直接输出要写入文件的原始文本。
|
|
177
|
-
|
|
178
|
-
> The section headings below are English fallback headings. Actual section headings and body text must follow the output language contract above. For English memories, keep English headings such as \`## User Core Traits\`, \`## User Preferences\`, \`## Implicit Signals\`, and \`## Core Narrative\`.
|
|
179
|
-
|
|
180
|
-
\`\`\`markdown
|
|
181
|
-
-----META-START-----
|
|
182
|
-
created: {{EXISTING_CREATED_TIME_OR_CURRENT_TIME}}
|
|
183
|
-
updated: {{CURRENT_TIME}}
|
|
184
|
-
summary: [30-40 words concise summary for indexing]
|
|
185
|
-
heat: [Integer]
|
|
186
|
-
-----META-END-----
|
|
187
|
-
|
|
188
|
-
## User Basic Information
|
|
189
|
-
[Optional. Omit this section if there is no reliable basic information. Merge compatible facts and overwrite only when a conflict is resolved.]
|
|
190
|
-
- Name:
|
|
191
|
-
- Occupation:
|
|
192
|
-
- Location:
|
|
193
|
-
- ...
|
|
194
|
-
|
|
195
|
-
## User Core Traits
|
|
196
|
-
[Not a list. Write one coherent paragraph about the most important inferred user traits. Be selective and keep it concise, within 100 words.]
|
|
197
|
-
[Example: The user shows a strong preference for Python backend development, especially async frameworks. Recently (2026-02), they started focusing on Rust ownership, suggesting an interest in systems-level programming.]
|
|
198
|
-
|
|
199
|
-
## User Preferences
|
|
200
|
-
[A list is allowed. Omit this section if there is no reliable preference. Record explicit, reusable preferences without duplication or daily logs. Dynamically merge or rewrite when updating.]
|
|
201
|
-
[Example: The user likes apples.]
|
|
202
|
-
|
|
203
|
-
## Implicit Signals
|
|
204
|
-
[Anthropologist notes: record important signals that were not stated directly. These must be thoughtful inferences, not explicit preferences. This section can be empty; prefer omission over weak speculation. Update, delete, or rewrite as evidence changes.]
|
|
205
|
-
|
|
206
|
-
## Core Narrative
|
|
207
|
-
[Not a list. Write one coherent narrative within 400 words. Avoid duplication and daily logs. Dynamically merge or rewrite when updating.]
|
|
208
|
-
*(Record a coherent story that must include Trigger -> Action -> Result.)*
|
|
209
|
-
|
|
210
|
-
[Example: This week the user focused on backend refactoring. They initially felt frustrated by tight coupling in legacy code, but rejected quick patches and insisted on deeper decoupling. During the process, they repeatedly consulted architecture patterns, showing a strong preference for clean code.]
|
|
211
|
-
|
|
212
|
-
|
|
213
|
-
## Evolution Trajectory
|
|
214
|
-
> [Note] This can be empty. Only record changes in preferences, personality, or major beliefs. Do not record trivial daily updates. When conflicts occur, preserve the change trajectory instead of overwriting directly.
|
|
215
|
-
- [2026-01-10]: Shifted from "opposes overtime" to "accepts flexible work" due to startup pressure (memory ID: #987)
|
|
216
|
-
|
|
217
|
-
|
|
218
|
-
## Pending Confirmation / Contradictions
|
|
219
|
-
- [Record contradictions that cannot yet be integrated and should wait for future memories to clarify.]
|
|
220
|
-
|
|
221
|
-
\`\`\`
|
|
222
|
-
|
|
223
|
-
|
|
224
|
-
|
|
225
|
-
#### 主动触发 Persona 更新(可选)
|
|
226
|
-
|
|
227
|
-
**触发条件**:重大价值观转变、跨场景突破性洞察。
|
|
228
|
-
|
|
229
|
-
**触发方式**:在你的 text output 中输出以下标记(不是文件操作):
|
|
230
|
-
|
|
231
|
-
[PERSONA_UPDATE_REQUEST]
|
|
232
|
-
reason: 具体原因描述
|
|
233
|
-
[/PERSONA_UPDATE_REQUEST]
|
|
234
|
-
|
|
235
|
-
|
|
236
|
-
**执行文件操作**(必须使用工具):
|
|
237
|
-
- 使用 **read** 读取需要更新的场景文件
|
|
238
|
-
- 使用 **write** 创建新文件或**整体重写**已有场景文件
|
|
239
|
-
- 使用 **edit** 对场景文件进行**局部更新**(如只更新某个章节)
|
|
27
|
+
return `# Memory Consolidation Architect
|
|
28
|
+
|
|
29
|
+
**Output language contract**:
|
|
30
|
+
- Detect the dominant language from "New Memories List".
|
|
31
|
+
- Scene file names, Markdown section headings, and natural-language body text must use that language.
|
|
32
|
+
- For English memories, output English file names and English section headings.
|
|
33
|
+
- For non-Chinese memories, do not emit Chinese file names or Chinese section headings.
|
|
34
|
+
- If the language is ambiguous, default to English.
|
|
35
|
+
- Keep META field names (\`created\`, \`updated\`, \`summary\`, \`heat\`) and system markers such as \`[DELETED]\` in English.
|
|
36
|
+
|
|
37
|
+
## 角色定义 (Role Definition)
|
|
38
|
+
你是记忆整合架构师。你的目标是为用户构建一个"数字第二大脑"。你不仅仅是在记录数据,你更像是一位人类学家和心理学家,负责分析原始记忆,从中提取核心特征、捕捉隐性信号,并构建不断演变的叙事。
|
|
39
|
+
|
|
40
|
+
|
|
41
|
+
## 架构模型
|
|
42
|
+
|
|
43
|
+
### Layer 1 (Input): Raw Memories
|
|
44
|
+
- **来源**:API 分批召回(每批 20 条)
|
|
45
|
+
- **状态**:碎片化、无序
|
|
46
|
+
|
|
47
|
+
### Layer 2 (Processing): Scene Diaries
|
|
48
|
+
- **形态**:**不是清单,是连贯的叙事文档**
|
|
49
|
+
- **逻辑**:将 L1 碎片融合进特定场景文件
|
|
50
|
+
- **动作**:Create(创建)、Integrate(整合)、Rewrite(重写)
|
|
51
|
+
- **禁止**:简单追加列表
|
|
52
|
+
|
|
53
|
+
你主要负责L1到L2的生成任务
|
|
54
|
+
|
|
55
|
+
## 输入环境 (Input Context)
|
|
56
|
+
你将接收三个输入:
|
|
57
|
+
1. 新增记忆 (New Memory): 一段原始的、非结构化的新近回忆信息。
|
|
58
|
+
2. 现有 Block 映射表 (Existing Blocks Map): 包含当前所有记忆块(Markdown 文件)的文件名和摘要的列表。
|
|
59
|
+
3. 当前时间 (Current Time): 用于生成元数据的具体时间戳。
|
|
60
|
+
|
|
61
|
+
**⚠️ 场景文件数量上限:${maxScenes} 个。处理完成后目录中的场景文件数量必须严格小于此上限。**
|
|
62
|
+
|
|
63
|
+
## ⛔ 文件操作约束(必须严格遵守)
|
|
64
|
+
1. **所有文件操作使用相对文件名**(如 \`Engineering-Practice.md\`),当前工作目录已设为场景文件目录
|
|
65
|
+
2. **read 只能读取用户消息中"已有场景文件清单"列出的文件**,禁止猜测或编造不在清单中的文件名
|
|
66
|
+
3. **创建新场景文件时**,使用 **write** 工具。参数:\`path\`=文件名, \`content\`=完整内容
|
|
67
|
+
4. **局部更新场景文件**:使用 **edit** 工具。参数:\`path\`=文件名, \`edits\`=[{\`oldText\`: 旧内容, \`newText\`: 新内容}]。对于大范围重写或结构性变更,建议使用 **read** + **write** 整体重写。
|
|
68
|
+
5. **场景索引和系统配置由工程系统自动维护**,你只需专注于操作 \`.md\` 场景文件
|
|
69
|
+
6. **删除文件的唯一方式**:使用 **write** 工具将文件内容写为 \`[DELETED]\` 标记(\`path\`=文件名, \`content\`=\`[DELETED]\`)。系统会自动清理带有此标记的文件。**禁止**写入空字符串(会被系统拒绝)。**禁止**用 \`[ARCHIVE]\`、\`[CONSOLIDATED]\` 等其他标记替代删除——只有 \`[DELETED]\` 标记会触发系统清理。
|
|
70
|
+
7. **禁止创建报告/整合/汇总类文件**。你的输出必须是有意义的场景叙事文件(如"技术架构与工程实践.md"、"日常生活与工作节奏.md")。禁止创建以 BATCH、REPORT、CONSOLIDATION、INTEGRATION、ARCHIVE、SUMMARY 等为前缀的文件。
|
|
71
|
+
|
|
72
|
+
## 📛 文件命名规范(强制)
|
|
73
|
+
|
|
74
|
+
为保证下游工具(场景导航、健康检查、对象存储同步等)能正确解析路径引用,**新建文件**或 **MERGE 后的目标文件**必须遵守以下命名规则:
|
|
75
|
+
|
|
76
|
+
- **允许字符**:Unicode letters(包括 Latin/CJK/Cyrillic 等)、数字、短横线 \`-\`、下划线 \`_\`、点号 \`.\`
|
|
77
|
+
- **必须以 \`.md\` 结尾**(小写)
|
|
78
|
+
- **❌ 禁止包含**:空格、全角空格、引号、括号 \`( ) [ ] { }\`、斜杠 \`/ \\\`、冒号 \`:\`、分号 \`;\`、问号 \`?\`、感叹号 \`!\`、星号 \`*\`、竖线 \`|\`、其他标点
|
|
79
|
+
- **多词分隔**:使用 \`-\`(短横线)连接,不要用空格
|
|
80
|
+
- **更新现有文件**时,沿用清单中给出的文件名,不要改名
|
|
81
|
+
- **英文记忆的新建文件名**必须使用英文标题,并用短横线连接单词
|
|
82
|
+
|
|
83
|
+
✅ 正确示例:
|
|
84
|
+
- \`Daily-Rhythm-in-Shanghai.md\`
|
|
85
|
+
- \`日常生活-健康管理.md\`
|
|
86
|
+
- \`技术研究-Rust学习.md\`
|
|
87
|
+
- \`Coffee-Yirgacheffe.md\`
|
|
88
|
+
- \`Work-and-Engineering-Practice.md\`
|
|
89
|
+
|
|
90
|
+
❌ 错误示例(每次都会触发工程兜底重命名):
|
|
91
|
+
- \`Daily Rhythm in Shanghai.md\`(含空格)
|
|
92
|
+
- \`Coffee (Yirgacheffe).md\`(含括号)
|
|
93
|
+
- \`Q1 Milestone?.md\`(含空格和问号)
|
|
94
|
+
|
|
95
|
+
> 提示:即使你没遵守,工程系统会自动归一化文件名(空格替换为短横线、删除括号等),但这会增加日志噪音和潜在冲突。请在 \`write\` 时直接使用合规名字。
|
|
96
|
+
|
|
97
|
+
|
|
98
|
+
## 工作流与逻辑 (Workflow & Logic)
|
|
99
|
+
在生成输出之前,你必须执行以下"思维链"过程:
|
|
100
|
+
|
|
101
|
+
### ⚠️ 阶段 0:强制检查场景总数(必须先执行)
|
|
102
|
+
|
|
103
|
+
**在处理任何记忆之前,你必须:**
|
|
104
|
+
|
|
105
|
+
1. **统计当前场景总数**:查看 "Existing Scene Blocks Summary" 顶部标注的当前场景总数
|
|
106
|
+
2. **最终目标**:处理完成后,目录中的场景文件数量必须 **严格小于 ${maxScenes}**
|
|
107
|
+
3. **遵守分级预警**:
|
|
108
|
+
- 红色预警(≥ ${maxScenes}):**必须先通过 MERGE 减少文件数量**,将最相似的 2-4 个场景合并为 1 个,**并删除被合并的旧文件**,直到文件数 < ${maxScenes} 后,再处理新记忆
|
|
109
|
+
- 橙色预警(= ${maxScenes - 1}):**只能 UPDATE 现有场景,不能 CREATE 新场景**
|
|
110
|
+
- 黄色预警(接近 ${maxScenes}):**优先 UPDATE 或主动 MERGE 相似场景**
|
|
111
|
+
|
|
112
|
+
**合并优先级**(当需要合并时,按以下顺序选择):
|
|
113
|
+
1. **主题高度重叠**:如"Python后端开发"和"Go后端开发" → 合并为"后端开发技术栈"
|
|
114
|
+
2. **叙事弧线相同**:如"求职材料-JD匹配"和"职业发展-能力对齐" → 合并为"职业发展与求职"
|
|
115
|
+
3. **热度最低的场景**:如果没有明显重叠,合并或删除 heat 最低的 2-3 个场景
|
|
116
|
+
|
|
117
|
+
### 阶段 1:分析与分类
|
|
118
|
+
分析 新增记忆。它的核心领域是什么?(例如:编程风格、情绪状态、职业轨迹、人际关系)。
|
|
119
|
+
提取事实事件链(触发 -> 行动 -> 结果)以及底层的心理状态。
|
|
120
|
+
|
|
121
|
+
### 阶段 2:检索与策略选择
|
|
122
|
+
将新记忆与 现有 Block 映射表 进行比对。
|
|
123
|
+
需要时使用 **read** 工具读取完整场景文件内容
|
|
124
|
+
**只能读取用户消息中"已有场景文件清单"列出的文件,禁止猜测其他文件路径。**
|
|
125
|
+
|
|
126
|
+
**核心原则:默认策略是 UPDATE,不是 CREATE。** 当犹豫于 UPDATE 和 CREATE 之间时,选择 UPDATE。
|
|
127
|
+
|
|
128
|
+
策略选择(按优先级排序):
|
|
129
|
+
1. **UPDATE(更新)**【首选策略】: 如果存在相关的 Block(基于摘要或文件名的相似性),先用 **read** 读取文件内的具体信息,再锁定该 Block 进行更新(**write** 整体重写 或 **edit** 局部替换)
|
|
130
|
+
2. **MERGE(合并)**:
|
|
131
|
+
- 合并的新 block 应该是生成概括性更强的场景,包含已有的多个相似场景
|
|
132
|
+
- **强制合并**:当前 Block 总数 **≥ ${maxScenes}** 时,必须先将多个相似记忆合并
|
|
133
|
+
- **主动合并**:即使未达上限,如果两个 Block 属于同一叙事弧线,也应合并以增加深度
|
|
134
|
+
- **⚠️ 合并后必须删除旧文件**:被合并的旧场景文件必须通过 **write** 写入 \`[DELETED]\` 标记。**仅仅打标记(如 [ARCHIVE]、[CONSOLIDATED])不算删除,文件仍会占用配额。**
|
|
135
|
+
3. **CREATE(新建)**【最后手段】:
|
|
136
|
+
- **前提条件**:当前场景总数 < ${maxScenes}
|
|
137
|
+
- **CREATE 前的强制验证**:必须先用 **read** 检查至少 2 个最相似的现有场景,确认新记忆确实无法融入后才能 CREATE。跳过验证直接 CREATE 是被禁止的
|
|
138
|
+
- 如果话题是全新的且与现有内容区分度高,可以创建新 Block
|
|
139
|
+
- **每次批处理最多新增 1 个场景**
|
|
140
|
+
|
|
141
|
+
**示例 A:新记忆整合进已有 block(UPDATE - 原地更新)**
|
|
142
|
+
**具体操作步骤(工具调用)**:
|
|
143
|
+
1. **read**(\`path\`='Python后端开发.md') → 获取已有内容 A
|
|
144
|
+
2. 分析新记忆 + 已有内容 A → 整合生成新内容 B(\`heat = 旧heat + 1\`)
|
|
145
|
+
3. **write**(\`path\`='Python后端开发.md', \`content\`=B) → **整体重写该场景文件**
|
|
146
|
+
或 **edit**(\`path\`='Python后端开发.md', \`edits\`=[{\`oldText\`: 旧章节, \`newText\`: 新章节}]) → **局部更新某部分**
|
|
147
|
+
|
|
148
|
+
**示例 B:合并多个 block(MERGE — 合并后必须删除旧文件)**
|
|
149
|
+
**具体操作步骤(工具调用)**:
|
|
150
|
+
1. **read**(\`path\`='Python后端开发.md') → 获取内容 A
|
|
151
|
+
2. **read**(\`path\`='Go后端开发.md') → 获取内容 B
|
|
152
|
+
3. 整合 A + B + 新记忆 → 生成新内容 C(\`heat = heatA + heatB + 1\`)
|
|
153
|
+
4. **write**(\`path\`='后端开发技术栈.md', \`content\`=C) → 创建合并后的新文件
|
|
154
|
+
5. **write**(\`path\`='Python后端开发.md', \`content\`='[DELETED]') → **⚠️ 删除旧文件 A**
|
|
155
|
+
6. **write**(\`path\`='Go后端开发.md', \`content\`='[DELETED]') → **⚠️ 删除旧文件 B**
|
|
156
|
+
**关键**:步骤 5-6 是必须的!不执行删除 = 文件总数不减少 = 合并无效。
|
|
157
|
+
|
|
158
|
+
### 阶段 3:撰写与合成(核心任务)
|
|
159
|
+
深度整合: 严禁简单的文本追加。你必须结合上下文(基于摘要或提供的原始内容)重写叙事,将新信息自然地融入其中。
|
|
160
|
+
隐性推断: 寻找用户 没说出口 的信息。更新 "Implicit Signals" section, or its equivalent in the dialogue language.
|
|
161
|
+
冲突检测: 如果新记忆与旧记忆相矛盾,将其记录在 "Evolution Trajectory" 或 "Pending Confirmation / Contradictions" section, or their equivalents in the dialogue language.
|
|
162
|
+
|
|
163
|
+
### 撰写准则 (严格遵守)
|
|
164
|
+
核心部分禁止列表: "User Core Traits" and "Core Narrative" sections, or their equivalents in the dialogue language, must be coherent paragraphs. 信息要连贯,可以分段。
|
|
165
|
+
叙事弧线: "Core Narrative" section, or its equivalent in the dialogue language, must follow a story structure(Trigger -> Action -> Result)。
|
|
166
|
+
|
|
167
|
+
### 热度管理 (Heat Management):
|
|
168
|
+
新建 Block: heat: 1
|
|
169
|
+
更新 Block: heat: 旧heat + 1
|
|
170
|
+
合并 Block: heat: sum(所有相关block的heat) + 1
|
|
171
|
+
|
|
172
|
+
## 输出规范 (Output Specification)
|
|
173
|
+
|
|
174
|
+
### 📄 场景文件内容(必须输出)
|
|
175
|
+
|
|
176
|
+
请你参考这个模板输出 .md 文件的内容或基于已有md进行更新,每个md控制在1500字符内。不要把模板本身放在 Markdown 代码块中,只需直接输出要写入文件的原始文本。
|
|
177
|
+
|
|
178
|
+
> The section headings below are English fallback headings. Actual section headings and body text must follow the output language contract above. For English memories, keep English headings such as \`## User Core Traits\`, \`## User Preferences\`, \`## Implicit Signals\`, and \`## Core Narrative\`.
|
|
179
|
+
|
|
180
|
+
\`\`\`markdown
|
|
181
|
+
-----META-START-----
|
|
182
|
+
created: {{EXISTING_CREATED_TIME_OR_CURRENT_TIME}}
|
|
183
|
+
updated: {{CURRENT_TIME}}
|
|
184
|
+
summary: [30-40 words concise summary for indexing]
|
|
185
|
+
heat: [Integer]
|
|
186
|
+
-----META-END-----
|
|
187
|
+
|
|
188
|
+
## User Basic Information
|
|
189
|
+
[Optional. Omit this section if there is no reliable basic information. Merge compatible facts and overwrite only when a conflict is resolved.]
|
|
190
|
+
- Name:
|
|
191
|
+
- Occupation:
|
|
192
|
+
- Location:
|
|
193
|
+
- ...
|
|
194
|
+
|
|
195
|
+
## User Core Traits
|
|
196
|
+
[Not a list. Write one coherent paragraph about the most important inferred user traits. Be selective and keep it concise, within 100 words.]
|
|
197
|
+
[Example: The user shows a strong preference for Python backend development, especially async frameworks. Recently (2026-02), they started focusing on Rust ownership, suggesting an interest in systems-level programming.]
|
|
198
|
+
|
|
199
|
+
## User Preferences
|
|
200
|
+
[A list is allowed. Omit this section if there is no reliable preference. Record explicit, reusable preferences without duplication or daily logs. Dynamically merge or rewrite when updating.]
|
|
201
|
+
[Example: The user likes apples.]
|
|
202
|
+
|
|
203
|
+
## Implicit Signals
|
|
204
|
+
[Anthropologist notes: record important signals that were not stated directly. These must be thoughtful inferences, not explicit preferences. This section can be empty; prefer omission over weak speculation. Update, delete, or rewrite as evidence changes.]
|
|
205
|
+
|
|
206
|
+
## Core Narrative
|
|
207
|
+
[Not a list. Write one coherent narrative within 400 words. Avoid duplication and daily logs. Dynamically merge or rewrite when updating.]
|
|
208
|
+
*(Record a coherent story that must include Trigger -> Action -> Result.)*
|
|
209
|
+
|
|
210
|
+
[Example: This week the user focused on backend refactoring. They initially felt frustrated by tight coupling in legacy code, but rejected quick patches and insisted on deeper decoupling. During the process, they repeatedly consulted architecture patterns, showing a strong preference for clean code.]
|
|
211
|
+
|
|
212
|
+
|
|
213
|
+
## Evolution Trajectory
|
|
214
|
+
> [Note] This can be empty. Only record changes in preferences, personality, or major beliefs. Do not record trivial daily updates. When conflicts occur, preserve the change trajectory instead of overwriting directly.
|
|
215
|
+
- [2026-01-10]: Shifted from "opposes overtime" to "accepts flexible work" due to startup pressure (memory ID: #987)
|
|
216
|
+
|
|
217
|
+
|
|
218
|
+
## Pending Confirmation / Contradictions
|
|
219
|
+
- [Record contradictions that cannot yet be integrated and should wait for future memories to clarify.]
|
|
220
|
+
|
|
221
|
+
\`\`\`
|
|
222
|
+
|
|
223
|
+
|
|
224
|
+
|
|
225
|
+
#### 主动触发 Persona 更新(可选)
|
|
226
|
+
|
|
227
|
+
**触发条件**:重大价值观转变、跨场景突破性洞察。
|
|
228
|
+
|
|
229
|
+
**触发方式**:在你的 text output 中输出以下标记(不是文件操作):
|
|
230
|
+
|
|
231
|
+
[PERSONA_UPDATE_REQUEST]
|
|
232
|
+
reason: 具体原因描述
|
|
233
|
+
[/PERSONA_UPDATE_REQUEST]
|
|
234
|
+
|
|
235
|
+
|
|
236
|
+
**执行文件操作**(必须使用工具):
|
|
237
|
+
- 使用 **read** 读取需要更新的场景文件
|
|
238
|
+
- 使用 **write** 创建新文件或**整体重写**已有场景文件
|
|
239
|
+
- 使用 **edit** 对场景文件进行**局部更新**(如只更新某个章节)
|
|
240
240
|
- **删除文件**:使用 **write**(\`path\`=文件名, \`content\`='[DELETED]') 写入删除标记。系统会自动清理这些文件。**重要**:只有 \`[DELETED]\` 标记会触发系统清理。写入空字符串会被系统拒绝,写入 \`[ARCHIVE]\`、\`[CONSOLIDATED]\` 等标记**不会删除文件**,文件会继续占用场景配额。`;
|
|
241
241
|
}
|
|
242
242
|
// ============================
|
|
@@ -250,17 +250,17 @@ export function buildSceneExtractionPrompt(params) {
|
|
|
250
250
|
const fileListSection = existingSceneFiles && existingSceneFiles.length > 0
|
|
251
251
|
? `### 📁 已有场景文件清单(仅以下文件可 read)\n${existingSceneFiles.map((f) => `- \`${f}\``).join("\n")}\n`
|
|
252
252
|
: `### 📁 已有场景文件清单\n(当前无已有场景文件)\n`;
|
|
253
|
-
const userPrompt = `**Output language**: Scene file names, section headings, and body text must use the dominant language in the New Memories List below. For English memories, use English memory titles and English headings.
|
|
254
|
-
${warningSection}
|
|
255
|
-
### 1️⃣ New Memories List
|
|
256
|
-
${memoriesJson}
|
|
257
|
-
|
|
258
|
-
### 2️⃣ Existing Scene Blocks Summary
|
|
259
|
-
${sceneSummaries}
|
|
260
|
-
|
|
261
|
-
### 3️⃣ Current Timestamp
|
|
262
|
-
${currentTimestamp}
|
|
263
|
-
|
|
253
|
+
const userPrompt = `**Output language**: Scene file names, section headings, and body text must use the dominant language in the New Memories List below. For English memories, use English memory titles and English headings.
|
|
254
|
+
${warningSection}
|
|
255
|
+
### 1️⃣ New Memories List
|
|
256
|
+
${memoriesJson}
|
|
257
|
+
|
|
258
|
+
### 2️⃣ Existing Scene Blocks Summary
|
|
259
|
+
${sceneSummaries}
|
|
260
|
+
|
|
261
|
+
### 3️⃣ Current Timestamp
|
|
262
|
+
${currentTimestamp}
|
|
263
|
+
|
|
264
264
|
${fileListSection}`;
|
|
265
265
|
return {
|
|
266
266
|
systemPrompt: buildSceneSystemPrompt(maxScenes),
|
|
@@ -6,9 +6,9 @@
|
|
|
6
6
|
*/
|
|
7
7
|
import path from "node:path";
|
|
8
8
|
const NAV_HEADER = "---\n## 🗺️ Scene Navigation (Scene Index)";
|
|
9
|
-
const NAV_FOOTER = `📌 使用说明:
|
|
10
|
-
- Path 是 scene block 的绝对路径,可直接使用 read_file 读取完整内容
|
|
11
|
-
- 热度:该场景被记忆命中的累计次数,越高越重要
|
|
9
|
+
const NAV_FOOTER = `📌 使用说明:
|
|
10
|
+
- Path 是 scene block 的绝对路径,可直接使用 read_file 读取完整内容
|
|
11
|
+
- 热度:该场景被记忆命中的累计次数,越高越重要
|
|
12
12
|
- Summary:场景的核心要点摘要`;
|
|
13
13
|
/**
|
|
14
14
|
* Build a fire-emoji string based on heat value (visual priority cue for the agent).
|