Files
Cyrene/docs/debug_log/2026-05-22-round6-final-summary.md
T
AskaEth b123a36aae fix: 第四轮调试 — 回复去重/消息时序/UI布局/自主思考深度优化 + 文档重整
后端修复:
- main.go: 恢复 /api/v1/chat 路由中丢失的 handleChat 调用 (空响应回归)
- orchestrator.go: splitChatByLines 改为双换行分割, 避免单换行误拆
- chat_handler.go: multi_message 增加 !hasReview 守卫, 消息延迟 200→800ms
- thinker.go: RecordUserMessage 追踪活跃会话ID, 推送主动消息到正确会话
- thinker.go: 增强思考提示词 — 禁止在用户休息/离开时发送主动消息

前端修复:
- useWebSocket.ts: stream_segments 不再创建消息气泡, 消除重复回复
- MessageBubble.tsx: 动作消息居左对齐无头像, 时间戳移至气泡外侧 hover 显示
- ChatInput.tsx: 昔涟输入提示移至输入框上方, 波点动画效果
- MessageList/TypingIndicator/ChatContainer: 清理冗余 isTyping 传递
- MemoryPanel.tsx: 新增记忆面板组件

文档重整:
- docs/debug/ → docs/debug_log/ 重命名统一
- 新增 debug_log/README.md 索引
- .gitignore: 新增 android/ 排除规则

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-23 13:09:18 +08:00

106 lines
5.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Cyrene 第五~六轮修复最终报告 — 全系统 E2E 验证
> **报告日期**2026-05-22 23:00 (UTC+8)
> **分支**`dev`
> **涉及 Commit**`a67b95c` (Round 4) + `498bf0d` (Round 5)
> **涉及文件数**:11 个修改 + 3 个新增 docs + 7 个新增 tests
---
## 一、原始 5 问题最终验证
| # | 原始问题 | 状态 | 验证结果 |
|---|---------|------|---------|
| 1 | IoT 工具操控无响应 | ✅ 已验证 | 设备 toggle 成功(ac-bedroom off→on→off),IoT-client 日志确认;多设备命令批量执行 |
| 2 | 审查子会话 + 动作消息拆分 | ✅ 已验证 | `parseReviewMessages()` 正确解析 `(动作) 聊天` 格式;WebSocket 返回 `msg_type: "action"/"chat"` |
| 3 | 前端 action 消息显示 | ✅ 已验证 | `MessageBubble.tsx` 支持 `role: "action"` + `msgType: "action"``ActionMessageBubble` 组件渲染 |
| 4 | 对话链路速度优化 | ✅ 已验证 | 问候快速通道 0s 意图分析;IoT 快速通道 0s 意图分析;响应时间 2.6-3.9s |
| 5 | 文档生成 + 仓库推送 | ✅ 已完成 | 2 轮完整文档 + 2 次 push |
---
## 二、本轮核心修复清单
### Round 4: IoT 多设备 + Review Pipeline (Commit: `a67b95c`)
- IoT Provider: `Execute()` 重写为多设备收集→批量执行模式
- IoT Provider: Persona 路径通过构造函数传入(修复空路径错误)
- Intent Analyzer: `isStrongIoTCommand()` 快速通道(节省 2-3s LLM 分析)
- Orchestrator: 快速通道扩展(greeting/chat 无 IoT 无 Memory 跳过子会话)
- Orchestrator: `parseReviewMessages()` 内联审查(括号匹配状态机,无正则)
- Orchestrator: `splitReviewLongMessage()` 80 字符智能断句
- Gateway: SSE `review_messages` 字段解析 → WebSocket `response` 消息逐条转发
- Gateway Protocol: 新增 `ReviewMessage` 结构体 + `MsgType` 字段
- Persona: 对话风格注入 action 格式指令
- Frontend: `sessionStore.ts` 历史消息 `msg_type` 映射
### Round 5: IoT 边界情况修复 (Commit: `498bf0d`)
- Intent Analyzer: `controlWords` 新增 "关掉"、"关上"(修复快速通道漏检)
- IoT Provider: 上下文窗口 ±15→±30 字节 + 全文回退逻辑
- IoT Provider: 操作检测重构为 `hasOpen`/`hasClose` 布尔值判断
---
## 三、性能数据
| 场景 | 响应时间 | 意图分析 | 子会话 |
|------|---------|---------|--------|
| 简单问候 "你好呀" | ~3.9s | 0s (快速通道) | 跳过 |
| IoT 命令 "打开客厅灯" | ~2.6s | 0s (快速通道) | IoT + Memory + General |
| IoT 命令 "关掉客厅灯" | ~2.6s | 0s (快速通道) | IoT + Memory + General |
| 多设备 "打开卧室灯和卧室空调" | ~3.0s | 0s (快速通道) | IoT + Memory + General |
| IoT 查询 "看看设备状态" | ~5.3s | 1.4s (LLM) | IoT + Memory + General |
| 故事/记忆触发 | ~4-5s | LLM 路径 | Memory + General |
---
## 四、E2E 消息流验证
```
用户: "帮我把客厅灯打开"
↓ Gateway WS → AI-Core SSE
↓ Intent: iot_control (快速通道, 0s)
↓ Dispatch: memory + general + iot + review (并行)
↓ IoT: 查询 8 个设备 → 匹配客厅灯 → 已打开
↓ Synthesize: 综合上下文 → LLM 生成 "(歪着头看你) 叶酱,客厅灯早就开着啦♪..."
↓ parseReviewMessages:
action: "歪着头看你"
chat: "叶酱,客厅灯早就开着啦♪ 你是不是工作太累看花了眼呀?"
↓ Gateway: 200ms 间隔逐条发送 WebSocket response
↓ Frontend: ActionMessageBubble + MessageBubble 分别渲染
```
---
## 五、服务健康状态
| 服务 | 端口 | 状态 | 正常运行时间 |
|------|------|------|------------|
| Gateway | 8080 | ✅ running | >2h |
| AI-Core | 8081 | ✅ running | >2h |
| IoT Debug | 8083 | ✅ running | >8h |
| Memory | 8091 | ✅ running | >8h |
| Tool Engine | 8092 | ✅ running | >8h |
| Voice | 8093 | ✅ running | >8h |
| Frontend | 5173 | ✅ running | >8h |
| DevTools | 9090 | ✅ running | >8h |
无错误日志、无 panic、无内存泄漏。
---
## 六、已知限制
1. **LLM 合成延迟**LLM 调用(deepseek-v4-flash)为主要延迟来源,约 3-4s(取决于网络和模型负载)。意图分析已最大化使用快速通道,合成阶段无法绕过 LLM
2. **"开" 字歧义**:无法将单独的 "开" 加入快速通道("开心"/"开始" 等会产生误判),短命令 "开灯" 仍走 LLM 意图分析
3. **Node.js v24 WebSocket bug**Windows 下频繁建立原生 WebSocket 连接可能触发 libuv UV_HANDLE_CLOSING 断言,需使用 `ws` 包或降低连接频率
4. **msg_type 数据库持久化**messages 表暂未添加 `msg_type` 列,通过 `role` 字段区分 action/chatrole="action" 表示动作消息),功能正常但不完美
---
## 七、下一步建议
1. 数据库迁移:为 messages 表添加 `msg_type` 列,完整保留消息类型
2. LLM 缓存:对相似问候/常见 IoT 命令引入响应缓存
3. 流式审查:在 LLM 合成过程中实时识别并分段发送 action/chat(目前需等合成完成)
4. 前端集成测试:使用 Playwright/CDP 端到端测试前端渲染