Eval Harness 是一个面向 Claude Code 会话的正式评估框架，实现评估驱动开发（EDD）原则。其核心理念是把评估视为“AI 开发的单元测试”：在实现之前定义预期行为，在开发过程中持续运行评估，每次变更都跟踪回归，并使用 pass@k 指标衡量可靠性。
【用途与激活场景】 该技能适用于：为 AI 辅助工作流搭建评估驱动开发；为 Claude Code 任务完成定义通过/失败标准；用 pass@k 指标衡量智能体可靠性；为提示词或智能体变更创建回归测试套件；跨模型版本对智能体性能进行基准测试。
【评估类型】 能力评估（Capability Evals）测试 Claude 能否完成此前无法完成的任务，格式包含任务描述、成功标准清单与预期输出。回归评估（Regression Evals）确保变更不破坏既有功能，格式包含基线（SHA 或检查点名称）、测试项及其 PASS/FAIL 状态与结果统计。
【评分器类型】
- 代码型评分器：使用代码进行确定性检查，例如用 grep 检查文件是否包含预期模式、运行测试、检查构建是否成功。
- 模型型评分器：使用 Claude 评估开放式输出，按是否解决问题、结构是否良好、边界情况是否处理、错误处理是否恰当等维度给出 1-5 分及理由。
- 人工评分器：标记需要人工复核的变更，注明原因与风险等级（LOW/MEDIUM/HIGH）。 产品评估（v1.8）中另列出规则型评分器（正则/模式约束）与人工评分器（对模糊输出进行人工裁定）。
【指标】 pass@k 表示“k 次尝试中至少一次成功”，如 pass@1 为首次尝试成功率、pass@3 为 3 次内成功，典型目标为 pass@3 > 90%。pass^k 表示“k 次试验全部成功”，是更高的可靠性门槛，如 pass^3 为连续 3 次成功，用于关键路径。推荐阈值：能力评估 pass@3 >= 0.90；回归评估在发布关键路径上 pass^3 = 1.00。
【工作流】
- 定义（编码前）：编写评估定义，包含能力评估、回归评估与成功指标。
- 实现：编写代码以通过已定义的评估。
- 评估：运行能力评估并记录 PASS/FAIL，运行回归评估，生成报告。
- 报告：输出评估报告，包含各项能力评估与回归评估结果、pass@1 与 pass@3 等指标及状态（如 READY FOR REVIEW）。
【集成模式】 实现前使用 /eval define feature-name，在 .claude/evals/feature-name.md 创建评估定义文件；实现期间使用 /eval check feature-name 运行当前评估并报告状态；实现后使用 /eval report feature-name 生成完整评估报告。
【评估存储】 在项目中存储于 .claude/evals/ 目录，包括 feature-xyz.md（评估定义）、feature-xyz.log（运行历史）、baseline.json（回归基线）。最小评估产物布局还包括 docs/releases/<version>/eval-summary.md 发布快照。
【最佳实践】 编码前定义评估，强制清晰思考成功标准；频繁运行评估以尽早发现回归；长期跟踪 pass@k 以监控可靠性趋势；尽可能使用代码评分器（确定性优于概率性）；安全相关检查始终保留人工复核；保持评估快速；将评估与代码一起版本化。
【本地框架工具】 机械性工具位于 scripts/lib/eval-harness/，可通过 node scripts/eval-harness.js example 运行。功能包括：胶囊（capsule）——带哈希链接的日志，含五个谱系与本地完整性检查；检查（inspection）——源摘要、已验证变体路径与语法警告；重放（replay）——声明工具与内容寻址夹具，缺失夹具时失败关闭，SE3 及以上在重放中被拒绝，记录模式会调用已注册实现，因此只应注册可信函数；回执（receipt）——对胶囊与产物字节进行离线验证并带命名检查；回顾性准备——node scripts/eval-harness.js capsule group <dir> [<dir> ...] 按声明的 harness 版本对同一任务族中 1 到 100 个显式选定、已验证的本地胶囊快照进行分组，重复快照只计一次，身份冲突或无效胶囊会拒绝整个报告，这是只读记录计数，不产生新的 rollout、评分或晋升，建议使用小型、静止的胶囊，载荷、目录参数与原始运行/胶囊 ID 会被省略，但任务族/版本标签为逐字保留且摘要引用可链接，分享前应审查，操作验证仍待完成。
【限制】 候选执行在所有操作系统上均被禁用，因为未实现经过验证的操作系统隔离后端。gate run、runGate、runVariant、直接子进程启动以及已退役的 effect preload 都会以 gate.isolation_required 拒绝，任何信任标志或调用方提供的执行器都无法绕过该拒绝。示例会记录该拒绝并在不执行、不评分的情况下检查源代码。不得将静态警告、胶囊回执或成功的工具测试呈现为候选隔离或晋升证据。未来的 gate 需要独立审查的操作系统边界、受保护的检查器与审计通道，以及致命基线拒绝。
【评估反模式】 将提示词过拟合到已知评估示例；只测量顺利路径输出；在追求通过率时忽略成本与延迟漂移；在发布门禁中允许不稳定的评分器。