企业官网建设流程全解析

oh-my-claudecodeself-improve命令解析：轻量分发与自主进化优化循环

【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode

本篇技术指南聚焦 oh-my-claudecode（OMC）中的/oh-my-claudecode:self-improve命令：它是一条"兼容性命令"，用最轻量的方式让该命令在每一个 Claude Code 会话中都可用，而无需在每个会话加载完整的self-improveskill 描述。读者将掌握它的分发机制、插件/安装定位回退策略，以及它真正驱动的"自我改进"引擎——一条从目标澄清、基准构建、研究-规划-评审-执行到锦标赛式优胜劣汰选出的全自主优化循环，可用于对任意目标仓库进行可量化指标的持续进化。

为什么需要一条"兼容性命令"

在 oh-my-claudecode 中，能力以 skill 形式存在，而 skills/self-improve/SKILL.md 是一个level: 4的完整自主编排指令，包含了设置、研究、规划、执行、锦标赛选择、历史记录、可视化与停止条件判断等一整套循环协议。如果每个会话都默认加载这一整段描述，会显著增加上下文占用与开销。

commands/self-improve.md 定义的正是解决该问题的产物：一条"兼容性命令"（compatibility command）。它的目的是：

在不于每个 Claude Code 会话加载完整self-improveskill 描述的前提下，保持/oh-my-claudecode:self-improve命令可用。

也就是说，命令文档本体刻意保持轻薄（front-matter 中description为空、正文只有分发指令），真正的内容在按需读取时才注入。这一模式也存在于 commands/ 目录的其他命令（如ask.md、remember.md、hud.md、psm.md等，它们同样使用$ARGUMENTS占位约定）。

命令分发机制（Dispatch）

当用户在会话中触发/oh-my-claudecode:self-improve时，命令按以下两步执行：

1. 读取完整的内置 skill 指令：从当前活跃的 OMC 插件/安装中读取skills/self-improve/SKILL.md。
2. 严格按其执行：把用户传入的参数视为$ARGUMENTS，原样交给 SKILL.md 协议处理。

$ARGUMENTS是 OMC 命令/skill 体系中的标准占位符约定（参见 src/commands/index.ts 与 src/hooks/auto-slash-command/executor.ts 中的同类用法），代表用户在斜杠命令后输入的原始参数文本。

定位回退链：若skills/self-improve/SKILL.md无法从当前工作目录直接读取，命令需依次在以下位置查找：

1. 活跃的CLAUDE_PLUGIN_ROOT/OMC_PLUGIN_ROOT环境变量指向的插件根目录；
2. package 根目录；
3. 已安装的 OMC 插件目录。

仓库中大量脚本以这两种环境变量为锚点（例如 scripts/lib/hud-wrapper-template.txt 中 OMC_PLUGIN_ROOT 为最高优先级、scripts/lib/hook-command-normalizer.mjs 使用$CLAUDE_PLUGIN_ROOT/scripts/run.cjs作为 hooks 前缀），说明 OMC 安装/插件体系把这两类根路径作为解析内置资源的事实标准。

命令真正触发的内容：自主进化编排循环

命令执行的核心是完整读取并遵循 skills/self-improve/SKILL.md。该文档描述了一个"带锦标赛选择的自主进化式代码改进引擎"（Autonomous evolutionary code improvement engine with tournament selection）。作为编排控制器，它管理完整的生命周期并委托给专门的 OMC agent。

自主执行策略与信任边界

一旦设置检查通过、循环开始，控制器全程自主运行，绝不中途停下来向用户提问：

• 单次失败仅重试一次，随后跳过该 agent 继续；
• 所有计划被拒、所有执行失败、基准错误均只记录并继续下一轮迭代；
• 循环停止的唯一依据是 Step 11 的停止条件；
• 信任边界：循环只按原样在被改进仓库内运行基准命令，不安装包、不修改系统配置、不访问额外网络资源；
• 密封文件（sealed files）：scripts/validate.sh 强制基准代码不可被循环修改，防止评估机制被自我改写。

状态目录布局

所有产物位于通过 scripts/resolve-paths.mjs 解析出的<self-improve-root>下。解析规则可从源码确认（scripts/resolve-paths.mjs）：

• 新运行默认落到.omc/self-improve/topics/default/；
• 指定 topic/slug 时落到.omc/self-improve/topics/{topic_slug}/；
• 传入--session-id或存在OMC_SESSION_ID时进一步隔离为topics/<slug>/sessions/<sid>/，避免并行运行冲突；
• 未指定 topic 且扁平布局已存在时，旧的.omc/self-improve/仅作为兼容回退保留；
• 状态根解析顺序为OMC_STATE_DIR > .omc-workspace > git > cwd（可参考 docs/REFERENCE.md）。

完整目录树：

<self-improve-root>/ ├── config/ # 用户配置 │ ├── settings.json # agents、benchmark、阈值、sealed_files │ ├── goal.md # 改进目标 + 目标指标 │ ├── harness.md # 护栏规则（H001/H002/H003） │ └── idea.md # 用户实验想法 ├── state/ # 运行时状态 │ ├── agent-settings.json # iterations、best_score、status、counters │ ├── iteration_state.json # 迭代内进度（可续跑） │ ├── research_briefs/ # 每轮研究输出 │ ├── iteration_history/ # 每轮完整历史 │ ├── merge_reports/ # 锦标赛结果 │ └── plan_archive/ # 已归档计划（永久） ├── plans/ # 活跃计划（当前轮） └── tracking/ # 可视化数据 ├── raw_data.json # 全部候选得分 ├── baseline.json # 初始基准分 ├── events.json # 配置变更 └── progress.png # 生成的图表

OMC 模式生命周期状态记录在.omc/state/sessions/{sessionId}/self-improve-state.json。

角色映射：谁在循环中做什么

所有增强均通过在 spawn 时的 Task 描述上下文注入，不改动任何既有 agent .md 文件。技能内置的补充提示词文件作为独立 agent 的 prompt：

研究 agent 的 prompt 取自si-researcher.md，基准构建 agent 的 prompt 取自si-benchmark-builder.md，目标澄清由控制器直接读取si-goal-clarifier.md以交互式执行。

输入文件清单

每次启动及每轮迭代开始需读取以下文件：

settings.json 关键配置模板

仓库中的 templates/settings.json 给出了可直接使用的默认值：

{ "si_claude_setting": false, "number_of_agents": 3, "number_of_max_critics": 3, "current_repo_url": "", "fork_url": "", "upstream_url": "", "topic_slug": "default", "target_branch": "main", "benchmark_command": "", "benchmark_format": "json", "benchmark_direction": "higher_is_better", "max_iterations": 50, "plateau_threshold": 0.01, "plateau_window": 3, "target_value": null, "primary_metric": "primary", "sealed_files": [], "regression_threshold": 0.05, "circuit_breaker_threshold": 3, "auto_push": false, "auto_pr": false }

关键字段语义：

• number_of_agents：每轮并行 planner/executor 的数量（默认 3）；
• benchmark_format：json/number/pass_fail；
• benchmark_direction：higher_is_better或lower_is_better，决定排序与回归判断方向；
• max_iterations/plateau_threshold/plateau_window/circuit_breaker_threshold：共同定义循环终止条件；
• sealed_files：数组，列出不允许循环修改的文件（如基准脚本），validate.sh 会在执行前校验；
• auto_push/auto_pr：默认false，即合并后默认不推送、目标达成后默认不自动创建 PR。

设置阶段（Setup Phase）

控制器按顺序完成以下准备工作：

1. 校验目标仓库路径是否存在，否则向用户询问要改进的仓库路径；
2. 运行node {skill_dir}/scripts/resolve-paths.mjs --project-root {repo_path} [--topic "..."] [--slug "..."] --ensure-dirs解析<self-improve-root>；
3. 从本 skill 的templates/复制目录结构到解析出的config/根；
4. 读取state/agent-settings.json，检查si_setting_goal/si_setting_benchmark/si_setting_harness；
5. 信任确认（强制，不可跳过）：若trust_confirmed已是true则走续跑路径；否则展示目标仓库路径并要求用户确认"Self-improve will run benchmark commands inside {repo_path}. This executes arbitrary code in that repository. Confirm? [yes/no]"，拒绝则中止退出，同意则写入trust_confirmed: true；
6. topic 解析生效时把topic_slug持久化到config/settings.json，保证未来续跑在同一条轨道上；
7. 若目标未设置 → 读取si-goal-clarifier.md并直接执行 4 维度苏格拉底式访谈（Objective / Metric / Target / Scope），结果写入config/goal.md；
8. 若基准未设置 → 读取si-benchmark-builder.md，spawn 自定义 agent（model=opus），由它调研仓库、创建或包装基准、3 次验证并记录 baseline，随后需用户确认基准命令；
9. 若护栏未设置 → 与用户确认默认 H001/H002/H003 或定制；
10. 门禁（Gate）：上述四项必须全为true才能进入循环；
11. 若改进分支不存在则创建improve/{goal_slug}（基于{target_branch}），并将goal_slug持久化到 agent-settings.json；
12. 模式互斥：调用state_list_active，若 autopilot 或 ralph 正在运行则拒绝启动；
13. 写入初始状态state_write(mode='self-improve', active=true, iteration=0, started_at=<now>)。

目标澄清访谈的量化方法

si-goal-clarifier.md 定义了访谈的具体规则：对 Objective、Metric、Target、Scope 四个维度各打分 0-100，每轮只针对最低分维度提一个问题，退出条件为模糊度 ≤ 20%（各维度 ≥ 80），软上限 8 轮、硬上限 12 轮；若用户直接给出完整目标则走快路径跳过访谈。

基准构建的规范要求

si-benchmark-builder.md 要求基准满足：JSON 输出优先（stdout 最后一行形如{"primary": 85.2, "sub_scores": {...}}）、确定性（固定种子）、快速（理想 5 分钟内）、自包含（不依赖外部服务）、诚实反映真实质量。完成后需运行 3 次、方差 < 5%，并把基准脚本加入sealed_files、把均值写入tracking/baseline.json。

Git 策略：分支与 worktree

所有 Git 操作都发生在目标仓库内（而非 OMC 项目根目录）：

• 改进分支：improve/{goal_slug}—— 只累积获胜变更；
• 实验分支：experiment/round_{n}_executor_{id}—— 每个执行者的短命分支；
• 归档标签：archive/round_{n}_executor_{id}—— 失败分支在删除前先打标；
• 每个 executor 启动前的 worktree 建立：

  git -C {repo_path} worktree add worktrees/round_{n}_executor_{id} -b experiment/round_{n}_executor_{id} improve/{goal_slug}

• 获胜者由 oh-my-claudecode:git-master 合入（--no-ff），提交信息为Iteration {n}: {hypothesis} (score: {before} → {after})；
• 合入后可执行非阻塞推送：git -C {repo_path} push origin improve/{goal_slug}；
• 失败者打标归档后删除。

改进循环：12 个步骤

门禁通过后循环启动，状态更新为status="running"，迭代序执行以下步骤：

Step 0 — 清理过期 worktree（每轮必跑）

先用git worktree list列出所有 worktree，凡匹配worktrees/round_*但不属于本轮的一律git worktree remove {path} --force，再git worktree prune。该步骤幂等、安全，是崩溃恢复的关键——被中断迭代遗留的孤儿 worktree 会在新一轮开始前被清除。

Step 1-3 — 刷新状态、检查停止请求、消费用户想法

每轮先state_write(...iteration=N)重置 30 分钟 TTL；随后读取状态判断是否有取消或user_stopped；最后读取config/idea.md，非空则为 planner 快照内容并在被消费后清空。

Step 4 — 研究（Research）

spawn 1 个通用 Agent（model=opus），以si-researcher.md内容为 prompt，传入：当前迭代号、目标仓库路径、goal.md 路径、历史与过往 brief 路径、data_contracts.md 第 3 节（Research Brief schema）。输出研究简报 JSON →state/research_briefs/round_{n}.json。研究失败时仅凭历史继续。

Step 5 — 规划（Plan）

并行 spawn N 个oh-my-claudecode:planner（N = settings 中的number_of_agents）。每个 planner 获得：身份标识、研究简报路径、迭代历史路径、harness 规则、Plan Document 的数据契约、覆盖指令（输出 JSON 而非 markdown、跳过访谈模式、每份计划只生成一个可测试假设、包含 approach_family 标签与 history_reference）。用户想法若存在则 planner_a 优先。输出 Plan Document JSON →plans/round_{n}/plan_planner_{id}.json。

Step 6 — 评审（Review）

每个计划串行通过两道评审：

6a. 架构评审（architect）：6 点清单——可测试性、新颖性、范围是否得当、目标文件是否存在且未被密封、实现清晰度、基于证据的预期结果是否现实。架构评审结论仅为建议。

6b. 批判评审（critic）：对照 harness 规则与数据契约：

• H001：恰好一个假设（零个或多个即拒绝）；
• H002：同一 approach_family 连胜不超过 3 次；
• H003：轮内多样性（同轮不允许两个计划同族）；
• 对照 data_contracts.md 做 schema 校验；
• 历史感知检查。

critic 设置critic_approved: true/false，被拒计划不进入执行。若全部计划被拒则记录并跳到 Step 9。

Step 7 — 执行（Execute）

每个通过的计划并行 spawnoh-my-claudecode:executor（model=opus）。spawn 前先在目标仓库创建对应 worktree/实验分支。executor 的 prompt 包含：获批计划 JSON、worktree 目录、settings 中的基准命令、sealed_files 列表、scripts/validate.sh路径、Benchmark Result 契约、覆盖指令（忠实实现计划、跑基准前先跑 validate.sh、执行基准命令、输出 Benchmark Result JSON）。

Step 8 — 锦标赛选择（Tournament Selection）

由 SKILL.md 直接完成（不委托）：

1. 收集全部 executor 结果；
2. 仅保留status: "success"，若为零则跳到 Step 9；
3. 按benchmark_score（尊重benchmark_direction）排序；
4. 按序逐候选判定：先做无回归检查（相对best_score不劣于、且需优于或持平），再经 git-master 执行--no-ff合并，接着在合并态重新跑基准确认提升；若回归则git reset --hard HEAD~1回退并试下一个候选；若冲突则git merge --abort继续；
5. 有获胜者且auto_push为true时推送改进分支；为false（默认）时记录手动推送命令；
6. 归档全部非获胜分支（打标 + 删除）；
7. 无候选存活则本轮不合并，改进分支保持原状；
8. 写 Merge Report JSON →state/merge_reports/round_{n}.json（schema 见 data_contracts.md 第 9 节）。

Step 9 — 记录与可视化

写入迭代历史state/iteration_history/round_{n}.json；更新 agent-settings.json（iterations + 1；有胜者且提升 ≥plateau_threshold时更新best_score、清零两个 counter；有胜者但提升低于阈值时更新 best_score 并plateau_consecutive_count + 1；无胜者时仅circuit_breaker_count + 1，plataeu 只统计停滞不统计失败）；追加tracking/raw_data.json；运行python3 {skill_dir}/scripts/plot_progress.py --tracking-dir <self-improve-root>/tracking生成progress.png；归档本轮计划到state/plan_archive/round_{n}/。

Step 10-11 — 清理与停止条件

清理 worktree（remove --force + prune），把iteration_state.json置为completed。随后评估全部停止条件，任一为真即退出：

无停止条件满足则立即回到 Step 1。

可续跑性（Resumability）

任何恢复逻辑执行前必须先完整跑完 Step 0。恢复流程如下：

1. 总是先跑 Step 0（即使全新启动）；
2. 读取 agent-settings.json 的status：user_stopped→ 询问是否续跑；running→ 会话崩溃，自动续跑（无提示）；idle→ 全新开始；
3. 仅当trust_confirmed为false时才重新确认信任门禁；
4. 读取iteration_state.json：in_progress→ 从current_step续跑并跳过已完成子步骤；completed→ 开始下一轮；failed→ 补齐记录后开始下一轮；文件缺失 → 从第 1 轮开始。

完成、错误处理与并行注意事项

循环退出时的收尾

更新最终状态后，若target_reached且auto_pr为true，spawn git-master 从improve/{goal_slug}向 upstream 创建 PR；为false（默认）时记录手动命令gh pr create --head improve/{goal_slug} --base {target_branch}。最后再跑一次 plot_progress.py，并打印汇总：

=== Self-Improvement Loop Complete === Status: {status} Iterations: {iterations} Best Score: {best_score} (baseline: {baseline}) Improvement: {delta} ({delta_pct}%)

随后调用/oh-my-claudecode:cancel做状态清理。

错误处理对照表

并行会话注意事项

• 多仓库 workspace 锚点：在父目录放置.omc-workspace标记，使跨子仓库的多个会话共享同一个.omc/；解析顺序OMC_STATE_DIR > .omc-workspace > git > cwd；
• 会话 ID 来源：CLI 场景OMC_SESSION_ID环境变量优先，hook 场景取 hook payload 的data.session_id；
• 计划 ID：self-improve 产物目录按 topic-slug 隔离，同一 workspace 内同 topic 并行运行可能出现会话 ID 后缀；
• 并行结论：有条件支持（存在 topic-slug 冲突可能）。

数据契约：多 Agent 通信的 JSON Schema

data_contracts.md 是所有 Agent 间消息的规范 JSON schema，是循环"可被校验、可被复现"的基石：

• Plan Document（planner → critic/executor）：plan_id、hypothesis（恰好一条）、approach_family、target_files、steps、expected_outcome、history_reference，以及 critic/architect 的评审结果字段；
• Benchmark Result（executor → 锦标赛）：benchmark_score、benchmark_raw（原样 stdout）、status（success|regression|error|timeout）、sub_scores、failure_analysis；
• Research Brief（researcher → planners）：仓库分析摘要 + 带confidence/estimated_impact的想法列表；
• Iteration History Record：胜者 + 败者（含失败分析）；
• Failure Analysis Object：what/why/category（枚举：oom、timeout、regression、logic_error、scope_error、infrastructure、benchmark_parse_error、sealed_file_violation）/lesson；
• Iteration State：以子阶段粒度跟踪research、planning、execution、tournament、recording的进度；
• Merge Report：锦标赛结论（merged|no_improvement|no_winner|all_rejected）。

密封文件与 schema 校验的脚本实现

scripts/validate.sh 是循环中"防作弊"的硬性关卡，可直接独立使用：

./validate.sh --worktree /path --settings /path/to/settings.json plan.json ./validate.sh --project-root /path/to/repo --topic "Improve tests" plan.json

它按优先级解析 settings 路径（显式--settings>SELF_IMPROVE_SETTINGS_PATH环境变量 > 通过 resolve-paths.mjs 从--project-root/--topic/--slug解析 > 向上逐级发现.omc/self-improve/config/settings.json），然后执行两类校验：

1. 密封文件检查：通过 git diff（含 worktree 场景下对 improve 分支基线的 merge-base 对比、未提交与暂存改动）找出被改文件，凡命中sealed_files中精确路径或以/结尾的目录前缀即exit 1；
2. schema 校验：对 Plan Document 检查必需字段、hypothesis必须为字符串、steps非空；对 Benchmark Result 检查必需字段、status枚举、非 success 状态必须携带完整的failure_analysis（含 category 枚举），以及sub_scores数值类型。执行过程中需要jq可用。

Approach Family 分类体系

每份计划必须且只能贴一个approach_family标签，critic 依据它执行 H002/H003 多样性约束：

harness.md 中定义的自定义 family 同样有效（参见 templates/harness.md 的 Custom Approach Families 段）。

实战小结

一条/oh-my-claudecode:self-improve命令背后是一个完整的自主进化系统：命令本体通过"兼容性命令 +$ARGUMENTS占位 + 插件根路径回退"实现零开销可用，执行时则加载 skills/self-improve/SKILL.md 的全套编排协议。对想要在自有仓库上使用该能力的开发者，关键动手路径是：确认目标仓库与基准命令（信任门禁）→ 让系统通过访谈收敛出可测目标 → 让基准构建 agent 建立可重复、低方差、被密封的评估 → 观察研究-规划-评审-执行-锦标赛的迭代循环 → 依据tracking/progress.png、iteration_history/与 agent-settings.json 中的计数判断平台期/熔断/达标状态。由于auto_push与auto_pr默认关闭，产出改进分支后可手动执行git push origin improve/{goal_slug}与gh pr create将成果沉淀到上游。

【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode