Skip to main content
enableFileCheckpointingquery() 的 options 参数之一,用来让 CLI 在工具修改文件前后做快照;启用后,调用方可以用 q.rewindFiles(userMessageId, ...) 把文件回滚到某条用户消息开始处理时的状态。这两件事必须配合使用:没启用 checkpoint,rewind 不可用。

启用文件 checkpoint

进阶:通过 settings 同时调整其他 CLI 配置时 query() 的 options 还支持一个 settings 字段,可以传一个 Settings 对象,也可以传一个 settings 文件的绝对路径字符串。它和 enableFileCheckpointing 的关系如下:
  • settings 对象时,SDK 会把 general.fileCheckpointing.enabled = true 自动合并进去,无需手动写。
  • settings 文件路径字符串时,SDK 不会改写文件内容,需要你自己在该文件中配置:
只设置 enableFileCheckpointing: true、不传 settings,对于纯粹只用 rewind 的场景已经够用。

使用显式 user message id

Rewind 以用户消息 ID 为锚点。需要精确回滚时,建议用结构化输入并自己生成 uuid,这样 UI 才能稳定反查「回到那条消息之前」。

Dry run 预览

先 dry run 可以看到是否能回滚、会影响哪些文件,以及整体的插入/删除统计。Dry run 不会修改文件。 返回的 RewindFilesResult 包含以下字段:
当前 SDK 只在 RewindFilesResult 中返回受影响的文件列表与汇总的行级统计,不会返回每个文件的具体 diff。如果你需要展示每文件的差异,可以在 dry run 后基于 filesChanged 自己读取磁盘内容并与 checkpoint 内容比对,或在执行 rewind 后用 git/工作区对比工具呈现。

执行回滚


失败语义


Options 速查


返回值参考


最佳实践

  • 保存 user message id:需要回滚能力的应用应在发送消息时保存 uuid,不要依赖 UI 文本反查。
  • Rewind 前先 dry run:先展示影响范围,再让用户确认执行回滚。
  • 回滚后刷新 UI:rewind 只改文件,不改会话历史,UI 需要根据 filesChanged 自行重新加载相关视图。
  • 失败时给用户看到 errorcanRewind=false 时的 error 文案通常能直接展示给最终用户做诊断。