SkillMorph 用轨迹引导的故障定位演化智能体技能，在 SWE-Skills-Bench 上把 pass3 从 67.96% 提升到 88.37%

SkillMorph 在生成任何修订之前先显式确定编辑位置，即需要修改的技能内容，并把这一决定建立在执行轨迹的行为证据之上。 已有技能演化方法通常直接让 LLM 从任务结果、用例分数或整条轨迹生成修订，问题行为由 LLM 隐式判定且不留记录；ContractSkill 虽能显式定位，但要求技能可表示为带后置条件的有序步骤并配有确定性验证器。SkillMorph 改为以动作作为被覆盖实体，因为自然语言指导没有代码那样的显式执行语义。 论文以 mcp-builder 技能为例给出定位链条：Task 1 中智能体通过连接 A 导入文档却通过第二个内存连接 B 查询，因内存 SQLite 数据库对连接私有而验证报 no such table: documents（13 项检查通过 11 项）；Task 2 中智能体以 SIGTERM 停止服务器、未检查输入关闭时的关停，检查超时（17 项检查通过 16 项）。两处问题动作都发生在读取 reference/node_mcp_server.md 之后，因而被追溯到该文件。

可疑动作的识别同时利用稳定性与泛化性：跨重复执行比较失败与成功覆盖，按相邻轮次的变化调整证据，再跨任务聚合。 已有方法多从有限证据归因，例如 SkillAdaptor 把失败轨迹归因到最早的可执行步骤，其他方法让 LLM 对一小批 rollout 做反思，缺少行为与失败关联一致性的度量。SkillMorph 借用谱系故障定位（SBFL）的 Ochiai 形式，并额外处理演化场景：按上一轮变化调整覆盖计数，且先调整再跨任务聚合，以免不同任务的相反趋势相互抵消。 论文给出任务级覆盖计数、历史调整权重与可疑分数的公式化定义，并说明成功运行中由某动作引入、随后被智能体自行恢复的错误也计入失败覆盖，因为同一错误在另一次运行中可能未被解决而导致失败。

在 SWE-Skills-Bench 与 CannBot 上，SkillMorph 演化出的技能在留出任务上取得更高且更一致的执行成功率，并优于四种已有技能演化方法。 相对原始技能，SWE-Skills-Bench 上 pass@3 从 82.45% 升到 95.51%（相对提升 15.84%），pass3 从 67.96% 升到 88.37%（相对提升 30.03%）；CannBot 上 pass@3 从 80.00% 升到 93.33%（相对提升 16.67%），pass3 从 46.67% 升到 93.33%（相对提升 100%）。相对最强基线 CAP-Evolve，SWE-Skills-Bench 上多解 16 个任务，且一致解出的任务增益更大（17 至 68 个任务，pass3 高 3.47 至 13.88 个百分点）。 SWE-Skills-Bench 共 490 个任务，SkillMorph 取得 95.51%（468/490）pass@3、88.37%（433/490）pass3，在 1,470 次评测运行中 trial 级准确率 92.24%（1356/1470）；CannBot 上 15 个任务中 14 个在每次试验都成功，三项指标均为 93.33%。细粒度比较显示 SWE-Skills-Bench 上改进 126 个任务、回退 9 个，而 CAP-Evolve 改进 122 个、回退 36 个；在 333 个原本稳定解出的任务上保留 327 个（98.20%），CAP-Evolve 为 309 个（92.79%）。

消融实验表明重复执行主要贡献任务覆盖，显式编辑位置定位主要贡献执行一致性，历史信息影响最小；该方法还在真实 AI 算子开发中落地。 论文把技能演化拆成可检验的组件，并给出各组件缺失时的量化代价，同时报告了与开发团队协作的部署结果。 Single-run 变体使 pass@3 在 SWE-Skills-Bench 与 CannBot 上分别下降 5.31（26/490）与 13.33（2/15）个百分点；去掉定位使 pass3 分别下降 6.12（30/490）与 33.33（5/15）个百分点；w/o History 影响最小。部署方面，评测覆盖 63 个 AI 算子，提交的 6 个技能修订 PR 全部被开发者接受；对原始与演化技能都能通过正确性检查的任务，平均完成时间从 123.63 分钟降到 72.81 分钟（降低 41.11%）；在 1,788 次用例级测量中，44.18% 的生成内核达到或超过参考实现性能。

该方法面向使用文件包式技能、且任务带有可执行验证或测试的代码智能体，适用于技能集合服务同一类相关任务、并存在留出任务用于评估的场景。论文在 SWE-Skills-Bench 的 49 个独立技能与 CannBot 的 12 个协同技能上验证，覆盖仓库级软件工程与 AscendC 内核生成两类领域，并在 AI 算子开发团队的 63 个算子上部署。对读者而言，这意味着若你的智能体工作流能提供重复执行与通过/失败判定，就可以复用“先定位可疑动作、再回溯编辑位置、最后生成并筛选修订”的流程；若技能无法被验证器判定，或任务之间不构成同一类，则论文给出的证据不直接覆盖。

读者仍需关注若干开放问题。可疑动作的识别依赖一个刻意收窄的 LLM 判断，即某动作是否引入了错误状态，而非判断哪个动作导致失败；论文指出后者即便对强模型仍然困难，因此这一判断的稳定性会影响后续定位。历史调整与跨任务聚合的权重由公式给出，但论文未报告这些超参数在不同技能集合上的敏感性。消融显示 w/o History 影响最小，说明历史信息在当前设置下的边际作用有限，其在更长演化轮次或更频繁回归的场景中是否更重要仍待观察。论文还提到跨任务演化积累的经验可能仍无法解决当前任务特有的困难：在双向交叉验证中有 21 个任务在原始技能与用另一折演化的技能下三次评测全部失败，其中 5 个在自身参与演化时至少成功一次，这提示任务级自适应与跨任务经验如何结合仍是开放方向。此外，CannBot 因执行成本高只使用单一固定划分，其结论对划分方式的依赖程度未被进一步检验。