AI agent 平台的很多故障，真正让客户失去信任的并不是“系统短时间出问题”本身，而是平台在故障期间说不清楚现在到底还能做什么。任务慢了，是全局故障还是某类连接器漂移？ETA 失真了，是因为 review 积压、预算收紧还是区域故障？自动化暂停了，是只影响高风险动作，还是整个平台都不能用？如果这些问题对外没有一个稳定说法，客户的恐慌会比故障扩散得更快。
很多团队在这里的默认沟通都太像传统状态页模板：正在调查、正在修复、已经恢复。问题是 AI agent 平台的故障很少这么线性。一个任务可能还能产出草稿但不能自动外发，一个区域可能只影响长任务恢复而不影响新请求，一个 connector 失灵可能只影响某个工作流而不是整个平台。你如果把所有情况都压成一条含糊的“部分服务异常”，客户读完只会更不敢判断自己现在该不该继续用。
所以 customer-facing incident communication 的真正价值，不是让公关更体面，而是把平台内部复杂的运行状态翻译成客户可行动的决策信息。没有这层翻译，状态页就只是一种看起来在更新、实际上没有帮助客户做判断的礼貌动作。
建议配合 AI agent Run Status、ETA 与 Needs Review 语义、AI agent SLO、Error Budget 与 Service Tier Design、AI agent Support Replay Pack 与 Escalation Handoff 和 AI agent Disaster Recovery 与 Regional Failover 一起看。
客户最想知道的，从来不是内部告警名，而是“我现在还能不能继续干活”
| 内部信号 | 团队内部怎么理解 | 客户真正关心的问题 |
|---|---|---|
| review queue aging | 人工队列积压 | 我的任务多久能轮到人工接手 |
| connector degradation | 某个外部依赖不稳定 | 哪些自动化会失败，哪些还能继续 |
| regional failover in progress | 平台正在切换执行区域 | 当前任务是否会丢、是否要重提 |
| error budget burn | 平台进入退化策略 | 哪类任务会被限流、哪类承诺仍保留 |
这也是为什么客户沟通不能只是把内部 incident room 里的语言原样搬出来。内部团队需要足够精细，客户则需要足够明确。两者不是谁更真实的问题，而是面向的问题根本不同。
状态页不是“我们在处理”的公告栏，而是服务边界的解释器
一个对客户真正有用的状态页，至少要持续回答三类问题：
- 当前影响面到底是什么，是全局、某类工作流、某个连接器，还是某个地区
- 平台现在还保留哪些能力，哪些能力已经退化或暂停
- 客户此刻最合理的动作是什么，是继续提交、延后执行、转人工，还是等待恢复
如果状态页不能把这三件事讲清，它就很容易退化成一种安抚仪式。平台更新得很勤，客户却仍然要去问支持、群里追问或者靠自己猜。那说明真正的沟通对象仍然不是状态页，而是支持团队手工补充的解释。
ETA 最危险的不是不准，而是假装比真实更确定
AI agent 平台很容易给出一个看起来精确的 ETA，因为系统里有队列、有历史时长、有 worker 状态、有 review backlog。可一旦事故处在连根因都还没稳定的阶段，精确分钟数往往是最不可靠的信息。真正成熟的对外沟通，会把 ETA 当成带置信度的承诺，而不是强行报一个让人安心的时间点。
更稳的说法通常是：
- 先说明当前仍在确认影响范围，不给伪精确时间
- 一旦能判断恢复路径，再给出时间窗和下一次更新时间
- 如果只对部分任务类型有把握，就明确写哪类任务预计先恢复
客户多数时候可以接受系统正在波动，但很难接受平台连续几次给出错误的确定性承诺。因为一旦 ETA 被证明不可信，后面哪怕技术恢复了，客户仍然会本能地更偏向自己停用或转人工。
一个常见事故：系统恢复了，客户却继续把它当作不稳定平台
某团队的 AI agent 平台在一次外部连接器故障中，技术层面其实恢复得不慢。问题出在对外沟通完全围绕“我们正在调查”和“预计很快恢复”。客户读到这些话之后，仍然不知道：
- 已经在跑的任务会不会丢
- 新提交的任务是否应该暂停
- 哪些自动化动作会被系统强制转人工
- 当前 ETA 是否只适用于一个连接器场景
结果是故障恢复后，很多客户仍然主动停用了相关自动化，因为他们对平台的判断不是“这次出了问题但处理得清楚”，而是“这套系统一旦出事，我们根本不知道还能不能信”。后来团队真正补的不是更多告警，而是客户沟通模板：每次更新都必须给出影响范围、当前保留能力、建议动作和下一次更新时间。这个改动没有减少故障次数，却明显降低了支持团队在事故期间的重复解释成本。
如果你现在只能先补一层，先把更新节奏和退化语义讲成固定合同
很多平台最先想做的是更漂亮的状态页界面。那当然有帮助，但比界面更重要的，是沟通合同：什么级别的 incident 多久必须更新一次，更新时一定要包含哪些信息，ETA 可以在什么条件下出现，退化模式要如何向客户解释。没有这份合同，状态页就会继续依赖值班同学的写作水平和当时的情绪稳定度。
AI agent 平台不可能永远没有故障。真正能区分成熟度的，不是是否零事故，而是事故发生时，客户能不能从平台的沟通里快速判断出自己该怎么做。说得清边界，本身就是服务能力的一部分。
延伸阅读：
