内容简介：

在编程智能体场景中，Skill 正逐渐成为连接模型能力与真实研发任务的关键载体。相比一次性的 Prompt 调用，Skill 能够沉淀任务经验、复用执行策略，并在单元测试生成、代码修改、问题修复等复杂工程任务中显著提升 Agent 的稳定性与执行质量。因此，Skill 是否具备持续优化能力，正在成为决定编程智能体自身能力持续进化的重要因素之一。

近期，围绕 Skill 的自迭代、自演进与持续学习，业界已经出现了大量相关探索，关注点也逐渐从“如何构建一个 Skill”转向“如何让 Skill 在真实任务中持续优化并稳定发挥作用”。

围绕这一问题，我们在华为云码道智能体中探索了一套 Skill 自迭代优化机制，使码道智能体能够围绕真实任务结果持续完成 Skill 的生成、验证、评估与优化，并进一步尝试以客观任务指标驱动 Skill 演化。在真实业务代码仓单元测试补齐实践中，该方法将行覆盖率从 46% 提升至 96.61%，分支覆盖率从 33.8% 提升至 83.8%，函数覆盖率从 37.5% 提升至 100%，验证了 Skill 自迭代在真实研发场景中的技术价值。

一、 业界技术洞察：Skill 自进化技术

过去一段时间，编程智能体系统的主要竞争点更多集中在基础模型能力、工具接入能力、上下文长度和任务编排能力上；但随着真实研发场景不断拉长任务链路，越来越多研究与工程实践开始表明，真正决定编程智能体长期效果上限的，已经不只是“单次任务能否做好”，而是系统能否把一次次任务中积累下来的有效做法沉淀为可复用、可更新、可迁移的能力资产。近期关于 Agent Skills 的系统性综述也明确指出，Skill 正在从一次性的提示增强或工具调用封装，逐步演化为承载程序性知识、支撑长期能力积累的重要中间层。

这一趋势在近期代表性研究中已经表现得相当清楚。AutoSkill 的核心思路，是从真实交互轨迹中自动抽取、维护并复用 Skill，把原本容易随任务结束而消散的交互经验，转化为显式、可维护、可迁移的能力资产，而且这一过程不依赖重新训练底层模型。XSkill则进一步把可复用知识拆分为“经验”和“技能”两层，在多路径 rollout、归纳和检索适配的基础上形成持续学习闭环，并在多项 benchmark 与不同 backbone 设置下取得了稳定提升。

如果说上述工作更强调“如何把经验沉淀为 Skill”，那么 SkillRL一类方法则开始把 Skill 演化进一步推进到“围绕目标函数持续试验和优化”的阶段。它的核心思想是让 Agent 在固定预算内持续提出修改、执行实验、根据结果获得反馈，并把任务结果直接转化为后续优化信号。与此同时，Anthropic 在 2026 年发布的 Skill Creator更新，也已经把 Skill 开发从“写出一个 Skill”推进到“围绕真实任务写测试、跑评测、比较新旧版本并持续重写优化”的工程闭环；这背后反映出的一个关键信号是，Skill 优化正在从经验驱动转向证据驱动。

把这些研究和工程实践放在一起看，可以看到一个越来越明确的方向：未来高水平编程智能体的竞争，不再只是“会不会调用工具”，而是“能不能把经验长成 Skill，并让 Skill 持续进化”。换句话说，编程智能体正在从“任务执行系统”走向“能力成长系统”。而在这一过程中，Skill 不再只是附属模块，而正在成为连接经验沉淀、任务验证和持续优化的关键中间层；与此同时，工程侧的 harness 设计也越来越被证明会直接影响这套能力能否稳定发挥出来。

二、从自动开发到持续优化：技术探索与实践效果

2.1 基于系统化评估技术的 Skill 自迭代 Pipeline

当前这套面向穿刺场景的 Skill 自迭代 pipeline，已经初步形成了一个较完整的闭环结构，整体可以拆解为四个相互衔接的核心单元：意图捕获、Skill 编写与验证、Skill 评估，以及迭代优化。相比传统依赖人工手工调试的方式，这套 pipeline 更强调让 Agent 在真实任务中完成从需求理解到能力演化的全流程闭环，把原本分散的分析、开发、验证和改进过程，压缩为一条可持续运行的自动化链路。

图 1 Pipeline 概览

首先是意图捕获模块。该模块主要负责对输入的任务信息进行统一归纳和结构化整理，将原本分散、非结构化的需求表达，转化为后续优化流程可以直接消费的任务定义。经过这一过程，系统会沉淀出三类关键产物：一类是对当前任务能力边界和目标的概括，也就是 Skill 需求本身；一类是衡量效果优劣的量化指标；另一类则是训练与评测所依赖的样例。这三类产物为后续 Skill 的编写、验证和迭代建立了一个统一起点。

Skill 编写和验证模块的作用是能力生成与效果验证：一方面，Agent 需要在既定任务约束下持续迭代 Skill；另一方面，它也需要让新旧版本在统一标准下进行对照执行和量化比较。为了尽可能保证比较结果可信，系统会让不同版本的 Skill 在相互独立的条件下完成评测，并完整保留执行过程与最终结果，作为后续分析的依据。与此同时，系统还会围绕具体任务生成更贴近用户视角的期望描述，使得验证过程不只是停留在输出层面的简单比较，而是进一步对应到“用户真正希望看到什么样的过程和结果”。

Skill 评估模块的核心作用，是把前一阶段沉淀下来的执行记录转化为可量化、可解释的反馈信号。系统会结合任务期望，对 Skill 在不同样例上的表现进行逐条分析，判断它是否真正达成了预期目标，并据此统计整体达成情况。和只关注最终分数的评测方式相比，这种设计更强调证据驱动：既看结果是否正确，也看过程是否符合预期。基于这些分析结果，系统能够进一步判断本轮 Skill 迭代是否相较此前版本取得了实质性提升，并自动生成面向下一轮优化的反馈信息。

最后是迭代优化模块。该模块负责承接评估结果，将上一轮分析中暴露出的有效经验与失效模式，进一步转化为下一轮 Skill 更新的依据。也就是说，系统并不会在一次验证后停止，而是会围绕反馈继续调整和优化 Skill，推动其进入持续演化状态。至此，整个流程形成了一个完整闭环：从需求理解出发，经由 Skill 生成与验证，再到效果评估与反馈回流，最终实现面向真实任务的连续优化。

整体来看，这四个模块共同构成了一条相对完整的 Skill 自进化链路：前端负责把非结构化需求压缩成结构化问题定义，中段负责在统一约束下完成能力生成与对照验证，后端则通过基于证据的评估与反馈回流，推动 Skill 进入多轮优化。它试图解决的，不只是“如何生成一个可用的 Skill”，而是“如何让 Skill 在真实任务中被不断验证、不断修正、不断积累”。相比一次性 Prompt 工程或人工规则调优，这样的设计更接近一个可运行的研发闭环，也更贴近业界近年来对 Agent 系统“持续学习、持续评估、持续改进”的主流理解。

当前该 pipeline 在码道上进行穿刺，在一些较为基础的 Skill 上取得了比较好的效果，已经可以初步迭代 Skill 开发过程中的一些基础工作。针对单元测试生成，我们抽取了来自开源项目中的被测函数，并且对比了 a. 不依赖 Skill；b. 尝试用该方法自迭代的单元测试生成 Skill；c. 人工调优编写的单元测试生成 Skill。结果表明，自动迭代生成的 Skill 在行覆盖率，测试通过率，以及断言有效性三个指标上分别提升 90%、66%、和 80%，效果持平人工调优生成的 Skill。下面通过一段效果演示视频，展示 Skill 自迭代技术在单元测试生成场景的效果。

(此处为 skill 自迭代 demo 视频)

近期，我们将该技术在实际业务场景（单元测试用例智能生成场景）进行实践验证，针对某 TS 语言代码仓中一个中等偏复杂的业务代码文件（约 680 行代码，15 个函数，涉及 patch 解析、文件操作、模式匹配等多种技术）补充单元测试。该文件的复杂度主要体现在：实现了完整的 patch 解析和应用功能，包含三种操作类型支持、文件内容替换算法、多策略模式匹配以及文件系统操作；同时包含复杂的解析状态机、较多错误处理分支和递归/迭代的数据处理逻辑。

测试结果表明，使用自迭代生成的 UT Skill 在码道中生成单元测试后，相比不使用 Skill 的基线版本，各项覆盖率指标均有显著提升：行覆盖率从 46%（319/680）提升至 96.61%（657/680），分支覆盖率从 33.8%（48/142）提升至 83.8%（119/142），函数覆盖率则从 37.5%（6/16）大幅提升至 100%（16/16）。这一实践结果充分验证了 Skill 自迭代技术在真实业务代码场景中，能够有效提升单元测试的覆盖质量和代码逻辑理解能力。

2.2 基于演化算法的 Skill 自迭代探索

在 2.1 所介绍的 Skill 自动优化 pipeline 中，我们已经尝试用“期望满足程度”替代人工或 AI 的纯定性判断，对 Skill 迭代效果进行量化评估。相比传统依赖主观经验的方式，这一步让 Skill 优化初步具备了可度量、可比较的闭环基础。与此同时，系统也引入了辅助脚本，对编译率等部分结果指标进行更稳定的分析，以提升评测的一致性。

不过，这套方案的局限也比较明显：它虽然实现了量化评估，但整体粒度仍然偏粗，核心判断依然较大程度依赖 AI 自行完成。对于真正面向生产环境、高可用场景的 Skill 自动进化来说，仅靠这种半结构化的评估方式还不够，更关键的方向在于，让优化过程尽可能建立在客观、稳定、可复现的任务指标之上。这一点其实也和近期关于 Skill 真实使用效果的研究观察是一致的：只有当 Skill 的检索、选择、适配和细化能够真正对任务结果产生稳定贡献时，Skill 才能从“看起来有用”走向“在生产中可靠有用”。

针对上述局限性，我们进一步在单元测试场景中探索了一套完全依赖客观任务指标驱动的 Skill 自动进化 pipeline。该方案延续了 2.1 中环境隔离的思路，确保不同版本 Skill 的执行与比较保持公平可控；但在评估阶段，不再主要依赖 AI 对期望达成情况进行解释性判断，而是直接围绕任务结果构建优化目标。在穿刺阶段，我们定义了四项核心指标：编译率、Pass@1、平均编译错误数量和平均修复耗时。系统会基于这四项指标的加权得分，对当前轮次 Skill 的整体效果进行评估，从而用更客观的方式判断 Skill 是否真正取得提升。

图 2 方法概览

在迭代阶段，系统也不再只是围绕单轮反馈做局部修改，而是将历次 Skill 迭代的副本及其评估表现一并交给 Agent，由其分析不同版本中的有效因素，并进一步组合形成更强的 Skill。相比前一阶段的方法，这套 pipeline 更强调以任务结果为中心驱动 Skill 演化，也为 Skill 自动进化从“可用”走向“生产可落地”提供了更扎实的基础。

我们仔细评估了该方法在 50 个被测方法组成的训练集上的效果，可以看到，随着训练的增长，平均错误数量（avg_errors）和平均修复距离（avg_fix_gap）两个指标均有所提升。

三、未来工作展望

整体来看，未来工作可以重点聚焦两个方向。

首先，是面向真实研发场景的泛化验证。当前 Skill 自动演化已经在特定任务和局部样本上展现出明确收益，但这类收益能否稳定迁移到未见任务、不同代码库、不同技术栈以及更复杂的工程约束下，仍然需要进一步验证。后续需要构建覆盖更多任务类型、更多真实仓库和更多难度层次的评测集合，从而更准确地判断 Skill 进化带来的收益边界，并避免系统只在局部数据上取得提升。

第二，是从单点 Skill 优化走向面向运行闭环的 Harness Engineering。后续优化的重点，不应只放在 Skill 本身，而应进一步扩展到 Skill 的触发方式、检索策略、评测机制、回归验证、失败恢复以及长链路执行约束等整个运行框架。近期 Anthropic 的公开工程实践已经越来越清楚地表明，Agent 在长时任务和复杂软件工程场景中的效果，高度依赖 harness 设计，包括任务拆分、检查点、上下文压缩、回归检查与环境稳定性控制等机制。对于研发 Agent 来说，未来更有价值的方向，是把 Skill 优化与运行机制优化结合起来，使系统不仅“拥有更好的 Skill”，而且“具备让 Skill 稳定发挥作用的工程框架”，从而推动 Skill 自动进化真正走向生产可落地。