# Lesson 06｜自进化机制：从会话历史抽取 skill gap（而不是靠感觉）

# 核心问题

团队里最常见的“能力建设”陷阱是：

• 复盘时人人都说“以后要更稳、更自动化”，但下次还是同样的坑；
• gap 清单靠主观印象维护，最后变成“谁嗓门大写谁的需求”。

这节课要建立一个可执行机制：从真实会话/执行日志里，证据化地挖出能力缺口（skill gaps），并持续写入长期库。

# 真实案例（带证据）

案例：会话驱动自进化（24h 信号采集 → 更新 skill-gaps.md）

• 证据1：明确扫描范围与方法：sessions_list(activeMinutes=1440) + sessions_history(limit=50)。
  • sessionKey: agent:main:cron:72b13206-d958-428d-bcd1-e32a8dd44c84
  • time: 2026-03-03T10:01:38.840Z
  • quote: “已用 sessions_list(activeMinutes=1440) 拉取过去24h活跃 session，并逐个用 sessions_history(limit=50) 扫描”
• 证据2：gap 库被真实落盘更新（不是停在口头）。
  • sessionKey: agent:main:cron:72b13206-d958-428d-bcd1-e32a8dd44c84
  • time: 2026-03-03T10:01:18.636Z
  • quote: “Successfully replaced text in …/memory/skill-gaps.md.”
• 证据3：存在“信号分类规则”文件，说明不是随便抓关键词，而是先定义口径。
  • sessionKey: agent:main:cron:72b13206-d958-428d-bcd1-e32a8dd44c84
  • time: 2026-03-03T10:00:58.715Z
  • quote: “# 信号分类规则 Agent 自进化系统通过扫描对话记录来识别能力缺口。”

# 错误尝试 / 失败点

1. 只在出事故时复盘：平时的小摩擦（429、fetch failed、timeout、命令不存在）没被记录，最后变成“事故突然发生”。
2. 没有信号分类规则：今天说“需要更稳定”，明天说“需要更自动化”，无法聚类、无法排序。
3. 只生成一次清单：一次性的 gap 清单很快过期；你需要“每天/每周增量更新”的节奏。
4. gap 不落盘：只在聊天里说，下一轮又从 0 开始。

# 关键转折

从“复盘会”转为“采集系统”，关键是两点：

• 定义信号口径：什么算 gap？什么不算？（例如：重复出现的错误字符串、手动补跑、频繁求助等）
• 用会话数据作为唯一证据来源：减少主观争论，让改进更像工程问题。

# 可复用 SOP（建议每周一次，或者每天轻量跑）

1. 准备规则文件 signal-rules（文件名 Unknown，可按团队习惯）：
   • 信号类型：报错类（429/fetch failed/timeout）、流程卡点类（需要人点一下）、质量类（输出被退回）等
   • 每类信号的“判定条件”与“记录字段”（至少含：sessionKey、时间、quote 摘要）
2. 拉取样本：
   • sessions_list(activeMinutes=1440) 取过去 24h 活跃会话
   • 对每个会话 sessions_history(limit=50) 扫描最近记录
3. 抽取：命中规则就写入候选 gap（含证据三元组）。
4. 去重与聚类：
   • 按“错误模式/工具/链路”聚类
   • 同类 gap 合并证据，保留最新一次 + 最典型一次
5. 写入长期库：memory/skill-gaps.md（或团队知识库），并标记：
   • 新增/已存在/已解决（Unknown：如何判定“已解决”取决于你们的回归验证机制）
6. 产出行动项：每个 gap 至少对应一个“下一步动作”（写脚本/补 SOP/加监控/加兜底）。

# 课后作业

1. 用你们最近一周的聊天/日志（哪怕是手工复制）做一次“信号分类”：把出现频率最高的 3 类问题列出来。
2. 给每类问题定义一个可机读的判定条件（例如包含某个错误字符串、某个工具返回 error）。
3. 做一个最小版 gap 库（markdown 就够），每条 gap 至少带 2 条证据（时间+原句摘要）。
4. 思考题：如果某类问题的证据不足（例如只出现一次），你是把它标成“待观察”，还是立即行动？写出你的规则；不确定就写 Unknown。