Agent 任务失败的归因与统计

Agent 没有提交报告时，直接记零分很方便。但如果要比较模型能力，还需要知道它为什么没有完成任务。

在一批覆盖 10 个模型、50 个任务的计算化学评测中，共有 71 次运行没有提交报告。检查最后一次尝试的退出信息和事件流，得到以下分类：

其中，前四类共 58 次，约占 82%，在复盘中归为工程或记录问题。这个比例只对应本批未交卷样本。进程被杀和记录缺失的具体原因，还需要额外信息才能确定。

退出码为零，任务仍可能没完成

流中断的 40 次运行都以退出码 0 结束，但事件流停在未完成的内容或工具调用上。外层程序据此认为运行成功，没有触发重试。

这组运行在中断前持续时间的中位数只有 15 分钟，远短于 12 小时的任务预算。因此，这些记录不支持“模型耗尽了计算时间”的解释。不过，仅凭客户端事件流，还不能确定中断发生在上游服务、网关还是客户端，需要结合各层日志继续定位。

因此，判断任务完成不能只看进程退出码，还需要检查事件流是否正常结束，以及要求提交的文件是否存在、内容是否有效。

API 连接失败又是另一种情况。本批有 11 次运行在网关连接上游时触发 90 秒超时，三次尝试都失败。它们与模型正常结束但没有写报告，应当使用不同的状态记录，否则后续统计很难区分。

另一类问题是 Agent 提交后台计算后，自行结束会话，并声称“计算完成后将自动生成报告”。但在当时的运行配置下，没有后续机制继续整理结果。后台计算的提交、完成和报告生成，需要由调度程序明确衔接。

保留足够的运行状态

对长任务，可以分别记录会话状态、计算作业状态和交付状态。会话已经结束时，计算可能仍在后台运行；计算已经结束时，报告也可能尚未生成。只用一个“成功／失败”字段，很容易丢掉这些区别。

每次尝试至少保留开始和结束时间、退出码、超时标记、最后一个完整事件，以及产物检查结果。分类时优先使用这些可观察信息。比如，进程收到终止信号可以确认，但是否因为内存不足被杀，需要另外的系统记录。

恢复任务时还应检查已有计算是否完成。报告整理阶段失败，不一定需要重跑全部计算；已有后台作业仍在运行，也不宜直接重复提交。重试次数和总时间预算需要一并记录。

如何统计成绩

缺报告记零分，可以反映整套系统的交付表现，但其中同时包含模型、服务连接和运行框架的影响。

如果只对已提交的报告取平均，又可能偏向那些只完成了较容易任务的模型。因此，比较时应同时给出提交率、已交报告的平均成绩和失败原因；有必要时，再比较各模型共同完成的任务。

其中，提交率的分母应包含计划执行的任务；报告平均成绩的分母是实际纳入评分的报告。缺少原始轨迹的任务还应单独标注，因为它可能有报告，却无法完成报告与轨迹的一致性检查。

如果排除工程故障或补跑失败任务，也应保留排除原因和补跑记录，并对各模型使用相同规则。否则，排行榜的变化可能来自样本集合改变，而不是模型表现改善。

这样才能区分报告质量与运行可靠性，也方便判断下一步应该改进模型行为，还是修复调度和服务连接。