PostHog ReviewHog 提示缓存成本优化跨沙箱缓存复用候选方案与实验设计全解【免费下载链接】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本文基于仓库内实验记录文档 CANDIDATES.md 及其配套的 HARNESS.md、INVESTIGATION.md、PLAN.md系统梳理 ReviewHog 在 2026-07 prompt-caching 项目中如何围绕 Anthropic 服务端提示缓存设计成本优化实验从计量学修正、候选方案评审、锁定约束到旗舰方案 warm-upfork 的完整技术蓝图。读者读完后将掌握该项目的成本结构真相、跨沙箱缓存复用的底层机制TTL、前缀字节一致性、fork 原理以及一套以质量为先、以实验为证的 AI 成本优化方法论。背景ReviewHog 的成本痛点与 prompt-caching 项目的由来ReviewHog 是 PostHog 的 AI 代码审查引擎。从 workflow.py 可见其单次审查流水线为 7 个阶段抓取 PR → 分块chunking→ 视角波浪perspective wave 盲点检查blind-spot→ 去重 → 校验validation→ 构建报告 → 发布。其中每个 review unit每个perspective × chunk以及每个 chunk 的 blind-spot 检查都是一个全新的 Task → 全新 Modal/Docker 沙箱 → 全新 agent-server → 全新 Claude Code 会话见 INVESTIGATION.md。这意味着同一个 PR 的探索性工作会被 N 个视角单元各自重复执行一遍——每个单元都要重新阅读 diff、相关文件、调用链。这正是成本放大的根源成本由 turn 数主导而非 payload 大小每个 turn 都会重新读取不断增长的整个前缀并产出输出median 约 15 turns/unit。2026-07-03 的初步调查INVESTIGATION.md之后2026-07-06 进入创意征集ideation轮4 个不同视角的生成器产出 18 个原始候选合并为 13 个每个由 2 位独立评审者进行对抗式审计缓存机制经济学质量先例审计杀死 3 个同日用户决策见锁定约束又杀死 3 个最终7 个候选存活。被杀的候选记录在墓地graveyard中避免未来会话重复提案。候选编号#1-#10在跨轮次时保持稳定PLAN.md和DECISIONS.md均引用该编号。锁定约束质量是护城河用户在 2026-07-061-5 条与同日稍晚6-9 条5 条于 07-07 修订锁定了 9 条约束它们是整个实验计划的宪法质量是护城河——不是时间不是金钱。ReviewHog 绝不允许产出垃圾never generate bullshit。代码调查的一次性 LLM 调用永久出局——单次调用无法做侦探工作跟进线索、验证怀疑、跨调用图跳转。只有分块和去重纯文本任务保留一次性调用每个调查代码的单元wave、blind-spot、validation必须是拥有完整、无限制探索能力的沙箱 agent。项目宗旨是通过缓存复用来让沙箱更便宜而不是替换沙箱。大 PR1000 新增行是优先级——那里审查最难、产品价值最大。所有实验按 chunk 运行chunker 目标约 300 新增行的 chunk因此节省随 chunk 数扩展大 PR 在绝对金额上受益最大。范围只做 review 阶段wave blind-spot不做 validator 实验不降级模型在质量门槛内优先成本如果 $/run 下降数分钟 wall-clock 回退可接受每个实验臂都必须通过标准的冻结 PR #62096 评估。工作模式07-07 修订单分支——所有实验都在signals/reviewhog上不建每实验分支。实验代码藏在开/关常量后面constants.pyknob 模式arm-vs-control 通过切换常量实现失败的实验提交被回滚实验文件夹保留记录。实验仍然逐个迭代运行。fork 重新定位从收割偶然重叠改为把 warm-up 设计成调查阶段本身。分块后每个 chunk 一个中立 agent 理解 chunk 及相关代码空间只读、不下判断、不写代码各视角从其缓存会话中 fork 出来不应需要重新调查。视角保留完整工具和自由约束 1-2 不变——跳过重新调查是预期结果而非规则锚定护栏per-perspective finding-count 分布 标尺仍然强制。价值主张是扇出宽度而非测量到的重叠视角是用户可扩展的可以是 20 个不限制自定义视角数量因此 warm-up 在 N 上摊销只要我们让缓存工作它就总是值得。s 0.55 的预构建门槛被删除——没有重叠测量来门控构建。测量移到构建后follower turn 数 / 每 turn 成本 vs 对照节省来自 turn 消除 质量对等。fork 实验的夹具冻结 PR #62096标准评估夹具3 chunks——与之前每轮可比。大 PR1000桶暂不测试接受。TTL 策略沙箱路径默认 5m已验证——见 HARNESS.md 1h cache TTLENABLE_PROMPT_CACHING_1H1可在沙箱环境内强制执行 1h按单元2× 写入成本。为 5m 滑动窗口设计扇出立即调度、重叠供给或对 warm-up 单元选择性使用 1h只有在测量到缺口需要时才放宽。项目立足的测量事实事实一朴素 token 数学高估真实成本约 4.8×——且计量工具已交付并验证这是整个项目最重要的数字。$ai_input_tokens是网关报告的完整 promptfresh cache read cache write 的总和按输入价求和会严重高估成本。修正后的 dump_result.py 将每次生成拆分为fresh1×/ cache-write1.25×/ cache-read0.1×/ output按 (model × stage) 聚合并输出true_usd列表价回算与gw_usd网关 LiteLLM 成本双列交叉验证。在runs/gate0-run1-pr68749-publish.md真实发布运行上验证结果true $9.90 vs gw $9.90每个桶、每一侧 Δ 0.0%而朴素方法算出 $47.52即4.8× 真实成本。该运行的桶拆分43% cache reads / 33% cache writes / 19% output / 5% fresh——缓存读取是最大的真实成本桶。此前探针时代的 28% gw-vs-list 差异被证实是测量伪影LiteLLM 的input_cost字段是整个输入侧含缓存不是 fresh-only。10 天探针的历史数据316.26M 输入 293.84M reads 20.17M writes 2.25M fresh约 $136 true vs 约 $655 naive把模型轮的naive $87-101/run修正为多 chunk 运行的约 $18-21/run true。事实二跨沙箱缓存共享已部分生效——观察到了两次冒烟运行 2 和 PR #68749 发布运行中3 个 fresh wave 沙箱中的 2 个在 turn 1 读取了 leader 写入的完全相同的 27,618-token [tools system-preset] 段。这意味着网关证明了可以在多个沙箱进程间共享同一个 Anthropic 缓存。但有个关键缺陷Task-Id追加V1会污染该段之后的所有字节价值只有几美分。因此fork 硬性要求 T2字节完全一致的全前缀和 T3原始 transcript fork 种子。wave→blind-spot 的 5m52s–12.5min 间隔两次都击穿了 5m TTL → 扇出需要立即调度 重叠供给仅 fresh 沙箱设置就要约 4-6 分钟ENABLE_PROMPT_CACHING_1H作为按单元保险。事实三一次性直接调用方向的否决记录为了记录已测量、方向被否决一次性直接调用本可消除大部分沙箱循环成本审计给两个此类候选打了约 $7-8/run 的分。否决仍然有效那些调用无法调查而质量是护城河。记录在此以便未来会话不再重新推导经济学、不再重新争论否决。实验程序总览截至 2026-07-07round内容状态0测量#1 计量学 #2 网关探针 #3 fork 尺寸 spikes2026-07-06 关闭#1 已交付并验证#2 可选基底已两次实况证明#3 降级约束 7 取消了 s 门槛。PLAN.md为记录下一个fork 构建#8 在约束 6-9 下T2T3 本地 harness 补丁 → Spike 2剥离形式 fork 保真度→ 常量后面的 warm-up 阶段 → #62096 上的 2v2 评估独立实验文件夹 计划门 机制 / 成本 / 质量见 #8 状态排队便宜构建#4 skill-body splice #10 预打包 touched files在其免费预门之后在 opus 时代价格下合计约 $4-7/run——在信任前重新锚定 fresh sonnet 时代对照对冲未排序#5 Arm Bblind-spot 作为 warm continuation turnC5 护栏#9 Arm Aprompt turn 预算——与约束 1 冲突最后才做分别约 $2.9 和约 $3/run同样的重新锚定注意项Harness 路径2026-07-06 已解决fork 的 harness 变更T2 缓存稳定 system prompt、T3 原始 JSONL fork 种子直接在本地 PostHog Desktop checkout 打补丁已验证的构建/叠加/验证循环和精确补丁面在HARNESS.md。修复如何上游化在实验证明价值后决定。定价参考sonnet-5 列表价$2/M in、$10/M out写入 5m TTL 时 1.25×、1h 时 2×读取 0.1×。候选 $ 估算早于计量学仅作为尺寸输入需对照 fresh sonnet 时代对照重新锚定。存活的候选方案详解#1cache-aware-metrology— 缓存感知成本归因 修正基线 T1 重新量化DEP无离线。直接节省$0仅决策价值条件性 T1 EV 约 $0.1-0.15/run。裁定modify modify。状态 2026-07-06计量工具已交付并验证每个桶、每一侧 Δ 0.0% vs 网关 LiteLLM差异子任务已解决探针伪影归档臂重算已死DB 被清空——基线从 fresh 运行累积。剩余未完成工作搭 fork 实验的对照运行便车T1 重写检测器在 fresh 运行上检测连续的生成同一 task_run_id 内按时间排序是否出现cache_read 0.05x prev、cache_creation 0.8x prev、gap 120s的重写签名扫描 creation 阈值到 0.5x分类 rewrite-after-write vs session-restart注意 Bedrock 回退混淆。决策 $0.5/run 则推进 Tasks 团队 ticket $0.3/run 则降级并记录粗略探测约 $0.005/run降级是可能结果。将 #4、#5、#9、#10 的候选 $ 估算重新锚定到 fresh sonnet 时代对照运行。#2gateway-cache-probe— 跨客户端缓存共享探针Spike 1便宜的 worker 侧变体成本约 $0.25-0.60约 1-3h。状态 2026-07-06 晚可选。存在性问题已有生产级 PASS两次——smoke run 2 PR #68749 发布运行且 fork 构建自身的机制门follower turn-1 cache reads ≈ warm-up transcript吸收基底检查。仅在构建的缓存行为出人意料时才运行受控臂。否决后重新定向arm 5沙箱起源对是承重臂——所有跨沙箱共享T2/T3/#8的基底检查。探针方法学值得记住的细节字节完全一致的messages.create请求不要用.parse——结构化输出会注入 schema 字节关闭 thinking约 10K-token 文档块带显式cache_control通过get_async_anthropic_gateway_client(productreview_hog)。五个臂同进程重复对照网关是否转发cache_control两个 OS 进程相隔 2 分钟用 fresh nonce 复制 3x报告为共享率网关若池化多个上游 key 会概率性共享单次试验给出假二元结论allowlist 映射检查两侧确认$ai_model若非 allowlist 名称映射到同一默认模型HIT 是预期结果而非 miss6 分钟间隔 TTL 健全性fresh nonce 保证零中间读取读取会免费刷新滑动 TTL任何跨沙箱绿灯前的强制项从沙箱内部以原始网关调用发出一个字节完全一致的对网络起源/凭据检查Claude Code CLI 驱动的对今天因 V1/V2 无法字节一致构造上就会 miss每个臂都用 nonce 盐化文档防止臂之间读取对方的条目。解读纪律arm 25 PASS workspace 基底已验证它本身并不能去风险跨沙箱项目T2/T3 字节修复和 CLI breakpoint 行为仍未证实。#3fork-sizing-spikes— 探索重叠份额 sSpike 3 前缀热度 TTL 时间线状态 2026-07-06 晚被锁定约束 7 降级——s 不再门控构建重新定位的 warm-up 按设计把 s 推向 1价值随无界视角数量扩展。热度/TTL 半部分折叠进 fork 构建在其运行上测量间隔超过 5m 时ENABLE_PROMPT_CACHING_1H是杠杆。重叠分析仅作为可选的后构建诊断存活。原规格记录价值一个提取 harness 连接$ai_generation时间戳、cache_creation与任务的 ACP 日志以获取工具调用参数$ai_tools_called只有名字已验证。(a) 重叠标准化工具调用早期窗口 turns 2..ceil(0.4 × turns)按 next-gen cache_creation 减 prior-gen output 加权只对 3 个 wave 单元计算 sstrict 3 个全有loose 2-of-3blind-spot 的边际重叠单独报告。(b) 热度每个 (run, chunk) 的 wave 联合体最大连续 gen 间隔最差未刷新 TTL 窗口与 last-wave-gen → first-blind-spot-gen 间隔p50/p95。原门wave-fork GO 需s_p50 ~0.55 strict审计显示在调查原 0.40 边界上净值低于实质线一旦计入重读税wave 内 gap p95 4 min → fork 无需重排 TTL 安全wave→blind-spot gap p95 4 min → blind-spot 可做第 5 个 forker$0.8-1.1/run。#4skill-body-splice— 内联固定视角 skill 正文干掉 skill-get 编排修正后节省opus 时代约 $4-4.5/run先在 sonnet 上重测可能缩水到约 $1-2.5。沙箱保留单元保持完整探索只改 skill 交付。自定义 skill 完全保留——同一按团队版本化 DB 行ReviewSkillConfig→ LLMSkill同一选择逻辑worker 在 prompt 构建时解析正文而不是 agent 在运行中通过 MCP 获取。将解析后的正文就地拼接到现有视角块prompt.jinja:83-87用你的视角包含在下方不要调用 skill-get替换运行时的skill-get指令MCP 工具保留可用skill-file-get保留用于自定义用户 skill 的捆绑文件。版本在构建时固定与今天相同的竞态保护。杀死测量的2.65 fetch-choreography gens/unit约 $0.44-0.58/unit × 12 unitsopus 时代新增 payload 约 $0.1/run。每个单元自身工作会话内的 turn 消除不声称跨单元共享。评审者要求的修复已纳入不要把 138 行静态后缀提升捆绑进 eval 臂V1/V2 下今天值 $0且会在 n2 时混淆质量归因以后作为机械变更或 T2 上线后再应用output schema 无论如何都留在 prompt 末尾预门从 sonnet 时代 traces 重测 fetch-choreography $/unit若 约 $0.17/unit 则降级。门fetch gens ~0且总 gens/unit 下降 ~2捕获 turn 重分配命名的第三个失败模式缓存感知 $/run 下降 15-20% vs 对照相对非 opus 时代绝对有效发现 对照 - 1per-perspective lens-adherence rubric 不变。这是本轮最便宜、最可组合的构建是强默认的首个 BUILD。#5blind-spot-restructure— 仅 Arm Bblind-spot 作为 warm 延续 turn修正后节省约 $2.9/run 上限。Arm A一次性直接转换2026-07-06 被用户否决杀死——见墓地。Arm B 作为未排序、保留探索的对冲存活。把 blind-spot 检查作为仍在温暖的 wave 单元沙箱会话内的一个后续 turn 运行多 turn 原语存在于executor.py:95-164今天仅 validation 使用——宿主的完整探索上下文已在其中会话缓存中因此后续 turn 以 0.1× 读取约 150K约 $0.045而不是 fresh 单元在约 15 个 turn 中重建等价上下文。这是 C5 认可的 revisit单个同 chunk 后续 turn不是C5 的跨 chunk 顺序 turn携带 C5 裁定命名的显式反锚定装置扩展为排除整个 wave覆盖的领域而不仅仅是宿主自己的探索。要求按 chunk 触发把 blind-spot 移出 per-run gather 宿主 最后一个完成的 wave 单元否则空闲宿主的 5 分钟 TTL 到期约 $0.56 的全前缀重写吃掉一半节省后续 turn-1 cache_read 0 是 arm 无效信号而非建议。门blind-spot 归因的有效发现 对照 - 1与 wave 的重叠率不高于对照锚定检测器缓存感知 blind-spot 成本 $1.0/chunk。质量风险真实存在锚定到宿主的探索路径正是 C5 失败模式而 blind-spot 存在的意义就是找 wave 漏掉的东西——这正是它是对冲而非旗舰的原因。#8warmup-fork-wave— 按 chunk 中立读取 warm-up N 个 wave 单元的 forkT3——旗舰方案DEPharnessT2 T3 SHA 固定 checkout。修正后节省s 在 [0.55, 0.6] 时约 $0.7/chunk3-chunk 冻结 PR 约 $1.5-2.2/run随 chunk 数扩展大 PR 受益最大。2026-07-06 晚状态在锁定约束 6-9 下晋升为下一个实验——门控阶梯#3 s 门 → #2 arm 5 → Spike 2崩溃无预构建测量Spike 2剥离形式 fork 保真度成为构建的第一个里程碑基底检查折叠进机制门。上面的 $ 数字是在 N3 wave 单元、s≈0.55 下计算的——在新定位下warm-up 调查阶段N 通过自定义视角无界它是下限而非估算。夹具冻结 PR #62096标准评估2 arm vs 2 control带锚定护栏门 机制follower turn-1 cache_read ≈ warm-up transcript、成本follower turns 每 turn 成本下降、质量标尺对等。每个评审者仍是具有无限制探索的完整沙箱 agent视角不变的那部分探索作为 0.1× 缓存前缀预先完成而不是每个 chunk 重新推导 3 次。工作机制warm-up 一个真实的 Claude Code 沙箱会话toolssystem 必须与 followers 字节完全一致直接调用无法播种它读取 diff touched files 直接调用者带 no-analysis 指令T3 上传原始会话 JSONL绝不使用有损的 ACP hydrationfollowers 下载到相同的确定性 cwd 并 fork追加一个用户消息静态指令 output schema 2 行视角块。审计发现的机制洞修复已纳入thinking-block 剥离。follower 追加的非工具结果用户消息会在服务端剥离先前的 thinking blocks因此 fork 的字节在第一个 thinking block 处发散约 70K 的 fork 读取永远不会发生warm-up 必须以一个 settling user turn 结束让它自己写一次剥离形式缓存约 $0.19/chunk且 Spike 2 的保真度门必须针对剥离形式前缀重新表述否则会错误杀死正确实现。其他纳入的修复重读税不是 wash——如果 warm-up 覆盖不足cap warm-up transcript 约 70K门控 follower 每 turn 成本 vs 对照而不只是 turn 数错开 followers 或依赖 settling write 避免并发重写竞态Spike 2 必须测量完整 warm-up 完成 → follower 首个请求延迟 vs 5 分钟 TTLJSONL 上传 Task 调度 供给——仅 fresh 沙箱设置就约 4-6 分钟所以重叠 follower 供给与 warm-up 运行ENABLE_PROMPT_CACHING_1H1在 warm-up 沙箱上作为按单元回退2026-07-06 已解决——见 HARNESS.md 1h cache TTL生产 follower turn-1 cache_read 监控带自动禁用 kill switch静默缓存回归会在功能上不可见地翻转净负应急 B2fork 一个真实视角单元的中途会话 transcript已死——它会在上下文中继承冲突的视角指令并重新引入 C5 式共享分析状态。阶梯2026-07-06 崩溃约束 6-9T2T3 本地补丁 → Spike 2剥离形式保真度→ 常量后面的构建 → #62096 上的标准 2v2 评估per-perspective finding-count 分布作为锚定护栏。被杀的 TTL-bridge 候选的 blind-spot-as-5th-forker 内核作为近免费子臂搭车以测量的 wave→blind-spot 热度和 blind-spot 独有发现指标为门。锚定姿态共享前缀不含发现或判断只有中立原始工具结果每个视角分支进自己隔离的 fork 会话可从那里探索任何地方。#9turn-budget-cap— 仅 Arm A带批量读取的 prompt turn 预算修正后节省单独约 $3-3.6/run与 #4/#10不叠加同样的 turns。标记与锁定约束 1 冲突预算会推动探索变短。未排序对冲最后才做。硬 executor 上限Arm B已死——Tasks facade 中无 max-turns knob已验证低于 median 的上限会截断否决保护的侦探工作。Arm A 一个 jinja 编辑软预算语句 前置加载读取在一个并行工具批量中请求独立文件相同信息、更少 turns不是更少信息。离线预门来自现有遥测计算 per-unit turn 分布和 turns-above-13 的测量节省若 约 $1.5/run 则整体丢弃。质量门收紧以匹配 sonnet--high 先例40% 节省因 -1-2 findings 被杀有效发现 对照且系统性缺陷同一标尺发现在两个 arm 运行中都丢失即使在 -1 也是 kill。#10prepack-touched-files— 把 touched-file 内容预打包进沙箱单元 prompt修正后节省约 $2-2.5/run若 agent 反正会读文件则下限 -$1.8。与 #4 和 #8 叠加与 #9 不叠加。沙箱保留agent 保持完整探索自由打包预喂它们反正会获取的内容且明确鼓励超越它的探索。在 patch JSON 之后追加 chunk 的 touched files 的 post-image 内容带行号的 cat -n 风格让发现无需重读即可锚定完全排除 约 400 行的文件并列出名字为未包含请自行阅读绝不静默截断放在已在 wave 单元间字节一致的区域内增长未来共享前缀兼容 T2/fork 工作。任何 eval 运行前的强制预门来自现有冻结 PR 遥测每单元早期 touched-file 读取 turn 的 median 必须 4net of rg/search 和非 touched-file 读取且重新测量 sonnet 时代缓存感知 $/turn仅当 (可避免 turns × $/turn - $0.15) × 12 $2 时才继续。arm 模板还必须修正矛盾的静态指令总是用 cat 读取整个文件、精确行锚定否则 turn-drop kill 门会对着 harness 自己的指令而不是假设开火。在沙箱实际检出的 ref 处获取 blob今天 branch tipSHA 固定修复会改变这点。门median turns/unit 下降 3机械 kill switch无论质量如何都停止有效发现 对照 - 1off-touched-file 发现在对照 0 时不塌缩到 ~02v2 时率比较没有功效。墓地为什么不重新提案2026-07-06 被用户否决杀死一次性代码调查出局质量是护城河direct-cached-review-tier#6——wave blind-spot 作为 4 个直接网关调用共享一个显式 cache_controld 上下文包带尺寸门控和沙箱回退。审计修正节省约 $7-8/run机制裁定keep因原则而非经济学被杀一次性调用无法跟进线索、验证怀疑或跳转调用图且没有确定性上下文包能替代侦探工作。审计的可复用发现记录在测量事实和 #8 的 spec 中例如 output_format 在缓存 key 中先于 system/messages流式 writer-then-readers 排序per-perspective count 分布作为锚定检测器。explore-once-hybrid#7——每个 chunk 一个沙箱探索者产出 facts-only 档案由 4 个直接缓存调用消费。同样的病只有探索者有工具评审者自己无法调查。审计修正约 $7.5-8/run。探索一次、缓存复用的想法只以沙箱消费者形式存活即 #8每个评审者都是 fork warm-up transcript 的完整沙箱 agent。blind-spot-restructureArm A#5A——blind-spot 作为每个 chunk 一个带填充上下文的一次性调用约 $4/run。blind-spot 的超出 diff 的 repo 扫描就是它的目的填充无法替代它。Arm Bwarm continuation turn沙箱在上面存活。2026-07-06 被对抗式审计杀死经济学/机制t1-t2-staggered-launchT1T2 上线 leader 优先错开 wave 启动。错开这个独特杠杆在 sonnet 价格下约 $0.4/run微类。$2.4 的声明把独立以 ticket 形式上线的 T1/T2 harness 节省算进来、用了 opus 时代定价、还数了一次不可能发生的 chunk 本地用户前缀读取wave 单元的共享跨度位于 Task.description 的一个content block 内缓存命中只发生在 breakpoint/content-block 边界CLI 永远不会在模板第 84 行的 block 中间放一个。其生产 go 信号payload 别处免费blind-spot 单元已是天然的后 wave followers因此 T1/T2 后普通埋点运行加 #2 无需 6 轮 eval 就能翻转同样的 T3 决策。T1/T2 本身作为 Tasks 团队 ticket 存活见 INVESTIGATION.md Phase 0只有这个 eval 包装死了。blindspot-fork-ttl-bridgekeep-alive 重放 ping vs 1h-TTL 桥接 跨 chunk 缓存感知调度。桥接解决的是非问题wave-follower 读取免费为整个 wave 刷新 warm-up 跨度上的滑动 TTL唯一真实间隔blind-spots 前的全局 wave 屏障workflow.py:160-189被一个微不足道的 DEPnone 按 chunk 排序变更关闭。ping 本身很可能无法刷新 message-span blocksthinking-config 不匹配会使 message breakpoints 失效V3 类字节保真度风险如果 miss约 $2.2-2.7/run 的静默浪费超过声称的节省保险腿依赖 DAG 无法产生的 12-on-10 信号量争用需求是 3 → 9 → 3永远不会 12。挽救内核blind-spot 作为第 5 个 forker 按 chunk blind-spot 排序折叠进 #8 的 eval 作为子臂。batches-oneshot-stackingMessage Batches API 50% 折扣叠加在直接层上。诚实上限约 $1.1-1.6/run三重门控在一个未证实的层、一个不存在的网关 batches 路由、一个与 Anthropic 无 SLA batch 周转不兼容的 poll-timeout 设计之后。其宿主 #6 被否决杀死后此方案也无意义。协议笔记评估纪律标准评估冻结 PR #62096 上 2 个 arm 运行 vs 2 个 controlLLM 判定 vs 旧-10 标尺../2026-07-reviewer-topology/fixtures/per-perspective 有效发现数分布是常设锚定检测器C5 实际显现的方式标尺发现 ID 重叠捕获保持计数但转移覆盖的偏移。未决协议问题2026-07-06 提出添加第二个冻结评估夹具——一个真正的 1000 新增行 PR——使每个 arm 也在最重要处被判定judge 评分对它没有旧评审者标尺。所有成本门都是缓存感知的且相对于测量的 sonnet 时代对照Gate 0 #1opus 时代绝对值$0.10/turn、$19.6 review stage、$5.3 blind-spot 切片仅是尺寸输入。Harness 工作V1/V2/V3 修复、INVESTIGATION.md 中的 T1-T3位于 PostHog Desktop 仓库。2026-07-06用户开放本地双仓库实验——实验可在本地补丁的packages/agent上运行上游化修复是单独的、稍后的决定。Validators 保持 fresh 会话——没有任何东西从 review/warm-up transcript 播种 validator。附录如何在当前仓库中验证这套机制如果你想亲手验证缓存感知计量的输出格式与价格表直接阅读 dump_result.py 的_spend_report函数即可它按 (model × stage) 聚合每次$ai_generation生成fresh max(0, input - read - write)列表价表_LIST_PRICESsonnet-5 $2/$10、opus-4-8 $5/$25、write 1.25×、read 0.1×直接镜像 LiteLLM 的成本表200K是诊断列而非定价输入。同文件的 turn-1 cache-read 分布是跨沙箱共享的绊线tripwire并附带了 fork 碰撞追踪器每个 chunk 的 prefix writer/reader 计数理想是 1 writer N readers。真实运行证据见 gate0-run1-pr68749-publish.md142 次生成、true/gw 均为 $9.90、2/5 单元在 turn 1 读到 leader 的 27,618-token 前缀、blind-spot 在 wave 后 12.5 分钟启动导致 TTL 击穿全量重写——这些数字与本文引用的每个结论一一对应。需要说明的是实验涉及的 T2/T3 harness 补丁位于仓库外的 PostHog Desktop checkout本文档记录的/Users/woutut/Documents/Code/code当前仓库内可验证的是 ReviewHog 侧的工作流编排workflow.py 中视角波浪与盲点检查的扇出结构、BLIND_SPOT_PASS_NUMBER 1000的保留 pass 号、常量旋钮模式constants.py 中REVIEW_MODEL等 pin 与开关常量、以及 dump_result.py 中已经为 warmup 阶段预留的 stage 分类_stage_of已含(warmup, warmup)映射。warm-up 阶段本身按计划将落在workflow.py的每 chunk 扇出之前作为该实验构建的主体部分。【免费下载链接】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），仅供参考