AI 的失败 78% 不报警一次关于「静默错状态」的工程复盘做 AI 客服落地这两年最容易被忽略的一类故障不是模型胡说而是它每一步都成功结果却是错的。2026 年 8 月 KDD 智能体评测与可信度研讨会KDD-ETAAI 26的论文《Reason Less, Verify More》把这类失败单独拎了出来在 τ²-bench 的航空票务任务里78% 的失败属于 silent wrong-state failure—— 工具调用返回成功、全程无异常、Agent 如实报告任务完成但数据库状态违反了业务规则订单被取消、乘机人数被改成 0、理赔未经核验即受理。一、机制接口只校验格式业务规则留在人脑里论文给出的解释是策略宽松接口policy-permissive只要调用格式合法接口就执行哪怕这次状态变更在业务规则上是被禁止的。对照到企业内部系统这套结构很常见——作废按钮对谁都可用能不能点靠操作的人自己知道规矩。规则没写下来模型只能猜猜对了是运气猜错了不报错。二、为什么换更强模型不解决论文的解法不是换模型而是加确定性前置闸门若干个只读断言在写操作真正发生之前拿当前状态校验这次调用是否越界。不调用模型、几乎不增加延迟。实测τ²-benchgpt-4o-mini全量任务成功率29.6% → 42.0%12.4pp配对 bootstrap P0.0012另一组 15 个随机种子复现12.3ppP0.0008提升集中在闸门真正触发的任务上26 个触发任务 19.2pp。附加观察gpt-5.2 在默认推理设置下仍会尝试违规写入同一套闸门把成功率从 61.2% 提到 71.6%10.4ppP0.020n5属提示性证据。结论一句话Agent 可靠性是边界执行问题不是推理问题。三、工程落点三层可复现的做法1边界断言放在写操作之前只读、无模型# 伪代码状态机式前置校验失败即拒绝不做尽力而为 def assert_transition_ok(state, action): if action.kind approve_refund and state.amount REFUND_LIMIT: raise PreconditionFailed(超限退款必须转人工) # 不返回 True/False直接拒绝 if state.status in TERMINAL_STATES: raise PreconditionFailed(终态不可再变更) return True要点断言只读当前状态、不引入模型判断、失败抛异常而不是回退到默认允许。跑起来长这样真实输出形态$ python -m pytest tests/test_precondition.py -q FAILED tests/test_precondition.py::test_over_limit_refund_is_rejected PreconditionFailed: 超限退款必须转人工 (amount8600, limit5000) 1 failed, 12 passed这条 FAILED 是故意的修法不是改测试而是把超限必须转人工这条规则从老员工脑子里搬进断言。补完规则后同一命令返回13 passed日志里不再出现已批准的越权单。接口侧同理任何格式合法就执行的写入接口都应该在服务端返回HTTP 409冲突而不是HTTP 200成功——状态码是最便宜的报警器用不上就等于没有。2每条知识事实带元数据缺元数据不放行检索企业知识库里最贵的不是文档数量而是同一条政策的多个版本并存。实测过的坑同行公开复盘一家跨境家电客户 1.2 万条 FAQ退货时效有 7 天 / 15 天 / 30 天三版全未删除检索按相似度召回 → 越复杂的问题答错率越高且答得特别自信。最小可用字段集8 项source来源/effective_from、effective_to生效起止/marketplace适用市场/product_scope适用范围/owner负责人/confidence置信度/supersedes取代关系外加conflict_policy硬冲突处理。冲突处理三步先按生效范围过滤 → 再按来源权威度排序 → 仍硬冲突则转人工不猜。3把抽查写进流程而不是等投诉每周跑一次过期扫描捞出effective_to已过但未被supersedes标记失效的条目、负责人离职超 90 天的孤儿事实、180 天未更新的低置信条目。每周从真实工单抽 50 条高风险会话退款 / 赔付 / 合规 / 账号人工核证据链它引的是哪条、版本对不对、范围对不对。命中率就是知识库的健康分连续两周下滑就说明该大扫除而不是继续灌文档。四、行业数据供立项论证引用VB Pulse 2026-07n101百人以上企业68% 的企业过去半年把一次自信但错误的 Agent 回答追溯到缺失或不一致的业务口径6 月为 57%37% 不止一次。Gartner 2025-10n321客服负责人91% 面临2026 年落地 AI的组织压力仅约 1/4 真正提升了自助服务效果58% 计划把一线坐席培养为知识管理专员。Forrester 2026 预测约 1/3 的 AI 自助服务部署将失败主因是内容质量差与知识缺口不是模型不够好。20 个企业案例调研85% 用闭源模型、70% 不微调、85% 完全自研不用框架74.2% 采用人在环路验证无人完全信任 AI 判断68% 的生产系统在需要人工干预前执行步骤不超 10 步。五、给技术负责人的三条落点建议先写规则再写 Prompt把什么情况下必须转人工这类判断逐条显性化成可执行、可校验的规则这一步的收益比换模型大。只读断言前置能拦住的错都不要留给模型事后道歉。验收口径改一改把AI 有没有报错换成抽样的 50 条答得对不对故障记录变干净不一定是好事可能是没人查。我们做企业知识库与 AI 客服落地把公司里靠默契运转的规矩变成机器能执行、人能核验的知识。数据与结论均来自公开来源并人工核对代码示例为脱敏后的最小复现形态。