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