上一篇我们讲 Long-running Agent Harness：长任务要靠状态外部化、handoff artifact 和 checkpoint 才能持续推进。但推进只是第一步。新的问题马上来了：你改了 handoff 模板、加了 progress file、调整了 context reset 策略，怎么证明 Agent 真的变好了？

如果答案是"这次看起来更顺"，那还不够。

Agent 的非确定性很强。同一个任务，今天跑通，明天可能因为模型更新、工具输出变化、依赖版本变化、上下文裁剪不同而失败。一次成功演示不能证明系统可靠，一次公开 benchmark 提升也不能证明你的业务场景变好。

这就是 Evaluation Harness 要解决的问题：把 Agent 的一次运行变成可复现、可评分、可对比、可回归拦截的实验。

---

01Benchmark 不等于 Evaluation Harness

Benchmark 和 Evaluation Harness 都在"评估 Agent"，但它们回答的问题完全不同。

对比项	Benchmark	Evaluation Harness
核心问题	模型/Agent 在公共任务上表现如何	我们的 Agent 改动是否让业务任务变好
输入	固定公开任务集	私有任务、真实工作区、工具和权限
输出	排行榜分数	trace、artifact、score、regression gate
关注点	能力上限	生产可靠性和回归风险
主要风险	数据污染、排行榜过拟合	case 设计偏差、评分器漂移

表 1: Benchmark 与 Evaluation Harness 对比。
公共 benchmark 有价值，它告诉你某类能力的大致上限。代码 Agent 可以看 SWE-bench，浏览器 Agent 可以看 WebArena，通用工具使用可以看 GAIA。但它们不能回答你的核心问题：这次 Harness 改动有没有让你的 Agent 在你的仓库、你的工具、你的权限边界里更可靠？

Evaluation Harness 的基本闭环是：

Eval Case → Agent Run → Episode Package → Scoring → Baseline Comparison → CI Gate

图 1: Evaluation Harness 闭环。从 eval case 到 episode package，再到评分、基线对比和回归门禁。

这一层和 Runtime Harness 的关系很紧：Runtime Harness 负责让 Agent 运行，Evaluation Harness 负责证明运行是否变好。没有 Evaluation Harness，Runtime Harness 的改进就会停留在感觉层面。

图 1 可以当成全文的阅读地图：前半部分解决"一次运行如何变成证据"，后半部分解决"多次运行如何变成发布决策"。

---

02Eval Case 应该长什么样

很多团队一开始写 eval，会写成这样：

任务：修复登录失败。期望：测试通过。

这太粗了。它更像一句需求，不像一个评测用例。一个可复现的 eval case 至少要包含六类信息。

字段	作用
task	用户任务和背景
workspace	初始文件、仓库版本、数据集、环境
tools	可用工具、权限、超时、禁止动作
expected behavior	期望完成什么，不期望做什么
scoring rubric	怎么评分，哪些是硬失败
metadata	标签、难度、历史 bug、负责人

表 2: Eval Case 字段说明。
一个更完整的 eval case 可以写成这样：

id: auth-callback-missing-statetask: 修复 OAuth callback 在缺少 state 参数时返回 500 的问题workspace:  repo: git@example.com/app.git  ref: 4f2c9e1  files:    - src/auth/callback.ts    - tests/auth/callback.test.tstools:  allowed:    - read_file    - apply_patch    - shell:pnpm test tests/auth/callback.test.ts  forbidden:    - modify_database_schema    - install_dependencyexpected_behavior:  must:    - 缺少 state 时返回 400    - 原有成功登录流程不回归  must_not:    - 改动 public API    - 跳过现有测试scoring:  hard_fail:    - 测试未通过    - 修改禁止文件  soft_score:    correctness: 0.5    minimality: 0.2    evidence_quality: 0.2    cost: 0.1

图 2: Eval Case 结构。好的评测用例不只描述任务，还描述初始工作区、工具权限、评分规则和禁止动作。

这里有个关键点：eval case 评的不只是模型输出，还评 Harness 边界。 如果 Agent 修改了禁止文件、绕过了验证命令、访问了未授权目录，即使最终答案看起来正确，也应该被扣分甚至判硬失败。

Evaluation Harness 不是让 Agent 尽可能拿高分，而是让团队知道系统在哪些边界内可靠。

写 eval case 时有三个常见反模式：

• 只写成功路径：case 里只有"应该做什么"，没有"绝对不能做什么"

• 工作区不固定：每次运行的仓库版本、依赖版本、环境变量都可能不同

• 评分规则太模糊：只写"回答质量高"，没有明确 hard fail 和权重

这些反模式会让评估结果看起来很热闹，但无法用于发布决策。

Eval Case 的生命周期

Eval case 不是一次写完就不再变化的配置文件，而是一组需要长期维护的测试资产。一个成熟的 Evaluation Harness 通常会给 case 标注来源和状态：

来源	适合沉淀成什么
历史线上事故	Regression case
高频用户任务	Golden case
权限、异常输入、边界条件	Edge case
线上抽样 trace	Shadow case
人工构造的能力测试	Capability case

表 3: Eval Case 来源与沉淀方式。
维护 eval case 时要避免两个极端：一是 case 永远不更新，导致它无法代表真实任务；二是每次失败都随手改 expected behavior，导致 baseline 失去稳定性。比较稳的做法是：新增 case 很容易，修改核心 case 很谨慎，删除 case 必须记录原因。

还要防止 case 被"污染"。如果 eval case、参考答案或评分细节长期暴露在训练数据、prompt 示例或 agent 可读文档里，Agent 可能学会迎合 case，而不是真正解决任务。对于核心 Golden Set，至少要做到：固定版本、控制访问、记录变更，并在 episode package 里保存 case 版本号。

---

03End-state Evaluation 与 Step-by-step Evaluation

Agent 评估有两种基本视角：看最终结果，或者看过程步骤。

End-state Evaluation

End-state evaluation 只看最终状态。代码任务里，它通常检查：

• 测试是否通过

• diff 是否合理

• 输出 artifact 是否存在

• 是否违反禁止动作

• 最终回答是否解释清楚

它的优点是简单、稳定、成本低。用户最终关心的也通常是结果：功能修没修好，报告有没有生成，数据有没有分析完。

但它有一个缺点：它看不见糟糕过程。

一个 Agent 最终可能把测试跑通了，但中间删过用户文件、重复调用了 20 次昂贵工具、靠猜测改了不该改的模块。End-state evaluation 可能给它高分，但生产系统不能接受这种路径。

Step-by-step Evaluation

Step-by-step evaluation 会看执行过程。它检查：

• 工具选择是否合理

• 每一步是否推进任务

• 是否出现无效循环

• 是否及时验证假设

• 是否在高风险动作前请求审批

• 失败后是否正确恢复

AgentEval 这类研究强调，用 DAG 建模 Agent 步骤依赖，可以发现端到端评分漏掉的中间失败[1]。这对 Harness 特别重要，因为 Harness 的很多价值都发生在过程里：权限拦截、状态恢复、trace 记录、artifact 生成、失败归因。

图 3: End-state Evaluation 看结果，Step-by-step Evaluation 看路径。生产评估通常需要两者结合。

怎么组合

任务类型	推荐评估方式
简单问答	End-state 为主
代码修改	End-state + 关键步骤检查
长任务 Agent	Step-by-step + milestone 评分
高风险工具调用	Step-by-step + 权限审计
多 Agent 协作	Trace-based evaluation + failure attribution

表 4: 不同任务的评估方式。
一句话总结：结果评分告诉你有没有做成，过程评分告诉你做成的方式是否可接受。

真正落地时，建议把 End-state 作为硬门槛，把 Step-by-step 作为质量信号。也就是说，测试不通过、产物不存在、违反禁止动作，直接判失败；但工具选择是否优雅、是否绕路、是否出现无效循环，可以进入质量分和回归分析。这样既不会让评估系统过度主观，也不会放过那些"结果碰巧对了、过程很危险"的运行。

---

04Episode Package：一次运行的证据包

没有证据包，评估就不可复现。你只保存了最后回答，却没有保存初始工作区、工具调用、diff、日志和评分过程。过两周发现一个回归，想复盘时只剩一句"当时好像跑通了"。

Evaluation Harness 应该把每次运行保存成 episode package。它不是一个日志文件，而是一组可复现实验材料。

一个 episode package 至少包含：

episode/├─ case.yaml             # eval case├─ manifest.json         # 工作区和权限声明├─ initial_snapshot/     # 初始工作区引用├─ final_snapshot/       # 最终工作区引用├─ trace.jsonl           # LLM 调用、工具调用、状态转移├─ artifacts/            # 报告、patch、handoff、图片等产物├─ verification.log      # 测试、构建、lint、人工检查记录├─ scores.json           # 自动评分和人工评分└─ metadata.json         # 模型、prompt、tool 版本、运行时间、成本

图 4: Episode Package 结构。它让一次 Agent run 从"聊天记录"变成可复现、可对比、可审计的实验样本。

Episode package 的价值有三个：

1. 可复现：同一个 case、同一个 workspace、同一组工具权限，可以重新运行

2. 可归因：知道失败来自模型、prompt、工具、workspace 还是 Harness

3. 可审计：高风险动作、权限拦截、人工介入都有证据

AI Harness Engineering 论文把 trace-based evaluation protocol 作为 Harness 的一项核心能力，原因也在这里：Agent 的问题很少只体现在最终答案里，更多藏在中间路径里[2]。

Episode package 还承担一个容易被低估的角色：让评估结果可争辩。当 CI gate 拦住一次发布时，团队不应该只看到一个分数，而应该能打开对应 episode，看到 case、trace、diff、日志和评分理由。只有这样，评估才会从"模型裁判说不行"变成工程团队可以复盘的事实材料。

---

05LLM Judge 能评什么，不能评什么

LLM-as-Judge 很适合 Evaluation Harness，但不能盲用。它擅长评语义质量，不擅长替代确定性验证。

能评	不应该只靠它评
回答是否完整	测试是否真的通过
解释是否清楚	是否越权访问文件
patch 是否看起来合理	是否泄漏凭证
报告是否覆盖关键问题	是否满足安全策略
handoff artifact 是否可接手	是否产生不可逆副作用

表 5: LLM Judge 能评什么。
一个可靠的评分系统通常是混合的：

确定性检查：测试、lint、权限、文件 diff、成本阈值规则评分：是否包含必要 artifact、是否跑过指定命令LLM Judge：语义正确性、解释质量、handoff 可读性人工复核：高风险 case、边界 case、争议 case

LLM Judge 应该拿到足够证据，而不只是最终回答。比如评一个代码 Agent，不应该只看"我已经修好了"这句话，而应该看 task、diff、测试日志、trace 摘要和最终说明。

但证据也不能无限塞。最好的方式是由 Harness 生成一个 judge packet：

Judge Packet├─ task summary├─ allowed / forbidden actions├─ final diff summary├─ verification results├─ key trace events└─ final answer

这样 Judge 看到的是结构化证据，而不是完整聊天历史。

Warning：LLM Judge 的分数不能直接当真理。至少要做位置随机化、样本人工校准、模型版本记录和评分解释留存。否则你无法区分 Agent 变好了，还是 Judge 口味变了。

---

06Baseline Comparison：只看绝对分不够

Evaluation Harness 的核心不是"跑一次得 83 分"，而是"这个版本相对基线有没有变好"。

基线至少有三类：

基线	用途
当前生产版本	判断是否可以发布
上一个候选版本	判断本次改动是否有效
人工或脚本基线	判断 Agent 是否真的有必要

表 6: Baseline 类型。
Eval case 本身也应该分层管理：

数据集	内容	更新频率
Golden Set	核心业务场景，人工确认标准答案	慢，谨慎更新
Regression Set	历史失败和线上事故	每次修复后追加
Edge Set	权限、边界、异常输入	随风险发现更新
Shadow Set	线上抽样生成的新 case	定期筛选进入前三类

表 7: Eval 数据集分层。
没有分层的数据集很快会变成一锅粥：核心 case、历史 bug、边界场景混在一起，分数涨跌都解释不清。

对 Agent 来说，平均分不够，还要看方差和失败类型。一个版本平均分从 82 提到 85，但高风险 case 的失败率从 2% 升到 8%，这不是变好。

一个更实用的对比表应该长这样：

指标	baseline	candidate	判断
任务完成率	78%	84%	变好
高风险越权次数	0	1	阻断
平均 token	42k	55k	成本变差
P95 延迟	180s	240s	需要关注
Handoff 可接手评分	3.8/5	4.5/5	变好
失败归因清晰度	62%	80%	变好

表 8: Baseline 对比指标。
这里最重要的是"阻断项"。有些指标不能被平均分抵消，例如越权访问、凭证泄漏、禁止文件修改、不可逆副作用。Evaluation Harness 必须允许某些 case 一票否决。

---

07CI Gate：把评估接进发布流程

Evaluation Harness 只有接进发布流程，才真正有价值。否则它只是一个偶尔运行的分析脚本。

一个最小 CI gate 可以分四层：

1. Smoke eval：少量核心 case，每次 PR 都跑，控制在 5-10 分钟

2. Regression eval：历史 bug case，每天或合并前跑

3. Full eval：完整任务集，发布候选版本跑

4. Shadow eval：线上流量镜像或抽样，观察真实分布

图 5: CI Regression Gate。不同评测层级对应不同频率和阻断强度。

门禁策略也要分级：

门禁类型	触发条件	响应
Hard gate	安全违规、禁止动作、核心测试失败	阻止发布
Soft gate	成本上升、延迟上升、Judge 分下降	告警，需要人工确认
Trend gate	连续多次小幅退化	阻止或降级发布
Manual gate	高风险 case 变化	需要人类复核

表 9: CI Gate 门禁类型。
Agent Patterns 对 eval harness 的建议也是这个方向：构造可重复评测、保存 baseline、在 CI 中比较 candidate 与 baseline[3]。这不是为了追求流程复杂，而是为了避免 Agent 系统最常见的问题：局部看起来变好，整体悄悄回归。

---

08失败归因：到底是谁变了

Agent 系统的回归很难定位，因为变量太多。

一次失败可能来自：

• 模型版本变了

• prompt 变了

• 工具 schema 变了

• 工具实现变了

• workspace 初始状态变了

• sandbox 镜像变了

• context compaction 策略变了

• 权限策略变了

• Judge 模型变了

如果 episode package 没有记录这些版本，失败归因就会变成猜谜。

Evaluation Harness 应该强制记录运行矩阵：

{  "model": "model-name@version",  "prompt": "agent-system-prompt@sha256",  "tools": {    "shell": "v2",    "apply_patch": "v1"  },  "sandbox_image": "agent-node-22@sha256",  "manifest": "manifest@sha256",  "harness": "runtime-harness@commit",  "judge": "judge-model@version",  "case": "auth-callback-missing-state@v3"}

有了这张矩阵，你才能做最基本的 ablation：

• 固定模型，只改 Harness，看 Harness 是否有效

• 固定 Harness，只换模型，看模型是否更强

• 固定 case 和 workspace，只改 prompt，看提示词是否带来回归

• 固定 Judge，比较候选版本，避免评分器漂移

一句话总结：没有版本矩阵，就没有失败归因。没有失败归因，Evaluation Harness 只是在打分，不是在学习。

---

09最小可行 Evaluation Harness

如果你现在要从零开始，不需要一次性做完整平台。可以先做一个最小版本：

evals/├─ cases/│  ├─ auth-callback-missing-state.yaml│  └─ billing-permission-denied.yaml├─ baselines/│  └─ production-v1/├─ episodes/│  └─ 2026-05-20-auth-callback/├─ scorers/│  ├─ deterministic.ts│  ├─ judge_prompt.md│  └─ rubric.yaml└─ report.md

最小闭环：

1. 选择 20-50 个真实 case

2. 每个 case 固定 workspace、工具权限和评分规则

3. 每次运行保存 episode package

4. 自动跑确定性检查

5. 对语义部分使用 LLM Judge

6. 和 production baseline 对比

7. 核心 case 回归时阻止发布

这套系统不一定华丽，但已经能回答最重要的问题：改动之后，Agent 在我们的任务上有没有更可靠？

---

10总结：评估不是打分，而是闭环

Evaluation Harness 的核心价值不是给 Agent 一个漂亮分数，而是让团队能持续回答四个问题：

1. 这次运行发生了什么？ 通过 episode package 保存证据。

2. 结果是否满足标准？ 通过 deterministic check、规则评分和 LLM Judge 混合评估。

3. 相比基线有没有变好？ 通过 baseline comparison 看均值、方差和失败类型。

4. 是否可以发布？ 通过 CI gate 把评估结果接入工程流程。

这也是它和公共 benchmark 的根本区别。Benchmark 评能力上限，Evaluation Harness 评你的系统在真实边界里的可靠性。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】