边生成边执行：在 LLM 代码生成中隐藏执行延迟 Executing as You Generate: Hiding Execution Latency in LLM Code Generation

EAGER 的运行分四个阶段：(1) **Producer（LLM 流式生成）**：通过 OpenRouter API 以 streaming 模式拉取 token，每个 token 到达后追加到代码缓冲区。生成速度记为 $v_{gen}$ tokens/s，首 token 延迟记为 $T_{FT}$。(2) **Chunker（AST 切分 + 预测性消歧）**：每收到新 token，chunker 尝试用 `ast.parse(buffer, mode='exec')` 把缓冲区解析成 AST。解析成功后判断顶层语句是否真正完整——大多数情况下语法完整即语义完整（例如 `print("hi")\n` 之后 newline 出现即说明该语句已结束），可直接切出 chunk；但函数定义等场景中，第一行函数体之后解析器已能给出合法 AST，下一行却可能继续填充该函数体，此时 chunker 启用「lookahead」策略：等下一个 token 到来后再决定当前语句是否真的闭合（如果下一个 token 开始新顶层语句或 dedent，则确认闭合）。(3) **Executor（持久 REPL + 动态批处理 + gating）**：chunk 进入 pending queue，executor 空闲时把当前所有 pending chunk 合并为一个 batch 提交给持久 Python REPL 子进程（Jupyter 内核或本地子进程），跨 chunk 保留 import、变量、函数定义。提交前过一遍静态 gating 检查：黑名单命中（os/subprocess/shutil/socket/multiprocessing、time/signal/threading、eval/exec/compile/__import__、纯定义类语句）则降级为串行执行；否则按并行路径提交。每个 chunk 的执行附加约 1 ms 的 per-call 开销 $T_{setup}$。(4) **Error 路径（早期中断，可选）**：chunk 抛 RuntimeError 时 executor 立刻调用 LLM 端点的 abort/stream-close 接口终止生成，把错误信息连同截至失败点的代码一并返回给调用方；调用方把错误附加到代码尾部触发修复循环。

本文在概念、理论、工程三层都有明确新颖性。**概念层面**，首次把「生成—执行」的串行假设显式化并提出并行范式，与已有「执行反馈改进代码」路线正交。**理论层面**，给出三阶段流水线的闭式延迟公式 $T_{parallel} = \max_{1 \le i \le N}\left[ T_{FT} + \frac{\sum_{j=1}^{i} l_j}{v_{gen}} + \delta_i + \sum_{j=i}^{N}(T_{setup} + T_{exe,j})\right]$，并由此推导出非劣性条件 $T_{setup}^{(full)} \geq \bar{\delta} + N \cdot T_{setup}$、速度提升上界 $S \lesssim 1 + (T_{setup}^{(full)} + T_{exe}^{(full)})/(T_{FT} + L/v_{gen})$，以及在均匀 chunk 假设下三种 regime（R1 生成主导、R2 执行主导、R3 平衡）的临界 chunk 数 $N^* = (L/v_{gen} - T_{exe}^{(full)})/T_{setup}$。**工程层面**，AST 切分 + lookahead 消歧是新颖的：之前没有工作研究过在 LLM token 流上做边界无歧义、可证明保真的语句切分；gating policy 用静态 denylist 覆盖副作用/时序/动态/低产出四类语句，弥补了并行执行可能改变语义的隐患；早期错误中断与修复的耦合则是从工程中「意外发现」被形式化为可选特性，并在 RQ3 中被验证。

**独立分析的弱点**：(1) **gating 过于保守**——当前 denylist 是固定 denylist 加上「外部副作用语句降级串行」的两条规则，覆盖范围粗；改进方向是引入更细粒度的 AST-level effect analysis，例如追踪 `os.remove(path)` 的 `path` 是否受后续代码影响，若无依赖则仍可安全并行；同时允许 deployer 通过配置注入自定义 allow/deny 项。(2) **早期中断的语义保留**——`sys.exit()` 这类用户主动抛出的退出不会被识别为错误 chunk，但同时它会终结 REPL 会话，后续 chunk 无法在同一会话执行；改进方向是在 chunk 执行前静态扫描 `exit/quit/sys.exit` 关键字，把这种「终结性」chunk 标记为串行 + 后续 chunk 串行。(3) **chunk 大小分布不均**——LLM 生成的代码天然按语义块分布（一行 import、一段循环、一个完整函数），当前 AST 切分并不感知 chunk 大小分布，可能出现 N 很大但 $T_{exe,i}$ 都很小的退化情况，触发 $N \cdot T_{setup}$ 主导 regime；改进方向是根据历史 chunk 长度自适应合并小 chunk，或引入 token-budget-based 的切分。(4) **真实 LLM TPS 不可控**——Table I 是用「mock token stream at fixed TPS」模拟的，但真实 LLM 速度随 prompt 长度、温度、batch 变化；改进方向是把 20/50/100/200 TPS 替换为对真实 7 个 LLM 多次运行测得的速度分布，并在 RQ1/RQ2 中报告「在 P50 速度下 E2EL 节省多少」而非单一 TPS 数字。(5) **错误 chunk 的检测时延**——在 EAGER 中一个 chunk 必须等执行完成才能报错，但 `numpy` 这类大 import + 第一次矩阵运算的 chunk 可能耗时数百毫秒；改进方向是引入「first-failure-fast」机制，对高风险 chunk（涉及未 import 的标识符或重 I/O）在执行前先做轻量 dry-run 检查。

**作者提出的**：(1) 扩展到编译型语言（增量编译 / JIT backend）以及 JS、R 等其他解释型语言；(2) 仓库级 agent 场景的扩展，本文 R2 regime 表明执行主导下节省有限但仍有理论空间。**基于结果可延伸的**：(1) **流式编程语言设计**——论文 §VIII 提到一个有意思的方向：让编程语言本身把「可流式执行」作为一等设计目标，例如显式的语句分隔符消除 chunk 边界歧义，或提供语言级 primitive 让运行时增量消费生成的代码。这对 AI 辅助编程生态有结构性影响。(2) **chunk-aware 的解码策略**——既然知道哪些语句是「低产出」的定义类，可以让 LLM 在生成这些 chunk 时降低采样温度以减小 $N$、摊薄 $N \cdot T_{setup}$；反过来对「高执行开销」chunk 加快生成让流水线更接近 R3 balanced regime。(3) **与其他执行反馈方法正交组合**——EAGER 只做调度不动语义，可以与 EG-CFG（执行反馈 steer 生成）、Self-Debugging（迭代修复）、Chain of Code（选择性 emulation）等代码质量方法叠加；下一步工作应系统化测量这种叠加的复合收益。(4) **跨会话的 chunk 缓存**——很多 LLM 调用生成的 import 块、辅助函数定义是重复的，可在 chunk 级别做 hash 缓存，跳过重复执行。(5) **在 agent loop 中的 per-turn 重叠**——多轮 agent 对话中每轮都要生成 + 执行，EAGER 的并行机制能否在多轮之间流水线化（例如第二轮的生成与第一轮的执行重叠）是值得探索的方向。

**开源情况**：作者把 artifacts 放在 https://doi.org/10.6084/m9.figshare.31869469，包含 EAGER 框架代码、实验配置、chunking 验证脚本与 4 个 benchmark 的处理脚本。**数据集**：4 个公开 benchmark 均可独立获取（DSBench arXiv:2409.07703、DABench ICML'24、PandasPlotBench arXiv:2412.02764、GitChameleon arXiv:2507.12367），作者使用了 gold solution 或 DeepSeek-V3.2 生成的 runnable solution 作为 mock token stream。**算力需求**：实验在 Intel Xeon Platinum 8352V 单机 + 2 CPU 容器化环境上完成，无 GPU 训练需求；LLM 全部通过 OpenRouter API 调用（streaming mode），需要相应 API 配额；7 个 LLM 涵盖开源（DeepSeek-V3.2、MiMo-V2-Flash、Qwen3-Coder、DeepSeek-Reasoner）与商用（GPT-4o-mini、GPT-5.1-Codex-Mini、Gemini-3.1-Flash-Lite）模型。**复现难度**：中等偏低——核心算法（AST 切分 + 批处理 + gating + 中断）的实现约几百行 Python，理论部分只需照公式实现；难点在 (a) 与各 LLM 端点的 streaming + abort 协议对接（不同供应商实现差异大），(b) Docker 容器化与 CPU pinning 的精确时序测量。建议复现顺序：先复现 §V-A 的 chunk 重组保真度（无需 LLM），再复现 RQ1 的 mock token stream 实验（无需真实 LLM），最后才进入 RQ2/RQ3 的真实 LLM 实验。整体而言，有系统编程背景的工程师约 1–2 周可完整复现核心结果。