a2ui Atom 推理格式优化实验剖析：run_026 事件参数归一化（_compile_event）优化报告的完整解读

本篇以 a2ui 仓库中一次真实的推理格式（Inference Format）迭代优化记录为主线，解读 eval/iterative_format_optimizer/history/atom/run_026_ec77d38e_compile_event_normalization/report.md 这份优化报告：它如何提出假设、如何修改 AtomCompiler._compile_event、评估指标如何变化，以及为什么最终被判定为 Backtracked（回滚）。读完后，你将掌握 a2ui 推理格式优化循环的决策规则、S_opt 综合评分机制，以及如何从优化历史中复用已验证的编译器归一化技巧。

背景：一次迭代优化 Pass 的产物

该报告是 a2ui iterative_format_optimizer（推理格式迭代优化器）对 atom 实验格式执行第 26 轮（run_026）优化后自动归档的产物。这一优化循环由 inference-format-optimizer 技能 定义，其核心工作流是六步：分析历史假设 → 修改 compiler.py / prompt_generator.py / parser.py → 跑 pytest 一致性测试 → 跑基准评估 → 按决策规则保留或回滚 → 归档工件并同步历史索引。

每次运行归档为一个独立目录，run_026 目录下的三个文件各司其职：

• report.md：评估指标汇总表、pytest 输出、活跃 git diff、样例失败明细；
• patch.diff：本轮对代码库的完整变更；
• run_meta.json：假设（hypothesis）、状态（status）与指标元数据。

run_meta.json 给出的关键元数据是：

• 假设："Compiler-side dynamic event action parameter normalization for nested event maps and positional arguments."（在编译器侧对嵌套事件映射与位置参数做动态归一化）；
• 状态：Backtracked（已回滚）；
• 指标中位数：输入 token 4451.5、代码输出 token 307.5、推理 token 4636.5。

评估使用的模型为 google/gemini-3.5-flash，预算为 Unbounded，与 主优化历史表 中该行记录一致。

修改点：AtomCompiler._compile_event 的归一化补丁

atom 是 a2ui 的一个实验性推理格式（S-expression 风格），由 AtomCompiler 把 LLM 输出的紧凑表达式编译为 A2UI 组件树。其中 _compile_event 负责把形如 event 的表达式编译为 A2UI 的事件/动作对象。该函数在 当前版本的 compiler.py 中仍可见其演化后的形态（后续若干轮优化在此继续迭代，详见下文"后续回响"一节）。

run_026 的补丁针对 _compile_event 的三处短板：

1. 事件名残留引号：LLM 输出 (event "click") 时事件名是带引号的字符串，原实现直接 str(expr[1])，导致事件名带引号进入最终 JSON。
2. 嵌套事件映射无法展开：当 context 参数本身是一个嵌套的 :key value 列表（而非标量）时，原实现只按"关键字-值"两两消费，遇到子列表会错位。
3. 位置参数无名：事件后直接跟的裸值（无 :key 前缀）原来被静默丢弃，现在被映射为 value / arg_0 / arg_1 等命名参数。

补丁的核心 diff（摘自 patch.diff）：

def _compile_event(self, expr: List[Any]) -> Dict[str, Any]:
-   event_name = str(expr[1]) if len(expr) > 1 else ""
+   event_name = str(expr[1]).strip("'\"") if len(expr) > 1 else ""
    context = {}
    i = 2
+   pos_idx = 0
    while i < len(expr):
-       if str(expr[i]).startswith(":") and i + 1 < len(expr):
-           context[str(expr[i])[1:]] = expr[i + 1]
-           i += 2
+       item = expr[i]
+       if isinstance(item, str) and item.startswith(":") and len(item) > 1:
+           if i + 1 < len(expr):
+               context[item[1:]] = expr[i + 1]
+               i += 2
+           else:
+               i += 1
+       elif isinstance(item, list) and item and isinstance(item[0], str) and item[0].startswith(":") and len(item) > 1:
+           context[item[0][1:]] = item[1] if len(item) > 1 else True
+           i += 1
        else:
+           param_k = "value" if pos_idx == 0 else f"arg_{pos_idx}"
+           context[param_k] = item
+           pos_idx += 1
            i += 1

从源码结构看，这次改动的思路是"容错式归一化"：先做 isinstance 类型守卫（避免对非字符串元素调用 startswith 触发异常），再把"嵌套的 :key value 子列表"整体折叠为一个 context 键值对，最后把裸值按位置编号命名。这种编译器侧兜底能减少 LLM 必须"写对格式"的压力——这正是该轮假设中"降低推理 token"的来源。

评估结果：指标表与异常解读

报告中的 Summary Table（策略 atom，模型 google/gemini-3.5-flash）：

Metric	Baseline	Current	Diff
Pytest Conformance	PASS	FAIL	-
Overall Pass Rate	100.0%	100.0%	0.0%
Algorithmic Schema Pass Rate	100.0%	100.0%	0.0%
Inference Duration (sec)	8.79s	8.93s	+1.6%
Avg Input Tokens	0	0	-
Avg Output Tokens	0	0	-

需要注意两点，避免误读：

1. "Pytest FAIL" 是环境问题，不是代码回归。 报告附带的 pytest 日志显示 28 个测试模块在收集阶段全部报 ModuleNotFoundError（缺 a2ui、a2ui.core、yaml、a2a、google 等模块），根目录是一个隔离 worktree（.../worktrees/opt-atom-run26），日志末尾还有 "Creating virtual environment at: .venv / Installed 22 packages in 72ms" —— 即测试在虚拟环境刚创建、依赖尚未就绪的窗口内被执行了。而 run_meta.json 的 notes 字段明确记录 "Pytest 100% pass"，且历史表中该轮 Pytest 列亦为 PASS。可以推断，报告表格中的 FAIL 反映的是该 worktree 环境初始化的时序问题，而非 _compile_event 补丁本身破坏了单元测试。

2. Avg Input/Output Tokens 为 0 是占位值。 真实的 token 统计在 run_meta.json 的 metrics 中以中位数形式落盘（输入 4451.5、代码输出 307.5、推理 4636.5），评估样例层面的通过情况则见报告尾部 "Failure Details (Count: 0 / 6)"——6 个基准样例全部通过。

run_meta.json notes 给出的对比结论是：推理 token 下降 10.3%（4,636 vs 5,168），但代码输出 token 上升 16.5%（308 vs 264），非推理输出耗时上升 21.7%，综合分 S_opt 从 +0.600 跌至 +0.580（-0.020）。

决策：为什么 100% 准确率仍然被回滚

inference-format-optimizer 的决策规则 要求每个候选变更同时满足三道护栏：

1. 正确性护栏：必须通过 pytest 且保持基线准确率（本例 100%/100% 达标）；
2. 效率上限：代码输出 token 不得膨胀超过 +5%（本例 +16.5%，违规）;
3. 综合分：S_opt 必须提升，否则回滚（本例 -0.020，违规）。

因此 run_026 被判定 Backtracked，按规则 2 与规则 3 回滚。这里暴露了该优化循环最典型的张力：编译器侧多做的容错/兜底逻辑，会诱导 LLM 生成更"随意"但更长的输出——推理过程变短了（因为格式要求被放宽），但产出的代码 token 变长了，净效果是综合分下降。评分模型细节可参考 scoring_model.md。

后续回响：同一优化方向如何最终落地

run_026 的回滚并不是终点。从 主优化历史表 可以看到，_compile_event 的事件归一化方向在后续两轮以不同的实现被成功保留：

• run_031（Kept）："Compiler-side dynamic event handler context parameter normalization in _compile_event"——推理 token -9.7%（4,175 vs 4,621）、代码输出 token -14.9%（174 vs 204）、非推理输出时间 -21.9%，S_opt 升至 +0.627；
• run_041（Kept）："Dynamic event parameter normalization in AtomCompiler._compile_event"——推理 token -5.1%，代码输出 token 持平，S_opt 升至 +0.615。

对照 run_026 的做法可以推断，后续成功版本把 run_026 的"位置参数统一命名"改成了更保守的策略（例如首个裸值映射为 id、其余裸值直接跳过），从而在保留容错能力的同时不让输出 token 膨胀。当前 compiler.py 中 _compile_event 的实现 正是这些轮次叠加后的产物：它处理了带引号/反引号的事件名、:name/:action/:event 别名回退、:context 的 dict 与列表两种形态、嵌套 dict 项展平，以及裸字符串首个映射为 context["id"] 的规则。

如何复现与查证

• 查看单次运行：直接阅读 run_026 目录 下的三个归档文件；
• 纵览全部优化轨迹：history_summary.md 按格式（atom/express）列出每轮假设、准确率、延迟、token 与处置状态；
• 复跑评估与对比基线：按 SKILL.md 的 CLI 速查表执行，例如 python scripts/optimize_format.py --format atom（快速验证）、python scripts/compare_results.py --baseline eval/iterative_format_optimizer/baselines/atom/... <logs_dir>（对比基线）；
• 阅读被测代码：AtomCompiler。

小结

run_026 报告的价值不在于它"成功"，而在于它完整示范了 a2ui 推理格式优化循环的判定逻辑：一次在 6 个基准样例上 100% 通过、且推理 token 下降 10.3% 的编译器补丁，仍会因代码输出 token 膨胀 16.5%（超 +5% 效率上限）和 S_opt 下降 0.020 而被回滚。同时，pytest 表格中的 FAIL 与实际"Pytest 100% pass"的差异提醒读者：在隔离 worktree + 全新 venv 的自动化评估环境里，必须先区分环境时序错误与真实代码回归，再下结论。这正是该仓库优化历史能够沉淀 50+ 轮可追溯假设与决策记录的原因。