我的智能体并没有忽视客户，是我自己的安全守卫吞掉了回复

几个星期以来，用户报告说智能体不理会他们。我以为是模型不稳定，花了很多时间更换模型和重写提示。但这从来都不是模型的问题。三个bug，全是我自己的，每一个都造成了沉默而不是报错。一个在传送路径上故障关闭的防护。每条外发回复都要经过一个语义检查，该检查有10秒超时，而检查本身调用的模型很慢，所以经常超时。超时分支是'不发送'，这意味着在聊天频道上，客户什么也看不到。错误的答案可以挽回，沉默则不行。基于一个小型路由模型的猜测，工具在轮次运行前就被移除了。有人请求提醒，路由模型交给轮次一个日历工具包，智能体试图引导用户连接谷歌日历，而不是使用自己的调度器。从外部看，这就像一个愚蠢的模型。但它其实是被困住了。嵌套的工具参数以JSON字符串而非对象的形式到达。处理程序对dict进行了isinstance检查，并静默地丢弃了其他所有类型，因此那些提醒上的run_at时间戳消失了，没有任何错误。共同的模式是，每个防护都将错误状态变成了安静状态，而且每一个都通过了测试套件，因为测试断言的是防护触发了，而不是用户实际收到什么。如果你在实时渠道上运行智能体，我想知道你是选择了故障开放，还是找到了在保持阻塞检查的同时避免沉默风险的方法。