A2UI Atom 推理格式优化实验记录单属性组件描述截断为何触发效率上限回滚【免费下载链接】a2ui项目地址: https://gitcode.com/GitHub_Trending/a2/a2ui本文以 A2UI 仓库中atom推理格式迭代优化流水线的第 015 轮运行报告为主体完整还原一次提示词prompt signature压缩实验它修改了哪个生成器函数、评估指标发生了什么变化、5 个 Pytest 失败为何被判定为环境问题以及最终因“推理 token 超限”而按效率上限规则回滚的完整决策链路。读完本文你可以掌握该仓库格式优化实验的归档结构report / patch / run_meta 三件套、决策门槛正确性护栏 效率上限以及AtomPromptGenerator生成组件签名的源码实现细节。一、实验背景atom 格式与提示词签名压缩A2UI 的 Python Agent SDK 在 a2ui/inference_formats/experimental/atom 下维护了一种实验性的atom推理格式模型以紧凑的 S 表达式输出 UI而非直接输出完整 JSON 消息。为了让模型“看得懂”目录catalog里有哪些组件和函数AtomPromptGenerator会在系统提示词中动态生成Component Catalog Signatures组件目录签名其中每个属性的description与枚举取值enum都会参与拼接。本次运行run_015的核心假设记录于 run_meta.json是Truncate property descriptions ONLY for redundant single-property primitive components in prompt signatures, while keeping descriptions for complex multi-enum components.仅对提示词签名中“只有单个冗余属性的原语组件”截断属性描述同时保留复杂多枚举组件的描述。对应的评估模型为google/gemini-3.5-flash。二、代码改动解析_generate_component_signatures的条件收紧本轮改动全部集中在 prompt_generator.py 的AtomPromptGenerator._generate_component_signatures方法中完整 diff 见 patch.diff。改动共两处新增“单属性”判定在遍历属性之前先排除协议保留字段id与component统计剩余属性个数non_id_props [p for p in props if p not in (id, component)] is_single_prop len(non_id_props) 1收紧属性描述行的输出条件原逻辑是“只要属性有描述或枚举就输出描述行”新逻辑额外排除了“单属性组件且该属性无枚举”的情形# 旧 if p_desc or enum_vals: ... if p_desc: p_line_parts.append(p_desc) # 新 if (p_desc and not (is_single_prop and not enum_vals)) or enum_vals: ... if p_desc and not (is_single_prop and not enum_vals): p_line_parts.append(p_desc)结合仓库中 该方法的当前实现 可以看出整条签名生成链路CatalogSchemaHelper提供每个组件的属性列表、必填项required与属性 schema生成器按序拼出:prop参数标签可选参数带?后缀再对“有描述或有枚举”的属性输出形如- :prop: 描述 Must be one of: a, b的详情行最后汇总为- (ComponentName :arg1 :arg2?)的 S 表达式签名。因此本轮实验的本质是让单属性组件例如只有一个text属性的文本类组件不再输出描述行从而压缩系统提示词的输入 token而枚举约束Must be one of: ...始终保留。值得注意的对照是patch 中还保留了上一轮基线run_004 之后累积对ATOM_RULES语法规则文案的精简改动如哨兵标签说明合并、data块与模板语法示例的改写run_015 在此基础上只叠加了上述“描述截断”这一变量。三、结果总览通过率持平推理耗时翻倍report.md 的 Summary Table 给出了基线与本轮的对比指标基线Baseline本轮Current差异Pytest ConformancePASSFAIL-Overall Pass Rate100.0%100.0%0.0%Algorithmic Schema Pass Rate100.0%100.0%0.0%Inference Duration (sec)8.78s18.43s110.0%Avg Input Tokens00-Avg Output Tokens00-同时报告末尾的## Failure Details (Count: 0 / 6)标注为_All tests passed successfully!_即 6 个评测样本sample全部通过。也就是说在正确性维度上截断描述没有损害任何 schema 校验结果代价集中体现在耗时与 token 维度推理耗时 8.78s → 18.43s110%。四、5 个 Pytest 失败逐一拆解环境依赖缺失而非代码回归报告内嵌了完整的 pytest 输出collected 507 items最终5 failed, 502 passed, 409 warnings in 9.81s。5 个失败用例全部位于 test_atom_format.py且失败原因完全一致 from a2ui_eval.shared.utils import GIT_ROOT E ModuleNotFoundError: No module named a2ui_eval失败清单如下TestAtomFormat.test_atom_prompt_generator第 218 行TestAtomFormat.test_compile_child_list_template_property_assignment第 499 行TestAtomFormat.test_compiler_positional_properties_with_real_catalog第 244 行TestAtomFormat.test_compiler_schema_expects_single_child_and_helpers第 358 行TestAtomFormat.test_function_signatures_and_enum_helpers第 325 行从源码结构看这 5 个用例的共同点是在函数内部惰性导入a2ui_eval.shared.utils.GIT_ROOT——该模块对应仓库根目录下的 eval/a2ui_eval 包用于定位仓库根部的真实 catalog JSON。测试会话的rootdir指向一个独立 worktree.../worktrees/opt-atom-run15在该环境里a2ui_eval包未安装/未进入 PYTHONPATH于是抛出ModuleNotFoundError。因此这 5 个失败属于运行环境依赖缺失与本次对prompt_generator.py的逻辑改动无直接因果关系run_meta.json 中的结论也记录为 “Pytest 100% pass”。这也解释了为何 Summary 表中 “Pytest Conformance: FAIL” 与最终判定 “Backtracked 的原因是效率上限” 并不矛盾——报告的 FAIL 是环境性失败决策依据来自完整测试与基准指标。报告同时保留了大段 warnings summary409 条其中与本文主题最相关的是实验性格式的标注UserWarning: [EXPERIMENTAL] AtomFormat: This feature is experimental and may change or be removed in future versions without notice.这提示atom属于实验性 API接口可能在后续版本中变更。五、决策依据为什么输出 token 降了 11.4% 仍然回滚优化流水线的判定规则定义在 scoring_model.md 中分两层正确性护栏不可妥协Pytest 必须 PASSSchema Pass Rate 与 Quality Score 均不得低于基线。run_015 两条均为 100%护栏全部通过。效率上限触发即回滚Code Output Tokens 增幅 5%Non-reasoning Output Time 增幅 10%Reasoning Tokens 增幅 15%。run_015 的实测指标来自 run_meta.json 的metrics字段为指标基线本轮判定Code Output Tokens中位数289256-11.4%达标Reasoning Tokens中位数5,0615,913.516.8%超过 15% 上限Input Tokens中位数4,4524,451.5持平Non-reasoning Time-42.8%超上限run_meta.json 的notes给出了最终结论Pytest 100% pass. Schema Acc 100%, Quality Score 100%. Code output tokens reduced from 289 to 256 (-11.4%). However, reasoning tokens increased from 5,061 to 5,914 (16.8%, exceeding 15% cap) and non-reasoning time increased (42.8%). Reverted per Rule 2 efficiency cap.status字段为Backtracked即按 Rule 2 效率上限回滚。从评分模型的设计意图理解这一结果Reasoning Tokens 增长 15% 被视为“提示词指令搜索空间出现歧义”的信号——当单属性组件的描述被删掉后模型在推理阶段需要花更多 token 去确认“这个属性到底要填什么、有没有约束”于是压缩输入省下的成本被推理开销反超综合得分 S_opt 不升反降。六、横向印证描述截断在这条历史线上并非首次尝试history_summary.md 记录了 atom 格式全部 50 轮迭代的完整台账run_015 只是其中一次被回滚的实验。把同主题的运行放在一起看可以读出清晰的规律run_014Streamline catalog component signature property detail descriptions整体削减属性描述输入 token -46.3%、推理 token -32.4%但 Schema Acc 与 Quality Score 从 100% 跌到 75%按 Rule 1 回滚run_015本轮退一步只截断“单属性且无枚举”的描述正确性守住 100%但推理 token 16.8%按 Rule 2 回滚run_019Selective catalog signature compaction保留枚举、修剪单字符串属性描述输入 token -16.8%但推理 token 与耗时因“属性描述缺失导致 LLM 歧义”而上升回滚run_030Compact catalog schema parameter formatting for boolean/enum flags省略短枚举/布尔的描述行Schema Acc 与 Quality Score 双双跌至 83.3%回滚。对照之下最终被 “Kept” 的收益主要来自编译器侧的无损 AST 简化如 run_016 自动省略默认键包装、run_031 事件 handler 参数归一化、run_035 单子容器槽位解析等而非提示词描述的删减。这说明从本仓库的实验历史可以推断出对于atom这类依赖签名提示词的格式属性描述行承载的是消歧义信息其压缩收益输入 token难以覆盖推理歧义的成本reasoning token流水线用硬性的效率上限规则把这类“看似无损”的微优化挡在了基线之外。七、如何复现与查阅归档结构与命令每次优化运行的产物统一归档为三件套位于eval/iterative_format_optimizer/history/format/run_nnn_shortsha_slug/文件内容report.md指标对比表、完整 pytest 输出、Active Git Diff、评测样本失败明细patch.diff本轮对prompt_generator.py等文件的完整 git diffrun_meta.json假设、结论 notes、statusKeep/Backtracked与关键指标中位数配套的迭代工作流定义在 inference-format-optimizer/SKILL.md 中核心命令包括# 快速验证评估 python scripts/optimize_format.py --format atom # 完整评估套件 python scripts/optimize_format.py --format atom --full # 直接编译一条 S 表达式验证解析 python scripts/optimize_format.py --format atom --compile (Card (Text \Hi\)) # 归档本轮产物并登记历史 python scripts/optimize_format.py --format atom --archive --hypothesis ... --status KEEP # 汇总多 worktree 的历史索引 python scripts/sync_history.py其六步工作流为分析历史 → 在agent_sdks/python/a2ui_agent/src/a2ui/inference_formats/experimental/format/下修改compiler.py/prompt_generator.py/parser.py→ 跑 Pytest 一致性测试 → 跑基准评估 → 按决策规则保留或git reset --hard HEAD回滚 → 归档并同步历史索引。run_015 正是这条流水线上一次标准回滚案例正确性护栏全绿、单侧效率指标改善输出 token -11.4%但 reasoning token 增幅越过 15% 的硬上限最终状态记为 Backtracked其 diff 未进入基线——你可以在 prompt_generator.py 的当前实现中确认条件仍是原始的if p_desc or enum_vals:没有任何is_single_prop判定。小结run_015 这份报告的价值不在于一次成功的优化而在于它完整示范了 A2UI 格式优化流水线的判定纪律假设要可归因只改一个变量单属性描述截断便于把指标变化归因到该改动报告要留全证据链指标表、原始 pytest 日志、git diff、样本级失败明细齐全环境性失败a2ui_eval缺模块与真实回归可以被区分决策要过双层门槛正确性护栏Pytest/Schema/Quality 不低于基线 效率上限输出 token ≤ 5%、流式延迟 ≤ 10%、推理 token ≤ 15%任何一条触顶即回滚历史要可检索所有轮次集中在 history_summary 台账中避免重复验证已被否决的方向。对维护该仓库推理格式的开发者的直接启示是在压缩AtomPromptGenerator生成的签名提示词时属性描述与枚举约束属于消歧义信息激进删减会推高推理 token更稳妥的优化方向是编译器侧的无损 AST 归一化该历史线中被 Keep 的收益几乎都来自这一侧。【免费下载链接】a2ui项目地址: https://gitcode.com/GitHub_Trending/a2/a2ui创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考