# Harness Evolve

> 面向 Agent workspace（OpenClaw / Claude Code / LangGraph / 任何有"系统配置文件 + 运行日志"概念的框架）的自进化 skill——一次运行走完整闭环：追踪前沿研究 → 精读分析 → 系统自检 → 按 L1/L2/L3 风险分级自主执行或提案。触发词："运行自进化"、"跑一次 harness evolve"、"检查一下系统有没有能优化的地方"、"今天有什么新研究可以落地"、"帮我看看 agent 配置是不是该收敛了"。

- Skill: `agentgamelab/harness-evolve` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add agentgamelab/harness-evolve`
- Raw SKILL.md: https://api.skillmd.com/api/skills/agentgamelab/harness-evolve/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: AgentGameLab (https://skillmd.com/u/agentgamelab)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/agentgamelab/harness-evolve

---


# Harness Evolve — Agent 系统自进化引擎

> 一次运行 = 一条完整闭环：**搜前沿 → 读懂它 → 照镜子 → 分级动手**。
> 不是"读论文写笔记"，也不是"盲目自动重构"，而是把研究发现和系统自检结果，
> 用同一套风险分级规则，转成**安全、可验证、可回滚**的动作。

---

## v3.0 定位说明

v1.x/v2.x 把"只研究"和"消费研究 + 执行"拆成两个 skill（harness-research / harness-evolve），
理由是怕研究阶段的直觉污染执行判断。实践下来，多数使用场景是单 Agent 单会话跑一次就想要结果，
拆两个 skill 只是增加了"先跑哪个、日志同不同步"的心智负担。

v3.0 合并成一条流程，但**把原来靠"物理隔离两个 skill"守住的安全边界，改成靠"流程内部的强制关卡"守住**：
研究结论不能跳过风险分级直接变成执行动作——第 4 步系统自检和第 5 步分级执行之间必须有明确判断，
高风险项（L3）依然禁止在本次运行内直接改文件。**边界没有消失，只是从"两个文件"收进了"一个流程里的强制关卡"。**

---

## 一句话定位

当你想让一个**正在运行的 Agent workspace** 持续变好时，用这个 skill 跑一次：

1. 向外看世界（outward）：最近 ≤3 天 Agent harness / 记忆编排 / 多智能体领域有什么新发表
2. 向内照镜子（inward）：当前系统配置有没有冗余、冲突、积压、退化
3. 向后落地（action）：能安全直接改的直接改，中风险的写提案等审核，高风险的只记录不动手

**终点不是"我看了什么"，而是"系统今天有没有变得更清楚、更少冲突、更少债务"。**

---

## 职责边界

### 本 skill 负责
- 读取当前项目 / workspace 的真实配置结构，找到真正决定行为的文件
- 在时间窗口内搜索前沿材料并精读分析
- 对当前系统做结构自检（冗余/冲突/积压/退化/债务）
- 把研究发现 + 自检结果，按 L1/L2/L3 风险分级转成动作
- 写入统一进化日志，输出可用于日报的摘要

### 本 skill 不负责
- 不允许"觉得有启发"直接等于"应该立刻上线"——必须过风险分级
- 不在没有安全边界定义（safe_files / review_file 未知）时改任何文件
- 不对高风险项（DB migration、auth/RLS、CI/CD、删 ADR）动手，只能观察上报
- 不重复分析日志里已出现过的标题 / URL
- 不用平庸内容凑数——没发现就写没发现

一句话：**这条流程可以又搜又改，但改多深由风险分级说了算，不由"看起来值得"说了算。**

---

## 执行约束（贯穿全程）

- **证据优先**：结论必须有论文/文章/工程案例依据，直觉只能指导搜索方向
- **场景优先**：从当前 workspace 的真实问题倒推，不从"这个论文看起来很酷"正推
- **单变量**：每条落地建议只描述一个主要变量，避免捆绑多个改动
- **诚实高于数量**：没有高质量发现 / 没有系统问题，就如实记录，不用平庸内容污染日志
- **去重铁律**：已记录过的标题 / URL 不重复分析，哪怕换了搜索词命中
- **风险分级不可跳过**：任何"可落地方向"落地前，必须先过第 5 步的 L1/L2/L3 判断

---

## 第 0 步：读取项目 / workspace 上下文

### 0.1 先找真正决定行为的入口

系统配置通常不是一个文件能说清，要按"谁真正决定运行行为"找上下文，而不是按文件名猜。

### 0.2 推荐识别的配置项

| 配置项 | 说明 | 默认理解 |
|---|---|---|
| **workspace_root** | 当前共享工作区根目录 | 当前工作目录 |
| **config_files** | 真正影响运行行为的核心配置 | 优先含 `AGENTS.md`、`GROUPS.md`、`SOUL.md`、`agents/*.md` 等价物 |
| **safe_files** | 可直接修改且不改变运行语义的文件 | 研究日志、进化日志、纯说明文档、实验记录 |
| **review_file** | 中风险提案写入位置 | 默认 `pending-review.md` |
| **log_dir** | 运行日志 / memory 目录 | `memory/`、`logs/`，或项目已有沉淀目录 |
| **unified_log** | 本 skill 的统一进化日志 | 默认 `workspace/harness-evolve-log.md` |
| **workspace_docs** | 其他工作区说明材料 | `README.md`、`CLAUDE.md`、其他工作区文档 |

在共享 workspace（多引擎 / 多 Agent 共用同一目录）场景下，至少确认：workspace 是否独占、行为入口是哪几个文件、统一日志放哪、当前核心痛点是什么、当前生效结构是单层还是多层。

### 0.3 缺信息就停，不要猜

如果读完仍无法判断：当前核心痛点是什么 / 哪些文件是运行时主入口 / 哪些文件可以安全直接改 / 日志该写到哪里——就先问用户，不要脑补配置图。后续所有分析和执行都依赖这些前提。

### 0.4 先读上次的统一日志

如果 `unified_log` 已存在，先读取最近几次运行的记录，了解：哪些研究方向已经转化 / 被放弃 / 还在观察，上次做了哪些 L1/L2 动作，哪些 L3 观察项还悬着。避免重复推荐、重复提案。

---

## 第 1 步：确定搜索窗口与去重基线

从 `unified_log` 提取：上次搜索日期、已分析标题/URL 列表、上次搜索词、尚未标记"已转化/已放弃"的 P0/P1 积压。

| 场景 | 时间窗 | 用途 |
|---|---|---|
| daily routine | **≤3 天** | 跟踪世界最前沿，纯报道优先 |
| ad-hoc backfill | **≤14 天** | 用户明确要求覆盖更长范围时 |
| 有日志 | `上次搜索日期 → 今天` | 增量去重 |

**铁律**：daily 遇到 >3 天的内容就跳过，不要因为"以前漏看了"往前补——补扫走 ad-hoc backfill（用户明确要求时）。

日期判断：arXiv 用 Submitted 日期；机构博客用正文顶部发布日期；日期不确定就在日志里写"日期不确定，约 YYYY-MM"。

---

## 第 2 步：搜索

在时间窗口内搜索，每次选 2–3 个关键词组合，目标是覆盖"最可能改善当前系统的方向"，不是搜得多。

### 推荐研究方向

| 方向 | 关键词示例 |
|---|---|
| Agent harness / runtime | `"agent harness" OR "agentic harness" OR "agent runtime"` |
| Agent skills / 工具发现 | `"agent skills" OR "skill discovery" OR "skill lazy load"` |
| Context engineering | `"context engineering" OR "context compaction" OR "prompt caching"` |
| Agent memory | `"agent memory" OR "memory tool" OR "episodic memory for agents"` |
| Tool use / ACI | `"tool use" OR "ACI" OR "agent computer interface"` |
| 多智能体协作 | `"multi-agent orchestration" OR "agent handoff"` |
| 自进化 / 元学习 | `"self-improving agent" OR "agent self-evolution" OR "meta-learning"` |
| 评测与回归 | `AI agent evaluation benchmark tool-use SWE-bench` |
| 头部公司每跑必扫 | Anthropic / OpenAI / DeepMind / Meta AI / xAI / DeepSeek / Moonshot / Qwen / Zhipu |
| Benchmark / 顶会 | SWE-bench / GAIA / TerminalBench / WebArena / OSWorld · NeurIPS Agentic AI / ICLR / ICML / ACL / COLM |

跨学科 latticework（认知科学 / 决策科学 / 复杂系统等）默认不启用，只有议题明确需要跨域支撑时才查 [references/cross-discipline-lattice.md](references/cross-discipline-lattice.md)。

### 优先信息源
arxiv.org、anthropic.com/research、openai.com/research、deepmind.google/research、huggingface.co/blog、高质量工程博客（Lilian Weng、Simon Willison 等）。

### 入选标准（全部满足才精读）
在搜索窗口内发表；标题和 URL 均未在日志中出现过；有实验数据、工程案例或明确方法论；提出新角度而不只是泛泛综述；能映射到当前 workspace 的至少一个真实问题。

全部不达标 → 照样进入第 6 步记录"无发现"。

---

## 第 3 步：精读与分析

能读全文就读全文；只能读摘要时，在日志中注明 `⚠️ 仅基于摘要分析，未读全文`。

固定分析框架：

1. **基本信息**：标题 / 机构 / 发表日期 / 来源 URL / 一句话概括在解决什么问题
2. **核心发现**：1–3 条，尽量带数据（"在 X 任务上相比 Y 提升了 Z"，不写"效果更好"这种空话）
3. **认知冲击**：全新方向 / 印证已有认知 / 挑战现有做法——挑战的是哪条默认假设
4. **系统映射**：映射到当前系统的哪个层级（`AGENTS.md` 全局流程层 / `GROUPS.md` 路由层 / `SOUL.md` 表达层 / `agents/*.md` 场景层 / `memory` 沉淀层）；具体能改善什么问题；映射置信度（高/中/低）
5. **可落地方向**：改什么、怎么改（只描述思路）、优先级（P0/P1/P2）、风险、验证方式——**这一步只产出候选，不直接执行，执行判断留给第 5 步**

---

## 第 4 步：系统自检

读取 `config_files + safe_files + log_dir`，建立当前系统快照，至少检查以下 8 项：

| # | 检查项 | 扫描对象 | 触发条件 |
|---|---|---|---|
| 1 | 规则冗余 | 全局配置 + 场景层文件 | 同一约束反复出现、边界重复定义 |
| 2 | 规则冲突/漂移 | 全局配置层 + 场景层 | 上层写法与下层执行约束冲突，旧规则未同步 |
| 3 | 研究积压 | `unified_log` | P0/P1 超过合理周期仍未转化 |
| 4 | 进化回归 | 上次执行动作 + 实际文件 | 上次修复被覆盖、丢失、反向退化 |
| 5 | 日志异常 | 最近 3 天 `memory/` / `logs/` | 无输出、重复内容、格式退化、异常中断 |
| 6 | 研究映射可执行性 | 本次 P0/P1 条目 + 配置文件 | 映射指向的层级在系统里真实存在 |
| 7 | 复杂度债务 | 核心配置文件 | 文件过长、链式例外太多、分层失衡 |
| 8 | Skill 提炼机会 | 规则 + 近期日志 | 同类操作重复出现 3 次以上但未抽象 |

每项输出 `[PASS]`（结构健康）/ `[WARN]`（发现问题，附一句话）/ `[SKIP]`（无此结构或样本不足）。

---

## 第 5 步：按风险分级执行（核心关卡，不可跳过）

把第 3 步的"可落地方向"和第 4 步的"[WARN]"项，逐条过下面的分级——**这是唯一允许把候选转成动作的地方**。

### L1 自 ship — 安全小修

**条件**：修改对象属于 `safe_files`；不改变 Agent 核心运行语义；更像"修补/整理/补链路"而非"改行为"。

典型动作：给日志条目补状态、修正文档失效路径、清理过期草稿、补全缺失引用、整理索引摘要、议题元数据同步。

**执行**：直接改 + commit，不开提案。

**特别提醒**：即便是文档文件，只要它**直接决定运行时行为**（`AGENTS.md` / `GROUPS.md` / `SOUL.md` / `agents/*.md` 这类），也不按 L1 直接改，走 L2-b，除非用户已明确授权直接修改。

### L2 自决策 ship — owner 可事后 challenge

**决策三要素**（必须同时达标，任一不达 → 沉淀为观察项，不勉强 ship）：

1. **reversibility**：git revert 能否原地恢复 + 测试覆盖能否 catch regression，二者同时成立
2. **scope minimization**：能否拆出单点子集独立 ship（单点 ship 风险显著低于全套 ship）
3. **expected_value**：修复类改动的必要性 / 反 pattern 严重度 / 拖着不改的复利成本，三者权衡

#### L2-a 直接执行（非破坏性）
新增非破坏性 hook（不改 deny 决策）、加资源（不改现有 schema）、删掉已被其他机制覆盖的旧段落、日志 append/状态流转、metadata 修补。

**执行**：开分支 → commit（`[auto-evolve]` 前缀）→ push → 开 PR + 自动化检查通过后合并；或按项目已有的 CI 治理规则走。

#### L2-b 提案（中风险变更）
改核心规则文件的铁律、改路由 / 专业化提示词、改关键调用协议、改主仓 Agent 行为定义。

**执行**：开分支 + commit（`[evolve-proposal]` 前缀）+ `--draft` 开 PR，通知 owner review。**绝不自动合并**。

#### L2 提案 schema（写入 `review_file`）

```markdown
## 自进化提案 · {YYYY-MM-DD}

**来源**：{研究条目标题+日期 / 自检发现编号}
**子档**：L2-a 直接执行 / L2-b draft PR
**目标文件**：{文件名}
**当前问题**：{一句话}
**当前内容**：{原文摘录}
**建议修改**：{具体改法，before/after}
**为什么现在改**：{研究依据 / 日志证据 / 冲突证据}
**falsifiable_contract**：
  - predicted_metric: {可观测信号，例如 "daemon p95 latency ↓ ≥ 20%"，不能松成"表现更好"}
  - verify_method: {跑什么命令 / 观察多少次运行 / diff 哪个指标文件}
  - verify_after: {时间窗 ≤14 天 / ≤14 次 routine}
  - rollback_trigger: {什么观测信号 → 撤销该提案}
**风险**：{可能副作用、回滚方式}
**优先级**：P0 / P1 / P2
```

#### L2 执行后强制验证

1. 语法/类型检查全过（`node --check` / 对应语言的等价检查）
2. 跑现有测试 + dry-run 命令（如有）
3. `git diff --stat HEAD~1` 核对改动量符合预期
4. commit + push + 同步通知（不要求 ack）
5. 回看本次输出里的延续性断言（"沿用/连续/仍/仍未"这类词），逐条核实是否仍然成立，发现漂移立刻撤回

#### L2 自动回滚触发
测试/lint/部署失败 → 立刻 `git revert`；owner 明确说"撤回/不对/revert" → 立刻 revert；ship 后短期内出现同模块的修复类改动 → 视为回归信号，撤回并记录一条反例。

### L3 仅观察 — 高风险禁动

**条件**：DB migration（schema/data）、auth/RLS/加密相关、CI/CD pipeline、删除现有 ADR/playbook/规则、强依赖跨模块协议变更。

**执行**：通知 owner「proposal: {title} · 涉及高风险（L3）· 详情见 {review_file}#{id}」。**绝不开 PR、绝不改文件**，只在日志里记录观察。

### 暂无把握（跟分级正交，不算执行档）
发现了模式但还不够确定 / 研究有启发但映射仍不稳 / 有复杂度问题但暂无好拆解方案——在日志对应条目补 `跟踪状态：观察中 — {一句话原因}`。

---

## 第 6 步：写入统一进化日志

写入 `unified_log`（默认 `workspace/harness-evolve-log.md`），每次运行追加一条：

```markdown
## {YYYY-MM-DD} · Harness Evolve 运行记录

### 研究发现
{有发现则按下面子模板列出；无发现写"今日搜索未发现高价值新发表，搜索词：{...}"}

#### {论文/文章标题}
**来源**：{URL} · **机构**：{简写} · **发表**：{日期} · **搜索词**：{关键词组合}
**核心发现**：{1-3 条，含数据}
**认知冲击**：{全新/印证/挑战} — {一句话}
**系统映射**（置信度：{高/中/低}）：{层级}：{价值}
**可落地方向**（{P0/P1/P2}）：{改什么}：{怎么改}；风险：{...}；验证：{...}

### 系统自检
- [PASS/WARN/SKIP] 规则冗余 — {详情}
- [PASS/WARN/SKIP] 规则冲突/漂移 — {详情}
- [PASS/WARN/SKIP] 研究积压 — {详情}
- [PASS/WARN/SKIP] 进化回归 — {详情}
- [PASS/WARN/SKIP] 日志异常 — {详情}
- [PASS/WARN/SKIP] 研究映射可执行性 — {详情}
- [PASS/WARN/SKIP] 复杂度债务 — {详情}
- [PASS/WARN/SKIP] Skill 提炼机会 — {详情}

### 本次执行动作
- [L1] {直接执行了什么；若无写"无"}
- [L2-a] {直接 push 了什么；若无写"无"}
- [L2-b] {写了哪些提案到 review_file；若无写"无"}
- [L3] {上报了哪些高风险观察；若无写"无"}
- [观察] {记录了哪些暂无把握的观察项；若无写"无"}

### 摘要（供下游使用）
{2-4 句：这次消费了什么研究、系统哪里有问题、做了什么动作、哪些需要审核}

---
```

---

## 第 7 步：输出摘要

给用户 / 日报的简明版本：

```text
本次研读：{标题}（{机构，日期}）｜核心发现：{一句话含关键数据}
系统自检：{有几项 WARN，最严重的一项}
本次动作：L1 {N} 项直接执行 / L2 {N} 项 push 或提案 / L3 {N} 项已上报观察
需要你看的：{列出所有 L2-b 提案 + L3 上报，没有就写"无"}
```

无发现无问题时：

```text
本次搜索未发现高价值新发表，系统自检全 PASS，无需动作。
当前最高优先待验证方向：{从 P0/P1 积压中选一条；无则写"暂无"}
```

---

## 适配提醒

- 不要默认 `CLAUDE.md`/`README.md` 是唯一入口或能完整描述运行行为
- 不要默认单文件 prompt 就代表系统结构——很多框架是多层配置
- 很多优化点不在代码，而在路由 / 边界 / 沉淀 / 协作协议
- 共享 workspace（多人/多引擎共用）意味着"文档工程"本身也是自检对象：同一规则是否在多处分叉、新文档是否纳入了结构层级

---

## 铁律

1. **核心行为文件默认不直接改**——`AGENTS.md`/`GROUPS.md`/`SOUL.md`/`agents/*.md` 走 L2-b 提案流程
2. **研究驱动优先，但不唯研究**——日志证据和当前系统结构同样重要
3. **诚实高于动作**——今天无需优化就写"系统状态健康"，不为了产出硬造动作
4. **先定义边界，再做修改**——不清楚 `safe_files`/`review_file`/`config_files` 时先停
5. **输出必须可追溯**——每条动作都能追溯到研究条目、自检发现或日志证据
6. **避免重复提案**——已写入 `review_file` 且未处理的提案不重复写第二遍
7. **风险分级不可跳过**——再有说服力的发现，落地前也必须先过第 5 步

---

## 最后一条

**自进化不是自动改配置，而是自动把"值得改的事"和"不该乱改的事"区分开。**
如果说不清一条修改会影响哪一层配置、由谁审核、如何验证，它就还不该进入执行态。