Sarv
Sarv
[prompt.txt](https://github.com/user-attachments/files/22114677/prompt.txt)
我测试是正常的，请检查下 chatlog 的 HTTP 服务是否正常开启；或是切换到 Streamable HTTP 试试，endpoint 是 `http://localhost:5030/mcp`
> 如何切换到Streamable HTTP cherry studio 中，MCP 类型改为 Streamable HTTP，URL 的 `/sse` 改为 `/mcp`
见 FAQ 说明，可以通过 `chatlog --debug` 打开程序，尝试获取密钥，然后在 文稿/chatlog/chatlog.log 中，会有相关日志信息。
“明明有记录”指的是在微信中看到对应记录吗？还是说通过 API 在 chatlog 中看到对应记录了？ 如果是第一种情况，3.x 版本微信写数据库文件不积极，需要主动触发写入数据库文件只能重新启动微信，再重新解密数据后查询。 如果是第二种情况，那就要检查 LLM 的 MCP 调用请求参数，是不是时间或其他参数设置错了。
不需要 sudo，你这是读取内存数据超时了"read memory timeout"，尝试下 lldb 是否能够读到内存数据
3.x 版本的特点是不太写数据库，所有数据都在缓存文件中，只有退出微信时或 1 天以上才会刷入数据库文件。 所以期间进行任何解密操作读取的都是没有新数据的数据库文件。 0.0.25 ~ 0.0.27 没有调整消息数据库读取的机制，可以尝试退出微信后重新解密一次试试。
实时更新确实会造成持续写盘。 因为程序的处理逻辑是监控数据库文件变化，如果发生变化，说明微信更新了数据，那么就执行一次解密操作。 解密操作需要对数据库文件做全文件解密运算并拷贝数据，由于 Windows 系统对文件有强制锁定，所以我们还额外引入了 filecopy 机制将解密后的数据再拷贝一次。 数据量最大的应该是 MSG_0.db 文件，假设这个文件有几百 M，加上你的群比较多，消息更新频繁，这个大文件被频繁写入，就会存在你说的持续写盘的问题。 解决方案我简单考虑了下，有几个方案，可以考虑结合： 1. 改用 docker 方案运行 chatlog，挂载 Docker Volumn 作为 Work Dir，这样就避免了 filecopy 机制。 2. 将微信数据做一次分离，历史的大量数据解密后归档保存，使用一个 chatlog 实例读取；当前正在运行的微信不保留历史记录，这样应该可以让 MSG_0.db 的数据保持在比较小的体量，加快解密速度。查询时再将两组...
感觉像是模型问题，使用其他模型有成功生成吗？
“迁移到 x86” 指的是拷贝数据还是重新下载 amd64 版本的 chatlog？