Double Evolution

double-evolution — 双速技能进化引擎

吸收自：MOMO CODE × Pioneer Agent（§2.1-§2.8, §21.4）

核心范式：将 LLM 权重级的双速进化（KEP + MCGS + LoRA）适配到 Hermes 技能的 prompt/procedure 级进化。

架构

┌──────────────────────────────────────────────────────────┐
│                  双速技能进化引擎                          │
│                                                          │
│  Fast Loop (/evolve，手动触发)                             │
│  ┌────────────────────────────────────────────┐          │
│  │ observe → distill → inject → solidify      │          │
│  │  扫描      蒸馏      注入      固化         │          │
│  │  signals  →tactics →patches →feedback      │          │
│  └────────────────────────────────────────────┘          │
│                      │ Bridge                            │
│                      ↓                                   │
│  Slow Loop (Cron 30min，自动)                             │
│  ┌────────────────────────────────────────────┐          │
│  │ mine → evaluate → gate → report            │          │
│  │ 聚合    三维评测   Ratchet  飞书提案        │          │
│  └────────────────────────────────────────────┘          │
│                                                          │
│  数据层: ~/.hermes-feishu/evolution/                      │
│  ├── signals.jsonl    ← 原始信号（append-only）           │
│  ├── tactics.jsonl    ← 蒸馏出的策略卡片                  │
│  ├── patches.jsonl    ← 候选/已应用 patch                │
│  └── ledger.jsonl     ← 审计日志                         │
└──────────────────────────────────────────────────────────┘

触发条件

命令触发

上下文触发

当用户说以下内容时自动加载本技能：

• "技能进化" / "进化技能" / "优化技能"
• "看看哪些技能该优化了" / "技能自进化"

命令详细流程

1. /evolve status — 进化状态仪表盘

目标：展示所有已追踪技能的健康状态。

流程：

1. 读取 ~/.hermes-feishu/evolution/tactics.jsonl
2. 读取 ~/.hermes-feishu/evolution/patches.jsonl
3. 按技能聚合统计：
   • 信号总数（近 7 天 / 近 30 天）
   • 成功率（pass / total）
   • 候选 tactic 数
   • 已注入 patch 数
   • 已固化 patch 数

输出格式：

## 技能进化仪表盘

| 技能 | 7天信号 | 成功率 | 候选tactic | 已注入 | 已固化 |
|------|:------:|:------:|:----------:|:------:|:------:|
| feishu-doc | 23 | 78% | 3 | 1 | 0 |
| answer | 15 | 87% | 1 | 0 | 0 |
| github-absorb | 8 | 75% | 2 | 1 | 0 |

### 需要关注的技能
- **feishu-doc**: 成功率 < 80%，3 个候选 tactic 待注入 → 建议 `/evolve inject`
- **github-absorb**: 有 1 个已注入 patch 待 solidify → 建议 `/evolve solidify`

2. /evolve observe — 扫描信号

目标：从 signals.jsonl 中提取近期失败模式。

流程：

1. 读取 signals.jsonl，筛选近 7 天的信号
2. 按 skill + outcome 分组
3. 识别高频失败模式（同一组 ≥ 3 条）
4. 对每次失败，加载原始 session 上下文（session_search）
5. 输出聚类报告

输出格式：

## 信号扫描报告 ({日期})

### 发现的失败模式

#### feishu-doc
- **user_corrected × 5**: 创建文档时标题格式错误
  - s_001: "标题应包含日期" → 触发词"创建文档"不够精确
  - s_012: "缺少 --parent-token" → 未在上下文中提供 Wiki 节点
  - ...

#### github-absorb
- **rejected × 3**: Phase 4 吸收策略矩阵与用户预期不一致
  - s_008: 用户选了"只记录参考"但技能继续推进 Phase 5
  - ...

### 聚类摘要
- 总计: 42 条信号，识别 4 个失败模式
- feishu-doc (2) / github-absorb (1) / answer (1)

3. /evolve distill — 蒸馏候选 patch

目标：对 observe 识别的失败模式，生成可执行的 patch 建议。

流程：

1. 对每个高频失败模式（≥ 3 条信号）
2. 读取对应技能 SKILL.md 全文
3. 分析根因：是触发词问题？流程缺失？输出去向不明？
4. 调用 LLM 生成候选 patch（old_string → new_string）
5. 检查去重：相同 old_string 的 patch 是否已存在于 tactics.jsonl
6. 写入 tactics.jsonl（status=candidate，alpha=1，beta=1）

🔴 CHECKPOINT：生成的 patch 必须满足——

• old_string 在技能文件中唯一存在
• new_string 保留原有功能，只增加/调整
• 不改变技能的核心架构

输出格式：

## 蒸馏结果 ({日期})

### 新候选 tactic

| # | 技能 | 类型 | 标题 | 成功率预估 |
|---|------|------|------|:--------:|
| t_001 | feishu-doc | trigger_addition | 添加"新建飞书文档"触发词 | — |
| t_002 | github-absorb | checkpoint_add | Phase 3 后加用户确认检查点 | — |
| t_003 | answer | flow_reorder | Clarify 跳过逻辑前置 | — |

### 去重命中
- t_004 (answer trigger_addition) 与已有 t_a1b2c3d4 重复 → 已跳过

4. /evolve inject — 注入 patch

目标：Thompson 采样选择最优候选 tactic，生成 patch 预览，人工确认后执行。

流程：

1. 读取 tactics.jsonl，筛选 status=candidate 的 tactic
2. 对每个 tactic，计算 Beta(α, β) 随机采样值
3. 选择采样值最高的 tactic
4. 展示 patch 预览（diff 格式）
5. 等待用户确认

🔴 CHECKPOINT：应用前必须展示预览并等待确认。

5. 用户确认后：
   • 执行 skill_manage(action='patch', name='{skill}', old_string='...', new_string='...')
   • 写入 patches.jsonl（action=applied）
   • 更新 tactics.jsonl（status=injected）
   • 写入 ledger.jsonl（kind=inject）

输出格式：

## 注入预览 — t_{id}

**技能**: feishu-doc
**类型**: trigger_addition
**标题**: 添加"新建飞书文档"触发词
**Thompson 采样**: Beta(α=3, β=1) → sample=0.81
**胜率预估**: 75%

### 变更预览

```diff
 triggers:
   - "创建飞书文档"
   - "写飞书文档"
   - "创建文档"
+  - "新建飞书文档"

确认注入？(y/n)

### 5. `/evolve solidify` — 固化反馈

**目标**：收集注入后 patch 的表现反馈，更新 Beta 分布。

**流程**：
1. 读取 patches.jsonl，筛选 status=injected 且未 solidify 的 patch
2. 读取对应 tactic 的后续信号（注入后的 signals）
3. 展示每个 injected patch 注入前后对比
4. 询问用户评价

**用户评价选项**：
- `好用` → tactic.alpha += 1，记录信号
- `不好用` → tactic.beta += 1，记录信号
- `没感觉` → tactic.alpha += 0.5，tactic.beta += 0.5

**门禁规则**：
- alpha + beta ≥ 5 且 alpha/(alpha+beta) ≥ 0.7 → status = solidified
- alpha + beta ≥ 5 且 alpha/(alpha+beta) < 0.5 → status = rejected（触发自动回滚）
- 否则保持 injected

**自动回滚**：当 tactic 被 rejected 时——
- 读取对应 patch，执行 `skill_manage(action='patch')` 反向回滚
- 写入 patches.jsonl（reverted=true）
- 写入 ledger.jsonl（kind=rollback）

**输出格式**：

```markdown
## 固化反馈

| # | 技能 | Tactic | 注入时间 | 注入后信号 | 当前胜率 | 状态 |
|---|------|--------|---------|:--------:|:--------:|------|
| 1 | feishu-doc | trigger_addition | 3h前 | 4 pass, 1 fail | 80% | → solidified |

### 待评价
| # | 技能 | Tactic | 操作 |
|---|------|--------|------|
| 2 | github-absorb | checkpoint_add | 好用 / 不好用 / 没感觉 |

Slow Loop（Cron 30min）

Slow Loop 由独立的 cron job 驱动，不依赖本技能的手动触发。

流水线

每 30 分钟执行:
  ① Mine:
     - 读取 signals.jsonl（自上次运行后的新信号）
     - 按 skill 聚合，识别高频失败模式（≥5 次）
  
  ② Evaluate:
     - 对每个 solidifiable tactic：
       - 创建技能副本 ~/.hermes-feishu/skills/_eval/{skill}_v{n}/
       - 应用 patch
       - 调用 skill-evaluator 三维对比
         · 执行精准度 (precision)
         · 端到端时效 (timeliness)
         · 计算成本 (cost)
  
  ③ Gate (Ratchet):
     - 只保留三维评分全部 ≥ 原版的 patch
     - 任一维度退化 → 标记 rejected + 自动回滚
     - 通过 → 标记 promoted + 发送飞书通知
  
  ④ Report:
     - 生成飞书文档《技能进化提案 {日期}》
     - 每个提案：
       · 技能名 / 问题描述 / 建议 patch / 预期改善 / 风险
     - 发送到当前 DM

Cron 创建命令

⚠️ 重要：cronjob API 的 repeat 默认为 once（只跑一次）。创建持续循环的 Slow Loop 时必须显式传 repeat=0（= forever）或后续用 update 修正。

# 首次初始化时执行（技能加载后自动触发）
cronjob create \
  --name "hermes-evolution-slow-loop" \
  --schedule "30m" \
  --repeat 0 \
  --skills "double-evolution,skill-evaluator" \
  --prompt "加载 double-evolution 技能，执行 Slow Loop 流水线：Mine→Distill→Evaluate→Gate→Report"

验证创建成功：

cronjob list | grep evolution
# 确认 repeat=forever，非 once

如已创建为 once，用 cronjob update --job-id <id> --repeat 0 修正。

技能间关系

数据文件位置

信号采集（通过技能引用）

本技能不要求在其他技能 SKILL.md 中嵌入信号采集代码。改为更轻量的引用模式：

方式：技能引用 + Agent 自主记录

1. 核心技能声明关联：在目标技能的 related_skills 中添加 double-evolution。当 Agent 加载该技能时，会同时知道此技能被进化系统追踪。

2. Agent 自主记录：当 Agent 在会话中使用被追踪的技能时，根据以下 schema 在 ~/.hermes-feishu/evolution/signals.jsonl 追加一行记录：

{"id":"s_{uuid8}","ts":"{ISO8601}","session_id":"{chat_id}","skill":"{skill_name}","trigger":"hit|miss|false_trigger","outcome":"pass|multi_iteration|user_corrected|rejected|not_used","iterations":{N},"corrections":{N},"user_feedback":"","duration_s":{秒},"context":{"task_summary":"{一句话总结}"}}

记录时机

Agent 在以下时刻隐性记录信号（不打断对话、不向用户展示）：

• 技能产出被直接使用，无修改 → outcome=pass → 会话结束或切换技能时记录
• 用户要求修改 ≥2 次 → outcome=multi_iteration → 最终产出被接受时记录
• 用户明确指出错误 → outcome=user_corrected → 修正完成后记录
• 用户否定方向 → outcome=rejected → 切换策略时记录
• 技能触发但产出未被使用 → outcome=not_used → 会话结束或超时记录

已关联技能

以下技能已声明 double-evolution 关联（共 91 个，全量追踪 jorinyang/awesome-skills 仓库）。

🧠 方法论 (20)：advanced-elicitation、author-methodology-analysis、blue-team、book-deconstruct、darwin-skill、deep-think、domain-decompose、edge-case-hunter、editorial-review-prose、editorial-review-structure、external-skill-evaluation、github-absorb、ljg-elicitation-modes、ljg-infographic-design、ljg-writing-voice、opportunity-solution-tree、pm-prioritization-frameworks、qa-extract、relationship-analysis、stakeholder-mapping

🏗️ 构建与设计 (22)：answer、answer-standalone、architecture-diagram、brandkit、claude-design、design-md、drawio-generation、feishu-html、fireworks-tech-graph、hallmark、html-ppt、huashu-design、humanizer、pretext、redesign-skill、requesting-code-review、requirement-alignment-analysis、sketch、strategy-plan-writing、taste-skill、writing-plans、dynamic-workflow

🔧 开发工程 (11)：agent-native-cli-design、coding-agents、cross-project-adaptation、dingtalk-cli、github-release-readme、hermes-instance-sync、subagent-driven-development、supabase-backend、technical-documentation-production、test-driven-development、wsl-browser-cdp

🤖 AI 工程 (5)：agent-tool-system、benchmark-generator、double-evolution、skill-ab-test、skill-evaluator

📱 平台工具 (1)：feishu-voice

📋 飞书系列 (5)：feishu-doc、feishu-table、feishu-wiki、project-kanban、zhike-task-hub

🏔️ 贵州之客 (18)：amap-lbs、cost-engine、customer-view、guide-exec、jimeng-video、supply-check、travel-intel、travel-itinerary、travel-workflow、trip-archive、trip-briefing、trip-landing、trip-quote、vendor-brief、wechat-article-archive、zhike-content-output、windows-troubleshooting-from-wsl、ocr-and-documents

🔬 研究 (4)：ara-compiler、ara-research-manager、ara-rigor-reviewer、systematic-debugging

🎨 创意内容 (6)：baoyu-article-illustrator、baoyu-comic、baoyu-cover-image、baoyu-infographic、baoyu-translate、image-analysis

新增技能：① 在新技能的 related_skills 加 double-evolution；② 更新上方的分类列表。批量同步：当追踪列表与仓库脱节时，用 references/bulk-sync.md 脚本一键对齐全部技能。

反例（禁止）

• ❌ 跳过 observe 直接 distill — 没有信号基础的蒸馏是瞎猜
• ❌ 注入 patch 时不展示预览 — 用户必须有确认机会
• ❌ solidify 时只看 pass/fail 计数不看语义 — 需要分析失败的具体原因
• ❌ Slow Loop 自动 promote 不通知用户 — 所有 promote 必须经过飞书提案
• ❌ 对同一技能同时注入 ≥2 个未 solidify 的 patch — 无法归因哪个有效
• ❌ 手动修改 signals.jsonl / ledger.jsonl — 破坏审计完整性
• ❌ 把本技能用于非技能文件的修改 — 进化范围严格限定在 SKILL.md
• ❌ 在目标技能 SKILL.md 中嵌入信号采集代码 — 应使用 related_skills 声明关联，Agent 自主记录信号。嵌入代码污染技能文件且无法统一管理
• ❌ 在被追踪技能中嵌入信号采集代码 — 应通过 related_skills 引用方式，由 Agent 自主记录信号。用户明确纠正过此错误（已回滚嵌入方案）
• ❌ 在其他技能 SKILL.md 中嵌入信号采集代码块 — 用户明确拒绝此方案。正确做法是核心技能在 related_skills 中声明 double-evolution，Agent 按本技能 schema 自主记录信号到 signals.jsonl。已嵌入的必须回滚。
• ❌ 创建 Slow Loop Cron 时不指定 repeat — cronjob(action='create') 默认 repeat='once'（只跑一次）。必须显式传 repeat=0（forever）或正整数。否则 30 分钟后 cron 静默停止，进化中断
• ❌ 创建 Slow Loop Cron 时不检查 repeat 参数 — 默认 once 只跑一次，必须显式 repeat=0 设为 forever
• ❌ 让追踪列表与仓库脱节 — 新增技能到 awesome-skills 时必须同步：① 在新技能的 related_skills 加 double-evolution；② 更新本文件的"已关联技能"列表。批量同步脚本见 references/bulk-sync.md

异常与边界条件