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

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

看脚法，曾经遇到过一个上海师傅全程微操，保持非常规律的非匀速运动，差点晕死在车上 ^-^

v0.3.0更新 - 新增： 新增 research 更迭机制。边界明确时可以更迭 research，避免知识腐化。旧笔记标明被哪一篇替换后，查询会优先给出现行内容。 - 新增： 新增压缩对话后读取 session 内记录。agent 在 compact 之后，可以按这场会话读回压缩前写下的内容。 - 修复： 完善压缩摘要边界。压缩摘要不再被当成原始对话返回。 - 优化： 优化召回机制。结果很少时

感谢建议，当前侧重的更多是从Trellis迁移延续（既希望保留业务沉淀，又不希望过重约束），对于从零开始构建这部分我会考虑下如何进行设计，既能快速切入又不过度消耗token。 下面是我真实场景的一个效果展示 ![图片](https://cdn3.ldstatic.com/optimized/4X/3/2/a/32a2fdcd3a04db75112bf19f4a3d92e01b16ecd1_2_69

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

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

不需要，安装后执行进行迁移命令（最好手动备份保存），注意同一个项目下不要同时开启Trellis和mini-trellis。 如果有顾虑可以拿已有的`.trellis/`的内容新开一个路径进行测试

感谢，欢迎反馈~

这个没有拿具体的case去统计，后续我考虑下怎么补一个对比测试，直观看下结果。 但是可以确认注入的内容是大幅减少，单一轮次下上下文是有减负的。

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