针对性验证
启动完整任务前，先检查导入与注册表发现，再验证配置解析、协议校验、启动命令生成、输出解析、脱敏和清理行为。 用以下场景验证失败处理：- 缺少可执行文件或可选依赖。
- 不支持的 Model 协议或 Environment 能力。
- 无效凭证或 Model 端点响应。
- 安装失败。
- 命令超时、步骤限制、格式错误输出和取消。
- 部分会话启动后的清理。
端到端矩阵
先使用一个真实 Benchmark 任务，将任务并发数设为1 并关闭重试，然后按下表扩展验证范围：
小型并发批次用于发现共享配置文件、固定进程名称、会话 ID 冲突、全局可变状态、日志混用、客户端复用和清理竞态等问题。
如果 Harness 支持在基线阶段与运行阶段之间切换网络策略，需要证明安装或启动在基线策略下完成，并确认受限运行阶段会拒绝真实的出站请求。还要确认策略切换或 agent 执行失败时，runtime 仍会调用
close_session()。
官方对齐
如果 Harness 声称与官方 agent 或排行榜配置一致，应使用固定的 Harness 版本运行完整官方 Benchmark 数据划分。提示词、Model 协议、推理设置、步骤与成本限制、超时、资源、网络策略、重试策略和每个任务的尝试数都必须与官方配置一致。 报告需要包含：- 支持的 Benchmark、协议、Environment 和安装矩阵。
- 准确且脱敏的冒烟测试和完整评测命令。
- 一条代表性标准化轨迹和终止记录。
- 任务覆盖范围、分类后的失败情况、得分及其与官方设置的比较。
- 重要提示词、provider、Model 部署或资源差异。