EnterpriseArchitect/specs/BIZ-84_知识缺口上报 SOP_v1.0.md

# 知识缺口上报 SOP v1.0

> 生效日期：2026-07-06 | 负责人：COO（陆怀瑾） | 审批：刘总 2026-07-06

---

## 一、什么是知识缺口

**知识缺口**指 Agent 在任务执行过程中遇到的、无法通过现有知识库检索到的关键信息缺失，且该缺失会影响任务交付质量或导致决策偏差。

### 1.1 触发条件（满足任一即需上报）

| 场景 | 示例 | 上报优先级 |
|------|------|-----------|
| **核心业务数据缺失** | 某业务线 KPI 无历史记录、竞品分析无基准数据 | 高 |
| **SOP/流程文档不存在** | 需要执行某流程但无标准文档可查 | 高 |
| **关键决策依据缺失** | 需要历史决策记录但检索无结果 | 中 |
| **外部信息无法验证** | 需要核实供应商资质/合同条款但无存档 | 中 |
| **技术文档/API 文档缺失** | 需要调用某系统 API 但无文档 | 中 |
| **Agent 配置/技能文档缺失** | 新 Agent 接入时无 AGENTS.md/SOUL.md 参考 | 低 |

### 1.2 不属于知识缺口的情况

- 可通过 `web_search` / `tavily_search` 快速获取的公开信息 → 自行检索，不上报
- 可通过 `memory_search` / `wiki_search` 检索到的现有知识 → 自行读取，不上报
- 任务执行中的临时疑问（不影响交付） → 记录在任务评论中，不上报
- 可通过联系对应 Agent 获得的信息 → 直接联系，不上报

---

## 二、上报流程

### 2.1 标准流程（5 步）

```
发现知识缺口
    ↓
步骤 1：记录缺口（在任务评论中）
    ↓
步骤 2：通知 COO（飞书消息）
    ↓
步骤 3：COO 评估优先级（高/中/低）
    ↓
步骤 4：创建 WorkBoard 卡片（分配责任人）
    ↓
步骤 5：补全后通知原 Agent（关闭循环）
```

### 2.2 步骤详解

#### 步骤 1：记录缺口

在**当前任务**的 Multica issue 或 WorkBoard 卡片评论中记录：

```markdown
## 📚 知识缺口上报

**缺口类型**：[核心业务数据 | SOP 缺失 | 决策依据 | 外部信息 | 技术文档 | Agent 配置]
**缺口描述**：[具体缺什么，为什么影响任务]
**影响范围**：[哪些任务/决策受影响]
**紧急程度**：[高/中/低]
**建议补全方式**：[需要谁提供 / 需要查什么 / 需要创建什么文档]
```

#### 步骤 2：通知 COO

通过飞书消息通知 COO（陆怀瑾）：

```
【知识缺口上报 - 紧急程度：高/中/低】

任务：[任务标题/ID]
缺口：[一句话概括]
影响：[不补全的后果]
建议：[你希望怎么处理]

请评估并创建补全卡片。
```

**COO 飞书 ID**：`ou_9f73b4e54af59f038e2b754793ea0908`

#### 步骤 3：COO 评估

COO 在收到上报后 **2 小时内** 完成评估：

| 优先级 | 响应时效 | 处理方式 |
|--------|---------|---------|
| **高** | 立即处理 | 创建紧急卡片，分配专人，24h 内补全 |
| **中** | 当日内处理 | 创建常规卡片，纳入排期，48h 内补全 |
| **低** | 3 日内处理 | 纳入知识 backlog，周度批量处理 |

#### 步骤 4：创建补全卡片

COO 通过 WorkBoard 创建知识补全卡片：

- **标题**：`[知识补全] <缺口主题>`
- **描述**：引用原始上报评论
- **assignee**：对应领域负责人（见责任矩阵）
- **priority**：根据评估结果设定
- **labels**：`knowledge`, `gap`, `<领域>`
- **parent**：关联到原任务（可选）

#### 步骤 5：闭环通知

知识补全完成后：

1. 责任人在卡片中上传补全内容（文档链接 / 数据文件 / 决策记录）
2. COO 验收并关闭卡片
3. COO 飞书通知原上报 Agent：
   ```
   【知识缺口已补全】
   
   原缺口：[简述]
   补全内容：[文档链接/说明]
   归档位置：[知识库路径]
   
   后续可直接检索使用。
   ```

---

## 三、责任矩阵（Who to Assign）

| 缺口类型 | 默认责任人 | 备选 |
|---------|-----------|------|
| 业务数据/KPI | marketanalysis（顾析策） | COO |
| SOP/流程文档 | COO（陆怀瑾） | projectmanager |
| 技术/API 文档 | opengineer（严维序） | architect |
| 产品需求/PRD | productmanager（沈路明） | COO |
| Agent 配置/技能 | COO（陆怀瑾） | 对应 Agent |
| 外部信息/供应商 | lawyer（苏慎） | COO |
| 设计/UI 规范 | designer（苏绘锦） | COO |

---

## 四、上报渠道

### 4.1 主渠道：WorkBoard 评论 + 飞书通知

**适用场景**：所有正式知识缺口上报

**操作**：
1. 在原任务评论中记录缺口（格式见 2.2）
2. 飞书通知 COO
3. COO 创建 WorkBoard 卡片跟进

### 4.2 补充渠道：Multica Issue

**适用场景**：
- 任务本身在 Multica 上管理
- 需要技术团队协作的知识补全
- 涉及代码/配置/技术文档的缺口

**操作**：
1. 在原 issue 评论中记录缺口（格式同上）
2. 使用 `multica issue create` 创建补全任务：
   ```bash
   multica issue create \
     --title "[知识补全] <缺口主题>" \
     --description-file gap_description.md \
     --priority <high|medium|low> \
     --assignee <责任人> \
     --label knowledge,gap,<领域>
   ```
3. 飞书通知 COO 备案

### 4.3 紧急通道：直接联系 COO

**适用场景**：高优先级缺口，需立即处理

**操作**：
- 飞书直聊 COO，简要说明缺口和影响
- COO 口头确认后先行处理，事后补卡片

---

## 五、知识库质量监控（COO 职责）

### 5.1 周度巡检

COO 每周五执行：

```bash
# 检查本周新增知识缺口上报数
# 检查补全卡片完成率
# 检查 gap 标签卡片积压情况
```

**指标**：
- 新增缺口数 ≤ 5 个/周（超标需分析根因）
- 补全完成率 ≥ 90%（48h SLA）
- 积压缺口数 ≤ 3 个

### 5.2 月度分析

每月底输出《知识缺口分析报告》：

- 缺口类型分布（哪类最常缺失）
- 根本原因分析（为什么缺失）
- 流程改进建议（如何预防）
- 责任人绩效（补全时效/质量）

---

## 六、纳入 TOOLS.md 模板

所有 Agent 的 `TOOLS.md` 必须包含以下章节（可放在"知识库查询"章节后）：

```markdown
## 📚 知识缺口上报

### 触发条件

遇到以下情况需上报知识缺口（而非自行 web_search）：
1. 核心业务数据/SOP/决策依据缺失
2. 缺失影响任务交付质量或决策准确性
3. 无法通过 memory_search/wiki_search 检索到

### 上报流程

1. **记录**：在任务评论中使用标准格式记录缺口
2. **通知**：飞书通知 COO（ou_9f73b4e54af59f038e2b754793ea0908）
3. **跟进**：COO 评估后创建补全卡片
4. **闭环**：补全后 COO 通知你可直接使用

### 标准格式

```markdown
## 📚 知识缺口上报

**缺口类型**：[核心业务数据 | SOP 缺失 | 决策依据 | 外部信息 | 技术文档]
**缺口描述**：[具体缺什么]
**影响范围**：[哪些任务受影响]
**紧急程度**：[高/中/低]
**建议补全方式**：[希望怎么处理]
```
```

---

## 七、版本历史

| 版本 | 日期 | 变更内容 | 审批 |
|------|------|---------|------|
| v1.0 | 2026-07-06 | 初始版本，建立完整上报流程 | 刘总 |

---

**附件**：
- 知识缺口上报模板（见 2.2）
- 责任矩阵（见第三节）
- TOOLS.md 模板章节（见第六节）