Hyperloom Specialist 与配置调优：一个 Agentic 调参系统的源码拆解

拆解 AMD Hyperloom 的 specialist 实现与服务配置调优链路：knob 面、变体指纹、贪心爬山、衰减接受线与单次测量的方法学边界

这是一份对 AMD-AGI/Hyperloom 的源码级拆解，读的是 2026-08-04 的主干快照（v1.0.0a2，MIT）。结论带 文件:行号，从代码而非 README 得出；README 与实现不一致的地方单独标注。本文不含任何性能承诺——主要结论之一恰恰是：这套系统报出的收益数字不能当测量值读。

30 秒复习

一句话：Hyperloom 的调参不是搜索算法，是「LLM 提议 flag + 确定性代码把关」。提议侧没有参数空间模型，把关侧的工程质量很高但统计学是空的。
三个判断：knob 完全无类型（自由字符串，不校验合法值）；接受阈值按 0.1 + 0.9/N 逐 cycle 衰减，第 10 个 cycle 降到 0.19%，穿到了代码自己声称的噪声地板之下；每个变体只测一次，全仓唯一带重复采样和显著性检验的工具没有任何调用方。
来源问题：这份源码回答一个 agentic 调参系统的 knob 面从哪来、变体如何去重与验收、以及收益数字能被当作测量值到什么程度。
值得抄的：禁止 agent 自报加速比（机器强制）、内容寻址指纹去重、冷热轮分离、12 类失败分类学、KEEP 后二次复测。
边界：静态阅读，未实际运行过；跨运行知识沉淀有多处字段投影丢数据，「self-evolving」在 OSS 版本里基本不成立。

1. 范围与术语

Hyperloom 的整体流水线是 Magpie 采 trace → TraceLens 出 roofline 目标 → Arbor 做搜索 → GEAK 优化 kernel。方法论背景见 Agentic Infra：LLM 推理性能优化。

本文只拆两件事：specialist 子系统怎么实现，以及服务配置的超参数调优怎么做。kernel 生成（GEAK）和 trace 分析（TraceLens）不在范围内。

术语对齐：这里的「超参数」不是训练超参，而是推理服务的配置量——server 启动参数（--max-num-seqs、--kv-cache-dtype）和环境变量（VLLM_ROCM_USE_AITER、HSA_ENABLE_SDMA）。代码里管一次配置改动叫 variant（变体），管一个可调项叫 knob 或 lever。

2. 可调什么：knob 面

没有 knob 注册表

这是理解整套设计的前提：Hyperloom 没有任何 per-knob 的类型定义。没有名字表，没有类型，没有合法区间，没有默认值，没有「这个 knob 属于哪个框架」，没有「改了要不要重启」。

一次配置改动的完整载体就是这个 dataclass（actions/executors/_grid_base.py:73）：

@dataclass
class GridVariant:
    name: str
    extra_server_args: str = ""          # 自由字符串，LLM 直接写
    extra_envs: dict[str, str] = field(default_factory=dict)
    remove_args: list[str] = field(default_factory=list)
    unset_envs: list[str] = field(default_factory=list)
    args_mode: str = "append"            # 或 "replace"
    note: str = ""

对 knob 的校验只有结构层，没有语义层：

参数串必须能被 shlex 切开、不含 shell 元字符、必须是 flag 形状（_grid_server_args.py:32）
环境变量键必须匹配 ^[A-Za-z_][A-Za-z0-9_]*$ 且不在 secret 名单里（common/env_safety.py:57）
环境变量值只做 str(value)，从不做区间检查

--max-num-seqs 999999 和 VLLM_ROCM_USE_AITER=maybe 都会被原样送进去，靠 server 启动失败来发现。这是有意的取舍：失败带 error_class 记进台账让 LLM 下次别再选，代价是烧掉一次 benchmark。

真正花了工夫的地方是容忍 LLM 输出不规范：_coerce_args_str（explore.py:112）接受 JSON 数组并空格拼接；coerce_extra_envs（_grid_base.py:160）接受 dict、"FOO=1 BAR=2" 字符串、["FOO=1"] 列表、[{"FOO":"1"}] 列表套字典四种形状；split_config_changes（_grid_server_args.py:190）按前导 - 把一个扁平 dict 拆成 args 和 envs。

knob 词汇表散在五处

来源	位置	内容
种子网格	`explore.py:262`（atom）、`:350`（xdit）	只有 atom / xdit 有代码定义的初始网格；sglang 和 vLLM 返回 `[]`，冷启动完全依赖 LLM，无输入时直接 `empty_grid` 失败
Prompt focus 块	`prompts/specialist_prompt_builder.py:670`	每个 domain 一段 Markdown 散文，knob 名字写在文字里
强制注入 / 守护	`_grid_server_args.py`、`_workload_envs.py`	不是候选而是硬默认，如 `--watchdog-timeout 1800`、MoE 中间维非 128 对齐时剥掉 `--attention-backend aiter`
精度风险名单	`_accuracy_gate.py:336`	5 个 CLI 子串 + 10 个环境变量键，只有命中的才跑精度门禁
黑名单	`_grid_variant_filter.py:309`	xDiT 的已知崩溃组合，但这个过滤器在生产路径无调用方

prompt 里的 knob 是散文形式的。举个真实例子（specialist_prompt_builder.py:251，kernel_switch domain）：SGLang 的 --attention-backend 枚举 ROCM_AITER_MLA / TRITON_MLA / ROCM_AITER_TRITON_MLA，vLLM 的枚举 ROCM_ATTN / ROCM_AITER_FA / ROCM_AITER_UNIFIED_ATTN / FLASH_ATTN，还专门标了一个陷阱值 ROCM_FLASH（无效）。这些知识只存在于 prompt 文本里，代码不知道。

serving domain 那一段还带 ALWAYS_ON / NEVER_TOUCH 标注（VLLM_ROCM_USE_AITER=1 常开，VLLM_ROCM_USE_AITER_RMSNORM=0 别动），以及反向 knob（MLA + FP8 上别开 torch.compile）。这套东西本质是把一份人类调参手册塞进 prompt。

覆盖到的类别：批处理调度（--max-num-seqs、--max-num-batched-tokens、--enable-chunked-prefill）、KV/显存（--kv-cache-dtype fp8_e4m3、block_size ≥ 16、--gpu-memory-utilization）、attention 后端、编译与图捕获（--compilation-config、--enforce-eager、--cudagraph-capture-sizes）、通信（VLLM_ROCM_QUICK_REDUCE_QUANTIZATION=INT4、NCCL_MIN/MAX_NCHANNELS）、驱动与系统（HSA_ENABLE_SDMA=0、HIP_HIDDEN_FREE_MEM、numactl --cpunodebind）。这些 knob 各自的语义见批处理与调度和推理 Kernel / Runtime 优化。

SKILL.md:897 还列了一批「specialist 可以自行提出」的候选族（--disable-radix-cache、--max-running-requests、--stream-interval、SGLANG_OPT_USE_MULTI_STREAM_OVERLAP），这些只在文档里，代码完全不知道。

框架覆盖与跨框架翻译

framework_registry.py:62 是一张五行表：sglang（默认）、vllm、atom 是 serving 类；xdit、hunyuan_image3 是 scriptable 类（无 server，单命令，用 LPIPS/SSIM 图像质量门禁替代精度评测，排序指标翻转成 e2el_mean_ms）。

框架分派靠字符串子串匹配，而且判据是「解析出来的环境变量名」而不是框架本身——if server_args_env_name(framework) != "EXTRA_SGLANG_ARGS": return args 这个模式在 _grid_server_args.py 里出现 5 次（592、725、797、920、989）。未识别的框架串会静默按 sglang 处理。

跨框架 knob 拼写差异只在一处硬编码特例里被处理（_workload_envs.py:1020）：

_mimo_is_vllm = "vllm" in str(bench.get("framework") or "").lower()
# sglang accepts lowercase `triton`; vLLM only knows TRITON_ATTN.
_mimo_attn_backend = "TRITON_ATTN" if _mimo_is_vllm else "triton"

没有通用翻译层。所以在 sglang 会话里提一个 vLLM 专属 flag，会被原样写进 EXTRA_SGLANG_ARGS，然后 sglang 的 argparse 在启动时报错——烧掉一次 benchmark。框架间实现差异为什么难做成通用层，见推理框架对比 2026。

3. specialist：提案的生产者

10 + 1 个 domain

specialists/domains.py:73 是一个硬编码的 10 项 tuple，外加一个合成的 freeform_specialist：

key	负责层	kb_anchor
`serving_specialist`	sglang/vllm scheduler、cuda_graph、kv_cache、chunked prefill	framework
`kernel_switch_specialist`	aiter / sglang kernels / triton，attention、MoE、GEMM	kernel_agent
`comm_specialist`	RCCL/NCCL、AllReduce、QuickReduce、拓扑	communication
`compiler_specialist`	torch.compile、inductor、AMDGCN、寄存器压力	compiler
`system_specialist`	KFD/driver、launch latency、dispatch 开销、numactl	systems
`pr_intel_specialist`	跨仓库 PR 调研，给其他 specialist 喂 ref	pr_intelligence
`research_scout_specialist`	只读：参考脚本、config.json 架构特性、NVIDIA PR/MLPerf	research_scout
`static_recon_specialist`	只读：grep 源码找被 predicate 静默关掉的快路径	static_recon
`enablement_specialist`	让跑不起来/精度不过的组合能跑对，可改到 /opt/rocm、HIP、aiter	framework
`cross_framework_rewrite_specialist`	sglang ↔ vllm 特性移植，重写而非 git-apply	framework

**domain 只是一个字符串。**它唯一的作用是选一段 prompt focus 模板和一个 KB anchor 标签，没有任何 per-domain 代码。README 说的「Dynamic Specialist Agent」就是这个——不是学出来的 agent，也没有动态合成。

一个 specialist 就是一个 claude CLI 子进程

这是最值得注意的实现事实（specialists/subprocess_.py:705）：

claude --print --output-format stream-json --verbose
       --permission-mode bypassPermissions
       --system-prompt-file <workspace>/prompt.md
       -p "Execute the task in your system prompt. Work autonomously.
           Write specialist_done.json as your absolute last action."
       --allowedTools <csv> --add-dir <worktree> --add-dir <workspace>

隔离：git worktree add -b specialist-<task_id>，真 worktree 不是拷贝。找不到 git root 时会降级为无写隔离继续跑（runner.py:1378）
权限：bypassPermissions 是默认值（subprocess_.py:166）。源码注释给了理由——claude-cli 的安全分类器依赖另一次网关调用，降级时曾经「96 次 classifier-unavailable vs 6 次成功运行」，直接烧完预算
Bash 不过滤。runner.py:98 原话：“Bash is granted unfiltered — there is no per-call filter. Safety rests on the isolated git worktree, this allowlist, and Critic + PolicyGate review.” SPECIALIST_TOOL_DENYLIST 是空集
并发数 = 2 × GPU 数（policy/gate.py:205），探不到 GPU 时兜底 2。8 卡 MI300X → 16 个并发 CPU specialist；但要 GPU 的 specialist 走 gpu_research_lane，容量是 1，严格串行
--max-turns 从不传。specialist.yaml 里写的 max_turns: 12 不生效，运行时默认 1000（domains.py:359），真正的停止条件是墙钟：min(base × (cycle+1), 240min)，base = 10min（CPU）/ 60min（GPU），带 bench 的地板 140min
存活判定：每 5s 轮询，heartbeat.json 或 process.log 的 mtime 超 300s 未更新才收割，实际约 10 分钟静默才杀
prompt 规模实测 ~4–7k token，大头是 13–15KB 的静态 domain playbook，不是遥测数据

自动重试 SPECIALIST_AUTO_RETRY_MAX = 2（loop/coordinator.py:27），只对 TIMEOUT / STALE_HEARTBEAT / CRASH 三种基础设施故障重试；语义失败（空提案、工具违规）不重试。注意 specialist executor 从不抛异常——每条退出路径都合成一个 specialist_done 载荷，所以 SubAgentResult.state 永远是 succeeded，真实结果藏在 result["runner_status"] 里。

domain 选择：一个真实的评分函数，但纯咨询性

phases/explore.py:134 的 _plan_cycle_focus 是确定性打分，结构上能看出探索-利用的意图：

信号	权重
匹配当前 `bottleneck_shift.to_domain`	+5.0
该方向已在 roofline 内饱和	−100.0
未饱和	+1.0
历史 cycle `gain_delta`	clamp(−2.0, +3.0)
还没当过 cycle focus（探索奖励）	+1.5
近期负台账计数	−min(4.0, 0.5·count)

两个问题：

候选集只有 5 个 domain。来源是 BOTTLENECK_DOMAIN_HINTS（kernel/roofline_snapshot.py:659，5 个方向映射到 4 个 domain）加 freeform。compiler_specialist、enablement_specialist、cross_framework_rewrite_specialist 等 6 个永远不会被选为 cycle focus，只能靠 LLM 直接派或内部 enqueue。
负反馈那一项是断的。_negative_ledger_domain_counts 按 domain / specialist_domain / source_domain / provenance 取 key，但写入 explore_search 台账的行只有 provenance，取值是 llm_direct / default_grid / specialist:<tag>——没一个是 domain key。惩罚全落到凭空造出来的 key 上，5 个真实候选一分不扣。

而且 focus 的输出是纯咨询性的：PolicyGate 的 specialist 门禁完全不读它，prompt 里那行字面写着 "Advisory only: use this as a prior, not a dispatch gate."

唯一确定性的强制派发是「停滞 domain 兜底」（phases/explore.py:533）：per-anchor 计数器 rounds_since_last_specialist ≥ 8 或 rounds_since_last_keep ≥ 12（coordinator.py:258）时强制派一个，每 tick 最多一次，选 gap 的规则是最高严重度 → 尝试最少 → 最旧。这条是真的轮转覆盖保证——任何知识域不会被饿超过 8 轮。

提案的质量控制：禁止自报数字

这是整套系统里最该抄的一条。patch_safety.py:33：

FORBIDDEN_PROPOSAL_FIELDS = {
    "expected_gain", "expected_gain_pct", "bench_evidence",
    "confidence", "score", "rank", "force_provenance",
}

外加 4 条正则扫自由文本里的 % / x / ms|us|tok/s|qps|tps / speedup of N（:47）。prompt 里也明确写「the Coordinator measures gain」。禁用字段是硬信号，数字声明是 advisory 警告——两者都不丢弃提案，但都进 notes 留审计痕。

提案还有个 4 模型 LLM 集成打分器（scoring/proposal_scorer.py，claude-opus-4-8 / gpt-5.5 / Kimi-K2.6 / gemini-3.1-pro），输出 0–10 整数，最多打 16 条。它是结构性咨询的：渲染时把模型名替换成 rater_1..rater_N、不算均值、不排序，prompt 里写「Advisory only — one reference among many, NOT a ranking directive」，还叮嘱「不要猜 rater_N 是哪个模型」「评分者之间的分歧本身是不确定性信号」。唯一的非 prompt 用途是 Langfuse 里的预测-实测校准遥测。

4. 从提案到可运行变体

指纹：内容寻址，但不含 workload

_canonical_fingerprint.py:64，16 位 SHA-1：

args_tokens = sorted(shlex.split(args_text))
env_pairs = sorted((str(k), str(v)) for k, v in (extra_envs or {}).items())
# remove_args / unset_envs / args_mode / runtime_override 只在非默认时才进 payload
payload_obj = [args_tokens, [list(p) for p in env_pairs]]

故意排除：name 和 note（改名不影响去重，这个设计对）、framework、tp、workload_signature。

最后一项是真问题。workload_signature（CONC/ISL/OSL/PRECISION/TP 的 12 位摘要）只作为旁路元数据存着，不进哈希。后果是：一个在 CONC=64 测过的变体，会把 CONC=256 下的同一变体一起挡掉。对任何要扫 workload 形状的场景，这是硬伤。

还有个次要的归一化损失：排序后 --a 1 --b 2 和 --a 2 --b 1 都变成 ['--a','--b','1','2']，会碰撞。

`args_mode` 是黏性的

compose_server_args（_grid_server_args.py:171）两种模式：

append（默认）：remove_args 只作用于 inherited + base，变体自己的参数不被剪
replace：inherited_args 整个丢掉，remove_args 同时作用于 base 和变体自身——这是不对称的，LLM 要是把自己的参数写进 remove_args，会静默删掉自己的改动

更麻烦的是黏性（explore.py:1378、:1541）：一旦某个变体用了 remove_args 或 replace，本轮剩下的所有变体都切到 replace 模式，YAML 继承的参数对后续每个变体都被丢掉。

冲突参数靠三道「后者胜」来收：merge_server_args 故意不去重（「重复 flag 就是后者覆盖前者的手段」），然后 _shell_safe_dedupe 对所有框架跑一遍，dedup_vllm_server_args 只对 vLLM/atom 跑（sglang 是 no-op，因为 vLLM 对重复 flag 会硬报错）。两个去重器只要字符串里出现任何 JSON 值的 flag（--compilation-config、--hf-overrides、--speculative-config 等 7 个）就整体放弃，此时任意 flag 的重复都会存活。

物化：Hyperloom 默认不写 server 命令行

默认后端只产出 Magpie YAML（benchmark_backend.py:79），参数落在一个环境变量里（EXTRA_SGLANG_ARGS 等）。真正的 server 命令行由外部 Magpie/InferenceX shell 脚本拼，而且 $EXTRA_*_ARGS 是不加引号展开的。

这一个决定制造了大量偶然复杂度：compact_json_server_args、_reserialize_json_blobs、_repair_unquoted_json、_SPACE_VALUE_FLAGS、两个去重器——全部只为了伺候这个 unquoted splice。改成传 argv 数组（bypass 后端就是这么做的），这几百行可以全删。

workload 形状的映射在 _workload_envs.py：CONC / ISL / OSL / MAX_MODEL_LEN / TP 从环境变量读入，TP 会按可见 GPU 数自动夹取；客户端负载按序列成本分档推导（ISL+OSL ≤ 1024 → NUM_PROMPTS = CONC×10，≤4096 → ×5，≤16384 → ×3，更大 → ×2），NUM_WARMUPS = min(CONC, 8)。

运行前校验：只有一个真探针

检查	触发条件	位置
`validate_server_args_shell_safe`	shell 元字符、切不开、裸位置参数	`_grid_server_args.py:32`
`unsupported_capability_reason`	唯一的真 build 探针，30s 子进程	`_grid_runner.py:315`
sweep 组合剔除	`ISL+OSL > MAX_MODEL_LEN`	`sweep.py:108`
TP 夹取	`TP > 可见 GPU 数`	`_workload_envs.py:621`
模型闸门	15 个检测器的瀑布：vision-only、不支持的量化、rope 异常等	`model_gate.py:1648`

那个「唯一的真探针」只覆盖一个环境变量、一个框架：

fw = (os.environ.get("FRAMEWORK", "") or "sglang").strip().lower()
if fw != "vllm":
    return None
val = envs.get("VLLM_ROCM_USE_AITER_FUSION_SHARED_EXPERTS")

它有一个细节做得对：探针返回 unknown 时既不丢弃也不缓存——不确定就别拦。

没有任何探针检查「提议的 flag 是否存在」或「值是否合法」。

三张死掉的安全网

_grid_variant_filter.py 里有六个过滤器，只有两个接进了生产路径（多节点无效变体、aiter MoE pin）。以下全部只有测试调用：

apply_compatibility_filter — 连带整个 xDiT 崩溃黑名单（TRITON_HIP_USE_ASYNC_COPY 在 gfx950 上崩、AMD_DIRECT_DISPATCH=1 + AMDGCN_USE_BUFFER_OPS=1 已知 −28.6%、NCCL_PROTO=LL 回退 10–22%）和 --help 版本探针
apply_user_skip_list + resolve_skip_spec — --skip-variants CLI flag 一路传到 $SKIP_VARIANTS 和多节点子进程，但没有任何代码读回来；help 文本承诺的 state.json 里的 dropped_variants 字段，全仓只有那句 help 文本本身
_probe_server_help_text — 这是唯一能提前发现「flag 在当前框架版本里不存在」的机制

而 explore.py:361 的 docstring 明确写着「已知回退/崩溃 knob 在这里省略，并额外由 _grid_runner.py 的 xdit_blacklist_reason 强制」。那张安全网不运行。

5. 搜索算法：贪心爬山 + 衰减接受线

分类：不是任何一种经典优化器

代码里没有代理模型、没有采集函数、没有种群、没有 reward 后验、没有 UCB/Thompson 项。实际形态是：LLM 提议 flag，串行贪心叠加，确定性阈值判收。

分工很清楚。LLM 负责生成候选，它看到的全是 prompt 文本：gap 台账、TraceLens 的 analysis.md、4 模型集成的咨询打分、plateau 提示、当前接受阈值、可重测清单。确定性代码负责其余一切——去重、串行运行、冷热轮纪律、KEEP/REVERT 判定、二次复测、精度门禁、相位机。

关键机制：贪心叠加（有序依赖）

explore.py:1293 拿每个变体和 running_base_tput 比，而这个值每次确认 KEEP 后就地更新（:1542）。所以同一轮里第 k+1 个变体是叠在第 k 个变体的配置之上测的。后果：

顺序依赖：LLM 给出的网格顺序（多节点还会被 reorder_grid_for_multi_node 重排）会改变哪些变体被留下。代码不做任何顺序纠偏。
无交互搜索：synergy_attempted 这个台账字段存在、被读、被回传，但没有任何写入方。组合效应完全交给 LLM 去提一个合并变体。
设计规则明确写了一次只改一个（explore.py:20，理由是单租户 serving GPU）。

衰减接受曲线

这是整套设计里最值得单独讲的一处（phases/machine_state.py:429，已逐行核实）：

# Decaying acceptance curve: the marginal-gain bar shrinks each macro-cycle. The
# KEEP threshold, stack-stable threshold (=keep/2) and convergence gain bar all
# ride this single curve.
KEEP_THRESHOLD_FLOOR_PCT: float = 0.1
KEEP_THRESHOLD_SPAN_PCT: float = 0.9
# Multi-node baseline noise floor is ~2x single-node; scale the curve to match.
MULTI_NODE_KEEP_THRESHOLD_FACTOR: float = 2.0

def decaying_keep_threshold_pct(macro_cycle, *, multi_node=False):
    n = max(1, int(macro_cycle) + 1)
    base = KEEP_THRESHOLD_FLOOR_PCT + KEEP_THRESHOLD_SPAN_PCT / n
    return base * MULTI_NODE_KEEP_THRESHOLD_FACTOR if multi_node else base

注入点 loop/proposals.py:371，同时设定 stack_stable_threshold_pct = keep / 2.0。

macro_cycle N	KEEP 阈值	二次复测地板
1	1.00%	0.50%
2	0.55%	0.275%
3	0.40%	0.20%
10	0.19%	0.095%
→ ∞	0.10%（地板）	0.05%

同一条曲线同时驱动 KEEP 门槛、复测稳定性地板和每 cycle 收敛判据。

这条曲线的意图是合理的：越往后越只剩边际收益，台账里旧的次阈值变体会随着门槛下降重新可测（_is_blocked 在 explore.py:826 按 prior_gain < keep_threshold_pct 解锁）。问题是它和噪声地板的关系——见 §6。

去重台账

tested: dict[fingerprint → entry]，上限 _EXPLORE_TESTED_CAP = 5000，按插入序淘汰最旧
rejected: list，按指纹去重，无上限
accepted: list，唯一写入方是 record_explore_accepted
每行在合并时打上 cycle 和 bottleneck 戳

阻塞规则（explore.py:810）：KEEP / FAILED / KILLED_OVERTIME 永久阻塞；REVERT / KEEP_UNSTABLE 随阈值衰减解锁，解锁清单会作为「Re-testable now」进 prompt。

这里有个缺陷：KEEP_UNSTABLE 永远不会重新阻塞。它记录的 gain_pct 是复测前的决策轮增益，按定义已经过了 KEEP 门槛，所以 prior_gain < keep_threshold_pct 恒为假 → 永久可重测，而门槛只会继续降。一个复测不稳定的变体，恰恰是最不该再烧 2–3 次 benchmark 的那个。

并发度：严格串行

explore.py:1008 是 for idx, gv in enumerate(runnable) 顺序 await；_grid_runner.py:1214 同样。一轮里一次只有一个 server。注释解释了原因（explore.py:996）：per-variant ray.kill 会搞崩 raylet，所以一个 Ray serving lease 跨整轮，变体之间靠 driver 侧 pgid kill 收服务。

每个变体最多 3 次 benchmark：丢弃的冷启动 warmup、决策轮、KEEP 后的复测轮。6 个变体 2 个 KEEP 的一轮 = 14 次 server 侧 benchmark pass，全串行。

每变体的硬超时是 baseline_runtime_sec × (kill_ratio + 0.5)，夹在 [2400, 14400] 秒；软超时 decision_anchor_sec × 2.0，从 server-ready 开始算。

停滞与收敛

机制	判据	常量位置
EXPLORE plateau（唯一确定性相位推进）	最近 5 个 winner 增益和 < 0.5% 且尾部空 specialist 轮 ≥ 5	`machine_state.py:363`
EXPLORE 硬退出（覆盖 plateau）	会话剩余 ≤ 3h 或相位剩余比 ≤ 20%	`:372`
全局收敛	连续 3 个 cycle 无增益 → 终止	`:420`
方向饱和	`within_roofline_pct ≥ 95%`	`roofline_snapshot.py:28`

注意 EXPLORE plateau 是个严格的 AND：只要 LLM 还在产出非空 specialist 轮，无论增益多平，plateau 都不触发。真正结束一次平坦运行的是硬时间闸门，不是 plateau。

方向饱和只在一个地方真正门控行为：should_reloop_to_explore 要求 saturated_directions 的每一项都饱和才阻止 reloop。但这个 dict 只会为「曾经成为主导方向」的项累积 key，典型情况下只有一个 key——所以单次 95% 快照就能阻止 reloop。其他地方饱和都只是 prompt 文本。没有任何地方因为方向饱和而剪掉一个变体或一族 flag。

roofline 饱和判据背后的模型见 Compute-bound vs Memory-bound。另有一处小 hack：dominant_direction 在 roofline_bound_kind == "memory" 时注入一个 max(compute_pct, 0) + 0.01 的合成候选（roofline_snapshot.py:692），所以只要 roofline 判 memory-bound，memory 就必然胜出，无视实测的 comm/idle 百分比——一个 comm 主导但 memory-bound 的负载会被路由到 serving_specialist 而不是 comm_specialist。

6. 测量方法学

这是最要命的部分。前面的工程质量很高，这里是空的。

优化目标：单目标吞吐

优化的标量是 throughput.output_throughput（输出 tok/s），benchmark_result.py:745 抽取，gain_pct = (new-base)/base*100 是唯一被拿去和阈值比的量。

request_throughput、ttft_mean_ms、ttft_p99_ms、tpot_mean_ms、e2el_mean_ms、e2el_p99_ms 全都解析了、存了、进报告了，但没有任何决策读它们。全仓没有 goodput、没有 SLO、没有 MFU。

用户能控制的只有停止条件（TARGET_GAIN_PCT / TARGET_TPUT_PER_GPU / TARGET_DIR），不是排序指标。你没法让 Hyperloom 在吞吐下界约束下优化 P99 TTFT。

单次测量，无重复，无显著性检验

每个变体的决策只依赖一个 benchmark 窗口。

通道	每变体轮数	谁定生死	统计量
`explore`（配置调优）	warmup（丢弃）→ 决策 → 复测	决策轮定 KEEP，复测轮替换掉头条数字	无
`integrate_patch`（补丁）	bench → 复测	bench 定 KEEP	无
baseline	warmup（丢弃）→ 测量	测量轮	无

变体确实测了两次，但两次从不合并：第一次管准入，第二次覆盖第一次成为头条。没有均值、没有中位数、没有离散度。run_grid 里不存在任何重复循环。

冷热分离做得是对的。冷轮在三个层次被真正丢弃：baseline 双跑（baseline.py:2117，日志还会打印「冷产物本来会是 +X%」）、explore warm-decision（explore.py:1081）、run_grid 自己的 warmup。但这治的是偏差，不是方差。

全仓唯一的正确做法，没有调用方

agents/kernel/tools/apply_and_bench.py 是个独立 CLI，方法学完全正确：

reps: int = 5（:743），每臂 5 次计时重复，外加一次不计时的 warmup
--seed 固定，注释写明理由：“Fixed --seed so both arms benchmark the identical random prompt set”（:362）
_spread() 算 median / p25 / p75 / stdev（:552）
真的显著性检验——IQR 不重叠（:876）：

significant = (ps_sp["p25"] > bs_sp["p75"]) or (ps_sp["p75"] < bs_sp["p25"])
# None=insufficient reps; False=within noise (flat); True=clears IQR

全仓 grep significant，5 处命中全在这个文件自己内部（初始化、注释、计算、输出 dict、日志行）。零外部消费方。工具自己也写明了："gate": "none (... KEEP/REVERT/NEEDS_REVIEW bypassed; policy is the caller's job)"。调用方 integrate_patch / kernel_stack 走自己的单次路径，从不读 apply_and_bench_result.json。

有人建对了测量装置，然后把决策接到了另一条更差的路上。

另外，orchestrator 路径从不固定 benchmark 种子。_workload_envs.py 传了 CONC/ISL/OSL/MAX_MODEL_LEN/TP/RANDOM_RANGE_RATIO，没有 seed。有 RANDOM_RANGE_RATIO 在，同一配置连续两次运行的 prompt 长度分布是重采样的——差的不只是系统噪声，是负载本身。

噪声地板：断言过，从未测量

常量	值	代码里的依据
`explore.DEFAULT_KEEP_THRESHOLD_PCT`	1.0	注释：「grid noise floor」
`MULTI_NODE_KEEP_THRESHOLD_FACTOR`	2.0	注释：「Multi-node baseline noise floor is ~2x single-node」
`DEFAULT_STACK_STABLE_PCT`	0.5	9 行注释，讲的是内部一致性（复测地板 < KEEP 地板）
`_grid_runner.SINGLE/MULTI_NODE_DEFAULT_KEEP_THRESHOLD_PCT`	1.0 / 2.0	死常量，在 `__all__` 里导出，无任何引用

**仓库里没有任何地方测量过 run-to-run 方差并拿它和 1.0% / 2.0% / 0.5% 比较。**多节点「约 2 倍」这个说法没有数据、没有工单、没有测量脚本。

叠上 §5 的衰减曲线，结论是：如果 1.0% 在第 1 个 cycle 是噪声地板，那么噪声地板并没有变，只是接受线走到了它下面。按代码自己的前提，中期之后的每一次 KEEP 都和噪声不可区分。

系统自己知道这件事

agents/robustness/signals/decision_audit.py:182 有个守卫，对任何 gain_pct < 1.0 的 KEEP 报 MEDIUM 级症状，措辞是 “likely noise-floor”，建议是：

“raise the executor’s keep threshold to >= 1% and require multi-seed confidence for sub-threshold KEEPs”

一个内部审计器建议做多种子置信度；决策路径没有种子也没有重复；而衰减曲线保证这个审计器在第 1 个 cycle 之后几乎每次 KEEP 都会触发。同一文件里的兄弟守卫更锐利：_g1 抓「零字节补丁的 KEEP」（没改代码，任何增益都是噪声），_g3 抓 dispatched_count == 0 或 |gain| < 0.5% 的 KEEP（补丁可能根本没执行）。这些直觉都对——只是它们诊断的是一个分不清 0.2% 和 0 的测量过程。

基准锚点是单向棘轮

resolve_grading_anchor_tput（state/shared_state.py:92）返回 current_best.tput，回退到 baseline_tput。docstring 的理由是对的：候选是带着 current_best 的参数启动的，拿原始 baseline 打分等于「把一个测量值和它从未在上面取过的配置比较」。

但 current_best.tput 就是上一个被接受变体的复测值——本身也是单次测量。所以锚点是一列单次测量上的随机游走，而且只会往上走（变体只有打赢锚点才被接受）。被接受变体上的测量噪声永久烧进后续所有增益的分母。漂移纠正也是单向的（explore.py:602）：

if not revalidating_stack and live_anchor > base_tput:
    base_tput = live_anchor     # 只在 live > snapshot 时纠正

会话中不做周期性 baseline 重测。只有 resume 时会比一次，measured < recorded × 95% 才报 current_best_drift 观测，且只记日志不改值。

变体之间的状态隔离

跨变体是干净的，做得很到位：teardown_lifecycle_server 在每条退出路径的 finally 里跑；_kill_stale_servers 扫 /proc 找 VLLM::Worker / sglang.srt 等残留、killpg(SIGKILL)、清 /dev/shm/{vllm,nccl,cuda,torch,atom}*、然后 sleep 2–8s 等 KFD 异步释放显存；每会话换一个临时端口。所以进程内状态（prefix/radix cache、CUDA graph 捕获、KV pool、分配器 arena）不可能跨变体。

变体内部的状态延续是故意的，这里有个未被处理的偏差。warmup → 决策 → 复测三轮共用一个持久 server。决策轮跑在一个已经服务过完整 warmup 负载的 server 上，复测轮跑在被 warmup 和决策轮都预热过的 server 上。没有任何显式 cache flush（grep flush_cache 只命中被调优的 flag 本身）。由于复测值替换头条并成为下一个锚点，这是系统性向上偏差，不是相互抵消。KV/prefix cache 的复用语义见 KV Cache。

跨变体唯一存活的是磁盘编译缓存：aiter JIT 的 jit/*.so 是节点共享持久的，_probe_aiter_jit_cache 数 .so 个数来选冷/热超时。这个不清是对的（清一次要多花 30 分钟），但意味着新会话的第一个变体付了后续变体不付的编译成本。

精度门禁

评测：lm-eval GSM8K，指标 exact_match,strict-match，默认全量 1319 题
ACCURACY_THRESHOLD = 0.05 是绝对 exact-match 单位的 5 个百分点，不是 5% 相对。baseline 0.80 → 候选须 ≥ 0.75
无 baseline 精度就整个跳过：if baseline_accuracy <= 0: return True

这是全仓唯一一处做了显式噪声-阈值论证的地方，而且论证成立（docs/reference/environment-variables.md:126）：GSM8K 在 p≈0.85、n=1319 时标准误约 1.0pp，5pp 约等于 5σ，单次运行噪声碰不到。代价是这道门非常钝——一个真实的 4 个百分点回退（4σ，毫无疑义是真的）会静默通过，吞吐收益照记。

serving 框架的门禁只在命中硬编码风险名单时才跑（_accuracy_gate.py:336）：5 个 CLI 子串（--kv-cache-dtype、--enforce-eager、--compilation-config、--attention-backend、--decode-attention-backend）+ 10 个环境变量键。名单外的任何 flag 都不做精度校验。--quantization 不在名单上——一个量化变体可以只靠吞吐被 KEEP。在一个「整个目的就是让 LLM 提出没人枚举过的 flag」的系统里，用枚举式风险名单是结构性错配。量化对质量的影响边界见量化方法与评测。

对比之下，scriptable 框架（xDiT）的门禁是每个变体都跑且 fail-closed：图像质量门禁缺失/跳过/歧义都判 accuracy=0.0 → REVERT。serving 路径反而更宽松。

还有个兜底常量值得一提：DEFAULT_ENABLEMENT_ACCURACY_FLOOR = 0.05，注释是全文件最好的一条——“At 0.0 the gate degenerates to accuracy > 0, which admits a model that is answering essentially nothing: a real run KEPT a candidate scoring gsm8k=0.00076 (0.08% of a 0.906 baseline) as ‘correct’.” 事故后修的，事故记录在案。

另一处仪表做得很好：generation-pathology 探针（_accuracy_gate.py:71）区分「模型没吐 EOS、评测被 token 上限截断、得分接近 0」和「模型答了但答错」，触发条件是 ≥128 个采样响应中 ≥75% 撞到 completion 上限。这正是朴素精度门禁会误读的失效模式。

失败分类学

这是系统最强的部分。有效性判据（benchmark_result.py:881）：output_throughput > 0 且 serving 的 completed_requests > 0。

12 种 error_class：capability_unsupported、yaml_build_error、magpie_timeout、server_init_dead、detokenizer_stall、killed_overtime、agentx_preflight、no_benchmark_workspace、benchmark_report_missing、benchmark_report_invalid_metric、cuda_graph_capture_failed、session_time_exhausted。

「真的更慢」被干净地区分出来了：慢但有效的配置是 status="succeeded" + 真实吞吐 + reason="gain_below_threshold"；上面每一类失败都是 status="failed" + tput=None + gain_pct=None。崩溃永远不会伪装成回退，反之亦然。

几个值得单独点出的细节：

killed_overtime 从不产出决策数字。会从 server.log 的 decode-rate 标记估一个吞吐（丢掉前 25% 样本当 warmup），但落在 estimated_output_throughput，tput 显式为 None，注释写明 “never enters winner selection or gain math”
超时截止时间锚在对的钟上：warm-decision 模式下软截止是 baseline_warm_runtime_sec × kill_ratio（纯客户端时间），从 server-ready 标记开始算；warmup 轮的 soft_deadline_sec=None，一次性冷启动不会误触发
泄漏产物打捞按 mtime 闸门：harvest_leaked_artifacts 能回收写到 workspace 外的结果，但拒绝任何早于 subprocess_started_unix - 1.0s 的文件——上一次运行的结果不可能被当成本次的
陈旧评测防护：run_eval_disabled 从子进程实际消费的物化 YAML 里回读，不从 params 读，因为评测失败重试会复用 output_dir，否则会把上次的 results*.json 当本次的
有效数字已落盘后的非零退出降级为 warning，测量保留
每次中止都写 abort_reason.json，事后能区分「测过但失败」和「没测」

缺口：有效但退化的输出不是一个失败类别。一个又快又输出垃圾的配置满足 output_throughput > 0 and completed_requests > 0，就是一个有效测量和候选赢家。唯一防线是精度门禁，而 serving 的精度门禁只跑硬编码名单。

并发扫描：验证工件，不是优化器

kernel/conc_sweep.py 看着像个经典参数扫描，实际不是：

固定 8 点阶梯 DEFAULT_CONCS = [256, 128, 64, 32, 16, 8, 4, 2]，字面量不是算出来的
两臂对照：baseline（空配置）vs optimized（current_best）
算的是 argmax 加速比，不是吞吐拐点、也不是延迟预算下的最优点：best_conc = argmax(optimized_tput / baseline_tput)
ttft_mean_ms / e2el_mean_ms 每行都收集了，但没有任何代码读它们做决策。整个模块没有 SLO 常量
best_conc 从不写回配置，只进报告

工程实现本身很扎实：boot-retry-descend（在最高 CONC 起不来就降一档重试，失败的高 CONC 记为真实容量失败而不是丢弃）、每点后原子增量落盘 JSON+CSV（硬杀不丢曲线）、每点前查预算。

附带的 decode roofline ceiling（每个并发点的 T_mem / T_cmp / MBU%）是整个 sweep 里最有原则的部分——它告诉你每个并发点离物理上限多远——也是只进报告。

另有一个可 LLM 提议的完整 workload sweep（actions/executors/sweep.py），[4,16,64] × ["1024:1024","8192:1024","1024:8192"] 九点全交叉，是全仓唯一算 Pareto 前沿（max 吞吐 / min e2el_mean_ms）的地方。同样只进报告。批处理与并发的调度语义见批处理与调度。

7. 跨运行沉淀：什么真的传下去了

五条声称跨会话传递知识的通道，端到端能走通的只有两条。

通道	跨运行	约束力	状态
`best_config` → warm-replay	是	强约束（自动应用配置）	能用，最强的真实机制
`kb/framework_optimization/lessons.jsonl`	是	咨询性 PR 排序 + 一处强约束精度阻断	能用
`lessons` / `pitfalls`	持久化正确	咨询性（prompt 文本）	只以裸 JSON blob 到达模型，结构化的 5b/5c 段渲染成 `(none)`
`what_failed` → `explore_search.rejected`	—	强约束（永久阻塞）	死的，字段在写入时被投影掉
`prs_tested` → 补丁重放/阻断	—	强约束（补丁过滤）	死的，同一原因

存储键太窄

canonical id 是 7 段（recipe_snapshot_constants.py:121）：

inference:{model}:{hardware}:{framework_name}:{model_type}:{architectures}:{framework_version}:{precision}

framework_version 是硬键段。0.4.6 → 0.4.6.post1 就是另一个目录、另一个 recipe.json。级联降级（L1 exact 1.0 → L2 same_arch 0.95 → L3 same_arch_any_version 0.5 → L4 relative 0.3）救不回来：L2 仍然锁 framework_version，所以版本 bump 直接掉到 L3/L4，而 warm-replay 的门槛是 _DEFAULT_WARM_REPLAY_MIN_CONFIDENCE = 0.7（coordinator.py:48）。**一个 .post1 补丁版就静默清零了唯一能用的知识通道。**没有语义化版本距离，没有「同 minor」层级。

硬件方向零迁移：hardware 是硬键段，MI300X 和 MI355X 是两个目录，级联的任何一层都不放宽它。这个选择可辩护（为一张卡调的配置在另一张上确实不安全），但意味着跨硬件世代一点知识都不传，连「我们对邻居卡知道点什么」都不提示。

反过来，键在一个要紧的维度上又太宽：workload 形状（conc/isl/osl/tp）不在键里，只在 extras 里做重排提示。所以在 conc=32, isl=1024 调出来的配置，会以 tier exact、置信度 1.0 返回给 conc=512, isl=8192 的运行，并被自动应用。形状冲突门禁 _shape_conflict 存在，但 recipe_kb_t0.py:1211 在 warm_tier == "exact" 时显式绕过它。

写入路径丢数据

_record_fact_impl（loop/writeback.py:898）是严格两分支：

if is_keep and gain_pct is not None and gain_pct > 0:
    → 追加一条 lesson
    return                                    # 提前返回
severity = self._pitfall_severity_for(...)    # crash/oom/hang，或 gain_pct <= -5.0
if severity is not None:
    → 追加一条 pitfall
# 否则：什么都不写

中性结果一条都不记。测出 gain_pct = 0.0 或 +0.3% 或 −2% 的变体——也就是一次调参扫描里的绝大多数——两个分支都不命中，KB 里什么都没有。系统学不到「这个 knob 在这里没用」，每次新会话都要重测一遍。

更严重的是字段投影，这条我逐行核实过。local_store.py:449：

"what_worked": _normalise_str_dicts(what_worked, ("description", "measured_impact")),
"what_failed": _normalise_str_dicts(what_failed, ("description", "reason")),

而 _normalise_str_dicts 就是 {k: str(d.get(k) or "") for k in keys}——其他键全部丢弃。写入方（writeback.py:1521）发的是 {"name": ..., "reason": ...}，连标签都因为键名不匹配（name vs description）丢了。

读取方（phases/prelude.py:102）要的是：

args = str(row.get("extra_server_args") or "").strip()
envs = row.get("extra_envs") or {}
if not args and not envs:
    continue            # 恒真
fp = canonical_fingerprint(args, envs)

写入方没发这两个字段，投影层也不会保留它们，所以这个 continue 恒真，注入 0 行。而 explore_search 是 per-session 状态——这条曾是拒绝记录跨会话传递的唯一路径。

如果它能工作，会是真正的强约束且永久：注入行不带 outcome 键，_is_blocked 无条件返回 True，基于增益的解锁不适用。

prs_tested 同一失效模式：_normalise_prs 只留 {repo, number, outcome, notes}，而下游 _extract_patches_from_prs_tested 需要 patch_content、measured_gain_pct、applicable_arch——全没了。所以 recommended_replay.patches 和 blocked_patches 从本地行永远是空的。

没有去重，`validated_count` 从不写入

proposals.py:211 是裸 append，docstring 自己写了 “lesson/pitfall appended without dedup”。

意图是有的。_build_statement（writeback.py:1076）刻意构造了身份稳定的 key，并写明理由：“MUST exclude volatile fields (e.g. gain_pct) so N sessions merge instead of producing N rows”。gain_pct 作为参数接收然后故意忽略，就是为了让重复观测碰撞。但没有任何地方去哈希它或比较它。

validated_count 全仓 3 处读取（都在 prompt renderer 里），零处写入。同一个 lesson 语句跑 3 个会话就是 3 行，无上限、无去重、无 LRU，而这个数组会被整个拷进 prompt。

对照：同一份代码在别处是会去重的——sessions[] 按 session_id、kernel_optimizations 按 kernel_id、explore_search.rejected 按 fingerprint、emit_fact 按三元组。recipe 行的 lessons/pitfalls 只是被漏掉了。

知识图谱：读客户端，没有数据源

kg_client.py（1352 行）不是图数据库。默认模式下「图查询」是 gbrain 全文搜索，然后正则解析 Markdown 的 ## Facts 围栏。原生模式（GBRAIN_KG_NATIVE=1）把三元组映射到 gbrain 的链接图上，属性通过自由文本 context 字段塞 JSON。

10 种谓词有消费方（REVERTED_ON、IMPROVES、CONFLICTS_WITH、KNOB_IMPROVES…），但 emit_fact 全仓只有一个生产调用方：phases/framework.py:3156 的 _emit_kg_decision，只为框架补丁决策写 IMPROVES / REVERTED_ON，且需要 GBRAIN_KG_NATIVE + 可达的原生客户端。

所以 KNOB_IMPROVES / KNOB_REVERTED_ON 没有写入方——graph_guided_knobs 和 kg_cross_model donor 读的是没人生产的边。docstring 点名生产者是 “kb-mirror drivers”，那个组件不在 OSS 发布里。而在树内的镜像也救不了：gbrain_ingest.recipe_to_page 产出的页面体根本没有 ## Facts 段。

远端存储（gbrain_remote_client.py）严格只读，且默认不可达（需要 GBRAIN_BASE_URL + GBRAIN_TOKEN，.env.template 里两个都是注释掉的占位符）。OSS 版本里跨运行学习是单机的，没有共享知识底座。

一处设计正确但从未渲染的功能

specialist_prompt_builder.py:1441 的 _format_version_note：

return f" [from {framework_label}@{lesson_fv}, you're on {current_fv}]"

在每条 lesson / pitfall 上内联标注 [from sglang@0.4.6, you're on 0.5.1]，docstring 说 “the LLM gets the final call”。这个直觉完全对：标注来源差距、让模型自己判断，比硬丢弃或盲目信任都好。

但它读的 framework_version 字段写入方从不发，而且它的两个调用方（_section_lessons / _section_pitfalls）都读一个 legacy 的 attrs 包装形状，当前写入路径不产生 attrs，于是两段都提前 return、渲染成 (none)。这个功能从未渲染过。

顺带一提，prelude.py 那边是兼容两种形状的（recipe_attrs = (recipe.get("attrs") or recipe)），说明这是一次漏掉了 prompt 层的迁移。

8. 工程借鉴清单

值得抄

禁止 agent 自报数字，机器强制。FORBIDDEN_PROPOSAL_FIELDS + 4 条正则扫自由文本，prompt 里明确「the Coordinator measures gain」。这条和「缺失/不可比的数据保持为空、前端不做估算」是同一个原则，但他们做成了机器强制的。
内容寻址的指纹去重。排序 token + 排序 env pair 的 SHA-1，排除 name / note 所以改名不影响去重。这个形状是对的——但要把 workload 形状加进哈希。
冷热轮分离。baseline 双跑、explore warm-decision、run_grid warmup 三层都真正丢弃冷轮。治偏差有效。
失败分类学。12 种 error_class，「崩溃」和「更慢」严格不混淆；超时不产出决策数字；打捞按 mtime 闸门防跨运行污染；陈旧评测从实际物化的 YAML 回读。这些细节明显是被真实事故打磨出来的（gsm8k=0.00076 那条注释、orphaned FileBaton 清理、端口复用修复）。
KEEP 后二次复测。作为复现性检查是真实有效的——靠运气赢的变体得再赢一次，能滤掉相当一部分纯噪声赢家。
本地写 / 远端读，且无条件本地兜底。正确性从不依赖网络，每一次远端失败都有本地答案。
原子写协议。archive-then-write 加 flock、tmp+rename+fsync、单调 version、provenance 里存 replaced_by。免费得到完整版本历史。
每次写入的 delta 记账。prior_counts vs counts 让「这次写入到底贡献了知识吗」变成可回答的问题——如果有人对它告警，§7 那两处字段丢失第一天就会暴露。
_donor_is_trustworthy。借用他人配置的门禁：有可重放配置且有正向已验证增益且架构具体匹配且 workload 形状不冲突。docstring 老实写了没有它会怎样：“Borrowing a champion config on a loose same-arch match empirically produced near-zero or negative replay gains.”
标注来源差距、让模型判断，而不是硬丢弃或盲信。

不要抄

不要硬投影到固定键组。{k: str(d.get(k) or "") for k in keys} 是两处数据丢失的同一个根因。要么保留未知键（Recipe.extras 已经这么做了），要么对意外键大声失败。静默清零一个下游必需的字段是最坏的失效模式：没有报错、没有日志、没有测试失败，一个「self-evolving」的系统安静地什么都没进化。
不要让读形状和写形状漂移而没有契约测试。这几处缺陷是同一类。每一处都有通过的单元测试——因为每侧的 fixture 都是按自己那侧期望的形状手写的。只有过真实 store 的往返测试能抓住这类问题。
版本当精确键段是知识悬崖。要么加一个带自己置信度的版本距离层级，要么每个 .post1 都丢一次语料。
不要丢弃中性结果。「knob X 在这里没用」测起来贵、存起来便宜，而且是任何扫描的大多数。只记赢和崩的 KB 会让搜索永远重新推导空结果。
接受阈值不能衰减到自己声称的噪声地板之下。KEEP_THRESHOLD_FLOOR_PCT 应该是 max(0.1, k·σ)，而 σ 得先测出来。
不要发一个读客户端却没有能写的语料。KG 的 1352 行在 OSS 版本里是没有数据源的架构。
不要建只写通道。kernel_optimizations 和整个 Attempt schema（predicted_delta / measured_metrics / fitness，一套完整的演化搜索记录）都没有写入方或读取方。
confidence 要么算出来要么删掉。永久钉在 0.85 的字段会诱导下游把它当证据强度用。

如果要让它变成真的优化器

最高杠杆的改动不是换个更好的提议者，而是三件事：把 workload 形状加进接受台账的键；在已接受集合上做交互搜索（synergy_attempted 目前是死字段）；把并发扫描的 Pareto 前沿和 MBU% 在一条明确的延迟 SLO 下接回 current_best。

统计学侧最小可行改动：会话开始时把同一配置连测 10 次（双跑守卫已经把 server 起好并持有，边际成本只是客户端轮），把 σ 写进 state.json，让所有阈值从 σ 推导，然后把 apply_and_bench.py 已经写好的 5 次重复 + 固定种子 + median + IQR 检验接到决策路径上。那个 significant 字段现在没人读——要么消费它，要么删掉它，因为发一个没人读的正确显著性检验比没有更糟，它从外面看起来像严谨。

怎么读 Hyperloom 报出的累计收益

一次长运行报出的累计收益，应该读作「一条单向棘轮在单次测量上累加、且接受线衰减到系统自称噪声地板之下」的上界，不是测量到的加速比。要问的数字不是那个 gain，而是拿最终 current_best 配置和原始 baseline 配置在同一台机器上各自重复测几次的干净对比。

9. 复核边界

本文基于 2026-08-04 的主干快照静态阅读，没有实际运行过 Hyperloom。「死代码」判定基于全仓 grep 加调用图追溯；衰减曲线、significant 孤儿、KB 字段投影三条逐行复核过。
项目是 v1.0.0a2（alpha），2026-03-27 建仓，README 挂着 beta 问卷。这里指出的缺陷有相当一部分是 alpha 阶段的正常状态，不代表最终形态。
§6 的方法学批评针对决策路径。apply_and_bench.py 证明团队里有人知道正确做法，问题是接线。
README 与实现不一致的地方（“tree-based cognition layer”、“self-evolving”、specialist.yaml 的 max_turns: 12 和 allowed_tools 列表）在正文对应位置已标注。