如何评估一个 Skill 的质量？有哪些可量化的指标？
“评估 Skill 质量，我反对只看‘跑没跑通’。我把质量拆成五个维度，每个维度都有一组可自动采集的量化指标，最后综合成一个质量分，类似信用评分那样。这五个维度是：功能正确性、性能效率、稳定韧性、安全合规、用户价值。
下面我逐个说每个维度具体看哪些数据。
一、功能正确性 —— 它到底干对了没有
这是底线。我不只看单次成功，而是看长周期内的统计。核心指标：
-
成功率：成功执行次数 / 总调用次数。这里的成功不是不抛异常，而是输出通过了我预先定义的断言校验（比如返回的 Schema 符合声明、金额字段不为负数）。成功率的及格线通常是 99.5% 以上。
-
参数兼容通过率：在沙箱里用一批历史真实请求和变异参数（模糊测试）回放，看 Skill 是否会给出错误响应或崩溃。
-
业务逻辑校验通过率：有些正确性必须人工或 LLM 评判，比如“穿衣建议是否合理”。可以定期抽样，用强模型打分，得到一致性比率。
二、性能效率 —— 它跑得快且省资源
这个维度直接决定用户体验和成本。可量化的指标：
-
平均响应时间 和 P95/P99 延迟：区分异步与同步 Skill。同步 Skill 的 P95 延迟必须低于声明的
timeout_ms阈值。如果 P99 延迟超过 3 倍中位数，通常意味着有长尾阻塞。 -
首次响应时间（TTFX）：对于流式返回的 Skill，第一个 token 或第一条数据吐出来的时间，用户感知极强，一般要求 < 800ms。
-
吞吐量（QPS）：在标准沙箱配置下，每秒能处理的最大调用数。这个用来做容量规划。
-
资源效率：每次调用的平均 CPU 时间、内存峰值。如果两个 Skill 功能一样，但 A 消耗的内存是 B 的 5 倍，那 A 就要扣分。
三、稳定与韧性 —— 出错时能不能扛住
这是区分高质量和低质量 Skill 的分水岭。
-
错误率：这里的“错误”包括超时、外部依赖挂掉、自身逻辑异常。要拆开看，不能混在一起。错误率 = 错误次数 / 总调用次数。通常要求 < 1%。
-
熔断触发次数：如果调用下游不稳定，导致这个 Skill 的熔断器频繁打开，说明它的依赖治理有问题。
-
重试成功率：当 Skill 自动重试时，重试最终成功的比例。如果重试成功率很低，说明重试策略设置不当，只是浪费资源。
-
超时率：超过声明 SLA 的次数占比。超时率高的 Skill 会被降级或降低路由权重。
四、安全合规 —— 它会不会闯祸
这个维度更偏审计，但同样可量化。
-
权限声明合规率：实际调用中，是否有越权访问被能力网关拦截的记录。一次拦截就是一次扣分。
-
输入输出校验违规次数：Skill 是否输出了不符合 Schema 的数据（比如偷偷增加字段），或者接收了未声明的参数，这可能是被注入攻击的迹象。
-
敏感数据泄露检测：通过日志脱敏后，是否还能检测到有生数据（如手机号）被输出。用正则扫描输出日志，命中率应为零。
-
依赖包漏洞等级：扫描 Skill 包引用的库，存在高危 CVE 的直接不合格，中危的扣分。
五、用户价值与体验 —— 是不是真的有人用、好用
这是业务视角，防止开发者自嗨。
-
调用量 / 活跃用户数：过去 30 天被多少不同的用户或 Agent 实例调用过。零调用的 Skill 会标记为“僵尸”，考虑下架。
-
复用率：被多少个其他 Skill 或编排流程依赖。复用率越高，说明这个 Skill 作为基础能力越成功。
-
用户满意度评分：如果用户执行后可以反馈（点赞/踩），看满意度。踩超过一定比例触发重审。
-
任务完成率：该 Skill 所在的复杂任务（比如出行安排），用户最终完成整个流程的比例。如果订酒店 Skill 经常导致用户放弃，说明它的体验可能不好（比如参数澄清太啰嗦）。
-
平均交互轮次：Skill 为了完成任务需要和用户澄清多少次。轮次越少通常体验越好，但这不是绝对值，关键任务可以接受多一次确认。
综合质量分与雷达图¶
我会把上面五个维度，每个维度加权后算出综合质量分（0-100）。权重可以根据 Skill 类型调整：
-
核心交易类 Skill：正确性 40%、安全 30%、稳定 15%、性能 10%、体验 5%。
-
轻量查询类 Skill：性能 30%、体验 30%、正确性 20%、稳定 15%、安全 5%。
-
内部工具 Skill：正确性 30%、稳定 30%、体验 15%、性能 15%、安全 10%。
在管理后台，我用一张雷达图展示每个 Skill 的五个维度分数，一眼就能看出短板：比如某个 Skill 功能正确性 98 分，但稳定性只有 60 分，说明它经常超时或依赖外部服务容易挂，需要重点治理。