内部支持 runbook

触发条件

收到客户支持工单。所有工单进入此 runbook。

角色与责任

角色	主要责任
一线支持	工单分类、标准化处理、SLA 时间内回复
二线支持	一线无法解决的工单升级处理；agent 特有问题排查
CSM	关键客户的高严重度工单接力；与一线协调避免客户被多人触达
工程	产品 bug / 系统级问题升级处理
产品	工单模式分析，定期 review 排前三类问题驱动产品改进

Agent 产品工单分类

跟传统 SaaS 不同，agent 产品的工单需要专属分类。一线支持收到工单后第一步是按下表分类：

类别	典型工单	一线 vs 二线	SLA
agent 输出错误	”agent 给的回答不对”、“标签贴错了”	二线	4 工时
任务卡死	”agent 跑到一半不动”、“任务一直 in_progress”	二线	2 工时
账单超预期	”为什么这个月账单多了 3 倍”	一线 → 二线	24 工时
Cache 命中率下降	”我们的成本最近涨了”（深层原因可能是 cache miss）	二线	1 工作日
HITL 介入太频繁	”为什么每个任务都要我确认”	二线	1 工作日
Tier 限额相关	”为什么我突然不能用了”（撞上限）	一线	4 工时
集成 / API 问题	”BUA 扩展连不上”、“API 401”	一线	4 工时
账号 / 权限	”新员工没访问”、“忘了密码”	一线	4 工时
功能咨询	”agent 能做 X 吗”、“怎么配置 workflow”	一线	4 工时

标准处理流程（按类别）

Agent 输出错误

1. 收集：工单中要求客户提供任务 ID、原始 prompt、agent 输出、期望输出
2. 二线核查：在管理后台调出任务级日志（含 token 用量、tool 调用序列、模型版本）
3. 区分：
   • 可重现的 prompt 问题——客户提示词不够清晰 → 反馈优化建议 + 推荐 prompt 模板
   • 不可重现 / 概率性问题——同样 prompt 多次跑结果分歧 → 升级工程评估 prompt 调优或换模型
   • 明显的产品 bug——agent 完全误解任务、走错工具 → 工程立即介入
4. 反馈：72 小时内给客户具体定性 + 后续行动

任务卡死

1. 立即在管理后台手动 kill 该任务（避免持续消耗 token）
2. 二线核查任务级日志，确认卡死位置（哪个 step、哪个 tool 调用、什么错误）
3. 区分：
   • 超时 / 上游模型 unavailable——常规重试，告知客户已恢复
   • HITL 等待——用户没点确认 → 教育客户使用 HITL 流程
   • agent 逻辑 bug / 失控循环——工程升级（incident-response 的”硬中断”触发条件）
4. 客户工单内退还任务对应的 token 配额

账单超预期

最敏感的工单类型——涉及金钱，客户情绪通常较高。

1. 一线先承诺核查——不要在没查日志前承诺退款或解释原因
2. 升级二线核查：
   • 调出 30 天用量分布（按 tier / 任务类型 / 用户拆分）
   • 与上月对比，标记异常增量
3. 区分：
   • 客户使用量真实上涨——详细解释增长来源（哪个用户、哪个 workflow）；客户感觉合理则闭合工单；感觉不合理则引导考虑升级 tier 或限额
   • 产品侧 cache 命中率下降导致同样使用量但成本上升——CSM 接力，主动告知客户、说明产品侧 fix 路径、考虑账单调整
   • 明确计费 bug——立即退款 + 工程修复 + 全平台扫描其他受影响客户

Cache 命中率下降

1. 二线在管理后台查该客户的 cache hit 历史曲线
2. 区分：
   • 客户侧 prompt 改成动态了——某次集成更新引入变量 prompt → 反馈给客户调整
   • 产品侧 prompt 结构变化——发版改了 system prompt → 工程评估是否需要回滚
3. 与”账单超预期”经常联动，按那条流程处理

升级判断

一线必须升级到工程的情况：

• 同一类型工单 24 小时内出现 ≥ 3 个不同客户 → 可能是平台级问题，触发 incident-response
• 客户损失明确归因 agent 行为 → 涉及法律责任，升级到工程 + 法务（见 compliance/model-output-liability）
• 数据泄漏 / 合规事件 → 立即升级到工程 + 法务 + IC（不走支持渠道走 incident-response）

关键不要做的事

• 不要让一线解释 agent 内部机制——一线不知道 prompt 设计 / 工具链架构细节，错误解释会成为下一波客户不满的种子；技术解释由二线 / 工程出
• 不要在工单里承诺修复时间——除非工程已确认；推迟兑现损害信任
• 不要把”agent 输出错误”标记为”功能咨询”——前者是质量问题需要追溯，后者是教育问题；分类错会让产品错过质量信号
• 不要给同一客户的同类工单回复模板化答复——客户能看出来”上次也是这个回复”，等于宣告”我们没在解决”

度量指标

每周 review：

• SLA 达成率：按类别拆分，关注哪类工单经常延期
• 一次解决率：工单是否在首次接触后关闭
• 升级率：一线升级到二线 / 工程的比例（合理区间 15-25%；过低说明一线在硬扛超出能力的问题）
• 重复工单率：同客户同问题 30 天内重开比例
• 工单 → 产品 issue 转化率：有多少工单最终触发产品改进 ticket（健康基线 5-10%）

与其他章节的衔接

• 平台级事故的对外沟通：incident-response
• Agent 输出责任归属：compliance/model-output-liability
• 账单异常的 cost 模型基础：economics/cost-model
• Cache 命中率与定价机制：pricing/tier-design