归一化分只在配了范围时才有：阿里云把评估结果拆进 evaluation_detail

归一化分只在配了范围时才有：阿里云把评估结果拆进 evaluation_detail

AgentLoop 是阿里云的 Agent 观测与优化产品。文档《评估结果字段说明》的页面日期是 2026 年 8 月 31 日。评估任务跑完后，每个评估器的结果写成一条日志，落到该 AgentSpace 对应 SLS Project 里的 evaluation_detail Logstore。这篇只解释这些字段的含义和类型，没有给出任何准确率或通过线。

任务、运行、评估器、结果是四层

文档先把四个名词分开：

• 评估任务（Task）是用户创建的一次评估配置，里面有数据源、评估器和调度策略。
• 运行（Run）是这次任务的一次实际执行，可以手点，也可以在持续评估窗口里自动调度。
• 评估器（Evaluator）是打分或判定的单元。一个任务可以挂多个评估器，每个评估器单独写一条结果日志。
• 评估结果（Evaluation Result）是单个评估器对单条数据的打分、判定和解释，对应 evaluation_detail 里的一条日志。

所以一条数据配三个评估器，日志是三条，不是把三个分数塞进同一行。

每条日志都有的公共字段

这些字段每条都有。timestamp 是结果产生时间，毫秒时间戳。task_id 是任务 ID。eval_id 是这一条结果的唯一 ID。eval_base_id 是评估数据 ID，用来把评估队列和结果记录串起来。run_id 是本次运行 ID。window_id 是持续评估窗口 ID，只有持续评估模式才有值。另外还有 user_id、region_id、agentSpace。

status 只有三种写法：success、failed、unknown。失败原因不在这个字段里，要到后面的错误字段去看。

任务模式和运行类型是两套枚举

任务和运行上下文单独一组。task_mode 取值是 batch（批量）、oneshot（单次）、stream（流式）。run_type 取值是 backfill（回填）和 continuous（持续）。channel 标明任务从哪来：default、experiment，或 AgentRun（由 Agent 运行触发）。

data_start_time 和 data_end_time 是这次运行的数据范围，毫秒时间戳。eval_latency 是从运行创建到结果产出的端到端耗时，单位毫秒。它不是单个评估器自己的耗时，那个数在后面的度量字段里。

分数、二值和文本是三种结果

评估结果这一组记单个评估器打了什么。名称有 evaluator_name 和 evaluator_display_name。score_name 标识这个评估器产出的指标项。score_value 是原始分数，类型 double。

normalized_score_value 是 0 到 1 的归一化分数，文档写明只有评估器配置了分数范围时才有值。score_range 是原始范围，格式写成 [min,max]。没配范围就不要假设平台已经把分收成 0 到 1。

result_type 三选一：score 是数值打分，binary 是二值判定，text 是文本。解释分两层：explanation 给用户看，evaluation_process 写分数和说明是怎么推出来的。trajectory_summary 是 Session 逐轮轨迹摘要，只有相关评估结果才会写入，不是每条都有。

失败才写错误码

状态是 failed 时，才用 error_code 和 error_message 记失败原因。成功的日志不要到这两列里找解释。

关联字段把结果指回原始数据

data_link 是 JSON，用来追溯这条结果对应的原始数据。里面可以有数据集 ID 和条目 ID（dataset_id、dataset_item_id），被评估数据的 trace_id、span_id、session_id，以及实验、应用、Agent 名称。

data_scope 标明粒度，取值是 span、trace、session、log、dataset。时间范围用 start_time 和 end_time，类型是 text，和前面运行级的毫秒时间戳不是同一套字段。

实验侧还有 experiment_id、plan_id、plan_name、experiment_group_name、record_id、record_name、run_env。日志侧有 SLS 的 project、logstore 和 logstore_item_id。一条结果到底能填满哪些键，取决于数据从数据集、链路还是日志来，文档没有说缺字段会报错。

评估器自己的调用也单独记账

eval_meta 记评估器执行时的调用信息：model_name、evaluator_request_id、evaluator_log_id、evaluator_thread_id。evaluator_trace_id 是评估器自己这次执行的 Trace，不是被评估数据的 trace_id。两边混用就会把裁判的链路当成被测 Agent 的链路。

eval_metrics 记这次评估器花了多少：input_tokens、output_tokens、total_tokens，以及 latency。这里的耗时是单个评估器的执行耗时，单位仍是毫秒。

送进去的变量和额外输出没有固定表

eval_info 记实际送进评估器的变量。Key 对应评估器 variableMapping 里定义的变量名，Value 是当时的取值。文档的例子把 input 映射到 question、expected 映射到 label，于是 eval_info 里出现的是 input 和 expected 这两个键，值是那两个字段的实际内容。列名对不上，这里就是空的或错位的，不会自动改名。

custom_outputs 保存标准结果以外的自定义输出。结构由评估器自己定义，没有固定 Schema。

这篇是结果日志的字段合同，不是打分标准

能核对的限制就是这些：一个评估器一条日志；window_id 只在持续评估；归一化分只在配了分数范围时出现；结果类型只有 score、binary、text；错误字段只在失败时写；评估器自己的 Trace 和被评估 Trace 不是同一个字段；变量名以 variableMapping 为准。没有准确率，也没有说哪种 result_type 算通过。

阿里云，阿里云帮助中心，评估结果字段说明，2026-08-31，https://help.aliyun.com/zh/agentloop/developer-reference/field-descriptions-for-evaluation-results