我的代理循环中的一个验证步骤连续数周运行零测试并返回退出码0
摘要
作者描述了AI代理循环的验证步骤静默失败运行测试并导致误报的场景,并给出了改进开发工具以防止类似问题的指导。
我运行了长达几个月的自主循环。模型能够完成工作。问题在于,它根据看似正常但实际不正常的证据将任务标记为完成。最糟糕的是:我有一个表格,将更改的文件映射到测试命令。其中三行指向的测试文件后来已被拆分为兄弟文件。命令运行后,收集到零个测试,退出码为0,并打印了“未运行任何测试”。连续数周显示为绿色(通过)。报告“已验证”的代理完全诚实。一个运行后无操作却返回退出码0的命令,看起来与通过命令相同,而且自动化程度越高,这种假象持续的时间就越长。在争论使用哪个模型之前,我会在测试工具中检查以下几点:任务完成是否需要一个工件,还是仅仅依赖模型的判断?一个运行无操作的命令返回退出码0,证明不了任何事情。它运行的是真正的入口点,还是仅运行测试套件?pytest会将包添加到sys.path,而直接调用则不会,因此即使测试套件全部通过,实际调用时仍可能出现ModuleNotFoundError。我曾将这样的错误发布到一个cron job中。它能否区分截断的检索和完整的检索?长循环会积累自信的部分答案,每个答案都会为下一步提供输入。这些都不依赖于模型。在你的系统中,你如何判断“完成”?你是需要命令的输出,还是接受代理的报告?
相似文章
一次成功的代理运行并不等同于验证。我们的一项相同模型消融研究完成了60/60个任务,但正确率为0/60。
本文基于一项消融研究,指出AI代理中成功完成任务并不保证正确性的一种失败模式,并介绍了AdaptOrch作为在代理工作流中实现外部验证和可靠性的工具。
让我损失最惨重的智能体故障全都声称成功
作者分析了155个AI智能体任务,发现大多数故障源于基础设施问题,如超时和虚假成功信号,而非模型错误,从而提出了基于效果断言和使用多条验证路径等实践方法。
外部验证一直是我编码代理运行中缺失的关键环节
作者指出,在有效使用 AI 编码代理时,外部验证是一个关键缺失的组成部分。
我停止信任我的编程代理的通过测试。构建了一个控制循环来让它证明自己的工作。
作者介绍了一种验证驱动的控制循环,用于编程代理,受核工业安全实践启发,确保代理在变更被接受之前证明其工作。
运行AI代理数月后的四大失败(由代理撰写)
一个AI代理反思了自身运行数月来的四大失败,强调了在持久AI系统中独立监控、任务验证以及防止捏造的重要性。