AI 会话一多就找不到？hmh /resume 列出全部会话，295 个 53ms 出预览

用户11791048833
19 阅读4分钟

用 AI 编程工具做鸿蒙项目时，最浪费时间的常常不是模型答错，而是找回昨天做到一半的上下文：构建参数、签名失败原因、模拟器状态、上一轮改过的文件，都散在几段会话里。只凭文件名或时间戳猜，很容易打开错会话，把已经讨论过的问题再解释一遍。

hmharness 0.4.4 把这个问题做成一个 TUI 选择器：在 hmh tui 里输入 /resume，列出全部历史会话；每行显示会话 ID 前缀和第一条用户输入；确认目标后才加载完整上下文。公开更新日志记录的实测口径是：295 个会话全部构建预览只用 53ms。

hmharness GitHub 仓库首页

这不是“越用越聪明”的夸张说法，只是一个很具体的小功能：让历史会话可见、可选择、可快速恢复。

先看交互：不用记完整会话 ID

进入 TUI 后输入：

/resume

回车后面板会打开：

  • ↑↓ 或滚轮：在全部历史会话中移动；
  • 输入 ID 前缀：快速过滤；
  • Enter：载入选中的会话；
  • Esc：关闭面板。

如果已经知道会话 ID 前缀，也可以走快捷路径：

/resume 2026-09-08T20

/resume 历史会话选择器

0.4.3 先把原来的文本列表改成了可导航的活面板；0.4.4 又去掉了“最近 8 条”的任意上限，长列表通过滚动和 ID 前缀过滤处理。

为什么 295 个会话还能秒开预览

如果把每个会话文件都完整解析一遍，选择器会随着历史积累越来越慢。hmharness 的做法是把“列表预览”和“完整恢复”分开：

/resume 读取路径

  1. 读取 HMH_HOME/sessions/*.jsonl，按时间倒序列出全部文件；
  2. 每个文件只读取头部 64KB；
  3. 在头部找第一条 t: "user" 的事件，截成一行预览；
  4. 用户按下 Enter 后，才对选中的文件执行完整 loadTranscript。

64KB 头部窥读

这个设计的关键假设是：第一条用户输入通常出现在会话文件头部。列表阶段只需要识别线索，不需要扫描后面的完整工具输出和长对话。若头部没有可读用户行，则显示“无预览”，不会为了预览强行解析整个文件。

和旧实现相比，改变的是两个限制

维度旧实现hmharness 0.4.4
会话数量最近 8 条全部历史会话
预览读取完整解析会话后提取用户输入每个文件头部 64KB 窥读
定位方式主要靠人工记忆ID 前缀过滤 + 首条用户输入
加载时机预览阶段成本前置选中后才完整加载

295 个会话 53ms 预览

需要注意的是：53ms 来自公开 CHANGELOG 记录的一次实测，表示“295 个会话全部构建预览”的耗时，不是所有机器、所有会话形态下的保证值。

放进鸿蒙开发链路里看

一个真实排障任务经常是连续的：

构建失败 → 分析 hvigor 日志 → 修签名配置
→ 安装 HAP → 启动 Ability → 回读 hilog
→ 根据页面截图继续修 UI

这类任务中断后，最重要的不是重新提问，而是找回当时的判断链：模型看到了哪段日志、执行过哪些工具、哪些结论已经被否掉。/resume 解决的就是这个入口问题。

上手路径

要求 Node >= 22：

npm install -g @hmharness/cli
hmh init
hmh tui

在 TUI 中输入 /resume 即可。历史会话保存在本机 HMH_HOME 状态目录中，不要把包含敏感内容的会话目录提交到 Git 仓库。

功能演示视频

边界也要说清楚

  • /resume 是 ID 前缀过滤和首条用户输入预览，不是全文语义搜索；
  • 0.4.4 只保证列出全部本地会话文件，不做跨机器同步；
  • 64KB 窥读用于预览，选中后仍会加载完整 transcript；
  • hmharness 是独立 MIT 开源项目，不隶属 Huawei/OpenAtom，也没有官方背书；
  • Windows 是优先验证平台，macOS/Linux 属于社区支持。

如果你正在试用，欢迎把环境差异反馈到 GitHub Discussions：OS、Node、DevEco/OpenHarmony SDK、是否有真机或模拟器，以及第一条失败命令。这类反馈比点赞更有价值。

相关链接

avatar
文章
阅读
粉丝