AI agent在身份验证步骤比推理步骤更容易失败。其他人也有发现吗？
摘要
AI agent常常因为身份验证障碍（如电子邮件验证、OTP超时和验证码）而失败，而非推理错误，这凸显了生产环境中的基础设施挑战。
我一直在构建AI agent，并注意到一个模式：LLM推理部分可以正常工作，但出问题的是所有与账户、登录和验证相关的东西。当agent到达“注册此服务”这一步时：\- 电子邮件验证循环中断 \- OTP在agent执行步骤期间超时 \- 触发验证码或机器人检测 \- 步骤之间会话过期 模型已经知道该做什么，但周围的基础设施不配合。好奇这是否与其他人在构建时遇到的情况相符。你的agent在生产环境中实际失败在哪里？是推理部分，还是管道部分？
相似文章
AI代理的失败方式鲜有人论及。以下是我亲眼所见。
文章强调了AI代理工作流程中实际的系统级失败，例如上下文泄漏和幻觉细节，认为这些通常是基础设施问题而非模型缺陷。
为什么我的智能体在生产环境中失败？
本文解释了 AI 智能体在生产环境中失败的原因，即它们缺乏人类处理模糊性、例外情况和复杂决策所需的推理能力和隐性知识。
让我损失最惨重的智能体故障全都声称成功
作者分析了155个AI智能体任务，发现大多数故障源于基础设施问题，如超时和虚假成功信号，而非模型错误，从而提出了基于效果断言和使用多条验证路径等实践方法。
大多数AI智能体失败的原因在于人们像构建聊天机器人那样构建它们
许多AI智能体实现失败是因为它们把智能体当作聊天机器人来对待，依赖聊天历史记录来管理状态，而非使用确定性的数据结构。文章提倡将推理（LLM）、动作（工具）、工作流进度（状态机）和外部触发（网络钩子）分开，以构建可靠的业务智能体。
AI代理最诡异的一点：人类失败模式开始显现
作者观察到AI代理展现出类似人类的失败模式，比如在上下文压力下过度自信和跳过步骤，这表明系统可靠性更多地依赖于稳健的验证和受控环境，而不仅仅是模型智能。