Harness Score — deterministic maturity scanner for coding-agent harnesses
Harness Score — deterministic maturity scanner for coding-agent harnesses
为什么重要
Harness Score 把一个越来越重要但容易停留在口号层的问题量化了：同一个模型在不同 repository harness 下会表现出完全不同的可靠性。它的价值不是再做一个 LLM judge，而是用零 LLM 调用、零网络访问的 deterministic filesystem checks，扫描一个 repo 的 context files、rules、skills、hooks、sensors、CI 和安全卫生，并给出 L0–L4 maturity level 与 108 分 breakdown。
这对用户特别重要，因为 Hermes / llm-wiki 的许多改进正在从“写更多规则”转向“把规则变成可检查资产”。Harness Score 提供了一个低风险路线：先不评估模型聪不聪明，而是评估 repo 是否给 agent 提供了足够上下文、反馈和 guardrails。
机制 / 一阶原理
Harness Score 的机制是：用可重复的静态/结构检查衡量 agent harness 的成熟度。
它把 coding-agent harness 拆成六个维度：
- Context & Guides：如
AGENTS.md是否实质性存在，规则是否有 scope/frontmatter。 - Skills & Commands：是否有可复用 procedure、slash commands、subagents 或 trigger-worthy skill description。
- Hooks & Guardrails：是否有预执行或运行时约束，防止危险动作只靠 prompt。
- Sensors & Feedback：是否有测试、lint、typecheck 等 agent 可调用反馈。
- CI Feedback：验证是否进入持续集成，而不只在本地自证。
- Hygiene & Safety：secret、防误删、ignore 配置、基础安全卫生。
它的 maturity ladder 体现了一个重要的一阶原理：文档不是成熟，闭环才是成熟。L1 只是 documented；L2 guided；L3 sensing；L4 self-correcting。大量文档但没有测试/CI/guardrail 不能算高级 harness。
与既有 wiki 概念的关系
- 对 Harness-Engineering：Harness Score 给出了可执行的 harness 结构体检表，补足“harness 应该长什么样”的工程化维度。
- 对 Agent-Benchmarks：它把 benchmark 对象从 agent/model 扩展到 repo harness 本身，而且是 deterministic evaluator。
- 对 AGENTS.md-Context-Files：AGENTS.md 是最低高杠杆入口，但只有和 scoped rules、skills、sensors、CI 组合后才接近成熟。
- 对 AI-Code-Review：它把 review 前移到 repo readiness，减少 agent-generated PR 进入人工 review 时才暴露系统性缺陷。
- 对 External-Agent-Skills-Design-Patterns：skills/commands 不应只是文件存在，还应触发清晰、边界明确、可维护。
对 Hermes / llm-wiki 的可执行启发
- 给 llm-wiki radar 建结构检查：每天 deep ingest 后检查 raw 是否有 sha256、source 页是否有写入记录、_index/log 是否更新、wikilinks 是否至少连接核心概念。
- 给 Hermes 项目/用户代码库引入 harness maturity preflight：在让 agent 大规模改代码前，先检查 AGENTS.md、测试命令、CI、危险目录、secret ignore、hooks。
- 将“优化建议”转成可评分项：例如“报告是否列出未入库原因”“是否记录访问失败”“是否区分 deterministic check 与 LLM synthesis”。
- 先做 deterministic，再做 LLM judge：结构缺陷不需要昂贵模型判断；LLM review 应留给语义一致性、深度和设计权衡。
- 把 maturity level 作为风险路由信号：L0/L1 repo 不应让 agent 直接做高风险自动修改；L3/L4 repo 才适合更长程自治。
失败模式 / 边界条件
- Goodhart 风险：团队可能为了得分创建空洞文件；scanner 需要 substance checks 和抽样人工/LLM review 配合。
- 静态检查看不到真实执行质量：有 CI 文件不代表测试有效，有 hooks 不代表覆盖关键危险动作。
- 工具差异：Cursor、Claude Code、Codex、Hermes 的配置形态不同，通用 scanner 可能漏掉平台特有强/弱项。
- 过早门禁：对小型早期项目要求 L4 可能降低迭代速度；成熟度应服务风险分级而非形式主义。
- README 证据限制：当前入库基于项目 README，没有在真实 repo 上运行
npx harness-score验证结果。
深度判断
本条值得 deep ingest，因为它把 Harness-Engineering 从理念推进到可执行 maturity scanner，直接能转化为 llm-wiki 自检和 coding-agent preflight。它与过去的 did-it、coder_eval、context-fails-first 形成互补：did-it 查最终声明，coder_eval 查 skill/workflow 回归，Harness Score 查 repo harness 结构成熟度。
写入记录
- 2026-07-21 09:01 CST：新增 Harness Score source 页，提炼 deterministic harness maturity scanner、六维评分和 L0–L4 成熟度对 Hermes/llm-wiki 的启发。