第 18 章：自动化执行、版本血缘与可复现

18.1 同一个版本，为什么今天和昨天分数不同

以下是一个假设案例。一个团队每天凌晨自动运行客服 Agent 回归评测。某天早上，质量看板显示核心场景分数下降 4%。团队开始排查，却发现没有人能说清楚到底变了什么。

模型服务是否升级了？

Prompt 是否被热更新了？

知识库索引是否重新构建了？

Judge Prompt 是否改过？

工具返回是否和昨天不同？

采样参数是否一致？

如果这些问题回答不上来，评测平台就无法支撑工程决策。自动化执行不只是“批量跑起来”，更重要的是让每一次结果都可追踪、可复现、可解释。

18.2 自动化执行的基本要求

企业级评测自动化需要满足六个要求。

要求	说明
批量	能运行大量 Case 和多版本对比
稳定	超时、失败、重试可控
可追踪	每个结果能追溯到输入和配置
可复现	其他人能复跑同一 Run
可扩展	支持规则、脚本、Judge、Agent 沙箱等不同任务
成本可控	支持缓存、抽样、增量评测和预算控制

只做到批量调用模型，还不能称为 EvalOps。

18.3 任务编排

任务编排负责把一次评测拆成可运行的任务单元。

一个评测任务通常包括：

• 数据集选择。
• Case 切分。
• 模型或 Agent 配置。
• Evaluator 配置。
• 运行环境配置。
• 并发和超时策略。
• 结果存储位置。

任务编排要支持：

能力	价值
并发控制	提升吞吐，避免压垮模型和工具服务
优先级	高风险回归优先运行
超时	避免长程 Agent 卡死
重试	处理临时网络或工具失败
断点续跑	大规模评测失败后不必重跑全部
失败隔离	单条 Case 失败不影响全局
资源配额	控制 Token、沙箱和人工成本

Agent 评测尤其需要超时、循环检测和资源上限。否则一个错误 Case 可能反复调用工具，消耗大量成本。

18.3.1 Run 状态机

自动化执行需要明确 Run 状态机。

stateDiagram-v2
  [*] --> created
  created --> queued
  queued --> running
  running --> completed
  running --> failed
  running --> cancelled
  completed --> [*]
  failed --> [*]
  cancelled --> [*]

Run 状态只描述执行生命周期。Report、Gate Result 和发布决策是引用 Run 的独立证据对象，不应把 reported、approved 或 released 塞进 Run 状态机。失败或取消的 Run 可以生成执行异常报告，但不能伪装成已经形成质量结论的 completed Run。

每条 Case 都要生成独立的 Case Result；每个 Evaluator 再针对该结果生成 Evaluation Result。执行状态、质量结论和评估器错误不能塞进同一个枚举：

对象与字段	枚举	含义
Case Result.execution_status	pending / running / completed / skipped / error	Case 是否完成执行
Case Result.quality_status	passed / failed / needs_human_review / not_evaluated	汇总 Evaluation Result 后得到的质量结论
Case Result.execution_error_type	none / system_error / timeout / environment_error	被评系统或环境为何未正常完成
Evaluation Result.outcome	passed / failed / needs_human_review / error	单个 Evaluator 的判断
Evaluation Result.error_type	none / evaluator_error / invalid_evidence	该 Evaluator 为何未形成正常判断

退款工具超时不能直接算 Agent 质量失败，Judge 调用失败也不能写成被评系统失败。前者进入 Case Result 的执行错误，后者进入对应 Evaluation Result 的评估器错误。

18.3.2 队列与资源隔离

不同评测任务应进入不同队列。

队列	任务
smoke_queue	PR 和小变更快速检查
release_queue	发布前核心回归
batch_queue	夜间全量评测
redteam_queue	安全红队评测
sandbox_queue	长程 Agent 和代码执行任务
human_queue	人工复核任务

队列隔离可以避免一个长程 Agent 任务堵塞所有评测。发布前高风险回归应有更高优先级，夜间全量评测可以使用更低优先级。

18.4 幂等与缓存

幂等意味着同一个输入和同一组配置重复执行，不应该产生不可解释的副作用。

客服 Agent 评测中，工具调用必须运行在沙箱或模拟环境里，不能真的提交退款、修改账户或发送通知。

缓存用于降低成本和提升可复现性。适合缓存的内容包括：

• 检索结果。
• 工具模拟返回。
• Judge 评分结果。
• 模型输出。
• 中间 Trace。

但缓存需要绑定版本。检索结果缓存要绑定知识库和索引版本；Judge 结果缓存要绑定 Judge Prompt 和模型版本；工具返回缓存要绑定工具 Schema 和环境状态。

错误的缓存会制造更隐蔽的问题：系统看起来稳定，实际是在复用过期结果。

每次缓存命中还应记录缓存对象类型、完整缓存键、来源 Run、结果哈希和命中时间，并在结果中区分新执行与缓存复用。否则平台会把“复用旧证据”误写成“本次重新执行”，既无法解释波动，也无法审计成本和门禁证据。

18.4.1 缓存键设计

缓存需要精确的键，而且不同缓存对象不能共用一套键。一个模型或 Agent 执行输出缓存至少应绑定：

缓存维度	示例
case_id 和 case_version	refund_member_partial_001@v2
model_version	model_a_202607
prompt_hash	prompt_sha256
knowledge_index_version	refund_index_20260701
tool_schema_version	refund_tool_schema_v4
sampling_config	temperature、top_p、max_tokens

Evaluator 不改变被评系统的原始输出，因此不应混入执行输出缓存键。评估结果缓存应另外绑定 output_hash、evaluator_id、evaluator_version、rubric_version 以及 Judge 模型版本。这样 Evaluator 更新后可以复用原始输出重评，又不会错误复用旧评分。

如果执行输出缓存键缺少知识库版本，RAG 评测会复用过期召回结果；如果评估结果缓存键缺少 Judge 或 Rubric 版本，Evaluator 更新后仍可能显示旧评分。

18.5 版本血缘

版本血缘是可复现的核心。

本节按类别解释为什么要记录这些依赖；18.10 交付物定义血缘核心字段路径和必填性，模板 06 在此基础上增加触发信息、结果摘要和 artifacts 等运行外壳，并给出权威 YAML 交换格式。

图 18-1 版本血缘关系图

flowchart TB
  RUN["Eval Run"] --> MODEL["Model<br/>model_id/version/provider/参数"]
  RUN --> PROMPT["Prompt<br/>system/task/content_hash"]
  RUN --> AGENT["Agent Config<br/>planner/executor/memory"]
  RUN --> DATA["Dataset<br/>dataset_id/version/case_ids"]
  RUN --> KB["Knowledge<br/>corpus/index/embedding"]
  RUN --> TOOL["Tool<br/>schema/permission"]
  RUN --> EVAL["Evaluator<br/>evaluator_id/version/rubric"]
  RUN --> ENV["Environment<br/>sandbox/runtime/deps"]
  RUN --> EXEC["Execution<br/>timestamp/runner/seed/sampling"]

一次 Run 至少要记录：

类别	字段
模型	model_id、model_version、provider、参数
Prompt	system_prompt_version、task_prompt_version、content_hash
Agent	agent_config_version、planner、executor、memory_config
数据	dataset_id、dataset_version、case_ids
知识库	corpus_version、index_version、embedding_model
工具	tool_schema_version、permission_config
Evaluator	evaluator_id、version、judge_model、rubric_version
环境	sandbox_version、runtime、dependency_version
执行	timestamp、runner_version、random_seed、sampling_config

没有这些字段，就无法判断分数变化来自哪里。

18.5.1 Run 证据包

版本血缘最终应沉淀为 Run 证据包，供后续发布评审、问题归因和审计复查同一次评测，而不只是归档保存。

一个可用的 Run 证据包至少包含：

内容	用途
Run 配置快照	证明该次评测使用了哪些模型、Prompt、数据和 Evaluator
Case 快照	证明评测样本当时是什么状态
原始输出	支持人工复查和争议处理
Evaluator 结果	支持指标计算和门禁判断
Trace 与工具日志	支持 Agent 过程归因
成本和延迟记录	支持规模化和预算决策
Gate Result	支持发布审批和风险接受
异常记录	区分系统失败、评估器失败和质量失败

如果一次 Run 只能看到聚合分数，不能回到样本、证据、版本和执行环境，它就不足以支撑企业级发布决策。Run 证据包是 EvalOps 平台从“跑分工具”升级为“质量基础设施”的关键对象。

18.6 运行环境

评测运行环境要和生产环境足够接近，同时保持安全隔离。

对于客服 Agent，运行环境包括：

• 订单数据沙箱。
• 退款工具模拟。
• 身份权限配置。
• 知识库索引。
• 业务规则版本。
• 审计日志。

对于代码 Agent，运行环境包括：

• 仓库快照。
• 依赖版本。
• 测试命令。
• 文件系统权限。
• 网络访问策略。
• 命令执行沙箱。

运行环境也要版本化。否则，一个 Case 今天通过、明天失败，可能只是依赖或测试数据变了。

18.7 结果存储

评测结果不应只保存聚合分数。至少要保存五类数据：

数据	用途
原始输入和输出	复查和人工分析
Evaluation Result	指标计算、人工复核和门禁
Trace	过程回放和归因
日志和错误栈	排查执行失败
成本和延迟	规模化决策

Case Result 与 Evaluation Result 的最小契约如下。实际平台可以拆表或使用 artifact 存储大字段，但这些关联键不能缺失。

case_result:
  case_result_id:
  run_id:
  case_id:
  case_version:
  execution_status: pending | running | completed | skipped | error
  quality_status: passed | failed | needs_human_review | not_evaluated
  input_snapshot_uri:
  output:
  trace_id:
  artifact_refs: []
  execution_error:
    type: none | system_error | timeout | environment_error
    message:
  started_at:
  completed_at:

evaluation_result:
  evaluation_result_id:
  case_result_id:
  evaluator_id:
  evaluator_version:
  metric_values: {}
  outcome: passed | failed | needs_human_review | error
  reason:
  evidence_refs: []
  confidence:
    value:
    semantics:
  review_required:
  error_type: none | evaluator_error | invalid_evidence
  evaluated_at:

Run 的通过率、高风险失败数、成本和延迟都应由这些逐 Case 事实聚合生成。模型回答错误是质量问题；工具服务超时可能是执行或环境问题；Judge 调用失败是 Evaluator 问题。三者应能分别查询和重算。

一旦原始输出、Evaluator 结果或 Trace 被 Gate Result、Report 或发布决定引用，就不得原地覆盖。修正、补跑或重评应生成新的不可变 artifact、结果哈希和关联记录，并保留旧证据。否则历史发布决定会失去可审计的事实基础。

18.8 可复现运行

可复现不是“再点一次运行”。可复现意味着：使用同一组输入、配置、版本和环境，可以重新得到一致或可解释的结果。

可复现运行需要：

1. 记录所有版本。
2. 固定采样参数。
3. 保存 Case 快照。
4. 保存 Prompt 快照。
5. 保存 Evaluator 快照。
6. 保存环境镜像或配置。
7. 保存工具模拟数据。
8. 标记不可控外部依赖。

对于概率性模型，完全一致不一定总能保证。即使记录了随机种子，远程模型服务、并发调度或依赖版本变化仍可能引入非确定性；平台至少要记录已知随机性来源，并通过预先约定的重复运行或统计方法解释波动。

18.8.1 可复现验收的三个维度

可复现不是一条从低到高的单轴等级。平台应分别验收配置、差异解释和决策稳定性；三者可以同时成立，也可能分别失败。

验收维度	含义	适用场景
配置可复现	能复原模型、Prompt、数据、工具、Evaluator 和环境配置	常规版本对比和报告复查
差异可解释	重跑结果允许有波动，但波动来源和证据可追踪	概率模型、Judge、开放式回答评测
决策稳定	在预设重复运行协议下，关键门禁不发生无法解释的反转	发布门禁、高风险回归

对于客服 Agent，普通语义回答不一定要求逐字一致，但高风险门禁结论需要稳定。如果同一条隐私红队样本有时通过、有时失败，说明系统不稳定，应进入阻断或人工复核，而不能用平均结果掩盖。

因此，平台要记录重跑次数、波动范围和关键指标是否反转。可复现关注差异能否解释、结论是否可信，并不要求所有输出逐字相同。

18.9 增量评测

全量评测成本高，不是每次变更都需要跑所有 Case。

增量评测的前提是对象和依赖关系清楚。具体发布触发规则以第 19 章为准；本章只解释执行引擎如何从变更对象反查受影响 Case，避免再次维护一张发布矩阵。

18.9.1 受影响 Case 选择

增量评测的关键是选择受影响 Case。

选择依据包括：

变更	受影响 Case 选择方式
Prompt 修改	关联该 Prompt 的场景、能力和 Regression Case
知识库文档更新	引用该文档或同主题 gold evidence 的 RAG Case
Tool Schema 修改	使用该工具的 Tool Case 和 Agent Trace Case
Agent 配置修改	涉及该编排路径的多轮和长程 Case
Evaluator 修改	使用该 Evaluator 的历史 Run 校准集
安全策略修改	相关 Red Team Set 和误拒样本

平台应支持从对象关系反查 Case，而不是依赖人工记忆。

18.9.2 增量评测的风险

增量评测不能替代周期性全量评测。它的风险是影响范围判断不完整。

例如，Prompt 中新增“遇到金额问题要更谨慎”，表面只影响退款场景，实际可能让普通物流赔付咨询过度转人工。平台应定期运行全量评测，校准增量策略是否漏掉退化。

18.10 交付物一：评测 Run 血缘字段表

字段	必需	说明
run_id	是	运行唯一标识
task_id	是	评测任务
versions.model	是	模型服务、版本与关键参数快照
versions.system_prompt	是	系统 Prompt 版本或内容哈希
versions.app_prompt	是	业务 Prompt 版本或内容哈希
versions.agent_config	Agent 场景必需	Agent 编排和状态配置版本
versions.dataset	是	数据集版本
case_snapshot	是	Case 快照
versions.evaluator	是	Evaluator 版本
versions.rubric	是	Rubric 版本
versions.tool_schema	Tool 场景必需	工具 Schema 和权限版本
versions.knowledge_base / index / embedding_model	RAG 场景必需	语料、索引与向量模型版本
versions.environment	是	沙箱、依赖和外部数据快照
execution_config.runner_version	是	执行器版本
execution_config.sampling_config	是	采样参数和已知随机性来源
timestamp	是	执行时间
case_results_uri	是	逐 Case Result 的不可变结果集
evaluation_results_uri	是	逐 Evaluator 判断结果集
result_hash	建议	结果摘要

18.11 交付物二：自动化执行引擎能力清单

能力	是否必需
批量 Case 执行	必需
并发和限流	必需
超时和重试	必需
断点续跑	必需
结果缓存	建议
增量评测	建议
Trace 采集	Agent 场景必需
沙箱隔离	执行型任务必需
人工复核队列	高风险场景必需
成本预算控制	大规模评测必需

18.12 交付物三：可复现运行检查表

检查项	通过标准
输入是否固定	Case 快照可追溯
配置是否固定	模型、Prompt、Evaluator、工具版本完整
环境是否固定	沙箱和依赖版本可追溯
随机性是否记录	采样参数和运行次数明确
输出是否保存	原始输出、评分、Trace 保存
错误是否分类	质量失败和系统失败区分
是否可重跑	能基于 run_id 复现或解释差异

18.13 本章小结

自动化执行让评测稳定、可追踪、可复现、可解释，批量调用模型只是其中一步。

本章的核心是版本血缘。没有血缘，版本对比不可信；没有可复现，评测无法支撑门禁；没有执行引擎，评测无法规模化。

有了自动化执行能力，下一章将把评测接入发布流程，建立 CI/CD 门禁和灰度策略，让评测结果直接参与发布决策。