tb-v4 memory 门控验证: 69/89 · 0.775

各改进点的生产验证结论

注意：本次运行的事件名为 context.*（改名后），分析脚本同时兼容 memory.*。

新发现：input-balloon 恶性循环

compaction 与 reward 的关系

报告之后的新改动（442396d，待下次全量验证）

1. Summarizer 输入 cap（DEFAULT_SUMMARIZER_INPUT_CAP_CHARS=150k）：attempt 1 永远读全量；attempt 2 先 compact_observations 折叠（对子完整、verbatim 用户保留）再喂。§2 的恶性循环（失败→boundary 停→输入胀→更易失败，MIPS 胀到 54 万字符）就靠这个打破：cap 只勒病态尾巴，正常 segment（成功 yield 多在 12–124 msgs）几乎不触发。trace 记 input_capped + 截前/截后字符数（.invalid / .yield 均有）。
2. AgentTurn 级 hard-gate 集成测试：之前 HardGateRecoveryTests 用手写 refresh 绕过了真 hook；新测试跑完整 run_turn，覆盖 genome 算 70% target → refresh_view(force_budget) → 按 size 判进展整条 wiring。
3. 调大预算验证不了 hard gate：预算只管 soft gate；hard gate 开火的唯一条件是 provider 400（请求 > 模型上下文）。60k vs 1M 注定零触发 —— 这是系统正常工作的表现，不是缺验证。真要生产开火，需小上下文模型 + 大预算（见 §1 表格）。

澄清：prompt 透传 bug 已修（9291f51，改名后复查健在）

逐任务明细（报告原表 88 行）

列：iters（llm.start）/ compact（apply 事件）/ yield（真快照）/ inval（空/缺§2/缺§3）/ retry 救活 / preserved（带 verbatim 用户的 yield 数）/ frozen（md5 复用）/ boundary（多 yield 是否单调）/ reward。

reward 0.0 的 20 个任务归因（harness / 环境 vs 模型能力）

先澄清口径：verifier 不是我们写的，是 TB 官方的 —— evaluation/terminal_bench/readme.md 写明 “Harbor runs the task's own verifier”，判分跑在任务镜像（alexgshaw/<task>:20251031 等）自带的 /tests/test_outputs.py + test.sh；src/agent_runtime/agent/verification.py 头注释写明 “It never executes gold tests here”，我们的 harness 只做 submit_result 形状 / 引用门控。所以 0 分是官方判的，能修的只有自家 harness bug，官方测试问题只能报 issue + quarantine。

后续观测点

1. 再跑全量（比如验证 cap 有没有把 MIPS 的 41 连败打下来），trace 里直接看 invalid 的 input_capped 和截后字符数就行，观测点都是现成的。
2. llm.wire.dangling_tool_calls_dropped：跑新任务集时 grep 该日志。出现且 count>0 = B 在兜底，说明又有路径造出了悬空 tool_calls（历史只存、wire 修），值得回头定位是哪条路径（submit 以外的拦截 / compaction 切片 / 新工具），而不是视为正常。
3. raman 类 400 是否归零：之前 LLM error 400: ... tool_calls must be followed by tool messages 直接杀死整轮；修复后该错误应不再出现。若再现，先查 trace 里被 contract 打回的 submit 与 dangling_tool_calls_dropped 是否同时出现。

Artifacts & record