98 lines
4.3 KiB
Markdown
98 lines
4.3 KiB
Markdown
|
||
# todolist
|
||
|
||
## 实现
|
||
1. 从cherry-studio代码中，移植:
|
||
“模型服务”
|
||
“显示设置”
|
||
“MCP”
|
||
模块，使用typescript+vue3实现。
|
||
✅
|
||
|
||
火山：
|
||
https://ark.cn-beijing.volces.com/api/v3
|
||
853e780d-a789-42fc-8f9e-c6a8c3c97082
|
||
|
||
阿里
|
||
https://dashscope.aliyuncs.com/compatible-mode/v1
|
||
sk-2546da09b6d9471894aeb95278f96c11
|
||
|
||
3. 阿里模型直接使用，模型ID。
|
||
✅
|
||
|
||
以后再考虑不要使用接口去获取。(先跑通)
|
||
🚩
|
||
|
||
4. MCP 功能叠加。
|
||
✅
|
||
|
||
## 优化
|
||
1. 该项目经过反复重构，重构过程关注功能实现，没有关注性能、结构合理性、和实现的优雅性。全量分析，提供优化点及思路。
|
||
**先优化，在做数据库改造**。
|
||
|
||
### 重构进度 (2025-10-16)
|
||
|
||
#### Phase 1: 核心服务拆分 (Day 1-2) ✅ 已完成
|
||
- ✅ Step 1: 创建服务目录结构 `/web/src/services/chat/`
|
||
- ✅ Step 2: 提取 MessageService - 消息 CRUD 操作（20+ 方法）
|
||
- ✅ Step 3: 提取 ConversationService - 对话管理（10+ 方法）
|
||
- ✅ Step 4: 创建统一日志系统 Logger (支持日志级别、命名空间、格式化)
|
||
- ✅ Step 5: 创建错误处理体系 AppError (ValidationError, NetworkError, APIError, ServiceError, StorageError + ErrorHandler)
|
||
- ✅ Step 6: 提取 StreamProcessor - 流式响应处理（性能监控、批量输出、工具集成）
|
||
- ✅ Step 7: 提取 ToolExecutor - 工具调用执行（递归调用链、错误处理）
|
||
- ✅ Step 8: 创建 ChatOrchestrator - 协调所有服务（话题管理、消息管理、流式发送、持久化 + togglePin/Favorite/Archive）
|
||
- ✅ Step 9: 更新 chatStore 使用新服务（已完成：chatService → chatOrchestrator）
|
||
- ⏸️ Step 10: 测试验证，确保无功能回归
|
||
|
||
**✅ Phase 1 重构完成！旧的 chatService.ts (1147行) 已完全被新架构替代。**
|
||
|
||
**服务架构总结：**
|
||
```
|
||
ChatOrchestrator (协调器)
|
||
├── MessageService (消息 CRUD)
|
||
├── ConversationService (对话管理)
|
||
├── StreamProcessor (流式处理)
|
||
└── ToolExecutor (工具执行)
|
||
|
||
工具层：
|
||
├── Logger (统一日志)
|
||
└── AppError + ErrorHandler (错误处理)
|
||
```
|
||
|
||
#### Phase 2: 优化与集成 (Day 3-4)
|
||
- ⏸️ 替换所有 console.log 为 logger
|
||
- ⏸️ 实现虚拟滚动优化消息列表
|
||
- ⏸️ 添加数据库索引
|
||
- ⏸️ 优化重渲染 (shallowRef)
|
||
|
||
#### Phase 3: 新功能开发 (Week 2+)
|
||
- ⏸️ 在干净的架构上开发新功能
|
||
|
||
## 问题
|
||
1. 优化消息交互。比如标题\内容超长怎么处理❓
|
||
|
||
2. 上下文的问题？上下文由谁维护❓以及如何维护❓
|
||
可以在cherry-studio中验证。
|
||
|
||
3. 大模型选择不知道是否生效？
|
||
✅
|
||
|
||
4. 前端本地持久化（localStorage）, 后端（Node/Express），不使用数据库，运行时内存保存。
|
||
Pinia store、localStorage、内存状态三处保存数据？
|
||
使用sqlite3 vs. better-sqlite3持久化？性能开销？
|
||
没有统一的数据源?
|
||
|
||
5. 当前实现，client参数重带图片path，server收到后按path发布图片。目前client/server部署在同一个服务器，测试没问题，因为server可以从path找到图片。
|
||
但问题是：server部署如果部署在远程服务器上，用户是client需要使用mcp server发布文章，图片在client侧处理好，需要送到远程服务器上，否则server找不到图片。在多client用户使用mcp server下，进一步需要考虑几个问题：
|
||
- 图片通过什么方式传送到远程服务器？
|
||
- 用户publish content时，需要等待图片上传完成，等待时间根据网络状态，可能会很长？
|
||
本来用户发布文章到xhs，本地之间上传图片到xhs，现在多了一个环节，图片上传mcp server，mcp server在上传图片到xhs。
|
||
- 图片上传和发布文章能不能解耦，比如，用户先传送图片，缓存到mcp server。需要的时候，再发布文章。
|
||
但这样，用户操作会很繁琐。
|
||
- 上传图片到mcp server，还有一个存放位置问题。client的path参数用什么？上传到哪个目录？发布时从哪个目录寻找？
|
||
如果上传图片，最好约定一套策略，path中只要填文件名，mcp server的路径不需要client考虑。
|
||
- 如果用上传图片方式，大量client接入的排队机制怎么处理？client采用异步方式递交，点击发送/发布，可以去喝茶了，不必考虑多久完成。
|
||
- mcp server侧需要考虑的机制。
|
||
|
||
|