副题： SKILLLITE_EVO_* 当作「统计策略旋钮」，把 tool_sequence_key 当作「模式指纹」——比盲目加提示词更能稳定地让 Skill 从重复成功里长出来；同时学会读 evolution_run / evolution_run_noop / evolution_run_outcome，排障会快一个数量级。

---

一、先建立三条「用户预期」，避免错误 opened 的工单

1. 「开了 skills 臂」≠「一定生成 pending Skill」：还有 dedup、门禁、invoke 实测等链路，任一环卡住都可能本轮无落盘。
2. 「进了 evolution run」≠「一定写 evolution_run」：无 changelog 时会是 evolution_run_noop——有时间线记录，但不应推进「有产出冷却」时钟。
3. 「decisions 很多」≠「meaningful 很多」：meaningful 通常要求单条决策 total_tools 达到 SKILLLITE_EVO_MEANINGFUL_MIN_TOOLS（默认「至少 2 次工具」）才计入条数——零工具刷屏不会自动喂饱进化。

这三条对齐后，一半「进化坏了」的主观感受会消失——剩下的一半才是阈值与数据质量问题。

---

二、想少跑：从「关」到「保守」到「拉大间隔」

目标	实用旋钮（择一或组合）
彻底关闭	SKILLLITE_EVOLUTION=0
保留能力但少打扰	SKILLLITE_EVO_PROFILE=conservative
拉长被动冷却	SKILLLITE_EVO_COOLDOWN_HOURS
控制 A9 周期与「未处理决策」门槛	SKILLLITE_EVOLUTION_INTERVAL_SECS、SKILLLITE_EVOLUTION_DECISION_THRESHOLD 等（见 ENV 文档）
限制每日尝试成本	SKILLLITE_MAX_EVOLUTIONS_PER_DAY（含 material 与 noop 类完整执行）

注意：调度层仅记录的 evolution_run_outcome 与「跑满一轮 learner」不是同一计数语义——调每日上限时不要凭感觉对齐两种日志。

---

三、想多长 Skill：优先把「模式 key」写稳

被动侧统计 repeated_patterns 时，会在窗口内对
pattern_key = COALESCE(NULLIF(tool_sequence_key,''), task_description)
分组——也就是说：tool_sequence_key 越稳定、越短、越像指纹，越不容易被长自然语言任务描述误伤。

可操作的工程建议：

1. 在 Agent / 集成层为同类任务写入稳定 tool_sequence_key（例如规范化工具名序列的 hash 或规范串），比单纯调「重复次数阈值」更划算。
2. 若你改的是「开不开臂」的阈值，确认没有和 skill_synth/query.rs 里 query_repeated_patterns 的窗口/分组逻辑搞混——两处意图相近但 SQL 不同，调参时要分清文件。

---

四、想搞懂「为什么没跑」：从日志类型倒推

现象	优先读什么	常见原因
时间线里频繁 NoScope	describe_empty_evolution_proposals 一类说明 / evolution_log	窗口内 meaningful 不足、失败/重规划未达 prompts 门槛、skills 需要失败或重复模式等
SkippedBusy	全局锁占用	上一轮还在跑；属于保护，不是配置坏了
有 noop	evolution_run_noop	learner 合并结果为空；冷却不应被 noop 推着走（若你本地观察到相反行为，应以当前代码为准提 issue）
有 material 但磁盘没感觉	各 learner 写盘路径与权限	prompts/memory/skills 写入目录不同；skills 可能在 _pending

---

五、表格速查：三臂「开」的直觉条件（非 force）

下列为文档化的心智模型，精确条件以 should_evolve_impl 为准：

臂	直觉
skills	meaningful 达到 skills 阈值，且（有失败 或 存在高成功率重复模式）；有重复模式时偏 Generate，否则偏 Refine
memory	meaningful 达到 memory 阈值即可（不强制要有失败）
prompts	meaningful 更高，且失败或重规划达到各自门槛

---

六、mermaid：把「旋钮 → 统计 → 臂 → 审计」缩成一张图

---

七、验收与风险：别只盯「有没有文件」

仓库内还有 acceptance 窗口指标（成功率、纠错率、回滚率等）与 risk budget 相关环境变量——当你把自动执行从 demo 切到更保守的生产策略时，建议：

1. 先看 noop 比例：noop 高可能说明样本噪声大或门禁严，而不是单纯「模型不行」。
2. 再看 回滚率：进化是长期收益，短期回滚有时是正确护栏在起作用。
3. 最后才调 LLM 温度/提示词：否则容易把系统性阈值问题伪装成「prompt 工程」。

---

八、延伸阅读（Github仓库）

• docs/zh/ENV_REFERENCE.md：进化相关 env 的权威表格。
• spec/capability-gap-evolution.md：贡献者在仓库内补脚本/晋升路径的习惯说明，与运行时进化引擎不同层。

---

版权声明：本文基于 SkillLite 开源实现整理；转载请注明项目与文档出处。