第4章 典型场景故事板：客服流转、数据ETL、审批自动化

4.1 为什么是这三个场景

场景故事板是需求分析的“第一现场”。本章选取企业级 Agent 任务编排中最具代表性的三类场景，分别覆盖「人机协作」（客服流转）、「数据管道」（数据ETL）和「规则驱动」（审批自动化）。三个场景在触发方式、节点类型、分支逻辑、异常处理四个维度上形成完整互补，适合作为原型设计的通用参考基线。

4.2 客服流转场景

4.2.1 用户场景与业务问题

用户角色：客服主管 张敏（8年经验，管理15人客服团队）
典型场景：每日 8:00–22:00 用户通过在线渠道提交咨询、投诉、售后请求。团队需在 30 秒内响应，但重复问题占 62%，人工回复效率低，夜间时段响应超时率达 41%。

核心业务问题：

• 重复消耗：高频常见问题（账单查询、密码重置等）占用客服 70% 工时，团队疲于应付。
• 响应延迟：人工切换系统查询平均耗时 45 秒，超出客户期望的 15 秒。
• 流转断裂：复杂问题需转接 2-3 次，客户重复描述，体验差。
• 知识滞后：知识库更新后客服未同步，回复一致性仅 73%。

4.2.2 用户访谈与需求拆解

需求拆解表：

需求编号	用户陈述	需求拆解	优先级
CS-R01	“常见问题自动回复就行”	意图识别 + 知识库匹配 + 自动生成回复	P0
CS-R02	“复杂 case 转人工时带上下文”	会话摘要生成 + 流转信息附着	P0
CS-R03	“夜间要有人值守兜底”	时段策略 + 升级报警 + 移动端提醒	P1
CS-R04	“新知识能快速生效”	知识库热加载 + 版本回滚	P1

4.2.3 方案表达与编排设计

Agent 任务编排采用「意图路由+分级处理」模式：用户消息进入后先经过 NLU 意图分类，高置信度常见问题直接走知识库自动回复；低置信度或情感负面问题升级人工。升级时自动携带会话摘要和已尝试方案，减少人工重复阅读。

核心编排步骤（伪配置）：

{
  "scene": "客服流转",
  "trigger": "用户消息事件",
  "steps": [
    { "id": "intent_classify", "type": "NLU", "output": "intent_label" },
    { "id": "confidence_check", "type": "condition",
      "if": "confidence > 0.85 && intent in FAQ_LIST",
      "then": "goto auto_reply",
      "else": "goto human_escalate" },
    { "id": "auto_reply", "type": "knowledge_retrieval",
      "source": "kb_v2", "return": "answer_text" },
    { "id": "human_escalate", "type": "agent_transfer",
      "attach": ["summary", "attempted_steps"] }
  ]
}

4.2.4 指标验证与验收标准

指标名称	当前基线	目标值	验证方式
首次响应时长（中位数）	32 秒	≤ 8 秒	埋点采样 1000 次
自动解决率	0%	≥ 55%	会话标记 + 人工抽检
升级后重复描述率	78%	≤ 15%	人工质检 200 条
知识库命中率	62%	≥ 85%	日志统计

验收标准：

• Agent 自动回复内容与人工标准答案一致率 ≥ 95%（抽检 200 条）。
• 升级人工时附带的上下文摘要完整率 ≥ 90%（含问题描述、已尝试步骤、客户情绪标签）。
• 系统支持知识库热更新，生效延迟 ≤ 5 分钟。

4.2.5 交付物模板

输出《客服流转 Agent 任务编排规格说明书》，包含：

• 意图-动作映射表（intent → action 矩阵）
• 会话摘要生成规范（字段定义+示例）
• 升级条件与路由策略配置表
• 人工兜底值班时段表

4.3 数据ETL场景

4.3.1 用户场景与业务问题

用户角色：数据工程师 李铭（5年经验，维护 6 个业务系统数据管道）
典型场景：每日凌晨 2:00-5:00 从 CRM、ERP、WMS 等系统抽取增量数据，清洗后加载到分析数仓。任务链中任一环节失败需人工恢复，平均每月发生 3-4 次断流事故。

核心业务问题：

• 串行依赖脆弱：抽取→清洗→加载串行执行，单点失败整个管道阻塞。
• 恢复耗时：失败后平均恢复耗时 47 分钟，影响早间报表产出。
• 数据质量不可见：脏数据直到下游消费时才暴露，溯源困难。
• 扩容困难：数据量月增 12%，现有管道无弹性伸缩能力。

4.3.2 用户访谈与需求拆解

需求拆解表：

需求编号	用户陈述	需求拆解	优先级
ETL-R01	“失败能自动重试，别老半夜叫我”	任务级重试策略 + 指数退避 + 最大重试次数	P0
ETL-R02	“脏数据跳过但要记录”	异常数据隔离 + 错误日志持久化 + 事后兜底修复	P0
ETL-R03	“能看见每一步的进度”	任务链路可视化 + 实时指标看板	P1
ETL-R04	“新数据源能快速接入”	插件化连接器 + 配置式 schema 映射	P2

4.3.3 方案表达与编排设计

采用「DAG 编排 + 容错泳道」架构：每个 ETL 步骤封装为独立节点，失败后根据策略自动重试或跳过；脏数据被路由到异常队列，不阻塞主流程；所有节点状态实时上报到监控看板。

核心编排步骤（伪配置）：

{
  "scene": "数据ETL",
  "trigger": "cron: 0 2 * * *",
  "steps": [
    { "id": "extract_crm", "type": "connector", "source": "CRM_API",
      "retry": { "max": 3, "backoff": "exponential" } },
    { "id": "extract_erp", "type": "connector", "source": "ERP_DB",
      "retry": { "max": 3, "backoff": "exponential" } },
    { "id": "merge_and_clean", "type": "transform",
      "depends_on": ["extract_crm", "extract_erp"],
      "on_failure": "skip_and_log" },
    { "id": "load_dw", "type": "writer", "target": "DWH_TABLE",
      "depends_on": ["merge_and_clean"] }
  ]
}

4.3.4 指标验证与验收标准

指标名称	当前基线	目标值	验证方式
管道成功率	87%	≥ 99.5%	30 天连续运行统计
失败恢复时长（P95）	47 分钟	≤ 5 分钟（自动）	注入故障测试
数据延迟	6 小时	≤ 30 分钟	端到端时间戳比对
脏数据捕获率	无	≥ 98%	已知脏数据注入测试

验收标准：

• 单节点失败后自动重试 3 次，重试间隔符合指数退避策略（1s→4s→9s）。
• 脏数据被隔离至 error_queue，不影响下游节点，且保留原始记录用于修复。
• 监控看板展示每个节点的状态、耗时、输入/输出行数，刷新间隔 ≤ 5 秒。

4.3.5 交付物模板

输出《ETL 任务编排配置模板》与《数据源注册表》，包含：

• DAG 节点定义规范（type/input/output/retry 字段）
• 连接器插件注册表（数据源类型、连接参数、schema 映射）
• 异常数据隔离策略文档
• 监控指标看板设计稿

4.4 审批自动化场景

4.4.1 用户场景与业务问题

用户角色：行政总监 王涛（15年经验，负责跨部门审批流程优化）
典型场景：采购审批、合同审批、报销审批等 20+ 流程，涉及 3-5 个部门串行签批。纸质流转平均耗时 4.2 天，且常因某节点负责人出差而卡住。

核心业务问题：

• 流转效率低：串行审批导致总耗时 = 各节点耗时累加，瓶颈节点放大延迟。
• 规则僵化：所有申请走同一路径，小额审批与大额审批无差异。
• 缺乏可见性：申请人无法实时知道审批进度，频繁催办。
• 合规风险：纸质签批难以追溯，审计时需人工翻阅档案。

4.4.2 用户访谈与需求拆解

需求拆解表：

需求编号	用户陈述	需求拆解	优先级
AP-R01	“小额和大额审批分开走”	金额阈值路由 + 分级审批链配置	P0
AP-R02	“卡住时自动提醒或转交”	超时策略 + 自动转交 + 移动端推送	P0
AP-R03	“能看到当前到哪一步了”	审批进度查询 API + 进度看板	P1
AP-R04	“审计时能全链路追溯”	操作日志 + 审批链快照 + 电子签章	P1

4.4.3 方案表达与编排设计

设计「规则引擎 + 并行网关」模式：申请提交后，规则引擎根据金额、类型、部门等字段动态匹配审批链；支持并行节点（会签/或签）、串行节点、条件跳过节点；超时自动转交上级或备选审批人。

核心编排步骤（伪配置）：

{
  "scene": "审批自动化",
  "trigger": "审批申请提交事件",
  "steps": [
    { "id": "rule_router", "type": "decision_table",
      "rules": [
        { "if": "amount < 5000", "then": "direct_approve" },
        { "if": "amount >= 5000 && amount < 50000", "then": "parallel_review" },
        { "if": "amount >= 50000", "then": "serial_review" }
      ] },
    { "id": "parallel_review", "type": "parallel",
      "branches": ["finance_check", "dept_manager_approve"],
      "completion": "all" },
    { "id": "serial_review", "type": "sequence",
      "steps": ["vp_approve", "ceo_approve"],
      "timeout": { "duration": "48h", "action": "escalate" } }
  ]
}

4.4.4 指标验证与验收标准

指标名称	当前基线	目标值	验证方式
审批周期（中位数）	4.2 天	≤ 1.5 天	200 条样本统计
自动分流准确率	无	≥ 99%	规则引擎 + 人工复核
超时自动转交率	0%	100%	注入超时场景测试
审计追溯完整度	60%	100%	全量日志比对

验收标准：

• 规则引擎支持 10+ 维度（金额、部门、紧急度、地区）组合路由，变更配置后实时生效。
• 并行审批节点中任一分支超时 48 小时，自动转交该分支的上级审批人。
• 审批全链路日志包含：操作人、动作、时间戳、审批链快照，不可篡改。

4.4.5 交付物模板

输出《审批流编排模板》与《审批规则配置表》，包含：

• 审批链模板（串行/并行/条件分支的节点定义）
• 决策规则配置表（if-then 矩阵，支持多条件组合）
• 超时与转交策略配置
• 审计日志规范（字段定义 + 存储周期）

4.5 三类场景对比与设计启示

将三个场景的关键维度横向对比，提炼 Agent 任务编排的通用设计模式。

对比维度	客服流转	数据ETL	审批自动化
触发方式	事件触发（用户消息）	定时触发（cron）	事件触发（申请提交）
核心编排原语	条件分支 + 人工升级	DAG 并行 + 重试 + 异常隔离	决策路由 + 并行/串行网关 + 超时转交
失败处理策略	升级人工兜底	自动重试 → 跳过 → 告警	超时转交 → 升级上级
状态可见性需求	会话摘要 + 流转记录	节点级进度 + 指标看板	审批进度 + 全链路日志
关键非功能需求	低延迟（秒级）	高吞吐 + 数据一致性	合规追溯 + 不可篡改