从 SkillClaw 到执行锚定自进化：让 Agent 技能在真实环境中验证、进化、部署

摘要

自进化 Agent 是当前 LLM Agent 领域最前沿的方向之一：让 Agent 从自身的执行轨迹中提炼经验、进化技能（skills），实现跨会话的累积式能力提升。然而，现有工作（SkillClaw、EvoSkill、AutoSkill、EmbodiSkill、Trace2Skill、SkillOpt、SkillLens）普遍面临三大痛点：认识论锚点缺失（LLM 判 LLM，无外部验证）、更新不稳定（ad hoc 编辑，语义漂移）、错误累积（失败模式被固化进共享技能库）。

本文在深度解析 SkillClaw 源码和系统性调研 7 篇前沿工作的基础上，提出 执行锚定技能进化（Execution-Grounded Skill Evolution, EGSE） 框架。核心洞察是：当一个 Agent 的技能本质是可执行的操作流程（如 chaos inject→validate→recover 闭环）时，"真实环境执行"本身就是最可靠的锚点——不需要 LLM 自评，不需要人工标注，执行通过即为技能有效。我们在一个真实的生产级 Chaos Agent（alcor-chaos 故障注入系统，运行在 K8s + GPFS + RDMA 集群上）上验证了这一思路，该 Agent 使用 Claude Code 作为 harness，通过 CLAUDE.md + Skills + MCP 配置实现零代码自进化闭环。

1. 背景：自进化 Agent 的两条路线

自进化 Agent 的核心问题是：Agent 每天在跑任务，每次成功或失败都有轨迹留下来，但这些轨迹往往直接扔掉，下次从零开始。自进化的目标是把这些经历沉淀下来，变成更好的策略、更丰富的工具集。

现有工作分为两条路线：

路线一：技能积累（不改模型权重）

工作	核心思路	锚点	验证机制
EvoSkill (2026)	三 Agent 协作：Executor 跑任务→Proposer 诊断失败→Skill-Builder 写技能	真实答案（ground truth）	无执行验证，仅 LLM 判
AutoSkill (上海 AI Lab)	五模块 prompt-driven：检索 skills 辅助回答 + 根据新交互更新 skill bank	LLM 自评	无
EmbodiSkill (清华)	证据类型分类：先判 trajectory 对 skill 的证据类型（新知识/优化信号/缺陷/偏差），再定向修改	LLM 判 LLM	无
Trace2Skill (阿里)	批量轨迹归纳：收集一批 traces→并行分析成败→统一归纳成 skill directory	失败轨迹对比	无执行验证
SkillOpt (微软)	有界编辑 + 验证集门控：textual learning rate 限制每步编辑数 + 验证集 accept/reject	验证集分数	有（验证集），但验证集本身是 LLM 跑的
SkillClaw (阿里)	跨用户集体进化：proxy 记录轨迹→evolver 自动演化→共享技能库	LLM PRM 多数表决	默认无（verifier/replay opt-in）
SkillLens (微软)	系统评估框架：经验生成→skill 抽取→skill 消费三步 pipeline 评估	实际效用指标	有（held-out test）

路线二：强化学习（修改模型权重）

工作	核心思路
AgentEvolver (阿里通义)	自提问机制生成代理任务 + 合成奖励 + 轨迹级策略优化（GRPO）

本文聚焦路线一（技能积累），因为：

不需要训练模型权重，落地门槛低（不需要 GPU 集群训练）。
技能（SKILL.md）是可读、可审查、可回滚的——比模型权重黑盒更安全。
与 Claude Code / Codex 等生产 Agent 天然兼容（它们本就支持 skill 目录）。

2. 现有工作的三大痛点（从 SkillClaw 源码实证）

基于对 SkillClaw 项目的逐行代码分析，我们坐实了自进化 Agent 的三个结构性缺陷：

痛点一：认识论锚点缺失

SkillClaw 的默认路径是 LLM 自举闭环：

1	LLM 写技能 → 写进共享库 → 该 LLM 未来又读这些技能 → 再写...

三层"验证"全是 LLM 判 LLM：

PRM Scorer：模型对每轮回答投票 +1/-1/0，多数表决——纯 LLM judge。
Skill Verifier（默认关）：又一个 LLM 调用，判"候选技能是否值得发布"。
重放 A/B 验证（默认关）：让 LLM 重答原始指令，PRM 打分比较——但不重跑工具、不对照 ground-truth。

核心问题：没有异源锚点。一个被污染的技能会被所有用户继承，而唯一的"验证"本身仍是 LLM 判断——形成自我强化循环。

痛点二：更新不稳定

SkillClaw 的更新是 ad hoc LLM 编辑——LLM 在一次调用里同时决定动作（create/improve/optimize_desc/skip）并产出新技能文本。

无有界编辑（bounded edit）：LLM 可以一次重写整个技能，导致语义大跳跃。
无 cooldown / 无 min-sessions：一个 session 就能触发演化，容易过拟合局部经验。
冲突解决极浅：SHA-256 字节级比较 + LLM 自行裁量，合并失败时 last-write-wins 兜底（直接覆盖，无拒绝）。

SkillOpt 虽提出了 textual learning rate（edit budget）+ validation gate，但其验证集仍是 LLM 跑的——验证通过不代表真实环境有效。

痛点三：错误累积

SkillClaw 默认路径下，一个候选技能只经过一次 LLM 演化调用就直写共享库。最强护栏（skill verifier + replay A/B）默认关闭。

reject 后无自动重试——同一 evidence 被消费删除，候选不再有第二次机会。
低效技能会降权（skill_stats.json），但不删除——共享库里的坏技能永久存在。
跨用户共享意味着一个人的错误模式会被所有用户继承。

3. 执行锚定技能进化（EGSE）：用真实执行取代 LLM 自评

3.1 核心洞察

现有工作的锚点缺失源于一个假设：技能的质量只能通过 LLM 判断或人工标注来评估。但当一个 Agent 的技能本质是可执行的操作流程时，"真实环境执行"本身就是最可靠、最廉价、最无需人工的锚点。

以我们的 Chaos Agent 为例，一个"技能"（chaos case）的生命周期是：

1
2
3

生成代码 + case YAML → go build（编译验证）→ 部署到 aemu（configmap reload）
→ POST /api/fault/<id>（inject 真实节点）→ executor pod 跑 chaos CLI
→ validate（验证故障生效）→ DELETE（recover）→ 全链路通过 = 技能有效

这条链路里，每一步都有确定性的验证（不是 LLM 判 LLM）：

步骤	验证机制	锚点类型
`go build ./... && go vet ./...`	编译器	程序化（确定性）
`make chart` + `helm upgrade`	configmap 生成 + K8s 部署	系统级（确定性）
`POST /api/fault/<id>` → executor pod Succeeded	故障注入成功	执行级（确定性）
`chaos validate` 或 case 内联断言	故障现象验证	语义级（确定性规则）
`DELETE /api/fault/<id>` → executor pod Succeeded	恢复成功	执行级（确定性）
`git push` → CI 通过	持续集成	系统级（确定性）

这不是 LLM 判 LLM，而是代码判代码、执行判执行。 一个技能（case）要么在真实节点上 inject→validate→recover 全通，要么不通——没有"看起来不错但实际不能用"的灰色地带。

3.2 EGSE 框架设计

┌──────────────────────────────────────────────────────────┐
│  EGSE: Execution-Grounded Skill Evolution                 │
│                                                          │
│  ┌─────────┐    ┌──────────┐    ┌──────────────────┐    │
│  │ 执行轨迹  │───→│ 轨迹分析  │───→│ 技能候选生成      │    │
│  │ (real)  │    │ (batch)  │    │ (LLM propose)    │    │
│  └─────────┘    └──────────┘    └────────┬─────────┘    │
│                                            │              │
│                              ┌─────────────▼───────────┐  │
│                              │  执行锚定验证环          │  │
│                              │  (Execution Anchor)     │  │
│                              │                         │  │
│                              │  build → deploy →      │  │
│                              │  inject → validate →   │  │
│                              │  recover → git push     │  │
│                              │                         │  │
│                              │  通过 → publish          │  │
│                              │  失败 → 反馈 → 迭代      │  │
│                              └─────────────────────────┘  │
│                                                          │
│  ┌──────────────────────────────────────────────────┐   │
│  │  持久记忆 (Memory)                                 │   │
│  │  跨会话记录: bug 模式 / 约束 / 集群状态             │   │
│  │  喂给下一次 propose: "上次踩过的坑别再踩"            │   │
│  └──────────────────────────────────────────────────┘   │
└──────────────────────────────────────────────────────────┘

3.2.1 批量轨迹分析（Batch Trajectory Analysis）

借鉴 Trace2Skill 的批量归纳思路（而非在线逐条修改）：

Agent 执行一批任务，产生轨迹（成功 + 失败）。
轨迹分析模块（LLM）批量分析失败模式，提炼技能候选。
失败轨迹最有价值——直接暴露 Agent 的误判、漏查、工具误用。

关键改进：Trace2Skill 的批量分析产出后直接写技能库；EGSE 在产出后必须过执行锚定验证环。

3.2.2 执行锚定验证环（Execution Anchor Loop）

借鉴 SkillOpt 的 validation gate，但将验证从"LLM 跑验证集"升级为真实环境执行闭环：

候选技能 → go build → 编译通过?
  ├── 否 → 反馈编译错误 → LLM 修正 → 重试
  └── 是 → 部署 → POST inject → 故障注入成功?
              ├── 否 → 反馈 executor pod 日志 → LLM 修正 → 重试
              └── 是 → validate → 故障现象验证通过?
                      ├── 否 → 反馈验证输出 → LLM 修正 → 重试
                      └── 是 → DELETE recover → 恢复成功?
                              ├── 否 → 反馈 recover 日志 → LLM 修正 → 重试
                              └── 是 → ✅ 技能有效 → git push → 发布

每个失败分支都有确定性反馈（编译器输出 / executor pod 日志 / 验证输出），LLM 基于这些真实信号修正技能，而非基于自我反思。

3.2.3 有界编辑（Bounded Edit）

借鉴 SkillOpt 的 textual learning rate：

每轮迭代最多修改 N 条规则（edit budget）。
每次修改是最小 diff（补一个约束 / 修一个 flag / 加一个步骤），不是重写整个技能。
编译 + 执行验证天然限制编辑幅度——大改更容易编译失败 / 执行失败，自然被拒绝。

3.2.4 持久记忆（Memory-augmented Evolution）

借鉴 SkillClaw 的跨用户经验积累，但用 Claude Code 的持久记忆机制实现：

~/.claude/projects/<repo>/memory/
├── MEMORY.md                    # 索引（每次会话自动加载）
├── job-volumespec.md      # job VolumeSpec 不支持 configmap
├── jobagent-eval-vendor-routing.md  # 厂商路由
└── ...

Memory 记录的内容：

Bug 模式：OptionBase 值拷贝 timeout bug、mmdelfileset -f、removeAllFiles NotFound。
约束：dev-NNN 唯一、queue=tryout、infiniai-scheduler 认 taint 不认 cordon。
集群状态：a9 GPFS 挂载卡死 17 天的根因（/mnt/nfs hard NFS）。

这些记忆在下一次 propose 时自动注入上下文——“上次踩过的坑别再踩”。与 SkillClaw 的 session judge 打分不同，这是结构化的失败模式知识，不是分数。

3.2.5 错误累积防护

机制	SkillClaw	EGSE
发布门	默认关（opt-in）	执行验证（默认开，硬门）
reject 后	删除 evidence，无重试	保留，带反馈重试（编译/执行日志）
低效技能	降权但不删	不通过执行 = 不发布（不存在"低效但发布"的技能）
冲突解决	SHA-only + last-write-wins	执行对比：两个候选都跑，谁通过谁发布

4. 生产实现：Claude Code 作为自进化 Agent harness

4.1 为什么用 Claude Code

维度	传统框架（inf_agent_framework）	Claude Code
Agent 本体	手写 agent.py + backend + middleware	零代码，Claude Code 本身即 agent
Shell 执行	LocalShellBackend（同步阻塞）	Bash 工具（支持后台任务 + 通知）
并行	串行工具调用	一条消息多个工具并行 + Agent 子 agent 并行
Skills	SkillsManager 框架代码	Skill 工具 + SKILL.md（原生支持）
Memory	无跨会话	persistent memory（`~/.claude/.../memory/`）
MCP	McpToolClient 代码接入	`.mcp.json` 零代码配置

Claude Code 的 harness 完备性（Bash 后台任务、并行工具调用、Agent 子 agent、Cron 定时、TodoWrite 任务跟踪、persistent memory）是 chaos agent 自进化的刚需——aemu POST 长任务异步、并行读源码 + 写代码、跨会话记忆 bug 模式。

4.2 文件结构

alcor-chaos/                          # 代码仓库（agent 的 workspace）
├── CLAUDE.md                          # 七步工作流 + 规范 + 约束（每次自动加载）
├── .mcp.json                          # MCP 工具配置（sandbox shell）
├── .claude/
│   ├── settings.json                  # env（aemu/langfuse/harbor 凭据）
│   └── skills/                        # 按需加载的技能
│       ├── cluster-activate/SKILL.md
│       ├── eval-seed/SKILL.md + scripts/upload_seed.py
│       ├── aemu-verify/SKILL.md
│       └── git-push/SKILL.md
├── cmd/chaos/                         # chaos CLI 代码
├── pkg/chaos/                         # 故障实现
├── new_config.yaml                    # aemu case 配置
├── 3rd_party/chaosblade/              # chaosblade 参考源码
└── references/cases/                  # 归档的 case + seed

4.3 七步自进化工作流

1. 激活集群 → alcor-cli/kubectl 探节点资源
2. 取故障 case → 读 chaosblade 源码提炼七元组
3. 判定 case 类型 → 普通 / pod / job
4. 生成代码+case → 三层代码 + new_config.yaml + cases.seed.json
5. 生成 eval seed → 题面/根因/解法 + 上传 langfuse
6. 执行锚定验证 → go build → make chart → helm upgrade
                  → POST inject → validate → DELETE recover
                  → 通过 = 技能有效
7. push + 归档 → git push feat/<type>-<fault>

Step 6 就是执行锚定验证环——每一步的失败都有确定性反馈（编译器日志 / executor pod 日志 / 验证输出），LLM 基于真实信号迭代修正。

4.4 实际验证：8 个 job case 的自进化闭环

我们在真实 K8s 集群（nvidia A100 节点 + GPFS + RDMA）上验证了 8 个 job case 的自进化闭环：

Case	故障类型	验证结果
job-hang-gpfs-hang-job	GPFS IO 停滞	✅ inject→recover 全通
gpfs-inode-job-fail-job	inode 配额耗尽	✅ 全通
node-unschedulable-job	taint → job Pending	✅ 全通
rdma-link-down-job	RDMA 链路 down	✅ 全通
eth-down-job	bond0 网卡 down	✅ 全通
ecc-xid48-job	GPU ECC 错误	✅ 全通
high-temp-job	GPU 高温	✅ 全通
pcie-downgrade-job	PCIe 降级	✅ 全通

每个 case 都经历了"生成→编译失败→修正→部署→inject 失败→修正→验证通过→push"的迭代——这些失败和修正本身就是轨迹，会被记忆记录，喂给下一次进化。

关键发现（已写入 persistent memory）：

Job VolumeSpec 只认 k8svolume（不支持 configmap）→ train.py 必须 base64 内联。
OptionBase 值拷贝导致 timeout=0 → inject/recover 的 RunE 需要 re-sync。
infiniai-scheduler 认 taint 不认 cordon → node-unschedulable case 必须用 taint + --no-tolerations。
mmdelfileset 不带 -f 在有文件 fileset 上失败 → GPFSDeleteFileset 需加 -f。
alcor-agent 的 df -h 撞 /mnt/nfs hard NFS → D 状态 → worker 阻塞 → nats 超时。

这些发现不是 LLM 自评出来的，是执行失败暴露的——这就是执行锚定的价值。

5. 与现有工作的对比

维度	SkillClaw	SkillOpt	Trace2Skill	EGSE (本文)
锚点	LLM PRM (默认)	LLM 验证集	失败轨迹对比	真实执行闭环
验证	LLM 判 LLM (opt-in)	LLM 跑验证集	无执行验证	编译+部署+inject+validate+recover
更新稳定性	ad hoc LLM 编辑	bounded edit + validation gate	批量归纳	bounded edit + 执行反馈迭代
错误累积	默认无护栏	reject buffer	批量减少过拟合	执行不通过 = 不发布
冲突解决	SHA-only + last-write-wins	—	批量合并	执行对比（两个候选都跑）
跨会话记忆	无	reject buffer	feedback history	persistent memory
检索	全量注入（RAG 死代码）	—	统一 skill directory	CLAUDE.md 全局 + skill 按需加载
隐私	无脱敏	—	—	执行日志不含用户数据
生产可部署	proxy + evolve server	研究框架	研究框架	Claude Code + K8s + aemu

5.1 与 SkillClaw 的关键差异

SkillClaw 的"集体进化"理念是对的——把技能更新从单用户扩展到多用户生态。但其落地是"理念先行、护栏后置"：

锚点：SkillClaw 默认 LLM 自举无锚点；EGSE 用真实执行作为硬锚点。
护栏：SkillClaw 的最强护栏默认关；EGSE 的执行验证是必须通过的门，不可跳过。
反馈：SkillClaw reject 后删除 evidence 无重试；EGSE 保留失败日志，LLM 基于真实错误修正后重试。
部署：SkillClaw 是 proxy + evolve server 架构；EGSE 是 Claude Code 原生（零框架代码）。

5.2 与 SkillOpt 的关键差异

SkillOpt 的 textual learning rate + validation gate 是对的方向，但：

验证集是 LLM 跑的——验证通过不代表真实环境有效。
EGSE 的验证集就是真实集群——inject/validate/recover 在真实节点上跑。

5.3 与 Trace2Skill 的关键差异

Trace2Skill 的批量轨迹归纳 + 统一 skill directory 是对的方向，但：

归纳后直接写技能库，无执行验证。
EGSE 在归纳后加执行锚定验证环——归纳的产出必须通过真实执行才发布。

6. 学术贡献与生产价值的统一

6.1 学术贡献（面向 NeurIPS / ICML）

执行锚定（Execution Grounding）：首次提出用真实环境执行闭环作为自进化 Agent 的认识论锚点，取代 LLM 自评。这是一个可形式化的贡献——定义"技能有效性"为"在目标环境中执行通过"，而非"LLM 判断有效"。
执行反馈驱动的迭代修正：LLM 的修正信号来自编译器输出 / executor pod 日志 / 验证输出等确定性反馈，而非自我反思。形式化为： $skill_{t+1} = \text{LLM}(skill_t, \text{execution\_feedback}(skill_t))$ ，其中 $\text{execution\_feedback}$ 是环境的真实响应。
Memory-augmented Evolution：持久记忆将跨会话的失败模式结构化存储，在 propose 阶段注入上下文。与 SkillClaw 的 session judge 打分不同，这是因果知识（“job VolumeSpec 不支持 configmap”），不是分数。
Bounded Edit + Execution Gate：结合 SkillOpt 的有界编辑与真实执行验证——编辑幅度受编译/执行失败天然约束（大改更容易失败）。

6.2 生产价值

零框架代码：Claude Code 作为 harness，不写 agent.py / backend / middleware——claude 启动即用。
同仓库闭环：CLAUDE.md + skills + .mcp.json 跟代码同 git 仓库——技能变更跟代码变更一起 PR review。
真实部署验证：8 个 case 在真实 K8s 集群上 inject→validate→recover 全通，不是合成 benchmark。
跨厂商支持：per-case 节点路由（nvidia → a9, metax → metax-host-027），一套框架覆盖多厂商。
eval 闭环：技能（case）生成后自动写 eval seed（题面/根因/解法）+ 上传 langfuse + 加入 FAULT_IDS——技能的有效性可以通过 Job agent 评测量化。

6.3 学术与生产的桥梁

学术关切	生产实现	桥梁
认识论锚点	chaos inject→validate→recover 闭环	执行通过 = 技能有效
更新稳定性	go build 编译验证 + bounded edit	编译失败 = 自然拒绝
错误累积	不通过 = 不 push	git push 是硬门
跨会话记忆	Claude Code persistent memory	memory 文件 = 结构化失败模式
评估指标	Job agent eval (langfuse + judge LLM)	eval score = 技能实际效用
可复现性	git 仓库 + K8s 集群	clone + claude = 复现

7. 讨论与未来方向

7.1 EGSE 的适用范围

EGSE 适用于技能本质是可执行操作流程的 Agent 场景：

Chaos/Fault injection agent（本文验证）
DevOps agent（部署→验证→回滚）
SRE agent（告警→诊断→修复→验证）
CI/CD agent（构建→测试→部署→验证）

对于非可执行的技能（如对话策略、写作风格），EGSE 不适用——仍需要 LLM 自评或人工标注。

7.2 开放问题

多 Agent 协作的执行锚定：当多个 Agent 协作时，执行验证需要协调（Agent A 的技能影响 Agent B 的环境）。如何设计分布式执行锚定？
执行成本：真实环境执行有成本（GPU 时间、集群资源）。如何用最小执行次数验证技能？（SkillOpt 的 edit budget 是一个方向，但执行预算 vs 编辑预算是不同维度。）
技能迁移性：一个在集群 A 上验证通过的技能，在集群 B 上是否有效？（SkillLens 的 Target Evolvability 问题。）
负迁移检测：一个新技能可能修复了 case A 但破坏了 case B。需要在发布前跑回归测试（所有已有 case 重新 inject→validate→recover）。
从执行反馈到 RL：执行反馈（通过/失败）是二值信号。能否引入更细粒度的执行信号（执行时间、资源消耗、agent 诊断准确率）作为 reward，过渡到 RL-based 进化？

7.3 与 AgentEvolver 的融合可能

AgentEvolver（RL 路线）的自提问机制（Agent 自己生成训练任务）与 EGSE 的执行锚定有互补性：

AgentEvolver 生成代理任务 → Agent 执行 → 合成 reward → 更新权重。
EGSE 生成 chaos case → Agent 执行 inject→validate→recover → 执行反馈 → 更新技能。

两者的"自生成任务 + 执行反馈"思路一致，但 EGSE 不更新权重、不需要 GPU 训练。未来可以探索：EGSE 的执行反馈作为 AgentEvolver 的 reward 信号——用真实环境执行作为 RL 的 reward function。

8. 结论

本文从 SkillClaw 源码实证出发，系统调研了 7 篇自进化 Agent 前沿工作，识别出现有工作的三大痛点：认识论锚点缺失、更新不稳定、错误累积。提出执行锚定技能进化（EGSE）框架，核心是用真实环境执行闭环取代 LLM 自评作为技能验证锚点。

在一个真实的生产级 Chaos Agent（alcor-chaos + Claude Code + K8s + GPFS + RDMA）上验证了 8 个 job case 的自进化闭环，每个 case 都经历了"生成→编译失败→修正→部署→inject 失败→修正→验证通过→push"的迭代，失败模式被持久记忆记录，跨会话不重复踩坑。

EGSE 的学术贡献在于首次形式化"执行锚定"概念并给出生产级实现；生产价值在于零框架代码、同仓库闭环、真实部署验证。这为自进化 Agent 从"LLM 自评的闭环"走向"执行验证的闭环"提供了一个可复现的起点。