# submit_feedback 触发规则

## 概述

本文档定义了 `submit_feedback` 工具的强制触发机制和信息补全引导规则。

## 核心原则

### 触发原则
- **零容忍机制**：符合触发条件时必须100%触发反馈上报
- **优先级最高**：反馈上报优先级高于其他任务处理
- **立即暂停**：发现问题后立即暂停当前任务流程

### 信息补全原则
- **禁止编造**：严禁模型自行编造或猜测缺失的参数值
- **引导补全**：必须引导用户提供缺失的必要信息

## 触发条件

### 1. 工具缺失（category=tool_not_found）
**标准**：用户请求的功能在当前工具集中完全不存在

### 2. 工具报错（category=tool_error）
**标准**：任何工具调用返回非成功状态（错误码 ≠ 0）

### 3. 能力不足（category=tool_inadequate）
**标准**：工具存在但参数限制或功能范围无法满足用户需求

### 4. 结果不符预期（category=unexpected_result）
**标准**：工具调用成功但返回结果与用户预期明显不一致

### 5. 改进建议（category=suggestion）
**标准**：发现工具集有明显改进空间或新增功能需求

## 参数补全引导规则

### 引导流程
```
检测到参数不全 → 明确告知缺失信息 → 引导用户补充 → 用户提供信息 → 调用submit_feedback
                                 ↘ 用户无法提供 → 暂不上报，记录原因
```

### 条件必填参数
- **category=tool_error**：必须引导用户提供 `tool_name` 和 `error_code`
- **category=tool_inadequate/unexpected_result**：必须引导用户提供 `tool_name`
- **intent描述不清**：引导用户明确描述原本想完成什么任务

## 触发流程

### 标准流程
1. **检测问题**：识别符合触发条件的情况
2. **暂停任务**：立即暂停当前任务处理
3. **明确描述**：清晰描述发现的具体问题
4. **询问上报**：使用固定句式"检测到[具体问题]，是否需要通过submit_feedback上报反馈以改进工具集？"
5. **用户确认**：获得用户明确同意后调用工具
6. **继续任务**：根据用户选择继续或取消原任务

## 示例场景

### ✅ 正确引导示例
**用户**："我要反馈工具报错"
**模型**："检测到工具报错问题，需要上报反馈。请提供以下信息：
1. 具体是哪个工具报错？（tool_name）
2. 返回的错误码是什么？（error_code）
3. 您原本想完成什么任务？（intent）"

### ❌ 错误行为示例
**用户**："我要反馈工具报错"  
**模型**："检测到工具报错问题，将为您上报反馈（假设是get_meeting工具，错误码9042）" ← **禁止自行编造**

## 注意事项

### 内容规范
- **客观性**：如实描述问题，禁止主观判断
- **最小化**：仅包含必要信息，遵循隐私保护
- **防滥用**：同一问题单次会话只上报一次

### 隐私保护
- 反馈内容必须严格按隐私政策完成脱敏
- 严禁包含未脱敏的隐私信息

## 输出规范

### 成功上报
```
已通过submit_feedback记录该反馈（反馈ID：xxxxx），我们将持续改进工具集。
```

### 用户拒绝
```
已取消反馈上报，将继续处理原任务。
```

### 信息不全引导
```
检测到反馈信息不全，需要您补充以下信息才能上报：
- [缺失的具体参数和说明]
请提供相关信息后重新尝试反馈。
```