ECC Harness Audit基于确定性脚本的 Agent Harness 仓库体检与优先级评分实战指南【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC导读本指南围绕 ECCEverything Claude Code仓库内置的/harness-audit命令展开讲解如何用一个确定性审计引擎对Agent 工作台Harness仓库进行体检得到结构化的分数卡、失败检查项与 Top 3 修复建议。读者将掌握该命令的 5 种审计范围scope、text/json 两种输出契约、12 个固定评分维度的判定条件以及 ECC 仓库在自审计与消费方项目审计两种模式下的源码级原理可直接用于评估自己的 Agent 工程化仓库健康度。一、它是什么一次确定性的 Agent Harness 体检在 ECC 这类以 Agent 能力skills、commands、agents、hooks、记忆、评估、安全为核心资产的仓库中配置是否完整、能力是否成体系很难用肉眼判断。harness-audit命令解决的正是这个问题不依赖模型主观打分而是通过逐条检查显式文件与规则输出可复现的评分结果。该命令的完整命令文档位于 .opencode/commands/harness-audit.md其在命令体系中的主入口文档位于 commands/harness-audit.md两者内容保持一致这也正是审计引擎内部tool-command-parity检查项所要求的状态多运行时的命令文档必须对齐。它有三个典型应用场景仓库自检对 ECC 仓库本身做持续健康度评估防止 hooks、skills、质量门禁等资产悄悄退化消费方项目体检对使用 ECC 插件的下游项目consumer project做适配度检查判断其是否把 harness 信号.claude/配置、CI、测试、记忆文件等接齐作为优化闭环的基线信号配合 agents/harness-optimizer.md 中的 harness 优化 Agent先出基线分改完配置后重跑验证形成基线 → 改动 → 回归 → 复评的闭环。二、命令用法与审计范围2.1 基本调用命令文档给出的调用形态如下/harness-audit [scope] [--format text|json] [--root path]在脚本层则始终通过同一确定性引擎执行node scripts/harness-audit.js scope --format text|json [--root path]参数含义依据命令文档与 scripts/harness-audit.js 中的parseArgs实现参数可选值默认值说明scoperepo、hooks、skills、commands、agentsrepo审计范围。位置参数与--scope两种写法等价例如node scripts/harness-audit.js hooks等同于--scope hooks--formattext、jsontext输出格式。text面向人读的分数摘要json面向自动化消费的完整报告--root任意绝对/相对路径当前工作目录或环境变量AUDIT_ROOT指定要审计的目录而非默认的当前目录实现细节上参数解析支持--formatjson、--scopehooks、--rootpath的等号写法见 scripts/harness-audit.js非法参数会直接报错退出。五种 scope 的值校验位于normalizeScopescripts/harness-audit.js传入repo以外的非法值会抛出Invalid scope: xxx--format仅接受text|json。2.2 不同 scope 审计什么审计脚本会在构建报告后按check.scopes.includes(scope)过滤检查项scripts/harness-audit.js因此repo全量检查覆盖下面前 7 个常驻维度 GitHub 集成 触发的部署平台维度hooks只审计与 hooks 相关的检查项hook 配置文件、scripts/hooks/实现数量、记忆持久化 hooks、会话启停脚本、安全护栏 hook 等skills只审计 skill 类资产战略压缩、持续学习、eval-harness、安全审查、成本感知等 skill 是否存在commands只审计命令类资产模型路由、checkpoint、安全扫描、命令文档对账等agents只审计 Agent 定义资产。测试用例也验证了这一点scope filtering changes max score and check list断言hooksscope 下所有检查项的 path 都包含hooks或scripts/hooks见 tests/scripts/harness-audit.test.js。三、确定性引擎与 12 个固定评分维度3.1 脚本即事实源的设计原则命令文档明确了两条硬约束脚本是评分的唯一事实源source of truthnode scripts/harness-audit.js必须始终被实际运行禁止人工臆造额外维度或临时加分项当前 Rubric 版本号为2026-05-19该常量硬编码于脚本中scripts/harness-audit.js并在 JSON 报告中以rubric_version字段回显。测试json output is deterministic between runs验证了同一目录下两次运行输出完全一致tests/scripts/harness-audit.test.js这正是同一 commit 结果可复现的设计目标。3.2 12 个评分类别及其激活条件脚本内置固定的 12 个类别见CATEGORIES数组scripts/harness-audit.js每个类别得分被归一化到0-10#类别是否常驻激活/检测条件1Tool Coverage常驻始终计分2Context Efficiency常驻始终计分3Quality Gates常驻始终计分4Memory Persistence常驻始终计分5Eval Coverage常驻始终计分6Security Guardrails常驻始终计分7Cost Efficiency常驻始终计分8GitHub Integration常驻repo scope始终计分9Vercel Integration条件触发检测到vercel.json或.vercel/10Netlify Integration条件触发检测到netlify.toml或.netlify/11Cloudflare Integration条件触发检测到wrangler.toml或wrangler.jsonc12Fly Integration条件触发检测到fly.toml前 8 项部署平台除外在 ECC 仓库与消费方项目中均被审计而 4 个部署平台类别由一组检测器决定是否计入总分。检测器定义在脚本的PROVIDERS常量中scripts/harness-audit.js例如 Vercel 的检测逻辑是vercel.json存在、或.vercel/project.json存在、或.vercel/目录存在三者满足其一即激活。这一点在命令文档中有专门提醒max_score满分取决于哪些类别适用于当前目标永远不要假设固定总分。测试用例max_score reflects only applicable categories直接构造了带 vercel.json 的项目满分高于不带的项目的对比来锁定该行为tests/scripts/harness-audit.test.js。四、双模式检测审计 ECC 仓库还是消费方项目审计脚本默认对当前工作目录操作并会自动判定目标属于哪种模式detectTargetModescripts/harness-audit.jsrepo 模式当目标目录的package.json中name everything-claude-code或同时具备scripts/harness-audit.js、.claude-plugin/plugin.json、agents/、skills/等结构特征时判定为 ECC 仓库本身采用getRepoChecks的检查集consumer 模式其余情况判定为消费方项目采用getConsumerChecks的检查集重点验证项目是否把 ECC 的 harness 信号接齐。两种模式下的检查项结构完全一致{ id, category, points, scopes, path, description, pass, fix }即每个检查项都携带精确文件路径path与失败时的修复建议fix失败检查项的fix会被汇总进top_actions。4.1 repo 模式的核心检查项节选repo 模式的检查项由getRepoChecks构造scripts/harness-audit.js横跨 8 个维度例如Tool Coveragehooks/hooks.json是否存在scripts/hooks/下至少 8 个 hook 实现脚本.jsagents/下至少 10 个 Agent 定义skills/下至少 20 个SKILL.md主命令文档与 OpenCode 命令文档是否逐字对齐tool-command-parity要求两个文件文本完全一致Context Efficiency是否具备 skills/strategic-compact/SKILL.md 战略压缩技能、scripts/hooks/suggest-compact.js提示压缩自动化 hook、commands/model-route.md 模型路由命令、docs/token-optimization.md token 优化文档Quality Gates是否存在统一测试入口 tests/run-all.jspackage.json的test脚本是否在跑测试前先执行validate-commands.js校验链hook 测试文件与安装漂移诊断脚本scripts/doctor.js是否存在Memory Persistencehooks/memory-persistence/记忆持久化 hook 目录、scripts/hooks/session-start.js与会话启停脚本、skills/continuous-learning-v2/SKILL.md 持续学习技能Eval Coverageskills/eval-harness/SKILL.md 与 skills/verification-loop/SKILL.md、commands/checkpoint.md 检查点命令、tests/下至少 10 个.test.js文件Security Guardrailsskills/security-review/SKILL.md、agents/security-reviewer.md 安全审查 Agent、hooks/hooks.json是否引用beforeSubmitPrompt/PreToolUse守卫事件、commands/security-scan.md 安全扫描命令Cost Efficiencyskills/cost-aware-llm-pipeline/SKILL.md 成本感知 LLM 技能、token 优化文档与模型路由命令。4.2 consumer 模式的检查项consumer 模式getConsumerChecksscripts/harness-audit.js面向使用 ECC 的项目例如Tool CoverageECC 插件是否已为当前用户/项目安装会扫描~/.claude/plugins/下 manifest、flat layout、marketplace cache 三种安装布局见findPluginInstall.claude/下是否存在项目级 overrideContext Efficiency是否提供AGENTS.md/CLAUDE.md作为项目指令上下文是否存在.mcp.json或.claude/settings.json声明本地工具配置Quality Gates是否有test脚本或已入库的测试是否有.github/workflows/CIMemory Persistence是否入库持久化记忆.claude/memory.md或docs/adr/架构决策记录Security Guardrails是否提供SECURITY.md或依赖/代码扫描配置.gitignore是否忽略.env类密钥文件项目级 hook 设置是否引用工具/提示守卫。4.3 GitHub 集成与部署平台检查GitHub Integration 被刻意设计为 repo 级代码注释说明了原因hooks/skills/commands/agents 等受限 scope 只应报告其自身表面。buildGithubChecksscripts/harness-audit.js检查 CI workflow 是否入库、PR 模板、Issue 模板、CODEOWNERS 与依赖自动更新Dependabot/Renovate 任一配置均可五项。部署平台类别的单类检查由buildProviderChecks统一生成scripts/harness-audit.js每个平台 4 个检查项部署配置是否入库如vercel.jsonpackage.jsonscripts 是否引用该平台 CLI.env.example/.env.sample是否记录了该平台环境变量键.github/workflows/中是否存在使用该平台 action/CLI 的 workflow。测试用例分别用netlify.toml、wrangler.toml、fly.toml验证了三个平台的类别激活tests/scripts/harness-audit.test.js。五、评分算法与输出契约5.1 分数是怎么算出来的buildReportscripts/harness-audit.js的计算流程为先按目标模式取出对应检查集再按 scope 过滤summarizeCategoryScores对每个类别把通过项的 points 求和earned除以该类别的最大 pointsmaxMath.round归一化为0-10scripts/harness-audit.jsoverall_score为所有通过检查项 points 之和max_score为所有适用检查项 points 之和即得分与满分都是点数制因此命令文档明确要求返回时给出overall_score与max_score并说明不能假定固定满分失败检查项按 points 降序排列取前 3 生成top_actions。5.2 输出契约Output Contract命令文档要求审计结果按以下契约返回overall_score得分与max_score满分满分随适用类别浮动applicable_categories[]与category_count描述哪些类别实际贡献了总分各类别得分与具体发现findings失败检查项及其精确文件路径由确定性输出导出的Top 3 行动建议top_actions下一步应建议应用的 ECC skills。配套的 Checklist 强调了三条纪律直接使用脚本输出、禁止人工重算分请求json时原样返回脚本 JSON请求text时摘要失败项与 top actions且必须保留checks[]与top_actions[]中的精确路径。六、text 与 json 两种输出实测命令文档给出了一个示例文本输出Harness Audit (repo, repo): 71/80 - Tool Coverage: 10/10 (10/10 pts) - Context Efficiency: 9/10 (9/10 pts) - Quality Gates: 10/10 (10/10 pts) - GitHub Integration: 2/10 (2/10 pts) Top 3 Actions: 1) [GitHub Integration] Add at least one workflow under .github/workflows/. (.github/workflows/) 2) [Security Guardrails] Add prompt/tool preflight security guards in hooks/hooks.json. (hooks/hooks.json) 3) [Eval Coverage] Increase automated test coverage across scripts/hooks/lib. (tests/)该格式由printText生成scripts/harness-audit.js首行输出(scope, target_mode)与得分/满分随后逐行列出适用类别的归一化分数与点数再输出总检查数/失败数与 Top 3 Actions。在本文撰写时对本仓库实际执行node scripts/harness-audit.js repo得到Harness Audit (repo, repo): 80/80 - Tool Coverage: 10/10 (10/10 pts) - Context Efficiency: 10/10 (10/10 pts) - Quality Gates: 10/10 (10/10 pts) - Memory Persistence: 10/10 (10/10 pts) - Eval Coverage: 10/10 (10/10 pts) - Security Guardrails: 10/10 (10/10 pts) - Cost Efficiency: 10/10 (10/10 pts) - GitHub Integration: 10/10 (10/10 pts) Checks: 31 total, 0 failingJSON 输出--format json则在根对象中回显deterministic: true、rubric_version: 2026-05-19、overall_score: 80、max_score: 80并给出categories含未激活部署平台的score/max均为 0 的占位、applicable_categories本次为 8 项、category_count: 8、逐条checks[]与top_actions[]。注意未激活类别的max: 0表示不计入总分这与文档永远不要假定固定满分的约定是一致的。七、从审计到优化harness-optimizer 的闭环用法harness-audit单独使用得到的是体检报告真正发挥价值需要把它接入改进循环。agents/harness-optimizer.md 展示的标准工作流为Understandnode scripts/harness-audit.js repo --format json输出作为 Code-Based Grader 的基线信号Execute仅对 harness 配置表面hooks、agents、skills、commands 元数据、settings做最小可逆改动禁止改写产品代码改动前先快照以便精确回滚Verify改动后重跑node scripts/harness-audit.js repo --format json与node tests/run-all.js做回归评估——任一失败则自动还原快照绝不交付半成品改动按 eval-harness 的三类 GraderCode-Based / Model-Based / Human打分安全敏感改动保持BLOCKED直至人工批准。该 Agent 的角色定义还强调子代理不能直接调用/harness-audit这类斜杠命令必须运行其底层脚本node scripts/harness-audit.js。这也解释了为什么命令文档把脚本即事实源作为最高原则——审计能力应当能被任意 Agent 以可编程方式调用。八、测试保障审计引擎自身的可靠性审计脚本自带一套独立于 CLI 行为的测试集 tests/scripts/harness-audit.test.js它既是对命令行为的契约锁定也是读者理解引擎内部逻辑的最佳素材。其中覆盖的关键性质包括参数解析--help/-h、空格与等号两种参数写法等价、非法 scope/format 抛错Invalid scope/Invalid format、未知参数报Unknown argument确定性相同目录连续两次 JSON 输出逐字节一致分数边界overall_score不越界、类别含 8 个常驻维度、applicable_categories与category_count一致、且max 0才计为 applicable结构探测非 git 目录不崩溃、以非标准package.json名称但具备结构特征时仍识别为 repo 模式、消费方空项目稳定得到overall_score: 0与 3 条 top actions安装探测能识别installed_plugins.jsonmanifest、project 级plugins/marketplaces、用户级cache目录等多种 Claude 插件安装布局且 cache 多版本场景下选取最新版本通过compareVersionDesc排序。运行整套测试可执行node tests/scripts/harness-audit.test.js它与仓库全局质量门禁 tests/run-all.js 相配合确保审计工具本身先通过回归再去审计别人。九、在自有仓库中使用的最小行动清单结合命令文档 Checklist 与脚本实现在任意仓库中落地这套审计的最小步骤为确认运行环境仓库已内置 Node.js 运行环境与审计脚本消费方项目可借助 ECC 插件安装机制获得同样的脚本先跑 repo 全量在仓库根目录执行node scripts/harness-audit.js repo拿到基线分数、失败项精确路径与 Top 3 Actions按失败项定点修复每个checks[]都自带path与fix文案按路径补文件/配置即可若在 Agent 会话中消费直接读top_actions[]转成任务自动化时用 JSONCI 或 Agent 流程中固定--format json解析overall_score/max_score/top_actions避免人工二次判分针对性分项审计只关心 hook 时用scope hooks只关心技能资产用scope skills减少噪音纳入回归门禁把审计命令与tests/run-all.js一起作为改动后的回归信号参考 agents/harness-optimizer.md 的闭环任一失败即回滚保持工作区干净。十、总结harness-audit的设计精髓在于把Agent 工作台健康度从主观印象变成可编程、可复现、可回归的确定性度量12 个固定类别、8 个常驻维度、部署平台按 marker 条件触发、repo/consumer 双模式自适应、每条检查都携带精确路径与修复建议。对于 ECC 仓库本身它是维持 hooks/hooks.json、agents/、skills/、commands/等大量资产不腐化的持续体检仪对于使用 ECC 的下游项目它则是判断harness 信号是否接齐的适配度仪表盘。开发者既可以把它当作一次性体检工具也可以把它接入像 agents/harness-optimizer.md 那样的迭代优化循环让每一次 harness 改动都有基线分数与回归验证兜底。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ECC Harness Audit：基于确定性脚本的 Agent Harness 仓库体检与优先级评分实战指南
ECC Harness Audit基于确定性脚本的 Agent Harness 仓库体检与优先级评分实战指南【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC导读本指南围绕 ECCEverything Claude Code仓库内置的/harness-audit命令展开讲解如何用一个确定性审计引擎对Agent 工作台Harness仓库进行体检得到结构化的分数卡、失败检查项与 Top 3 修复建议。读者将掌握该命令的 5 种审计范围scope、text/json 两种输出契约、12 个固定评分维度的判定条件以及 ECC 仓库在自审计与消费方项目审计两种模式下的源码级原理可直接用于评估自己的 Agent 工程化仓库健康度。一、它是什么一次确定性的 Agent Harness 体检在 ECC 这类以 Agent 能力skills、commands、agents、hooks、记忆、评估、安全为核心资产的仓库中配置是否完整、能力是否成体系很难用肉眼判断。harness-audit命令解决的正是这个问题不依赖模型主观打分而是通过逐条检查显式文件与规则输出可复现的评分结果。该命令的完整命令文档位于 .opencode/commands/harness-audit.md其在命令体系中的主入口文档位于 commands/harness-audit.md两者内容保持一致这也正是审计引擎内部tool-command-parity检查项所要求的状态多运行时的命令文档必须对齐。它有三个典型应用场景仓库自检对 ECC 仓库本身做持续健康度评估防止 hooks、skills、质量门禁等资产悄悄退化消费方项目体检对使用 ECC 插件的下游项目consumer project做适配度检查判断其是否把 harness 信号.claude/配置、CI、测试、记忆文件等接齐作为优化闭环的基线信号配合 agents/harness-optimizer.md 中的 harness 优化 Agent先出基线分改完配置后重跑验证形成基线 → 改动 → 回归 → 复评的闭环。二、命令用法与审计范围2.1 基本调用命令文档给出的调用形态如下/harness-audit [scope] [--format text|json] [--root path]在脚本层则始终通过同一确定性引擎执行node scripts/harness-audit.js scope --format text|json [--root path]参数含义依据命令文档与 scripts/harness-audit.js 中的parseArgs实现参数可选值默认值说明scoperepo、hooks、skills、commands、agentsrepo审计范围。位置参数与--scope两种写法等价例如node scripts/harness-audit.js hooks等同于--scope hooks--formattext、jsontext输出格式。text面向人读的分数摘要json面向自动化消费的完整报告--root任意绝对/相对路径当前工作目录或环境变量AUDIT_ROOT指定要审计的目录而非默认的当前目录实现细节上参数解析支持--formatjson、--scopehooks、--rootpath的等号写法见 scripts/harness-audit.js非法参数会直接报错退出。五种 scope 的值校验位于normalizeScopescripts/harness-audit.js传入repo以外的非法值会抛出Invalid scope: xxx--format仅接受text|json。2.2 不同 scope 审计什么审计脚本会在构建报告后按check.scopes.includes(scope)过滤检查项scripts/harness-audit.js因此repo全量检查覆盖下面前 7 个常驻维度 GitHub 集成 触发的部署平台维度hooks只审计与 hooks 相关的检查项hook 配置文件、scripts/hooks/实现数量、记忆持久化 hooks、会话启停脚本、安全护栏 hook 等skills只审计 skill 类资产战略压缩、持续学习、eval-harness、安全审查、成本感知等 skill 是否存在commands只审计命令类资产模型路由、checkpoint、安全扫描、命令文档对账等agents只审计 Agent 定义资产。测试用例也验证了这一点scope filtering changes max score and check list断言hooksscope 下所有检查项的 path 都包含hooks或scripts/hooks见 tests/scripts/harness-audit.test.js。三、确定性引擎与 12 个固定评分维度3.1 脚本即事实源的设计原则命令文档明确了两条硬约束脚本是评分的唯一事实源source of truthnode scripts/harness-audit.js必须始终被实际运行禁止人工臆造额外维度或临时加分项当前 Rubric 版本号为2026-05-19该常量硬编码于脚本中scripts/harness-audit.js并在 JSON 报告中以rubric_version字段回显。测试json output is deterministic between runs验证了同一目录下两次运行输出完全一致tests/scripts/harness-audit.test.js这正是同一 commit 结果可复现的设计目标。3.2 12 个评分类别及其激活条件脚本内置固定的 12 个类别见CATEGORIES数组scripts/harness-audit.js每个类别得分被归一化到0-10#类别是否常驻激活/检测条件1Tool Coverage常驻始终计分2Context Efficiency常驻始终计分3Quality Gates常驻始终计分4Memory Persistence常驻始终计分5Eval Coverage常驻始终计分6Security Guardrails常驻始终计分7Cost Efficiency常驻始终计分8GitHub Integration常驻repo scope始终计分9Vercel Integration条件触发检测到vercel.json或.vercel/10Netlify Integration条件触发检测到netlify.toml或.netlify/11Cloudflare Integration条件触发检测到wrangler.toml或wrangler.jsonc12Fly Integration条件触发检测到fly.toml前 8 项部署平台除外在 ECC 仓库与消费方项目中均被审计而 4 个部署平台类别由一组检测器决定是否计入总分。检测器定义在脚本的PROVIDERS常量中scripts/harness-audit.js例如 Vercel 的检测逻辑是vercel.json存在、或.vercel/project.json存在、或.vercel/目录存在三者满足其一即激活。这一点在命令文档中有专门提醒max_score满分取决于哪些类别适用于当前目标永远不要假设固定总分。测试用例max_score reflects only applicable categories直接构造了带 vercel.json 的项目满分高于不带的项目的对比来锁定该行为tests/scripts/harness-audit.test.js。四、双模式检测审计 ECC 仓库还是消费方项目审计脚本默认对当前工作目录操作并会自动判定目标属于哪种模式detectTargetModescripts/harness-audit.jsrepo 模式当目标目录的package.json中name everything-claude-code或同时具备scripts/harness-audit.js、.claude-plugin/plugin.json、agents/、skills/等结构特征时判定为 ECC 仓库本身采用getRepoChecks的检查集consumer 模式其余情况判定为消费方项目采用getConsumerChecks的检查集重点验证项目是否把 ECC 的 harness 信号接齐。两种模式下的检查项结构完全一致{ id, category, points, scopes, path, description, pass, fix }即每个检查项都携带精确文件路径path与失败时的修复建议fix失败检查项的fix会被汇总进top_actions。4.1 repo 模式的核心检查项节选repo 模式的检查项由getRepoChecks构造scripts/harness-audit.js横跨 8 个维度例如Tool Coveragehooks/hooks.json是否存在scripts/hooks/下至少 8 个 hook 实现脚本.jsagents/下至少 10 个 Agent 定义skills/下至少 20 个SKILL.md主命令文档与 OpenCode 命令文档是否逐字对齐tool-command-parity要求两个文件文本完全一致Context Efficiency是否具备 skills/strategic-compact/SKILL.md 战略压缩技能、scripts/hooks/suggest-compact.js提示压缩自动化 hook、commands/model-route.md 模型路由命令、docs/token-optimization.md token 优化文档Quality Gates是否存在统一测试入口 tests/run-all.jspackage.json的test脚本是否在跑测试前先执行validate-commands.js校验链hook 测试文件与安装漂移诊断脚本scripts/doctor.js是否存在Memory Persistencehooks/memory-persistence/记忆持久化 hook 目录、scripts/hooks/session-start.js与会话启停脚本、skills/continuous-learning-v2/SKILL.md 持续学习技能Eval Coverageskills/eval-harness/SKILL.md 与 skills/verification-loop/SKILL.md、commands/checkpoint.md 检查点命令、tests/下至少 10 个.test.js文件Security Guardrailsskills/security-review/SKILL.md、agents/security-reviewer.md 安全审查 Agent、hooks/hooks.json是否引用beforeSubmitPrompt/PreToolUse守卫事件、commands/security-scan.md 安全扫描命令Cost Efficiencyskills/cost-aware-llm-pipeline/SKILL.md 成本感知 LLM 技能、token 优化文档与模型路由命令。4.2 consumer 模式的检查项consumer 模式getConsumerChecksscripts/harness-audit.js面向使用 ECC 的项目例如Tool CoverageECC 插件是否已为当前用户/项目安装会扫描~/.claude/plugins/下 manifest、flat layout、marketplace cache 三种安装布局见findPluginInstall.claude/下是否存在项目级 overrideContext Efficiency是否提供AGENTS.md/CLAUDE.md作为项目指令上下文是否存在.mcp.json或.claude/settings.json声明本地工具配置Quality Gates是否有test脚本或已入库的测试是否有.github/workflows/CIMemory Persistence是否入库持久化记忆.claude/memory.md或docs/adr/架构决策记录Security Guardrails是否提供SECURITY.md或依赖/代码扫描配置.gitignore是否忽略.env类密钥文件项目级 hook 设置是否引用工具/提示守卫。4.3 GitHub 集成与部署平台检查GitHub Integration 被刻意设计为 repo 级代码注释说明了原因hooks/skills/commands/agents 等受限 scope 只应报告其自身表面。buildGithubChecksscripts/harness-audit.js检查 CI workflow 是否入库、PR 模板、Issue 模板、CODEOWNERS 与依赖自动更新Dependabot/Renovate 任一配置均可五项。部署平台类别的单类检查由buildProviderChecks统一生成scripts/harness-audit.js每个平台 4 个检查项部署配置是否入库如vercel.jsonpackage.jsonscripts 是否引用该平台 CLI.env.example/.env.sample是否记录了该平台环境变量键.github/workflows/中是否存在使用该平台 action/CLI 的 workflow。测试用例分别用netlify.toml、wrangler.toml、fly.toml验证了三个平台的类别激活tests/scripts/harness-audit.test.js。五、评分算法与输出契约5.1 分数是怎么算出来的buildReportscripts/harness-audit.js的计算流程为先按目标模式取出对应检查集再按 scope 过滤summarizeCategoryScores对每个类别把通过项的 points 求和earned除以该类别的最大 pointsmaxMath.round归一化为0-10scripts/harness-audit.jsoverall_score为所有通过检查项 points 之和max_score为所有适用检查项 points 之和即得分与满分都是点数制因此命令文档明确要求返回时给出overall_score与max_score并说明不能假定固定满分失败检查项按 points 降序排列取前 3 生成top_actions。5.2 输出契约Output Contract命令文档要求审计结果按以下契约返回overall_score得分与max_score满分满分随适用类别浮动applicable_categories[]与category_count描述哪些类别实际贡献了总分各类别得分与具体发现findings失败检查项及其精确文件路径由确定性输出导出的Top 3 行动建议top_actions下一步应建议应用的 ECC skills。配套的 Checklist 强调了三条纪律直接使用脚本输出、禁止人工重算分请求json时原样返回脚本 JSON请求text时摘要失败项与 top actions且必须保留checks[]与top_actions[]中的精确路径。六、text 与 json 两种输出实测命令文档给出了一个示例文本输出Harness Audit (repo, repo): 71/80 - Tool Coverage: 10/10 (10/10 pts) - Context Efficiency: 9/10 (9/10 pts) - Quality Gates: 10/10 (10/10 pts) - GitHub Integration: 2/10 (2/10 pts) Top 3 Actions: 1) [GitHub Integration] Add at least one workflow under .github/workflows/. (.github/workflows/) 2) [Security Guardrails] Add prompt/tool preflight security guards in hooks/hooks.json. (hooks/hooks.json) 3) [Eval Coverage] Increase automated test coverage across scripts/hooks/lib. (tests/)该格式由printText生成scripts/harness-audit.js首行输出(scope, target_mode)与得分/满分随后逐行列出适用类别的归一化分数与点数再输出总检查数/失败数与 Top 3 Actions。在本文撰写时对本仓库实际执行node scripts/harness-audit.js repo得到Harness Audit (repo, repo): 80/80 - Tool Coverage: 10/10 (10/10 pts) - Context Efficiency: 10/10 (10/10 pts) - Quality Gates: 10/10 (10/10 pts) - Memory Persistence: 10/10 (10/10 pts) - Eval Coverage: 10/10 (10/10 pts) - Security Guardrails: 10/10 (10/10 pts) - Cost Efficiency: 10/10 (10/10 pts) - GitHub Integration: 10/10 (10/10 pts) Checks: 31 total, 0 failingJSON 输出--format json则在根对象中回显deterministic: true、rubric_version: 2026-05-19、overall_score: 80、max_score: 80并给出categories含未激活部署平台的score/max均为 0 的占位、applicable_categories本次为 8 项、category_count: 8、逐条checks[]与top_actions[]。注意未激活类别的max: 0表示不计入总分这与文档永远不要假定固定满分的约定是一致的。七、从审计到优化harness-optimizer 的闭环用法harness-audit单独使用得到的是体检报告真正发挥价值需要把它接入改进循环。agents/harness-optimizer.md 展示的标准工作流为Understandnode scripts/harness-audit.js repo --format json输出作为 Code-Based Grader 的基线信号Execute仅对 harness 配置表面hooks、agents、skills、commands 元数据、settings做最小可逆改动禁止改写产品代码改动前先快照以便精确回滚Verify改动后重跑node scripts/harness-audit.js repo --format json与node tests/run-all.js做回归评估——任一失败则自动还原快照绝不交付半成品改动按 eval-harness 的三类 GraderCode-Based / Model-Based / Human打分安全敏感改动保持BLOCKED直至人工批准。该 Agent 的角色定义还强调子代理不能直接调用/harness-audit这类斜杠命令必须运行其底层脚本node scripts/harness-audit.js。这也解释了为什么命令文档把脚本即事实源作为最高原则——审计能力应当能被任意 Agent 以可编程方式调用。八、测试保障审计引擎自身的可靠性审计脚本自带一套独立于 CLI 行为的测试集 tests/scripts/harness-audit.test.js它既是对命令行为的契约锁定也是读者理解引擎内部逻辑的最佳素材。其中覆盖的关键性质包括参数解析--help/-h、空格与等号两种参数写法等价、非法 scope/format 抛错Invalid scope/Invalid format、未知参数报Unknown argument确定性相同目录连续两次 JSON 输出逐字节一致分数边界overall_score不越界、类别含 8 个常驻维度、applicable_categories与category_count一致、且max 0才计为 applicable结构探测非 git 目录不崩溃、以非标准package.json名称但具备结构特征时仍识别为 repo 模式、消费方空项目稳定得到overall_score: 0与 3 条 top actions安装探测能识别installed_plugins.jsonmanifest、project 级plugins/marketplaces、用户级cache目录等多种 Claude 插件安装布局且 cache 多版本场景下选取最新版本通过compareVersionDesc排序。运行整套测试可执行node tests/scripts/harness-audit.test.js它与仓库全局质量门禁 tests/run-all.js 相配合确保审计工具本身先通过回归再去审计别人。九、在自有仓库中使用的最小行动清单结合命令文档 Checklist 与脚本实现在任意仓库中落地这套审计的最小步骤为确认运行环境仓库已内置 Node.js 运行环境与审计脚本消费方项目可借助 ECC 插件安装机制获得同样的脚本先跑 repo 全量在仓库根目录执行node scripts/harness-audit.js repo拿到基线分数、失败项精确路径与 Top 3 Actions按失败项定点修复每个checks[]都自带path与fix文案按路径补文件/配置即可若在 Agent 会话中消费直接读top_actions[]转成任务自动化时用 JSONCI 或 Agent 流程中固定--format json解析overall_score/max_score/top_actions避免人工二次判分针对性分项审计只关心 hook 时用scope hooks只关心技能资产用scope skills减少噪音纳入回归门禁把审计命令与tests/run-all.js一起作为改动后的回归信号参考 agents/harness-optimizer.md 的闭环任一失败即回滚保持工作区干净。十、总结harness-audit的设计精髓在于把Agent 工作台健康度从主观印象变成可编程、可复现、可回归的确定性度量12 个固定类别、8 个常驻维度、部署平台按 marker 条件触发、repo/consumer 双模式自适应、每条检查都携带精确路径与修复建议。对于 ECC 仓库本身它是维持 hooks/hooks.json、agents/、skills/、commands/等大量资产不腐化的持续体检仪对于使用 ECC 的下游项目它则是判断harness 信号是否接齐的适配度仪表盘。开发者既可以把它当作一次性体检工具也可以把它接入像 agents/harness-optimizer.md 那样的迭代优化循环让每一次 harness 改动都有基线分数与回归验证兜底。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
