用途：为 Intercom 集成故障提供快速应急响应流程，覆盖从告警到解决的四个阶段——分诊、决策、缓解与复盘，并以 HTTP 状态码分支判断故障在己方还是 Intercom 侧。
前置条件：shell 中导出 INTERCOM_ACCESS_TOKEN（工作区管理员令牌）；安装 curl 与 jq 用于 API 和状态页探测；具备运行 Intercom 集成的部署的 kubectl 访问权限（用于重启）；可访问密钥管理服务（如 AWS Secrets Manager）以轮换泄露令牌；具备 Developer Hub 访问权或可升级至工作区管理员。
严重级别：P1 全部 API 调用失败，响应时间小于 15 分钟；P2 服务降级，小于 1 小时；P3 部分影响，小于 4 小时；P4 无用户影响，下一工作日处理。
主要能力与用法：先定级；再用 curl 探测可达性，例如 curl -s -o /dev/null -w "%{http_code}" -H "Authorization: Bearer $INTERCOM_ACCESS_TOKEN" https://api.intercom.io/me，并检查 status.intercom.com 与限流响应头；然后决策，401 轮换令牌、403 补充 OAuth 作用域、429 排队退避、5xx 带退避重试；按错误类型缓解，并按固定节奏发布 Slack 状态更新；最后使用模板完成复盘，记录时间线、根因、影响计数、Intercom request_id 与行动项。
参考文件：references/triage.md 提供完整分诊脚本与决策树；references/mitigation.md 提供 401/429/5xx 处置与降级模式；references/templates.md 提供 Slack 更新与复盘模板。
限制：需工作区管理员令牌与 Developer Hub 权限；无 Developer Hub 访问权时需升级处理；状态页不可达时可尝试移动网络或 VPN；缓存为空时需预先实现缓存预热。数据合规参见 intercom-data-handling。具体脚本细节以参考文件为准，资料未提供收费等信息。