SkillOpt-Sleep 是什么？夜间自动优化 Agent Skills 的使用方法

白天连续让 Codex 或 Claude Code 处理同一类任务，晚上最值得复盘的往往不是某次回答，而是反复出现的失误：测试总漏一个入口、提交说明总要返工、某个 Skill 每次都要临时补一句。SkillOpt-Sleep 把这些日常会话当成待整理的经验，但它不会趁你离开电脑就直接改掉线上 Skill。

一晚到底做了什么？

流程从只读采集开始：读取受支持的 Claude Code、Codex 或 Cursor 会话，挖出重复任务，再用选定后端进行隔离重放。随后系统反思结果，在 edit budget 内提出有限修改，并拿真实的 held-out 任务做 gate。通过的内容先进入 staging，默认还要等人执行 adopt。

这里解决的是“经验散在聊天记录里”这一痛点。它不解决没有评分的问题：任务结果若无法检查，重放和验证只能得到很弱的信号。官方把 Sleep 标成 preview，接口与默认值仍可能变化，也不该把它当作无人值守的生产自更新服务。

第一次用，先跑哪条命令？

用 PyPI 安装后，先让 mock 后端检查链路。mock 不调用模型供应商，也不消耗 API 预算：

pip install skillopt
skillopt-sleep dry-run --backend mock
skillopt-sleep status

确认采集范围、任务数量和目标 Skill 都正确，再换成真实后端。Codex 场景可以限制本次最多读取的会话与任务，并明确要更新的项目级 Skill：

skillopt-sleep run --project "$(pwd)" \
  --source codex --backend codex \
  --target-skill-path .agents/skills/example/SKILL.md \
  --max-sessions 5 --max-tasks 3 --progress

dry-run 会不会花钱？

看后端。mock 不发供应商请求；换成 codex、claude、cursor 或 Azure OpenAI 等真实后端后，dry-run 仍会做挖掘、重放和反思调用，只是不写入 staging、adoption 与持久状态。max-sessions 和 max-tasks 限制采集工作量，却不是严格的 token、时间或费用上限。

“夜间自动”最该防的不是报错，而是数据越界

采集本身在本地只读，但真实后端会收到截断后的会话片段与派生任务，用于挖掘、重放、评判和反思。已知密钥形状会被脱敏，这仍不是绝对保证。敏感项目更稳妥的做法是先 harvest 到 JSON，人工检查和删改，把顶层 reviewed 标成 true，再交给真实后端处理；未审核的任务文件会被拒绝。

另外，状态化 run 即使没有挖出任务，也会推进采集 checkpoint。第一次正式运行前先用 harvest 或 dry-run 看数量，避免误以为第二晚仍会扫描同一窗口。Cursor 的 source 与 backend 还是两回事：读取 Cursor 会话不代表已经配置好 cursor-agent。

什么时候才值得 schedule？

先手动完成至少一次 dry-run、run、status、adopt，确认 proposal 放在预期项目、目标 Skill 路径正确、备份可恢复，再设置夜间计划。schedule 记录的是项目、后端、时间和可选 auto-adopt；某些 source、模型、CLI 路径与 target skill 需要提前写入用户配置，不能指望计划任务继承交互式终端环境。

把 auto-adopt 留到很后面更稳妥。Sleep 的价值不是省掉复核，而是把“哪些经验值得进入长期 Skill”变成可重放、可验证、可撤回的过程。只要任务会重复、结果能检查、会话边界可接受，它才有机会把夜间空档变成真正的能力积累。