目前的话我的使用环境（Trellis0.6.5和pi）下基本上能够稳定复现这个问题，当然缓存既可能是客户端也可能是上游渠道，我这里只是提出一个现象，各位佬如果对token开支和缓存命中比较敏感的话可以自己去看看。 
具体现象就是可能第一个请求是1w3的缓存，第二次就会掉到3k，然后第三次就是正常重建后的缓存。经过几天的收集和日志排查，我发现Trellis的before_agent_start每次都会通过buildContext()动态的注入task的文档内容到系统提示词。那么也就是说，user->assistant过程中如果你对task本身的prd等要注入的东西有改动，那么下次你发消息的时候，系统提示词的内容就会改变了。当然怎么做缓存肯定是基于上游渠道，所以这里只是我的观察。 
这个也是他的设计，所以目前我的用法是如果观察到有对task相关文件的改动我就会开新对话continue来防止这种...