Metric Design 是一个面向评估指标设计的技能，帮助用户把已有的评估原则或数据集转化为可运行的评分管道。
用途
当用户已有评估维度或原则，但不确定该用哪种评分器类型；或需要为特定失败模式编写 LLM-as-judge 提示词；或需要组合多个维度得到综合分；或希望从标注数据自动生成评分器而非手工编写；或现有评估全部依赖 LLM 导致成本高、速度慢时，可启用该技能。
主要能力
1. 按维度选择评分器类型
技能提供一棵按优先级匹配的决策树：
- 能用确定性规则检查的，使用 StringMatchGrader、JsonValidatorGrader 或 FunctionGrader（零成本、结果一致），例如分类标签精确匹配、格式正则、JSON 结构校验、关键词有无。
- 需要语义理解文本质量的，使用内置 LLMGrader，例如 CorrectnessGrader、RelevanceGrader、HallucinationGrader。
- 涉及智能体行为（工具调用、规划、记忆）的，使用专用 LLMGrader，例如 ToolSelectionGrader、TrajectoryAccuracyGrader、MemoryAccuracyGrader。
- 涉及代码执行或语法的，使用 CodeExecutionGrader 或 SyntaxCheckGrader。
- 需要调用外部工具核验的，使用 AgenticGrader（成本高，仅在必要时使用）。 技能同时给出按输出类型推荐评分器的速查表，并强调优先穷尽确定性方案，因为每个 LLM 评分器都会带来成本、延迟和不确定性。
2. 创建自定义评分器
技能规定每个评委提示词必须包含四个组件：任务与标准（只评一件事）、二元通过/失败定义（具体可观察，不用 Likert 量表）、少样本示例（至少 1 个通过、1 个失败、1 个边界案例）、结构化输出（先写 critique 再给 result，以减少先下结论再倒推理由的偏差）。同时给出 FunctionGrader 编写确定性检查的代码示例。
3. 冷启动自动生成评分器
没有评分细则但已有任务描述或标注数据时，可使用 SimpleRubricsGenerator（零样本，基于任务描述与示例查询）或 IterativeRubricsGenerator（数据驱动，适合 20 条以上带标签的 query/response/score 样本）自动生成可直接使用的 LLMGrader。
4. 反模式扫描
在最终确定前检查每个 LLM 评分器：Likert 量表、缺少少样本示例、整体性标准（一个评委评 3 个以上维度）、缺少输出格式、含糊的通过/失败定义、评委模型与被评模型相同。技能对其中多项标记为阻断级问题，并说明原因。
5. 构建管道代码
技能建议先把设计记录为可复用的 metric-plan.yaml，再用 GradingRunner 组装各评分器，用 WeightedSumAggregator 做加权聚合，并支持并发运行。对于安全、合规、PII 等不可妥协的要求，技能主张使用门控而非加权求和，因为加权求和会让其他维度的高分掩盖违规；由于 OpenJudge 只自带 WeightedSumAggregator，技能给出了一个小的门控聚合器实现示例（资料中该代码末尾被截断）。技能还给出权重设计原则：权重应反映失败出现频率、业务影响，并区分门控与评分。
使用方式
需先安装 OpenJudge（pip install py-openjudge）。评分器选择、GradingRunner 和聚合器都是 OpenJudge API；如果使用其他框架，设计思路仍适用，但代码不适用。资料包含完整的 LLMGrader、FunctionGrader、两种生成器以及 GradingRunner 的代码示例，其中评委模型通过 OpenAIChatModel 配置，可指向任意 OpenAI 兼容端点。
适用场景
适用于构建 LLM 应用或智能体的评估体系：为客服问答、事实性回答、工具调用、代码生成等维度选择评分器，编写二元评委提示词，从标注数据冷启动评分器，以及把多个维度组装成带权重和门控的评分管道。
限制
该技能的代码示例依赖 OpenJudge SDK；门控聚合器需要自行实现；自动生成评分器需要任务描述或足够的标注样本；AgenticGrader 成本较高。具体收费、价格与平台支持情况资料暂未提供。