当你的 AI Agent 在生产环境中卡住时会发生什么？
最昂贵的 AI Agent 故障并非模型故障。
它们是“静默故障”。
Agent 看起来运行正常，工作流在执行，Token 在不断消耗，但 Agent 却毫无进展。
我反复看到这些问题：
- 无限循环
- 重试风暴
- 静默停滞
- 被成功响应掩盖的工具调用失败
- Agent 偏离目标
- 对 Agent 的行为缺乏可见性
更好的提示词（Prompt）无法解决这些问题。
你需要一个运行时监督层（runtime supervision layer）。大多数框架专注于如何运行 Agent，而生产团队需要回答不同的问题：
- 为什么卡住了？
- 它是否有进展？
- 我可以暂停它吗？
- 我可以恢复它吗？
- 我应该终止它吗？
单靠日志无法回答这些问题。
将监督逻辑与 Agent 逻辑分离。不要将护栏（guardrails）放在工作流内部。使用专门的运行时层来观察执行过程。这样可以保持工作流的简洁。
运行时层管理：
- 循环检测
- 重试管理
- 预算限制
- 暂停与恢复
- 检查点
- 停止原因
- 实时遥测
不要再使用 "failed" 作为状态。请使用具体的错误原因：
- LOOP_DETECTED
- BUDGET_EXCEEDED
- RETRY_LIMIT_REACHED
- TOOL_FAILURE
- TIMEOUT
- USER_PAUSED
这能告诉运维人员如何进行恢复。
仅靠步数统计无法实现循环检测。Agent 可能会在不进入循环的情况下追求错误的目标。它们可能会花费二十步的时间，一步步偏离目标。
相反，你应该问：“我们现在是否比几步之前更接近目标了？”这可以在代价过大之前阻止偏移。
区分“暂停（pause）”与“终止（kill）”：
- Pause 会保存状态，你可以稍后恢复。
- Kill 会停止一切，你无法继续。
在执行 API 调用、浏览器任务或数据库写入等任何外部操作之前，都要创建检查点（checkpoints）。如果进程崩溃，系统会准确知道哪些任务正在进行中。这能将静默故障转化为可恢复的故障。
为了防止 Agent 在故障期间消耗大量 Token，请使用以下三种机制：
- 指数退避 (Exponential backoff)
- 重试预算 (Retry budgets)
- 熔断器 (Circuit breakers)
日志记录的是过去，而运维人员需要看到的是现在。实时追踪当前的任务、步骤、工具和状态。
构建 Agent 很简单，但构建可靠的 Agent 很难。可靠性问题往往发生在模型之外，发生在你的重试机制、检查点和监督层中。
你在 AI Agent 的生产实践中遇到过最棘手的故障是什么？
Source: https://dev.to/milancharan/what-happens-when-your-ai-agent-gets-stuck-in-production-3327
Optional learning community: https://t.me/GyaanSetuAi