Harness Evolve — harness 进化机制
harness 不是固定产物，而是持续进化的系统。该技能捕捉“哪些做法有效、哪些无效”的差异并回馈给 harness，使下一次运行能够可衡量地变得更好。
流程概览：初始 harness → 实际项目使用 → 当前 harness →（通过 evolve 捕捉差异）→ 反馈归纳 → 反映到 agent、skill、orchestrator → 更新变更历史 → 下一次运行从更好的草稿开始。
工作流程
Phase 1：差异收集
读取 .claude/agents/、.claude/skills/、CLAUDE.md（变更历史表）。
如果是 git 仓库，查询 harness 文件的变更历史（git log --oneline -- .claude/ CLAUDE.md），以了解相对初始配置在何时、为何发生了变化。
如果存在 _workspace/，浏览最近运行的中间产物以确认实际执行痕迹：
- orchestrator 定义的路径下是否确实存在产物（若不存在，说明工作流被绕过或存在死代码）
- 产物质量是否遵循 skill 规定的格式/标准
向用户请求反馈（若已提供反馈则省略）：
- “结果中有需要改进的地方吗？”
- “对 agent 构成或工作流有想改的地方吗？”
若没有反馈则不强行索取。但若存在以下观察信号，则主动提出改进建议。
基于观察的进化信号（即使没有反馈也建议）：
- 同一类型的修改请求重复出现 2 次以上
- agent 反复失败/重试的模式
- 用户绕过 orchestrator 手动操作的痕迹（疑似 orchestrator 触发失败 → description 扩展候选）
- orchestrator 中残留 v1 遗留物（TeamCreate/TeamDelete/实验标志）→ 引导至 harness 技能的迁移流程
Phase 2：反馈类型分类与修改对象映射
反馈类型 → 修改对象 → 示例
- 产物质量 → 对应 agent 的 skill → “分析太肤浅” → 在 skill 中加入深度标准
- agent 角色 → agent 定义 .md → “也需要安全审查” → 通过 harness 技能引导添加 agent
- 工作流顺序 → orchestrator skill → “应该先验证” → 调整 Phase 顺序
- 团队构成 → orchestrator + agent → “这两个可以合并” → 合并 agent
- 触发缺失 → skill description → “用这个表达不生效” → 扩展 description
- 执行模式不适配 → orchestrator → “每次都是同样的扇出，太慢” → 切换工作流模式
- 规模/成本 → orchestrator → “消耗太多 token” → 缩小默认规模，加入预算联动
范围判断：若需要新增/删除 agent 或重新设计架构，则不在本技能中直接进行，而是引导至 harness 技能（第 0 阶段的既有构成扩展流程）。evolve 专注于既有构成的调整。
Phase 3：归纳与反映
将反馈归纳——只适用于特定案例的狭窄修改属于过拟合。“这次报告的前言太长了”不应直接改成“前言控制在整体的 10% 以内”，而应找出前言变长的原因（skill 中缺少篇幅分配标准），在原理层面进行修改。
同时记录 Why——修改后的指令要附上理由。知道理由后，agent 在边缘情况下也能做出正确判断。
变更一次只应用一个，每次变更后立即执行 Phase 4。
防止退化：若修改方向会撤销变更历史中此前的修改，则向用户告知冲突并确认（过去因“太长”而缩短，这次又说“太短”，正确答案是找到同时满足两者的标准）。
保持既有文件的语言——反映到 agent、skill、orchestrator、CLAUDE.md 中的语句，使用修改对象文件中已有的语言。不因本技能文档是韩语，就向其他语言的 harness 中混入韩语句子。
Phase 4：更新变更历史并验证
在 CLAUDE.md 的变更历史表中记录：
变更历史：
| 日期 | 变更内容 | 对象 | 理由 |
|---|---|---|---|
| 2026-07-19 | 添加语气指南 | skills/content-creator | “太生硬”的反馈 |
验证修改文件的结构（frontmatter、引用一致性）。
若修改了 description，则进行触发验证（should-trigger 与 near-miss 各 3 个以上）。
最终确认 CLAUDE.md 与实际文件是否一致。
Phase 5：进化报告
向用户报告：
- 捕捉到的差异摘要（初始构成 → 当前）
- 本次反映的变更及其归纳依据
- 决定不反映的反馈及理由（如有）
- 下一次运行预期可获得的改进
原则
- 差异是资产——变更历史越积累，同一领域下一次构建 harness 时就能从“更接近发布状态的草稿”开始。不要删除历史。
- 禁止无归纳的反映——为一个案例添加一条规则，会让 skill 变成规则堆砌。要压缩为原理。
- 一次一个——若一次性应用多个变更，就无法判断哪个变更产生了效果。