Appearance
自进化机制
好的 Harness 不只是被维护，它自己会变强。自进化是三层递进的：自修复 → 自迭代 → 自简化。
三层进化
Level 1: 自修复 (Reactive)
失败 → 匹配已知方案 → 自动修复
前提: Solution 库 + 日志系统
Level 2: 自迭代 (Proactive)
日志分析 → 发现模式 → 提出改进
前提: 20+ 次运行数据 + L2/L3 日志
Level 3: 自简化 (Meta)
模型升级 → 测试约束必要性 → 退休过时组件
前提: 成熟的 Harness + 衰减检测实验Level 1: 自修复
原理
每次修复一个新问题，都在 solutions/ 留下记录。下次遇到相同问题，系统先搜索已知方案再尝试自动修复。随着 solution 库积累，自修复比例逐渐上升。
实现流程
Pipeline Phase 执行
│
├─ 成功 → 正常继续
│
└─ 失败 → 进入自修复流程
│
├─ 1. 提取错误特征
│ error_type: 'api_error' | 'quality_failure' | 'timeout' | 'validation'
│ error_message: 错误消息关键词
│ phase: 失败的 phase 名
│
├─ 2. 搜索 solutions/
│ grep -l "$error_type\|$keyword" docs/harness/solutions/*.md
│
├─ 3a. 匹配到 solution
│ → 读取 ## Solution 部分
│ → 按步骤执行修复
│ → 重试该 phase
│ → 成功? → 日志记录 "auto-repaired via solution X"
│ → 失败? → 上报人类 + 在 solution 中记录修复无效的情况
│
└─ 3b. 未匹配
→ 尝试自行修复（agent 的通用能力）
→ 成功? → 在 solutions/ 创建新记录
→ 失败? → 上报人类 → 人工修复后补充 solution效果追踪
在 quality-tracker.jsonl 中记录自修复事件：
jsonl
{"date":"2026-04-08","topic":"x","autoRepaired":true,"solutionUsed":"hero-image-fallback","retryCount":1}长期追踪自修复率：auto_repaired_count / total_failure_count
参考模型
AutoAgent 的 hill-climbing:
- 每次修改后跑 benchmark
- 分数提升 → 保留修改
- 分数下降 → 回滚
Compound Engineering 的 compound 步骤:
- 每次工作循环后显式记录学到的模式
- 下一个循环自动继承
Level 2: 自迭代
原理
积累足够的运行数据后，分析日志发现系统性问题和改进机会。这不是修复单次故障，而是改进整个系统。
分析维度
1. 质量趋势
最近 20 次运行平均分: 68 → 62 (下降中)
→ 调查: 哪个评分维度在下降?
→ 发现: typography 分从 18 降到 12
→ 根因: 上周改了 font preset，新字体搭配不好
→ 行动: 更新 ADR-004，调整 font pairing2. 性能退化
content_gen phase 平均耗时: 12s → 18s (过去两周)
→ 调查: LLM 调用次数变了? 模型变了? 输入变长了?
→ 发现: 切换模型后，新模型首 token 延迟更高
→ 行动: 评估性价比，决定是否换回或接受3. 成本异常
本周 token 消耗比上周翻倍
→ 调查: 哪个 phase 消耗最多?
→ 发现: judge phase 增加了第二轮评判，token 翻倍
→ 行动: 评估第二轮评判是否真的提升质量，否则移除4. 重复故障
"429 rate limit" 错误本月出现 8 次
→ 检查: 有没有对应的 solution?
→ 有，但 solution 中的重试策略不够
→ 行动: 更新 solution，增加 stagger delay触发方式
| 方式 | 频率 | 适合谁 |
|---|---|---|
| 手动分析 | 每周 | 个人项目 |
| Scheduled Agent | 每 N 次运行 | 团队项目 |
| CI 触发 | 每次部署 | 生产系统 |
产出
自迭代分析的输出是以下之一：
- 新 ADR（发现了需要记录的决策）
- 更新 Solution（改进已有修复方案）
- 调参（修改 pipeline 配置）
- 无操作（一切正常，记录分析结论即可）
Level 3: 自简化（衰减检测）
原理
Harness 的每个组件（约束、workaround、检查）都是对模型能力边界的假设。当模型升级后，某些假设不再成立。好的 Harness 会检测并退休过时组件，而非无限膨胀。
"Harness 组件的每一个都代表了一种假设——关于模型还不能做什么。这些假设会以不同速率衰减。" — Anthropic, Harness Design for Long-Running Apps
衰减检测实验
1. 选择一个约束 C（例如 "禁止使用 Inter 字体"）
2. 准备测试任务 T（一个典型的页面生成任务）
3. 运行两次:
- A: 启用约束 C → 得到质量分 Score_A
- B: 禁用约束 C → 得到质量分 Score_B
4. 比较:
- Score_B >= Score_A → 约束 C 可能不再需要
- Score_B < Score_A → 约束 C 仍然有价值
5. 如果 Score_B >= Score_A:
- 在多个不同任务上重复验证
- 通过后: 在 ADR 中标记 status: deprecated
- 在 CLAUDE.md 中移除该约束衰减速度分级
| 衰减速度 | 类型 | 示例 |
|---|---|---|
| 快衰减 | 模型能力补丁 | "不要把 JSON 放在代码块外" — 新模型已修复 |
| 中衰减 | 质量约束 | "不使用 Inter 字体" — 新模型可能自己选更好的字体 |
| 慢衰减 | 架构决策 | "Judge/Fix 分离" — 自评能力改善缓慢 |
| 不衰减 | 领域知识 | "我们的品牌色是 #3B82F6" — 模型无法猜测 |
维护节奏
- 模型升级时: 对快衰减约束做衰减检测
- 每季度: 对中衰减约束做衰减检测
- 每年: 审视慢衰减约束是否仍合理
进化的反馈闭环
┌─────────────────────────────────────────────┐
│ Pipeline 运行 │
│ research → kit → content → judge → fix │
└──────────────┬──────────────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ L1 日志记录 │
│ Phase 级 JSONL + LLM 调用记录 │
└──────────────┬──────────────────────────────┘
│
┌──────┼──────────────────────┐
▼ ▼ ▼
┌─────────────┐ ┌──────────┐ ┌──────────┐
│ L1: 自修复 │ │ L2: 汇总 │ │ L2: 汇总 │
│ 失败→搜索 │ │ Run 级 │ │ Tracker │
│ solution→修 │ │ 日志 │ │ 追加 │
└──────┬──────┘ └─────┬────┘ └─────┬────┘
│ │ │
│ └──────┬──────┘
│ │
│ ▼
│ ┌───────────────────────┐
│ │ L2: 自迭代 │
│ │ 分析趋势 → 提出改进 │
│ └────────────┬──────────┘
│ │
▼ ▼
┌──────────────────────────────────────────┐
│ 知识库更新 │
│ 新 Solution / 更新 ADR / 调参 / 新 Playbook │
└──────────────────────────────────────────┘
│
▼ (模型升级时)
┌──────────────────────────────────────────┐
│ L3: 自简化 │
│ 衰减检测 → 退休过时约束 → Harness 瘦身 │
└──────────────────────────────────────────┘成熟度模型
| 阶段 | 标志 | 自进化能力 |
|---|---|---|
| Level 0 | 没有 harness，每次从零开始 | 无 |
| Level 1 | CLAUDE.md + 基本约束 | 人工维护 |
| Level 2 | 日志 + Solution 库 | 自修复（匹配已知方案） |
| Level 3 | 趋势分析 + 改进提案 | 自迭代（发现和解决系统性问题） |
| Level 4 | 衰减检测 + 组件退休 | 自简化（Harness 不会无限膨胀） |
大多数项目达到 Level 2 就能显著提升效率。Level 3-4 适合长期运行的复杂系统。