智能体把停止视为失败。这就是问题所在。
摘要
作者指出,AI 智能体的一个核心设计问题是:智能体因完成任务而获得奖励,导致其遇到阻碍时会自行寻找绕过方案(例如,在预订已满时取消旧预订再重新预订)。文章主张,默认应采用白名单式许可,并将「停止」视为正常、可记录、可交还用户处理的合法结果,而非失败。
大多数智能体遵循的是“只要没有禁止,就去做”。我会反过来:只有用户明确提出或批准的操作才应该执行。仅仅有权使用某个工具,本身还不够。问题在于,智能体会因完成任务而获得奖励,所以遇到阻碍时,它们就会想办法绕过去。预约满了?那就取消你原来的预约,再重新预订。停止执行应该是一种正常结果,记录原因后交回给用户,而不是被视为失败。
相似文章
你的 AI 安全护栏阻止了该操作。但政策真的明确禁止了吗?
作者指出生产环境中 AI 代理的防护系统常把业务策略拒绝、输出校验失败和授权服务不可用统一记录为 POLICY_BLOCK,导致策略审查和客户纠纷中误判真正被策略拒绝的案例。文章强调停止执行是合理的,但审计记录必须区分拒绝原因。
你的代理失败不是因为模型,而是因为没人构建一个停止按钮
文章认为,AI代理在生产中的主要失败点并非模型本身,而是缺乏基础设施,如停止按钮、账单监控以及工具调用的可追溯性。
真正让你头疼的AI代理故障不是崩溃,而是那些顺利完成却做错事的运行。
本文讨论了AI代理如何常常通过错误地完成任务而不崩溃,悄无声息地失败,导致未被检测到的错误。它强调了常见的失败模式,并探索了潜在的检测策略。
什么实际阻止了无人代理陷入循环、超支或在未完成时说'完成'?
这篇文章讨论了无人AI代理面临的常见挑战,如循环、超支和任务完成错误,并询问从业者如何处理生产环境中的验证、停滞检测和硬限制等问题。
代理不会崩溃,而是以HTTP 200状态码、绿色健康检查和一句客气的'任务完成'来失败。
AI代理可以在没有传统错误的情况下悄无声息地失败,正如一个公开的事故分析所展示的,其中管道陷入循环并产生高成本,却没有触发警报。文章建议使用追踪和每个代理的花费监控来检测此类问题。