# SOP-017：知识缺口上报 SOP（v1.3 草案）

> **版本**：v1.3 草案  
> **基线**：SOP-017 v1.2 草案（经 COO 二次复检后定点修订）  
> **起草人**：刘诗妮（secretary）  
> **送审人**：陆怀瑾（COO）  
> **起草日期**：2026-10-29  
> **关联 Issue**：BIZ-158  
> **关联闭环卡**：BIZ-162（检索层不可达）  
> **状态**：草案，待 COO 复检与刘炜承批准；批准且检索层准入验证通过前不替代 v1.0

---

## 0. 修订说明与系统定位

### 0.1 修订背景

v1.0 第 5 节 Step 3 仍指向旧工单通道。v1.1 完成主通道迁移，v1.2 闭合分母口径、流程时序与检索层准入问题；经 COO 二次独立复检，上一轮 6 条已全部闭环。本版进一步修复可复制建单命令的负责人参数、迁移落点与 Multica 完整优先级枚举，并按建议将新上报卡设为 `todo` 以进入看门狗巡检。

### 0.2 系统定位（新增）

| 系统 | 定位 | 用途 | 不承担的职责 |
|------|------|------|--------------|
| **Multica** | **唯一书面真相源与主工单通道** | 任务建单、缺口登记、补全任务、状态与评论回写、闭环追踪 | 无 |
| **Gitea** | 代码与文档版本控制系统 | 代码、配置、方案、报告、记忆的版本控制与审阅 | 不作为工单、知识缺口登记或任务状态跟踪通道 |
| **思源知识库** | 人类浏览与编辑层 | 最终版 SOP、指南、制度 | 不承担工单流转 |
| **memory / wiki** | Agent 查询层 | 知识检索与读取 | 不承担工单流转 |
| **WorkBoard** | 内部执行看板（辅助） | 需要时承载可执行补全卡片；不得取代 Multica issue 作为书面真相源 | 不取代 Multica 记录、状态与评论 |

> **原则**：Multica 优先，Gitea 退位。任何知识缺口只有完成 Multica 建单并回写 issue id，才视为完成“登记”。Gitea commit、PR 或仓库文件均不能替代 issue id。

### 0.3 修订索引

| 评审编号 | 类别 | 落实位置 | 修订结果 |
|---------|------|---------------|----------|
| 阻断 1 | `G` 口径可被刷 | §7.2–§7.4 | `G` 改为周期内发生的缺口事件数；判定源为上报记录与独立巡检的并集；拒绝仍计入 `G`；区分两类 `G=0`；新增反刷分条款 |
| 阻断 2 | 时序倒置 | §5.1–§5.2 Step 2–Step 3 | 调整为记录 → Multica 建单并回写 → 通知 COO（正文含 issue id）→ 审核 |
| 阻断 3 | 批准后仍读不到正文 | §11.1–§11.2 | 新增思源正文同步与双通道命中正文验收；与 BIZ-162 明确绑定 |
| 必改 4 | priority 硬编码 | §5.2 Step 2 | 改为 `<high|medium|low>`，按 §8 判据选择 |
| 必改 5 | 占位符口径不统一 | §10.3 | 明确中文占位词禁止项与尖括号合法范围 |
| 必改 6 | COO sessionKey 未实测 | §5.2 Step 3 | 主键改为 `agent:coo:main`，并要求附送达回执 |
| v1.3 阻断 1 | 建单命令负责人参数不可解析 | §5.2 Step 2 | `--assignee coo` 改为已实测可用的 `--assignee-id 1c38b437-b54d-4784-bda3-29ce4c8a6722`，并给出姓名替代写法 |
| v1.3 必改 1 | 迁移落点错误 | §10、§11.1、§11.3 | 注入与迁移主落点改为各 Agent 的 `AGENTS.md` 知识库章节；`TOOLS.md` 仅作为实际存在时的兼容项 |
| v1.3 必改 2 | priority 枚举覆盖不足 | §5.2 Step 2、§8 | 明确 `urgent/high/medium/low/none` 五个合法值及业务分级映射 |
| v1.3 建议 1 | `backlog` 不进入看门狗巡检 | §5.2 Step 2 | 上报 issue 状态改为 `todo`，确保停滞卡可被巡检拾取 |


---

## 1. 目的

解决知识缺口“发现后无书面登记、无主通道、无法追踪闭环”的问题，使每个影响任务交付的知识缺口都可查询、可审核、可补全、可量化。

---

## 2. 适用范围

全部 Agent（产研线、运营线、职能线），以及负责知识补全的责任人。

---

## 3. 知识缺口定义与判据

### 3.1 定义

**知识缺口** = 执行任务时发现知识库（memory / wiki / 思源）中找不到的、且影响任务交付或决策质量的必要知识。

### 3.2 属于知识缺口的情况

| # | 类型 | 示例 |
|---|------|------|
| 1 | 核心业务数据缺失 | 缺少业务线 KPI 历史、竞品基准或经营口径 |
| 2 | 核心 SOP / 流程文档缺失 | 没有对应流程标准，操作无法一致执行 |
| 3 | 决策依据缺失 | 选型或决策缺少可核验的数据与依据 |
| 4 | 模板 / 指南缺失 | 缺少 PRD、验收、交接等标准模板 |
| 5 | 外部信息缺失 | 需要外部文档、资质或条款且现有知识库无存档 |
| 6 | 技术 / API 文档缺失 | 缺少接口规范、配置说明或操作文档 |
| 7 | Agent 配置 / 技能文档缺失 | 新 Agent 接入缺少必要说明或配置参考 |

### 3.3 什么不算知识缺口

**直接沿用 SOP-017 v1.0 第 3 节“**不属于知识缺口的情况**”，不重复制定替代判据**：

| # | 场景 | 应对方式 |
|---|------|----------|
| 1 | 可通过 `web_search` / `tavily_search` 快速获取的公开信息 | 自行检索 |
| 2 | 可通过 `memory_search` / `wiki_search` 检索到的现有知识 | 自行读取 |
| 3 | 可通过联系对应 Agent 获得的信息 | 直接联系 |
| 4 | Agent 自身职责范围内的常识 | 无需上报 |

补充说明：任务执行中的临时疑问若不影响交付质量或决策准确性，记录在任务评论即可，不构成知识缺口。

---

## 4. 触发条件

完成执行前检索（SOP-016）后，满足以下任一条件即触发上报：

1. `memory_search(corpus=all, ...)`、`wiki_search` 与思源全文搜索均无匹配；
2. 检索有结果，但缺少支撑当前任务或决策的关键环节；
3. 任务执行中发现缺少必要规范、模板、指南、数据或外部存档；
4. 现有口径互相冲突，无法判定应采用哪一项。

> 外部公开信息可快速获取时，按第 3.3 节自行检索，不进入本流程。

---

## 5. 上报流程（Multica 主通道）

### 5.1 流程总览

```text
发现知识缺口
  → Step 1 记录：在当日 memory 日志及当前任务评论中记录
  → Step 2 建单：multica issue create，并在日志/评论回写 issue id
  → Step 3 通知：sessions_send 通知 COO，通知正文包含 issue id
  → Step 4 审核：COO 基于已存在的 issue 审核接受 / 拒绝 / 升级
  → Step 5 补全卡：COO 在 Multica 创建补全任务并关联原上报 issue
  → Step 6 补全：责任 Agent 完成知识补全并提交证据
  → Step 7 闭环：COO 验收、关闭补全任务与原上报 issue，回写结果
```

### 5.2 逐步动作与命令

#### Step 1：记录

**动作**：在 `memory/YYYY-MM-DD.md` 追加标准格式记录；若当前已有 Multica issue 或 WorkBoard 卡片，同时在该任务评论中粘贴同一份记录。

```bash
# 路径示例；按实际日期写入对应文件
memory/YYYY-MM-DD.md
```

记录必须包含第 6 节标准格式、已执行的检索方式与 query、当前任务 id / 标题。不得只写“知识缺失”而没有证据。

#### Step 2：在 Multica 建单并回写 issue id（核心步骤）

**动作**：使用 `multica issue create` 创建“知识缺口上报”书面项；从 stdout 取得 issue identifier（如 `BIZ-123`）后，立即回写当日日志和当前任务评论。**建单成功是通知 COO 的前置条件**，确保 COO 审核时可核到 issue id。

```bash
cat > gap_description.md <<'EOF'
## 📚 知识缺口上报

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

## 已执行的检索
- `memory_search(corpus=all, query="[实际 query]")`：无结果 / 结果不足
- `wiki_search(query="[实际 query]")`：无结果 / 结果不足
- 思源全文搜索 `[实际 query]`：无结果 / 结果不足

## 当前任务
- 任务：[任务标题或 id]

## 验收标准
- [ ] 缺口所需知识已补全并可检索
- [ ] 补全内容含来源、版本 / 生效日期与归档路径
- [ ] 原上报 Agent 已收到闭环通知
EOF

multica issue create \
  --title "知识缺口-<领域>-<关键词>" \
  --description-stdin \
  --assignee-id 1c38b437-b54d-4784-bda3-29ce4c8a6722 \
  --priority <urgent|high|medium|low|none> \
  --status todo \
  < gap_description.md
```

> **负责人参数（v1.3 阻断 1）**：`--assignee` 模糊匹配只认 Agent 姓名，不认角色词 `coo`。本流程固定使用已实测可解析的 COO UUID：`--assignee-id 1c38b437-b54d-4784-bda3-29ce4c8a6722`；若工作区人员记录发生变化，可改用姓名 `--assignee 陆怀瑾`，执行前须确认姓名可解析。禁止使用 `--assignee coo`。
>
> **优先级选择（v1.3 必改 2）**：按 §8 判据从 `<urgent|high|medium|low|none>` 选择。只有阻塞当前任务、无法继续执行时才使用 `high`；`urgent` 是公司级即时处置的保留值，不能替代普通高优。若工作区要求项目归属，应先执行 `multica project list` 确认有效 `<pid>` 后追加 `--project <pid>`，不得臆造 pid。
>
> **状态选择（v1.3 建议 1）**：新上报 issue 使用 `--status todo`，使停滞卡能够进入看门狗巡检；不得以 `backlog` 作为默认状态。

**回写动作**：拿到 issue id 后，将下列内容追加到 `memory/YYYY-MM-DD.md` 和当前任务评论：

```markdown
**Multica 上报 issue id**：[ISS-123]
**建单时间**：[YYYY-MM-DD HH:MM]
```

只有包含 issue id 回写的记录，才计入“知识缺口上报通道是否落地”的分子（见第 7 节）。若建单失败，不得进入 Step 3 正式审核；须在当前任务中记录失败原因，恢复后补建并以补建后的 issue 为唯一审核对象。

#### Step 3：通知 COO

**动作**：通过 `sessions_send` 通知 COO（陆怀瑾），请求审核。**通知正文必须包含 Step 2 取得的 issue id**，使通知、书面记录与审核对象三者一致。

```text
sessionKey: agent:coo:main
```

已实测可达直投键为 `agent:coo:main`。历史飞书直连键 `agent:coo:feishu:coo:direct:ou_9f73b4e54af59f038e2b754793ea0908` 可作为跨通道备用，但以运行时实际可达者为准；每次上报须保留送达回执（发送时间、目标 sessionKey、runId 或可核验的回执标识）。

通知正文必须包含：缺口类型、一句话描述、影响、紧急程度、建议处理方式、已记录位置、已执行的检索证据，以及 **Multica 上报 issue id**。

> 通知不是登记的替代品，COO 审核时以 Step 2 已补建并回写 issue id 的 Multica issue 为准。

#### Step 4：COO 审核

**动作**：COO 核对检索证据、缺口定义、影响范围、紧急程度与建议补全方式，并给出以下结论之一：

- **接受**：进入 Step 5；
- **拒绝**：在原上报 issue 评论中说明理由并关闭；
- **升级**：涉及预算、外部采购、跨部门资源或战略决策时，转刘炜承决策，并在 issue timeline 保留升级记录。

COO 不得仅在飞书消息中口头处置而不在 Multica 留下评论或状态记录。

#### Step 5：创建补全卡（Multica 补全任务）

**动作**：COO 在 Multica 创建补全任务，关联原上报 issue，并设置 stage / 依赖关系。

```bash
cat > gap_remediation.md <<'EOF'
## 补全目标

[说明需要补齐的知识及验收口径]

## 来源与证据

[原上报 issue id、检索证据、缺口影响]

## 验收标准
- [ ] 补全内容可被 memory_search / wiki_search 检索
- [ ] 文档包含版本 / 生效日期、维护者与归档路径
- [ ] 原上报 issue 中回写补全链接并通知原上报 Agent
EOF

multica issue create \
  --title "[知识补全] <缺口主题>" \
  --description-stdin \
  --parent <原上报-issue-id> \
  --stage 1 \
  --assignee <领域责任人> \
  --priority <urgent|high|medium|low|none> \
  < gap_remediation.md
```

说明：

- `<原上报-issue-id>` 与 `<领域责任人>` 必须使用实际值，不得保留尖括号占位符；
- 责任矩阵沿用现行《知识缺口上报 SOP v1.0》第三节；无法匹配时由 COO 明确指派；
- 若同时使用 WorkBoard 承载执行，仍须以该 Multica 补全任务记录状态与验收结果，不得只维护 WorkBoard。

#### Step 6：补全

**动作**：责任 Agent 在补全任务中完成知识产出，并提交可验证证据：

1. 补全文档 / 数据 / 决策记录及其归档路径；
2. 版本号、生效日期、维护者；
3. 检索验证结果（`memory_search` / `wiki_search` 能命中）；
4. 与原上报 issue 的关联说明。

补全任务的状态更新只能在实际完成后进行；不得以“已创建文档”替代“已完成补全”。

#### Step 7：闭环

**动作**：COO 验收补全内容，确认检索可命中、证据齐全后：

1. 在补全任务中回写验收结论、链接和验收人；
2. 在原上报 issue 中回写补全 issue id、验收结论与闭环时间；
3. 按 Multica 流程关闭补全任务及原上报 issue；
4. 通过 `sessions_send` 通知原上报 Agent：

```text
【知识缺口已补全】
原上报 issue：[ISS-123]
补全 issue：[ISS-456]
补全内容：[文档链接或归档路径]
验收结论：[通过 / 需返工]
后续可直接检索使用。
```

闭环的完成标志是：原上报 issue 与补全 issue 均有验收和闭环记录，且原上报 Agent 已收到通知。

---

## 6. 标准上报格式

### 6.1 核心模板（与 BIZ-84、`SOP_知识缺口上报_v1.0.md` 口径一致）

以下五项为必填核心字段：

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

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

### 6.2 登记证据与任务关联（随模板一并记录）

```markdown
## 已执行的检索
- `memory_search(corpus=all, query="[实际 query]")`：[结果]
- `wiki_search(query="[实际 query]")`：[结果]
- 思源全文搜索 `[实际 query]`：[结果]

## 当前任务
- 任务：[任务标题或 id]

## Multica 登记
**Multica 上报 issue id**：[ISS-123]
**建单时间**：[YYYY-MM-DD HH:MM]
```

> 字段顺序可调整；五个核心字段不得删减。issue id 只有在 `multica issue create` 成功后才能填写。

---

## 7. 量化口径与运营指标（改进）

### 7.1 直接计数口径

将知识缺口运营指标从“抽样评论中是否含检索证据”的代理指标，改为直接统计：

> **知识缺口上报通道落地数 = 在日志或任务评论中回写了 Multica issue id 的知识缺口上报记录数。**

### 7.2 分母 `G`：周期内发生的知识缺口事件数

设：

- `G` = **周期内发生的知识缺口事件数**；
- `I` = 周期内含有效 Multica issue id 回写的知识缺口上报记录数。

`G` 的判定源是以下两类记录的**并集**：

1. 上游 Agent 提交的知识缺口上报记录，包括最终被 COO 合理拒绝的上报；
2. 巡检抽样或专项巡检独立发现的、确实影响交付或决策的缺口。

同一缺口在两类来源中出现时按同一事件去重。**被 COO 拒绝的上报仍计入 `G`**，拒绝只改变处理结论，不改变“缺口事件已经发生”的事实。

### 7.3 分子 `I` 与计算规则

```text
通道落地率 = I / G × 100%
```

计数规则：

1. 一条缺口事件对应一个 Multica 上报 issue，按 issue id 去重；
2. 只有日志或任务评论中明确回写该 issue id，才计入 `I`；
3. 仅发消息通知、仅创建 WorkBoard 卡片、仅提交仓库 commit / PR、仅口头上报，均不计入 `I`；
4. 巡检独立发现但尚未建立 Multica issue 的缺口计入 `G`、不计入 `I`；
5. 合理拒绝率作为辅助指标单列：`合理拒绝数 / G × 100%`，不得从 `G` 中扣除；
6. 月度巡检报告须列出：本期 `G`、本期 `I`、合理拒绝数与合理拒绝率、通道落地率、去重后的 issue id 清单及未落地原因。

### 7.4 `G=0` 的两种情形与反刷分条款

`G=0` 时必须按以下两种情形分别留痕：

| 情形 | 判定条件 | 报告口径 |
|------|----------|----------|
| 经检索确认本期确无缺口 | 有独立巡检覆盖，并留存任务量、抽样范围、检索结果与“未发现缺口”结论 | 记为“不适用（经检索确认本期确无缺口）” |
| 本期无上报且无独立巡检覆盖 | 没有上游上报，也没有独立巡检覆盖或可核验抽样 | 记为“无数据（上报通道疑似失效）”，不得记“不适用” |

**反刷分条款**：任一周期若出现“上报数下降但任务数上升”，且月度报告未给出可核验的原因说明，该周期通道落地率标记为**待审**，不得直接计入达标；待审原因补齐并经 COO 核验后方可重新判定。

### 7.5 建议目标

- **通道落地率目标：≥ 80%**；
- **P0 缺口落地率目标：100%**；
- 未落地项须在下一次巡检前完成补建或记录明确豁免原因；
- `G=0` 的“无数据（上报通道疑似失效）”不得视为达标。

---

## 8. 优先级与响应时限

| 业务分级 | Multica priority | 定义 | 建议响应时限 | 建议补全时限 |
|----------|------------------|------|--------------|--------------|
| P0 | `high` | 阻塞当前任务，无法继续执行 | COO 4 小时内响应 | 24 小时内补全 |
| P0-升级 | `urgent` | 公司级重大风险、合规事件或生产故障等需即时处置；由 COO 明确保留使用 | COO 即时响应 | 按专项处置方案执行 |
| P1 | `medium` | 有 workaround，但影响效率或质量 | COO 1 个工作日内响应 | 3 个工作日内补全 |
| P2 | `low` | 当前可正常运行，属于应排期改进的知识缺口 | COO 1 周内响应 | 按排期补全 |
| 记录项 | `none` | 不要求立即响应或排期，仅保留为知识治理记录 | 按月度复查看板处理 | 按 COO 决定 |

> 标准模板中的“紧急程度”仍使用高 / 中 / 低；建单时按上表映射为 Multica 合法枚举。`urgent` 是 P0 的升级通道，不是普通高优的默认替代；`none` 仅用于不要求行动的知识治理记录。

---

## 9. COO 审核标准

| 审核项 | 标准 |
|--------|------|
| 是否真正检索过 | 上报记录包含实际 query 与结果，而非只写“已检索” |
| 是否属于知识缺口 | 对照第 3 节；第 3.3 节四类场景应驳回并引导自行处理 |
| 是否完成 Multica 登记 | 原上报 issue 已创建，issue id 已回写 |
| 优先级是否合理 | 根据影响范围与阻塞程度判断 |
| 补全方式是否可行 | 责任人、产出形式、归档位置和验收标准明确 |
| 闭环是否可验证 | 补全后能通过 `memory_search` / `wiki_search` 命中 |

### 审核结果与处理

| 结果 | 处理方式 |
|------|----------|
| 接受 | 创建关联的 Multica 补全任务并明确责任人 |
| 拒绝 | 在原上报 issue 评论中说明理由，关闭 issue |
| 升级 | 转刘炜承决策，在 issue timeline 与评论中留存记录 |

---

## 10. AGENTS.md 注入模板（同步替换旧流程）

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

> 完整 SOP 见 `specs/SOP-017_知识缺口上报SOP.md`；待 v1.3 批准并完成检索层准入后更新引用版本。本章节应内联到各 Agent 的 `AGENTS.md`“企业知识库”章节；若该 Agent 实际另有独立 `TOOLS.md`，可同步注入，但不得把 `TOOLS.md` 当作唯一落点。

### 触发条件
执行 SOP-016 检索后，满足以下任一条件需上报：
1. 核心业务数据 / SOP / 决策依据缺失；
2. 缺失影响任务交付质量或决策准确性；
3. 无法通过 memory_search / wiki_search / 思源全文搜索获得必要知识。

### 不属于知识缺口的情况
直接引用 SOP-017 v1.0 第 3 节，不另行维护副本。

### 上报流程
1. **记录**：在 `memory/YYYY-MM-DD.md` 与当前任务评论中使用标准格式记录；
2. **建单**：执行 `multica issue create`，并回写 issue id；
3. **通知**：通过 `sessions_send` 通知 COO，正文包含 issue id；
4. **审核与补全**：COO 基于已存在的 issue 审核后创建关联的 Multica 补全任务；
5. **闭环**：COO 验收并关闭 issue，通知原上报 Agent。

### 标准格式
见 SOP-017 第 6 节。核心字段：缺口类型、缺口描述、影响范围、紧急程度、建议补全方式。
```

### 10.3 统一占位符口径

- 交付物正文不得残留任何表示“尚未确定”的中文措辞或英文缩写占位标记；具体禁词以 COO 复检清单为准；
- 尖括号占位符仅允许出现在**可复制执行的命令示例**与**格式模板**中；复制执行前必须替换为实际值；
- `<high|medium|low>` 只能出现在优先级命令示例中，实际值必须按 §8 判据选择；
- 交付复检统一执行 COO 约定的占位词扫描规则：正文禁词命中即不通过；命令示例与格式模板中的尖括号占位符另行人工核验其可替换性。

---

## 11. 生效、迁移与维护

### 11.1 生效条件

本文件为 v1.2 **草案**。以下条件必须全部满足后方可生效：

1. COO 独立复检通过；
2. 刘炜承批准；
3. **依据 BIZ-19《Agent 内容存储与分发标准》把批准后的正文同步入思源知识库**，建议路径 `/规范/SOP-017 知识缺口上报 SOP v1.2`；
4. 同步后实测 `memory_search(query="知识缺口上报 SOP")` 与 `wiki_search(query="知识缺口上报 Multica 建单")` **均命中正文**，而不是仅命中 MEMORY.md 索引条目；
5. 在复检评论贴出两个查询各自的命中路径与正文原文片段，并绑定 BIZ-162 的闭环结果；
6. 生效后以新文件替换现行引用，但不得改写 v1.0 本体或 v1.1 草案，以保留历史基线；
7. 同步更新各 Agent `AGENTS.md`“企业知识库 / 知识缺口上报”章节中的旧上报步骤；仅当某个 Agent 实际存在独立 `TOOLS.md` 时，才同步更新该文件。

### 11.2 检索层准入与 BIZ-162 绑定

BIZ-162 记录的问题是 SOP-017 / SOP-016 正文未进入 Agent 运行时检索层。本版与其明确绑定：

- BIZ-162 是本 SOP 生效前置条件，不得与本 SOP 脱钩；
- 正文同步思源后，须分别执行：
  - `memory_search(query="知识缺口上报 SOP")`；
  - `wiki_search(query="知识缺口上报 Multica 建单")`；
- 两次查询都必须在命中路径中展示正文中的规则片段，例如 Multica 建单、issue id 回写与 Gitea 退位表述；
- 若只命中索引条目、只命中其中一个通道，或思源搜索仍为 0，则 BIZ-162 不得判定闭环，本 SOP 不得生效；
- 复检评论必须记录命中路径、原文片段、查询词和实测时间，作为准入证据。

### 11.3 迁移要求

1. 以各 Agent 的 `AGENTS.md` 为主落点，检查并替换“企业知识库 / 知识缺口上报”章节中的旧上报步骤；不得因不存在独立 `TOOLS.md` 而判定迁移无法执行；
2. 仅对实际存在独立 `TOOLS.md` 的 Agent 同步更新该文件，避免重复维护两份冲突规则；
3. 迁移后逐 Agent 验证 `AGENTS.md` 至少命中一次 `multica issue create`，并命中正确负责人参数与 `issue id` 回写要求；
4. 存量、尚未建 Multica issue 的知识缺口，按本 SOP 第 5 节补建并回写；
5. 已存在的旧仓库 issue 不自动迁移为 Multica issue，但须在巡检报告中列出待补建清单；
6. 对 Multica 建单失败项，保留失败日志，修复后补建，不以旧仓库替代。

### 11.4 维护信息

- **维护人**：COO（陆怀瑾）
- **起草协助**：刘诗妮（secretary）
- **review 周期**：每季度一次，或发生流程通道变更时即时修订
- **基线保留**：`specs/SOP-017_知识缺口上报SOP.md`（v1.0）保持零改写

---

## 12. 版本历史

| 版本 | 日期 | 变更内容 | 审批 |
|------|------|----------|------|
| v1.0 | 2026-07-06 | 初始版本；第 5 节 Step 3 使用旧工单通道 | 刘总 |
| v1.1 草案 | 2026-10-29 | 上报主通道改为 Multica；增加 issue id 回写；统一标准格式；量化改为直接计数；Gitea 退位为版本控制 | COO 复检打回 |
| v1.2 草案 | 2026-10-29 | 闭合 `G` 分母与反刷分口径；纠正建单/通知/审核时序；新增思源入库与双通道正文命中准入；priority 改为分级占位符；统一占位符口径；改用已实测 COO 直投键 | COO 二次复检通过主体、发现 1 阻断 + 2 必改 + 1 建议 |
| v1.3 草案 | 2026-10-29 | 修正建单负责人参数；迁移主落点改为 AGENTS.md；覆盖 Multica 五个 priority 枚举；新上报卡改用 todo 进入看门狗巡检 | 待审 |

---

*本草案承接 BIZ-158，并绑定 BIZ-162 检索层闭环。经 COO 复检、刘炜承批准且第 11.1 节全部准入条件满足前，SOP-017 v1.0 仍为现行基线。*