SkillCoach：用于评估和增强代理技能使用的自演化评价框架 SkillCoach: Self-Evolving Rubrics for Evaluating and Enhancing Agentic Skill-Use

方法步骤的完整描述如下。Step 1: 初始rubric构建R^0_t，从任务指令、候选技能、gold和distractor skills、verifier信息和代表性rollouts构建。rubric基于可观察关键步骤K_t = {k_1, ..., k_m}，每个k_i映射到可见事件如file reads、script calls、artifacts、final writes或checks。rubric定义评分规则、证据要求和negative cases，每个有稳定标识符用于本地patching。Step 2: 轨迹执行和judging，agent π_θ在真实环境中执行产生轨迹z_t,i，验证器应用V_t(final(z_t,i))得到结果。Judge提取证据E(z)包括skill reads、gold/distractor信号、tool calls、file edits、script executions、artifacts和validation attempts，然后根据rubric评分。Step 3: 验证门控演化，rollouts分为calibration C_t和held-out validation U_t。仲裁模型提出本地补丁，在U_t上评估候选rubric。硬门H拒绝破坏性变更（如忽略distractors或标记不支持的步骤完成为正确），软目标Q测量证据覆盖、证据质量、反思基础、过程-验证器一致性和紧凑性。只有当ΔH ≥ 0, ΔQ > ε, Δ_mat ≠ ∅且无结构违规时才接受候选。最终R_best = arg max_{R∈A_t} Q(R, U_t)。Step 4: 轨迹诊断，用R_best诊断轨迹中的过程级问题，定位在哪个维度失败（错误选择技能、跳过步骤、错误组合、缺失反思）。Step 5: Rubric-filtered训练，用R_best作为离线过程质量过滤器，只保留rubric-based meta score ≥ 0.95且通过外部验证器的轨迹用于SFT。

技术新颖性体现在多个方面。首先，轨迹级元能力评估框架首次将agentic skill-use形式化为四个可分离维度（skill selection, skill following, skill composition, skill-grounded reflection），与外部验证器信号分离。其次，验证门控演化机制通过本地补丁和硬软门控更新rubric，避免破坏性变更。第三，将外部验证器与rubric分离的设计允许过程质量和结果质量独立评估，揭示了仅基于结果评估的局限性。第四，过程质量与结果解耦，轨迹可能通过verifier但过程质量差（trial-and-error、跳过步骤、选择distractors），也可能失败但过程质量好（正确使用技能但失败）。第五，多个过程维度可分离作为监督信号，ablation显示不同维度提供不同价值。第六，distractor-augmented skill library设置和distractor-boundary分析反映了真实企业部署场景，揭示了大型共享技能库中的选择脆弱性。

独立分析的弱点包括几个方面。首先，initial rubric构建依赖任务指令、技能和rollouts，如果这些输入质量差或不完整，initial rubric可能有gap。self-evolution可以修复，但可能需要更多rollouts和更多evolution rounds，增加成本。改进方向是开发更好的initial rubric生成方法，或结合多种源（human expertise, oracle solutions, historical trajectories）构建更完整的initial rubric。其次，evidence extraction从轨迹中提取skill reads、tool calls、file edits等，但如果agent以非标准方式使用技能或工具，evidence可能不清晰。改进方向是开发更robust的evidence extraction方法，或设计skill interface以产生更清晰的evidence。第三，validation-gated evolution依赖validation set质量，如果validation set有bias或不足够多样化，演化可能overfit到validation set或未能捕获所有重要failure modes。改进方向是使用更diverse和representative validation sets，或添加validation set质量检查和自动augmentation。第四，方法依赖LLM作为judge，可能引入LLM的bias和局限性。改进方向是使用multiple LLM judges进行ensemble，或develop更structured和deterministic的judging方法。第五，方法假设技能库相对静态，但real-world repositories可能持续变化（新skills添加、旧skills更新）。改进方向是探索continuous evolution机制，当skills变化时自动更新rubric。第六，distractor-augmented设置虽然反映真实场景，但仍相对controlled，real-world repositories可能有更复杂的overlap和interdependencies。改进方向是研究更复杂和动态的skill库设置，或从real enterprise repositories直接收集evaluation cases。

未来研究方向包括作者提出的和基于成果可延伸的方向。作者提出process scores可以自然作为RL的reward signals，这是直接延伸。基于成果可延伸的方向包括：探索on-policy RL与rubric-filtered training的结合，用rubric作为reward shaping或reward model；研究从更少rollouts中学习rubric，减少数据收集成本；探索domain-specific rubric customization，为不同领域（healthcare、finance、manufacturing）定制rubric标准和evidence requirements；研究continuous learning和adaptive evolution，rubric随时间持续学习和适应；探索multi-rubric ensemble，用多个rubric评估同一轨迹以获得更robust评估；研究与其他skill lifecycle methods的结合，如skill generation, evolution, verification，形成完整的skill management pipeline；探索在更复杂任务和更长horizons上的应用，测试rubric在multi-step和long-term planning中的适用性；研究human-in-the-loop rubric evolution，结合human feedback和automated evolution；探索rubric的transfer learning，从相似tasks或domains transfer rubric知识；研究rubric在multi-agent scenarios中的应用，评估和训练多个agents的collaborative skill use；探索rubric在安全critical domains的应用，如autonomous driving、medical decision，过程质量可能比最终结果更重要；研究rubric在skill recommendation和retrieval中的应用，帮助agents更快找到相关skills。

论文未明确提及代码开源情况、数据集可用性和算力需求。实验使用标准benchmarks（SkillsBench, Skill-Usage pool）和real skill documents（SKILL.md files），数据集描述相对详细。任务inventory和setup details在Appendix A，implementation details和prompts在Appendix C和D。实验涉及多个LLM backends（DeepSeek-V4-Flash, Opus-4.7, GPT-5.5, Gemini-3.1-Pro, Kimi-K2.6, Qwen3.5-4B, Qwen3.5-9B），这些模型需要相应的API access或本地部署。Training实验在Qwen3.5-4B和Qwen3.5-9B上进行，需要GPU资源。Self-evolution需要multiple rounds of rollouts和judging，计算开销可能较高。复制难度中等：实验设置描述详细，但需要access到具体的LLM models和skill documents；rubric generation和evolution的prompts在appendix，但需要根据具体环境调整；judge和arbitration需要LLM调用，可能有cost和latency；overall workflow相对清晰，但需要careful implementation和testing。建议作者提供代码开源、详细的环境配置和data splits，以提高reproducibility。