第 18 章：自动化执行、版本血缘与可复现
第 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 状态机。
created
↓
queued
↓
running
↓
completed / failed / cancelled
↓
reported
对 Agent 评测，还应记录 Case 级状态：
| 状态 | 含义 |
|---|---|
| pending | 尚未执行 |
| running | 正在执行 |
| passed | 质量通过 |
| failed_quality | 模型或 Agent 行为失败 |
| failed_system | 执行环境、工具或平台失败 |
| timeout | 执行超时 |
| needs_human_review | 需要人工复核 |
| skipped | 因配置或依赖缺失跳过 |
区分质量失败和系统失败非常重要。退款工具返回超时不能直接算 Agent 答错；Judge 调用失败也不能算被评系统失败。
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 和环境状态。
错误的缓存会制造更隐蔽的问题：系统看起来稳定，实际是在复用过期结果。
18.4.1 缓存键设计
缓存必须有精确缓存键。一个模型输出缓存至少应绑定：
| 缓存维度 | 示例 |
|---|---|
| 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 |
| evaluator_version | judge_v3 |
| sampling_config | temperature、top_p、max_tokens |
如果缓存键缺少知识库版本，RAG 评测会复用过期召回结果；如果缺少 Judge 版本，Evaluator 更新后仍可能显示旧评分。
18.5 版本血缘
版本血缘是可复现的核心。
图 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 过程归因 |
| 成本和延迟记录 | 支持规模化和预算决策 |
| 门禁结果 | 支持发布审批和风险接受 |
| 异常记录 | 区分系统失败、评估器失败和质量失败 |
如果一次 Run 只能看到聚合分数，不能回到样本、证据、版本和执行环境，它就不足以支撑企业级发布决策。Run 证据包是 EvalOps 平台从“跑分工具”升级为“质量基础设施”的关键对象。
18.6 运行环境
评测运行环境要和生产环境足够接近，同时保持安全隔离。
对于客服 Agent，运行环境包括：
- 订单数据沙箱。
- 退款工具模拟。
- 身份权限配置。
- 知识库索引。
- 业务规则版本。
- 审计日志。
对于代码 Agent，运行环境包括：
- 仓库快照。
- 依赖版本。
- 测试命令。
- 文件系统权限。
- 网络访问策略。
- 命令执行沙箱。
运行环境必须版本化。否则，一个 Case 今天通过、明天失败，可能只是依赖或测试数据变了。
18.7 结果存储
评测结果不应只保存聚合分数。至少要保存五类数据：
| 数据 | 用途 |
|---|---|
| 原始输入和输出 | 复查和人工分析 |
| Evaluator 结果 | 指标计算和门禁 |
| Trace | 过程回放和归因 |
| 日志和错误栈 | 排查执行失败 |
| 成本和延迟 | 规模化决策 |
每条 Case 的结果也要有状态：
- passed。
- failed。
- skipped。
- evaluator_error。
- system_error。
- timeout。
- needs_human_review。
评测失败和系统执行失败必须区分。模型回答错了是质量问题；工具服务超时可能是环境问题；Judge 调用失败是评估器问题。
18.8 可复现运行
可复现不是“再点一次运行”。可复现意味着：使用同一组输入、配置、版本和环境，可以重新得到一致或可解释的结果。
可复现运行需要：
- 记录所有版本。
- 固定采样参数。
- 保存 Case 快照。
- 保存 Prompt 快照。
- 保存 Evaluator 快照。
- 保存环境镜像或配置。
- 保存工具模拟数据。
- 标记不可控外部依赖。
对于概率性模型，完全一致不一定总能保证，但至少要记录随机性来源，并通过多次运行或统计方式解释波动。
18.8.1 可复现的三个等级
可复现不是单一标准。不同场景需要不同等级。
| 等级 | 含义 | 适用场景 |
|---|---|---|
| 配置可复现 | 能复原模型、Prompt、数据、工具、Evaluator 和环境配置 | 常规版本对比和报告复查 |
| 结果可解释 | 重跑结果允许有波动，但波动来源可解释 | 概率模型、Judge、开放式回答评测 |
| 结果近似可复现 | 重跑后结论稳定，关键门禁不发生反转 | 发布门禁、高风险回归 |
对于客服 Agent，普通语义回答不一定要求逐字一致，但高风险门禁结论必须稳定。如果同一条隐私红队样本有时通过、有时失败，说明系统不稳定，应进入阻断或人工复核，而不能用平均结果掩盖。
因此，平台要记录重跑次数、波动范围和关键指标是否反转。可复现的目标不是追求所有输出完全相同，而是让差异可解释、结论可信。
18.9 增量评测
全量评测成本高，不是每次变更都需要跑所有 Case。
可以按变更类型触发增量评测：
| 变更 | 优先评测 |
|---|---|
| Prompt 修改 | Golden Set、Prompt 回归、核心 Hard Case |
| 知识库更新 | RAG Case、相关业务场景 Regression Set |
| 工具 Schema 修改 | Tool Case、端到端工具链 Case |
| Agent 编排修改 | Trace Case、长程任务、异常恢复 |
| Judge 更新 | Meta-Evaluation、人工校准集 |
| 模型替换 | 全量 Eval Set、Red Team、成本延迟评测 |
增量评测的前提是对象和依赖关系清楚。否则系统不知道一个变更影响哪些 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 | 是 | 评测任务 |
| model_version | 是 | 模型版本 |
| prompt_version | 是 | Prompt 版本 |
| agent_config_version | 视情况 | Agent 配置 |
| dataset_version | 是 | 数据集版本 |
| case_snapshot | 是 | Case 快照 |
| evaluator_version | 是 | Evaluator 版本 |
| rubric_version | 是 | Rubric 版本 |
| tool_schema_version | 视情况 | 工具版本 |
| knowledge_index_version | 视情况 | 知识库索引 |
| environment_version | 是 | 环境版本 |
| runner_version | 是 | 执行器版本 |
| sampling_config | 是 | 采样参数 |
| timestamp | 是 | 执行时间 |
| result_hash | 建议 | 结果摘要 |
18.11 交付物二：自动化执行引擎能力清单
| 能力 | 是否必需 |
|---|---|
| 批量 Case 执行 | 必需 |
| 并发和限流 | 必需 |
| 超时和重试 | 必需 |
| 断点续跑 | 必需 |
| 结果缓存 | 建议 |
| 增量评测 | 建议 |
| Trace 采集 | Agent 场景必需 |
| 沙箱隔离 | 执行型任务必需 |
| 人工复核队列 | 高风险场景必需 |
| 成本预算控制 | 大规模评测必需 |
18.12 交付物三：可复现运行检查表
| 检查项 | 通过标准 |
|---|---|
| 输入是否固定 | Case 快照可追溯 |
| 配置是否固定 | 模型、Prompt、Evaluator、工具版本完整 |
| 环境是否固定 | 沙箱和依赖版本可追溯 |
| 随机性是否记录 | 采样参数和运行次数明确 |
| 输出是否保存 | 原始输出、评分、Trace 保存 |
| 错误是否分类 | 质量失败和系统失败区分 |
| 是否可重跑 | 能基于 run_id 复现或解释差异 |
18.13 本章小结
自动化执行不是批量调用模型，而是让评测稳定、可追踪、可复现、可解释。
本章的核心是版本血缘。没有血缘，版本对比不可信；没有可复现，评测无法支撑门禁；没有执行引擎，评测无法规模化。
有了自动化执行能力，下一章我们将把评测接入发布流程，建立 CI/CD 门禁和灰度策略，让评测真正影响发布决策。