PostHog ReviewHog 通宵实验运行日志深度解读验证模型对比Opus 5 vs GPT-5.6 Sol的工程化实践【免费下载链接】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导读本文围绕 PostHog 仓库中 ReviewHog 验证模型validator对比实验的一次通宵运行记录展开。实验核心问题只有一个gpt-5.6-solCodex 多轮会话能否在更低成本、更短耗时下替代 Claude Opus 成为 ReviewHog 的验证模型且不损失判定质量本文以原始操作日志 runs/overnight-2026-08-26.notes.md 为骨架结合同目录的 PLAN.md 与 FINAL_REPORT.md 展开逐条解读时间线中的故障模式、缓解手段、成本核算方法与最终评分结论。读完本文你将掌握如何在长跑型 AI 评测实验中做运行环境准备、故障复盘、成本追踪基于 LLM 网关事件以及严格的判定质量评分。一、实验背景为什么要做验证模型对比ReviewHog 是 PostHog 的代码评审 Agent 体系其流水线分为几个阶段review评审→ blind-spot盲区补充→ dedup去重→ validation验证。其中 validation 阶段负责对评审出的每条 finding 逐条核实决定保留还是丢弃是控制误报not-real findings的关键闸门。本次实验2026-08-validator-model-sol的核心问题写在该实验目录的 PLAN.md 中Question:doesgpt-5.6-sol(Codex) match Claude Opus as the validation model, at lower cost and time?实验设计要点冻结的 PR 与管线复用与评审模型实验../2026-07-reviewer-model-glm52/相同的冻结 PR#75215 a7fb363树等同1341596e、相同的固定 chunkpinned_chunks.json与零评论clean room环境保证两轮实验可比对照组已有 Sol 评审 claude-opus-4-8验证的 I1/I2 数据Opus 4.8 与 Opus 5 被视为同一验证器运行矩阵两轮 GPTGPTSol 评审 Sol 验证串行运行不发布评分方法把每条新 finding 匹配到已知问题注册表76 个 clusterjudge-round5/6.json复用其 real / not-real 判定只对未匹配上的 finding 做人工核验。按验证器统计real findings 保留多少、not-real findings 丢弃多少。二、运行前的三条前置条件修复PLAN.md 记录了开跑前必须先解决的三件事这也是本实验能跑通的前提Codex 多轮会话可用性用scripts/codex_mts_smoke.py做了三回合冒烟测试——同一 Codex 会话连续三轮线程跨 follow-up 保持历史能回忆出 secret word证明多轮能力成立Sandbox MCP 自 2026-08-13 起被拒REVIEW_MCP_SCOPES缺少user:read导致 MCP 服务器无法打开会话所有 ReviewHog 会话都没带技能运行。在 #88697 修复冒烟测试中 follow-up 回合的skill-get能取回验证技能本地沙箱镜像构建在 master 上被 #88274 破坏DEBUG 构建上下文缺products/desktop/packages/agent-shadow/在 #88698 修复。此外实验需要三处未提交的本地 hack跑完需还原tools/github_meta.py::fetch_pr_comments→return []屏蔽评论temporal/activities.py::split_chunks_activity在存在pinned_chunks.json时加载固定 chunkproducts/review_hog/backend/reviewer/constants.py中VALIDATION_*常量切换为 codex / gpt-5.6-sol / xhigh / full-access。三、运行配方与自动化脚本harness标准单轮运行命令flox 环境 Django 管理命令flox activate -- bash -c DJANGO_SETTINGS_MODULEposthog.settings python manage.py \ run_review --pr-url https://github.com/PostHog/posthog/pull/75215 --team-id 1 --user-id 1 LABELK-sol-validator-1 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())配套的运维脚本位于 scripts/harness/run.sh启动一轮仅数据库的 PR 75215 评审记录 start/end epoch 到 scratch 目录REVIEWHOG_EXP_SCRATCH日志落盘后追加退出码set_arm.py通过正则精确替换constants.py中VALIDATION_RUNTIME_ADAPTER / VALIDATION_MODEL / VALIDATION_REASONING_EFFORT / VALIDATION_INITIAL_PERMISSION_MODE四连块支持三档 arm——Lclaude/claude-opus-5/xhigh/ None即生产 pin、Mcodex/gpt-5.6-sol/xhigh/full-access、Nclaude/claude-sonnet-5/xhigh/ Nonewatch.sh每 60 秒轮询 Postgres当 75215 报告的状态或 artefact 计数变化时打印一行运行结束时退出同时监控 temporal worker 是否掉线。这些 pin 在生产代码中的默认位置是 products/review_hog/backend/reviewer/constants.pyVALIDATION_RUNTIME_ADAPTER RuntimeAdapter.CLAUDE、VALIDATION_MODEL claude-opus-5、VALIDATION_REASONING_EFFORT ReasoningEffort.XHIGH、VALIDATION_INITIAL_PERMISSION_MODE None而MAX_CONCURRENT_SANDBOXES 10位于同文件 L228-L232是每个 Temporal fan-outreview/validate通过asyncio.Semaphore控制的并发上限。四、通宵运行时间线01:32–06:27 的操作日志解读原文档是raw operator log原始操作员日志按时间顺序记录了 5 小时内发生的一切。以下按阶段展开。4.1 开局worker 崩溃与第一次沙箱创建失败01:32–01:4101:32constants.py被设置为 arm LClaude / claude-opus-5 / xhigh / None。此前phrocstemporal-worker 自 22:49 起已崩溃K3 期间 nodemon 约 58 次重启后出现spawn EBADF01:32:31 手动重启01:34:02第一轮尝试开始report 创建01:35 完成 perspective_selection01:34:33attempt 1 创建 8 个评审沙箱时create_sandbox失败SandboxProvisionError。根因是本地 Modal 构建刷新了products/posthog_ai/dist/skills/*.pyLocalSkillsCache 过期nodemon 在构建中途重启了 worker约 70 次重启01:37 手动重启 worker 后 skills 缓存哈希匹配不再触发重建。这一节直接对应 FINAL_REPORT 的 bug 8LocalSkillsCache.ensure_built()在create_sandbox_for_repository内重写products/posthog_ai/dist/skills/**/*.py而开发 worker 的 nodemon 监听products/**/*.py于是构建途中 worker 被 SIGTERM——仅影响开发环境解决办法是从 nodemon 监听中排除该目录或在 worker 之外构建 skills。4.2 attempt 2运行中途写 .py 文件导致的整轮失败01:41–01:5101:41–01:45attempt 2 拉起 8 个沙箱01:45 effort guard 放行32 次gpt-5.6-sol评审调用全部 xhigh$2.9401:46:15操作员在products/下写了scripts/reviewer_stats.py→ nodemon SIGTERM → worker 排空至 01:51:15 才重启attempt 2 在 01:51:41 失败浪费约 $3–5 和 17 分钟。由此诞生一条硬性操作规则运行期间严禁在products/下写任何.py文件。这解释了为什么本次实验的辅助脚本reviewer_stats.py、build_truth.py、summarize_runs.py等全部放在scripts/下且要在非运行窗口编写。4.3 attempt 3 与8/8 全灭故障01:51–02:2401:51:42attempt 3 启动8 个沙箱agent server 01:52:44–50 就绪~35 次调用集中在 01:52:50–01:53:2501:53:478 个回合全部以stopReasonrefusal结束且全部出现在cat .agents/skills/...SKILL.md之后伴随 Failed to signal task completion: fetch failed。这是 K3 的 bug 6 模式当时是 4/9这次变成 8/8。worker 只能等待 1800 秒的 poll 超时预期 ~02:23 重试01:52review-perspectives 的 child run 1 失败Review: 8/8 units failed父流程重试出 run 201:51:42 启动8 个review_chunk_activity处于 attempt 1/2持续 heartbeat02:20Modal 探测三个隧道全部 1 s 返回 20001:53 只是瞬时抖动不是边缘节点故障。沙箱镜像中的 agent 为posthog/agent2.4.8702:24:20重试波attempt 2/2以相同方式全灭codex stream disconnected before completion: error sending request (gateway tunnel)willRetryfalseagent 向 django 的 fetch failed8 个在 5 秒内先后发生距 agent 启动约 60 秒。ngrok inspector 显示 02:23:55–02:25:23约 85 秒内没有沙箱请求到达本机而几分钟后的 Modal 探测一切正常。形态与 01:53 及 K3 的 4/9 完全相同且镜像中 agent 2.4.87 并非诱因K3 的 2.4.86 也出现过02:33终止review-pr:1:posthog/posthog:75215无剩余 attempts32 个 Modal 沙箱均已退出rc 137删除报告attempt-1 文件保留为L1-attempt1.*。这一节的底层机制在 FINAL_REPORT 的 bug 7 中有详细解释Codex 的 provider 配置agent 的spawn.ts只设置了stream_idle_timeout_ms重试次数保持 Codex 默认值退避为 200ms × 2ⁿ——默认 5 次流重试约 13 秒就放弃远不够覆盖约 85 秒的网关路径抖动。8 个并发 xhigh 首请求把 K3 的 4/9 放大成了 8/8。4.4 缓解措施local hacks02:42针对上述故障操作员在本地打了两个补丁Dockerfile.sandbox-base中第二个 sedcodexstream_max_retries10、request_max_retries10退避 200ms×2ⁿ ≈ 200 秒、SANDBOX_STREAM_IDLE_TIMEOUT_MS90s → 300sconstants.py中MAX_CONCURRENT_SANDBOXES10 → 4预计首个沙箱触发镜像重建约 10 分钟。效果立竿见影后续四轮全部零 turn 失败。4.5 四轮正式运行L1 / M1 / L2 / M202:40–06:27缓解后按 LOpus 5 验证→ MSol 验证交替完成四轮轮次时段耗时原始→去重→有效评审阶段验证验证成本网关备注L102:40:39–03:54:534432 s28→23→11 valid34m26s并发 4内含 ~6 min 镜像重建03:24–03:544 个 Opus 会话 23 条判定验证 Opus $20.76134 calls Sonnet 辅助 $3.60126评审 $17.98246 calls85k reasoningM103:57:00–04:38:122455 s24→19→18 valid25m57s无重建04:25–04:384 个 Sol 会话 19 条判定~40 s/条验证 $13.62173 calls40.6k reasoning评审 $17.84255 callsL204:39:56–05:38:083491 s26→22→12 valid28m02s05:12–05:3822 条判定验证 Opus $23.42176 calls评审 $17.32244 callsM205:39:43–06:26:542792 s26→20→18 valid27m35s06:10–06:2620 条判定验证 $15.97161 calls44k reasoning评审 $18.50276 calls其他细节effort guard读取首批评审调用与首批验证调用的$ai_effort每轮都通过每轮结束删除报告不全局清库只删 PR 75215 报告arm 轮换L1 后 set LA、L2 后 set LB、M1 后 set MA、M2 后 set MB06:27 全部结束后VALIDATION_*恢复为生产 pinarm L。五、成本核算方法从 agent 日志到网关事件原日志中的成本数字全部来自 LLM 网关gateway计费这是一个重要的方法论修正点K1–K3 期间最初用 agent 日志usage_from_logs.py后被移除统计成本但该方法每回合只统计最后一次 LLM 调用低估 3–4 倍ACP 每回合 usage 是回合内最后一次 LLM 调用而非工具往返的总和权威口径改为直接读本地 Kafka 主题events_plugin_ingestion_ai上的$ai_generation事件——因为本地 ingestion 被 personhog :50052 阻塞事件滞留未消费正好提供了完整审计窗口。脚本为 scripts/kafka_ai_usage.py按RUN_START_EPOCH/RUN_END_EPOCH时间窗扫描提取每次调用的 stage、model、input/cache/ouput/reasoning token、$ai_total_cost_usd与$ai_effort并按阶段家族issues-review*→ review、blind-spots*→ blind-spot、validation*→ validation汇总成表计费单价以网关的 LiteLLM 费率为准$4 / $20 每百万 in/out$0.40 cache read。Opus 侧数字沿用 7 月 dump 的 cache-aware 列表价。结论Sol 验证每判定成本约 $0.72–0.80Opus 约 $1.06——xhigh 下成本差距缩到 ~30%而非 low 时代的 4–5 倍。六、Effort pin 之谜为什么此前 Sol 一直以 low 在跑日志中$ai_effort反复出现对应本实验最重要的技术发现——effort pin 从未到达 Codex详见 FINAL_REPORT.md 同名章节证据K1/K2/K3 中每次gpt-5.6-sol调用含验证、评审、盲区都携带$ai_effortlow而同批 Sonnet one-shots 是xhigh沙箱侧一切却都写着maxTaskRun.state.reasoning_effort、POSTHOG_CODE_REASONING_EFFORTenv、Codex 会话session/new结果里的effort max生产环境同样中招自至少 2026-08-04 起 21 天内每天 100% 的gpt-5.6-sol调用都是low。也就是说生产 50/50 A/B2026-08-03 起的 Sol 臂、以及 7 月的评审模型实验、K1–K3全部实际运行在 low effort机制agent镜像中 2.4.86打包openai/codex0.144.0的 Codex 适配器在每次turn/start同时发送effort参数和由collaborationModeForTurn()构造的collaborationMode对象其 settings 只含{ model }。Codex 在收到 collaboration mode 时会原样采用仅当未发送时才应用独立的effortcodex-rs/core/src/codex_thread.rs的preview_thread_settings_overrides路径。由于该 mode 没有reasoning_effort每回合都回退到 Codex 自带模型目录models.json里的默认值gpt-5.6-sol默认low。Claude 适配器通过 session meta 透传 effort所以 Opus 一直正常为xhigh修复PR #88893在collaborationModeForTurn().settings中加入reasoning_effort: this._effort或仅当 mode 未变时不发送 collaborationMode。验证方式agent 发布进入沙箱镜像后检查一轮运行首批 Codex 调用的$ai_effort。日志中 01:45 的 effort guard32 次评审调用全 xhigh表明缓解措施生效后本地镜像打上 sed 补丁真实 xhigh 终于到达了 Codex。七、评分协议与四轮结果四轮 scoring 在 03:55–06:45 完成操作员记录 Scoring the four runs每个 finding 集LA/MA/LB/MB由一个 agent 匹配到 76 个已知 clusterknown_clusters.json由 7 月 judge 文件构建意见一致的 cluster 直接采用注册表判定完全相同的 claim 复用 K/7 月判定26 条混合 cluster 或全新 claim 对冻结 worktree 做先反驳后验证refutation-first的人工核验findings/verify/产出 truth 文件findings/*.truth.json、评分findings/*.score.md、四轮汇总表findings/xhigh_summary.md、评审侧统计findings/reviewer_side.md与盲评findings/argumentation_judge_L_vs_M.json。xhigh_summary.md 汇总的关键指标LA/LB/MA/MB 四轮指标L1L2M1M2判定 findings23221920保留11121818保留中为 real9/11 (82%)8/12 (67%)11/18 (61%)12/18 (67%)real 保留率recall9/12 (75%)8/11 (73%)11/12 (92%)12/13 (92%)not-real 丢弃率9/11 (82%)7/11 (64%)0/7 (0%)1/7 (14%)每判定成本$1.06$1.06$0.72$0.80核心结论Sol 验证器几乎什么都不丢每轮只丢 1 条且是同一个 real finding——webhook 站点上的 secondary-reviewer toggle 副本 MA5/MB11却保留了它此前在 low 时代就保留的三类弱 claimunscopedfind_task_run查找、broker/retry 加固诉求、队列时间 toggle。xhigh 没有抬高它的门槛Opus 5 更严格两轮丢弃 22 条 not-real 中的 16 条保留 23 条 real 中的 17 条每判定 $1.06盲评Sol 的 write-up 中位 126 词 vs Opus 335 词29 组配对中 Opus 在证据与验证维度赢 21 组——Sol 更多是复述 finding 而非检验它且一轮内部判定自相矛盾丢弃 webhook 站点副本却保留 receiver 站点副本评审侧意外收获Sol 评审在 xhigh 下每轮产出 11–13 条 real findingslow 时代 3–4 条其中 8 条是此前 18 次评审从未报过的新问题含 1 条must_fixwebhook facade 的调用方可写 task attribution 授权漏洞 LA15MA9MB17。但评审成本从 ~$6 涨到 ~$26/轮。八、结论与工程建议来自实验交付FINAL_REPORT 的建议可操作化为五条验证器保留 Opus。真实 xhigh 下 Sol 依然保留 18/19–20 条、几乎不丢 not-real0/7、1/7成本优势缩至 ~30%Sonnet 5 是半价的同款故事保留 16/22、22/2250% real更便宜的 Claude 层级也救不了。Sol 作为验证器唯一剩下的变量是更严格的先反驳提示词上线 effort 修复#88893并用 xhigh 跑 Sol 评审。修复落地后所有 Codex 沙箱ReviewHog 评审/盲区、其他 Codex Tasks将从 low 切到 pin 的 effort评审侧每轮 real findings 提升约 3 倍、单 PR 发现 8 条新问题代价是 ~$26/轮与 25–35 分钟的评审阶段并发 4 下测得生产可测并发 10。若价格是障碍medium是回退档每轮 7 条 real、~$10.50、12–14 分钟但两轮中未发现新问题在 agent 发布前加固 Codex 回合对网关抖动的韧性bug 7在 agent 的 codex provider 配置里设置重试次数并重试 completion signal否则生产 xhigh 波次会在网关路径抖动 ~15 秒时像本地一样整波死亡重新解读生产 50/50 A/B其 Sol 臂从未真正以 xhigh 运行修复后对比要重来实验结束后还原 hackDockerfile.sandbox-base两行 sed、fetch_pr_comments的return []、split_chunks_activity的 chunk pin、MAX_CONCURRENT_SANDBOXES 4VALIDATION_*已还原为生产 pin。九、运行中的其他故障清单Bug registry 摘录通宵日志中暴露的故障在 FINAL_REPORT.md 的 Bugs found on the way 中被系统化为 9 条其中与通宵日志直接相关的有bug 6Codex turn 卡死可钉住沙箱 30 分钟——K3 中 4/9 沙箱在 5 秒窗口内以stopReasonrefusal结束且无法回报完成fetch failedworker 等满 1800 秒 poll 超时后重试4 次重试 ~3 分钟全部成功属共享网关/隧道抖动而非提示词问题代价只是墙钟时间bug 7Codex 在隧道抖动 ~13 秒内放弃详见 4.3bug 8本地 Modal 镜像构建重启开发 worker详见 4.1bug 9Opus 验证会话自行扇出到 Sonnet——L1 验证阶段 134 次 Opus 调用旁还有 126 次claude-sonnet-5调用Claude 会话自己的 sub-agent$3.60 / $24.35均标记validation-*做任何按模型拆分成本时必须包含它们。此外还有两条通宵前的已知问题ReviewHog 沙箱无 MCP#88697已合并与评审沙箱自 2026-07-15 起检出了 master 而非 PR#88775Tasks 的 checkout 只解析refs/heads/namepull/N/head解析失败后回退到 master 新分支K1 因此在错误的树上判定被保留为 before/after 数据点。十、参考资料索引本次实验的完整证据链都保留在该实验目录下便于读者继续深挖原始操作日志runs/overnight-2026-08-26.notes.md本文骨架另含 N/P 两臂次日补充轮次的完整时间线见 PLAN.md实验设计决策与运行配方PLAN.md最终结论与全部 bug 清单FINAL_REPORT.md八轮汇总指标表findings/xhigh_summary.md评分脚本scripts/score_validator.py、truth 草稿生成scripts/build_truth.py、成本统计scripts/kafka_ai_usage.py、多轮冒烟scripts/codex_mts_smoke.py运行 harnessscripts/harness/run.sh、scripts/harness/set_arm.py、scripts/harness/watch.sh验证 pin 的生产默认值products/review_hog/backend/reviewer/constants.py并发上限见 同文件 L228-L232pin 合法性测试见 products/review_hog/backend/reviewer/tests/test_constants.py。一次成功的通宵 AI 评测实验靠的不只是跑两条命令而是对沙箱供给、worker 生命周期、隧道可靠性、成本计量口径与评分协议的全链路控制——这正是这份操作日志的价值所在。【免费下载链接】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 通宵实验运行日志深度解读：验证模型对比（Opus 5 vs GPT-5.6 Sol）的工程化实践
PostHog ReviewHog 通宵实验运行日志深度解读验证模型对比Opus 5 vs GPT-5.6 Sol的工程化实践【免费下载链接】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导读本文围绕 PostHog 仓库中 ReviewHog 验证模型validator对比实验的一次通宵运行记录展开。实验核心问题只有一个gpt-5.6-solCodex 多轮会话能否在更低成本、更短耗时下替代 Claude Opus 成为 ReviewHog 的验证模型且不损失判定质量本文以原始操作日志 runs/overnight-2026-08-26.notes.md 为骨架结合同目录的 PLAN.md 与 FINAL_REPORT.md 展开逐条解读时间线中的故障模式、缓解手段、成本核算方法与最终评分结论。读完本文你将掌握如何在长跑型 AI 评测实验中做运行环境准备、故障复盘、成本追踪基于 LLM 网关事件以及严格的判定质量评分。一、实验背景为什么要做验证模型对比ReviewHog 是 PostHog 的代码评审 Agent 体系其流水线分为几个阶段review评审→ blind-spot盲区补充→ dedup去重→ validation验证。其中 validation 阶段负责对评审出的每条 finding 逐条核实决定保留还是丢弃是控制误报not-real findings的关键闸门。本次实验2026-08-validator-model-sol的核心问题写在该实验目录的 PLAN.md 中Question:doesgpt-5.6-sol(Codex) match Claude Opus as the validation model, at lower cost and time?实验设计要点冻结的 PR 与管线复用与评审模型实验../2026-07-reviewer-model-glm52/相同的冻结 PR#75215 a7fb363树等同1341596e、相同的固定 chunkpinned_chunks.json与零评论clean room环境保证两轮实验可比对照组已有 Sol 评审 claude-opus-4-8验证的 I1/I2 数据Opus 4.8 与 Opus 5 被视为同一验证器运行矩阵两轮 GPTGPTSol 评审 Sol 验证串行运行不发布评分方法把每条新 finding 匹配到已知问题注册表76 个 clusterjudge-round5/6.json复用其 real / not-real 判定只对未匹配上的 finding 做人工核验。按验证器统计real findings 保留多少、not-real findings 丢弃多少。二、运行前的三条前置条件修复PLAN.md 记录了开跑前必须先解决的三件事这也是本实验能跑通的前提Codex 多轮会话可用性用scripts/codex_mts_smoke.py做了三回合冒烟测试——同一 Codex 会话连续三轮线程跨 follow-up 保持历史能回忆出 secret word证明多轮能力成立Sandbox MCP 自 2026-08-13 起被拒REVIEW_MCP_SCOPES缺少user:read导致 MCP 服务器无法打开会话所有 ReviewHog 会话都没带技能运行。在 #88697 修复冒烟测试中 follow-up 回合的skill-get能取回验证技能本地沙箱镜像构建在 master 上被 #88274 破坏DEBUG 构建上下文缺products/desktop/packages/agent-shadow/在 #88698 修复。此外实验需要三处未提交的本地 hack跑完需还原tools/github_meta.py::fetch_pr_comments→return []屏蔽评论temporal/activities.py::split_chunks_activity在存在pinned_chunks.json时加载固定 chunkproducts/review_hog/backend/reviewer/constants.py中VALIDATION_*常量切换为 codex / gpt-5.6-sol / xhigh / full-access。三、运行配方与自动化脚本harness标准单轮运行命令flox 环境 Django 管理命令flox activate -- bash -c DJANGO_SETTINGS_MODULEposthog.settings python manage.py \ run_review --pr-url https://github.com/PostHog/posthog/pull/75215 --team-id 1 --user-id 1 LABELK-sol-validator-1 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())配套的运维脚本位于 scripts/harness/run.sh启动一轮仅数据库的 PR 75215 评审记录 start/end epoch 到 scratch 目录REVIEWHOG_EXP_SCRATCH日志落盘后追加退出码set_arm.py通过正则精确替换constants.py中VALIDATION_RUNTIME_ADAPTER / VALIDATION_MODEL / VALIDATION_REASONING_EFFORT / VALIDATION_INITIAL_PERMISSION_MODE四连块支持三档 arm——Lclaude/claude-opus-5/xhigh/ None即生产 pin、Mcodex/gpt-5.6-sol/xhigh/full-access、Nclaude/claude-sonnet-5/xhigh/ Nonewatch.sh每 60 秒轮询 Postgres当 75215 报告的状态或 artefact 计数变化时打印一行运行结束时退出同时监控 temporal worker 是否掉线。这些 pin 在生产代码中的默认位置是 products/review_hog/backend/reviewer/constants.pyVALIDATION_RUNTIME_ADAPTER RuntimeAdapter.CLAUDE、VALIDATION_MODEL claude-opus-5、VALIDATION_REASONING_EFFORT ReasoningEffort.XHIGH、VALIDATION_INITIAL_PERMISSION_MODE None而MAX_CONCURRENT_SANDBOXES 10位于同文件 L228-L232是每个 Temporal fan-outreview/validate通过asyncio.Semaphore控制的并发上限。四、通宵运行时间线01:32–06:27 的操作日志解读原文档是raw operator log原始操作员日志按时间顺序记录了 5 小时内发生的一切。以下按阶段展开。4.1 开局worker 崩溃与第一次沙箱创建失败01:32–01:4101:32constants.py被设置为 arm LClaude / claude-opus-5 / xhigh / None。此前phrocstemporal-worker 自 22:49 起已崩溃K3 期间 nodemon 约 58 次重启后出现spawn EBADF01:32:31 手动重启01:34:02第一轮尝试开始report 创建01:35 完成 perspective_selection01:34:33attempt 1 创建 8 个评审沙箱时create_sandbox失败SandboxProvisionError。根因是本地 Modal 构建刷新了products/posthog_ai/dist/skills/*.pyLocalSkillsCache 过期nodemon 在构建中途重启了 worker约 70 次重启01:37 手动重启 worker 后 skills 缓存哈希匹配不再触发重建。这一节直接对应 FINAL_REPORT 的 bug 8LocalSkillsCache.ensure_built()在create_sandbox_for_repository内重写products/posthog_ai/dist/skills/**/*.py而开发 worker 的 nodemon 监听products/**/*.py于是构建途中 worker 被 SIGTERM——仅影响开发环境解决办法是从 nodemon 监听中排除该目录或在 worker 之外构建 skills。4.2 attempt 2运行中途写 .py 文件导致的整轮失败01:41–01:5101:41–01:45attempt 2 拉起 8 个沙箱01:45 effort guard 放行32 次gpt-5.6-sol评审调用全部 xhigh$2.9401:46:15操作员在products/下写了scripts/reviewer_stats.py→ nodemon SIGTERM → worker 排空至 01:51:15 才重启attempt 2 在 01:51:41 失败浪费约 $3–5 和 17 分钟。由此诞生一条硬性操作规则运行期间严禁在products/下写任何.py文件。这解释了为什么本次实验的辅助脚本reviewer_stats.py、build_truth.py、summarize_runs.py等全部放在scripts/下且要在非运行窗口编写。4.3 attempt 3 与8/8 全灭故障01:51–02:2401:51:42attempt 3 启动8 个沙箱agent server 01:52:44–50 就绪~35 次调用集中在 01:52:50–01:53:2501:53:478 个回合全部以stopReasonrefusal结束且全部出现在cat .agents/skills/...SKILL.md之后伴随 Failed to signal task completion: fetch failed。这是 K3 的 bug 6 模式当时是 4/9这次变成 8/8。worker 只能等待 1800 秒的 poll 超时预期 ~02:23 重试01:52review-perspectives 的 child run 1 失败Review: 8/8 units failed父流程重试出 run 201:51:42 启动8 个review_chunk_activity处于 attempt 1/2持续 heartbeat02:20Modal 探测三个隧道全部 1 s 返回 20001:53 只是瞬时抖动不是边缘节点故障。沙箱镜像中的 agent 为posthog/agent2.4.8702:24:20重试波attempt 2/2以相同方式全灭codex stream disconnected before completion: error sending request (gateway tunnel)willRetryfalseagent 向 django 的 fetch failed8 个在 5 秒内先后发生距 agent 启动约 60 秒。ngrok inspector 显示 02:23:55–02:25:23约 85 秒内没有沙箱请求到达本机而几分钟后的 Modal 探测一切正常。形态与 01:53 及 K3 的 4/9 完全相同且镜像中 agent 2.4.87 并非诱因K3 的 2.4.86 也出现过02:33终止review-pr:1:posthog/posthog:75215无剩余 attempts32 个 Modal 沙箱均已退出rc 137删除报告attempt-1 文件保留为L1-attempt1.*。这一节的底层机制在 FINAL_REPORT 的 bug 7 中有详细解释Codex 的 provider 配置agent 的spawn.ts只设置了stream_idle_timeout_ms重试次数保持 Codex 默认值退避为 200ms × 2ⁿ——默认 5 次流重试约 13 秒就放弃远不够覆盖约 85 秒的网关路径抖动。8 个并发 xhigh 首请求把 K3 的 4/9 放大成了 8/8。4.4 缓解措施local hacks02:42针对上述故障操作员在本地打了两个补丁Dockerfile.sandbox-base中第二个 sedcodexstream_max_retries10、request_max_retries10退避 200ms×2ⁿ ≈ 200 秒、SANDBOX_STREAM_IDLE_TIMEOUT_MS90s → 300sconstants.py中MAX_CONCURRENT_SANDBOXES10 → 4预计首个沙箱触发镜像重建约 10 分钟。效果立竿见影后续四轮全部零 turn 失败。4.5 四轮正式运行L1 / M1 / L2 / M202:40–06:27缓解后按 LOpus 5 验证→ MSol 验证交替完成四轮轮次时段耗时原始→去重→有效评审阶段验证验证成本网关备注L102:40:39–03:54:534432 s28→23→11 valid34m26s并发 4内含 ~6 min 镜像重建03:24–03:544 个 Opus 会话 23 条判定验证 Opus $20.76134 calls Sonnet 辅助 $3.60126评审 $17.98246 calls85k reasoningM103:57:00–04:38:122455 s24→19→18 valid25m57s无重建04:25–04:384 个 Sol 会话 19 条判定~40 s/条验证 $13.62173 calls40.6k reasoning评审 $17.84255 callsL204:39:56–05:38:083491 s26→22→12 valid28m02s05:12–05:3822 条判定验证 Opus $23.42176 calls评审 $17.32244 callsM205:39:43–06:26:542792 s26→20→18 valid27m35s06:10–06:2620 条判定验证 $15.97161 calls44k reasoning评审 $18.50276 calls其他细节effort guard读取首批评审调用与首批验证调用的$ai_effort每轮都通过每轮结束删除报告不全局清库只删 PR 75215 报告arm 轮换L1 后 set LA、L2 后 set LB、M1 后 set MA、M2 后 set MB06:27 全部结束后VALIDATION_*恢复为生产 pinarm L。五、成本核算方法从 agent 日志到网关事件原日志中的成本数字全部来自 LLM 网关gateway计费这是一个重要的方法论修正点K1–K3 期间最初用 agent 日志usage_from_logs.py后被移除统计成本但该方法每回合只统计最后一次 LLM 调用低估 3–4 倍ACP 每回合 usage 是回合内最后一次 LLM 调用而非工具往返的总和权威口径改为直接读本地 Kafka 主题events_plugin_ingestion_ai上的$ai_generation事件——因为本地 ingestion 被 personhog :50052 阻塞事件滞留未消费正好提供了完整审计窗口。脚本为 scripts/kafka_ai_usage.py按RUN_START_EPOCH/RUN_END_EPOCH时间窗扫描提取每次调用的 stage、model、input/cache/ouput/reasoning token、$ai_total_cost_usd与$ai_effort并按阶段家族issues-review*→ review、blind-spots*→ blind-spot、validation*→ validation汇总成表计费单价以网关的 LiteLLM 费率为准$4 / $20 每百万 in/out$0.40 cache read。Opus 侧数字沿用 7 月 dump 的 cache-aware 列表价。结论Sol 验证每判定成本约 $0.72–0.80Opus 约 $1.06——xhigh 下成本差距缩到 ~30%而非 low 时代的 4–5 倍。六、Effort pin 之谜为什么此前 Sol 一直以 low 在跑日志中$ai_effort反复出现对应本实验最重要的技术发现——effort pin 从未到达 Codex详见 FINAL_REPORT.md 同名章节证据K1/K2/K3 中每次gpt-5.6-sol调用含验证、评审、盲区都携带$ai_effortlow而同批 Sonnet one-shots 是xhigh沙箱侧一切却都写着maxTaskRun.state.reasoning_effort、POSTHOG_CODE_REASONING_EFFORTenv、Codex 会话session/new结果里的effort max生产环境同样中招自至少 2026-08-04 起 21 天内每天 100% 的gpt-5.6-sol调用都是low。也就是说生产 50/50 A/B2026-08-03 起的 Sol 臂、以及 7 月的评审模型实验、K1–K3全部实际运行在 low effort机制agent镜像中 2.4.86打包openai/codex0.144.0的 Codex 适配器在每次turn/start同时发送effort参数和由collaborationModeForTurn()构造的collaborationMode对象其 settings 只含{ model }。Codex 在收到 collaboration mode 时会原样采用仅当未发送时才应用独立的effortcodex-rs/core/src/codex_thread.rs的preview_thread_settings_overrides路径。由于该 mode 没有reasoning_effort每回合都回退到 Codex 自带模型目录models.json里的默认值gpt-5.6-sol默认low。Claude 适配器通过 session meta 透传 effort所以 Opus 一直正常为xhigh修复PR #88893在collaborationModeForTurn().settings中加入reasoning_effort: this._effort或仅当 mode 未变时不发送 collaborationMode。验证方式agent 发布进入沙箱镜像后检查一轮运行首批 Codex 调用的$ai_effort。日志中 01:45 的 effort guard32 次评审调用全 xhigh表明缓解措施生效后本地镜像打上 sed 补丁真实 xhigh 终于到达了 Codex。七、评分协议与四轮结果四轮 scoring 在 03:55–06:45 完成操作员记录 Scoring the four runs每个 finding 集LA/MA/LB/MB由一个 agent 匹配到 76 个已知 clusterknown_clusters.json由 7 月 judge 文件构建意见一致的 cluster 直接采用注册表判定完全相同的 claim 复用 K/7 月判定26 条混合 cluster 或全新 claim 对冻结 worktree 做先反驳后验证refutation-first的人工核验findings/verify/产出 truth 文件findings/*.truth.json、评分findings/*.score.md、四轮汇总表findings/xhigh_summary.md、评审侧统计findings/reviewer_side.md与盲评findings/argumentation_judge_L_vs_M.json。xhigh_summary.md 汇总的关键指标LA/LB/MA/MB 四轮指标L1L2M1M2判定 findings23221920保留11121818保留中为 real9/11 (82%)8/12 (67%)11/18 (61%)12/18 (67%)real 保留率recall9/12 (75%)8/11 (73%)11/12 (92%)12/13 (92%)not-real 丢弃率9/11 (82%)7/11 (64%)0/7 (0%)1/7 (14%)每判定成本$1.06$1.06$0.72$0.80核心结论Sol 验证器几乎什么都不丢每轮只丢 1 条且是同一个 real finding——webhook 站点上的 secondary-reviewer toggle 副本 MA5/MB11却保留了它此前在 low 时代就保留的三类弱 claimunscopedfind_task_run查找、broker/retry 加固诉求、队列时间 toggle。xhigh 没有抬高它的门槛Opus 5 更严格两轮丢弃 22 条 not-real 中的 16 条保留 23 条 real 中的 17 条每判定 $1.06盲评Sol 的 write-up 中位 126 词 vs Opus 335 词29 组配对中 Opus 在证据与验证维度赢 21 组——Sol 更多是复述 finding 而非检验它且一轮内部判定自相矛盾丢弃 webhook 站点副本却保留 receiver 站点副本评审侧意外收获Sol 评审在 xhigh 下每轮产出 11–13 条 real findingslow 时代 3–4 条其中 8 条是此前 18 次评审从未报过的新问题含 1 条must_fixwebhook facade 的调用方可写 task attribution 授权漏洞 LA15MA9MB17。但评审成本从 ~$6 涨到 ~$26/轮。八、结论与工程建议来自实验交付FINAL_REPORT 的建议可操作化为五条验证器保留 Opus。真实 xhigh 下 Sol 依然保留 18/19–20 条、几乎不丢 not-real0/7、1/7成本优势缩至 ~30%Sonnet 5 是半价的同款故事保留 16/22、22/2250% real更便宜的 Claude 层级也救不了。Sol 作为验证器唯一剩下的变量是更严格的先反驳提示词上线 effort 修复#88893并用 xhigh 跑 Sol 评审。修复落地后所有 Codex 沙箱ReviewHog 评审/盲区、其他 Codex Tasks将从 low 切到 pin 的 effort评审侧每轮 real findings 提升约 3 倍、单 PR 发现 8 条新问题代价是 ~$26/轮与 25–35 分钟的评审阶段并发 4 下测得生产可测并发 10。若价格是障碍medium是回退档每轮 7 条 real、~$10.50、12–14 分钟但两轮中未发现新问题在 agent 发布前加固 Codex 回合对网关抖动的韧性bug 7在 agent 的 codex provider 配置里设置重试次数并重试 completion signal否则生产 xhigh 波次会在网关路径抖动 ~15 秒时像本地一样整波死亡重新解读生产 50/50 A/B其 Sol 臂从未真正以 xhigh 运行修复后对比要重来实验结束后还原 hackDockerfile.sandbox-base两行 sed、fetch_pr_comments的return []、split_chunks_activity的 chunk pin、MAX_CONCURRENT_SANDBOXES 4VALIDATION_*已还原为生产 pin。九、运行中的其他故障清单Bug registry 摘录通宵日志中暴露的故障在 FINAL_REPORT.md 的 Bugs found on the way 中被系统化为 9 条其中与通宵日志直接相关的有bug 6Codex turn 卡死可钉住沙箱 30 分钟——K3 中 4/9 沙箱在 5 秒窗口内以stopReasonrefusal结束且无法回报完成fetch failedworker 等满 1800 秒 poll 超时后重试4 次重试 ~3 分钟全部成功属共享网关/隧道抖动而非提示词问题代价只是墙钟时间bug 7Codex 在隧道抖动 ~13 秒内放弃详见 4.3bug 8本地 Modal 镜像构建重启开发 worker详见 4.1bug 9Opus 验证会话自行扇出到 Sonnet——L1 验证阶段 134 次 Opus 调用旁还有 126 次claude-sonnet-5调用Claude 会话自己的 sub-agent$3.60 / $24.35均标记validation-*做任何按模型拆分成本时必须包含它们。此外还有两条通宵前的已知问题ReviewHog 沙箱无 MCP#88697已合并与评审沙箱自 2026-07-15 起检出了 master 而非 PR#88775Tasks 的 checkout 只解析refs/heads/namepull/N/head解析失败后回退到 master 新分支K1 因此在错误的树上判定被保留为 before/after 数据点。十、参考资料索引本次实验的完整证据链都保留在该实验目录下便于读者继续深挖原始操作日志runs/overnight-2026-08-26.notes.md本文骨架另含 N/P 两臂次日补充轮次的完整时间线见 PLAN.md实验设计决策与运行配方PLAN.md最终结论与全部 bug 清单FINAL_REPORT.md八轮汇总指标表findings/xhigh_summary.md评分脚本scripts/score_validator.py、truth 草稿生成scripts/build_truth.py、成本统计scripts/kafka_ai_usage.py、多轮冒烟scripts/codex_mts_smoke.py运行 harnessscripts/harness/run.sh、scripts/harness/set_arm.py、scripts/harness/watch.sh验证 pin 的生产默认值products/review_hog/backend/reviewer/constants.py并发上限见 同文件 L228-L232pin 合法性测试见 products/review_hog/backend/reviewer/tests/test_constants.py。一次成功的通宵 AI 评测实验靠的不只是跑两条命令而是对沙箱供给、worker 生命周期、隧道可靠性、成本计量口径与评分协议的全链路控制——这正是这份操作日志的价值所在。【免费下载链接】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），仅供参考