feat: conversation long-term memory + fix source ENUM bug
- New: conversationSummarizer.js (LLM summary every 3 turns, loadBestSummary, persistFinalSummary) - db/index.js: conversation_summaries table, upsertConversationSummary, getSessionSummary - redisClient.js: setSummary/getSummary (TTL 2h) - nativeVoiceGateway.js: _turnCount tracking, trigger summarize, persist on close - realtimeDialogRouting.js: inject summary context, reduce history 5->3 rounds - Fix: messages source ENUM missing 'search_knowledge' causing chat DB writes to fail
This commit is contained in:
User
425
test2/server/docs/conversation-long-term-memory.md
Normal file
425
test2/server/docs/conversation-long-term-memory.md
Normal file
@@ -0,0 +1,425 @@
|
||||
# 对话长期记忆方案：会话内摘要 + 跨会话衔接
|
||||
|
||||
## 一、背景与问题
|
||||
|
||||
### 1.1 现状
|
||||
|
||||
当前对话记忆体系有 4 层，均为短期记忆：
|
||||
|
||||
| 层级 | 机制 | 存储 | 有效窗口 | 代码位置 |
|
||||
|------|------|------|----------|----------|
|
||||
| L1 | Redis 对话历史 | 最近5轮(10条) | 30分钟TTL | `redisClient.js` HISTORY_MAX_LEN=10 |
|
||||
| L2 | MySQL 全量记录 | 无限 | 永久 | `db.addMessage()` |
|
||||
| L3 | contextKeywordTracker | 最近8个关键词 | 30分钟TTL | `contextKeywordTracker.js` |
|
||||
| L4 | KB话题记忆 | 最后1个话题 | 60秒TTL | `session._lastKbTopic` |
|
||||
| L5 | handoffSummary | 确定性摘要(最后8条) | 会话生命周期 | `loadHandoffSummaryForVoice()` |
|
||||
|
||||
### 1.2 双重核心问题
|
||||
|
||||
**问题 A：会话内遗忘（第6轮起丢失）**
|
||||
|
||||
S2S 和 KB 检索实际使用的上下文只有最近5轮原文（`getRecentHistory(sessionId, 5)`），第6轮开始的信息完全丢失。
|
||||
|
||||
**问题 B：会话重启时上下文断裂**
|
||||
|
||||
| 断裂场景 | 触发条件 | 当前结果 |
|
||||
|----------|----------|----------|
|
||||
| ① 同 sessionId 快速重连 | 网络抖动/页面刷新（30min内） | Redis 历史还在，但 session 内存状态全丢（`_lastKbTopic`、`contextKeywordTracker`、`_turnCount`） |
|
||||
| ② 同 sessionId 超时重连 | 用户隔一段时间再来（30min后） | Redis TTL 过期，只剩 MySQL + `loadHandoffSummaryForVoice`（确定性摘要，只取最后8条，质量差） |
|
||||
| ③ PM2 重启/崩溃恢复 | 部署或进程崩溃 | 所有 session 内存清零，Redis 还在 |
|
||||
| ④ voice → chat 模式切换 | 用户从语音切文字 | `chat.js` 有 `loadHandoffMessages` 做交接，但也是确定性摘要 |
|
||||
|
||||
> **注意**：新 sessionId = 全新对话，不需要跨 session 记忆继承。
|
||||
|
||||
**关键差距**：MySQL 存了全量原文却从未被用于生成高质量摘要；`buildDeterministicHandoffSummary` 只做模式提取（"当前问题 + 上一轮关注 + 已给信息"），压缩比低、语义丢失大。
|
||||
|
||||
### 1.3 受影响场景
|
||||
|
||||
| 场景 | 当前体验 | 占比估算 |
|
||||
|------|----------|----------|
|
||||
| 用户聊了8轮后追问"刚才那个产品" | AI 丢失上下文，回答偏题 | ~20-30% 深度对话 |
|
||||
| 长对话中多产品对比 | 早期提到的产品信息丢失 | ~15% |
|
||||
| 网络抖动后重连继续聊 | 内存状态丢失，KB话题追踪断裂 | ~10% |
|
||||
| 隔30分钟再打开继续咨询 | Redis过期，只剩粗糙的确定性摘要 | ~10% |
|
||||
| voice→chat 切换后追问语音聊的内容 | 只有确定性摘要，细节丢失 | ~5% |
|
||||
|
||||
---
|
||||
|
||||
## 二、设计目标
|
||||
|
||||
解决两个并列的核心问题，缺一不可：
|
||||
|
||||
| 目标 | 描述 | 衡量标准 |
|
||||
|------|------|----------|
|
||||
| **G1：会话内长记忆** | 单次对话超过5轮后仍能准确关联早期话题 | 10轮后追问命中率 ≥ 80% |
|
||||
| **G2：会话重启上下文衔接** | 同sessionId重连/PM2重启后无缝延续对话 | 重连后首轮上下文关联率 ≥ 90% |
|
||||
|
||||
---
|
||||
|
||||
## 三、记忆分层架构（三层设计）
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ L1 热记忆（Redis） │
|
||||
│ · 最近3轮原文（精确上下文） │
|
||||
│ · 当前会话摘要（LLM生成，每3轮更新） │
|
||||
│ · TTL: 2小时 │
|
||||
├─────────────────────────────────────────────────────┤
|
||||
│ L2 温记忆（MySQL conversation_summaries 表） │
|
||||
│ · 每个 session 的最终摘要（会话结束时写入） │
|
||||
│ · 永久存储，同 sessionId 重连时可恢复 │
|
||||
├─────────────────────────────────────────────────────┤
|
||||
│ L3 冷记忆（MySQL messages 表，现有） │
|
||||
│ · 全量原文记录 │
|
||||
│ · 仅在 L1+L2 都缺失时作为降级数据源 │
|
||||
│ · 通过 buildDeterministicHandoffSummary 提取 │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**加载优先级**：L1(Redis摘要) → L2(MySQL摘要) → L3(MySQL原文确定性提取)
|
||||
|
||||
---
|
||||
|
||||
## 四、方案详细设计
|
||||
|
||||
### 4.1 支柱一：会话内摘要（解决 G1）
|
||||
|
||||
#### 触发机制
|
||||
|
||||
```
|
||||
用户说话 → persistUserSpeech → session._turnCount++
|
||||
AI回复 → persistAssistantSpeech ──→ _turnCount % 3 === 0 ?
|
||||
├─ Yes → 异步 summarize() [不阻塞]
|
||||
│ ↓
|
||||
│ LLM(旧摘要 + 最近3轮原文)
|
||||
│ ↓
|
||||
│ Redis.setSummary(sessionId)
|
||||
│ MySQL.upsertSummary(sessionId) // 双写
|
||||
└─ No → 继续
|
||||
```
|
||||
|
||||
#### 滚雪球数据流
|
||||
|
||||
```
|
||||
Round 1-3: 原文正常存Redis
|
||||
Round 3 完成后:
|
||||
→ LLM(Round 1-3 原文) → 生成摘要 S1 → 存 Redis + MySQL
|
||||
→ 后续上下文 = S1 + 最近3轮原文
|
||||
|
||||
Round 6 完成后:
|
||||
→ LLM(S1 + Round 4-6 原文) → 生成摘要 S2 → 存 Redis + MySQL
|
||||
→ 后续上下文 = S2 + 最近3轮原文
|
||||
|
||||
...以此类推（每次摘要都包含之前所有轮次的压缩信息）
|
||||
```
|
||||
|
||||
#### 上下文注入
|
||||
|
||||
```javascript
|
||||
// resolveReply 中
|
||||
const summary = await loadBestSummary(sessionId);
|
||||
const recentHistory = await redisClient.getRecentHistory(sessionId, 3);
|
||||
|
||||
const context = [];
|
||||
if (summary) {
|
||||
context.push({ role: 'system', content: `[历史对话摘要] ${summary}` });
|
||||
}
|
||||
context.push(...recentHistory.map(item => ({ role: item.role, content: item.content })));
|
||||
```
|
||||
|
||||
### 4.2 支柱二：会话重启衔接（解决 G2）
|
||||
|
||||
#### 新增 MySQL 表：`conversation_summaries`
|
||||
|
||||
```sql
|
||||
CREATE TABLE conversation_summaries (
|
||||
id INT AUTO_INCREMENT PRIMARY KEY,
|
||||
session_id VARCHAR(128) NOT NULL,
|
||||
user_id VARCHAR(128),
|
||||
summary TEXT NOT NULL, -- LLM 生成的摘要
|
||||
turn_count INT DEFAULT 0, -- 该 session 的总轮次
|
||||
topics JSON, -- 提取的话题标签 ["活力健","基础三合一","一成系统"]
|
||||
created_at BIGINT,
|
||||
updated_at BIGINT,
|
||||
UNIQUE INDEX idx_session (session_id),
|
||||
INDEX idx_user_time (user_id, updated_at)
|
||||
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
|
||||
```
|
||||
|
||||
#### 断裂场景修复方案
|
||||
|
||||
| 场景 | 修复策略 | 加载顺序 |
|
||||
|------|----------|----------|
|
||||
| ① 同 sessionId 快速重连（30min内） | Redis 摘要仍在，直接使用 | L1 Redis |
|
||||
| ② 同 sessionId 超时重连（30min后） | Redis 过期，从 MySQL `conversation_summaries` 加载该 sessionId 的摘要 | L2 MySQL摘要 |
|
||||
| ③ PM2 重启 | Redis 还在（Redis 独立进程），从 Redis 加载；Redis 也丢了则走 L2 | L1 → L2 |
|
||||
| ④ voice→chat 模式切换 | `chat.js` 的 `loadHandoffMessages` 改为优先从 `conversation_summaries` 加载 LLM 摘要 | L2 MySQL摘要 |
|
||||
|
||||
#### 核心函数：`loadBestSummary(sessionId)`
|
||||
|
||||
```javascript
|
||||
async function loadBestSummary(sessionId) {
|
||||
// 1. 尝试 Redis（最快，~1ms）
|
||||
const redisSummary = await redisClient.getSummary(sessionId);
|
||||
if (redisSummary) return redisSummary;
|
||||
|
||||
// 2. 尝试 MySQL 当前 session 的摘要（~5ms）
|
||||
const sessionSummary = await db.getSessionSummary(sessionId);
|
||||
if (sessionSummary) {
|
||||
// 回填 Redis 加速后续读取
|
||||
await redisClient.setSummary(sessionId, sessionSummary.summary);
|
||||
return sessionSummary.summary;
|
||||
}
|
||||
|
||||
// 3. 降级：MySQL 原文 → 确定性摘要（现有逻辑）
|
||||
return null; // 交给现有的 loadHandoffSummaryForVoice 兜底
|
||||
}
|
||||
```
|
||||
|
||||
#### 会话结束时持久化
|
||||
|
||||
在 `session.client.on('close')` 中触发：
|
||||
|
||||
```javascript
|
||||
// nativeVoiceGateway.js client close handler
|
||||
session.client.on('close', () => {
|
||||
// ...existing cleanup...
|
||||
|
||||
// 持久化最终摘要到 MySQL（异步，不阻塞关闭流程）
|
||||
persistFinalSummary(session).catch(err => {
|
||||
console.warn('[NativeVoice] persistFinalSummary failed:', err.message);
|
||||
});
|
||||
});
|
||||
|
||||
async function persistFinalSummary(session) {
|
||||
if (!session._turnCount || session._turnCount < 2) return; // 太短的对话不存
|
||||
|
||||
// 优先用已有的 LLM 摘要
|
||||
let summary = await redisClient.getSummary(session.sessionId);
|
||||
|
||||
// 如果还没生成过摘要（对话不足3轮），立刻生成一次
|
||||
if (!summary && session._turnCount >= 2) {
|
||||
const history = await redisClient.getRecentHistory(session.sessionId, 5);
|
||||
if (history && history.length >= 2) {
|
||||
summary = await summarizer.summarizeConversation(null, history);
|
||||
}
|
||||
}
|
||||
|
||||
if (summary) {
|
||||
await db.upsertConversationSummary(session.sessionId, session.userId, summary, {
|
||||
turnCount: session._turnCount || 0,
|
||||
topics: extractTopicTags(summary), // 从摘要中提取话题标签
|
||||
});
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4.3 话题标签提取（增强跨会话关联）
|
||||
|
||||
从摘要中用正则提取产品名/系统名/话题关键词，存入 `topics` JSON 字段：
|
||||
|
||||
```javascript
|
||||
function extractTopicTags(summary) {
|
||||
const tags = new Set();
|
||||
// 复用现有的 knowledgeKeywords 和 knowledgeQueryResolver
|
||||
const { TRACKER_KEYWORD_GROUPS, buildKeywordRegex } = require('./knowledgeKeywords');
|
||||
for (const group of TRACKER_KEYWORD_GROUPS) {
|
||||
const regex = buildKeywordRegex(group, 'gi');
|
||||
const matches = summary.match(regex);
|
||||
if (matches) matches.forEach(m => tags.add(m));
|
||||
}
|
||||
return [...tags].slice(0, 10);
|
||||
}
|
||||
```
|
||||
|
||||
用途：未来可按 `topics` 做更精准的跨会话记忆匹配（如用户上次聊的是"活力健"，这次又提"活力健"，优先加载那次摘要）。
|
||||
|
||||
---
|
||||
|
||||
## 五、摘要 Prompt 设计
|
||||
|
||||
### 会话内摘要 Prompt（每3轮触发）
|
||||
|
||||
```
|
||||
你是对话摘要助手。将以下对话历史浓缩为简短摘要，必须保留：
|
||||
1. 用户询问过的所有产品名称和具体问题
|
||||
2. AI给出的关键数字（剂量、价格、数量等）
|
||||
3. 用户表达的偏好或关注点
|
||||
4. 未解决的问题或用户的疑虑
|
||||
|
||||
规则：只输出摘要正文，不加前缀或标题。150字以内。用"用户"和"助手"指代双方。
|
||||
```
|
||||
|
||||
### 跨会话注入时的格式
|
||||
|
||||
```
|
||||
用户上次（{时间差描述}）的对话摘要：{summary}
|
||||
```
|
||||
|
||||
例如：`用户上次（2小时前）的对话摘要：用户咨询了活力健和基础三合一的区别，助手介绍了两者成分差异。用户对活力健的服用方法比较关心，每天2次每次1条。用户还问了适不适合高血压人群。`
|
||||
|
||||
---
|
||||
|
||||
## 六、关键设计决策
|
||||
|
||||
| 决策点 | 建议值 | 理由 |
|
||||
|--------|--------|------|
|
||||
| **摘要触发** | `persistAssistantSpeech` 后异步 | 不阻塞对话链路，用户无感知 |
|
||||
| **摘要模型** | 复用 Seed-2.0-lite (`ep-20260320175538-lcg7g`) | 已部署，延迟低（~1-2s），成本低 |
|
||||
| **摘要 max_tokens** | 120 | 控制摘要长度，避免注入过长上下文 |
|
||||
| **摘要 thinking** | `{ type: 'enabled' }` | 异步执行不阻塞，开启推理提升摘要质量 |
|
||||
| **Redis key** | `voice:summary:{sessionId}` | 与对话历史同级 |
|
||||
| **Redis TTL** | 7200秒（2小时） | 长于对话历史的30分钟 |
|
||||
| **MySQL 双写** | 每次摘要同时写 Redis + MySQL | Redis 快读 + MySQL 持久化 |
|
||||
| **原文保留** | 摘要后仍保留最近3轮原文 | 最近对话需精确上下文 |
|
||||
| **最小对话门槛** | `_turnCount >= 2` 才持久化 | 太短的对话（打招呼就走）不值得存 |
|
||||
| **失败降级** | LLM摘要失败 → 确定性摘要 → 5轮原文 | 三级降级保证不影响主链路 |
|
||||
|
||||
---
|
||||
|
||||
## 七、涉及文件修改
|
||||
|
||||
| 文件 | 修改内容 | 复杂度 |
|
||||
|------|----------|--------|
|
||||
| **新增** `services/conversationSummarizer.js` | LLM 摘要生成、异步触发、`loadBestSummary`、`persistFinalSummary`、话题标签提取 | 中 |
|
||||
| `db/index.js` | 新增 `conversation_summaries` 建表 + `upsertConversationSummary` / `getSessionSummary` | 中 |
|
||||
| `services/redisClient.js` | 新增 `setSummary()` / `getSummary()` | 低 |
|
||||
| `services/nativeVoiceGateway.js` | session 增加 `_turnCount`；`persistUserSpeech` 计轮；`persistAssistantSpeech` 后触发摘要；`client.close` 时 `persistFinalSummary` | 低 |
|
||||
| `services/realtimeDialogRouting.js` | `resolveReply` 调用 `loadBestSummary` 注入上下文；`getRecentHistory` 轮数 5→3 | 低 |
|
||||
| `services/kbRetriever.js` | `searchAndRerank` 的 conversationHistory 也注入摘要 | 低 |
|
||||
| `routes/chat.js` | `loadHandoffMessages` 优先从 `conversation_summaries` 加载 LLM 摘要 | 低 |
|
||||
|
||||
### 新增文件结构：`conversationSummarizer.js`
|
||||
|
||||
```
|
||||
exports:
|
||||
- triggerSummarizeIfNeeded(session, sessionId) // 检查轮次 → 异步触发
|
||||
- summarizeConversation(existingSummary, messages) // 调 LLM 生成摘要
|
||||
- loadBestSummary(sessionId) // 三级降级加载最优摘要
|
||||
- persistFinalSummary(session) // 会话结束时持久化
|
||||
- extractTopicTags(text) // 从文本提取话题标签
|
||||
|
||||
constants:
|
||||
- SUMMARIZE_EVERY_N_TURNS = 3
|
||||
- SUMMARY_MAX_TOKENS = 120
|
||||
- SUMMARY_MODEL = process.env.VOLC_ARK_KB_MODEL
|
||||
- MIN_TURNS_TO_PERSIST = 2
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 八、成本与性能影响
|
||||
|
||||
### 成本
|
||||
|
||||
| 指标 | 值 |
|
||||
|------|-----|
|
||||
| 会话内摘要频率 | 每3轮1次 ≈ 平均每会话1-3次 |
|
||||
| 会话结束摘要 | 每会话最多+1次（如果轮次不足3） |
|
||||
| 单次摘要 token | 输入~400 + 输出~120 ≈ 520 tokens |
|
||||
| Seed-2.0-lite 价格 | ~0.001元/千tokens（估算） |
|
||||
| 单会话增加成本 | ~0.001-0.004元 |
|
||||
|
||||
### 性能
|
||||
|
||||
| 指标 | 影响 |
|
||||
|------|------|
|
||||
| 对话响应延迟 | **0ms 增加**（纯异步 fire-and-forget） |
|
||||
| 会话启动延迟 | +5-10ms（`loadBestSummary` 读 Redis/MySQL） |
|
||||
| Redis 读取 | +1次 getSummary/次对话轮（~1ms） |
|
||||
| Redis 存储 | +1 key/session（~300 bytes） |
|
||||
| MySQL 存储 | +1 row/session（~500 bytes） |
|
||||
| MySQL 查询 | 新 session 启动时 1次（按 userId 查最近摘要，~5ms，有索引） |
|
||||
| LLM 调用（后台） | ~1-2s/次，不阻塞用户 |
|
||||
|
||||
---
|
||||
|
||||
## 九、风险评估
|
||||
|
||||
| 风险 | 概率 | 影响 | 缓解措施 |
|
||||
|------|------|------|----------|
|
||||
| 摘要丢失关键产品名 | 中 | 高 | Prompt 强调保留产品名+数字；话题标签做辅助索引 |
|
||||
| 摘要引入幻觉 | 低 | 高 | max_tokens=120；摘要只做压缩不做推理；`[历史对话摘要]` 前缀标识 |
|
||||
| LLM 调用失败 | 低 | 中 | 三级降级：Redis摘要 → MySQL摘要 → 确定性摘要 → 5轮原文 |
|
||||
| MySQL 写入失败 | 低 | 低 | 摘要双写 Redis+MySQL，任一成功即可；下次触发时重试 |
|
||||
| 与 contextKeywordTracker 冲突 | 低 | 低 | 互补：摘要提供语义上下文，tracker 提供精确关键词路由 |
|
||||
| 用户隐私（摘要留存） | - | - | 摘要遵循现有 messages 的同等存储策略；deleteSession 时同步删除摘要 |
|
||||
|
||||
---
|
||||
|
||||
## 十、实施计划
|
||||
|
||||
### P0 - 核心双支柱（1.5天）
|
||||
|
||||
1. `db/index.js`：新增 `conversation_summaries` 表 + CRUD 方法
|
||||
2. `redisClient.js`：新增 `setSummary` / `getSummary`
|
||||
3. **新建** `conversationSummarizer.js`：LLM 摘要 + `loadBestSummary` + `persistFinalSummary`
|
||||
4. `nativeVoiceGateway.js`：轮次计数 + 摘要触发 + close 时持久化
|
||||
5. `realtimeDialogRouting.js`：`resolveReply` 注入摘要上下文
|
||||
|
||||
### P1 - 增强（0.5天）
|
||||
|
||||
6. `kbRetriever.js`：KB 检索的 conversationHistory 也注入摘要
|
||||
7. `routes/chat.js`：voice→chat 切换时优先加载 LLM 摘要
|
||||
8. 话题标签提取 + `extractTopicTags`
|
||||
|
||||
### P2 - 高级（未来）
|
||||
|
||||
9. 摘要质量监控（定期抽检摘要 vs 原文的信息保留率）
|
||||
10. 用户画像标签聚合（高频话题、偏好产品、健康关注点）——如未来需要跨 session 记忆再启用
|
||||
|
||||
---
|
||||
|
||||
## 十一、验证方案
|
||||
|
||||
### 会话内记忆测试
|
||||
|
||||
```
|
||||
1. 模拟6轮对话 → 验证第3轮后生成摘要
|
||||
2. 验证摘要正确保留产品名和关键数字
|
||||
3. 第7轮追问第1轮的产品 → 验证上下文关联正确
|
||||
4. LLM 摘要失败时 → 验证降级到5轮原文模式
|
||||
```
|
||||
|
||||
### 跨会话衔接测试
|
||||
|
||||
```
|
||||
5. 完成6轮对话 → 断开 → 同 sessionId 重连 → 验证首轮即有摘要上下文
|
||||
6. 完成6轮对话 → 等 Redis 过期 → 重连 → 验证从 MySQL 加载摘要
|
||||
8. PM2 重启 → 重连 → 验证摘要恢复
|
||||
9. voice→chat 切换 → 验证 chat 模式拿到语音会话摘要
|
||||
```
|
||||
|
||||
### 降级测试
|
||||
|
||||
```
|
||||
10. Redis 不可用 → 验证从 MySQL 加载 + 主链路不受影响
|
||||
11. MySQL 摘要表为空 → 验证降级到确定性摘要
|
||||
12. LLM 服务不可用 → 验证降级到5轮原文模式
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 十二、配置项
|
||||
|
||||
| 环境变量 | 默认值 | 说明 |
|
||||
|----------|--------|------|
|
||||
| `ENABLE_CONVERSATION_SUMMARY` | `true` | 总开关 |
|
||||
| `SUMMARY_EVERY_N_TURNS` | `3` | 每N轮触发一次摘要 |
|
||||
| `SUMMARY_MAX_TOKENS` | `120` | 摘要最大 token 数 |
|
||||
| `SUMMARY_REDIS_TTL_SECONDS` | `7200` | 摘要 Redis TTL（秒） |
|
||||
| `SUMMARY_MODEL` | 同 `VOLC_ARK_KB_MODEL` | 摘要使用的模型 endpoint |
|
||||
| `SUMMARY_MIN_TURNS_TO_PERSIST` | `2` | 最小轮次门槛，低于此值不持久化 |
|
||||
|
||||
---
|
||||
|
||||
## 十三、与现有机制的关系
|
||||
|
||||
| 现有机制 | 变更 | 共存关系 |
|
||||
|----------|------|----------|
|
||||
| `redisClient.pushMessage` / `getRecentHistory` | `getRecentHistory` 轮数从5降到3 | 摘要覆盖早期轮次，原文只需最近3轮 |
|
||||
| `contextKeywordTracker` | 不变 | 互补：tracker 做精确关键词路由，摘要做语义上下文 |
|
||||
| `session._lastKbTopic` | 不变 | 互补：60s 窗口保护仍需要，摘要不能替代实时话题追踪 |
|
||||
| `loadHandoffSummaryForVoice` | 改为降级备选 | LLM 摘要不可用时才调用确定性摘要 |
|
||||
| `buildDeterministicHandoffSummary` | 保留作为 L3 降级 | 三级降级的最后一道防线 |
|
||||
| `withHandoffSummary` | 由 `loadBestSummary` 替代 | 新函数统一管理所有来源的摘要注入 |
|
||||
Reference in New Issue
Block a user