编码Agent为何长任务失效？运行时状态管理解析

摘要

长周期任务场景下，编码Agent会累积海量交互日志。但完整交互流水不等于实时运行状态：多轮修改之后，Agent早期读取的代码片段已经失效，系统却没有对应的感知机制，会导致模型继续基于过期信息做决策，或是在代码没有变动的场景重复执行测试逻辑。论文《Turning Interaction History into Execution State: A Runtime Layer for Long‑Horizon Coding Agents》点明了这一核心瓶颈：长任务编码Agent真正缺失的，并非更大的上下文存储能力，而是一套可以显式维护、表达当前执行现场的运行时状态层。本文围绕Ledger运行时账本架构展开分析，拆解交互历史与执行状态的本质差异，对比传统上下文管理方案的局限，解析Inform与Govern双通道的工作逻辑，结合SWE‑bench Verified公开实验数据，说明状态治理对任务成功率、Token开销带来的实际收益。在多模型混合部署的Agent工程实践中，可以借助koalaapi这类API网关完成多后端模型的统一接入与流量治理。

一、长周期编码Agent：交互历史不等于真实执行状态

当前绝大多数Agent实现，依靠线性追加的交互历史驱动模型做出判断。这套机制会完整记录每一次工具调用、代码读取、修改、测试行为。但交互记录仅仅是已经发生过的行为日志，并不是实时更新的环境快照。当任务周期拉长，二者之间会逐步产生状态偏移，直接引发两类典型工程问题。

第一类问题是时效性判断失效。Agent在任务早期读取的配置文件、源码模块，经过多轮跨文件修改后，文件内容已经发生变更。但交互历史不会主动标记“该读取结果已经过期”。模型每一轮推理，都需要从整条冗长对话历史中重新推导当前代码现状。推理过程很容易采信过期的旧信息，生成不符合当前代码库现状的操作。

第二类问题是无效动作循环。当代码没有发生任何改动，Agent无法自主判断：上一轮的测试结果、文件读取返回内容是否依旧有效。于是重复发起完全一致的读取、测试指令，产生大量无业务价值的空转，消耗Token配额，拉长任务耗时，甚至让Agent陷入原地循环无法推进任务。

很多开发者会直觉认为：只要扩大上下文窗口，就能解决长任务问题。但更大的上下文只是把更多历史内容放进模型视野，并不能自动标记哪些信息已经失效。过期记录依旧混杂在对话中，模型依然有概率误用旧数据。单纯提升上下文长度治标不治本。

二、传统上下文管理的能力边界

行业现有长任务优化方案大多归属于上下文管理范畴，包含历史截断、KV压缩、多轮摘要等手段。核心目标是降低单轮推理的Token负载，控制输入规模。

但是对于会持续改写外部环境的执行型Agent，核心瓶颈并不在于历史记录的体积，而在于历史信息和真实运行环境是否还保持一致。摘要可以概括“曾经读取过某个模块”，但没有办法判断该模块后续是否被修改；也无法阻止模型重复发起不必要的读取、重复执行测试用例。

这里需要明确二者定位差异：

• 上下文管理：管控历史信息的呈现体积，解决推理输入规模过大的问题；
• 运行时状态管理：维护真实环境边界、操作有效性标记，解决信息过期、动作重复执行问题。

两者属于不同维度的工程课题，上下文管理无法替代运行时状态治理。只有把两部分能力组合，长周期Agent才能稳定输出。

三、Ledger：面向编码Agent的外部运行时账本

针对上述痛点，相关研究提出Ledger，一套部署在Agent外部的确定性运行时中间层。该方案不需要改动原有Agent内部推理逻辑，也不新增大模型调用，依靠确定性程序逻辑，把零散交互历史，整理成一份显式可读取的执行账本（Execution Ledger）。

账本内部维护三类核心数据结构，共同构成环境感知的基础。

1. 观察记录

不只是简单记录“发起过读取文件”，而是精准保存真正成功返回给Agent的代码范围。读取失败、被截断、存在歧义的内容会直接剔除。以此构建一份硬索引，标记当前Agent实际掌握的代码文件范围。

1. 修改状态

引入双计数器机制，针对每一个文件、仓库维护修改状态。系统对比计数器数值的变化，就可以判断Agent之前拿到的观察记录是否依旧有效。一旦文件发生修改，对应旧的观察记录直接标记失效。

1. 命令记录

对命令做归一化处理，消除路径书写方式带来的形式差异。再结合修改状态，区分动作价值：代码发生变更之后重新运行测试，属于有效验证；环境完全没有改动时，重复读取、重复测试，标记为无效消耗。

整套Ledger全部是确定性计算，不需要调用LLM，不会带来额外推理开销，独立于Agent主流程之外运行。

四、Inform与Govern双通道，管控决策与执行全流程

Ledger在交互周期的两个边界切入，形成双通道的交互机制，分别处理模型输入与命令下发，兼顾任务完成率与推理成本。

Inform通道：模型推理前，提供最新状态视图

在模型生成动作之前，Inform通道会动态组装一份轻量化状态视图。内容包含当前修改焦点，以及各类读取内容的时效性索引。这份视图会追加到模型上下文末尾。

模型可以直接拿到整理完毕的实时状态，不需要通读全部历史来回溯推导；同时该实现不会破坏原有历史缓存逻辑，对Prompt缓存命中率几乎不产生负面影响。

Govern通道：命令下发到真实环境前，做状态规则研判

当Agent输出工具调用命令，在真正执行之前，Govern通道结合账本状态，输出三类处理结果：

1. ALLOW放行：命令正常下发，直接在真实环境执行；
2. REUSE复用：读取、搜索类操作对应的资源没有发生改动，直接返回历史结果，不需要重复调用工具；
3. NUDGE提示：检测到无变更前提下重复执行测试、循环读取，允许放行执行，同时向Agent追加提示，告知本次动作属于潜在无效重复操作。

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，开销接近减半。通过前置暴露状态，减少Agent反复检索、试探性读取带来的成本。

二者配合实现工程层面的权衡：Govern拉高任务完成质量，Inform压低维持状态需要付出的推理资源。

保护策略与安全边界

Govern机制采用保守的防护逻辑，避免误拦截合法的探索行为。环境配置修改、补丁提交、报错复现这类关键操作，默认走ALLOW放行逻辑，不会拦截。
NUDGE警告具备冷却周期；如果收到提示之后Agent依旧坚持发起相同调用，系统后续直接放行。该定位是辅助执行层，而非僵化的阻断系统，不会剥夺Agent探索空间。

五、长任务Agent三层架构分工：内存、上下文、运行时状态

面向生产环境长周期任务，内存、上下文管理、执行状态三者各司其职，构成互补的完整治理体系。

三者不存在互相替代的关系。内存沉淀长期知识，上下文管理控制单次输入规模，执行状态负责跟踪任务过程中的环境变更，三层协同完成从模型认知到运行时落地的闭环。

六、SWE‑bench Verified实验数据，验证状态管理收益

论文基于SWE‑bench Verified 500个真实工程任务开展对照测试，对比不同方案在Pass@1指标、相对资源损耗（RRU）上的表现。

从测试结果能够看到，接入Ledger运行时账本之后，两套基座模型Pass@1均获得可观提升：GPT‑5‑mini从56.2%提升至64.2%；MiniMax M2.5由75.8%提升至81.0%。同时两套配置下，资源开销分别降低28.9%与31.8%。

实验说明：运行时状态管理不会增强大模型本身的代码理解能力，它的价值体现在长任务流程中，减少重复操作、避免过期信息误导，降低状态恢复的成本，让模型能力可以稳定发挥出来。

七、总结

编码Agent正在从简单的单步代码补全，走向长时间复杂任务维护。当系统出现状态丢失、过期读取、无效循环的时候，单纯依靠优化提示词、扩大LLM调用次数，很难从根源解决问题。

Ledger方案给出了具备工程落地价值的思路：把语义推理交给大模型，把运行时状态的确定性治理交给外部中间层。不需要改动模型本体，通过一套独立的账本与双通道机制，解决长周期任务最棘手的状态漂移难题。未来Agent基础设施建设，运行时状态层会成为重要的实践方向。在多模型混合部署架构下，开发者可以通过统一网关简化多模型接入流程。

了解更多：https://koalaapi.com