26年4月来自Dream X公司团队的论文“SkillClaw: Let Skills Evolve Collectively with Agentic Evolver”。

大语言模型（LLM）智体（例如 OpenClaw）依赖于可重用技能来执行复杂任务，然而这些技能在部署后往往保持静态。因此，用户之间会反复发现类似的工作流程、工具使用模式和故障模式，从而阻碍系统通过经验进行改进。虽然不同用户的交互可以提供关于技能何时有效或失效的互补信号，但现有系统缺乏将此类异构经验转化为可靠技能更新的机制。为了解决这些问题，提出 SkillClaw，一个用于多用户智体生态系统中集体技能演化的框架。SkillClaw 将跨用户和随时间变化的交互作为改进技能的主要信号。SkillClaw 持续聚合使用过程中生成的轨迹，并使用自主演化器对其进行处理。该演化器识别重复出现的行为模式，并通过改进现有技能或扩展其新功能，将其转化为技能集的更新。最终生成的技能维护在共享存储库中，并在用户之间同步，使得在一个上下文中发现的改进能够传播到整个系统，而无需用户付出额外的努力。通过将多用户体验融入到持续的技能更新中，SkillClaw 实现了跨用户知识转移和累积能力提升，WildClawBench 上的实验表明，在有限的交互和反馈下，它显著提高了 Qwen3-Max 在真实世界智体场景中的性能。

---

现有的智体自适应方法未能支持技能在不同用户之间以及随时间推移的积累与演化。基于记忆的方法通过存储过往的交互轨迹以供检索（Shinn et al., 2023; Zhao et al., 2024; Fang et al., 2025a; Tang et al., 2025; Ouyang et al., 2025a; Chhikara et al., 2025; Liu et al., 2026），但此类记录往往局限于特定的实例，难以泛化为通用的改进行为。基于技能的方法将经验压缩为结构化的指令（Xia et al., 2026a; Zhang et al., 2025a, 2026b; Wu et al., 2025; Zhang et al., 2026a），然而它们往往将由此构建的技能库视为一种静态资源，无法随实际应用而发生演化。尽管局部优化能够提升单个智体实例的性能，但这些改进往往是孤立的，无法在不同用户之间实现积累，从而导致技能体系呈现碎片化状态，而非随时间推移实现整体性的提升。当前所缺失的，正是一种能够将日常交互转化为持续技能演化、并促成技能在不同用户群体中实现协同提升的机制。

基于这一洞察，提出 SkillClaw——一个专为多用户 OpenClaw 风格智体生态系统设计的“技能协同演化”框架（如图 1 所示）。SkillClaw 采用一种集中式的演化架构：部署在不同用户端的智体在日常使用过程中，会持续生成一系列交互轨迹。这些交互轨迹会在不同用户之间及随时间维度上进行汇聚，作为智体执行现实世界任务的实证数据；随后，这些数据将由一个集中式的演化引擎进行处理，从而驱动技能体系的更新与迭代。基于所汇聚的交互轨迹数据，该演化引擎会对成功的执行案例与失败的案例进行综合分析，识别出反复出现的问题与行之有效的操作流程，并通过对现有技能进行精修、创建新技能或调整技能描述等方式，对共享技能集进行更新。与预设的固定流程不同，这一演化过程由一个具备自主性的智体所驱动；该智体能够基于交互实证数据进行开放式的推理，并直接对技能定义进行编辑与修改。更新后的技能随后会被同步至所有的智体实例中，从而确保在特定情境下所获得的改进，能够跨越用户界限并随时间推移，泛化并应用于未来的各类交互场景之中。由此便形成一个持续演化的闭环：交互数据驱动技能的更新，而更新后的技能反过来又进一步优化后续的交互体验。从用户的角度来看，这一过程无需付出额外努力，因为数据的收集、演进和同步均在后台自动进行。

在所设定的场景中，不同的用户独立地与其各自部署的 OpenClaw 智体进行交互，这些交互可能跨越不同的设备、环境及时间。尽管这些交互在运行时彼此独立，但它们共享着一个共同的行为空间：相似的工作流、重叠的工具使用方式以及反复出现的故障模式，在不同用户之间普遍存在。SkillClaw 建立在这样一种观察之上：当不同用户在多元化的情境下演练同一项技能时，他们所产生的交互数据能够为该技能的行为边界提供互补的视角，从而揭示出该技能在何种条件下能够正常运作，又在何种条件下会发生失效。仅凭单一用户的交互数据，往往难以产生足够的信息量，从而无法有效区分出究竟是具有普适性的改进，还是仅仅针对个别情境的特殊修补。唯有通过汇聚来自不同用户的交互证据，方能奠定坚实的基础，从而使技能的稳健演进成为可能。

1 从孤立会话到共享证据

多用户技能演进需要将一系列孤立且异构的交互会话，转化为一种支持跨用户推理的形式。SkillClaw 通过两个阶段实现这一目标：首先，它对单个会话进行结构化处理以保留因果信息；随后，将这些会话汇聚成一个共享的证据库。 在系统层面，SkillClaw 通过一个通用的技能库将独立部署的智体（Agent）相互连接起来。每个智体都能访问当前的技能集，并在日常使用过程中生成交互会话。这些会话会被记录下来并作为共享证据上传。一个中心化的演进引擎会定期处理收集的会话，更新技能库，并将更新后的技能同步回所有的智体，从而形成一个闭环：

多用户交互 → 会话收集 → 技能演进 → 技能同步。

在推理阶段，智体会在其提示（Prompt）中接收一份可用技能目录，并能动态地选择并加载那些与当前任务相关的技能。用户之间无需直接交互，智体之间也无需进行协调。整体能力的提升完全源于共享技能的演进。 在这个闭环中，每一个交互会话所包含的内容远不止是简单的对话。SkillClaw 记录完整的因果链条：包括用户提示、智体的动作（含工具调用）、中间反馈（如工具执行结果、错误信息及用户的明确响应），以及智体的最终回复。之所以记录所有这些信息，是因为大多数技能层面的故障都属于程序性错误。错误的参数格式、遗漏的验证步骤，或是工具调用的顺序颠倒，都可能导致任务失败；然而，这些问题往往不会体现在最终的回复之中。唯有通过检查中间的“动作-反馈”轨迹，才能诊断出这些问题。每一个原始会话都会被转化为一种结构化的表示形式，从而保留这一因果链条：

提示 → 动作 → 反馈 → · · · → 智体回复。

此外，还会从每个会话中提取轻量级的元数据，具体包括：(i) 该会话引用哪些技能；(ii) 是否发生工具执行错误；以及 (iii) 对会话质量的粗略评估。这些信号有助于对会话进行归类整理，但并不会强行施加僵化的标签。 一旦会话完成结构化处理，它们便会依据所引用的技能进行分组，从而为跨用户推理奠定基础。对于任意特定的技能 s，会收集所有曾调用过该技能的会话：

G(s) = {τ_i | s∈K_i}，

同时，将那些未曾使用任何技能的会话归入一个单独的分组 G(∅)。这种分组方式不仅仅局限于对数据进行整理。当多个会话调用同一项技能，但在不同的用户、任务或环境下产生截然不同的结果时，通过对比分析，能够直接揭示该技能在何种情境下奏效、又在何种情境下失效——在此过程中，技能本身充当受控变量。这相当于一种“自然消融实验”（natural ablation），从而使两类仅凭单用户数据难以可靠完成的操作成为可能：(1) 评估现有技能在多元化的真实世界应用场景中究竟表现如何；(2) 识别那些现有技能尚未涵盖、且通过 G(∅) 分组中的模式所显现出来的重复性操作流程。

2 智体驱动的技能演化

SkillClaw 的核心是一个智体驱动的演化器（agentic evolver），它利用开放式的推理能力来更新共享技能库。SkillClaw 实例化一个智体演化器——这是一个基于大语言模型（LLM）的智体，配备一套结构化的“驾驭”（harness）；该驾驭负责向演化器提供分组后的会话证据、当前的技能定义，以及一套允许执行的演化操作。这套驾驭虽然提供了结构化的输入，但并不限制演化器的推理过程。演化器能够针对不同上下文长度的会话以及不同格式的技能，诊断出问题的根本原因，并据此决定应采取何种行动。这种将固定的驾驭结构与开放式推理过程相分离的设计，使得 SkillClaw 能够应对各种多样的故障模式，而无需针对每一种故障类型预先手工编写特定的规则。

具体而言，给定某项技能 s 及其关联的会话组 G(s)，演化器会同时审查成功的执行案例与失败的执行案例，并从中选择以下三种行动之一：
• 优化（Refine）：根据观察的故障模式，更新该技能以修正已识别的错误，或提升其鲁棒性。
• 创建（Create）：当 G(s) 中显露出某种反复出现的子流程，且该流程尚未被任何现有技能所涵盖时，引入一项全新的技能。
• 跳过（Skip）：当现有证据不足以支持进行任何修改时，保持该技能不变。

对于 G(∅)中的会话（即那些未曾调用任何技能的会话），演化器会将重点放在发掘那些缺失但具有复用价值的流程上。只有当观察的模式足够具体、具备可传授性且极有可能在未来再次出现时，才会据此创建新的技能。

无论最终选择了哪种行动，演化器在进行推理时，总是会将成功的会话与失败的会话结合起来进行综合考量。成功的会话定义技能的“不变量”——即那些运行正常且绝不应被改动的组成部分；而失败的会话则定义“修正目标”——即那些需要进行行为矫正的具体环节。正是这种综合性的视角，有效避免那种“低级错误”的发生：即在试图修复某个问题的同时，却无意中破坏此前原本运行正常的流程。每一次更新操作既修正已识别的缺陷，又保留那些经由成功会话验证为有效的成分，从而确保技能演化过程的累积性与持续改进。完整的演化流程详见“算法 1”（Algorithm 1）。

3 技能同步与演化闭环

在演化阶段结束后，候选技能的更新内容需经过验证，方可被回写至共享存储库中。验证工作在夜间进行，并利用闲置的用户环境来执行，从而确保评估结果能够真实反映实际的部署工况。对于某项技能 s 及其候选更新 s′，系统会从当日收集的交互数据中筛选出相关的任务样本。这两个版本将在完全相同的环境中运行，并使用完整的工具链——其中包括多步交互过程及中间反馈机制。执行完毕后，系统将利用模型对 s 与 s′ 所产生的任务结果进行对比评估。最终的采纳决策将依据整体任务的成功率及执行稳定性来判定。若更新后的技能展现出更优异的性能，则会被标记为“接受”（Accept）；反之，则标记为“拒绝”（Reject）。获准接受的更新将被合并至共享存储库中，并同步分发给所有的智体（Agents），以供次日使用；而被拒绝的更新则仅作为候选方案予以保留，不会被实际部署。得益于此，用户在进行交互时，所调用的始终是经前一夜严格验证后的“最优技能池”，而非未经核实的草案更新。这一验证环节确立了一种“单调递增式”的部署机制：由于仅有那些能够带来性能提升的更新才会被采纳，因此，已部署的技能库将随时间的推移而持续优化，绝不会出现性能退化的现象。若将此机制与前述的演化流程相结合，整个系统便构建起一个完整的闭环生态：

交互 → 证据 → 演化 → 验证 → 部署

在此闭环中，经过更新的技能将反过来重塑未来的用户交互体验，并为下一轮的技能演化提供全新的数据证据。

这一设计理念赋予系统三大核心特性。首先是“集体演化”：系统将汇聚来自所有用户的交互会话数据；在某次特定交互中发现的知识与经验，将被广播至一个共享的技能生态系统中，从而惠及所有的用户群体。其次是“全程自动化”：从用户会话的录制采集，直至技能更新的同步分发，整条工作流均在全自动模式下运行，无需任何人工的筛选干预或显式的用户指令。用户唯一需要提供的“人工输入”，仅仅是其对智体进行的日常性、常规性操作。第三是“智体的自适应能力”：技能的更新与迭代并非基于预设的僵化规则，而是通过智体所具备的“开放式推理能力”来生成；这一机制赋予系统极强的鲁棒性，使其能够有效应对此前从未遭遇过的各类故障模式及用户使用场景。

从用户的视角来看，上述所有的幕后运作过程均是完全隐形的。用户只需像往常一样与智体进行交互即可，而技能的演化与迭代工作则在系统的后台静默进行。随着时间的推移，原本分散、孤立的个体用户体验将被逐步整合、沉淀为一个共享的技能集；而这一共享技能集，亦将伴随着用户的持续使用而不断地自我完善与精进。

---

1 基准测试：WildClawBench

在 WildClawBench（Ding，2026）上对 SkillClaw 进行了评估。这是一个真实世界的智体基准测试集，包含跨越六大能力领域的 60 项复杂任务。如表 1 所示，该基准涵盖多种多样的场景，包括生产力工作流、代码执行、社交互动、信息检索、创意生成以及安全对齐。与以往的基准测试不同，WildClawBench 要求在逼真的环境中进行完整的端到端执行，并涉及多模态工具的使用。如表 2 重点列出了其关键特性，包括细粒度的评估指标以及旨在强制确保严格正确性的硬性约束条件。

2 实验设置

通过一种昼夜交替、持续进行的技能演化流程，模拟一个逼真的部署场景。实验共运行 6 天（即 6 个轮次），其中每一天包含两个阶段：白天的在线交互阶段，以及夜间的技能演化与验证阶段。在白天，用户与已部署的 OpenClaw 智体进行交互，以完成 WildClawBench 中的各项任务。这些交互过程会生成“会话轨迹”，记录下在执行过程中遭遇的失败模式、边缘案例以及反复出现的瓶颈问题。

在夜间，系统会对收集的交互数据进行处理，针对上述观测到的缺陷生成“候选技能更新”。随后，验证器会对这些候选更新进行筛选；唯有通过审批的技能，才会被添加至“共享部署池”中，供次日使用。这一过程形成了一个闭环：用户在白天利用当前最优的技能池进行操作，而系统则在夜间吸收反馈并生成更新后的技能，随后将这些新技能重新部署以支持后续的交互。

实验设置涉及 8 名并发用户，每位用户均依据其各自的目标及任务要求，在 WildClawBench 任务框架下与系统进行交互。所有的执行、技能演化及验证流程均由 Qwen3-Max 模型提供支持。在系统层面，维护着一个共享的“当前最优技能池”。第 1 天的实验始于一套初始技能集，该集合对应于基线（Baseline）水平。在随后的轮次中，仅有那些在交互过程中被触发、且显现出改进潜力的技能，才会被纳入候选更新的考量范围。本次实验结果主要针对四个具有代表性的类别进行汇报。

验证机制。验证机制是实验设计中的一个关键组成部分。在夜间阶段，系统首先会依据白天累积的交互日志，识别并确定候选的技能更新项。随后，这些候选更新会被部署至可用的用户环境中，并在实际运行条件下接受评估。验证器遵循一条简单的决策规则：如果某项候选技能在相应的验证任务中表现优于当前已部署的最佳技能，则将其标记为“接受”；反之，则标记为“拒绝”。获接受的技能将被并入当前的最佳技能池中，并于次日向所有用户进行部署。而被拒绝的技能仅作为候选记录予以保留，不会被部署。因此，用户始终是在与前一晚经充分验证的最佳技能池进行交互，而非那些未经核实的更新。尽管这种验证策略会产生额外的 Token 成本——因为候选技能必须在真实环境中执行并涉及完整的工具交互——但相较于未经验证便直接部署的做法，这一开销所换来的面向用户的性能稳定性显著更高。