AgentGameLab 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 跑一次：
- 向外看世界（outward）：最近 ≤3 天 Agent harness / 记忆编排 / 多智能体领域有什么新发表
- 向内照镜子（inward）：当前系统配置有没有冗余、冲突、积压、退化
- 向后落地（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。
优先信息源
arxiv.org、anthropic.com/research、openai.com/research、deepmind.google/research、huggingface.co/blog、高质量工程博客（Lilian Weng、Simon Willison 等）。
入选标准（全部满足才精读）
在搜索窗口内发表；标题和 URL 均未在日志中出现过；有实验数据、工程案例或明确方法论；提出新角度而不只是泛泛综述；能映射到当前 workspace 的至少一个真实问题。
全部不达标 → 照样进入第 6 步记录"无发现"。
第 3 步：精读与分析
能读全文就读全文；只能读摘要时，在日志中注明 ⚠️ 仅基于摘要分析，未读全文。
固定分析框架：
- 基本信息：标题 / 机构 / 发表日期 / 来源 URL / 一句话概括在解决什么问题
- 核心发现：1–3 条，尽量带数据（"在 X 任务上相比 Y 提升了 Z"，不写"效果更好"这种空话）
- 认知冲击：全新方向 / 印证已有认知 / 挑战现有做法——挑战的是哪条默认假设
- 系统映射：映射到当前系统的哪个层级（
AGENTS.md全局流程层 /GROUPS.md路由层 /SOUL.md表达层 /agents/*.md场景层 /memory沉淀层）；具体能改善什么问题；映射置信度（高/中/低） - 可落地方向：改什么、怎么改（只描述思路）、优先级（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）：
- reversibility：git revert 能否原地恢复 + 测试覆盖能否 catch regression，二者同时成立
- scope minimization：能否拆出单点子集独立 ship（单点 ship 风险显著低于全套 ship）
- 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 执行后强制验证
- 语法/类型检查全过（
node --check/ 对应语言的等价检查） - 跑现有测试 + dry-run 命令（如有）
git diff --stat HEAD~1核对改动量符合预期- commit + push + 同步通知（不要求 ack）
- 回看本次输出里的延续性断言（"沿用/连续/仍/仍未"这类词），逐条核实是否仍然成立，发现漂移立刻撤回
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（多人/多引擎共用）意味着"文档工程"本身也是自检对象：同一规则是否在多处分叉、新文档是否纳入了结构层级
铁律
- 核心行为文件默认不直接改——
AGENTS.md/GROUPS.md/SOUL.md/agents/*.md走 L2-b 提案流程 - 研究驱动优先，但不唯研究——日志证据和当前系统结构同样重要
- 诚实高于动作——今天无需优化就写"系统状态健康"，不为了产出硬造动作
- 先定义边界，再做修改——不清楚
safe_files/review_file/config_files时先停 - 输出必须可追溯——每条动作都能追溯到研究条目、自检发现或日志证据
- 避免重复提案——已写入
review_file且未处理的提案不重复写第二遍 - 风险分级不可跳过——再有说服力的发现，落地前也必须先过第 5 步
最后一条
自进化不是自动改配置，而是自动把"值得改的事"和"不该乱改的事"区分开。 如果说不清一条修改会影响哪一层配置、由谁审核、如何验证，它就还不该进入执行态。