## 用户反馈紧急升级与分流 {.case data-case-id="004"} | 字段 | 值 | | --- | --- | | 案例编号 | `004` | | 行业 / 部门 | 互联网 / 产品 | | 角色 | 产品经理 | | 难度 | `进阶` | | 调用来源 | `schedule`（定时由获授权 Agent 经 App/Extension 查询反馈渠道） | 用户反馈越积越多，产品经理不可能逐条判断哪些要紧急跟进。目标：定时由获授权 Agent 拉取新反馈并评估，正常的发回执归档（Loop 内留档）、不打扰产品经理；只有紧急或低置信度的反馈进入人工确认，确认升级后通知客服团队。为防"安全/数据丢失被漏判"，对正常结果做抽样核验。指标：紧急反馈从评估到客服收到通知的中位数 < 30 分钟；正常反馈不进入人工队列、100% 发回执归档。 - **覆盖**：定时拉取新反馈、评估紧急程度、紧急/低置信走人工确认、正常发回执归档（Loop 内留档）、命中升级后通知客服、正常结果抽样核验。 - **不覆盖**：批量反馈聚合分析、自动创建工单、客服跟进本身。 - **假设**：有一个经授权能读取反馈渠道的 Agent（通过 App/Extension）；反馈为带时间戳的文字内容。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：定时让获授权的反馈 Agent 从反馈渠道拉取新反馈，逐条评估紧急程度并返回（紧急程度、分类、置信度、理由、是否触及安全或数据丢失红线）。App/Extension 在读取侧即完成聚合与脱敏，Agent 只接收反馈编号、脱敏摘要、分类与置信度等白名单字段，不接收提交人姓名、邮箱、联系方式等原始字段。 触发：定时（计划）发起调用，调用时带入反馈渠道、团队频道、反馈 Agent 和审批人。 结果分流（按优先级从高到低依次判断，先判红线再判紧急度）： 触及安全或数据丢失红线：无论紧急程度与置信度如何，一律进入人工确认，绝不自动结案——这是最高优先级，命中即短路，不会落到下面的“正常”路径。 紧急或低置信（未触及红线）：进入人工确认，产品经理看到的是与 Agent 相同的脱敏摘要、命中的规则和理由（原文不进入工作流），确认后通知客服团队并留审计时间戳。 正常且高置信（未触及红线且置信度不低于阈值）：发回执归档（Loop 内留档、发汇总回执）并留审计时间戳，不打扰产品经理；按抽样口径抽出一部分留待产品经理事后核验。 本期无新反馈（查询成功但结果为 0）：发一条“本期无新反馈”汇总回执并留时间戳，不静默结束，也不当作取数失败。 审批：紧急/低置信必须经产品经理确认才升级通知，审批本身不设自动超时、无默认通过或否决；驳回则本次失败结束、归档为正常并留审计，不自动改判。 取数失败（反馈渠道不可达或数据陈旧）：发告警回执并留审计时间戳，按重试上限重试，仍失败则升级到值班频道；不当作"本期无新反馈"，也不进入正常路径。 异常：反馈 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容。 完成：正常路径与升级路径各自出回执后结束。 ``` ![案例 004 用户反馈升级与分流：定时让获授权 Agent 评估脱敏后的反馈；触及红线或紧急/低置信强制进入人工确认（可见脱敏摘要/规则/理由），正常且高置信未触及红线发回执归档并抽样核验，本期无新反馈发汇总回执，反馈渠道不可达按取数失败告警留审计重试升级；回传不合结构停在原等待点，驳回则失败结束](../../../media/cases/fig-case-004-01-flow.svg){#fig-case-004-01 width=94%} 如上图所示，正常路径、人工决策与异常同时可见： 1. **定时触发**：计划到点发起一次调用，带入反馈渠道、团队频道、反馈 Agent 与审批人。 2. **评估反馈**：获授权 Agent 从反馈渠道拉取新反馈，逐条评估并回传（紧急程度、分类、置信度、理由、是否触及安全或数据丢失红线）；回传结构不合要求时停在原等待点，等其重新提交，不自动重跑。 3. **多路分流（先判红线，再判紧急度，最后才归档）**： - **触及安全/数据丢失红线**：无论紧急程度与置信度，强制进入人工确认，绝不自动结案（红线是路由条件，不是仅返回的字段）。 - **紧急或低置信（未触及红线）**：进入人工确认。产品经理看到的是与 Agent 相同的脱敏摘要、命中的规则和理由（原文不进入工作流），确认后通知客服团队并留审计时间戳；驳回则本次失败结束、归档为正常并留审计。 - **正常且高置信（未触及红线且置信度不低于阈值）**：发回执归档（Loop 内留档、发汇总回执）并留审计时间戳，不打扰产品经理；按抽样口径抽出一部分留待事后核验，发现漏判即人工补升级。 - **本期无新反馈（查询成功但为空）**：发一条“本期无新反馈”汇总回执并留时间戳，不静默结束，也不当作取数失败。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"定时拉取 + 多路分流"流程——它知道"评估"需要一个发消息并等待回调的 Agent 环节、"分流"需要一个条件路由、"人工确认"需要一个审批环节、"回执与通知"各需要一个发消息环节，并把它们连起来。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **反馈 Agent 回传不合结构**：本次完成请求被拒绝，流程停在等待点等 Agent 修正后重新提交，不会反复重跑，也不会发出错误结果。 - **安全/数据丢失/付费失败被误判为正常**：这是最危险的漏判。靠两层兜底——规则里把这类设为永远紧急；再对正常结果抽样核验，发现漏判即人工补升级并留审计。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 - **产品经理驳回升级**：本次失败结束、归档为正常并留审计；要重新升级就再发起一次。 - **反馈渠道不可达**：按取数失败处理，告警并留审计时间戳，不当作"无新反馈"静默结束。 - **长时间无人审批**：审批本身不设自动超时，流程停在等待状态。若业务需要响应时限，由另一条定时检查的 Workflow（或值班人员）扫出超时项并通知经理。 只有紧急或低置信度的反馈才进入人工确认，正常的不打扰产品经理。确认时产品经理看到的是与 Agent 相同的脱敏摘要、命中的规则和理由，所以是"有依据的快速决策"而非盲目拍板。审批只有确认或驳回两种结果，驳回即本次失败、归档为正常，没有"AI 自动改判"。若要更严（如触及安全红线的必须双审），在提示词里写明，AI 会在流程里多加一个审批环节。 反馈渠道（客服平台或反馈系统）的读取由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统。访问凭据用占位由 Agent 运行时从密钥引用。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段以白名单为准（仅令牌化/白名单字段，原值不进入以上任何一层），可回溯个人的字段（姓名/邮箱/证件/联系方式等）在源头即被令牌化/伪名化，并按 10% 抽查四层实际记录。反馈渠道不可达或数据陈旧属于取数失败，走失败回执与升级，不当作"无新反馈"静默结束。 - **回放集与基准**：取最近 200 条已标注历史反馈，人工基准答案为既定升级决定（紧急/正常）；正常判定与基准一致率 ≥ 90% 视为通过。 - **漏判防线**：基准为"应升级"（紧急或触及红线）的反馈中，进入人工确认门的比例 = 100%，无豁免；红线样本 100% 进入人工门，置信度高低不影响红线路由。 - **分母与口径**：一致率分母为回放总数；每次回放记录评估与通知时间戳。 - **抽样核验**：对正常归档结果按 10% 抽样由产品经理复核，漏判率（含安全/数据丢失被误判为正常）< 1%。 - **不打扰**：正常结果 100% 发回执归档（Loop 内留档）、不进入人工队列；紧急/低置信 100% 经过产品经理确认。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅反馈编号、脱敏摘要、分类与置信度等令牌化字段，原值不进入以上任何一层），人工确认界面同样只见脱敏摘要，按 10% 抽查四层实际记录。 - **时效**：紧急反馈从评估到客服收到通知的中位数 < 30 分钟。 ### 复用与变体 - **同构迁移**：客服工单分级、运维告警路由、安全事件初筛。 - **调整抽样比例**：反馈量大时降低、量小时提高，在提示词里说"按 X% 抽样核验正常结果"。 - **双审红线**：对触及安全/数据丢失的反馈强制双审，在提示词里写明。