长程任务给 Coding Agent 堆积了冗长的交互轨迹，但操作流水账不等于执行状态：早期读取的代码在多轮修改后早已失效，系统却无法阻止模型拿着过时信息决策或在代码未变时重复跑测。
流水账记录发生过什么，执行状态则明确当前哪些事实依然成立。论文《Turning Interaction History into Execution State: A Runtime Layer for Long-Horizon Coding Agents》指出了这一长任务瓶颈：长程 Coding Agent 欠缺的不是更长的历史记录，而是一套能够显式表达并维护当前执行状态的运行时机制。
长程 Agent 需要从交互历史转向执行状态
主流 Agent 普遍依赖一条线性追加的交互轨迹驱动决策。但这本质上是一份按时间累积的操作记录，而非动态更新的执行状态。
在长程任务中，这种脱节会导致执行过程中的状态偏差。首先是**时效性判断困难。**早期读取的配置文件在经历多轮跨文件修改后可能已经失效。由于历史记录中缺乏明确的状态标记，模型必须在每次行动前，从冗长轨迹中重新推断代码现状，容易基于过期信息采取不合适的后续操作。
其次是**动作冗余与空转。**在没有代码改动的情况下，模型无法确定先前的测试或搜索结果是否依然有效，可能重复下发相同指令，产生无效执行。
上下文管理无法完全解决长任务执行问题
当前应对长任务的主流方案是上下文管理 ，如历史截断、KV 压缩或多轮摘要，其核心在于降低单步推理的 Token 负载。
但对持续向环境产生副作用的执行型 Agent 而言，更致命的瓶颈是历史信息是否依然映射当前真实环境。一段摘要能概括"曾读取过 auth 模块"，却无法直接裁定该模块在后续变更后是否已失效，更无法阻止模型发起多余的重复读取与无效测试。
上下文管理减少的是历史呈现的体积，而执行状态管理维护的是实时环境的边界与动作的有效性，二者解决的是不同维度的工程问题。
Ledger 为 Coding Agent 引入运行时状态管理
针对这一痛点，论文提出了 Ledger ------一个运行在 Agent 外部的确定性运行时层 。它不修改基础 Agent 的核心推理流，也不引入额外的 LLM 调用，而是通过纯确定性逻辑将历史交互提炼为显式的执行账本（Execution Ledger）
这份账本包含三类核心数据结构，共同构成环境感知的基石：
观察记录：不仅记录"发起了读取"，更精准追踪实际成功返回给 Agent 的代码范围，失败、截断或有歧义的读取均被剔除，以此建立代码已读范围的硬性索引。
修改状态：引入双计数器机制，为文件和仓库维护对应的修改状态信息。通过比对计数器差值，系统能够根据修改状态判断早期观察是否仍然有效。
命令记录：归一化命令文本以剥离路径等偶然差异，并结合修改状态研判意图。例如代码变更后重跑测试属于有效验证，而环境未变时的重复读取或检查则被标记为无效消耗。
Inform 与 Govern 管理 Agent 的决策和执行过程
Ledger 在单步交互的前后两个边界分别介入生命周期，形成双通道交互机制：
Inform 通道：在模型生成动作前，Ledger 动态构建一份紧凑的状态视图，呈现当前修改焦点与已读内容的时效索引。该视图被动态重绘在模型上下文的最末尾，既让 Agent 即时获取最新状态，又不会破坏前缀历史的 Prompt Caching 命中率。
Govern 通道：在命令下发至底层环境前进行状态规则研判，输出三类处理结果：
-
ALLOW：正常放行命令至环境执行； -
REUSE：针对仍然有效的读取或搜索结果，直接复用历史结果； -
NUDGE：针对无改动时的重复跑测或短循环，放行执行并在返回结果中追加轻量提示，警示潜在的无效重复。
该机制不评估代码修复的语义正确性，只专注减少确定性的重复执行和状态偏差。
Inform 和 Govern 分别优化任务完成效果与执行成本
基于 SWE-bench Verified 500 题的消融实验揭示了两个通道的明确分工与互补效应：
-
Govern 主导"任务成功率提升"：在 MiniMax M2.5 下，仅开启 Govern 通道即可将成功解决的任务数从 379 拉升至 402，接近完整系统的 405 题。这表明物理级拦截无效动作能有效减少 Agent 因重复操作导致的无效探索。
-
Inform 主导"调用与 Token 骤降"：仅开启 Inform 通道使模型调用次数从 30.2K 降至 21.3K，输入 Token 从 616.7M 降至 336.4M，消耗减少近半。通过前置暴露当前状态，Inform 有效消除了 Agent 自行检索历史与盲目试探的开销。
两者结合实现了"Govern 提准、Inform 降本"的工程平衡：前者提升执行过程中的任务完成效果，后者削减维持状态所耗费的推理资源。
保守设计与安全边界
为避免规则引擎误伤合法探索，Govern 机制设立了较为保守的防护策略：环境配置、报错复现及补丁提交等关键操作强制默认 ALLOW 豁免拦截；NUDGE 告警设有冷却周期，且若 Agent 在收到复用引用后仍坚持发起相同读取，下一次将强制放行，降低 Agent 与运行时之间形成重复阻塞的风险。它定位为确定性的执行辅助层，而非僵化的限制系统。
Agent 状态治理的架构分层
在生产级长任务架构中，执行状态与记忆、上下文系统各司其职，形成互补的治理体系：
| 能力维度 | 核心解决的问题 | 生效周期 |
| Memory | 沉淀跨任务或跨会话的长期知识与经验 | 长期 / 跨会话 |
| 上下文管理 | 压缩历史体积，控制单步推理的 Token 成本 | 单轮推理窗口 |
| 执行状态 | 当前执行状态 | 单个长任务全生命周期 |
三者并非替代关系，而是共同构成了从模型认知到运行时落地的完整工程闭环。
SWE-bench 验证执行状态管理的实际效果
在 SWE-bench Verified 500 个真实工程任务测试中，论文评估了 Ledger 对不同 Agent 配置的影响。
实验结果显示，引入 Ledger 后，GPT-5 mini 和 MiniMax M2.5 两种配置下 Pass@1 均有所提升。其中：
-
GPT-5 mini 从 56.2% 提升至 64.2%；
-
MiniMax M2.5 从 75.8% 提升至 81.0%。
同时，论文报告两种配置下成本分别下降 28.9% 和 31.8%。这说明执行状态管理并不是提升模型本身能力，而是在长流程任务中减少重复操作和状态恢复成本。
结语
Coding Agent 正在从"单步代码补全"走向"长时间复杂任务维护"。当系统面临状态失步、陈旧读取与无效死循环时，单纯堆叠 Prompt 或增加 LLM 调用往往难以治本。
Ledger 验证了一种具有工程价值的解法：让模型专注语义推理，让运行时负责状态确定性治理。未来的 Agent 基础设施，很可能需要围绕运行时状态层展开更多工程实践