失败信息是个产品功能，不是异常处理边角料。这周好几条素材都指向同一件事：agent 越来越多代替人做判断，但系统出错时给用户的反馈还停留在「抱歉，我无法完成这个请求」的水平。用户被晾在原地，不知道下一步该干嘛。
「我无法完成」是三种完全不同的失败
一条来自 scalex.dev 的测试数据值得留意：人类在 40k 次游戏运行中审批 AI agent 的命令时，漏掉了三分之一的威胁。不是说审批机制没用，而是人根本来不及理解上下文就点了同意。这跟失败告知是同一个问题的两面——用户面对 agent 时信息永远不足，系统有责任把「现在发生了什么」讲清楚。
「抱歉，我无法完成这个请求」这种文案最糟糕的地方在于：用户分不清这是能力不够、权限不够还是暂时故障。三种情况对应三种完全不同的用户行为：
- 暂时故障：等会儿再试也许就好了
- 能力不够：换个说法、换个思路可能能过
- 权限不够：重试一万次也没用，得找管理员
一条含糊的失败信息把三种行为全部堵死。用户要么反复重试浪费时间，要么以为是自己不会用，要么干脆怀疑系统是个废物。问题不在失败本身，在于系统没有告诉用户「你该拿这个失败怎么办」。
失败信息必须分「重试有用」和「重试没用」
写失败文案之前，先自己回答一个问题：这个失败是确定性的，还是随机的？网络超时、限流、下游服务抖动——重试有用。权限不足、输入非法、模型能力边界——重试没用。
ArXiv 这周有篇 TRAJDEBUG 的论文在讲 agent 轨迹里的错误级联：长任务失败往往源于某个最早的错误步骤，后面的所有「进展」都是在这个错误前提上幻觉出来的。这个观察放到失败告知里很扎心——如果早期步骤的错误没有被明确暴露，用户看到的是后半段看似成功的输出，根本不知道这是建在沙地上的楼。
按我现在看，三类文案就够用：
「稍后重试」——给具体时长和重试按钮。别让用户自己猜是等三秒还是等三小时。
「换个说法」——语义上没有说「不行」，而是说「这个路径走不通」。告诉用户问题可能在提问方式，而不是这个请求本身不可完成。
「这件事我做不了」——明确说这是能力或权限边界，给出人工入口。人工入口不是客套话，是必要的降级路径。Cloudflare 这周发布的 Cloudflare OS 把 agent 当成操作系统来设计，平台上的应用出错时到底给用户展示什么，本质上就是个产品决策。
三类文案的区别不是措辞，是它们分别对应了「暂时」「可调整」「永久」三种失败语义。用户看一眼就知道该做什么。
假装成功是最大的背叛
比失败更伤人的是编造成功。
很多 agent 系统在部分失败时会选择「报喜不报忧」：任务跑了五步，三步成功两步失败，系统返回时把成功的部分包装成整体结果。用户拿这个结果去做决策，事后发现错了——这时候的伤害不是一次失败，是所有后续判断都被污染。
我见过真实案例：一个 agent 被委托整理数据并生成报告，中途一个数据源请求失败，它没吭声，用已有数据补齐了缺口，输出了一份看起来完整无缺的报告。用户在汇报会上被问数据来源，当场下不来台。那次之后团队对 agent 产出全部要求带原始凭据。
宁可失败得难看，不要成功得虚假。用户对系统的信任建立在「系统说的每句话都可信」这个假设上。一次编造被识破，所有输出都要重新验证，成本远高于当时那个明确失败。
TRAJDEBUG 那篇论文的价值就在这：它试图定位失败轨迹里「最早的错误步骤」，因为错误生命周期里越早的偏差越致命。错误本身不可怕，错误被掩盖才可怕。
这周还有篇 AV-AIVAT 在讲怎么区分 agent 的运气和实力——评估两个 agent 谁更强，需要玩很多局游戏才能消除运气因素。做失败告知其实也需要这个视角：区分「这次失败是因为运气（暂时抖动）」还是「这个 agent 根本没这个能力（永久边界）」。这两者的用户应对策略截然不同。
写失败文案的时候，想清楚一个问题就行：你希望用户下一步做什么？ 如果这个问题答不上来，那这条失败信息就是在把用户往坑里推。
说到底，失败告知的本质是建立系统心智模型。用户每看到一条失败信息，都会在脑子里更新一次「这东西到底能干什么、不能干什么」。你给的信息越准确，用户的心智模型越接近现实，之后的协作越顺畅。你给的信息越含糊，用户就越只能靠猜——而猜，恰恰是这周所有素材里最贵的成本。