如何离线评测 Skill 的效果，并预估上线指标变化？

核心回答

Skill 的离线评测要拆成两件事：该用时能否被正确选择，以及加载后能否把任务做好。准备覆盖真实任务、相近但不适用请求和异常输入的样本，在固定模型、工具、环境与预算下，对比旧版、新版以及必要的无 Skill 基线，分别检查触发、执行、最终结果和成本。

上线指标要再做一层映射。例如转人工率不仅受回答正确率影响，还取决于任务分布、权限、业务兜底规则和用户行为。可以按线上场景占比，对离线回放得到的各类转人工比例加权，给出有前提的变化估计；再用小范围真实流量验证。离线成功率提高，不能直接推成线上转人工率下降相同幅度。

样本与评分怎样构造

以故障诊断 Skill 为参考场景，每个 Case 保存请求、必要日志或知识快照、可用工具和权限、预期诊断证据，以及允许的结束方式。标准结果应由已确认的故障事实和领域人员核对，不能只用另一个模型生成的诊断作为真值。

样本需要包括正常可解决、信息不全需补问、工具失败、超出权限或确实需要人工接手的任务，也要有相似措辞但不应调用此 Skill 的反例。按故障来源、业务类型和难度分组，避免同一次故障改写后同时进入开发集和留出集。专门收集的困难样本适合诊断缺陷，估计线上总体指标时还要按真实流量分布校正。

评分可分三层：

• 触发层：应触发样本中实际触发的比例，以及不应触发样本中的误触发比例。显式点名 Skill 只能检验一部分情况，还要测试真实用户的隐含表达和与其他 Skill 的竞争。
• 执行层：是否读取必要材料、使用正确工具和参数、遵守必要业务约束，缺参或工具失败时是否正确补问、恢复或转人工。只固定不可省略的关键动作，不强求所有合法路径完全一致。
• 结果层：诊断结论是否由证据支持、最终产物或状态是否符合要求，以及是否出现越权或错误副作用。脚本成功退出、工具返回成功和模型自述完成，都不能单独替代结果验收。

同时记录耗时、模型与工具调用、token、重试和人工核验时间。正确转人工可以是符合业务要求的结果，因此还需单独统计自动解决率、该转未转和不必要转人工，避免只追求更低的转人工率。

如何隔离 Skill 修改的影响

第一组测试可以显式加载 Skill，检查专业流程本身是否有效；第二组让宿主自然选择，检查实际端到端收益。若第一组表现好、第二组漏用较多，优先检查描述、发现与加载；若两组都失败，则继续定位流程、工具依赖或模型能力。

新旧版本使用同一批输入、相同环境初始状态、模型、工具和评分器，只改变待研究的 Skill。比较时保留逐题结果与轨迹，对随机性明显的任务重复运行，观察改善和退化分布。必要时与无 Skill 或已有工作流比较，确认效果来自 Skill 的方法和资源，而非增加了模型调用预算或恰好更换了模型。

用规则验证参数、结构和状态；需要理解诊断语义时使用经过校准的模型裁判或领域人员复核。让裁判不知道输出属于哪个版本，可以减少版本偏好。新增失败案例进入开发回归集，但用于最终检查的留出数据仍要保持独立。

怎样预估上线转人工率

先固定分母与转人工口径：是全部进入系统的会话，还是仅限该 Skill 适用的请求？同一会话多次请求怎样计数？人工接手、模型主动升级、用户主动要求人工，是否分别统计？这些定义要和线上埋点一致。

然后按场景 s 的线上占比 pₛ，以及版本 v 在该场景离线回放中的转人工比例 hᵥ,ₛ，计算条件估计：Hᵥ ≈ Σₛ pₛ × hᵥ,ₛ。这里的 h 应按同一套业务规则得到，不是直接取“1−模型准确率”。对需要交互的任务，还要考虑补问与恢复过程；只回放最后一条问题无法完整模拟用户是否继续配合。

例如下面是教学算例：假设线上简单任务占 70%、复杂任务占 30%；旧版两类转人工比例分别为 20%、60%，新版为 10%、50%。加权后旧版约为 0.7×0.2 + 0.3×0.6 = 32%，新版约为 0.7×0.1 + 0.3×0.5 = 22%，预估下降 10 个百分点。这只在任务占比和转人工规则等假设成立时有效，不是实际项目成绩。

如果评测集只包含可自动处理的故障，而线上还存在大量权限不足、业务指定人工和工具不可用的会话，就需要把这些场景加入权重，或明确估计仅覆盖其中一部分。还应报告样本量和估计波动，并检查流量结构变化时结论是否稳定；少量回放全部通过不代表线上会全部成功。

上线前可先用影子回放检查真实输入下的路由、工具依赖和结果分布；需要交互或写操作的链路，使用可控环境验证。影子结果能发现偏差，却不等于已经观察到真实用户的后续反应。随后在合适的会话或用户单位上比较版本，联合查看转人工、正确解决、漏转与成本，校准离线估计。

怎样控制评测成本，并决定改哪里

先用便宜的检查排除 Skill 资源缺失、脚本错误、输出格式和明显路由问题；再用固定工具反馈评测诊断方法；最后选有代表性和高风险任务做完整链路验证。Mock 能降低成本、帮助定位，但不能证明真实权限、网络和工具执行都可靠。

根据失败层改动：漏触发改描述与发现条件，执行偏离改步骤或资源组织，工具错误改接口与恢复，结论无依据改证据获取和评分标准。每次保留受影响场景和必要回归，避免为解决一种故障把 Skill 描述扩得过宽、导致其他任务误触发。模型或宿主变化后，重新检查其增益；原来有用的技巧可能不再需要，而团队特定的流程约定仍可能值得保留。

常见追问

离线评测分数很高，但线上没有收益，先查什么？

先对齐流量分布、Skill 是否真正触发、模型与工具版本、权限和转人工口径。再看离线是否只测显式调用或理想工具反馈，是否遗漏用户中断、信息不全和环境失败。最后逐条对照线上失败和离线样本，补足差异。

只看调用了哪些工具，能判断 Skill 按预期运行吗？

工具与参数检查只能验证部分过程。故障诊断还需确认取到的证据足够、推断与证据一致，并能排除主要替代原因；如果最终结论错误，工具链看似完整也不能算任务成功。

对应教程

参考资料