4.3 KiB
4.3 KiB
todolist
实现
- 从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
- 阿里模型直接使用，模型ID。 ✅
以后再考虑不要使用接口去获取。(先跑通) 🚩
- MCP 功能叠加。 ✅
优化
- 该项目经过反复重构，重构过程关注功能实现，没有关注性能、结构合理性、和实现的优雅性。全量分析，提供优化点及思路。 先优化，在做数据库改造。
重构进度 (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+)
- ⏸️ 在干净的架构上开发新功能
问题
-
优化消息交互。比如标题\内容超长怎么处理❓
-
上下文的问题？上下文由谁维护❓以及如何维护❓ 可以在cherry-studio中验证。
-
大模型选择不知道是否生效？ ✅
-
前端本地持久化（localStorage）, 后端（Node/Express），不使用数据库，运行时内存保存。 Pinia store、localStorage、内存状态三处保存数据？ 使用sqlite3 vs. better-sqlite3持久化？性能开销？ 没有统一的数据源?
-
当前实现，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侧需要考虑的机制。