从 Skill 到 Agent:评测技术的路径与实践

本文整理自2026年阿里云云栖大会演讲实录。

演讲人：

赵建强 阿里云智能集团高级技术专家

刘群 阿里云智能集团高级技术专家

大家下午好，我叫赵建强。接下来由我和我的同事刘群给大家分享Skill和Agent的评测实践。

我先以一个具体的问题开始我的演讲，就是我的一个订单日报的任务没有产出，这个时候用户说一句“给我修复和重跑”。大家有没有想过，负责完成这个任务的这个skill，它的可靠性是怎么保障的？我会围绕这样一个具体的任务来展开我下面讲的内容。

大家可以看到，Agent收到给我修复和重跑的时候，其实它整个需要经过左侧这个端到端的一个链路，首先需要去理解意图，比如说我要去恢复什么？应该要遵守哪些约束，再去做一些任务的拆解，再去选择一个合适的一个skill去执行，最后拿到结果。其实从这个左侧的链路当中可以看到整个skill的一个重要性，它是决定这个任务成败的关键因素。

我们再回到右侧这个DataWorks数据开发的skill，大家可以留意一下这个skill，因为我下面讲的一些内容，可能会以这个skill去贯穿这些所有的评测相关的一些内容。包括后面讲到的像测试的覆盖，质量的判据，自动化回归等，我们都会回到这个订单日报的实际的案例当中给大家去讲解。可以看到这个DataWorks数据开发的一个skill，它的核心的流程首先是定位任务，然后再去诊断原因，再去确认这个变更，再做一些开发校验，再做一个发布和重跑，最后去验证这个产出是不是符合预期。其实在这个过程当中是有一些关键的节点，如果你的这个skill质量存在问题，它可能会带来一些严重的问题，下面我就讲解三个关键的问题。

第一个，我们在定位的时候可能是选错了一个同名的任务，那这个时候有可能修改了其他的、不是这次故障带来的这样的一个同名的任务，会导致原来的故障肯定是没有解决，而且又引入一些新的故障。

第二个问题，我们在这个恢复的过程当中可能超出了这个授权的一个范围，导致把这个未经过审批的变更带到生产环境，会导致生产变更的失控。

第三个问题就是宣布这个任务恢复了，但是实际上其实他只是执行成功，那这个时候我们的这个订单日报其实还是不可用的，这样就是会掩盖掉真实故障。所以说如果我们要去评测这个skill，应该要看它具体改了什么？它的修改是不是在可控范围内？以及对应它的产出，我们有没有做过强一致的校验？我们把这三个检测的要求连成一套可执行的流程，这个其实就是skill的评测体系需要解决的问题。

我们怎么去体系化地解决上面这三类核心问题，接下来给大家分享一下我们skill的整个评测的一个框架是怎么样的？

首先它最上面是有我们对于skill质量的标准以及版本和用例，还有路径和判据的统一管理，本质上是确保每轮的评测我们有个一致的对象和依据。

中间是评测的一些核心能力，包括 trigger 测试，是确保应该触发的skill它是能够正常触发，然后不应该触发的这种，应该是要拒绝。测试设计主要是围绕我们接下来要讲到的路径覆盖，它本质是说去把这个条件的构造和用例做一些补齐，然后再往后是执行和判定，我们有了覆盖以后，我们需要通过这个agent去加载对应的skill ，按照用例的要求去完成整个的任务，我们对于这个执行的过程和最后的结果做一个质量的判据，用例会把这个路径的覆盖和质量的判据连在一起，既能保证我们讲到测了多少，也能保证做对了多少。能够形成一个整体的体系。

执行底座主要是说我们环境和数据的准备，包括我们配置这些权限和一些依赖，以及我们对应的复位和释放。最下面是持续保障，我们需要通过一些变更、定时、全量的这样的自动化的流程来保障持续的质量，还包含我们的一个环境的可重入以及human in the loop的一个可重入。

有了这套体系化的质量保障，我们当前带来哪些数字上的一些变化？

第一个是我们服务的一个规模，阿里云官方skill的话，我们现在已经全部服务于这二百六十三个，当然其实这个数字现在比这个要更多一些。这个是体现整个测试体系服务的规模。

第二个就是每个skill我们现在是经过了大概十一轮左右的一个评测，这个其实是体现我们整个持续投入的程度。

第三个就是我们评测前置检测出来critical类的问题有一千五百例左右。这个是体现我们前置发现问题的成效。我认为skill评测本质上是说我们在skill进入生产之前，把问题和风险识别出来并且推动修改，这样就能避免我们把问题带到生产。

如何去持续地基于这套体系能够让它去稳定可靠地去发现这些问题呢？

在讲方法之前，我先给大家介绍一下，什么是好的skill。

用一句话很简单，我认为好的skill应该是说在安全和成本可控的情况下，能够持续可靠地完成任务，我认为这是一个好的skill。那么它会落到功能、稳定、安全、效率、成本这五个维度。

讲完这个五维度质量，那我们怎么把这个五维度的质量带到实际的执行路径当中。接下来我给大家分享我们的具体的路径的覆盖，skill路径的覆盖和对应的一个质量判据。我们还是把这个维度质量回到我们这个订单日报的这样一个案例当中，大家可以看这个图中间，其实它大概会经历，比如说从定位到诊断，到确认变更。跟到发布的一个校验，以及到发布和重跑，最终到验证产出。

其实这个过程当中从定位的时候可能会遇到比如说同名的任务？那这个时候呢，应该是得到澄清以后，然后再继续往下走。那在诊断的时候可能会遇到，比如说我们上游的依赖的一些节点，一些这种任务，其实它没有就绪，这个时候我们应该是做一些有限的等待和重试。没问题以后才往下继续走，那么对于这个开发校验也一样的，我们如果是发现有问题，应该是支持返回修改，而不是说跳过这个发布的一个整个的校验，我们去做一个发布。发布重跑了也一样的，那么我们应该是发布重跑报错以后，应该是要支持按条件回退，或者是交给人工处理。

大家可以看到这个路径当中，我们除了成功的路径、正常的路径，其实还有分支，包括错误的路径。所以说，我们在画这个skill的覆盖路径的同时，我们应该要有成功的路径，也要把错误的路径以及回退的路径画清楚。

讲完前面的路径覆盖以后，那我们怎么去验证，接下来就给大家讲一下我们的质量判据，可以看到我们比如说在定位的时候这个对象，是不是这个出问题的这个任务？那这个时候我们要做一些对象的匹配，在发布的时候我们要去校验这个权限是不是OK的，是不是在我们的授权范围内？到宣布恢复的时候，我们要去看具体的这个数据的日期以及对应产出的这个日报是不是符合业务的要求？

刚刚其实我们是讲完了对应的我们的路径，那么大家可能会想那具体这些东西如何是落到测试用例上，因为测试逃不掉的就是测试用例，接下来我给大家分享这个测试用例的一个构建。我认为一个完整的测试用例应该是说它应该是能够确保你这个路径是触发的，而且你的执行的过程和对应的结果是能够支持被检查的。

所以可以看到，其实我们的用例主要是来源于四个方面。

第一个是对应的业务场景，这个地方其实它是给出我们的目标和验收的条件。

第二个就是我们所有的规范，它其实是给出对应的这个操作和授权边界。

第三个已有的用例，能够识别出我们还有哪些测试的缺口，并且做一些补齐。

线上工单，它是提供一些问题描述，以及提供一些复现的线索。有了这些物料以后，那么我们构建测试用例主要是有四个步骤：

第一个是说我们要选择对应的目标路径，比如说我们这个用例到底是成功路径还是回退路径还是错误路径？

第二个我们要基于这个路径构造出我们触发的条件，它在什么时候会被触发？

第三个就是我们要定义这个输出和约束，它到底是输出哪一天的日报，它的约束有哪些？它的权限线管控有哪些？

然后最后一步就是我们做执行验证并且入库。

以下面这个用例来讲，任务显示的成功，但是今天的日报没有生成，其实这种本质是我们测这个skill它是有问题没有恢复，但不能虚报说已经恢复了，可以看到这个整个用例里边它会有六个要素，它有输入和环境的前置条件。包括预期的一个输出，以及目标路径和终态，还有就是断言和禁止项。有了这个六要素以后，那么我们对于测试用例做一个入库的验收，确保每一个用例它是可执行的，而且能够触发并且可判定、可复现，这样的话我们才能够进入我们的一个回归集。

讲完测试用例以后，其实我们还要去验证一组用例它的一个充分性是怎么样的？测试用例的充分性本质是识别出来我们覆盖的一个缺口并且指导我们补测和验证。

然后测试用例的这个充分性里边主要是有几个方面，第一个是说，首先我们要找出分母，我们要明确这个要测的行为。那么我们会从 skill的这个主文件以及引用文件，还有就是脚本当中我们去提取出这些行为清单，并且按照用例的要求我们去补齐，比如说触发条件，比如说预期结果这些。那么拿到这些以后呢，我们再拿到我们现在库里边的已有的这个用例去逐项去比对，这样就是能够找出我们的测试的一些缺口，并且做一些补齐。这个方法STA，它是我们测试充分性评估的一个方法。它的分子其实就是我们当前已覆盖的这个行为数。然后分母是我们已经确认的需要测试的一个行为的总数，它是来表达我们整个测试用例的充分性，当然它是不能代表我们这个测试的一个通过率的，这是两个事情。这个方法我们也以论文的形式对外公开了，因为今天的时间关系，我可能不会给大家详细去展开。如果大家有兴趣的话可以去搜索下面这个各个相关的论文，然后做进一步的一个了解。质量判据，就前面我们讲了路径和充分性，其实这个能够回答我们测了多少？那么其实我们还有很重要一块就是回答我们到底测对了多少。

所以说质量判据的话，我们是做这样的一个东西，以证据判定、指导后面的改进。然后它主要是包含三个方面：

一个是说我们的检查的一个规则，它需要有一个必须要明确适用的条件，包括执行的证据以及对应的通过的标准是什么。包括我们拿日报恢复就这个例子来讲，其实它的对象的话，那在写操作之前你的这个对象，你所定位的这个对象是不是匹配的？那么在变更受控呢，那它其实是在发生这个变更的时候，那你是不是在我们授权的一个范围内的，有没有做一些越界？然后在这个恢复有效的话其实我们是发生在宣布恢复前，这个时候是确保我们的日报预期包括产物是正确的。

第二个方面是我们的判定方式，当前比如说对于这些状态、字段、顺序、阈值这些我们是采用确定性的规则来去检测，那么对于一些涉及到要语义理解的，我们以大模型去做一个辅助的确认，然后人工的标注和校验。

第三部分结论和动作呢这个相对就比较简单一点，如果符合标准就通过，如果违反要求了，那么它是不通过的。这里边有两个关键点，第一个是说如果是安全红线我们应该是独立的阻断。第二个就是如果证据不足的时候，我们不能判定通过，应该要判为不通过。前面我们回答了就是到底我们测了哪些，以及测对了哪些。

其实随着这个skill本身版本的迭代更新以及环境的变化，我们必须还要有一套自动的回归机制来保证持续的一个质量。这里边主要分为两个方面来讲：

第一个是说我们对应的一个变更的触发，它是检测skill本身版本的变化以及工具和模型发生变化以后带来的改变。

第二个就是定时调度，这一块是说我们去检测对应的依赖、权限、环境和数据，它的一些漂移，也就是即使这个skill本身它没有发生变化，但是它的环境发生变化，那么昨天能够跑通的任务今天有可能也会失败。考虑到我们动态调用的遗漏，我们还需要全周期的这种全量的回归来保证持续可靠性，这里边可重入执行保障主要是两个方面，一个是环境的可重入，还有一个是human in the loop的可重入。

我举一个例子，对于环境可重入来讲，比如说我们依然是拿这个订单日报这个例子来讲，如果第一轮测试它实际上已经产出了这个产物？如果我们不做一些清理做一些重置的话，其实它会带入第二轮的一个测试里边，会带来一些干扰，所以我们必须要保证环境的可重入。然后human in the loop的一个可重入的，那我们就拿这个，比如说我们今天这个订单日报发生变更，用户拒绝这个用例来讲，那么如果我们第一次执行，可能如果残留了这些审批或者是拒绝的这些节点的话，其实是会对结果造成干扰。我们应该让这个交互节点回到最开始的时候，然后再按照用例的要求往下去确认执行。然后执行完以后自动化回归呢，我们再和整个的五维的指标的基线去做一些比对，再提供整个skill的质量门禁。前面我以这些例子给大家分享了，比如说我们测试的围绕这个skill质量的一些测试，包括路径、包括质量判据、包括自动回归这些。

其实大家应该能够感受到这个可靠的skill肯定是非常重要的，它是agent的一个非常重要的一个单元。当然对于多skill的一些冲突，以及它对应的如何协作，本身这个agent自己动态一些从规划的时候，它可能会涉及到其他额外的一些边界，包括其他结果的一些保障和确认。

所以说， Agent本身的质量也是需要我们有一套完备的机制来保障。那么下面有请我的同事刘群给大家带来Agent的评测相关的分享。

大家好，我是刘群。我分享的主题是OpenAgent在真实云管理场景下的评测体系和工程实践。大家都在搞agent，agent在真的落地生产的时候，都必须先回答一个问题，那就是怎么证明你的agent是真的可用的、安全的，客户能够放心地把自己的业务交给它。这个问题呢，靠几个精心挑选的样例是回答不了的，需要的是一套系统化的评测。那么我分享的就是我们在OpenAgent上的一些评测经验。

刚才我的同事详细介绍了 skills 的评测建设的经验。实际上，Agent 肯定不止于一个模型、一套skills，它还包括了系统提示词、工具、知识库，还有运行环境，比如沙箱，还有它的编排模式，workflow、React，甚至还有多个agent的协作，所有这些都会直接影响agent的最终效果和质量。而且这个Agent是一个整体，每个组件看起来没问题，当它组合在一起的时候，就有可能在真实业务中跑不通，而且agent在执行过程中的错误会复合、会放大。

所以要真实地掌握agent的质量，需要的是什么？需要是端到端的评测。必须把agent放到真实业务中去，让它无完整地跑起来，这样才能真实全面地掌握agent的质量和效率，这样才能帮我们发现问题所在，给我们的Agent提供洞察，并且让它持续迭代。

做评测第一件事情是要明确评测的目标。要明确评测目标，先要对我们评测对象，也就是我们的agent，它的问题域和业务目标做全面的分析。我们构建的不是一个开放通用的评测基准，而是面向OpenAgent专用的评测体系。简单介绍一下OpenAgent，刚才也提到了，OpenAgent是阿里云推出的用于智能云管理的一个Agent的产品。那么云管理这个业务有什么特点呢？它有四个鲜明的特点：

第一，业务目标明确，就是用户在云管理的过程中，他的任务目标是很明确的，比如创建个数据库、排查一个故障等等，能够客观地验证和衡量。

第二个，云管理业务往往比较复杂，资源多、操作步骤也多，资源之间的依赖关系也很多。

第三个特点是环境动态。那么云环境它的资源在增减，状态在变化，所以它不是一个静态的快照。

最后一个呢是安全性要求很高，因为客户把自己的业务放在云上，你就必须做好安全的保障，比如有租户隔离、权限隔离、高危操作保护等等。那么基于云管理业务的这些特点，我们就可以定出我们评测的目标是什么。

我们OpenAgent的评测目标也定了四个：

第一个是真实环境中运行，我们把agent和Agent所触发的云管操作都放到真实的环境中去，让结果可验证，不做mock。

第二个是多场景覆盖，我们需要有丰富且分布合理的用例，然后做到多层次、多类别的覆盖。

还有一个呢，这也是最重要的一个，就多维度评估，既看结果也看过程，为Agent提供四个方面包括效果、效率、成本、安全方面的洞察。

最后一个是评测驱动开发，要把我们的评测纳入到Agent开发的CI/CD流程中去，让评测与发布的质量挂钩。

先看一下我们用例集的设计，因为这个也很重要。为了达到用例丰富和分布合理这个要求，我们先从场景分类开始设计，就是我们的这个agent它会面向哪些场景。我们不仅要覆盖各种云服务的核心功能，也要覆盖跨账号、跨产品的复杂场景。还有特别是安全方面的场景也要覆盖。

我们有了这些场景范围之后，我们就好定我们的用例范围了，我们从四个来源收集用例：第一个是线上工单，占百分之六十，这是客户真实的问题，价值最高。30%是由我们的业务领域专家构造，还有百分之五基于知识库生成，还有百分之五的专门的对抗样本，用于安全测试。这些初始的用例数据，需要经过一条带版本管理的入库流程才能转换为正式的用例，包括了脱敏、提取事实和目标API，然后做可行性验证，最后经过人工review，最终入库并更新版本，这是一套带版本化的流程。用例多了，因为用例其实是很好造的。

但是用例多了之后呢，就有一个问题，需要对对它们的优先级进行分级。我们这边参考的是FMEA的风险优先级的分类方法，由发生概率、严重程度加上检测难度三个维度来对用例进行分级。发生概率就是这个用例场景在客户侧真实出现的频率，比如说他每天都要运维操作的一些任务，那优先级肯定最高。还有一个是严重程度，就是这个任务涉及到了资源变更，它能造成的影响程度和工单等级，比如删除操作，它的这个等级就比较高。还有一个是检测难度。就是发生错误的时候，它被检查出来的难度。基于这三者相乘呢，我们把用例划分出了 P0、P1、P2三个等级。把各个场景的P0级别的用例组合在一起，就构成了我们的黄金用例集。这个黄金用例集非常重要，用于我们的线上回归和发布门禁。我们还特别地构建了一套heldout保留集，用于黑盒评测，它是不公开的用例集，避免我们的agent针对用例集做过拟合的优化。

来看一个具体的用例示例。我们使用一套有确定schema的json格式来表达一个用例，比如说这个，这是帮我在杭州创建一台PostgreSQL数据库。还有按量付费、规格选最便宜等要求。这是一个明确的用例输入，客户在线上确实也会问这样的问题、给这样的任务。定义用例的输入，还要定义它允许调用的API范围和不允许调用的API范围这些约束，因为创建数据库是付费操作，所以在用例中还强调了应该要唤起human-in-the-loop确认。

然后我们的定义中还支持定一些脚本函数来对用例执行过程中和最终结果做确定性的校验。值得一提就是用例跑着跑着其实也会跑飞，会失控，所以我们还要特别地去约束 Judge LLM 的运行限制，它的最大轮数、最大的工具调用次数，还有超时时间等等。正是因为有了这一套形式化的确定性的结构，让我们的用例成为了这个机器可运行、可验证的评测资产。这个资产很重要，它是后面自动化评测的基础。

有了用例之后，我们来看一下怎么评。评之前呢，我先强调一个关键点，先观测后评测。没有足够的可观测数据，是没有办法做评价的。我们的OpenAgent用的是阿里云的AgentLoop这个可观测服务，可观测服务完整地记录了我们的trace 数据。如果同学们对可观测服务感兴趣的话，本届云栖大会也有专门的主题分享，这里就不展开了。

有了观测数据之后，我们主要看agent行为结果的六个方面，就是六个维度：

第一个是安全合规，这是最重要的，它是红线，一旦违反一票否决直接零分。安全合规方面呢，我们主要看它在用例跑完之后，在trace中是不是出现了刚才不允许的调用，有没有暴露一些敏感信息？还有这个该唤起人工确认的时候有没有唤起人工确认，这些都要做到检查。还有一些我们用Judge LLM做的一些策略判定，这是安全合规。

第二个是任务完成度，这个检查的是agent的回复跟用户意图之间的匹配程度。我们看的是关键词召回，还有Judge LLM的判断。当然这个Agent的回复有时候看起来是正确的，但可能什么都没干，只是幻觉出了一个恰巧的回复，这个肯定是不够的，所以还得看它的忠实度。

忠实度我们是怎么计算的呢？我们用judge LLM把Agent的回复拆分成一条条的独立声明，然后再把这些声明去工具调用结果中去找证据支撑，有支撑的就算一个，所以看这个比例来得到它的忠实度评分。

第四个是看事实一致性，这个看的是执行过程中是不是调用的是我们允许的API，以及它的调用参数，是不是符合我们的预期，还有事实一致性，事实一致性指的是这个任务结束之后是不是真的发生了实际的效果，资源创建出来了没有，状态是不是符合预期的？

最后一个是效率成本，这个就很简单了，主要包括端到端的延迟，还有对话轮数、token消耗这些成本和效率方面的指标。

除了安全合规是一票否决，就是零分的话，其他的维度，我们会计算出一个一百分制的得分，然后在各个维度再加权算一个总分出来，这样一种直观的方式来反映我们agent的水平。

好，刚才这些方法讲的有点抽象，我们具体看一下一个用例跑完之后我们能看到什么？拿刚才创建数据库的例子，跑完之后我们能看到什么呢？

第一，可以看到它任务完成度一百分，很优秀。可以看到它用了九轮对话，产出回复是完全匹配的，关键词也完全命中。忠实度九十五分，提示我们找到了两条无支撑的声明。agent的回复中提到这个规格是最小规格，但是在我们评测中发现这个描述在工具调用结果中得不到支撑，所以就扣分了。这种声明级校验的价值就是能够把这种隐蔽的幻觉给挖出来。这是忠实度，还有事实一致性，它得了满分，因为经过实例回查，发现这个资源确实创建出来了，规格也是符合预期的。结果、幻觉检测加上这个真实状态，三者相互印证，共同回答的一个问题就是这个agent到底把事办完了没有？从示例结果来看呢，这事儿确实办完了，还不错。但是过程规不规范、代价高不高，我们就需要看报告的下半部分，来看一下过程和约束维度。

第一个过程正确性也得到满分，不错。从这个评估报告里可以看到，它调用的 API 是符合我们预期的一个 API，然后它的调用次序也清晰可查，参数也完全匹配，执行路径是正确的。安全合规也不错，得到了一百分，因为这个CreateDBInstance是高危操作，需要唤起human-in-the-loop确认，这里成功唤起了，而且全程没有暴露敏感信息，安全红线没有违反。最后是效率成本。可以看到，它有一项没通过，是 token 消耗过大，超出了我们设定的阈值。下面还有看到它的工具调用明细里面写到有七次同参重复的工具调用，那这个就有可能是原因之一。可以看到好的结果未必有好的过程。一个好的评测，不能仅仅给出一个通过还是不通过的结论，还必须提供可验证、可行动的改进线索，让我们的Agent能持续改进。

最后一点呢，我们经过刚才的方法之后把评测给评出来了，但是呢，还要把评测这个能力用得起来。

我们主要把评测用在两个方面：

第一个是横向评测。我们引入了一些通用的agent，加上阿里云的工具包，作为横向评测的目标。可以通过横向评测，看到我们的OpenAgent相对于这些目标来说，在云管理业务中确实有独特的优势。我们还支持快速切换不同的模型来做评测，这样能让我们的agent更好地平衡这个效果和成本。另外，横向评测的结果区分度也会直接影响我们评测的用例集和评测方法的优化，因为一个没有区分度的评测不是好评测。

第二个也是很重要的，就是我们把评测，刚才反复强调了，把它纳入了Agent开发的CI/CD流程，变成一个持续的自动化评测。我们目前呢沉淀了七十多个用例集，超过一千个用例，覆盖了十大场景，每天能跑一百二十多轮测试。并且在发布的时候，我们要求黄金用例集必须全部pass，并且综合总分不能低于线上回归的七日平均值，才允许发布。这样作为一个发布门禁，保证我们agent每次迭代发布质量。

好的，这些就是我今天分享的内容，Agent从能力验证到可信交付，必不可少的路径还是强调一下，就是评测。

希望今天我的分享能给大家带来一些参考，谢谢大家。