AI Agent 的 badcase 无法彻底消除，但可通过系统性设计持续压降。这套方法论聚焦真实落地场景，从意图识别、执行过程到事后反馈形成闭环，提供可量化、可复用的优化路径。
智能速览
badcase 主要源于意图误判、计划缺陷、执行失控、需求漂移和边界失管五类根源
前置阻断层强调‘不确定就不执行’，通过澄清、拦截和确认守住第一道防线
过程兜底层默认假设工具会失败，要求参数校验、容错重试与结果自检
事后收敛层将每个 badcase 视为信号，通过归因标注、模式挖掘与规则沉淀实现批量拦截
产品设计需优先保障可信度：提供撤销入口、执行解释与低风险默认路径
badcase 评估应拆解为误执行率、澄清后失败率、同类复发率三个关键指标
精华内容
在真实业务系统中，badcase 不是偶发故障，而是设计缺口的显性暴露。有效压降不依赖单点修补，而在于构建覆盖决策前、执行中、反馈后的三层防御体系。
五类根源
实测发现，92% 的线上 badcase 集中于五类典型场景：意图误判导致不该执行却执行（占比38%）；计划缺失关键步骤或可用工具（24%）；执行中工具调用失败且无 fallback（17%）；用户中途修改需求但 Agent 未感知（13%）；以及极端输入、冷启动等边界场景缺乏兜底策略（8%）。这些并非随机错误，而是系统设计中未显式建模的风险点。
前置阻断
在 15 个实际交付项目中，引入强制澄清机制后，意图误判类 badcase 下降 67%。具体做法包括：当置信度低于 0.7 时触发追问；关键字段缺失超过 2 项即终止流程；涉及资金、权限等高风险操作必须二次确认。数据显示，约 41% 的 badcase 在此阶段被主动拦截，根本未进入执行环节。
过程兜底
执行阶段引入三重校验后，工具失败引发的级联错误减少 53%。具体包括：调用前校验参数类型与范围（如时间格式、ID 长度）；失败后按指数退避策略重试最多 2 次，超时则切换至预设 fallback 工具；关键步骤完成后比对返回结果与预期 schema，异常则立即中止并上报。这使‘失败后继续错’的比例从 31% 降至 12%。
事后收敛
某金融客服 Agent 上线 3 个月后，通过 badcase 标注系统累计归因 1,287 条样本，识别出 7 类高频模式（如‘用户说‘改地址’但未提供新地址’出现 214 次）。将其中 4 类沉淀为规则引擎策略后，同类问题复发率从平均 4.8 次/周降至 0.6 次/周，下降 87.5%。修复单例不如建立识别-归因-拦截的自动化链路。
产品信任设计
在用户侧增加‘撤销上一步’按钮与执行逻辑说明后，用户主动中断率下降 29%，投诉率下降 44%。测试表明，当 Agent 主动解释‘无法执行因缺少收货人电话’而非仅返回‘操作失败’时，用户二次尝试成功率提升至 76%。默认采用保守路径（如先查余额再扣款）虽使平均响应延迟增加 0.8 秒，但误扣款类投诉归零。
这套三层框架的价值，不仅在于降低 badcase 率，更在于推动 AI Agent 从‘能跑通’走向‘可信赖’。当每个环节都嵌入止损逻辑，系统便具备了自我纠错与持续进化的能力。未来，是否会出现一套标准化的 badcase 治理 SLO？这或许是下一阶段的关键命题。
