一份面向 AI Agent 上线前 30 天的客服支持 Playbook，用来从真实用户问题、失败和信任顾虑中学习。
第一个月是学习系统
AI Agent 上线后的前 30 天不应该只是安静监控期，而是学习系统。用户会提出团队没预料到的问题，信任边界会被测试，客服会发现解释不清的地方，产品假设会遇到真实运营压力。支持 Playbook 的目标不是证明 Agent 完美，而是在可控范围内快速学习。
创建专门的支持分类
客服团队需要给 AI Agent 问题单独分类，不要混在普通 bug、问题或反馈里。可以设置错误回答、不安全建议、工具动作疑虑、上下文缺失、引用混乱、权限问题、成本疑问、升级请求和信任问题等分类。
给客服一份简单解释
客服需要能用普通语言说明 Agent 能做什么、不能做什么。说明应避免内部模型术语，写清支持的工作流、哪些动作需要人工确认、使用哪些数据源，以及什么时候升级。
定义升级触发条件
前 30 天需要清晰升级触发条件：疑似暴露错误数据、建议高影响动作、和公开政策冲突、重复已知失败、无依据结论、关键客户流程失败，或高价值客户投诉。触发条件应基于行为，而不是客服是否懂模型。
收集 trace，而不只是截图
截图有用但不够。Playbook 应告诉团队要收集用户消息、时间戳、账号或租户、Agent 回复、可见检索来源、工具动作、浏览器或会话 ID，以及用户是否基于输出采取行动。
第一周每日复盘
第一周应每日复盘 AI Agent 支持问题：新增数量、严重问题、重复问题、缺失帮助内容、解释不清的地方，以及扩大范围前需要修改什么。每日复盘能防止小混乱重复一整周。
维护已知问题页
客服需要一个持续更新的已知问题页，列出当前限制、替代方案、负责人、严重程度、客户影响和预计更新。这个页面可以先内部使用，关键是客服和产品不要对同一问题给出不同答案。
把问题转成内容
重复出现的支持问题就是内容机会。用户问 Agent 能做什么，就补产品页；问结果是否安全，就补信任说明；问人工审核如何工作，就补审批策略摘要。第一个月应该同时改进 Agent 和围绕它的网站。
诚实衡量支持负载
如果 Agent 自动化一个流程，却让客服负载翻倍，那不能算成功。要跟踪每个活跃用户的工单数、解决时间、升级率、重复问题率，以及由 Agent 行为混乱造成的工单比例。
第 30 天做范围决策
30 天结束时做明确决定：扩大范围、保持范围、缩小范围或暂停。依据应来自客服工单、trace、客户评论、评测结果和事故复盘，而不是演示仍然好看。
如何使用这份资源
把这篇文章当作工作评审辅助，而不是法律认证、正式渗透测试或安全保证。真正有用的下一步，是把每个部分转成可复查的证据：trace、策略、测试样例、负责人、阈值和上线决策。
相关 IBBS 资源
可复制的分享文案
AI Agent 上线前 30 天客服支持 Playbook：一份面向 AI Agent 上线前 30 天的客服支持 Playbook，用来从真实用户问题、失败和信任顾虑中学习。 阅读链接：https://ibbs.ai/zh/2026/07/08/ai-agent-support-playbook-first-30-days-cn/
如果需要更完整的评审，可以先做 AI Agent 就绪度自评，或查看 样例审计报告。