zk-data-agent/skills/label-master/knowledge/决策流程.md

决策流程

本文件定义 Agent 使用 label-master（标签大师）时的推荐判断顺序。目标是让 Agent 像人工标注同学一样，先判断结构维度，再判断业务标签，最后确定输出格式。

总体顺序

输入理解
  -> 结构维度预判：自动任务 / 多指令 / complex
  -> 业务标签候选：候选召回、领域、标签、高频边界
  -> 输出能力判断：function program / intent / Agent 包装
  -> 组合最终结果
  -> 不确定则向用户确认

不要把所有知识一次性读入。每一步只读取当前需要的索引和候选文件。

1. 输入理解

先提取：

• 当前 query。
• 上下文、前轮对话、设备、端侧信息。
• 用户是否明确要求某种输出格式。
• 用户是在做标签判断、数据生成、badcase 分析，还是标签知识问答。

如果是训练/评测数据生成，额外确认：

• 是否需要 function program。
• 是否需要 intent。
• 是否需要 Agent(tag="xxx") 包装。
• 是否需要 complex、多指令、自动任务字段。

2. 结构维度预判

结构维度不是业务标签，不要混进 Agent(tag="xxx")。

自动任务

如果 query 包含条件触发结构，例如“当/如果/时候/之后/到达/每/一...就”，或者涉及超级任务、自动化、提醒，则读取：

• 索引/维度索引.md
• 判断维度/自动任务判断.md

自动任务判断会给出 condition，并影响后续 subquery 的组织。

多指令

如果 query 包含多个动作、多个设备、并列连接、多个方向调整，或者可能需要拆成多个子任务，则读取：

• 索引/维度索引.md
• 判断维度/多指令判断.md

多指令判断会给出多个 subquery。后续业务标签判断应对每个 subquery 分别进行。

complex

complex 是复杂度判断，独立于业务标签。它可以先粗判，但建议在业务标签和输出形态判断后再最终确认。

读取：

• 判断维度/复杂度/复杂度判断.md
• 如果 query 涉及地图导航、POI 搜索、路线偏好、终点附近、沿途、顺路或多轮路线约束，继续读取 判断维度/复杂度/地图导航.md。这是 complex 维度下的专项条件表，不是新的结构维度；最终仍只输出 complex=false/true。
• 如果 query 涉及车控、IoT 设备控制、生活服务、系统控制、应用控制、图片问答、媒体资源播放，并出现感受/场景/约束/跨应用/视觉推理/模糊资源推断等复杂样式，继续读取 判断维度/复杂度/垂域专项.md。这是 complex 维度下的专项条件表，不是新的结构维度；最终仍只输出 complex=false/true。
• 如果专项条件依赖多轮上下文，必须先确认输入里是否真的提供了上一轮导航上下文；没有上下文时，不要把单轮完整 query 当作多轮次轮。
• 多轮场景里，如果当前轮判断依赖上一轮任务，需要先看上一轮任务的 complex 结果；专项规则明确要求继承时才继承，不要默认所有多轮都继承。

3. 业务标签候选

对原 query 或拆分后的每个 subquery，按下面路径读取知识：

1. 读取 索引/候选召回索引.md，根据 query 的动作、对象、资源、设备快速缩小候选范围。
2. 读取 标签总览.md，确认候选领域。
3. 读取 索引/标签索引.md，找到 2-5 个候选标签。
4. 如果候选命中高频混淆，读取 边界/边界索引.md 和 边界/高频混淆/ 下对应文件。
5. 读取候选标签卡片，例如 标签/地图导航/地图导航.md。
6. 如果仍然不清楚，再读取 边界/领域概览/ 下对应领域文件作为背景补充。

输出业务标签判断时必须说明：

• 推荐标签。
• 候选标签。
• 为什么推荐。
• 为什么排除其他候选。
• 哪些信息还不确定。

注意：边界/领域概览/ 多数来自自动迁移，适合补背景，不适合作为第一判断入口。人工维护的 边界/高频混淆/ 优先级更高。

4. 输出能力判断

业务标签不等于最终 target。判断最终输出格式时读取：

• 判断维度/标注输出形态.md
• 输出能力/README.md
• 输出能力/输出组合规范.md

如果是 function，再读取：

• 输出能力/函数目录.md
• 必要时读取 输出能力/对象目录.md

如果是 intent，再读取：

• 输出能力/意图目录.md

判断重点：

• 这个类别是否已经 function 化。
• function 是否需要参数。
• 参数是否需要先构造 object。
• 这个类别是否只是 intent。
• 当前任务是否要求 Agent(tag="xxx") 包装。
• Agent 字段是否只是承接知识，而不是最终 target。

5. 组合最终结果

单 query + function

CalendarQA(type="DATE",target_time="今天")

单 query + object + function

x0=Location(country="美国",province="华盛顿",city="西雅图")
CalendarQA(type="TIME",target_time="现在",location=x0)

单 query + intent

地图导航

单 query + Agent 包装

Agent(tag="地图导航")

多指令

[
  {
    "condition": null,
    "querys": [
      {"subquery": "关闭卧室的灯", "intent": "设备控制"},
      {"subquery": "定一个明天下午四点的闹钟", "intent": "闹钟计时器"}
    ]
  }
]

自动任务

[
  {
    "condition": "上车时",
    "querys": [
      {"subquery": "打开空调", "intent": "设备控制"}
    ]
  }
]

6. 需要用户确认的情况

以下情况不要硬猜：

• 用户要生成数据，但没说明 target 使用 function program、intent 还是 Agent 包装。
• function 和 intent 都可能满足。
• 旧标签资料里只有 tag，但输出能力目录里没有对应 function 或 intent。
• 多指令和单意图之间存在明显歧义。
• 自动任务和普通定时/延时控制存在冲突。
• complex 维度需要作为数据字段输出，但用户没有定义格式。

推荐提问方式：

我能判断业务标签大概率是“地图导航”，但这批数据的最终 target 还需要确认：
你希望写成 Agent(tag="地图导航")，还是写成具体 function / intent 形式？

7. 推荐输出模板

结构判断：
- 自动任务：否
- 多指令：否
- complex：待确认/false/true

业务标签：
- 推荐：地图导航
- 候选：地图导航、餐饮服务、通用问答
- 排除：餐饮服务，因为 query 明确要求导航动作

输出形态：
- 推荐：Agent 包装 / intent / function program / 待确认
- 候选：Agent(tag="地图导航")；地图导航 intent
- 需要确认：当前任务是否要求 Agent 包装