One-shot Chunking 与 Dedup 实验PostHog ReviewHog 如何将沙箱化流水线阶段重构为一次 LLM Gateway 调用【免费下载链接】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 的架构与实验方法感兴趣的开发者。ReviewHog 是 PostHog 仓库中的一个产品级代码评审系统其核心是将 GitHub PR 的评审流程拆分为多个流水线阶段其中PR 分块chunking与问题去重dedup原本以 agentic sandbox 方式运行。本文以products/review_hog/eval/experiments/2026-07-oneshot-chunking-dedup/PLAN.md为主线结合direct_llm.py、constants.py、activities.py、issue_deduplicator.py、FINAL_REPORT.md、sample_oneshot_chunker.py等仓库文件完整还原这个one-shot单次调用实验的设计、执行、测量与决策过程。你将掌握这两个阶段为什么适合去掉沙箱、CHUNKING_ONESHOT_MAX_ADDITIONS/DEDUP_ONESHOT_MAX_FINDINGS两个门控gate如何工作、结构化输出如何从机制上消灭 schema 失败类以及如何用离线采样器在极低成本下验证分块质量。一、实验动机两个纯文本阶段为何还跑在沙箱里1.1 ReviewHog 评审流水线中的两个沙箱阶段ReviewHog 的评审流程见 ARCHITECTURE.md把一次 PR 评审组织为多个阶段。其中两个阶段在很长一段时间里是流水线上仅存的agentic sandboxPR 分块chunkingsplit_pr_into_chunks用一次 LLM 调用把变更文件按关注点边界concern seams聚合成逻辑上可评审的块chunk并按照评审优先级排序见 ARCHITECTURE.md。它的 prompt 把 PR 元数据、评论与补丁内联嵌入不需要访问仓库。问题去重dedupdeduplicate_issues通过一次 LLM 调用合并位置重叠的重复发现duplicate issues并丢弃已被任何既有内联评论提出过的内容。它的 prompt 是纯文本甚至显式渲染CLAUDE_CODE_CONTEXT见 issue_deduplicator.py。而这两个阶段默认跑在 agent 默认配置opus-4-8 high的 agentic sandbox 上。1.2 沙箱路径的两个成本PLAN 明确列出两个痛点PLAN.md每个 sandbox 在串行关键路径上要付约 55 秒的 provisioning 时间存在两类失败Modal provisioning 抖动infra 层故障以及 chunking 阶段约 29% 的 schema 失败类——模型返回了裸数组bare array而不是chunks对象。一个关键证据是在归档的 20 次 dedup 调用中14 次没有使用任何工具zero tools说明这两类任务本质上根本不需要一个会拿工具、能跑仓库的 agent。1.3 实验假设PLAN 的实验假设也是 POTENTIAL_EXPERIMENTS.md 中 item 7 的原始表述两个阶段都是纯文本任务各自在串行关键路径上付出约 55s 的沙箱 provisioning直接、schema 强制的 gateway 调用相同模型/相同 prompt在效果上等价并且从结构上移除两类失败。具体回答的问题是用 one-shot gateway 调用Sonnet 5 xhigh、结构化输出保证 schema能否在保持 chunk-plan 与 dedup 质量的同时压缩阶段墙钟时间并消灭那两类失败PLAN.md二、实验设计门控、模型钉扎与基准2.1 测试 PR冻结且可比实验选择 PR #62096headba725a897db35053525e5bdfac2c64a8b007fcb4674 增 / 1 删 / 10 文件作为基准测试对象674 增高于 400 增的单块门控SINGLE_CHUNK_GATE_ADDITIONS因此两个新路径都会被实际触发chunking 与 dedup 的 one-shot 路径都活着它的质量标尺yardstick是旧版 ReviewHog 的 10 条发现见../2026-07-reviewer-topology/fixtures/old_reviewhog_report.md即 products/review_hog/eval/experiments/2026-07-reviewer-topology/fixtures/old_reviewhog_report.md。2.2 五个永久性 Instrument默认开启实验的仪器全部以永久代码落地默认开启用户负责提交Agent 只改文件。PLAN 列出五个要点PLAN.md门控 模型钉扎constants.pyCHUNKING_ONESHOT_MAX_ADDITIONS 5000仅统计新增行与其它 chunking 门控口径一致DEDUP_ONESHOT_MAX_FINDINGS 50进入 dedup 的 issue 数含边界ONESHOT_MODEL claude-sonnet-5、ONESHOT_REASONING_EFFORT xhigh任何一个门控设为 0 即整体禁用该阶段的 one-shot 路径回到沙箱。reviewer/sandbox/direct_llm.py → run_oneshot_review(...)一次 Messages 调用经 LLM gatewayget_async_anthropic_gateway_client(productreview_hog)发出adaptive thinking output_config.effortxhigh这是沙箱钉扎的 API 原生表达结构化输出来自该阶段的 pydantic 模型保证 JSON schema——chunking 的 schema 失败类不可能发生ai_stage头用于 dump/成本归因Anthropic 错误被重抛为紧凑的ApplicationError4xx 除 408/409/429 外均不可重试。Bedrock 回退被刻意关闭那条路径会剥离output_config。两条分支split_chunks_activity新增行 ≤ 门控 → one-shot否则沙箱不变与deduplicate_issuesissue 数 ≤ 门控 → one-shot否则沙箱不变。两条路径 prompt 完全一致。Gateway 产品注册永久 parity 管道review_hog被加入 gateway_client.py 的Productliteral并在 services/llm-gateway/src/llm_gateway/products/config.py 注册为产品任意模型、允许 API keys、不计费。不钉扎 chunk 数量unpinned刻意为之chunk plan 本身就是要测量的输出钉扎会完全短路 one-shot chunking 路径。刻意的混杂变量deliberate confoundone-shot 分支同时改变了模型agent 默认 opus-4-8 high → sonnet-5 xhigh与执行模式sandbox → 直接调用。它测试的是期望的终态配置而不是单变量版本。这一点在解读结果时必须始终记住。2.3 配置矩阵与基线label内容runsONESHOT-N完整 e2e 运行one-shot chunking dedup 生效chunk 不钉扎2offline samplesample_oneshot_chunker.py× 5 次对冻结快照的直接 chunker 调用不走流水线成本约 cents1 batch基线全部复用、不再重跑PLAN.md../2026-07-pipeline-models/的C1sonnet reviewvalidationdedup/chunking 沙箱跑 opus 默认钉扎3-chunk 切分18→11→7——最接近今天生产配置../2026-07-reviewer-model-sonnet5/的B1/B2sonnet review、opus-default validation、钉扎17→11→6 / 18→14→6。双向注意caveat基线都是钉扎的而本轮不钉扎因此2-chunk 还是 3-chunk 的抛硬币重新进入漏斗。所以chunk-plan 质量与 dedup 决策是主要读数漏斗/valid 计数是次要读数且附有结构上的 caveat。三、核心实现run_oneshot_review与门控路由3.1run_oneshot_review的完整契约direct_llm.py 是整个机制的心脏其完整调用参数与行为async def run_oneshot_review( *, team_id: int, user_id: int, prompt: str, system_prompt: str, model_to_validate: type[_ModelT], step_name: str, model: str ONESHOT_MODEL, reasoning_effort: str ONESHOT_REASONING_EFFORT, ) - _ModelT:关键实现细节单次 Messages 调用client.messages.parse(model..., max_tokens64_000, systemsystem_prompt, messages[...], thinking{type: adaptive}, output_config{effort: reasoning_effort}, output_formatmodel_to_validate, ...)。output_format传入阶段的 pydantic 模型由 SDK 在构建响应时就按该模型校验文本块——截断/非法 JSON 会在parsed_output之前直接抛pydantic.ValidationError。三个内部硬上限direct_llm.py_MAX_OUTPUT_TOKENS 64_000sonnet-5 的输出上限注意 adaptive thinking 也计入输出 token 且在 xhigh 下占大头_TIMEOUT_SECONDS 600.0大 chunking prompt 在 xhigh 下端到端合法地需要几分钟_RETRYABLE_CLIENT_STATUSES (408, 409, 429)。错误语义APIError被重抛为紧凑ApplicationError避免原始APIError链撑爆 Temporal 的失败序列化4xx除 408/409/429标记non_retryablepydantic.ValidationError同样被压缩为可重试的ApplicationError因为异常不带stop_reason无法证明是确定性失败parsed_output is None时stop_reason max_tokens标记为non_retryable——重试同一个超大 prompt 只会再次撞同一堵墙、白烧预算。ai_stage属性extra_headers{x-posthog-property-ai_stage: step_name}把一次生成归因到流水线阶段供 dump 与成本查询使用。3.2 门控路由split_chunks_activity在 activities.py 中chunking 活动按三级逻辑路由# 1) 小 PR跳过 chunking LLM 轮次用确定性单块 planned plan_deterministic_chunks(snapshot.pr_files) if planned is not None: # SINGLE_CHUNK_GATE_ADDITIONS (400) ... # 持久化后直接返回 # 2) 构建自包含 prompt元数据评论补丁内联 prompt generate_chunking_prompt(snapshot.pr_metadata, snapshot.pr_comments, snapshot.pr_files) # 3) 按 one-shot 门控路由 additions count_reviewable_additions(snapshot.pr_files) use_oneshot bool(CHUNKING_ONESHOT_MAX_ADDITIONS) and additions CHUNKING_ONESHOT_MAX_ADDITIONS async with Heartbeater(): if use_oneshot: chunks await run_oneshot_review(..., model_to_validateChunksList, step_namechunking) else: chunks await run_sandbox_review(..., modelCHUNKING_MODEL, reasoning_effortCHUNKING_REASONING_EFFORT)值得注意的两点代码级事实门控用bool(CHUNKING_ONESHOT_MAX_ADDITIONS)短路设为 0 时 one-shot 路径整体关闭每个文件恰好在一个 chunk 中是由代码强制、而非信任 LLM无论走哪条路径reconcile_chunks(chunks, snapshot.pr_files)都会校正遗漏文件避免下游静默漏审。路由行为有参数化测试背书test_split_chunks_activity_routes_llm_chunking_by_oneshot_gate断言additions CHUNKING_ONESHOT_MAX_ADDITIONS时走 one-shot、1时走沙箱见 test_review_activity.py。3.3 门控路由deduplicate_issuesissue_deduplicator.py 先去重一个确定性位置预过滤器_select_dedup_candidates只有与另一条 issue、任何既有内联评论或上一轮 finding 共享文件且行区间重叠的 issue 才可能重复因此位置孤立的问题不经过 LLM 调用直接存活零候选时整个 LLM 轮次被跳过。随后按实际送入 LLM 的候选数而非预过滤总数路由if DEDUP_ONESHOT_MAX_FINDINGS and len(candidates) DEDUP_ONESHOT_MAX_FINDINGS: deduplication_result await run_oneshot_review( ..., model_to_validateIssueDeduplication, step_namededup) else: deduplication_result await run_sandbox_review(...) # unique 总是存活只有位置候选可能被 LLM 丢弃 duplicate_ids {dup.id for dup in deduplication_result.duplicates} deduplicated_issues unique [issue for issue in candidates if issue.id not in duplicate_ids]同等的路由测试存在于 test_issue_deduplicator.py。另外注意 DECISIONS.md 记录了一个后期测量dedup 的输出 token 在 xhigh 下由 adaptive thinking 主导而非答案本身schema 只含 ids≤~700 token最坏一例 36-finding PR 输出 28,899 token / $0.35——这是后续可以再做一次efforthigh的尾巴优化。3.4run_oneshot_review的单元测试test_direct_llm.py 精确锁定了 gateway 调用的契约assert mock_get.call_args.kwargs[product] review_hog assert kwargs[model] ONESHOT_MODEL assert kwargs[output_config] {effort: ONESHOT_REASONING_EFFORT} assert kwargs[output_format] is IssueDeduplication assert kwargs[thinking] {type: adaptive}四、测量项与运行循环4.1 七项测量指标PLAN 明确了七项测什么PLAN.md机制mechanics运行时间线上没有sandbox_prompt:chunking/sandbox_prompt:dedup任务dump 的 per-model 统计里 chunking/dedup 生成以claude-sonnet-5ai_productreview_hogai_stage出现silent-fallback 防护也适用于 one-shot 调用。Chunk-plan 质量主要切分数与接缝 vs 归档分布在 2-chunk 的 backend/frontend 切分与好的 3-chunk 的 core.py / tooltoolkit / frontend 切分之间抛硬币17 次归档采样来自 2 次 e2e 与 5 次离线采样的全覆盖检查每个可审文件恰好出现一次。Dedup 决策主要raw→dedup 幸存集合 vs 归档行为——明显的重复坍缩仍发生、无新假合并抽查幸存者与 raw 发现列表。漏斗raw→dedup→valid vs C1/B 区间次要附结构 caveat。阶段成本/时间chunkingdedup 阶段墙钟C1 测得 dedup 阶段约 10 分钟含沙箱 provisioning预期远低于 1 分钟与 per-stage token经ai_stage切分。Schema 失败构造上期望 0对比归档中 14 次 chunking 任务的 4 次失败。Judge vs old-10按既定协议产出judge_results.json报告写FINAL_REPORT.md。4.2 每轮运行循环从../2026-07-pipeline-models/PLAN.md继承一次完整运行PLAN.md预检见下记录RUN_START_EPOCH$(date %s)然后执行不带--publishflox activate -- bash -c SANDBOX_PROVIDERMODAL_DOCKER DJANGO_SETTINGS_MODULEposthog.settings \ python manage.py run_review --pr-url https://github.com/PostHog/posthog/pull/62096 \ --team-id 1 --user-id 1Dump写结果前必须先 dumpLABELONESHOT-n RUN_SECONDSs RUN_START_EPOCHepoch \ OUT_DIRproducts/review_hog/eval/experiments/2026-07-oneshot-chunking-dedup/runs \ flox activate -- bash -c DJANGO_SETTINGS_MODULEposthog.settings python manage.py shell -c \ \exec(open(products/review_hog/eval/scripts/dump_result.py).read())\no-verdict 检查reset 之前grep -c no-verdict dump若有则重跑run_reviewskip-resume 只重试缺失 verdict 的部分并以相同 label 重新 dump。模型与机制验证强制per-model 统计显示 review/validation 仍在 sonnet-5且 chunking/dedup 生成不在沙箱路径上——通过ai_stage/ai_product属性查询本地$ai_generation事件与不存在 chunking/dedup 沙箱任务双确认。Run 1 dump 之后reset 之前运行离线 chunker 采样sample_oneshot_chunker.py→runs/chunker-offline-sample.md。最后flox activate -- bash -c DJANGO_SETTINGS_MODULEposthog.settings python manage.py reset_review_hog --yesdump 在 reset 之前。4.3 预检清单每次运行PLAN 的预检清单PLAN.mdWorker 已启动并热重载当前代码nodemon 监听products/启动时间需晚于文件 mtimereview-pr workflow 活动期间绝不编辑 workflow 读取的常量ngrok 已启动SANDBOX_PROVIDERMODAL_DOCKERfloxDEBUGTruePR head 复核 ba725a89LLM gateway 运行在 :3308 且已加载review_hog产品uvicorn --reload 会拾取配置编辑——但 reload 会切断 live 流所以 gateway 配置编辑只在轮次之间进行。2026-07-03 已做过 smoke 验证一次 one-shot dedup 调用端到端成功 →$ai_generation带 modelclaude-sonnet-5、ai_productreview_hog、ai_stage 戳593 in / 20 out环境坑仅 agent 驱动的 shellPostHog Desktop harness 会把LLM_GATEWAY_URL覆盖成它自己的本地代理——手动 shell 调用要加前缀LLM_GATEWAY_URLhttp://localhost:3308从普通终端启动的 Temporal worker 拿到的是正确的 debug 默认值不受影响上一轮的 DB reset 已完成dump-before-reset 纪律。五、离线采样器低成本、无流水线的分块质量探针5.1 基于 DB 快照的sample_oneshot_chunker.py实验设计了一个廉价去噪器sample_oneshot_chunker.py在 run 的数据仍在 DB 里时dump 之后、reset_review_hog之前对最新 team-1 ReviewReport 的持久化pr_snapshot连发 N 次直接的 one-shot chunker 调用。每次采样是一次 gateway 调用约 cents无沙箱串行执行。运行方式N_SAMPLES5 OUT_FILEproducts/review_hog/eval/experiments/2026-07-oneshot-chunking-dedup/runs/chunker-offline-sample.md \ python manage.py shell -c exec(open(products/review_hog/eval/experiments/2026-07-oneshot-chunking-dedup/sample_oneshot_chunker.py).read())脚本逻辑要点加载最新的PRSnapshotArtefact用count_reviewable_additions计算可审新增行若additions SINGLE_CHUNK_GATE_ADDITIONS或 CHUNKING_ONESHOT_MAX_ADDITIONS会打印 WARNING说明生产环境在这个尺寸下根本不会走该路径然后generate_chunking_prompt(...)渲染当前 prompt循环run_oneshot_review(..., model_to_validateChunksList, step_namechunking-offline-sample)。每个样本输出 chunk 数、每块的新增行分布并在最后做全覆盖校验missing/extra/ 重复文件出现即标记COVERAGE VIOLATION落盘到指定 OUT_FILE。5.2 完全本地的sample_oneshot_chunker_fixture.pyprompt 迭代场景下实验还提供了不需要 GitHub、不需要 DB的 fixture 变体sample_oneshot_chunker_fixture.py直接解析拓扑轮冻结的pr62096.diff复用与真实 fetch 相同的测试/lockfile 过滤器和补丁解析器渲染当前 chunking prompt连发 N 次直接 gateway 调用。N_SAMPLES5 python manage.py shell -c exec(open(products/review_hog/eval/experiments/2026-07-oneshot-chunking-dedup/sample_oneshot_chunker_fixture.py).read())已知与真实运行的偏差fixture 中没有 PR body所以PR_INTENT只带标题——对切分结构检查无影响。同样在 agent shell 中记得加LLM_GATEWAY_URLhttp://localhost:3308前缀。这两个采样器让chunking prompt 迭代的成本趋近于零且完全本地——这也是后续 prompt 修正能被快速验证的关键基础设施。六、运行结果与关键读数6.1 漏斗、成本与时间per runrunchunksdrawunitsraw→dedup→validfetch→chunk planwave-end→dedup donetotal tok (in/out)wall-clockONESHOT-12unpinned813→11→1047s/attempt*38s33.9M/230k sonnet-52374s incl.*eff ≈ 34 minONESHOT-23unpinned1218→14→936s54s53.1M/352k sonnet-51626s27.1 min, clean* ONESHOT-1 的 chunking 首次尝试被一次中途 worker 重启丢弃用户发起Temporal 在 5 分钟 heartbeat 超时后重跑——属于 infra 事件不是路径问题。对照基线C1all-sonnet、钉扎、沙箱 dedup/chunking18→11→743 分钟其中 dedup 阶段约 10 分钟B 对 17→11→6 / 18→14→6有效约 21 分钟。漏斗对比带有 unpinned-vs-pinned 的 chunk 结构 caveat。时间收益直接体现在机制上combine→clean→dedup→persist 坍缩到38–54s对比 C1 的约 10 分钟fetch→chunk-plan 是36–70s。两个 one-shot 阶段合计约$0.29/run naive每阶段约 50k in / 4k out。6.2 Old-10 覆盖率judgeroot-cause 匹配V 抓到且 validator 判 valid ·i 抓到但 validator 驳回 ·. 漏掉old# | O1 O2 | 1 | . . | 任何一轮都没出现此前 0/21 2 | V V | O1 只抓到一半O2 把完整根因拆到两条 VALID 发现里 3 | V V | 每一轮每一次运行都抓到 4 | . . | 从未出现此前 0/21 5 | V . | 第三次浮出水面——此处 VALIDupdate_action 步骤替换未被标为危险 6 | V . | 第三次 VALID无界的 compact list 输出 7 | . . | 只出现过一次B2被驳回 8 | . . | 从未出现旧 must_fix 9 | i . | validator 用合理的既有模式反驳将其驳回 10 | . . | 从未出现旧 must_fix技能内容盲区#1/#4/#8/#10依然存在——与每一轮一致它们住在 review 阶段而本次实验没有触碰该阶段。6.3 新发现judge 对照 diff 与仓库验证runnew_plausible其中 validator-VALIDnew_junk通过 validation 的 junkO16600O2664全部被驳回0两轮独立浮现的亮点list_actions的对象级访问控制绕过must_fix、VALIDjudge 对照filter_queryset_by_access_level先例验证——注意 sonnet-5 轮的 judge 对相关 finding 家族有分歧此变体通过了验证和$autocapture-only 元素过滤的静默退化。O1 的 validator 获得 judge 明确表扬每条 VALID 事实准确、一次有理有据的驳回、并抓出某条发现的修复建议不可行。6.4 One-shot 机制记分板check结果chunking one-shot ≤5k adds✓ 两轮 live PR每轮 1 次生成review_hog/chunkingdedup one-shot ≤50 findings✓ 两轮每轮 1 次生成review_hog/dedupdedup sandbox fallback 50✓ live PR #6741961 raw → 沙箱 dedupreview_hog/dedup生成数为 0schema 失败0结构化输出阶段归因✓ai_product/ai_stage戳把运行阶段与本地 cron 噪声区分开live publish✓ #67419 评审已发布30 条内联评论钉扎到 headpublished_head_sha已设置6.5 唯一的回归信号one-shot chunker 把小型 PR 切碎在 #62096497 可审新增行上in-pipeline draw 为 2、3离线批 4、4、4、3、3——n7 总分布 2,3,3,3,4,4,4碎片最小到 16 行。而同一 PR 的沙箱归档只出现过 2 或 317 次运行约 50/50。到大规模时效应消失3217 行的 live PR 拿到了干净的 6-chunk 计划约 536 行/块对比 300 行目标的 naive 11 块。每次 draw 覆盖率都完整。用户的裁决2026-07-03约 500 行的 PR 切 4 块明确太多——这是成本风险units chunks × 44-draw 会把 review 阶段成本翻倍 vs 2-draw而非正确性风险覆盖率在所有 draw 中都完整。这命中了 chunking 半边chunk plans degrade的 kill criterion。随后2026-07-04用户批准后应用了prompt 修正给prompts/chunking/prompt.jinja的 sizing 规则加了约 100 行下限 计数公式上限。2026-07-06 验证用sample_oneshot_chunker_fixture.py完全本地对 #62096 fixture 的 5/5 draw 每轮 2 块、全覆盖、零 100 行的碎片——未调优时 4,4,4,3,3 的切碎消失了。chunking 半边因此可以随 dedup 一起采纳。七、评分、kill 标准与决策记录7.1 评分流程每个 dump 对照 old-10 由 judge 评审与先前轮次相同的协议/promptraw 输出进judge_results.json用户最终复核 judge 的调用叠加上面六项阶段聚焦读数。7.2 Kill 标准item 7 改编dedup 幸存集合与归档 dedup 行为背离假合并或漏掉明显重复跨运行成立或 chunk plans 相对归档切分退化覆盖率破坏、接缝不连贯、系统性单文件切碎。Win ⇒ 默认开启的代码保留用户提交kill ⇒ 回滚 把两个门控设为 0沙箱行为字节级回归。7.3 已锁定的决策2026-07-03/04不钉扎 e2e ×2 离线 5 采样 chunker 批——chunk-plan 质量直接判定漏斗读数带结构 caveat门控指标 仅新增行——与SINGLE_CHUNK_GATE_ADDITIONS/CHUNK_TARGET_ADDITIONS口径一致review_hog注册为 gateway 产品——永久 parity 管道永久代码、默认开启于 5000/50——翻开关看风格回滚 两个常量用户提交一切agent 只编辑文件自 sonnet-5 轮起的常设约定任何运行都不 publish结果目录runs/位于本文件旁chunker-shatter 修复 prompt 调整先 DEFERRED现在不做再 APPLIED见 6.52026-07-04post-round、本分支上独立的 prod 变更VALIDATION_MODEL从claude-sonnet-5回退到claude-opus-4-8effort 保持 XHIGH——因用户观察到 sonnet validator 的量宽松倾向constants 测试保持绿色。与 one-shot 变更无关记录于此只因为它共享分支JUDGING DONE 2026-07-04→judge_results.jsonFINAL_REPORT.mdold-coverage 4 validO1含 #5 第三次浮出水面 #6 第三次 VALID/ 2 validO2对比 B 对的 3/1两轮 validated-junk 都是 0dedup 决策 in-band建议 现在采纳 dedupchunking 等调优 prompt 的批量验证或期间把门控设 0。三次 judge-agent 尝试有两次死于 harness infra一次中断级联、一次 gateway 502第三次成功。八、结论、交接与成本8.1 最终报告结论TL;DRFINAL_REPORT.md 的核心结论机制在门控两侧都成立≤5k 行的 chunking 与 ≤50 findings 的 dedup 以单次 gateway 调用运行每轮通过ai_productreview_hogai_stage戳验证、无 chunking/dedup 沙箱任务live PR #674193217 行、61 raw findings同时触发了 one-shot chunking 与50 的沙箱 dedup 回退然后正常发布。节省的是时间与可靠性不是 tokencombine→clean→dedup→persist 坍缩到38–54sC1 约 10 分钟fetch→chunk-plan 36–70s两阶段合计约$0.29/run naiveschema 失败 0 by construction结构化输出对比归档 29% 的 chunking schema 失败类。质量保持漏斗 13→11→10 与 18→14→9 valid0 no-verdictvalid 数持平或高于此前每一轮old-10 覆盖 4 validO1与 2 validO2对比 sonnet 轮 B 对的 3/1两轮 validated-junk 都是 0每条 VALID 都被 judge 验证为事实准确dedup 削减比例与归档行为一致无假合并或橡皮图章信号。一个真实的回归信号one-shot chunker 把小型 PR 切碎4,4,4,3,3 vs 沙箱 2–3——但覆盖率完整、大规模下消失prompt 修正后2026-07-06 验证 5/5 draw 2 块、全覆盖、零碎片。范围外 watch itemsonnet-5 validator 体积宽松这里 91%/64%、live PR 86% 且 30 条内联评论虽然 #62096 上它放行的没有 junk用户在轮末把VALIDATION_MODEL回退到claude-opus-4-8 xhigh。8.2 建议现在采纳 one-shot dedup——门控两侧路由都已验证、决策与归档行为一致、0 validated junk、阶段时间约 10 分钟 → 1 分钟、两类失败消失。也采纳 one-shot chunking——调优后的 prompt 已验证#62096 上 5/5 draw 2 块、无碎片CHUNKING_ONESHOT_MAX_ADDITIONS 0仍是线上行为出意外时的即时回滚。两条路径在分支上默认开启采纳 提交它。8.3 交接项Validator 轮sonnet validator 的体积宽松91%/64%/86% 存活率且 #62096 零 validated junk是校准数据点而非 junk 泄漏——但 live PR 上 30 条内联评论是 UX 问题。轮末VALIDATION_MODEL已回退到claude-opus-4-8 xhigh用户。Chunker prompt 调优已验证5/5 干净 draw。fixture 采样器让未来的 prompt 迭代几乎免费且完全本地——未经批量验证不要再发布 prompt 改动。技能内容轮#1/#4/#8/#10 在又一个配置下仍然全盲——结论不变。Infra两个非路径事件值得记住——activity 中途的 worker 重启会造成 5 分钟 heartbeat-timeout stallone-shot 调用中途不可续Temporal 会整体重试desktop-harness 的LLM_GATEWAY_URL覆盖可能误导 agent-shell 脚本worker 不受影响。8.4 本轮成本约 87M in / 580k out2 轮naive 约 $350真实成本远低——缓存读占主导 约 10 次离线 chunker 调用约 $1 2 个 judge agent。one-shot 阶段本身约 $0.29/run naive。九、方法论要点与可迁移经验这个实验对任何把 agentic sandbox 阶段降级为一次 LLM 调用的工程决策都有参考价值先看任务性质再决定架构dedup 归档里 14/20 次调用零工具使用、chunking prompt 完全自包含——纯文本任务是去沙箱的判据而不是凭直觉。可用grep/归档统计直接验证工具使用率。用门控而不是一刀切CHUNKING_ONESHOT_MAX_ADDITIONS/DEDUP_ONESHOT_MAX_FINDINGS让小规模走快路径、大规模保留沙箱沙箱能导航仓库、不必一次性 hold 全 PR门控设 0 即整体回退给了字节级一致的回滚面。两条路径共享同一 prompt避免模型/提示词漂移。结构化输出消灭一类失败把 pydantic 模型作为output_format让 SDK 在构建响应时校验max_tokens截断也会以确定性方式标为 non-retryable——schema 失败类从运行时故障变成不可能事件。混杂变量要显式声明模型 执行模式一起变是端到端态测试end-state-config style解读质量读数时明确钉扎 vs 不钉扎的 caveat把漏斗读数降级为次要指标。低成本探针基础设施sample_oneshot_chunker.pyDB 快照与sample_oneshot_chunker_fixture.py本地 diff fixture让 chunk-plan 质量在每次 run 之外可重复、批量、廉价地采样——prompt 调优验证5/5 draw正是靠它完成的。质量信号要多维漏斗 valid 数、old-10 覆盖率、validated-junk 数、dedup 幸存集合、chunk 切分分布各自回答不同问题单看任何一维都可能被结构 caveat 误导。相关仓库路径索引实验计划与结果PLAN.md、FINAL_REPORT.md、judge_results.json运行 dumpruns/ONESHOT-1.md、runs/ONESHOT-2.md、runs/chunker-offline-sample.md采样器sample_oneshot_chunker.py、sample_oneshot_chunker_fixture.py核心实现direct_llm.py、constants.py、activities.py、issue_deduplicator.py测试test_direct_llm.py、test_issue_deduplicator.py、test_review_activity.py背景POTENTIAL_EXPERIMENTS.md、DECISIONS.md、ARCHITECTURE.md、gateway_client.py、llm-gateway products 配置【免费下载链接】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），仅供参考