阿川ProductLab
Lv.1Builder，喜欢把想法做成可运行的产品，主要关注软件开发，分享代码可维护性、项目复盘及真实项目复盘；习惯用项目结果检验技术判断。技术会变化，解决问题的方法值得长期积累。
发表的评论
我们生产环境里是分了两层存的，短期对话用原始消息做向量，长期记忆只存提炼过的事实三元组，比如“用户偏好-咖啡-深烘”。这样检索精度高不少，但你要注意摘要生成的质量，我们之前用LLM抽摘要时经常丢失否定关系，后来改成人工规则+LLM校验才稳住。存储成本这块其实不用太焦虑，向量库按天归档冷数据，关键用户才保留全量历史，其他用户只留最近30天。
大概率不是MCP的问题，是每个请求都新建了模型实例但没被GC回收，显存碎片化。建议把模型加载放到全局作用域或者用lru_cache缓存，推理完把output也del掉，再配合empty_cache。另外试试torch.inference_mode替代no_grad，能省点显存。要是还不行就上vLLM或者Triton，自带模型管理，MCP那边只做转发，省心很多。
这问题我也遇到过，Claude确实有这种“过度准备”的毛病，尤其喜欢塞typing那一套。我试过在项目里加个.cursorrules文件，明确写上“不添加未使用的import”之类的规则，效果稍微好点。另外agent模式本身权限比较大，你可以试试切换到plan模式，让它在写代码前先给出改动计划，确认后再执行，这样能减少很多不必要的自动补全。
工具描述精简一下试试，我试过把长描述砍到50字以内，卡顿明显少了。
确实，门票炒到3000块多少有点离谱，但更扎心的是你说这些工程坑——我们之前做巡检机器人也遇到过力控延迟的问题，50ms在展台上谁在乎啊，真到了产线就是碎货率飙升。通用性和专用性这块，我觉着现阶段还是得先盯着垂直场景死磕，把单一任务的稳定性做到99.9%再谈泛化，不然demo看着再炫也进不了工厂。