跨 session 对话检索的能力

Trellis还有跨对话检索的能力？

可以在下一个session继续任务是当时Trellis最为关注的一点

佬，有对比过mini-trellis和trellis之间的token消耗情况吗

这个没有拿具体的case去统计，后续我考虑下怎么补一个对比测试，直观看下结果。

但是可以确认注入的内容是大幅减少，单一轮次下上下文是有减负的。

我之前使用trellis的时候就觉得跨会话记忆很不错，但是整体工作流太臃肿了就没用了，这个项目挺不错的，打算试用一下 ^-^

感谢，欢迎反馈~

npm install -g mini-trellis

佬，用这个极简版Trellis之前要先把原来的Trellis先卸载掉吗

不需要，安装后执行进行迁移命令（最好手动备份保存），注意同一个项目下不要同时开启Trellis和mini-trellis。

如果有顾虑可以拿已有的.trellis/的内容新开一个路径进行测试

迁移之后会变成这样，少了一个py文件，然后我执行mini-trellis init --codex命令也没有生成

codex hook的问题，迁移时清理了无关脚本但是hook配置没同步更新，需要手动在hook里更新配置

-

0.2.1

基于cc做了实验对比，严格来说是hook注入对比，不能等同于token消耗，具体看图吧

佬，图片有点糊，看不清啊 ^-^

对佬的项目十分感兴趣，狠狠star了

想请教一下历史对话迁移到知识库的功能。

现在开发过程中遇到需要长期保留项目知识的问题，但在使用 mini-trellis 之前，我已经积累了很多与当前项目有关的 Claude 历史对话，其中包含不少开发背景、技术决策和问题解决过程。

mini-trellis 是否支持读取这些已有的历史对话，从较早的会话开始整理，并生成适合放入项目知识库的文档？如果可以，历史会话需要以什么形式提供，或者需要放在哪个目录？它能否区分已确认的决定、未采用的建议和仍未解决的问题，并处理不同对话之间相互矛盾或已经过时的信息？

如果目前不支持自动读取，是否有推荐的手动导入流程，能把导出的对话整理成 Trellis 可使用的知识文件？也想了解这个过程对会话数量、隐私信息和上下文长度有没有限制。

感谢建议，当前侧重的更多是从Trellis迁移延续（既希望保留业务沉淀，又不希望过重约束），对于从零开始构建这部分我会考虑下如何进行设计，既能快速切入又不过度消耗token。

下面是我真实场景的一个效果展示

v0.3.0更新

- 新增： 新增 research 更迭机制。边界明确时可以更迭 research，避免知识腐化。旧笔记标明被哪一篇替换后，查询会优先给出现行内容。

- 新增： 新增压缩对话后读取 session 内记录。agent 在 compact 之后，可以按这场会话读回压缩前写下的内容。

- 修复： 完善压缩摘要边界。压缩摘要不再被当成原始对话返回。

- 优化： 优化召回机制。结果很少时也会留下现行笔记，前面的长回复不会把最后一条短限制挤掉。

建议升级或迁移mini-trellis前备份.trellis/内容

v0.3.1更新日志

- 新增cursor和DeepSeek harness支持

- 基于Claude code对比实验

- 累计耗时减少 38.4%（472.2s vs 766.5s，提速 1.62×）

- 累计处理 Token 减少 40.1%（242.6 万 vs 405.3 万，含未缓存输入、输出与缓存读取）

- 宿主交互轮次减少 27.8%（273 轮 vs 378 轮），全部样本通过自动检查。

详细的测试内容可以看仓库内docs/releases/benchmark-detail.md

欢迎各位佬提提意见，如果觉得有用希望可以点个star，再次感谢~

结合我真实的数据做了完整的对比实验，综合各场景测试下来，对比Trellis可以节省40%左右的token。同样读取背景和完成任务，整体注入和请求的轮次显著减少，速度更快。具体的细节可以看仓库里的评测记录。

挺好的，star了，目前用起来确实太臃肿了，随便一个小功能都要很久，但是它的工作流又舍不得

这个工作流听说很好用，试试极简版的效果