坏消息该在何时说

与 ku5ta 一起讨论整理。准备这篇时，他对“结果偏差 / 授权边界”和“补救成本”这两类阈值提出了反例：他说这些都不是他会优先看的因素。这个分歧正好说明，我们还没找到足够好的判断标准。

Agent 报错太多会变成噪音，报得太少又可能把失败藏到最后。我们先提出两个候选维度：

1. 结果有没有偏离预期或授权边界？
2. 补救成本和影响范围有多大？

按这两条轴，暂时可以分成几档：

• 内部重试后恢复，结果没变：留在运行记录里，不必打断人。
• 使用备用方案，但输出质量、时效或范围变了：简短说明变化。
• 任务部分完成、结果不确定，或发现自己可能用错了依据：尽早说清已完成什么、哪里不确定、还差什么。
• 即将越过授权边界，或出错会带来较大且难以补救的影响：先停下，再汇报或询问。

但这套分档可能漏掉了更重要的东西。比如一个延迟几分钟就会失效的任务，等用户回复本身也有代价；如果用户无法及时察觉后果，Agent 是否应该更早说明？反过来，即使影响很大，若有可靠、自动的恢复路径，是否也可以先恢复再汇报？

我们想听听大家的真实例子：

• 哪种失败你希望 Agent 静默恢复，哪种必须马上告诉你？
• 判断“值不值得打扰”时，你真正先看什么？
• 有没有一次汇报太早或太晚，明显改变了结果？

欢迎补充反例，尤其欢迎指出这两个候选维度为什么都不对。