场景挖掘的价值与目标：定义工具调用场景、评估业务收益、确定适用边界
场景挖掘是 Agent 工具调用能力建设的起点，其核心价值在于将模糊的业务需求转化为结构化、可执行、可度量的工具调用场景。缺乏系统化场景挖掘的项目，往往陷入工具数量膨胀但调用准确率低、业务价值无法归因的困境。本章从 SOP 维度建立场景挖掘的价值框架，明确定义场景、评估收益、确定边界三个核心目标的交付标准与操作依据。
中心思想：场景挖掘不是需求堆砌，而是通过结构化方法让每个工具调用场景都具备清晰的触发条件、量化的业务收益和明确的边界约束，从而在 Agent 工程落地前完成风险过滤与价值排序。
1. 适用场景
以下业务情境必须启动系统化的场景挖掘流程，不能跳过或合并到开发阶段中补做。
- 新 Agent 项目立项：需要从零定义工具调用清单时，场景挖掘提供第一版场景基线。
- 存量 Agent 能力扩展：已有工具调用能力但准确率或覆盖率不达标，需要重新收敛场景边界。
- 跨部门工具复用评估：工具被多个业务方申请调用，需统一评估场景优先级与通用性。
- Agent 安全合规审查：涉及敏感数据或高风险操作的工具调用，必须通过场景边界约束来规避越权风险。
- 业务收益争议仲裁：当工具调用链路投入与产出存在分歧时，场景挖掘提供客观的收益评估框架。
2. 前置条件
启动场景挖掘前，组织和项目必须满足以下条件，否则挖掘结果将缺乏可执行基础。
- 业务目标已收敛：项目有明确的季度或年度业务指标（如客服解决率 ≥ 85%、工单处理时长降低 30%）。
- 干系人地图已绘制：至少识别出业务方、技术交付方、运维方三个角色的关键决策人。
- 工具候选清单已初筛：已有初步的候选工具列表（可通过 API 或 SDK 调用的系统能力），且每项工具的功能边界文档可获取。
- 数据采集通道就绪：能获取至少 2 周的业务日志、用户反馈记录或工单样本，用于场景触发条件分析。
- 风险评估基线已建立：组织已有最低安全红线（如禁止调用删除类 API、禁止读取用户明文密码等），场景边界不能突破该基线。
3. 操作步骤
场景挖掘分为 5 个步骤，每一步产出物作为下一步的输入，形成可追踪的 SOP 链路。
- 收集业务需求与用户反馈：从业务方访谈、用户反馈工单、系统操作日志中提取高频、高价值、高痛点的业务事件。输出需求事件清单，按频次和影响范围排序。
-
定义工具调用场景：为每个需求事件建立结构化场景定义，包括触发条件、调用链路、期望产出和约束条件。使用以下 JSON 模板进行标准化记录。
{ "场景名称": "智能客服工单创建", "触发条件": "用户提出需要人工处理的请求，且 Agent 无法通过知识库直接解决", "调用链路": ["verifyUser", "searchKnowledge", "createTicket"], "期望产出": "工单创建成功并分配给对应部门，向用户返回工单编号", "约束条件": { "最大输入 token": 4096, "会话轮次上限": 10, "拒绝策略": "转人工兜底", "敏感字段脱敏": true }, "价值标签": "工单创建效率提升 60%，人工介入率降低 20%" } - 评估业务收益：对每个场景进行量化收益评估。至少包含效率提升（时间/人力节省）、质量改善（准确率/满意度提升）、成本降低（直接运维成本减少）三个维度。收益用绝对值或百分比标注，无法量化的场景标注"定性评估 + 预期方向"。
- 确定适用边界：明确场景的输入范围、输出权限、异常兜底和监控阈值。边界文档必须包含边界违反判定条件和对应处置动作，用于 Agent 运行时的护栏机制。
- 输出场景挖掘报告：将步骤 1-4 的成果汇总为场景挖掘看板，包含场景名称、优先级分、收益评分、边界状态、负责人和计划上线时间。看板作为项目排期的直接依据。
4. SVGs — 场景挖掘价值链路流程
下图将步骤 1-5 映射为可视化价值链路，展示从需求识别到场景就绪的完整推进路径，以及每个阶段的产出物。
最佳实践：在生成场景看板前，先对步骤 2 定义的每个场景做一次 「边界预检」——用边界条件反向推演是否会出现用户请求无法命中任何场景的情况，如果出现，需要补充兜底场景或调整现有场景的触发条件。
5. 输入输出物
| 类型 | 具体内容 | 形式 | 责任方 |
|---|---|---|---|
| 输入 | 业务需求文档、用户反馈记录、系统操作日志（至少 2 周） | 文档 / 数据库导出 / 文本摘要 | 业务分析师 |
| 输入 | 候选工具 API 清单及功能边界说明 | API 文档 / 接口规范 | 技术架构师 |
| 输出 | 场景定义文档（含 JSON 结构化定义） | JSON 文件 / 知识库条目 | 业务分析师 |
| 输出 | 业务收益评估报告（含 ROI 计算表） | 电子表格 / 数据看板 | 产品经理 |
| 输出 | 工具调用边界文档（含违反判定与处置） | Markdown / 决策树图 | 技术架构师 |
| 输出 | 场景挖掘看板（含优先级与排期） | 项目管理工具 / 看板 | 项目经理 |
6. 责任边界
| 角色 | 职责范围 | 交付物 | 协作接口 |
|---|---|---|---|
| 业务分析师 | 需求收集、场景定义、用户反馈分析 | 场景定义文档 | 向产品经理提供场景收益评估所需的原始数据 |
| 技术架构师 | 工具能力调研、边界条件编写、技术可行性确认 | 边界文档 | 向业务分析师反馈工具能力约束 |
| 产品经理 | 收益量化、优先级排序、价值归因 | 收益评估报告 | 向项目经理提供场景看板排序依据 |
| 项目经理 | 流程推进、看板维护、异常升级协调 | 场景挖掘看板 | 统筹所有角色的交付节奏 |
| 业务方（需求提出者） | 确认场景定义与边界是否符合业务实际 | 确认签字 / 评审意见 | 对场景的真实性负最终责任 |
7. 记录材料
- 场景挖掘工作记录表：每次调研访谈的日期、参与者、核心结论和待办事项，用于追溯需求变更源头。
- 场景定义模板（JSON Schema）：统一的结构化模板，确保所有场景的字段完整、格式可解析，支持后续自动化校验。
- 收益评估草算表：包含效率、质量、成本三个维度的原始数据、计算公式和最终评分，供评审会质疑时查验。
- 边界变更日志：边界条件一旦调整，必须记录变更原因、变更前后对比和审批人，防止边界无管控放宽。
- 场景挖掘看板截图：每个里程碑节点保留看板快照，用于项目复盘和场景覆盖率趋势分析。
常见陷阱：不要将「需求事件清单」直接当作「场景定义」使用。需求事件是原始素材，场景定义必须经过结构化和边界约束处理。跳过这一步会导致后续 Agent 工具调用时出现触发条件重叠或遗漏，修复成本远高于挖掘阶段的投入。
8. 异常处理
| 异常现象 | 可能原因 | 处理措施 | 升级路径 |
|---|---|---|---|
| 需求事件清单超过 50 条，无法收敛 | 业务目标不聚焦，干系人未对齐优先级 | 重新召开目标对齐会，按季度业务指标筛选 Top 15 事件 | 项目经理 → 业务负责人 |
| 场景收益无法量化（缺少基准数据） | 目标业务场景尚未有历史数据积累 | 标注「定性评估」并给出预期方向，同时设立数据采集期（2 周） | 产品经理 → 数据团队 |
| 工具边界与业务需求冲突 | 工具 API 能力无法满足场景触发条件 | 输出冲突清单，由技术架构师评估工具改造方案或替换工具 | 技术架构师 → 技术负责人 |
| 干系人对场景优先级存在重大分歧 | 利益归属不同，缺乏统一评分标准 | 使用权重大法：效率提升 40% + 成本降低 30% + 用户体验 30% 综合评分 | 项目经理 → 产品负责人 |
| 场景挖掘时间超过预期排期 | 需求范围蔓延或前置数据未就绪 | 冻结当前已完成的场景，未完成的场景推迟到下一迭代 | 项目经理 → 项目委员会 |
9. 验收标准
- 场景定义完整性：每个场景均包含触发条件、调用链路、期望产出、约束条件四个字段，缺一不可。
- 收益可追溯性：效率、质量、成本三个维度至少有两个维度有量化数据或明确的定性评估方向，且评估依据可查阅原始数据源。
- 边界可执行性：每个边界条件都配有违反判定逻辑和对应的处置动作（如拒绝、转人工、降级），并能通过评审会的模拟推演测试。
- 干系人确认：业务方、技术方、产品方三方在场景看板上签字确认，无遗留争议项。
- 看