陆怀瑾(COO)
a3bf8243b4
- 定义知识缺口触发条件（6类场景） - 明确5步上报流程（记录→通知COO→评估→建卡→闭环） - 双渠道上报（WorkBoard评论+飞书 / Multica issue） - 责任矩阵：7类缺口对应责任人 - 质量监控指标：周度巡检+月度分析 - 已更新全部16个Agent TOOLS.md Co-authored-by: multica-agent <github@multica.ai>
7.2 KiB
7.2 KiB
知识缺口上报 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 卡片评论中记录：
## 📚 知识缺口上报
**缺口类型**：[核心业务数据 | 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：闭环通知
知识补全完成后：
- 责任人在卡片中上传补全内容（文档链接 / 数据文件 / 决策记录）
- COO 验收并关闭卡片
- 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 评论 + 飞书通知
适用场景：所有正式知识缺口上报
操作：
- 在原任务评论中记录缺口（格式见 2.2）
- 飞书通知 COO
- COO 创建 WorkBoard 卡片跟进
4.2 补充渠道：Multica Issue
适用场景：
- 任务本身在 Multica 上管理
- 需要技术团队协作的知识补全
- 涉及代码/配置/技术文档的缺口
操作：
- 在原 issue 评论中记录缺口（格式同上）
- 使用
multica issue create创建补全任务：multica issue create \ --title "[知识补全] <缺口主题>" \ --description-file gap_description.md \ --priority <high|medium|low> \ --assignee <责任人> \ --label knowledge,gap,<领域> - 飞书通知 COO 备案
4.3 紧急通道：直接联系 COO
适用场景：高优先级缺口，需立即处理
操作：
- 飞书直聊 COO，简要说明缺口和影响
- COO 口头确认后先行处理，事后补卡片
五、知识库质量监控（COO 职责）
5.1 周度巡检
COO 每周五执行：
# 检查本周新增知识缺口上报数
# 检查补全卡片完成率
# 检查 gap 标签卡片积压情况
指标：
- 新增缺口数 ≤ 5 个/周（超标需分析根因）
- 补全完成率 ≥ 90%（48h SLA）
- 积压缺口数 ≤ 3 个
5.2 月度分析
每月底输出《知识缺口分析报告》：
- 缺口类型分布（哪类最常缺失）
- 根本原因分析（为什么缺失）
- 流程改进建议（如何预防）
- 责任人绩效（补全时效/质量）
六、纳入 TOOLS.md 模板
所有 Agent 的 TOOLS.md 必须包含以下章节（可放在"知识库查询"章节后）：
## 📚 知识缺口上报
### 触发条件
遇到以下情况需上报知识缺口（而非自行 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 模板章节（见第六节）