self-improve

自我改进编排器

用于代码演进式改进的自主循环控制器。管理完整生命周期：设置、研究、规划、执行、锦标赛式筛选、历史记录和停止条件评估。

适用场景

• 你希望通过迭代改进代码库，以达到可量化的基准目标
• 优化任务：性能、打包体积、测试覆盖率、准确率
• 通过可量化的指标改进代码质量

不适用场景

• 没有可量化的基准
• 一次性修复或功能需求 → 使用 /omg-autopilot
• 手动交互式编码 → 使用 /ralph

自主执行策略

改进循环期间绝不停止或暂停并向用户提问。 门槛检查通过并且循环开始后，必须全程自主运行，直至满足停止条件。

• 不要在迭代之间请求确认
• Agent 失败时：重试一次，然后跳过并继续
• 所有计划均被拒绝时：记录此事，然后继续下一轮
• 只有第 11 步中的停止条件会终止循环

状态跟踪

所有状态都保存在 .omc/self-improve/ 下：

.omc/self-improve/
├── config/
│   ├── settings.json          # agents, benchmark, thresholds, sealed_files
│   ├── goal.md                # Improvement objective + target metric
│   ├── harness.md             # Guardrail rules (H001/H002/H003)
│   └── idea.md                # User experiment ideas
├── state/
│   ├── agent-settings.json    # iterations, best_score, status, counters
│   ├── iteration_state.json   # Within-iteration progress (resumability)
│   ├── research_briefs/       # Research output per round
│   ├── iteration_history/     # Full history per round
│   ├── merge_reports/         # Tournament results
│   └── plan_archive/          # Archived plans (permanent)
├── plans/                     # Active plans (current round)
└── tracking/
    ├── raw_data.json          # All candidate scores
    ├── baseline.json          # Initial benchmark score
    └── events.json            # Config changes

Agent 映射

步骤	角色	Agent	用途
研究	代码库分析	@explore + @architect	生成假设
规划	假设 → 计划	@planner	为每个 Agent 制定结构化计划
架构审查	6 点审查	@architect	提供建议性审查
评审员审查	执行约束	@critic	批准或拒绝计划
执行	实现 + 基准测试	@executor	忠实地实施计划
Git 操作	合并/标记/PR	@git-master	原子化合并操作

设置阶段

1. 检查目标仓库路径是否存在。如果尚未配置，则询问用户。
2. 创建 .omc/self-improve/ 目录结构。
3. 读取 agent-settings.json。检查设置标记。
4. 信任确认（必需）：
   • 显示目标仓库路径，并请用户确认执行基准测试。
   • 如果用户拒绝：中止。
   • 记录同意状态：trust_confirmed: true
5. 如果尚未设置目标 → 运行苏格拉底式访谈（目标、指标、目标值、范围）。写入 goal.md。
6. 如果尚未设置基准 → 调查仓库，创建或封装基准，验证 3 次，并记录基线。
7. 如果尚未设置约束框架 → 确认默认约束规则（H001/H002/H003）。
8. 门槛：所有设置和信任确认都必须为真。
9. 从目标分支创建改进分支：improve/{goal_slug}。
10. 使用 omg_write_state 写入初始状态。

改进循环

门槛：所有设置都必须为真。持续执行，不得停止。

第 0 步 — 清理陈旧工作树

移除之前迭代遗留的孤立工作树。

第 1 步 — 刷新状态

更新状态以重置 TTL。

第 2 步 — 检查停止请求

如果状态已清除或状态为 user_stopped：正常退出。

第 3 步 — 检查用户想法

读取 idea.md。如果内容非空，则传递给规划 Agent。

第 4 步 — 研究

启动 @explore + @architect，根据目标、历史记录和先前简报分析代码库并生成假设。

第 5 步 — 规划

并行启动 N 个 @planner Agent（N = number_of_agents）。每个 Agent 都会提出一项可测试假设，并附上 approach_family 标签和 history_reference。

第 6 步 — 审查

针对每项计划：

• 6a. 架构审查：@architect 使用 6 点检查清单审查（可测试性、新颖性、范围、目标文件、实现清晰度、预期结果）。仅提供建议。
• 6b. 评审员审查：@critic 根据约束规则审查（H001：一项假设；H002：approach_family 连续出现次数不得 ≥3；H003：轮次内多样性）。设置 critic_approved: true/false。

第 7 步 — 执行

针对每项获批计划，并行启动 @executor。每个 executor 都在 Git 工作树中工作，实施计划、运行验证并进行基准测试。

步骤 8 — 锦标赛式选择

1. 收集结果，筛选出 status: "success"
2. 按 benchmark_score 排序（遵循其方向）
3. 对每个候选方案（从最佳开始）：
   • 对照 best_score 检查是否存在回退
   • 通过 @git-master 使用 --no-ff 合并
   • 在合并后的状态下重新运行基准测试
   • 若确认无误：接受胜出方案并退出循环
   • 若发生回退：还原合并，尝试下一个
   • 若发生冲突：中止合并，尝试下一个
4. 归档未胜出的分支

步骤 9 — 记录与可视化

记录迭代历史，更新 agent-settings（分数、平台期计数、熔断器），追加跟踪数据。

步骤 10 — 清理

移除 worktree，将迭代状态更新为 completed。

步骤 11 — 检查停止条件

条件	检查方式
用户停止	status == "user_stopped"
达到目标	best_score 达到或超过 target_value
平台期	plateau_consecutive_count >= plateau_window
最大迭代次数	iterations >= max_iterations
熔断器	circuit_breaker_count >= circuit_breaker_threshold

如果没有满足任何停止条件：立即返回步骤 1。

可恢复性

调用时：

1. 始终运行步骤 0（清理过期 worktree）
2. 检查 agent-settings.json：
   • user_stopped：询问是否恢复
   • running：已崩溃 — 自动恢复
   • idle：全新启动
3. 检查 iteration_state.json：如果正在进行中，则从上一步恢复

完成

1. 更新最终状态
2. 打印摘要（状态、迭代次数、最佳分数、基线、提升百分比）
3. 运行 /cancel 以彻底清理状态

方法类别体系

每个计划必须且只能标记为以下一类：

标签	描述
architecture	模型/组件结构变更
training_config	优化器、LR、调度器、批量大小
data	数据加载、增强、预处理
infrastructure	混合精度、分布式训练
optimization	算法/数值优化
testing	评估方法变更
documentation	仅文档变更
other	不属于以上类别