By Unbug 
清华大学和阿里巴巴达摩院合作的一篇论文《Failure as a Process: An Anatomy of CLI Coding Agent Trajectories》，首次将CLI编码代理的失败建模为时间过程而非静态标签。通过对3843条执行轨迹的分析，论文发现决定性错误的中位发生步仅为第7步，而错误暴露的中位滞后高达10步——这意味着大多数失败在可修复窗口关闭后仍在徒劳地继续执行。
失败的时间维度
传统评估将代理输出简单分类为成功或失败，但这一静态视角掩盖了失败发生的动态过程。论文提出三个关键时间戳来刻画失败轨迹：t_err表示决定性错误首次发生的步骤，即一旦该错误出现，后续修复概率急剧下降；t_lock是经验上不可恢复的锁定点，此后无论代理如何尝试都无法回到正确路径；t_obs则是错误信号首次被代理感知到的步骤。
基于这三个时间戳，论文衍生出两个核心度量指标：修复窗口（t_lock减去t_err）衡量从犯错到锁死之间的可操作空间，中位数约为3步；可见性滞后（t_obs减去t_lock）反映代理在锁死后仍继续执行的时间长度，中位数高达10步。这一发现揭示了一个关键问题：大多数失败轨迹并非在错误发生后立即终止，而是在已经不可挽回的情况下继续消耗计算资源。
错误的类型学分布
论文对63000多个步骤进行了手动标注，将错误分为三大类。认知性错误占比最高，达到57.9%，指环境中存在正确信息但代理忽略、遗忘或误读的情况；能力不足占32.8%，表示当前模型架构本身无法完成所需推理；环境因素仅占9.4%，包括工具调用失败、API超时等外部问题。
这一分布表明，提升CLI编码代理可靠性的主要瓶颈不在基础设施层面，而在代理的信息处理与记忆保持机制上。超过一半的错误源于”看得见却做不到”的认知缺陷，而非”根本不知道怎么做”的能力边界。
成功与失败的轨迹分野
论文最引人注目的发现之一是：71%的成功轨迹至少经历了一次错误后才最终成功。这意味着错误本身并非成功的对立面，关键在于代理能否从错误中有效恢复。
数据进一步揭示了这种差异的量化表现：成功轨迹在遇到错误信号后的响应率达到92%，而失败轨迹的响应率仅为37%。更值得注意的是，仅18%的失败轨迹在锁死后立即终止，其余82%继续执行但没有任何实质性进展——这些”僵尸轨迹”不仅浪费算力，还可能通过错误的自我强化进一步偏离正确方向。
AI 范式雷达：《从并行到递归：WebSwarm的多Agent深度广度协同搜索范式》