Harness Engineering 06从单个 Harness 到 Harness Platform四个项目各自独立做 Harness 三个月后团队发现了一个很现实的问题四个项目的 Harness 现状对比 activity-dev AIReview 配置表 Crashsight harness 风险评估 ───────────── ─────────── ───────── ───────── ────────── Eval 评测集 35 case ✓ 28 case ✓ 42 case ✓ 15 case ✓ Eval 自动回归 ✓ 每次变更 ✓ 每日 ✓ 每日 ✗ 手动 Trace 记录 5 类节点 ✓ 3 类节点 2 类节点 1 类节点 Trace 格式 自定义 JSON 自定义 CSV 无格式 纯文本日志 工具分级 L1/L2/L3 ✓ L1/L2 ✓ L1/L2 ✓ 无分级 Safety 权限矩阵 角色隔离 ✓ 部分 ✓ 部分 ✓ 无 HITL 接管机制 3轮升级 ✓ 低置信复核 高风险阻断 无 版本管理 4 维版本 ✓ 2 维 1 维 无 线上问题回收 ✓ 部分 ✓ ✗ ✗ ───────────────────────────────────────────────────────────────────── 成熟度 ████ ███ ██ █activity-dev-harness 最成熟Crashsight 最薄弱。但即使是最成熟的项目也没法把自己的 Harness 能力直接给别人用——因为每个项目的 Eval 格式不同、Trace 格式不同、工具分级标准不同、接管机制不同。四个项目的 Eval 回归脚本写了四遍Trace 记录方案设计了四遍工具分级逻辑实现了四遍。当同样的事情做第四遍的时候就不是各自做得好的问题了而是该沉淀平台了。手记系列讲了版本治理和平台化基础这篇讲Harness 怎么从项目长成平台手记 07 的视角 本篇的视角 ────────────── ────────────────── 版本治理的维度和方法 Harness 能力怎么从项目沉淀为平台 灰度发布策略 什么进平台、什么留场景 成本优化 从四个真实项目里提取共性四阶段演进项目 → 复用 → 治理 → 产品化Harness Platform 不应该一步到位。从四个项目的实践经验看自然演进路径是四个阶段┌──────────────────────────────────────────────────────────────────────┐ │ Harness Platform 演进路径 │ ├──────────────────────────────────────────────────────────────────────┤ │ │ │ 阶段 1: 项目级 Harness │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ 每个项目独立建设 Eval / Trace / Safety │ │ │ │ 格式、标准、实现各不相同 │ │ │ │ 适合团队只有 1-2 个 AI 项目时 │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ 项目 2 个时开始感到重复 │ │ ▼ │ │ 阶段 2: 能力复用 │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ 提取共性统一 Eval Runner、统一 Trace 格式、 │ │ │ │ 统一工具分级标准 │ │ │ │ 各项目仍然独立运行但共享基础组件 │ │ │ │ 适合团队有 3-5 个 AI 项目时 │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ 项目 5 个时需要统一治理 │ │ ▼ │ │ 阶段 3: 统一治理 │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ 统一评测标准、统一安全基线、统一变更流程 │ │ │ │ 跨项目质量可比较、跨项目安全可审计 │ │ │ │ 适合AI 能力成为团队基础设施时 │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ 需要对外提供能力时 │ │ ▼ │ │ 阶段 4: 平台产品化 │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ Harness 能力作为服务提供给其他团队 │ │ │ │ 自助接入、标准化配置、文档完善 │ │ │ │ 适合组织级 AI 平台建设 │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ 我们四个项目目前处于阶段 1 → 阶段 2 过渡期 │ └──────────────────────────────────────────────────────────────────────┘什么进平台什么留场景平台化最容易犯的错把所有东西都往平台里塞。结果平台变重、场景被束缚。进平台的标准3 个以上项目都需要 实现方式可标准化 跨项目共性高 跨项目共性低 ────────── ────────── 实现可标准化 进平台 按需封装 ──── ──── Eval Runner 具体评测用例 Trace 格式 具体 Trace 节点定义 工具分级框架 具体工具实现 安全基线 角色权限矩阵 实现强依赖场景 提供接口 留场景 ──── ──── HITL 框架 接管决策逻辑 版本管理规范 具体版本策略 线上回收管道 具体回收规则具体到四个项目进平台阶段 2 优先沉淀 留场景 ──────────────────────── ──────────────────────── 统一 Eval Runner 各项目的 case 设计 - 输入case 目录 评估脚本目录 - activity-dev: Lua code case - 输出通过率 波动率 对比基线 - AIReview: 代码片段 规则匹配 - 触发变更 / 定时 / 手动 - 配置表: JSON 配表 风险判定 统一 Trace 格式 各项目的 Trace 节点 - 固定字段task_id, step, tool, - activity-dev: Developer/Reviewer input, output, duration, status 角色交替的循环 Trace - 扩展字段项目自定义 - Crashsight: 历史相似匹配 Trace 统一工具分级标准 各项目的工具实现 - L1/L2/L3 分级定义 - activity-dev: pytest, grep, dry_run - 每级的校验/确认/审计要求 - AIReview: SH/DC 检查脚本 统一安全基线 各项目的权限矩阵 - 循环上限必须设 - activity-dev: Developer/Reviewer/ - 写操作必须有范围约束 Controller 三角色 - 高风险动作必须人工确认 - 配置表: 高/中/低三级接管最小 Harness Platform 架构┌──────────────────────────────────────────────────────────────────────┐ │ 最小 Harness Platform │ ├──────────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ Eval Service │ │ │ │ 统一 Runner 基线管理 回归报告 线上回收接口 │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ Trace Service │ │ │ │ 统一格式 存储 查询 版本对比 │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ Safety Baseline │ │ │ │ 工具分级注册 权限校验 循环限制 审计日志 │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ Version Registry │ │ │ │ 模型版本 Prompt 版本 知识版本 工具版本 → 统一快照 │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ HITL Gateway │ │ │ │ 接管触发条件注册 交接信息模板 通知 审批流 │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │ ├──────────────────────────────────────────────────────────────────────┤ │ │ │ 各项目通过配置接入不需要改代码 │ │ │ │ activity-dev-harness: │ │ eval: { case_dir: cases/, check_dir: checks/, trigger: on_ │ │ change } │ │ safety: { max_rounds: 3, write_whitelist: [combat/, src/] } │ │ │ │ AIReview: │ │ eval: { case_dir: test_cases/, check_dir: rules/, │ │ trigger: daily } │ │ safety: { max_rounds: 1, write_whitelist: [] } │ │ │ └──────────────────────────────────────────────────────────────────────┘平台化的 ROI到底省了什么没有平台时4 个项目各自建设 投入 activity AIReview 配置表 Crash 总计 -dev ──────────────── ──────── ──────── ────── ───── ────── Eval Runner 开发 5 天 4 天 3 天 3 天 15 天 Trace 方案设计实现 3 天 2 天 2 天 1 天 8 天 工具分级安全基线 3 天 2 天 2 天 0 天 7 天 版本管理方案 2 天 1 天 1 天 0 天 4 天 HITL 接管机制 2 天 1 天 1 天 0 天 4 天 ──────────────────────────────────────────────────────────────────────────── 总计 15 天 10 天 9 天 4 天 38 天 有平台后平台 4 个项目接入 投入 平台 各项目接入×4 总计 ──────────────── ────── ──────────────── ────── Eval Service 8 天 1 天 × 4 4 天 12 天 Trace Service 5 天 0.5 天 × 4 2 天 7 天 Safety Baseline 3 天 0.5 天 × 4 2 天 5 天 Version Registry 2 天 0.5 天 × 4 2 天 4 天 HITL Gateway 2 天 0.5 天 × 4 2 天 4 天 ────────────────────────────────────────────────────────────────────────── 总计 20 天 12 天 32 天 节省38 天 → 32 天-16% 但真正的价值不在时间而在 1. 格式统一 → 跨项目质量可比较 2. 安全基线统一 → 新项目自动继承最佳实践 3. 变更追溯统一 → 出问题时可跨项目归因 4. 第 5 个项目接入成本2.5 天不是 10 天平台化的陷阱陷阱 症状 怎么避免 ────────────── ──────────────────── ──────────────────── 过早平台化 只有 1 个项目就开始 等到 3 个项目都需要时 建通用 Eval 平台 再提取共性 过度抽象 平台配置比写代码还复杂 先硬编码再配置化 接入成本高于自己实现 保持配置 5 分钟可接入 忽视场景差异 强制所有项目用同一套 平台提供骨架 评测标准和安全规则 场景提供血肉 平台与场景耦合 改平台要同时改 4 个项目 平台接口稳定 场景通过配置接入从四个项目到一个平台的执行路径Month 1: 统一 Trace 格式成本最低、价值最快显现 所有项目的 Trace 都用同一套 JSON schema Month 2: 提取 Eval Runner最多项目需要 统一接口case_dir check_dir → 通过率 对比报告 Month 3: 统一安全基线 所有新项目自动继承循环上限 写操作白名单 L3 人工确认 Month 4: Version Registry HITL Gateway 跨项目变更可追溯 统一接管入口 Month 5: 平台完善 新项目自助接入Harness Platform 的核心判断平台化不是再做一个大系统而是把四个项目反复踩的坑沉淀成铺好的路。平台该做的是降低重复建设成本 提升治理一致性不该做的是统一所有细节 替代场景判断。Harness 从项目到平台的演进不是设计出来的是在真实项目里长出来的——先跑通、再复用、再标准化、最后才产品化。