到底变了什么？
区分任务行为变化与 prompt、rubric、数据和评分尺度变化。
探索中
如何证明 evaluator 真的改进了，而不是发生漂移？
EvalScope 会保留评测输入、评审和结果之间的关联。本页进一步探索：当 Evaluator 更新后，怎样确认它真的更好，而不只是数据、提示词或评分规则变了。
每次 Evaluator 变更都该回答的三个问题
谁在判断？
审计 Judge 一致性与失败模式，而不是把分数当成神谕。
这次选择还可靠吗？
若更新改变了排名或推荐，量化这次变化带来的选择代价。
一条可复现的验证路径
如何验证一次 Evaluator 变更。
冻结基线、一次只引入一个受控变化、在保留任务上验证、审查证据，并连同产物记录决策。保留原始输出和明确结论，才能让每一次看似改进都可被复核。
01
冻结基线
任务、环境与原始产物。
02
构造变体
一次只引入一个受控变化。
03
验证保留任务
保留任务与已声明指标。
04
审查证据
先审查证据，再接受分数。
05
记录决策
保留选择及其理由。
哪些现有能力支撑这项工作。
标签明确区分当前可用能力、外部研究证据与尚在探索的方向。
EvalScope 已具备
版本化 benchmark metadata、结构化 Judge 契约、输出产物、本地报告与 API-first 评测工作流。
研究方向
自我演进 Harness 的评测、Evaluator 漂移护栏与选择遗憾协议。这些是研究方向，不是产品承诺。
可追溯的 Agent 记录
将请求、工具调用和结果与任务结果一同保留。
版本化 Benchmark 目录
跨模态浏览 benchmark metadata 与评测版本。
关联的运行产物
报告、预测、review 与配置保持关联。