我越来越觉得，长期运行的 Coding Agent 最大的问题，可能不是上下文窗口不够长，而是缺少一套可靠的项目状态管理机制。 最近一篇论文《StateHa… · @xqliu · TwKit

@xqliu

我越来越觉得，长期运行的 Coding Agent 最大的问题，可能不是上下文窗口不够长，而是缺少一套可靠的项目状态管理机制。 最近一篇论文《StateHarness》研究的正是这个问题。 传统 Coding Agent 主要依赖对话历史和上下文窗口来维持对任务的理解。 但当一个 Agent 连续工作几个小时，修改几十个文件，经历多轮测试、失败和重试之后，问题就出现了。 它可能忘记之前为什么选择某个实现方案。 可能重新尝试已经被证明不可行的方法。 也可能完成了当前修改，却忘记检查受到影响的其他模块。 即使上下文窗口足够长，这些问题也未必能得到解决。 因为保存完整历史，不等于准确维护项目状态。 StateHarness 提出了另一种思路：在 Agent Runtime 中持续维护结构化的项目记录。 这些记录包括当前任务、已排除的假设、重要的实现决策、代码依赖关系，以及尚未完成的工作。 当 Agent 修改代码时，系统还会主动检查可能受到影响的调用方、测试和文档。 论文报告的实验结果： RefactorBench 完整任务链成功率：29.4% → 35.3% 清理检查准确率：87.0% → 95.4% ChainSWE Bug 修复率：35.1% → 39.5% 遗留未解决问题：60 → 43 这些提升并不是来自更大的基础模型，也不需要重新训练模型。 它们来自更好的执行状态管理。 不过，实验也发现连续修改过程中的部分回归问题有所增加。 这说明状态管理能够帮助 Agent 保持任务连续性，但不能替代测试和独立验证。 我认为这里有一个很重要的区别： Context History 不等于 Project State。 对话历史记录的是发生过什么。 项目状态记录的是当前什么成立、哪些问题尚未解决、哪些决策仍然有效，以及接下来需要验证什么。 对于长期运行的 Coding Agent，后者可能更加重要。 想象一个 Agent 从 GitHub Issue 开始，独立完成代码实现、测试、审查和发布。 如果它在执行过程中被中断，重新启动后不应该需要重新阅读几十万 Token 的历史，才能理解任务进行到了哪里。 它应该能够恢复明确的执行状态，知道哪些工作已经完成、哪些结果已经验证、哪些操作仍然待执行。 这让我越来越相信，未来的 Coding Agent Runtime 会逐渐具备类似操作系统和工作流引擎的能力。 它不仅需要管理上下文，还需要管理持久化状态、任务依赖、检查点、恢复过程和验证结果。 我的判断是： 长期运行的 Coding Agent，真正需要的不是无限增长的聊天记录，而是一套能够持续维护项目事实、执行状态和验证证据的系统。 更长的上下文可以帮助模型理解更多信息。 但可靠的项目状态管理，才能让 Agent 在长时间执行过程中不丢失方向。 论文：https://arxiv.org/abs/2610.17616

曝光 146 · 评论 0 · 点赞 0 · 书签 1