PostHog ReviewHog 验证器实验解析如何用 L-opus5-validator-2 实验转储读懂一次 Opus 5 验证器评审【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog本文解读 L-opus5-validator-2.md —— PostHog 仓库内 ReviewHogAI 代码评审产品「验证器模型选型」实验中 L2 这一次运行的完整实验转储dump。读完后你能掌握三件事ReviewHog「分块 → 多视角评审 → 盲点扫描 → 去重 → 验证器裁决」这条流水线的成本与时延结构验证器Opus 5 xhigh在 22 条发现上做出的保留/否决裁决及其源码级证据链以及如何从网关遥测与打分文件复算出该次运行的精确率、召回率与单裁决成本并把它放进整个 8 次运行的对比表中理解其结论。1. 实验背景L2 是一次「验证器对照组」运行ReviewHog 的评审由两个模型分工评审器reviewer负责发现问题验证器validator负责逐条反驳式审查决定保留还是丢弃。2026-08-validator-model-sol 实验 要回答的问题是gpt-5.6-solCodex能否替代 Claude Opus 担任验证器换取更低成本与耗时。实验全部冻结在同一份 PRPostHog #75215 a7fb363bStamphog 的「Inbox PR 自动审批」特性与同一份固定分块上唯一的变量是模型与 effort 档位。L2L-opus5-validator-2在 PLAN.md 的 Run log 中的定义是Arm L 生产验证器固定参数prod pinsclaude/claude-opus-5/xhighreviewer 固定为 Sol xhigh运行顺序 L1 → M1 →L2→ M2L 臂两次、M 臂两次交叉执行以排除顺序效应沙箱镜像已打上 effort 修复posthog/agent内collaborationModeForTurn()透传reasoning_effort网关遥测确认本次运行所有调用均为xhigh结果集记为LBfindings/LB.*L1 为 LAM1/M2 为 MA/MB。因此 L2 在整组实验中的定位是参考上限control arm它给出「最强验证器在真实 xhigh 下能保住多少真问题、扔掉多少假问题、花多少钱」的基线M 臂Sol 验证器的省钱幅度就是相对它来衡量的。2. 运行元数据与配置快照转储头部记录了本次运行的全部元数据报告 ID01a03bf0-7d70-758b-9679-32060abdf2fe对应上游 PR #75215Head 提交a7fb363bef6947e4e7fc30a0fe8a0a4cc4deaa82run_count: 1状态idle墙钟总时长3491 秒58.2 分钟配置快照项值runtime / model / effort验证器codex为 reviewer runtime验证器为claude/claude-opus-5/xhighsingle-chunk gate / chunk target400 / 300soft-max additions600从源码结构看验证器固定参数由reviewer/constants.py的VALIDATION_*常量控制PLAN.md 中明确「Arm L prod validator pins (claude/claude-opus-5/xhigh)」实验期间曾临时改写为 Sol 参数跑 M 臂运行结束后已恢复生产值。3. 评审流水线26 条原始发现如何漏斗成 12 条转储的核心是一张「漏斗表」描述了发现从产生到发布的收敛过程chunksreview unitsraw issuesafter deduppassed validator413262212review units 每一个 (perspective | blind-spot × chunk) 沙箱评审单元即「模型固定不变时的成本代理」model-held-constant cost proxy。13 个单元 3 个视角 × 3 个代码分块共 9 个 1 个通用盲点扫描 × 4 个分块共 4 个。3.1 分块chunking分块由pinned_chunks.json固定保证跨运行可比。本次的 4 个分块覆盖 Stamphog Inbox PR 特性的前后端chunk 18 文件ReviewHog 侧 —— models.py、迁移 0019、settings.py、receivers.py、前端CodeReviewScene.tsx与生成式 API schema 等chunk 28 文件Stamphog 后端 —— facade/api.py、tasks.py、temporal/activities.py、logic/reviewer.py、contracts.py 等chunk 34 文件tools/pr-approval-agent/评审引擎review_pr.py、review_local.py、reviewer.py、version.py注意这是冻结 PR 树内的路径见文末说明chunk 42 文件products/stamphog/AGENTS.md、products/stamphog/README.md—— 说明评审单元会把文档也纳入视角检查后文「posthog-bot 谓词」发现即来自文档与代码的对照。3.2 逐评审单元产出passchunkperspectiveraw issues11/2/3review-hog-perspective-contracts-security1 / 3 / 121/2/3review-hog-perspective-logic-correctness1 / 4 / 131/2/3review-hog-perspective-performance-reliability2 / 4 / 110001/2/3/4review-hog-blind-spots-general3 / 3 / 0 / 2三个编号 1/2/3 的视角契约与安全、逻辑正确性、性能与可靠性各跑一轮 wavepass1000 的 blind-spots 扫描是兜底视角。94 单元产出 26 条原始发现chunk 2Stamphog 核心后端贡献了 11 条是问题最密集的区域。3.3 阶段耗时阶段墙钟时长fetch snapshot0schunking0sperspective selection18sreview wave视角评审15m 52sblind-spot sweep12m 10sdedup含合并/清洗2m 46svalidation验证器裁决26m 46s评审阶段合计selection → 最后一个 finder 单元28m 02s这是用来横向比较「评审器模型速度」的口径数字阶段时长由 artefact 的created_at完成时持久化推导只对「全新、非续跑」的运行有意义值得注意验证阶段26m46s比整个评审阶段28m02s 中的 waveblind-spot几乎等长。L 臂两次运行的验证阶段分别为 30 min 与 26 minFINAL_REPORT.md「Runs at real xhigh」表验证器本身是整条流水线中不可忽视的耗时与成本大头。4. 成本核算从网关$ai_generation事件复算转储自身对成本有一句重要说明「cache-aware spend该时间窗内没有$ai_generation事件可能发往云项目或尚未摄入」——即 dump 脚本从本地摄入链路读不到费用。真实的逐阶段成本需要绕过摄入链路、直接读网关事件。本次运行对应的网关遥测汇总在 L-opus5-validator-2.gateway_usage.md原始 547 条$ai_generation事件在 L-opus5-validator-2.gateway_events.json可用 kafka_ai_usage.py 从本地 Kafka topicevents_plugin_ingestion_ai读取阶段族模型调用数output tokensreasoning tokens网关费用effortreviewgpt-5.6-sol244105,69874,886$17.32xhighblind-spotgpt-5.6-sol12557,03841,925$8.73xhighvalidationclaude-opus-5176193,2860$23.42xhighdedupclaude-sonnet-5117,2540$0.19xhighperspective_selectionclaude-sonnet-511,5380$0.03xhigh计费按网关 LiteLLM 牌价输入 $4/MTok、输出 $20/MTok、缓存读 $0.40/MTok。由此可复算验证阶段单裁决成本 $23.42 / 22 条 $1.06/verdict评审盲点阶段合计 $26.04369 次调用7.5 万 reasoning tokens。两个细节值得记录其一Claude/Opus 会话的reasoning列记 0推理开销体现在 input/output 里与 Codex 的 reasoning 计数方式不同跨模型比成本时不能直接比这一列其二实验组踩过一个坑——早期用 agent 日志的逐 turn usage 估算费用会少计 3–4 倍ACP 的 per-turn usage 只记录该 turn 最后一次 LLM 调用而非工具多轮往返之和所以最终报告一律改用网关事件口径。5. 十二条保留发现Opus 5 验证器的裁决细节转储的「Findings (post-dedup) with validator verdict」一节是全篇主体22 条去重后的发现Opus 5 保留 12 条✅ VALID、否决 10 条❌ dismissed。按 LB.score.md 的打分对照12 条保留中有 8 条为真precision 67%11 条真问题中漏掉 3 条recall 73%。下面按主题归类解读每条给出验证器的证据链骨架。5.1 安全类3 条保留Caller-writable PR URL 可绕过 Stamphog 审批门禁must_fix保留原级—— receivers.py L126-138、L225-230。TaskRun.output.pr_url通过任务输出接口是调用方可写的receiver 分支在触发 Stamphog 前只检查用户开关不校验任务仓库、PR 作者、head 仓库或可信 run 关联而它盖上的inbox_review印章会关闭 bot-author、draft、review-mode 三道门禁。验证器的 Checked/Found 链逐一核实写入面在 facade/api.py L1770 处仅对{pr_merged}做 webhook 认证L1773_apply_caller_output的 docstring 明确把「调用方把 run 指向另一个pr_url」列为威胁模型receiver 腿把pr_url原样转交receivers.py L126-138而 webhook 腿做了全部检查_is_bot_authored位于 tasks.py L169 附近。验证器还交叉印证master 分支同函数已加上repository参数与「重新对照 GitHub 校验作者和 head」的注释独立确认了缺陷与修复形态。子环境用户可启用父项目的审批开关must_fix降为 should_fix—— settings.py L58-65、L98-104。 端点用 URL 里的 team id 鉴权但_get_or_create写入的是规范化后的父 team行resolve_effective_team_id返回team.parent_team_id or team_id。验证器指出仓库内已有同类防御Stamphog 的StamphogCanonicalTeamAccessPermission并给出降级理由scope_object INTERNAL使个人 API key 路径本来就被拒绝且行以user_id为键、调用者只能改自己的偏好GitHub 审批后果还需第二个独立条件成立。PR URL 解析器接受内嵌 GitHub URLshould_fix否决—— tasks.py L113-121。 验证器否定的关键证据解析出的 slug 只是StamphogRepoConfig查询的查找键GitHub 调用用的是repo_config.repository与repo_config.installation_id而非 URL 里的字符串——可达仓库集合恰好就是团队自己已连接启用的仓库严格解析「不移除任何能力」不满足安全/正确性门槛。5.2 正确性类3 条保留Stamphog 忽略已选中的次要评审人must_fix保留—— receivers.py L111-126、L151-154。 解析逻辑先把评审人集合塌缩为单人acting next((user for user in resolved if user.id task_created_by_id), resolved[0])其余评审人的stamphog_review_inbox_prs开关值从未被读取。验证器额外标注了一条「correction」此分支两条路径逻辑一致不会当下互相矛盾但建议中「两条路径使用同一选择」是承重条款——只放宽初始分发而不放宽 webhook 解析器会造成撤销在途审批的新风险。Self-driving 身份在 PR 被校验前就已授予must_fix保留—— tasks.py L113-127、L176-204、L1158-1181。process_inbox_pr_review对任何「slug 匹配已连接仓库的 open PR」都盖上inbox_review不加载task_run_id、不对比signal_report_id、不检查 head 仓库与 bot 身份该印章是引擎侧豁免的唯一输入activities.py L451self_driving_reviewbool(output.get(inbox_review))。验证器同时做了「准确性注记」finding 中两个子论断较弱task_run_id与signal_report_id同源于一个 TaskRun天然自洽webhook 腿的宽松_is_bot_authored由find_signal_implementation_run的关联检查兜底——真实缺陷是 receiver 腿完全没有 PR 侧校验。可信提示词恒定声称 PR 是 draftshould_fix降为 consider—— 冻结树内tools/pr-approval-agent/reviewer.pyL699-700。 一个被人工标记 ready 的 self-driving PR 收到新提交后仍会触发评审但 TRUSTED 块依旧断言「它是有意保持 draft 的」。验证器降级理由该句是「宽松性」表述告诉模型不要把 draft 当谨慎信号对 ready PR 无可演示的裁决影响只造成轻微宽松措辞且触发需要 ready 翻转 新 head 事件偏离主流程。5.3 可靠性类3 条保留其中 2 条降级Worker 丢失可永久丢掉首次评审should_fix保留—— tasks.py L1109-1112。 Celery 默认提前 ackcelery.py 未设CELERY_TASK_ACKS_LATEworker 硬退出会丢唯一的首次触发建议acks_lateTrue, reject_on_worker_lostTruehead 级去重保证重投安全。验证器给出的在库先例products/visual_review/backend/tasks/tasks.py、posthog/tasks/exporter.py 等对同类 GitHub 幂等任务都设置了这两个标志。opt-out 路径遗留旧评审工作流活跃must_fix降为 should_fix—— tasks.py L881-898。 skip 分支只撤销已存审批不SUPERSEDED排队/评审中的 run旧工作流可能在新 push 之前取 head然后在工作流返回后贴出审批。post_verdict三道守卫中第三道GitHub 写入前的superseded_now数据库读取恰好为这类窗口而设。降级理由窗口要求 push 落进 fetch-to-write 间隙且该缺口在所有skip 路径上先于本 PR 存在下一次 head 变更投递会自动清扫孤儿。opt-out 撤销漏掉 GitHub 侧孤儿审批must_fix降为 consider—— tasks.py L894-898。dismiss_stale_approvals_for_head只查posted_review_id__isnullFalseapprovals.py L44-55worker 在「POST 成功 → 回写 id」的亚秒间隙内死亡、且工作流永不重试完成、且永不到达 terminal 处理三层防护同时失效才会留下无 DB 记录的活审批。降级理由这是既有缺口修复成本每次 skipped head 变更都加一次 GitHub 审批列表调用大于风险。「未绑定上下文标志不应被信任」must_fix否决—— 冻结树内tools/pr-approval-agent/review_local.pyL316-324。 这条否决是 Opus 5 裁决风格的典型验证器指出上下文 JSON 只在沙箱启动前由服务端渲染沙箱内代码无法置位ReviewRun.output无 API 写路径只读SerializerMethodFieldreceiver 腿的 task 关联在上游已被校验signal_report_id 非 internal 同 team 内解析启用的仓库配置。结论所述攻击「没有可达的攻击者」must_fix高估了它。「取消的实现 run 仍满足 carve-out 资格」should_fix否决—— facade/api.py L502-509。 验证器发现返回终态 run 是有意设计post-merge 事件需要经由 pr_url 腿解析且「终态」包含常规的 cloud-to-local 交接run 被标记 cancelled拒绝它会让后续每次 push 都走 skip 路径并撤销在途审批——是功能回归而非收紧。5.4 其余保留/否决各 1 条较旧的 completed run 可遮蔽最新的 failed 复审should_fix降为 consider—— tasks.py L1202-1209exclude(status__in(SUPERSEDED, FAILED))在按created_at排序之前执行同 head 的旧 completed run 会赢过更新的 failed run。触发需要三重条件巧合同 head 二次 run 失败 后续 output 保存重触发后果是缺裁决而非错误审批。子环境 PR 永远收不到 Stamphog 复审should_fix保留—— receivers.py L144-154、L180-184StamphogRepoConfig继承的save()把team_id规范化到父团队而TaskRun/Task/SignalReport保持环境 team idfind_signal_implementation_run的run.team_id ! team_id是精确比较于是首次评审走规范化查询成功、后续 push 永远失败且 skip 分支会用「不受信任作者」的理由误导排障。fail-soft 检查可拖慢请求、刷爆错误日志should_fix否决—— settings.py L77-81验证器核实该端点不是热点前端仅在场景挂载时加载一次10s 轮询驱动的是别的查询且最坏延迟被connect_timeout3与共享 Redis 熔断器posthog/db_circuit_breaker.py30s 窗口内 3 次失败全 Pod 共享一个 open 标记限制在「一次约 3 秒」。broker 故障永久丢失首次评审should_fix否决—— receivers.py L224-234吞掉发布异常是既定的 best-effort 约定docstring 明示 broker 故障绝不能冒泡进 saver且 receiver 每次 output 保存都会重触发、head 键去重行锁保证重发安全、webhook 腿在后续 push 时兜底——为 opt-in 评审新建 outbox 表「与风险不成比例」。资格过滤在选定 run 之后才执行should_fix否决—— facade/api.py L504-506两条腿都有确定性排序pr_url 腿非终态优先 -created_atsignals run 必然持有该 PR URL 因而必是候选更窄的检索会让两条腿对「哪个 run 拥有这个 PR」产生分歧。former 项目成员仍是审批评审人must_fix否决—— receivers.py L151-154、L202-207acting user id 在该腿只是溯源信息从不被读回做决策真正授予能力的身份沙箱凭据铸造者connected_by_user_id在is_active检查处 fail closed组织成员解析是跨产品统一约定单独换用Team.all_users_with_access()反而会让评审门与 Inbox「For you」过滤、Slack 扇出互相矛盾。Hosted bot 谓词漏掉posthog-botshould_fix降为 consider—— products/stamphog/AGENTS.md L82-90文档声称posthog-bot在每一层被拒绝但 hosted 侧_is_bot_authoredtasks.py L149 附近只查type Bot或[bot]后缀放它过了预过滤直到引擎层才被拒。后果是浪费一次沙箱与公开拒绝评论安全边界仍成立该 PR 无self_driving印章故降为 consider 的文档准确性问题。5.5 从这 22 条裁决中能读出的「验证器行为画像」反驳式证据链每条 Validator 段都以Checked声明核查范围开头再逐条Found给出文件行号证据最后Impact收口并给出Priority是否调整及理由。这是 FINAL_REPORT 所称「refutation-first」验证风格的可复现样例优先级降级是常见动作L2 的 12 条保留中至少 6 条被降档两条 must_fix→should_fix/consider、多条 should_fix→consider每次都附具体理由触发条件数量、后果性质、缺口是否既有、修复成本比对否决理由指向「设计约定」而非「代码错误」broker 吞异常、返回终态 run、组织成员解析三条被否决验证器都引用了 docstring/注释/兄弟路径来证明这是有意的系统姿态避免「防御性加固」类建议通过验证器自我纠错两条 finding 的裁决里嵌入了「(correction)」「(refinement)」「(accuracy note)」验证器在确认核心结论的同时修正 finding 作者过强的子论断——这解释了为何打分时它保留 8 条而非「全对」。6. 打分协议真值从哪来L2 的 22 条发现按 FINAL_REPORT.md 的协议判分每条发现先与 76 个「已知问题簇」known_clusters.json构建自 2026-07 reviewer 实验的 judge 文件匹配匹配记录在 LB.match.json落在一致簇里的发现直接继承簇的 real / not-real 裁决落在混合簇或簇外的发现逐条对冻结工作树做「反驳优先」的全新验证findings/verify/LB*.json相同论断复用先前裁决真值与打分落盘为 LB.truth.json 与 LB.score.md。L2 最终账目与 xhigh_summary.md 一致| 指标 | L2 | | ---- | -- | | 裁决发现数 | 22 | | 保留 | 128 真 / 4 假 | | 保留精度 kept-real | 8/12 67% | | 真问题召回 real-kept | 8/11 73% | | 假问题否决率 not-real dropped | 7/11 64% | | 验证墙钟 / 网关费用 | 26 min / $23.42176 次调用 | | 单裁决成本 | $1.06 |漏掉的 3 条真问题LB10 上下文标志 must_fix、LB13 canceled-run carve-out should_fix、LB17 hosted WAIT 遥测 should_fix是 L 臂两次运行中 Opus 的漏检样本FINAL_REPORT 指出其中「toggle 论断」在 L1 被否决、在 L2 又被保留说明 22 条样本量下存在一定运行间噪声。7. 横向对照L2 在整个实验中是什么位置八次运行的汇总xhigh_summary.md评审器均为 SolL 臂为 Opus 5 验证器、M 臂为 Sol 验证器、N 臂为 Sonnet 5 验证器LA (Opus 5)LB (Opus 5)MA (Sol)MB (Sol)NA (Sonnet 5)NB (Sonnet 5)裁决发现数232219202222保留精度9/11 (82%)8/12 (67%)11/18 (61%)12/18 (67%)8/16 (50%)11/22 (50%)真问题召回9/12 (75%)8/11 (73%)11/12 (92%)12/13 (92%)8/11 (73%)11/11 (100%)假问题否决率9/11 (82%)7/11 (64%)0/7 (0%)1/7 (14%)3/11 (27%)0/11 (0%)验证费用 / 单裁决$24.35 / $1.06$23.42 / $1.06$13.62 / $0.72$15.97 / $0.80$10.53 / $0.48$11.72 / $0.53实验结论FINAL_REPORT「Recommendation」真实 xhigh 下 Sol 验证器仍保留 19–20 条中的 18 条、几乎不扔假发现成本优势缩水到约 30%/verdict继续用 Opus 作为验证器xhigh 的价值在评审器侧3 倍真发现、8 个此前 18 次评审未报出的真问题代价约 $26/次评审。L2 作为 L 臂第二次运行其 67% 精度 / 73% 召回 / $1.06 单裁决正是这条结论里「Opus 基线」的数据来源之一。8. 复现一次 L2 式运行PLAN.md 给出了完整 run recipeflox activate -- bash -c DJANGO_SETTINGS_MODULEposthog.settings python manage.py \ run_review --pr-url 被评审 PR 的 URL --team-id 1 --user-id 1 LABELL-opus5-validator-2 RUN_SECONDSs RUN_START_EPOCHepoch OUT_DIR$PWD/runs \ python manage.py shell -c exec(open(products/review_hog/eval/scripts/dump_result.py).read())复现适用前提与限制均来自 PLAN.md 的「Experiment hacks」与 tree state 记录属实验期本地改动非生产配置需要本地 dev 环境flox 环境 Django Temporal 本地沙箱运行时run_review管理命令驱动整条流水线实验为保证跨运行可比做了四处本地 hackfetch_pr_comments返回[]零评论干净房、split_chunks_activity在存在pinned_chunks.json时加载固定分块、VALIDATION_*改写到目标模型、MAX_CONCURRENT_SANDBOXES10→4沙箱镜像需带 effort 透传修复与 Codex 重试参数stream_max_retries10等否则 xhigh 评审波次会在网关隧道抖动时整波失败网关遥测可用 kafka_ai_usage.py 离线复算阶段耗时与漏斗表由 parse_dump.py、summarize_runs.py 生成运行结束后删除该 PR 的报告即可无需全库清理VALIDATION_*与REVIEW_REASONING_EFFORT需恢复生产值。9. 结语这份 dump 的三种读法作为流水线度量漏斗表26 → 22 → 12与阶段耗时表给出「每评审单元成本、验证阶段占比」的量化骨架是评审系统调优视角裁剪、分块粒度、验证器并发的直接依据作为验证器能力样本22 条 Checked/Found/Impact/Priority 证据链展示了反驳式验证的完整形态包括降级、否决与自我纠错三种裁决动作可作提示词设计与评审技能validation skill调校的对照样本作为模型选型证据配合 FINAL_REPORT.md 的八运行对照L2 的 67%/73%/64% 与 $1.06/verdict 构成「保持 Opus 验证器」这一结论的对照基线。一个必要的引用边界说明转储中大量行号如tools/pr-approval-agent/reviewer.py:699、tasks.py:1202锚定在冻结的 PR 树a7fb363b/1341596e上其中tools/pr-approval-agent/目录在当前仓库主干中已不存在该特性代码已演进而products/stamphog/、products/review_hog/、products/tasks/下的路径在当前主干仍有效但行号可能有漂移。引用这些发现时应以冻结树为锚把行号视为实验时点的快照而非当前代码坐标。【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PostHog ReviewHog 验证器实验解析：如何用 L-opus5-validator-2 实验转储读懂一次 Opus 5 验证器评审
PostHog ReviewHog 验证器实验解析如何用 L-opus5-validator-2 实验转储读懂一次 Opus 5 验证器评审【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog本文解读 L-opus5-validator-2.md —— PostHog 仓库内 ReviewHogAI 代码评审产品「验证器模型选型」实验中 L2 这一次运行的完整实验转储dump。读完后你能掌握三件事ReviewHog「分块 → 多视角评审 → 盲点扫描 → 去重 → 验证器裁决」这条流水线的成本与时延结构验证器Opus 5 xhigh在 22 条发现上做出的保留/否决裁决及其源码级证据链以及如何从网关遥测与打分文件复算出该次运行的精确率、召回率与单裁决成本并把它放进整个 8 次运行的对比表中理解其结论。1. 实验背景L2 是一次「验证器对照组」运行ReviewHog 的评审由两个模型分工评审器reviewer负责发现问题验证器validator负责逐条反驳式审查决定保留还是丢弃。2026-08-validator-model-sol 实验 要回答的问题是gpt-5.6-solCodex能否替代 Claude Opus 担任验证器换取更低成本与耗时。实验全部冻结在同一份 PRPostHog #75215 a7fb363bStamphog 的「Inbox PR 自动审批」特性与同一份固定分块上唯一的变量是模型与 effort 档位。L2L-opus5-validator-2在 PLAN.md 的 Run log 中的定义是Arm L 生产验证器固定参数prod pinsclaude/claude-opus-5/xhighreviewer 固定为 Sol xhigh运行顺序 L1 → M1 →L2→ M2L 臂两次、M 臂两次交叉执行以排除顺序效应沙箱镜像已打上 effort 修复posthog/agent内collaborationModeForTurn()透传reasoning_effort网关遥测确认本次运行所有调用均为xhigh结果集记为LBfindings/LB.*L1 为 LAM1/M2 为 MA/MB。因此 L2 在整组实验中的定位是参考上限control arm它给出「最强验证器在真实 xhigh 下能保住多少真问题、扔掉多少假问题、花多少钱」的基线M 臂Sol 验证器的省钱幅度就是相对它来衡量的。2. 运行元数据与配置快照转储头部记录了本次运行的全部元数据报告 ID01a03bf0-7d70-758b-9679-32060abdf2fe对应上游 PR #75215Head 提交a7fb363bef6947e4e7fc30a0fe8a0a4cc4deaa82run_count: 1状态idle墙钟总时长3491 秒58.2 分钟配置快照项值runtime / model / effort验证器codex为 reviewer runtime验证器为claude/claude-opus-5/xhighsingle-chunk gate / chunk target400 / 300soft-max additions600从源码结构看验证器固定参数由reviewer/constants.py的VALIDATION_*常量控制PLAN.md 中明确「Arm L prod validator pins (claude/claude-opus-5/xhigh)」实验期间曾临时改写为 Sol 参数跑 M 臂运行结束后已恢复生产值。3. 评审流水线26 条原始发现如何漏斗成 12 条转储的核心是一张「漏斗表」描述了发现从产生到发布的收敛过程chunksreview unitsraw issuesafter deduppassed validator413262212review units 每一个 (perspective | blind-spot × chunk) 沙箱评审单元即「模型固定不变时的成本代理」model-held-constant cost proxy。13 个单元 3 个视角 × 3 个代码分块共 9 个 1 个通用盲点扫描 × 4 个分块共 4 个。3.1 分块chunking分块由pinned_chunks.json固定保证跨运行可比。本次的 4 个分块覆盖 Stamphog Inbox PR 特性的前后端chunk 18 文件ReviewHog 侧 —— models.py、迁移 0019、settings.py、receivers.py、前端CodeReviewScene.tsx与生成式 API schema 等chunk 28 文件Stamphog 后端 —— facade/api.py、tasks.py、temporal/activities.py、logic/reviewer.py、contracts.py 等chunk 34 文件tools/pr-approval-agent/评审引擎review_pr.py、review_local.py、reviewer.py、version.py注意这是冻结 PR 树内的路径见文末说明chunk 42 文件products/stamphog/AGENTS.md、products/stamphog/README.md—— 说明评审单元会把文档也纳入视角检查后文「posthog-bot 谓词」发现即来自文档与代码的对照。3.2 逐评审单元产出passchunkperspectiveraw issues11/2/3review-hog-perspective-contracts-security1 / 3 / 121/2/3review-hog-perspective-logic-correctness1 / 4 / 131/2/3review-hog-perspective-performance-reliability2 / 4 / 110001/2/3/4review-hog-blind-spots-general3 / 3 / 0 / 2三个编号 1/2/3 的视角契约与安全、逻辑正确性、性能与可靠性各跑一轮 wavepass1000 的 blind-spots 扫描是兜底视角。94 单元产出 26 条原始发现chunk 2Stamphog 核心后端贡献了 11 条是问题最密集的区域。3.3 阶段耗时阶段墙钟时长fetch snapshot0schunking0sperspective selection18sreview wave视角评审15m 52sblind-spot sweep12m 10sdedup含合并/清洗2m 46svalidation验证器裁决26m 46s评审阶段合计selection → 最后一个 finder 单元28m 02s这是用来横向比较「评审器模型速度」的口径数字阶段时长由 artefact 的created_at完成时持久化推导只对「全新、非续跑」的运行有意义值得注意验证阶段26m46s比整个评审阶段28m02s 中的 waveblind-spot几乎等长。L 臂两次运行的验证阶段分别为 30 min 与 26 minFINAL_REPORT.md「Runs at real xhigh」表验证器本身是整条流水线中不可忽视的耗时与成本大头。4. 成本核算从网关$ai_generation事件复算转储自身对成本有一句重要说明「cache-aware spend该时间窗内没有$ai_generation事件可能发往云项目或尚未摄入」——即 dump 脚本从本地摄入链路读不到费用。真实的逐阶段成本需要绕过摄入链路、直接读网关事件。本次运行对应的网关遥测汇总在 L-opus5-validator-2.gateway_usage.md原始 547 条$ai_generation事件在 L-opus5-validator-2.gateway_events.json可用 kafka_ai_usage.py 从本地 Kafka topicevents_plugin_ingestion_ai读取阶段族模型调用数output tokensreasoning tokens网关费用effortreviewgpt-5.6-sol244105,69874,886$17.32xhighblind-spotgpt-5.6-sol12557,03841,925$8.73xhighvalidationclaude-opus-5176193,2860$23.42xhighdedupclaude-sonnet-5117,2540$0.19xhighperspective_selectionclaude-sonnet-511,5380$0.03xhigh计费按网关 LiteLLM 牌价输入 $4/MTok、输出 $20/MTok、缓存读 $0.40/MTok。由此可复算验证阶段单裁决成本 $23.42 / 22 条 $1.06/verdict评审盲点阶段合计 $26.04369 次调用7.5 万 reasoning tokens。两个细节值得记录其一Claude/Opus 会话的reasoning列记 0推理开销体现在 input/output 里与 Codex 的 reasoning 计数方式不同跨模型比成本时不能直接比这一列其二实验组踩过一个坑——早期用 agent 日志的逐 turn usage 估算费用会少计 3–4 倍ACP 的 per-turn usage 只记录该 turn 最后一次 LLM 调用而非工具多轮往返之和所以最终报告一律改用网关事件口径。5. 十二条保留发现Opus 5 验证器的裁决细节转储的「Findings (post-dedup) with validator verdict」一节是全篇主体22 条去重后的发现Opus 5 保留 12 条✅ VALID、否决 10 条❌ dismissed。按 LB.score.md 的打分对照12 条保留中有 8 条为真precision 67%11 条真问题中漏掉 3 条recall 73%。下面按主题归类解读每条给出验证器的证据链骨架。5.1 安全类3 条保留Caller-writable PR URL 可绕过 Stamphog 审批门禁must_fix保留原级—— receivers.py L126-138、L225-230。TaskRun.output.pr_url通过任务输出接口是调用方可写的receiver 分支在触发 Stamphog 前只检查用户开关不校验任务仓库、PR 作者、head 仓库或可信 run 关联而它盖上的inbox_review印章会关闭 bot-author、draft、review-mode 三道门禁。验证器的 Checked/Found 链逐一核实写入面在 facade/api.py L1770 处仅对{pr_merged}做 webhook 认证L1773_apply_caller_output的 docstring 明确把「调用方把 run 指向另一个pr_url」列为威胁模型receiver 腿把pr_url原样转交receivers.py L126-138而 webhook 腿做了全部检查_is_bot_authored位于 tasks.py L169 附近。验证器还交叉印证master 分支同函数已加上repository参数与「重新对照 GitHub 校验作者和 head」的注释独立确认了缺陷与修复形态。子环境用户可启用父项目的审批开关must_fix降为 should_fix—— settings.py L58-65、L98-104。 端点用 URL 里的 team id 鉴权但_get_or_create写入的是规范化后的父 team行resolve_effective_team_id返回team.parent_team_id or team_id。验证器指出仓库内已有同类防御Stamphog 的StamphogCanonicalTeamAccessPermission并给出降级理由scope_object INTERNAL使个人 API key 路径本来就被拒绝且行以user_id为键、调用者只能改自己的偏好GitHub 审批后果还需第二个独立条件成立。PR URL 解析器接受内嵌 GitHub URLshould_fix否决—— tasks.py L113-121。 验证器否定的关键证据解析出的 slug 只是StamphogRepoConfig查询的查找键GitHub 调用用的是repo_config.repository与repo_config.installation_id而非 URL 里的字符串——可达仓库集合恰好就是团队自己已连接启用的仓库严格解析「不移除任何能力」不满足安全/正确性门槛。5.2 正确性类3 条保留Stamphog 忽略已选中的次要评审人must_fix保留—— receivers.py L111-126、L151-154。 解析逻辑先把评审人集合塌缩为单人acting next((user for user in resolved if user.id task_created_by_id), resolved[0])其余评审人的stamphog_review_inbox_prs开关值从未被读取。验证器额外标注了一条「correction」此分支两条路径逻辑一致不会当下互相矛盾但建议中「两条路径使用同一选择」是承重条款——只放宽初始分发而不放宽 webhook 解析器会造成撤销在途审批的新风险。Self-driving 身份在 PR 被校验前就已授予must_fix保留—— tasks.py L113-127、L176-204、L1158-1181。process_inbox_pr_review对任何「slug 匹配已连接仓库的 open PR」都盖上inbox_review不加载task_run_id、不对比signal_report_id、不检查 head 仓库与 bot 身份该印章是引擎侧豁免的唯一输入activities.py L451self_driving_reviewbool(output.get(inbox_review))。验证器同时做了「准确性注记」finding 中两个子论断较弱task_run_id与signal_report_id同源于一个 TaskRun天然自洽webhook 腿的宽松_is_bot_authored由find_signal_implementation_run的关联检查兜底——真实缺陷是 receiver 腿完全没有 PR 侧校验。可信提示词恒定声称 PR 是 draftshould_fix降为 consider—— 冻结树内tools/pr-approval-agent/reviewer.pyL699-700。 一个被人工标记 ready 的 self-driving PR 收到新提交后仍会触发评审但 TRUSTED 块依旧断言「它是有意保持 draft 的」。验证器降级理由该句是「宽松性」表述告诉模型不要把 draft 当谨慎信号对 ready PR 无可演示的裁决影响只造成轻微宽松措辞且触发需要 ready 翻转 新 head 事件偏离主流程。5.3 可靠性类3 条保留其中 2 条降级Worker 丢失可永久丢掉首次评审should_fix保留—— tasks.py L1109-1112。 Celery 默认提前 ackcelery.py 未设CELERY_TASK_ACKS_LATEworker 硬退出会丢唯一的首次触发建议acks_lateTrue, reject_on_worker_lostTruehead 级去重保证重投安全。验证器给出的在库先例products/visual_review/backend/tasks/tasks.py、posthog/tasks/exporter.py 等对同类 GitHub 幂等任务都设置了这两个标志。opt-out 路径遗留旧评审工作流活跃must_fix降为 should_fix—— tasks.py L881-898。 skip 分支只撤销已存审批不SUPERSEDED排队/评审中的 run旧工作流可能在新 push 之前取 head然后在工作流返回后贴出审批。post_verdict三道守卫中第三道GitHub 写入前的superseded_now数据库读取恰好为这类窗口而设。降级理由窗口要求 push 落进 fetch-to-write 间隙且该缺口在所有skip 路径上先于本 PR 存在下一次 head 变更投递会自动清扫孤儿。opt-out 撤销漏掉 GitHub 侧孤儿审批must_fix降为 consider—— tasks.py L894-898。dismiss_stale_approvals_for_head只查posted_review_id__isnullFalseapprovals.py L44-55worker 在「POST 成功 → 回写 id」的亚秒间隙内死亡、且工作流永不重试完成、且永不到达 terminal 处理三层防护同时失效才会留下无 DB 记录的活审批。降级理由这是既有缺口修复成本每次 skipped head 变更都加一次 GitHub 审批列表调用大于风险。「未绑定上下文标志不应被信任」must_fix否决—— 冻结树内tools/pr-approval-agent/review_local.pyL316-324。 这条否决是 Opus 5 裁决风格的典型验证器指出上下文 JSON 只在沙箱启动前由服务端渲染沙箱内代码无法置位ReviewRun.output无 API 写路径只读SerializerMethodFieldreceiver 腿的 task 关联在上游已被校验signal_report_id 非 internal 同 team 内解析启用的仓库配置。结论所述攻击「没有可达的攻击者」must_fix高估了它。「取消的实现 run 仍满足 carve-out 资格」should_fix否决—— facade/api.py L502-509。 验证器发现返回终态 run 是有意设计post-merge 事件需要经由 pr_url 腿解析且「终态」包含常规的 cloud-to-local 交接run 被标记 cancelled拒绝它会让后续每次 push 都走 skip 路径并撤销在途审批——是功能回归而非收紧。5.4 其余保留/否决各 1 条较旧的 completed run 可遮蔽最新的 failed 复审should_fix降为 consider—— tasks.py L1202-1209exclude(status__in(SUPERSEDED, FAILED))在按created_at排序之前执行同 head 的旧 completed run 会赢过更新的 failed run。触发需要三重条件巧合同 head 二次 run 失败 后续 output 保存重触发后果是缺裁决而非错误审批。子环境 PR 永远收不到 Stamphog 复审should_fix保留—— receivers.py L144-154、L180-184StamphogRepoConfig继承的save()把team_id规范化到父团队而TaskRun/Task/SignalReport保持环境 team idfind_signal_implementation_run的run.team_id ! team_id是精确比较于是首次评审走规范化查询成功、后续 push 永远失败且 skip 分支会用「不受信任作者」的理由误导排障。fail-soft 检查可拖慢请求、刷爆错误日志should_fix否决—— settings.py L77-81验证器核实该端点不是热点前端仅在场景挂载时加载一次10s 轮询驱动的是别的查询且最坏延迟被connect_timeout3与共享 Redis 熔断器posthog/db_circuit_breaker.py30s 窗口内 3 次失败全 Pod 共享一个 open 标记限制在「一次约 3 秒」。broker 故障永久丢失首次评审should_fix否决—— receivers.py L224-234吞掉发布异常是既定的 best-effort 约定docstring 明示 broker 故障绝不能冒泡进 saver且 receiver 每次 output 保存都会重触发、head 键去重行锁保证重发安全、webhook 腿在后续 push 时兜底——为 opt-in 评审新建 outbox 表「与风险不成比例」。资格过滤在选定 run 之后才执行should_fix否决—— facade/api.py L504-506两条腿都有确定性排序pr_url 腿非终态优先 -created_atsignals run 必然持有该 PR URL 因而必是候选更窄的检索会让两条腿对「哪个 run 拥有这个 PR」产生分歧。former 项目成员仍是审批评审人must_fix否决—— receivers.py L151-154、L202-207acting user id 在该腿只是溯源信息从不被读回做决策真正授予能力的身份沙箱凭据铸造者connected_by_user_id在is_active检查处 fail closed组织成员解析是跨产品统一约定单独换用Team.all_users_with_access()反而会让评审门与 Inbox「For you」过滤、Slack 扇出互相矛盾。Hosted bot 谓词漏掉posthog-botshould_fix降为 consider—— products/stamphog/AGENTS.md L82-90文档声称posthog-bot在每一层被拒绝但 hosted 侧_is_bot_authoredtasks.py L149 附近只查type Bot或[bot]后缀放它过了预过滤直到引擎层才被拒。后果是浪费一次沙箱与公开拒绝评论安全边界仍成立该 PR 无self_driving印章故降为 consider 的文档准确性问题。5.5 从这 22 条裁决中能读出的「验证器行为画像」反驳式证据链每条 Validator 段都以Checked声明核查范围开头再逐条Found给出文件行号证据最后Impact收口并给出Priority是否调整及理由。这是 FINAL_REPORT 所称「refutation-first」验证风格的可复现样例优先级降级是常见动作L2 的 12 条保留中至少 6 条被降档两条 must_fix→should_fix/consider、多条 should_fix→consider每次都附具体理由触发条件数量、后果性质、缺口是否既有、修复成本比对否决理由指向「设计约定」而非「代码错误」broker 吞异常、返回终态 run、组织成员解析三条被否决验证器都引用了 docstring/注释/兄弟路径来证明这是有意的系统姿态避免「防御性加固」类建议通过验证器自我纠错两条 finding 的裁决里嵌入了「(correction)」「(refinement)」「(accuracy note)」验证器在确认核心结论的同时修正 finding 作者过强的子论断——这解释了为何打分时它保留 8 条而非「全对」。6. 打分协议真值从哪来L2 的 22 条发现按 FINAL_REPORT.md 的协议判分每条发现先与 76 个「已知问题簇」known_clusters.json构建自 2026-07 reviewer 实验的 judge 文件匹配匹配记录在 LB.match.json落在一致簇里的发现直接继承簇的 real / not-real 裁决落在混合簇或簇外的发现逐条对冻结工作树做「反驳优先」的全新验证findings/verify/LB*.json相同论断复用先前裁决真值与打分落盘为 LB.truth.json 与 LB.score.md。L2 最终账目与 xhigh_summary.md 一致| 指标 | L2 | | ---- | -- | | 裁决发现数 | 22 | | 保留 | 128 真 / 4 假 | | 保留精度 kept-real | 8/12 67% | | 真问题召回 real-kept | 8/11 73% | | 假问题否决率 not-real dropped | 7/11 64% | | 验证墙钟 / 网关费用 | 26 min / $23.42176 次调用 | | 单裁决成本 | $1.06 |漏掉的 3 条真问题LB10 上下文标志 must_fix、LB13 canceled-run carve-out should_fix、LB17 hosted WAIT 遥测 should_fix是 L 臂两次运行中 Opus 的漏检样本FINAL_REPORT 指出其中「toggle 论断」在 L1 被否决、在 L2 又被保留说明 22 条样本量下存在一定运行间噪声。7. 横向对照L2 在整个实验中是什么位置八次运行的汇总xhigh_summary.md评审器均为 SolL 臂为 Opus 5 验证器、M 臂为 Sol 验证器、N 臂为 Sonnet 5 验证器LA (Opus 5)LB (Opus 5)MA (Sol)MB (Sol)NA (Sonnet 5)NB (Sonnet 5)裁决发现数232219202222保留精度9/11 (82%)8/12 (67%)11/18 (61%)12/18 (67%)8/16 (50%)11/22 (50%)真问题召回9/12 (75%)8/11 (73%)11/12 (92%)12/13 (92%)8/11 (73%)11/11 (100%)假问题否决率9/11 (82%)7/11 (64%)0/7 (0%)1/7 (14%)3/11 (27%)0/11 (0%)验证费用 / 单裁决$24.35 / $1.06$23.42 / $1.06$13.62 / $0.72$15.97 / $0.80$10.53 / $0.48$11.72 / $0.53实验结论FINAL_REPORT「Recommendation」真实 xhigh 下 Sol 验证器仍保留 19–20 条中的 18 条、几乎不扔假发现成本优势缩水到约 30%/verdict继续用 Opus 作为验证器xhigh 的价值在评审器侧3 倍真发现、8 个此前 18 次评审未报出的真问题代价约 $26/次评审。L2 作为 L 臂第二次运行其 67% 精度 / 73% 召回 / $1.06 单裁决正是这条结论里「Opus 基线」的数据来源之一。8. 复现一次 L2 式运行PLAN.md 给出了完整 run recipeflox activate -- bash -c DJANGO_SETTINGS_MODULEposthog.settings python manage.py \ run_review --pr-url 被评审 PR 的 URL --team-id 1 --user-id 1 LABELL-opus5-validator-2 RUN_SECONDSs RUN_START_EPOCHepoch OUT_DIR$PWD/runs \ python manage.py shell -c exec(open(products/review_hog/eval/scripts/dump_result.py).read())复现适用前提与限制均来自 PLAN.md 的「Experiment hacks」与 tree state 记录属实验期本地改动非生产配置需要本地 dev 环境flox 环境 Django Temporal 本地沙箱运行时run_review管理命令驱动整条流水线实验为保证跨运行可比做了四处本地 hackfetch_pr_comments返回[]零评论干净房、split_chunks_activity在存在pinned_chunks.json时加载固定分块、VALIDATION_*改写到目标模型、MAX_CONCURRENT_SANDBOXES10→4沙箱镜像需带 effort 透传修复与 Codex 重试参数stream_max_retries10等否则 xhigh 评审波次会在网关隧道抖动时整波失败网关遥测可用 kafka_ai_usage.py 离线复算阶段耗时与漏斗表由 parse_dump.py、summarize_runs.py 生成运行结束后删除该 PR 的报告即可无需全库清理VALIDATION_*与REVIEW_REASONING_EFFORT需恢复生产值。9. 结语这份 dump 的三种读法作为流水线度量漏斗表26 → 22 → 12与阶段耗时表给出「每评审单元成本、验证阶段占比」的量化骨架是评审系统调优视角裁剪、分块粒度、验证器并发的直接依据作为验证器能力样本22 条 Checked/Found/Impact/Priority 证据链展示了反驳式验证的完整形态包括降级、否决与自我纠错三种裁决动作可作提示词设计与评审技能validation skill调校的对照样本作为模型选型证据配合 FINAL_REPORT.md 的八运行对照L2 的 67%/73%/64% 与 $1.06/verdict 构成「保持 Opus 验证器」这一结论的对照基线。一个必要的引用边界说明转储中大量行号如tools/pr-approval-agent/reviewer.py:699、tasks.py:1202锚定在冻结的 PR 树a7fb363b/1341596e上其中tools/pr-approval-agent/目录在当前仓库主干中已不存在该特性代码已演进而products/stamphog/、products/review_hog/、products/tasks/下的路径在当前主干仍有效但行号可能有漂移。引用这些发现时应以冻结树为锚把行号视为实验时点的快照而非当前代码坐标。【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考