📚 课程目录第1章场景挖掘方法论

场景挖掘方法论：用户意图识别、业务边界划分、触发条件定义

场景挖掘是 Agent 工具调用的起点，决定了后续所有编排、执行与监控的质量。本章聚焦三大核心环节：用户意图识别、业务边界划分与触发条件定义。三者构成一个递进链条——先理解用户要什么，再确定 Agent 能做什么、不能做什么，最后定义什么时候该做什么。

1.1 用户意图识别：从自然语言到结构需求

用户表达的往往是模糊的、隐含的甚至矛盾的请求。意图识别的任务是将这些输入转化为可被 Agent 理解的结构化目标。

步骤清单：意图识别流水线

输入接收 – 收集用户原始文本、语音或行为日志，记录上下文（当前对话历史、场景标签）。
短语级解析 – 抽取关键词、实体、动作词、否定词，形成初始语义框架。
多候选匹配 – 将框架与预先定义的意图模板库进行模糊匹配，生成候选 Intent 列表并排序。
歧义裁决 – 针对排序靠前的候选，通过反问、确认、或对比上下文历史做最终消歧。
结构化输出 – 输出包含意图 ID、槽位值、置信度、关联工具列表的 JSON 对象。

识别方法	适用场景	准确率范围	输入物	输出物
规则匹配（正则/模板）	固定句式、高频简单指令	85%–95%	预编译规则库	意图标记 + 槽位
小样本分类（BERT/RoBERTa）	多样化表达、少量标注样本	80%–90%	推理引擎 + 微调模型	意图 ID + 置信度
大模型零样本（LLM Prompt）	开放域、长尾需求	70%–85%	Prompt 模板 + API	自然语言意图描述 + 槽位
混合方案（规则 + LLM 兜底）	生产环境、高可靠性要求	90%–98%	规则引擎 + 调度器 + LLM	带 fallback 标记的结构化意图

生产建议：不要单独依赖大模型零样本。生产级系统应采用“规则优先 + LLM 兜底”混合策略，将高频意图的识别延迟控制在 50ms 以内，长尾意图由大模型处理但需做超时熔断。

1.2 业务边界划分：划定 Agent 的能力范围

业务边界定义了 Agent 在给定场景中可以访问的数据、可以调用的工具、以及必须遵守的约束。边界过宽会导致不可控行为；边界过窄会使场景无法闭环。

边界划分四要素

数据域 – Agent 允许读取/写入的数据库表、API 端点、文件路径。每个数据域需标注读写权限和脱敏要求。
工具集 – 可调用的函数列表，每个工具需声明参数 schema、返回格式、最大执行时长、并发限制。
约束规则 – 业务规则引擎（如“订单金额超过 10 万必须人工审核”“不允许删除最近 30 天日志”）。
异常委托 – 当边界内无法完成任务时，应抛出特定异常而非自主扩展边界，异常信息应包含扩展建议。

  检查表：边界划分确认清单

  ☐ 每个工具是否都有明确的调用前提和后置条件？

  ☐ 数据域是否按最小权限原则配置？

  ☐ 是否存在“万能工具”绕过所有约束？

  ☐ 异常委托是否指向运维人员 inbox 或指定回调？

  ☐ 边界规则是否可以通过热更新修改而无需重启 Agent？

1.3 触发条件定义：什么时候该做什么

触发条件决定了 Agent 在何时、以何种方式启动一次工具调用。错误的触发条件会导致误调、漏调或死循环。

触发条件分类

类型	典型写法	示例
定时触发	Cron 表达式 / 固定间隔	`0 0 * * *` 每天零点同步订单
事件触发	消息队列消费 / Webhook	Kafka 订单创建事件 → 调用库存工具
状态触发	状态机跃迁 + 守卫条件	订单状态从“已支付”变“已确认”时触发物流查询
复合触发	多个条件 AND / OR / NOT	用户级别 VIP 且未在 5 分钟内响应且策略允许自动退款

定义触发条件时应明确：谓词（条件表达式）、边车数据（上下文快照）、幂等键（防止重复触发）。

常见错误：复合触发条件中条件顺序不当导致竞态。例如“先检查库存再检查用户信用”和“先检查信用再检查库存”在并发场景下结果可能不同。应该在定义时显式声明短路逻辑，或使用事务性状态检查。

场景挖掘总流程

下图将用户意图识别、业务边界划分、触发条件定义串联成一个可操作的工作流，每个节点都对应产出物（文档 / 配置文件 / 测试用例）。

1.4 场景配置实例（YAML 片段）

以下为最终产出的场景配置文件示例，融合了意图 ID、边界约束与触发条件。

# scene_definition.yaml
scene_id: "order_auto_refund"
version: "1.2"
intent_rules:
  - pattern: "退款[我的]订单{order_id}"
    intent: "refund_order"
    slots: ["order_id"]
boundary:
  data_domain:
    - db: "orders"
      operations: ["SELECT", "UPDATE"]
      where: "status = 'paid'"
  tools:
    - name: "refund_gateway"
      max_exec_ms: 3000
      concurrency: 5
  constraints:
    - if: "amount > 100000"
      then: "raise NeedManualReview"
trigger:
  type: "event"
  source: "kafka://order.paid"
  filter: "payment_method == 'credit_card'"
  dedup_key: "event_id"
  timeout_sec: 30

  调试经验：触发条件中的 filter 表达式建议用单元测试覆盖边界值。至少包括：空消息、异常字段、并发重复消息、超时消息。使用 dedup_key 时，应确保消息队列生产者设置了唯一的 event_id，否则幂等机制将失效。

1.5 性能与稳定性要点

意图识别缓存：对高频用户输入（如“查账单”）启用 LRU 缓存，避免重复调用 LLM。
边界规则预编译：将约束规则编译成 AST 或字节码，运行时只需匹配而非解析 YAML。
触发条件熔断：当同一场景被连续触发超过阈值（如 10 次/s），自动降级为间隔 1 秒的节流模式。
配置热加载：场景配置文件应支持监听文件变化或配置中心推送，无需重启 Agent 即可切换边界。