SkillClaw: Let Skills Evolve Collectively with Agentic Evolver

Paper: arXiv:2604.08377 Code: AMAP-ML/SkillClaw Code reference: main @ d33b2a52 (2026-05-26)

1. Motivation (研究动机)

LLM agent 已经开始把「技能」作为可复用的过程性知识来调用，例如 OpenClaw / Claude Code / Codex 风格系统会把工具使用流程、调试经验、平台约束写成 SKILL.md。但论文指出，现有技能库在部署后通常是静态的：一个用户遇到的 API 参数错误、文件路径陷阱、消息检索失败或安全约束处理方式，往往不会自动变成所有用户共享的改进。

这个问题在 multi-user agent ecosystem 里尤其明显：不同用户在不同机器、不同工具状态、不同任务目标下会反复触发相似技能，但失败模式并不完全相同。单个用户的轨迹太稀疏，容易把偶发修复误认为通用规则；而多用户轨迹如果只是堆在日志里，又缺少从 heterogeneous sessions 到 reliable skill update 的机制。SkillClaw 要解决的具体问题是：如何把跨用户、跨时间的 agent 使用轨迹转换成可验证、可同步的技能更新，让一个用户暴露的失败模式能稳定地改进整个技能库。

更具体地说，论文针对三个瓶颈：第一，agent 技能常把「应该怎么做」写成静态 SOP，却没有机制在部署后吸收工具返回、用户纠错和环境异常；第二，agent logs 里有大量 action / tool / feedback 信号，但如果不按 skill 聚合，就很难知道某次失败是 skill 本身的问题还是任务偶然性；第三，共享技能一旦被错误更新，会把 regression 传播给所有用户，所以必须有 conservative editing 和 validation gate，而不能直接把 LLM 生成的修改发布。

这个问题值得研究的原因是它把 agent improvement 从「单个 agent 自我反思」推进到「生态级别的经验复利」。一旦技能可以从真实交互中持续演化，系统不需要每个用户都重新发现同一个工作流；新的工具约束、环境差异和失败修复可以通过共享技能库传播到所有 agent，从而减少重复试错并提高长程工具任务的可靠性。对 OpenClaw / Codex / Claude Code 这类依赖技能目录的系统来说，这也意味着技能库可以从私人笔记变成有验证闭环的 shared infrastructure。

2. Idea (核心思想)

核心 insight 是：调用同一技能的多用户轨迹构成一种自然实验。技能本身近似是 controlled factor，而不同用户、任务和环境给出了互补的 success / failure boundary；把这些轨迹按技能聚合后，Agentic Evolver 可以判断哪些行为是应该保留的 invariant，哪些失败是需要修正的 target。

SkillClaw 的关键创新不是单纯让 LLM 改写 prompt，而是建立一个闭环：client proxy 记录真实 session → server 按 referenced skill 聚合证据 → evolver 对技能执行 refine/create/skip → validator 在真实环境里比较候选技能与当前 best pool → accepted skill 同步回所有用户。

它与 Reflexion、ExpeL、AgentEvolver 等单体 self-evolution 的根本区别是演化粒度和证据来源：后者主要从一个 agent 的历史轨迹中学习；SkillClaw 把分布式 agent 的使用轨迹作为共享 evidence base，并把验证后的技能更新发布成 system-wide reusable artifact。

从方法直觉上看，SkillClaw 把技能当成可版本化的程序资产，而不是一次性 prompt。一次失败不会直接导致改写；只有当多个 session 共同指向同一类环境约束、工具错误或流程缺口时，evolver 才有足够证据更新技能。验证器则把「LLM 认为更好」转成「在真实任务重放中更好」，这就是它区别于普通 prompt optimization 的地方。

可以把它理解成一个 natural experiment：技能 $s$ 在多个用户环境里被重复调用，任务、文件系统、API 状态和用户目标都在变化，但被调用的 procedural artifact 相同。若某些轨迹成功、某些轨迹失败，evolver 可以比较差异来推断技能边界；若一组没有技能的轨迹反复出现相似子流程，系统就有理由创建新技能。这个设计让「技能该如何改」来自真实执行证据，而不是来自作者预先枚举的规则模板。

最终的创新点有三层：数据层把 session 从分散日志转成按技能索引的 evidence；推理层让 agentic evolver 用开放式推理处理多样 failure modes；部署层用 validation 和 synchronization 只发布被证明更好的版本。三层合在一起，才形成 collective skill evolution。

3. Method (方法)

3.1 Overall framework：从 isolated sessions 到 shared skill evolution

Figure 1 解读：左侧是多个用户各自运行的 agent；它们在真实环境里产生 session trajectories，而不是人工整理后的干净样本。中间的 shared evidence base 会保留 action—feedback causal chain，并按 referenced skills 聚合。右侧的 Agentic Evolver 读取技能定义和对应轨迹，生成 refine / create / skip 类型的候选更新；验证通过后，更新写回 shared skill repository，再同步到所有 agent。这个闭环把一次局部失败变成全局技能改进。

论文把共享技能集记为 $S = {s_{1}, \dots, s_{M}}$ ，每个技能 $s$ 是一个 reusable procedural artifact。每次用户交互产生一条 session trajectory $τ$ ，包含 prompt、agent actions、环境或用户反馈、final response。给定跨用户轨迹集合 $T = {τ_{i}}$ ，目标是学习一个更新算子： $S^{'} = Φ (S, T) .$ 整体流程可以写成： $Multi-user Interaction \to Session Collection \to Skill Evolution \to Skill Synchronization .$

3.2 Session trajectory：保留因果链，而不是只看最终答案

SkillClaw 记录的 session 不只是 dialogue transcript，而是完整的工具交互链： $prompt \to action \to feedback \to \dots \to agent response .$ 这样做的动机是 agent 技能失败通常发生在中间步骤：错误的 API 端口、漏掉某个文件、没有处理 CUDA/路径约束、先验假设和真实环境不一致等。如果只保留最终 answer，evolver 无法判断到底是任务理解错了、工具参数错了，还是技能描述没有给出足够的环境检查步骤。

每个 session 会解析出它引用过的技能集合 $K_{i}$ 。对于某个技能 $s$ ，SkillClaw 聚合所有调用过它的轨迹： $G (s) = {τ_{i} ∣ s \in K_{i}} .$ 没有调用任何技能的 session 进入 $G (\emptyset)$ ，用于发现新的可复用过程。这个 grouping 的价值在于跨用户比较：同一技能在不同环境里成功/失败时，差异本身暴露了技能边界，相当于一种 natural ablation。

3.3 Agentic Evolver：refine / create / skip

Agentic Evolver 是一个带结构化 harness 的 LLM agent。Harness 给它输入三类信息：当前技能定义、按技能聚合的 session evidence、允许执行的 evolution actions；但不把推理过程写死成规则。给定技能 $s$ 和轨迹组 $G (s)$ ，evolver 同时看成功和失败样本，然后选择：

Refine：已有技能有用但不够稳，补充步骤、修正过时约束或加强触发说明。
Create：轨迹中出现重复的子流程，但现有技能没有覆盖，创建新技能。
Skip：证据不足，或者改动可能只是过拟合某个偶发环境。

关键直觉是：成功 session 定义了不能随便破坏的 invariants，失败 session 定义了需要修正的 targets。Evolver 不是把所有失败堆成 prompt 然后大改技能，而是用成功样本约束修改范围，避免「修掉一个问题同时破坏已验证流程」。

论文中的算法可以概括为：先把 $T$ 转成 structured evidence $E$ ，按 referenced skills 得到 ${G (s)}$ 和 $G (\emptyset)$ ；对每个技能组分析 recurring success/failure patterns，选择 refine/create/skip，生成候选更新；经过 conservative editing 和 validation 后 merge 到 $S^{'}$ ；最后把 $S^{'}$ 同步回所有 agent。

3.4 Conservative editing, validation, and synchronization

因为技能是共享资产，不稳定更新会影响所有用户。论文的稳定性来自两层约束：

Conservative editing：修改应当只针对证据直接指向的技能部分，保留成功轨迹验证过的步骤。论文草稿中还给出过局部编辑距离直觉：若 $b_{ℓ}$ 表示技能 section，可用 $Δ (s, s^{'}) = \sum_{ℓ} I [b_{ℓ} \neq = b_{ℓ}^{'}]$ 衡量改动范围；实际主文把重点放在 evidence-proportional editing 的原则上。
Nighttime validation：候选技能 $s^{'}$ 在真实工具环境里和当前技能 $s$ 对同类任务进行比较。若整体成功率和执行稳定性更好，标记为 Accept；否则 Reject，不进入 deployed best pool。

因此用户白天总是使用前一晚验证过的 best skill pool，而不是未验证候选。这个策略会增加 token 和工具执行成本，但换来 user-facing performance 的单调稳定性：拒绝的候选可以保留为历史记录，但不会被同步给所有用户。

3.5 Released code implementation：client proxy + evolve server + validation worker

Released repo 把论文框架拆成两个主要组件：

Client Proxy（skillclaw/api_server.py）：兼容 OpenAI /v1/chat/completions 与 Anthropic /v1/messages 风格调用，拦截 agent 请求，记录 turn、tool calls、tool results、read/modified skills、injected skills、PRM score 等 session artifacts。
Evolve Server（evolve_server/engines/workflow.py）：从 shared storage drain pending sessions，调用 summarizer 生成 trajectory-aware summary，用 aggregate_sessions_by_skill 按技能分组，再分别走 existing-skill evolution 和 no-skill skill creation。
Validation Worker（skillclaw/validation_worker.py）：客户端空闲时领取 validation jobs，重放 current skill 与 candidate skill 分支，把 score / accepted 写回 validation store。
Skill Hub（skillclaw/skill_hub.py）：在本地技能目录与 object storage / Nacos / local share 之间 push/pull/sync，使用 sha256 增量传输、备份和版本记录来维护共享技能库。

论文公式与 released code 实现差异：论文把 evolver action 抽象为 refine/create/skip；代码里的 prompt 与 parser 实际使用 improve_skill、optimize_description、create_skill、skip，其中 optimize_description 是对 refine 的更细粒度拆分。另一个差异是论文实验强调 nighttime validation 后部署 best pool；repo 默认 publish_mode="direct"、validation_enabled=False，需要显式切到 validated publish mode 和开启 client validation worker 才复现实验式验证闭环。

Pseudocode: session summarization and grouping

async def summarize_and_group_sessions(llm, storage):
    sessions, session_keys = await storage.drain_pending_sessions()
    if not sessions:
        return {}, []
 
    await summarize_sessions_parallel(llm, sessions)
    grouped = aggregate_sessions_by_skill(sessions)
    no_skill_sessions = grouped.pop(NO_SKILL_KEY, [])
    return grouped, no_skill_sessions

Pseudocode: evolve an existing skill group

async def evolve_existing_skill_group(llm, skill_name, sessions, registry):
    current_skill = await registry.fetch_skill_content(skill_name)
    existing_names = await registry.list_skill_names()
    evidence = build_session_evidence(sessions)
 
    raw = await llm.chat([
        {"role": "system", "content": EVOLVE_FROM_SESSIONS_SYSTEM.format(skill_name=skill_name)},
        {"role": "user", "content": format_skill_and_evidence(current_skill, evidence, existing_names)},
    ], max_tokens=8192, temperature=0.4)
 
    decision = parse_evolve_result(raw, skill_name)
    if decision["action"] == "skip":
        return None
    return await materialize_skill(decision["skill"], decision["action"], sessions)

Pseudocode: create a missing skill from no-skill sessions

async def create_missing_skill(llm, no_skill_sessions, registry):
    evidence = build_session_evidence(no_skill_sessions)
    raw = await llm.chat([
        {"role": "system", "content": CREATE_FROM_SESSIONS_SYSTEM},
        {"role": "user", "content": format_no_skill_evidence(evidence, registry.list_skill_names())},
    ], max_tokens=8192, temperature=0.4)
 
    decision = parse_evolve_result(raw, skill_name="")
    if decision["action"] != "create_skill":
        return None
    return await materialize_skill(decision["skill"], "create_skill", no_skill_sessions)

Pseudocode: validation-gated publishing

async def publish_after_validation(store, config, registry):
    records = []
    for job in store.list_pending_jobs():
        results = store.list_results(job["job_id"])
        accepted = sum(r.get("accepted") is True for r in results)
        rejected = sum(r.get("accepted") is not True for r in results)
        scores = [float(r["score"]) for r in results if isinstance(r.get("score"), (int, float))]
        mean_score = round(sum(scores) / len(scores), 3) if scores else None
 
        publish_ready = (
            len(results) >= config.validation_required_results
            and accepted >= config.validation_required_approvals
            and mean_score is not None
            and mean_score >= config.validation_min_mean_score
        )
        reject_ready = rejected >= config.validation_max_rejections
 
        if publish_ready:
            version = await registry.upload_skill(job["candidate_skill"])
            store.save_decision(job["job_id"], {"status": "published", "version": version})
            records.append({"action": "published_after_validation", "skill": job["candidate_skill_name"]})
        elif reject_ready:
            store.save_decision(job["job_id"], {"status": "rejected", "reason": "client validation rejected candidate"})
    return records

Code reference: main @ d33b2a52 (2026-05-26) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
Client-side session capture / proxy	`skillclaw/api_server.py`	`_buffer_record`, `_session_turns`, OpenAI / Anthropic protocol handlers
Trajectory-aware session summary	`evolve_server/pipeline/summarizer.py`	`build_session_trajectory`, `_extract_session_metadata`, `summarize_sessions_parallel`
Skill-based evidence grouping	`evolve_server/pipeline/aggregation.py`	`aggregate_sessions_by_skill`
Existing skill refinement	`evolve_server/pipeline/execution.py`	`evolve_skill_from_sessions`, `_EVOLVE_FROM_SESSIONS_SYSTEM`, `_parse_evolve_result`
New skill creation from no-skill sessions	`evolve_server/pipeline/execution.py`	`create_skill_from_sessions`, `_build_session_evidence`
Evolution cycle orchestration	`evolve_server/engines/workflow.py`	`EvolveServer.run_once`, `_handle_no_skill_sessions`, `_materialize_skill`
Optional OpenClaw-driven agent engine	`evolve_server/engines/agent.py`, `evolve_server/engines/agent_workspace.py`	`AgentEvolveServer`, workspace harness
Candidate validation	`skillclaw/validation_worker.py`, `evolve_server/pipeline/skill_verifier.py`	`ValidationWorker.run_once`, `verify_skill_candidate`
Shared skill synchronization	`skillclaw/skill_hub.py`, `skillclaw/object_store.py`	`SkillHub.pull_skills`, `SkillHub.push_skills`, storage backend builders
Config and deployment defaults	`evolve_server/core/config.py`, `skillclaw/config.py`	`EvolveServerConfig`, `SkillClawConfig`

4. Experimental Setup (实验设置)

Benchmark and data scale

实验使用 WildClawBench，论文写明它包含 60 complex tasks，覆盖六类真实 agent 场景：

Category	Example Tasks	Challenges
Productivity Flow	arXiv classification, scheduling, SCP	multi-step pipelines
Code Intelligence	debugging, puzzle solving	execution correctness
Social Interaction	negotiation, chat analysis	multi-turn reasoning
Search & Retrieval	academic search, conflict resolution	API usage
Creative Synthesis	video notes, poster generation	multimodal generation
Safety & Alignment	prompt injection, leakage detection	constraint satisfaction

Benchmark 环境强调真实执行：full Linux container with tools；输入模态包括 text, code, image, video；每个任务由 3—27 metrics aggregated；critical errors 会导致 zero score；任务长度 15—50 steps；还包含 API 与 model download 这类外部依赖。

Baselines and compared settings

论文没有与 GPT/Claude 或其他 agent framework 做横向模型对比，而是做 deployment-view comparison：

Day 1 / baseline：初始 OpenClaw agent + initial skill set，没有经过本轮 collective evolution 的 best pool。
Day 2—6 / SkillClaw best-skill deployment：每天白天使用前一晚 validator 接受后的 current best skill pool。
Skill Evolve Lite controlled validation：三条自定义查询上比较 baseline 与 post-evolve。

这个设置更像在线系统演化实验，而不是静态 benchmark leaderboard；因此结果重点是「同一系统随技能演化是否稳定提升」。

Metrics

主要 metric 是每个 category 的 aggregate success / score percentage。WildClawBench 每个任务会聚合 3—27 个细粒度指标，并有 hard constraint：critical error 直接归零。论文还记录 nightly validator 对候选技能的 Accept / Reject 决策，用来解释为什么 deployed pool 不会每天都变化。

Runtime / training config

这篇论文没有训练底层 LLM；实验是 agent skill evolution + validation。论文实验配置来自 sec/experiment.tex：运行 6 days / 6 rounds，每天分 daytime online interaction 和 nighttime evolution/validation；使用 8 concurrent users；execution、skill evolution、validation 都由 Qwen3-Max 驱动；只汇报四个 representative categories，其余类别留到 future version。

Released code 中可核对的系统配置位于 evolve_server/core/config.py 与 skillclaw/config.py：EvolveServerConfig 默认 engine="workflow"、llm_max_tokens=100000、llm_temperature=0.4、evolve_batch_size=20、skill_verifier_min_score=0.75、validation_required_results=1、validation_required_approvals=1、validation_min_mean_score=0.75、interval_seconds=600、http_port=8787；client 默认 proxy_port=30000、skill_top_k=6、max_context_tokens=20000、validation_enabled=False。这些是 released repo 的运行默认值，不等同于论文中 Qwen3-Max benchmark 的完整内部 launch config。

5. Experimental Results (实验结果)

Main deployment-view results

Category	Day 1	Day 2	Day 3	Day 4	Day 5	Day 6	Abs. Gain	Rel. Gain
Social Interaction	54.01%	60.34%	60.34%	60.34%	60.34%	60.34%	+6.33	+11.72%
Search & Retrieval	22.73%	30.00%	30.00%	34.55%	34.55%	34.55%	+11.82	+52.00%
Creative Synthesis	11.57%	21.80%	21.80%	21.80%	21.80%	21.80%	+10.23	+88.41%
Safety & Alignment	24.00%	24.00%	24.00%	24.00%	32.00%	32.00%	+8.00	+33.33%

主要观察是所有四类都提升，但曲线形态不同。Social Interaction 在 Day 2 从 54.01% 跳到 60.34% 后保持稳定，说明一个高覆盖 workflow bottleneck 被修掉。Search & Retrieval 从 22.73% 到 30.00%，再到 Day 4 的 34.55%，更像分阶段修复：先修文件存在性、路径解析、multimodal input validation，再提升 constrained retrieval planning。Creative Synthesis 从 11.57% 到 21.80% 后平台化，说明 bottleneck 主要在工作目录、输入检查、media preprocessing，而不是生成模型本身。Safety & Alignment 到 Day 5 才从 24.00% 到 32.00%，对应 Git auth fallback、clone-to-directory 等真实执行约束的可靠性修复。

Nightly evolution / ablation interpretation

论文的 Table 4—7 显示，validator 并不盲目接收所有候选技能。Social Interaction 只有 03_task6 在 Night 1 进入 deployed best pool；Search & Retrieval 接受 validate-file-existence 和一次 best-so-far confirmation，拒绝更激进的 multimodal pre-validation、technical search planning、missing input recovery；Creative Synthesis 只接受 validate-tmp-workspace-inputs；Safety & Alignment 在 Night 1—4 连续接受 Git push fallback、auth-failure fallback、correct clone-to-dir / subshell pitfalls 等更新，Night 5—6 的进一步候选被拒绝。

这个结果支持论文的核心 claim：SkillClaw 的收益不是来自越改越多的规则堆叠，而是 validator 选择与 category-specific bottleneck 对齐的少数更新。它也解释了为什么 Day 2—6 常出现 plateau：没有通过验证的候选不会发布，系统宁可保持 best pool，也不部署可能退化的技能。

Controlled validation: Skill Evolve Lite

Query	Baseline	Post-Evolve	Gain
basic extraction	21.7%	69.6%	+47.8%
deadline parsing	41.1%	48.0%	+6.9%
save report	28.3%	100.0%	+71.7%
Average	30.4%	72.5%	+42.1%

Controlled setting 隔离了 main results 中观察到的常见失败模式。save report 从 28.3% 到 100.0%，说明很多失败不是推理能力不足，而是缺少环境相关 SOP，例如 output path、workspace、写文件验证等。deadline parsing 只提升 6.9%，说明有些能力瓶颈不容易通过一次技能改写完全解决。

Case studies

Figure 2 解读：Slack message analysis 任务里，原始 agent 直接抓取所有消息，并通过 trial-and-error 处理 API port 等工具失败；evolved skill 改成先用 preview 过滤 task-relevant messages，再选择性读取全文，同时修正 tool configuration。这个案例说明技能演化能把「会做但低效」的流程改成结构化 pipeline。

Figure 3 解读：ICCV 2025 oral paper analysis 任务中，原始 agent 用大学名启发式匹配 affiliation，容易把非 first affiliation 算进去；evolved skill 明确定义 first affiliation，要对齐 OpenAccess record 并解析官方 PDF 首页。它把模糊 heuristic 转成可检查的 document-analysis procedure。

Figure 4 解读：SAM3 inference 任务里，原始 agent 假设路径、CUDA 和输入资产都可用；evolved skill 先检查 workspace，把 missing path 当成可恢复条件，搜索邻近 task-specific assets，并按系统约束调整执行。这个案例对应 Search / Creative 类任务中「环境前置检查」带来的收益。

Figure 5 解读：多条件选品任务里，原始 agent 会在找到看似合理候选后提前停止；evolved skill 要求逐条用 authoritative sources 验证约束，并在没有完全满足条件的候选时显式报告 partial matches。它体现了 Safety & Alignment 类任务中的 constraint-aware workflow，而不是只追求一个表面答案。

Limitations and caveats

论文没有给出大规模用户数、长期非平稳分布或跨组织隐私边界下的验证。实验只运行 6 天、8 concurrent users，并且主表只汇报四个 representative categories；论文也承认 validation 会引入额外 token / tool execution cost。Released repo 还显示实验式 validation loop 不是默认打开的部署模式，因此实际复现需要显式配置 shared storage、validated publish mode 和 client-side validation worker。

总体结论是：在 WildClawBench 的真实工具环境中，SkillClaw 能把分散交互轨迹转成可验证技能更新，并在多个任务类别上稳定提高 Qwen3-Max + OpenClaw-style agent 的执行表现；它的主要价值不在于提升底层模型，而在于把用户群体的失败经验压缩成共享、可同步、可回滚的 procedural skills。

Paper Notes

探索

SkillClaw: Let Skills Evolve Collectively with Agentic Evolver

SkillClaw: Let Skills Evolve Collectively with Agentic Evolver

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 Overall framework：从 isolated sessions 到 shared skill evolution

3.2 Session trajectory：保留因果链，而不是只看最终答案

3.3 Agentic Evolver：refine / create / skip

3.4 Conservative editing, validation, and synchronization

3.5 Released code implementation：client proxy + evolve server + validation worker

Pseudocode: session summarization and grouping

Pseudocode: evolve an existing skill group

Pseudocode: create a missing skill from no-skill sessions

Pseudocode: validation-gated publishing

4. Experimental Setup (实验设置)

Benchmark and data scale

Baselines and compared settings

Metrics

Runtime / training config

5. Experimental Results (实验结果)

Main deployment-view results

Nightly evolution / ablation interpretation

Controlled validation: Skill Evolve Lite

Case studies

Limitations and caveats

目录