oh-my-claudecode 的 Harsh-Critic 基准测试结构化缺口审查与多视角评审的科学量化【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode本基准测试用于回答一个具体问题存档的harsh-critic审查提示词是否比当前标准criticAgent 能发现更多真实缺陷oh-my-claudecode 团队通过一份精心构造的对照基准来验证这一假设读者读完本指南后将掌握该基准测试测量的维度与权重逻辑、8 个测试夹具与缺陷植入方式、如何从命令行一键运行并输出 A/B 对比报告以及打分器基于关键词模糊匹配的底层实现原理。一、为什么需要一个 Harsh-Critic 基准测试1.1 背景一次 Agent 合并引发的存档化在 oh-my-claudecode 的 Agent 体系中harsh-critic曾是一款以严苛批判著称的评审 Agent。在后续的 agent consolidationAgent 整合过程中它从活跃 Agent 注册表中被移除。为保留它的能力并持续验证其价值项目将其完整提示词以快照形式归档在 benchmarks/harsh-critic/prompts/harsh-critic.md并在 benchmarks/harsh-critic 目录下围绕它构建了一整套可复现的基准测试框架。当前活跃的普通评审 Agent 提示词则位于 agents/critic.md。1.2 核心假设决定成败的不是严厉而是结构化基准测试基于 issue #1240 的 A/B 测试结论构建其核心假说是结构化输出模板才是真正起作用的成分而非对抗性adversarial的措辞风格。关键差异在于Agent 是否被要求在进行裁决之前先跨越多个视角枚举缺失的覆盖项。换句话说harsh苛刻本身并不稀缺稀缺的是**强制 Agent 主动寻找这里缺了什么**的结构化机制。harsh-critic提示词中的Whats Missing结构化输出小节与多视角调查协议正是这一结论的具体化产物。这个假说也直接决定了打分体系将missing_coverage缺失覆盖设为权重最高的指标——因为它是区分两个 Agent 的核心差异点。二、测试夹具Fixtures带已知答案的陷阱场基准测试共8 个夹具横跨3 个领域领域数量内容plans3认证迁移计划、基础设施扩容计划、API 版本化计划code3认证中间件、数据管道、限流器实现analysis2性能分析报告、安全威胁模型真实目录结构对应如下均可点击查看plansplan-auth-migration.md、plan-api-refactor.md、plan-clean-baseline.mdcodecode-payment-handler.ts、code-session-manager.ts、code-utils-clean.tsanalysisanalysis-perf-report.md、analysis-incident-review.md2.1 缺陷植入与 Ground Truth 机制每个夹具都故意嵌入了缺陷deliberately embedded flaws其已知缺口清单存放在 benchmarks/harsh-critic/ground-truth 目录8 个与夹具一一对应的 JSON 文件。打分系统据此检查每个 Agent 检出了多少 ground-truth 缺口。以 plan-auth-migration.json 为例一条 ground-truth 缺陷记录的结构如下{ id: AUTH-CRIT-1, severity: CRITICAL, category: finding, summary: Stale reference to validateSession() — function was renamed to verifySession(), keywords: [validateSession, verifySession, renamed, stale], location: Task 1, auth-service-v2 dual-write description, explanation: Task 1 states the new service will call validateSession() ... }字段含义与 scoring/types.ts 中的GroundTruthFinding类型定义一致id唯一标识如AUTH-CRIT-1、AUTH-MAJ-2、AUTH-MISS-1severity期望严重级别取CRITICAL阻断执行/MAJOR导致重大返工/MINOR次优但可用category缺陷类型取finding直接缺陷/missing缺失项/perspective特定视角才能发现的缺陷perspective当category为perspective时标注视角如security/new-hire/opskeywords该缺陷的信号关键词列表Agent 的输出须命中足够多的关键词才被判定为检出location与explanation分别用于说明缺陷位置与判定依据。2.2 干净基线Clean Baselines抗误报测试在 8 个夹具之外还有2 个干净基线一个 plan、一个 code用于检验误报抵抗力——它们构造精良、本身没有缺陷优秀的评审 Agent 应当不在这类制品上误报问题。例如 code-utils-clean.json 中isCleanBaseline: true、findings: []即该夹具的期望输出是零缺陷。误报率指标false positive rate正是由这类夹具衡量。三、打分方法七维加权与关键词模糊匹配3.1 七维复合评分每个 Agent × 夹具组合的评分为0–1 区间的复合分由 7 个维度加权而来各维度的权重与理由见下该权重表在 scoring/types.ts 的SCORING_WEIGHTS常量中定义总和为 1.0维度权重理由True positive rate25%正确识别已知缺口Missing coverage20%Agent 检出的、不在 ground truth 中但确实成立的缺口False negative rate15%遗漏的已知缺口反向指标漏检率越低越好Evidence rate10%有制品中具体证据支撑的论断占比Perspective coverage10%检视的不同视角数量安全、性能、运维等Process compliance10%Agent 是否遵循了自身的结构化协议False positive rate10%在干净基线上误报的非问题项反向指标越低越好Missing coverage 权重最高的原因在 README 中阐述得很清楚harsh-critic的多视角调查协议其设计目的正是找出只盯单一角度的评审者会漏掉的缺口。而缺失覆盖率正是两者间最关键的区分指标。3.2 复合分的计算细节在 scoring/scorer.ts 的computeComposite()中两个反向指标false negative rate、false positive rate以1 - rate的形式计入总分三枚过程合规布尔量是否做了 pre-commitment 预测、是否覆盖全部视角、是否有非空Whats Missing小节则以满足三分之二作为 process compliance 得分composite 0.25 × TP_rate 0.15 × (1 − FN_rate) 0.10 × (1 − FP_rate) 0.20 × missing_coverage 0.10 × perspective_coverage 0.10 × evidence_rate 0.10 × process_compliance_score3.3 关键词匹配的宽容而严谨之道打分采用基于关键词的模糊匹配与 ground truth 比对。每个 ground truth 条目带有关键词列表Agent 的一条发现若命中足够多的关键词即计为一次 true positive。该逻辑在 SCORING_MATCH_CALIBRATION.md 中有专门的设计说明匹配器的实现位于 scoring/scorer.ts可总结为三层文本归一化normalizeTextForMatch先做小写折叠case-fold、Unicode NFKC 归一化再把标点/分隔符折叠为空格如new-hire与new hire、processPayment():47-52与processPayment 47 52得以对齐。这解决了真实模型输出在格式上的脆弱性——该文件明确指出其目标是减少评分环节的假阴性而非掩盖模型质量回归短语回退匹配多词关键词在归一化文本上做全 token 存在检查顺序无关同时保留直接子串匹配作为快速路径动态阈值基础要求为MIN_KEYWORD_MATCHES 2在 scoring/types.ts 中定义但对于关键词集更大的条目按 40% 比例下限提升要求——例如 6 个关键词的条目要求命中 3 个而不是 2 个以防更大关键词集带来的偶然误匹配。该方法刻意不引入 embedding 语义匹配或 LLM-in-the-loop 打分以保持确定性、可审计性与关键词锚定性同时用动态阈值守住精确度底线。四、如何运行基准测试4.1 命令行用法在仓库根目录执行前置条件设置ANTHROPIC_API_KEY环境变量# 完整基准测试两个 Agent × 全部夹具 ANTHROPIC_API_KEYsk-... npx tsx benchmarks/harsh-critic/run-benchmark.ts --agent both # 只跑单个 Agent npx tsx benchmarks/harsh-critic/run-benchmark.ts --agent harsh-critic npx tsx benchmarks/harsh-critic/run-benchmark.ts --agent critic # 只跑单个夹具 npx tsx benchmarks/harsh-critic/run-benchmark.ts --agent both --fixture plan-auth-migration # 干跑校验管道但不调用 API npx tsx benchmarks/harsh-critic/run-benchmark.ts --dry-run4.2 运行器支持的参数以上参数由 run-benchmark.ts 顶部的文档注释与parseArgs()实现确认完整清单为参数可选值默认值说明--agentharsh-critic/critic/bothboth运行哪个 Agent--fixture任意夹具 id全部只运行单个夹具如plan-auth-migration--output-dir路径benchmarks/harsh-critic/results结果输出目录--modelClaude 模型名claude-opus-4-6使用的模型--dry-run—关闭只加载夹具与 ground truth跳过 API 调用4.3 运行器的内部工作流结合 run-benchmark.ts 源码一次完整运行分以下步骤执行提示词加载loadAgentPromptFromFile()会按agents/name.md→benchmarks/harsh-critic/prompts/name.md的顺序查找提示词并经由stripFrontmatter()剥离 YAML frontmatter。这意味着已被移除出活跃注册表的harsh-critic正是从归档快照加载的夹具与 ground truth 加载按plans/code/analysis三个领域目录扫描.md与.ts文件并以文件名去扩展名为夹具 id--fixture过滤即在此生效API 调用callClaude()以 system prompt 携带 Agent 提示词、user message 为Review the following work:\n\n{fixture 内容}的方式调用 Anthropic Messages APImax_tokens: 8192并对 529 / overloaded / rate / 500 类错误做指数退避重试最多 5 次退避上限 60 秒解析与打分输出经 scoring/parser.ts 解析为结构化结果再由 scoring/scorer.ts 的scoreFixture()与matchFindings()计算各项指标报告生成scoring/reporter.ts 生成 JSON 与 Markdown 双格式报告若某夹具没有 ground truth会用空的占位 ground truth 并给出警告。输出位置结果写入benchmarks/harsh-critic/results/该目录在 git 中被忽略。每次运行都会同时写出带时间戳的results_timestamp.json、report_timestamp.md以及始终指向最新一次的results.json与report.md方便脚本与人工读取。4.4 打分逻辑的单元测试无需 API Key打分器带有独立的 vitest 测试可在不调用 API 的情况下验证匹配与阈值行为。需要说明的是README 中给出的命令npx vitest run src/__tests__/benchmark-scoring与实际仓库布局并不完全一致——真实测试文件位于 benchmarks/harsh-critic/scoring/tests即 parser.test.ts 与 scorer.test.ts本目录自带的 vitest.config.ts 也以scoring/__tests__/*.test.ts为 include 规则。因此在基准目录下使用本地配置运行即可cd benchmarks/harsh-critic npx vitest run五、解读结果从逐夹具对比到关键洞察5.1 输出形态每次运行都会在终端打印汇总表每夹具 × 每 Agent 一行展示 composite / TP rate / FN rate / Missing Cov与头对头Head-to-Head汇总。若跑双 Agent还会打印聚合分数与 deltaFixtureCritic ScoreHarsh-Critic ScoreDeltaWinnerplan-auth-migration0.610.780.17harsh-critic...............5.2 指标口径Composite score0–1 区间越高越好Deltaharsh-critic 得分减去 critic 得分正值表示 harsh-critic 更优Win/Loss/Tie按夹具判定。README 将平局解释为delta 在 0.05 以内从源码看scoring/reporter.ts 的generateJsonReport()中平局判定被实现为Math.abs(delta) 0.001——两者阈值略有出入阅读报告时以代码为准Key insight报告会自动找出 delta 绝对值最大的指标。这一设计的解读逻辑值得牢记最大改进出现在哪个指标就说明哪段协议元素贡献最大——如果missing_coverage的 delta 最大说明多视角调查协议在起作用如果true_positive_rate的 delta 最大则结构化输出模板是主要驱动。5.3 打分口径细节missingCoverage计算的是命中 ground truth 的Whats Missing条目数 ÷ ground truth 中category missing的条目总数perspectiveCoverage同理按category perspective计算severityAccuracy检查命中条目的严重级评定是否准确scoring/types.ts 中ALLOW_ADJACENT_SEVERITY true即允许相邻一级的误差CRITICAL↔MAJOR、MAJOR↔MINOR 视为可接受。六、可复现性与成本6.1 为什么需要多次运行LLM 输出在不同运行间存在方差。README 给出的可复现性建议跑 3 次取平均以获得稳定的对比结论若需跨时间可复现在 run-benchmark.ts 中固定模型版本默认claude-opus-4-6可通过--model指定结果目录被 git 忽略——每次运行都产生全新输出旧结果不纳入版本跟踪打分器自身带 vitest 测试可脱离 API Key 独立验证。6.2 成本参考README 给出的量级估算实际以模型定价为准完整基准运行8 夹具 × 2 Agent × Opus约3–5 美元开发期用--fixture做单夹具定向运行约0.50–1.00 美元/夹具对。由于系统提示词更短、输出 token 更少critic的每次运行成本通常略低于harsh-critic。七、纵深Harsh-Critic 提示词的结构化设计若想真正理解这份基准在验证什么需要回到归档提示词 prompts/harsh-critic.md。它的 frontmatter 声明了身份model: claude-opus-4-6且disallowedTools: Write, Edit——只读评审者。其核心机制按阶段组织Phase 1 — Pre-commitment预先承诺在细读制品前先根据类型与领域预测最可能的 3–5 个问题区域并写下来再逐一验证——用刻意搜索激活而非被动阅读。这也是打分器hasPreCommitment布尔量与解析器中Pre-commitment Predictions小节检测的来源Phase 2 — Verification验证通读并抽取所有文件引用/函数名/API 调用/技术论断逐一阅读真实源码核实code 场景追踪执行路径与错误路径、排查 off-by-one、竞态、缺失空值检查与安全疏漏plan 场景执行六步拆解关键假设抽取与 VERIFIED/REASONABLE/FRAGILE 评级、5–7 个失败场景的 Pre-Mortem、依赖审计、歧义扫描、可行性检查、回滚分析analysis 场景寻找逻辑跳跃与把假设当事实的论断Phase 3 — Multi-perspective多视角code 以安全工程师/新员工/运维工程师视角审视plan 以执行者/利益相关方/怀疑者视角审视混合制品则两组视角并用Phase 4 — Gap analysis缺口分析显式追问What would break this?等四个问题找出缺了什么而非哪里错了Phase 4.5 — Self-Audit自审对每条 CRITICAL/MAJOR 结论做置信度评级与作者能否立即反驳是真缺陷还是风格偏好检查低置信度与可被反驳项移入 Open QuestionsPhase 4.75 — Realist Check现实校准用真实最坏情况而非理论最大“被忽略的缓解因素”“实际发现速度”“是否存在 hunting mode 偏见”四个问题压测严重级降级必须附Mitigated by:理由涉及数据丢失、安全破坏、财务影响的一律不降级Escalation — 自适应严苛度发现任一 CRITICAL、或 3 条 MAJOR、或系统性缺陷模式时从 THOROUGH 模式升级为 ADVERSARIAL 模式对剩余内容有罪推定Phase 5 — Synthesis将实际发现与 pre-commitment 预测对照产出带严重级评定的结构化裁决。其输出格式强制为VERDICT: REJECT / REVISE / ACCEPT-WITH-RESERVATIONS / ACCEPT并包含 Critical/Major/Minor Findings、Whats Missing、Ambiguity Risks、Multi-Perspective Notes、Verdict Justification、Open Questions 等小节。打分器 scoring/parser.ts 中的parseHarshCritic()正是按这套章节别名如critical findings、whats missing、multi-perspective、pre-commitment predictions做正则定位与条目抽取从而把自由文本还原成ParsedAgentOutput结构化对象——同时每条 finding 的hasEvidence由证据模式正则反引号代码段、file:line、function():line-line判定。对critic简单 OKAY/REJECT 格式parseCritic()则退化为从 Summary/Justification 中抽取条目、统一归入 MAJOR 的无章节结构路径。这种设计形成了一个闭环提示词定义协议 → 解析器按协议反解 → 打分器按协议指标验证协议是否被遵守——也就是说即便两个 Agent 检出的缺陷数相同谁更严格地执行了结构化协议谁就能在 process compliance 与 evidence 维度上得分。八、参考资料与延伸阅读基准说明benchmarks/harsh-critic/README.md归档提示词快照benchmarks/harsh-critic/prompts/harsh-critic.md现役评审 Agentagents/critic.md运行器benchmarks/harsh-critic/run-benchmark.ts类型与权重定义benchmarks/harsh-critic/scoring/types.ts打分实现benchmarks/harsh-critic/scoring/scorer.ts输出解析benchmarks/harsh-critic/scoring/parser.ts报告生成benchmarks/harsh-critic/scoring/reporter.ts匹配校准设计benchmarks/harsh-critic/SCORING_MATCH_CALIBRATION.md测试夹具与 ground truth见 benchmarks/harsh-critic/fixtures 与 benchmarks/harsh-critic/ground-truth如 plan-auth-migration.json 完整展示了 11 条跨 finding/missing/perspective 三类别的期望缺陷【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oh-my-claudecode 的 Harsh-Critic 基准测试：结构化缺口审查与多视角评审的科学量化
oh-my-claudecode 的 Harsh-Critic 基准测试结构化缺口审查与多视角评审的科学量化【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode本基准测试用于回答一个具体问题存档的harsh-critic审查提示词是否比当前标准criticAgent 能发现更多真实缺陷oh-my-claudecode 团队通过一份精心构造的对照基准来验证这一假设读者读完本指南后将掌握该基准测试测量的维度与权重逻辑、8 个测试夹具与缺陷植入方式、如何从命令行一键运行并输出 A/B 对比报告以及打分器基于关键词模糊匹配的底层实现原理。一、为什么需要一个 Harsh-Critic 基准测试1.1 背景一次 Agent 合并引发的存档化在 oh-my-claudecode 的 Agent 体系中harsh-critic曾是一款以严苛批判著称的评审 Agent。在后续的 agent consolidationAgent 整合过程中它从活跃 Agent 注册表中被移除。为保留它的能力并持续验证其价值项目将其完整提示词以快照形式归档在 benchmarks/harsh-critic/prompts/harsh-critic.md并在 benchmarks/harsh-critic 目录下围绕它构建了一整套可复现的基准测试框架。当前活跃的普通评审 Agent 提示词则位于 agents/critic.md。1.2 核心假设决定成败的不是严厉而是结构化基准测试基于 issue #1240 的 A/B 测试结论构建其核心假说是结构化输出模板才是真正起作用的成分而非对抗性adversarial的措辞风格。关键差异在于Agent 是否被要求在进行裁决之前先跨越多个视角枚举缺失的覆盖项。换句话说harsh苛刻本身并不稀缺稀缺的是**强制 Agent 主动寻找这里缺了什么**的结构化机制。harsh-critic提示词中的Whats Missing结构化输出小节与多视角调查协议正是这一结论的具体化产物。这个假说也直接决定了打分体系将missing_coverage缺失覆盖设为权重最高的指标——因为它是区分两个 Agent 的核心差异点。二、测试夹具Fixtures带已知答案的陷阱场基准测试共8 个夹具横跨3 个领域领域数量内容plans3认证迁移计划、基础设施扩容计划、API 版本化计划code3认证中间件、数据管道、限流器实现analysis2性能分析报告、安全威胁模型真实目录结构对应如下均可点击查看plansplan-auth-migration.md、plan-api-refactor.md、plan-clean-baseline.mdcodecode-payment-handler.ts、code-session-manager.ts、code-utils-clean.tsanalysisanalysis-perf-report.md、analysis-incident-review.md2.1 缺陷植入与 Ground Truth 机制每个夹具都故意嵌入了缺陷deliberately embedded flaws其已知缺口清单存放在 benchmarks/harsh-critic/ground-truth 目录8 个与夹具一一对应的 JSON 文件。打分系统据此检查每个 Agent 检出了多少 ground-truth 缺口。以 plan-auth-migration.json 为例一条 ground-truth 缺陷记录的结构如下{ id: AUTH-CRIT-1, severity: CRITICAL, category: finding, summary: Stale reference to validateSession() — function was renamed to verifySession(), keywords: [validateSession, verifySession, renamed, stale], location: Task 1, auth-service-v2 dual-write description, explanation: Task 1 states the new service will call validateSession() ... }字段含义与 scoring/types.ts 中的GroundTruthFinding类型定义一致id唯一标识如AUTH-CRIT-1、AUTH-MAJ-2、AUTH-MISS-1severity期望严重级别取CRITICAL阻断执行/MAJOR导致重大返工/MINOR次优但可用category缺陷类型取finding直接缺陷/missing缺失项/perspective特定视角才能发现的缺陷perspective当category为perspective时标注视角如security/new-hire/opskeywords该缺陷的信号关键词列表Agent 的输出须命中足够多的关键词才被判定为检出location与explanation分别用于说明缺陷位置与判定依据。2.2 干净基线Clean Baselines抗误报测试在 8 个夹具之外还有2 个干净基线一个 plan、一个 code用于检验误报抵抗力——它们构造精良、本身没有缺陷优秀的评审 Agent 应当不在这类制品上误报问题。例如 code-utils-clean.json 中isCleanBaseline: true、findings: []即该夹具的期望输出是零缺陷。误报率指标false positive rate正是由这类夹具衡量。三、打分方法七维加权与关键词模糊匹配3.1 七维复合评分每个 Agent × 夹具组合的评分为0–1 区间的复合分由 7 个维度加权而来各维度的权重与理由见下该权重表在 scoring/types.ts 的SCORING_WEIGHTS常量中定义总和为 1.0维度权重理由True positive rate25%正确识别已知缺口Missing coverage20%Agent 检出的、不在 ground truth 中但确实成立的缺口False negative rate15%遗漏的已知缺口反向指标漏检率越低越好Evidence rate10%有制品中具体证据支撑的论断占比Perspective coverage10%检视的不同视角数量安全、性能、运维等Process compliance10%Agent 是否遵循了自身的结构化协议False positive rate10%在干净基线上误报的非问题项反向指标越低越好Missing coverage 权重最高的原因在 README 中阐述得很清楚harsh-critic的多视角调查协议其设计目的正是找出只盯单一角度的评审者会漏掉的缺口。而缺失覆盖率正是两者间最关键的区分指标。3.2 复合分的计算细节在 scoring/scorer.ts 的computeComposite()中两个反向指标false negative rate、false positive rate以1 - rate的形式计入总分三枚过程合规布尔量是否做了 pre-commitment 预测、是否覆盖全部视角、是否有非空Whats Missing小节则以满足三分之二作为 process compliance 得分composite 0.25 × TP_rate 0.15 × (1 − FN_rate) 0.10 × (1 − FP_rate) 0.20 × missing_coverage 0.10 × perspective_coverage 0.10 × evidence_rate 0.10 × process_compliance_score3.3 关键词匹配的宽容而严谨之道打分采用基于关键词的模糊匹配与 ground truth 比对。每个 ground truth 条目带有关键词列表Agent 的一条发现若命中足够多的关键词即计为一次 true positive。该逻辑在 SCORING_MATCH_CALIBRATION.md 中有专门的设计说明匹配器的实现位于 scoring/scorer.ts可总结为三层文本归一化normalizeTextForMatch先做小写折叠case-fold、Unicode NFKC 归一化再把标点/分隔符折叠为空格如new-hire与new hire、processPayment():47-52与processPayment 47 52得以对齐。这解决了真实模型输出在格式上的脆弱性——该文件明确指出其目标是减少评分环节的假阴性而非掩盖模型质量回归短语回退匹配多词关键词在归一化文本上做全 token 存在检查顺序无关同时保留直接子串匹配作为快速路径动态阈值基础要求为MIN_KEYWORD_MATCHES 2在 scoring/types.ts 中定义但对于关键词集更大的条目按 40% 比例下限提升要求——例如 6 个关键词的条目要求命中 3 个而不是 2 个以防更大关键词集带来的偶然误匹配。该方法刻意不引入 embedding 语义匹配或 LLM-in-the-loop 打分以保持确定性、可审计性与关键词锚定性同时用动态阈值守住精确度底线。四、如何运行基准测试4.1 命令行用法在仓库根目录执行前置条件设置ANTHROPIC_API_KEY环境变量# 完整基准测试两个 Agent × 全部夹具 ANTHROPIC_API_KEYsk-... npx tsx benchmarks/harsh-critic/run-benchmark.ts --agent both # 只跑单个 Agent npx tsx benchmarks/harsh-critic/run-benchmark.ts --agent harsh-critic npx tsx benchmarks/harsh-critic/run-benchmark.ts --agent critic # 只跑单个夹具 npx tsx benchmarks/harsh-critic/run-benchmark.ts --agent both --fixture plan-auth-migration # 干跑校验管道但不调用 API npx tsx benchmarks/harsh-critic/run-benchmark.ts --dry-run4.2 运行器支持的参数以上参数由 run-benchmark.ts 顶部的文档注释与parseArgs()实现确认完整清单为参数可选值默认值说明--agentharsh-critic/critic/bothboth运行哪个 Agent--fixture任意夹具 id全部只运行单个夹具如plan-auth-migration--output-dir路径benchmarks/harsh-critic/results结果输出目录--modelClaude 模型名claude-opus-4-6使用的模型--dry-run—关闭只加载夹具与 ground truth跳过 API 调用4.3 运行器的内部工作流结合 run-benchmark.ts 源码一次完整运行分以下步骤执行提示词加载loadAgentPromptFromFile()会按agents/name.md→benchmarks/harsh-critic/prompts/name.md的顺序查找提示词并经由stripFrontmatter()剥离 YAML frontmatter。这意味着已被移除出活跃注册表的harsh-critic正是从归档快照加载的夹具与 ground truth 加载按plans/code/analysis三个领域目录扫描.md与.ts文件并以文件名去扩展名为夹具 id--fixture过滤即在此生效API 调用callClaude()以 system prompt 携带 Agent 提示词、user message 为Review the following work:\n\n{fixture 内容}的方式调用 Anthropic Messages APImax_tokens: 8192并对 529 / overloaded / rate / 500 类错误做指数退避重试最多 5 次退避上限 60 秒解析与打分输出经 scoring/parser.ts 解析为结构化结果再由 scoring/scorer.ts 的scoreFixture()与matchFindings()计算各项指标报告生成scoring/reporter.ts 生成 JSON 与 Markdown 双格式报告若某夹具没有 ground truth会用空的占位 ground truth 并给出警告。输出位置结果写入benchmarks/harsh-critic/results/该目录在 git 中被忽略。每次运行都会同时写出带时间戳的results_timestamp.json、report_timestamp.md以及始终指向最新一次的results.json与report.md方便脚本与人工读取。4.4 打分逻辑的单元测试无需 API Key打分器带有独立的 vitest 测试可在不调用 API 的情况下验证匹配与阈值行为。需要说明的是README 中给出的命令npx vitest run src/__tests__/benchmark-scoring与实际仓库布局并不完全一致——真实测试文件位于 benchmarks/harsh-critic/scoring/tests即 parser.test.ts 与 scorer.test.ts本目录自带的 vitest.config.ts 也以scoring/__tests__/*.test.ts为 include 规则。因此在基准目录下使用本地配置运行即可cd benchmarks/harsh-critic npx vitest run五、解读结果从逐夹具对比到关键洞察5.1 输出形态每次运行都会在终端打印汇总表每夹具 × 每 Agent 一行展示 composite / TP rate / FN rate / Missing Cov与头对头Head-to-Head汇总。若跑双 Agent还会打印聚合分数与 deltaFixtureCritic ScoreHarsh-Critic ScoreDeltaWinnerplan-auth-migration0.610.780.17harsh-critic...............5.2 指标口径Composite score0–1 区间越高越好Deltaharsh-critic 得分减去 critic 得分正值表示 harsh-critic 更优Win/Loss/Tie按夹具判定。README 将平局解释为delta 在 0.05 以内从源码看scoring/reporter.ts 的generateJsonReport()中平局判定被实现为Math.abs(delta) 0.001——两者阈值略有出入阅读报告时以代码为准Key insight报告会自动找出 delta 绝对值最大的指标。这一设计的解读逻辑值得牢记最大改进出现在哪个指标就说明哪段协议元素贡献最大——如果missing_coverage的 delta 最大说明多视角调查协议在起作用如果true_positive_rate的 delta 最大则结构化输出模板是主要驱动。5.3 打分口径细节missingCoverage计算的是命中 ground truth 的Whats Missing条目数 ÷ ground truth 中category missing的条目总数perspectiveCoverage同理按category perspective计算severityAccuracy检查命中条目的严重级评定是否准确scoring/types.ts 中ALLOW_ADJACENT_SEVERITY true即允许相邻一级的误差CRITICAL↔MAJOR、MAJOR↔MINOR 视为可接受。六、可复现性与成本6.1 为什么需要多次运行LLM 输出在不同运行间存在方差。README 给出的可复现性建议跑 3 次取平均以获得稳定的对比结论若需跨时间可复现在 run-benchmark.ts 中固定模型版本默认claude-opus-4-6可通过--model指定结果目录被 git 忽略——每次运行都产生全新输出旧结果不纳入版本跟踪打分器自身带 vitest 测试可脱离 API Key 独立验证。6.2 成本参考README 给出的量级估算实际以模型定价为准完整基准运行8 夹具 × 2 Agent × Opus约3–5 美元开发期用--fixture做单夹具定向运行约0.50–1.00 美元/夹具对。由于系统提示词更短、输出 token 更少critic的每次运行成本通常略低于harsh-critic。七、纵深Harsh-Critic 提示词的结构化设计若想真正理解这份基准在验证什么需要回到归档提示词 prompts/harsh-critic.md。它的 frontmatter 声明了身份model: claude-opus-4-6且disallowedTools: Write, Edit——只读评审者。其核心机制按阶段组织Phase 1 — Pre-commitment预先承诺在细读制品前先根据类型与领域预测最可能的 3–5 个问题区域并写下来再逐一验证——用刻意搜索激活而非被动阅读。这也是打分器hasPreCommitment布尔量与解析器中Pre-commitment Predictions小节检测的来源Phase 2 — Verification验证通读并抽取所有文件引用/函数名/API 调用/技术论断逐一阅读真实源码核实code 场景追踪执行路径与错误路径、排查 off-by-one、竞态、缺失空值检查与安全疏漏plan 场景执行六步拆解关键假设抽取与 VERIFIED/REASONABLE/FRAGILE 评级、5–7 个失败场景的 Pre-Mortem、依赖审计、歧义扫描、可行性检查、回滚分析analysis 场景寻找逻辑跳跃与把假设当事实的论断Phase 3 — Multi-perspective多视角code 以安全工程师/新员工/运维工程师视角审视plan 以执行者/利益相关方/怀疑者视角审视混合制品则两组视角并用Phase 4 — Gap analysis缺口分析显式追问What would break this?等四个问题找出缺了什么而非哪里错了Phase 4.5 — Self-Audit自审对每条 CRITICAL/MAJOR 结论做置信度评级与作者能否立即反驳是真缺陷还是风格偏好检查低置信度与可被反驳项移入 Open QuestionsPhase 4.75 — Realist Check现实校准用真实最坏情况而非理论最大“被忽略的缓解因素”“实际发现速度”“是否存在 hunting mode 偏见”四个问题压测严重级降级必须附Mitigated by:理由涉及数据丢失、安全破坏、财务影响的一律不降级Escalation — 自适应严苛度发现任一 CRITICAL、或 3 条 MAJOR、或系统性缺陷模式时从 THOROUGH 模式升级为 ADVERSARIAL 模式对剩余内容有罪推定Phase 5 — Synthesis将实际发现与 pre-commitment 预测对照产出带严重级评定的结构化裁决。其输出格式强制为VERDICT: REJECT / REVISE / ACCEPT-WITH-RESERVATIONS / ACCEPT并包含 Critical/Major/Minor Findings、Whats Missing、Ambiguity Risks、Multi-Perspective Notes、Verdict Justification、Open Questions 等小节。打分器 scoring/parser.ts 中的parseHarshCritic()正是按这套章节别名如critical findings、whats missing、multi-perspective、pre-commitment predictions做正则定位与条目抽取从而把自由文本还原成ParsedAgentOutput结构化对象——同时每条 finding 的hasEvidence由证据模式正则反引号代码段、file:line、function():line-line判定。对critic简单 OKAY/REJECT 格式parseCritic()则退化为从 Summary/Justification 中抽取条目、统一归入 MAJOR 的无章节结构路径。这种设计形成了一个闭环提示词定义协议 → 解析器按协议反解 → 打分器按协议指标验证协议是否被遵守——也就是说即便两个 Agent 检出的缺陷数相同谁更严格地执行了结构化协议谁就能在 process compliance 与 evidence 维度上得分。八、参考资料与延伸阅读基准说明benchmarks/harsh-critic/README.md归档提示词快照benchmarks/harsh-critic/prompts/harsh-critic.md现役评审 Agentagents/critic.md运行器benchmarks/harsh-critic/run-benchmark.ts类型与权重定义benchmarks/harsh-critic/scoring/types.ts打分实现benchmarks/harsh-critic/scoring/scorer.ts输出解析benchmarks/harsh-critic/scoring/parser.ts报告生成benchmarks/harsh-critic/scoring/reporter.ts匹配校准设计benchmarks/harsh-critic/SCORING_MATCH_CALIBRATION.md测试夹具与 ground truth见 benchmarks/harsh-critic/fixtures 与 benchmarks/harsh-critic/ground-truth如 plan-auth-migration.json 完整展示了 11 条跨 finding/missing/perspective 三类别的期望缺陷【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考