EnterpriseArchitect/specs/SOP-017_知识缺口上报SOP_v1.1_草案.md

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

版本：v1.1 草案
基线：SOP-017《知识缺口上报 SOP》v1.0（2026-07-06）
起草人：刘诗妮（secretary）
送审人：陆怀瑾（COO）
起草日期：2026-10-29
关联 Issue：BIZ-158
状态：草案，待 COO 审核与刘炜承批准；批准前不替代 v1.0

---

0. 修订说明与系统定位

0.1 修订背景

v1.0 第 5 节 Step 3 仍指向旧工单通道。该流程已与公司现行编排规则不一致，导致知识缺口上报缺少可追踪的书面记录。

0.2 系统定位（新增）

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

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

---

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 流程总览

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

5.2 逐步动作与命令

Step 1：记录

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

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

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

Step 2：通知 COO

动作：通过 sessions_send 通知 COO（陆怀瑾），请求审核；同时保留 Multica 建单动作。

sessionKey: agent:coo:feishu:coo:direct:ou_9f73b4e54af59f038e2b754793ea0908

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

通知不是登记的替代品。若 Step 3 建单失败，应立即在通知中说明失败原因，并在恢复后补建。

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

动作：使用 multica issue create 创建“知识缺口上报”书面项；从 stdout 取得 issue identifier（如 BIZ-123）后，立即回写当日日志和当前任务评论。

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 coo \
  --priority high \
  --status backlog \
  < gap_description.md

优先级口径：高 = 阻塞当前任务；中 = 有 workaround 但影响效率；低 = 可排期改进。若 Multica 当前工作区要求项目归属，应使用 multica project list 确认有效 <pid> 后追加 --project <pid>；不得臆造 pid。

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

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

只有包含 issue id 回写的记录，才计入“知识缺口上报通道是否落地”的分子（见第 7 节）。

Step 4：COO 审核

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

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

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

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

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

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 <high|medium|low> \
  < 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：

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

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

---

6. 标准上报格式

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

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

## 📚 知识缺口上报

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

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

## 已执行的检索
- `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 = 周期内确认的知识缺口总数（每条缺口按唯一上报记录计数）；
• I = 周期内含有效 Multica issue id 回写的知识缺口上报记录数。

则：

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

计数规则：

1. 一条缺口对应一个 Multica 上报 issue，按 issue id 去重；
2. 只有日志或任务评论中明确回写该 issue id，才计入 I；
3. 仅发飞书通知、仅创建 WorkBoard 卡片、仅提交仓库 commit / PR、仅口头上报，均不计入 I；
4. G = 0 时，本周期通道落地率记为“不适用（无知识缺口）”，不得记为 0%；
5. 月度巡检报告须列出：本期 G、本期 I、通道落地率、去重后的 issue id 清单及未落地原因。

7.3 建议目标

• 通道落地率目标：≥ 80%；
• P0 缺口落地率目标：100%；
• 未落地项须在下一次巡检前完成补建或记录明确豁免原因。

---

8. 优先级与响应时限

优先级	定义	建议响应时限	建议补全时限
高 / P0	阻塞当前任务，无法继续执行	COO 4 小时内响应	24 小时内补全
中 / P1	有 workaround，但影响效率或质量	COO 1 个工作日内响应	3 个工作日内补全
低 / P2	当前可正常运行，属于改进建议	COO 1 周内响应	按排期补全

上表的“高 / 中 / 低”用于标准模板和 Multica 优先级；“P0 / P1 / P2”沿用 v1.0 分级语义，两者一一对应，不另行造轮子。

---

9. COO 审核标准

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

审核结果与处理

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

---

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

## 📚 知识缺口上报

> 完整 SOP 见 `specs/SOP-017_知识缺口上报SOP.md`；待 v1.1 批准后更新引用版本。

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

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

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

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

---

11. 生效、迁移与维护

11.1 生效条件

• 本文件为 v1.1 草案，经 COO 审核并由刘炜承批准后方可生效；
• 生效后应以新文件替换现行引用，但不得直接改写 v1.0 本体，以保留历史基线；
• 同步更新各 Agent TOOLS.md 中旧工单通道的上报步骤。

11.2 迁移要求

1. 检查所有 Agent 的 TOOLS.md / AGENTS.md，将“创建旧仓库 Issue 作为上报通道”替换为 Multica 建单并回写 issue id；
2. 存量、尚未建 Multica issue 的知识缺口，按本 SOP 第 5 节补建并回写；
3. 已存在的旧仓库 issue 不自动迁移为 Multica issue，但须在巡检报告中列出待补建清单；
4. 对 Multica 建单失败项，保留失败日志，修复后补建，不以旧仓库替代。

11.3 维护信息

• 维护人：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 退位为版本控制	待审

---

本草案承接 BIZ-158。批准前，SOP-017 v1.0 仍为现行基线。