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

0.3 缺信息就停，不要猜

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

0.4 先读上次的统一日志

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

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

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

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

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

第 2 步：搜索

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

推荐研究方向

跨学科 latticework（认知科学 / 决策科学 / 复杂系统等）默认不启用，只有议题明确需要跨域支撑时才查 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 项：

每项输出 [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）

## 自进化提案 · {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），每次运行追加一条：

## {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 步：输出摘要

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

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

无发现无问题时：

本次搜索未发现高价值新发表，系统自检全 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 步

最后一条

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