大多数 agent-native 产品把设计精力花在了"当一切顺利时"——任务自动完成、结果超出预期、用户感到惊喜。但产品信任真正被建立或摧毁的时刻，几乎总在 agent 失败的时候。

一个 agent 做了错误操作，这件事本身不一定致命。致命的是三件事经常同时发生：它把用户的工作区或数据搞乱了、它说不清楚到底发生了什么、它下次还会犯完全一样的错。用户不仅要处理原本的任务，还要先替 agent 擦屁股。

第一个产品坑是"失败时把用户的工作区弄脏"。很多 agent 工具在执行中途报错后，留下半成品文件、改了一半的代码行、生成了但没有正确写入的内容。用户回来看到的不是"任务未完成"，而是"我不知道哪些是我改的、哪些是 agent 改的"。好的设计应该反过来：agent 失败后的默认状态必须是可恢复的——每一步关键操作都有快照或回滚点，失败时自动回到最后一个确定干净的状态。这不是工程上的过度投资，这是产品信任的基础合约。

第二个坑是"失败时用技术原因解释"。用户不需要知道是 token 超限、API 超时还是模型产生幻觉。他们只需要知道三件简单的事：什么没完成、我的东西还在不在、我现在应该怎么办。把技术故障翻译成用户可行动的信息，比任何模型能力升级都更直接影响用户下次会不会再打开这个产品。

第三个坑往往被忽略：agent 不会从失败中学习。同一个 agent 在同类型任务上反复掉进同一个坑，用户发现自己从"使用者"变成了"质量 QA"。如果 agent 不能从失败模式中提取约束、自动调整后续行为，那它不是在帮用户——是用户需要替它维护一套"不要这样做"的心智清单。

反过来看，做得好的产品往往在失败路径上投入了比成功路径更多的产品思考。Cursor 的 inline diff 和单步 undo 不是锦上添花的细节，是产品安全网的核心结构。好的 agent 产品不是承诺"永不出错"，而是承诺"出错不会让你更糟"。

可以问一个小问题：你的产品在用户最生气的那一刻，还能不能让他觉得"至少没丢"？