plans(BIZ-89): 淘宝+聚水潭自动化运营方案设计 v1.0

- 整体架构: 淘宝千牛 ↔ 自动化中间层 ↔ 聚水潭ERP - 5阶段实现路径: 调研→对接→开发→测试→部署 - 团队资源: 6角色约220工时 - 风险评估: 接口/反爬/安全/合规关联 issue: BIZ-89 提交人: 陆怀瑾(COO) Co-authored-by: multica-agent <github@multica.ai>
BIZ-84: 知识缺口上报 SOP v1.0
2026-07-11 05:02:54 +08:00 · 2026-07-07 16:12:40 +08:00 · 2026-07-06 05:37:36 +08:00
4 changed files with 773 additions and 0 deletions
@@ -0,0 +1,168 @@
+# 淘宝 + 聚水潭自动化运营方案设计
+
+## 1. 方案思路
+
+### 1.1 整体架构
+
+```
+┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
+│   淘宝千牛平台   │ ←─→ │  自动化中间层    │ ←─→ │   聚水潭 ERP     │
+│  - 商品管理      │     │  - API 适配层     │     │  - 订单管理      │
+│  - 订单管理      │     │  - 数据同步引擎   │     │  - 库存管理      │
+│  - 库存管理      │     │  - 任务调度器    │     │  - 采购管理      │
+│  - 客服消息      │     │  - 监控告警      │     │  - 财务报表      │
+└─────────────────┘     └──────────────────┘     └─────────────────┘
+                              ↓
+                    ┌──────────────────┐
+                    │   数据存储层      │
+                    │  - SQLite/MySQL   │
+                    │  - Redis 缓存     │
+                    │  - 日志系统       │
+                    └──────────────────┘
+```
+
+### 1.2 数据采集方式
+
+| 数据源 | 推荐方式 | 理由 |
+|--------|----------|------|
+| 淘宝千牛 | **浏览器自动化 (opencli)** | 千牛工作台无开放 API，需模拟登录操作 |
+| 聚水潭 | **API 对接优先** | 聚水潭提供开放 API，稳定可靠 |
+| 备用方案 | 浏览器自动化 | API 受限时的降级方案 |
+
+### 1.3 自动化流程设计
+
+**核心流程**：
+1. **订单同步**：淘宝订单 → 聚水潭（实时/定时）
+2. **库存同步**：聚水潭库存 → 淘宝（避免超卖）
+3. **商品管理**：批量上下架、价格调整
+4. **数据报表**：销售分析、库存周转、利润核算
+
+---
+
+## 2. 实现路径
+
+### 阶段 1：前期调研（1-2 周）
+
+| 任务 | 负责人 | 交付物 |
+|------|--------|--------|
+| 淘宝 opencli adapter 开发 | costcodev | `taobao-qiniu-adapter.ts` |
+| 聚水潭 API 能力评估 | architect | 《聚水潭 API 调研报告》 |
+| 反爬策略分析 | costcodev | 风险评估文档 |
+| 技术选型确认 | architect | 架构决策记录 ADR |
+
+### 阶段 2：系统对接（2-3 周）
+
+| 任务 | 负责人 | 交付物 |
+|------|--------|--------|
+| 淘宝千牛数据读取模块 | costcodev | 可运行脚本 |
+| 聚水潭 API 封装库 | costcodev | `jushuitan-sdk` |
+| 数据同步中间件 | costcodev | 核心同步引擎 |
+| 数据库 schema 设计 | architect | ER 图 + 建表脚本 |
+
+### 阶段 3：核心功能开发（3-4 周）
+
+| 任务 | 负责人 | 交付物 |
+|------|--------|--------|
+| 订单自动同步 | costcodev | 订单同步模块 |
+| 库存自动同步 | costcodev | 库存同步模块 |
+| 商品批量管理 | costcodev | 商品管理模块 |
+| 报表生成引擎 | costcodev | 数据报表模块 |
+| Web 控制台 | designer + costcodev | 管理后台 UI |
+
+### 阶段 4：测试验证（1-2 周）
+
+| 任务 | 负责人 | 交付物 |
+|------|--------|--------|
+| 功能测试 | coo + taobaospecialist | 测试报告 |
+| 稳定性测试 | opengineer | 压力测试报告 |
+| 数据一致性校验 | coo | 校验脚本 + 报告 |
+| 安全审计 | opengineer | 安全评估报告 |
+
+### 阶段 5：部署上线（1 周）
+
+| 任务 | 负责人 | 交付物 |
+|------|--------|--------|
+| 生产环境部署 | opengineer | 部署文档 |
+| 监控告警配置 | opengineer | Grafana 面板 |
+| 运维交接 | opengineer | 运维 SOP |
+| 用户培训 | coo | 使用手册 |
+
+---
+
+## 3. 团队资源需求
+
+| 角色 | 工时估算 | 职责 |
+|------|----------|------|
+| **architect 梁思筑** | 20h | 架构设计、技术选型、ADR 撰写 |
+| **costcodev 徐聪** | 120h | 核心开发（API 对接、同步引擎、Web 后台） |
+| **designer 苏绘锦** | 16h | Web 控制台 UI 设计 |
+| **opengineer 严维序** | 24h | 部署、监控、运维 SOP |
+| **taobaospecialist 陆云帆** | 16h | 业务需求输入、流程验证、UAT 测试 |
+| **coo 陆怀瑾** | 24h | 项目管理、风险评估、进度跟进 |
+
+**总工时**：约 220 小时（约 5.5 人周）
+
+---
+
+## 4. 风险与约束
+
+### 4.1 接口限制
+
+| 风险 | 影响 | 应对措施 |
+|------|------|----------|
+| 淘宝 API 调用频率限制 | 数据同步延迟 | 请求队列 + 令牌桶限流 |
+| 聚水潭 API 权限不足 | 部分功能无法实现 | 申请高级权限或改用浏览器自动化 |
+
+### 4.2 反爬机制
+
+| 风险 | 影响 | 应对措施 |
+|------|------|----------|
+| 淘宝风控检测 | 账号被封禁 | 1. 使用真实 Cookie 2. 限制操作频率 3. 添加人工操作混淆 |
+| 登录态失效 | 自动化中断 | Token 自动刷新 + 失效告警 |
+
+### 4.3 数据安全
+
+| 风险 | 影响 | 应对措施 |
+|------|------|----------|
+| 账号密码泄露 | 严重安全事故 | 1. 使用密钥管理服务 2. 环境变量存储 3. 权限隔离 |
+| 数据传输未加密 | 中间人攻击 | HTTPS + 数据加密传输 |
+
+### 4.4 平台稳定性
+
+| 风险 | 影响 | 应对措施 |
+|------|------|----------|
+| 聚水潭接口变更 | 功能失效 | 1. 接口版本监控 2. 快速适配机制 |
+| 淘宝页面结构变更 | 选择器失效 | 1. 多选择器备用 2. 定期巡检更新 |
+
+### 4.5 合规风险
+
+| 风险 | 影响 | 应对措施 |
+|------|------|----------|
+| 违反淘宝服务条款 | 店铺处罚 | 1. 评估自动化操作合规性 2. 控制操作频率在合理范围 3. 保留人工审核环节 |
+
+---
+
+## 5. 下一步行动
+
+1. **立即启动**：architect 开始聚水潭 API 调研
+2. **并行推进**：costcodev 开发淘宝 opencli adapter
+3. **周会同步**：每周五同步进展，识别阻塞点
+4. **里程碑**：阶段 1 结束后进行方案复审
+
+---
+
+## ⚠️ 安全提示
+
+**严禁在代码/配置文件中明文存储账号密码！**
+
+正确做法：
+```bash
+# 使用环境变量
+export TAOBAO_ACCOUNT=$(vault read -field=value secret/taobao/account)
+export TAOBAO_PASSWORD=$(vault read -field=value secret/taobao/password)
+```
+
+或使用密钥管理服务（如 HashiCorp Vault、AWS Secrets Manager）。
+
+---
+提交人：陆怀瑾（COO）| 提交时间：2026-07-11 | 关联 issue：BIZ-89
@@ -0,0 +1,252 @@
+# 知识缺口上报 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 模板章节（见第六节）
@@ -0,0 +1,159 @@
+# SOP-016：执行前检索 SOP 强制规则
+
+> **版本**: v1.0  
+> **起草人**: 胡蓉（projectmanager）  
+> **批准人**: 刘炜承  
+> **生效日期**: 2026-07-06  
+> **关联 Issue**: BIZ-81
+
+---
+
+## 1. 目的
+
+解决 BIZ-45 巡检发现的 Agent 知识库调用率极低问题（徐聪 0%、诗妮 0%、沈路明 33%）。知识库已建立 SOP 但 Agent 不主动检索，导致重复造轮子、忽略历史经验、决策缺乏依据。
+
+---
+
+## 2. 适用范围
+
+全部 Agent（产研线 + 运营线 + 职能线），共 14 个。
+
+---
+
+## 3. 触发条件（任一触发即必须检索）
+
+| # | 触发场景 | 说明 |
+|---|----------|------|
+| 1 | 接收新任务 | WorkBoard 认领 / Multica Issue / TODO.md 分派 / session_send 任务 |
+| 2 | 任务涉及已知业务领域 | 开发/部署/运营/设计/内容/法务/市场等 |
+| 3 | 需要技术选型、流程设计、资源分配决策 | 需参考历史方案 |
+| 4 | 遇到不确定如何处理的问题 | 需查找是否有 SOP 或历史经验 |
+
+---
+
+## 4. 检索流程（严格执行）
+
+```
+开始任务
+    ↓
+Step 1: memory_search(corpus=all, query="<业务类型> SOP/历史经验")
+    ↓
+Step 2: 如有匹配 → memory_get / wiki_get 读取详细内容
+    ↓
+Step 3: 如无匹配 → wiki_search(query="<任务关键词>")
+    ↓
+Step 4: 仍无匹配 → exec curl 思源知识库全文搜索
+    ↓
+Step 5: 根据检索结果调整执行方案
+    ↓
+开始执行任务
+```
+
+### 查询构造规范
+
+- **SOP 查询**: `memory_search(corpus=all, query="<业务类型> SOP")`
+  - 示例：`memory_search(corpus=all, query="项目拆解 SOP")`
+  - 示例：`memory_search(corpus=all, query="部署运维 SOP")`
+
+- **历史经验查询**: `memory_search(corpus=all, query="<项目名> 决策/问题/方案")`
+  - 示例：`memory_search(corpus=all, query="知识库选型 决策")`
+  - 示例：`memory_search(corpus=all, query="Agent 任务积压 问题")`
+
+- **结构化知识查询**: `wiki_search(query="<主题>")`
+  - 示例：`wiki_search(query="项目管理规范")`
+
+- **思源知识库全文搜索**: 
+  ```bash
+  curl -s -X POST "http://192.168.1.99:6806/api/search/fullTextSearchBlock" \
+    -H "Content-Type: application/json" \
+    -H "Authorization: Token 8ixgqexbnxgibk4u" \
+    -d '{"query":"<关键词>", "notebook":"20260623155217-njb0mkn"}'
+  ```
+
+---
+
+## 5. 跳过条件（仅以下情况可跳过检索）
+
+| # | 跳过场景 | 原因 |
+|---|----------|------|
+| 1 | 简单重复性任务 | 如"重启容器""发送消息"——已知操作无需检索 |
+| 2 | 紧急故障处理 | 先止损，事后补检索 |
+| 3 | 用户明确指示 | "不需要检索历史" |
+| 4 | 纯闲聊/问候 | 无业务内容 |
+
+---
+
+## 6. 审计指标
+
+### 月度检查项
+
+| 指标 | 目标 | 检查方式 |
+|------|------|----------|
+| 检索覆盖率 | ≥80% | 对比有检索记录的任务数 / 总执行任务数 |
+| query 相关性 | query 与任务内容匹配 | 抽查 query 与任务 brief 的关键词重合度 |
+| 执行方案调整率 | 有检索的任务中 ≥30% 有方案调整 | 检查检索后是否在 notes/评论中记录调整 |
+| 零检索执行 | <20% | 无检索记录直接执行的任务占比 |
+
+### 纳入 Agent 行为审计
+
+- ✅ 任务执行前有检索记录（memory_search / wiki_search 调用日志）
+- ✅ 检索 query 与任务相关性强
+- ✅ 根据检索结果调整了执行方案
+- ❌ 无任何检索直接执行（除非符合跳过条件）
+- ❌ 检索 query 过于笼统（如单字查询）
+
+### 审计由 COO 月度执行
+
+COO（陆怀瑾）每月 1 日检查上月全部 Agent 的检索执行情况，输出审计报告。
+
+---
+
+## 7. AGENTS.md 注入模板
+
+各 Agent 的 AGENTS.md 中需注入以下章节：
+
+```markdown
+## ⚠️ 执行前检索 SOP（强制规则）
+
+> **BIZ-81 要求**：任务执行前必须先检索知识库，避免重复造轮子、忽略历史经验。
+
+### 触发条件
+以下情况**必须**执行检索（任一触发）：
+- 接收到新任务（WorkBoard/Multica/TODO.md 认领）
+- 任务涉及已知业务领域
+- 需要做出技术选型、流程设计、资源分配决策
+- 遇到不确定如何处理的问题
+
+### 检索流程
+Step 1: memory_search(corpus=all, query="任务关键词 SOP/历史经验")
+Step 2: 如有匹配 → memory_get / wiki_get 读取详细内容  
+Step 3: 如无匹配 → wiki_search(query="任务关键词")
+Step 4: 根据检索结果调整执行方案
+→ 开始执行任务
+
+### 跳过条件
+- 简单重复性任务（如"重启容器""发送消息"）
+- 紧急故障处理（先止损，事后补检索）
+- 用户明确指示"不需要检索历史"
+
+### 审计指标
+以下行为将纳入 Agent 执行质量审计：
+- ✅ 任务执行前有检索记录
+- ✅ 检索 query 与任务相关性强
+- ✅ 根据检索结果调整了执行方案
+- ❌ 无任何检索直接执行（除非符合跳过条件）
+- ❌ 检索 query 过于笼统
+```
+
+---
+
+## 8. 生效与维护
+
+- **生效日期**: 2026-07-06
+- **维护人**: 胡蓉（projectmanager）
+- **revision 周期**: 每季度 review 一次，根据审计数据调整检索流程
+- **下次 review**: 2026-10-06
+
+---
+
+*本 SOP 由 projectmanager 胡蓉起草，经刘炜承批准后生效。*
@@ -0,0 +1,194 @@
+# SOP-017：知识缺口上报 SOP
+
+> **版本**: v1.0  
+> **起草人**: 胡蓉（projectmanager）  
+> **批准人**: 刘炜承  
+> **生效日期**: 2026-07-06  
+> **关联 Issue**: BIZ-82
+
+---
+
+## 1. 目的
+
+解决 BIZ-45 巡检发现的全平台零知识缺口上报问题。各 Agent TOOLS.md 有"知识缺口记录"章节但无明确触发条件和上报流程，导致知识缺口被忽略、遗忘，长期影响任务交付质量。
+
+---
+
+## 2. 适用范围
+
+全部 Agent（产研线 + 运营线 + 职能线），共 14 个。
+
+---
+
+## 3. 知识缺口定义
+
+**知识缺口** = 执行任务时发现知识库（memory / wiki / 思源）中找不到的、且影响任务交付的知识。
+
+### 属于知识缺口的情况
+
+| # | 类型 | 示例 |
+|---|------|------|
+| 1 | 核心 SOP 缺失 | 没有淘宝上架 SOP，运营不知道怎么操作 |
+| 2 | 技术规范缺失 | 没有代码审查规范，开发不知道标准 |
+| 3 | 决策依据缺失 | 选型时缺乏对比数据，无法做出有依据的决策 |
+| 4 | 模板/指南缺失 | 没有 PRD 模板，每次手写格式不一致 |
+| 5 | 外部信息缺失 | 需要某个 API 文档但找不到 |
+
+### 不属于知识缺口的情况
+
+| # | 场景 | 应对方式 |
+|----|------|----------|
+| 1 | 可通过 web_search 快速获取的公开信息 | 自行检索 |
+| 2 | 可通过 memory_search / wiki_search 检索到的现有知识 | 自行读取 |
+| 3 | 可通过联系对应 Agent 获得的信息 | 直接联系 |
+| 4 | Agent 自身职责范围内的常识 | 不需上报 |
+
+---
+
+## 4. 触发条件
+
+执行 SOP-016（执行前检索）后，以下情况触发上报：
+
+1. **检索无结果**: memory_search + wiki_search + 思源全文搜索均无匹配
+2. **检索结果不足以支撑决策**: 有部分信息但缺少关键环节
+3. **任务执行中发现缺少必要规范/模板/指南**: 执行中途发现被忽略的知识需求
+
+---
+
+## 5. 上报流程
+
+```
+发现知识缺口
+    ↓
+Step 1: 记录 — 在 memory/当日日志.md 中记录缺口
+    ↓
+Step 2: 通知 — 通过 sessions_send 通知 COO（陆怀瑾）
+    ↓
+Step 3: 创建 Issue — 在 Gitea 仓库创建 Issue（标题格式：知识缺口-<领域>-<关键词>）
+    ↓
+Step 4: COO 审核 — COO 评估后决定：接受 / 拒绝 / 升级
+    ↓
+Step 5: 创建 WorkBoard 卡片 — COO 创建补全卡片，分配给合适的 Agent
+    ↓
+Step 6: 补全完成 — 补全 Agent 完成后通知上报 Agent + COO
+    ↓
+Step 7: 闭环 — COO 确认补全质量，关闭 Issue 和卡片
+```
+
+---
+
+## 6. 上报格式
+
+### 6.1 memory 日志记录格式
+
+在 `memory/YYYY-MM-DD.md` 中追加：
+
+```markdown
+## 📚 知识缺口上报
+
+**缺口类型**: [核心SOP缺失 | 技术规范缺失 | 决策依据缺失 | 模板/指南缺失 | 外部信息缺失]
+**缺口描述**: [具体缺什么，越详细越好]
+**使用场景**: [在做什么任务时发现的，为什么需要这个知识]
+**影响范围**: [哪些任务/Agent 受影响]
+**紧急程度**: [P0-阻塞当前任务 | P1-影响效率 | P2-改进建议]
+**建议补全方式**: [希望怎么处理——新建SOP/更新现有/外部采购等]
+**已执行的检索**: [列出已尝试的检索方式和query]
+**上报时间**: [YYYY-MM-DD HH:MM]
+```
+
+### 6.2 通知 COO 的消息格式
+
+通过 `sessions_send` 发送给 COO（sessionKey: `agent:coo:feishu:coo:direct:ou_9f73b4e54af59f038e2b754793ea0908`）：
+
+```
+【知识缺口上报】
+类型: [缺口类型]
+描述: [缺口描述]
+场景: [使用场景]
+紧急: [P0/P1/P2]
+已记录: memory/YYYY-MM-DD.md
+请审核并决定是否创建补全卡片。
+```
+
+### 6.3 Gitea Issue 格式
+
+- **标题**: `知识缺口-<领域>-<关键词>`
+- **标签**: `knowledge-gap`
+- **描述**: 包含缺口类型、描述、使用场景、影响范围、紧急程度、建议补全方式
+
+---
+
+## 7. 优先级分级
+
+| 优先级 | 定义 | 响应时限 | 补全时限 |
+|--------|------|----------|----------|
+| P0 | 阻塞当前任务，无法继续执行 | COO 4h 内响应 | 24h 内补全 |
+| P1 | 影响效率，有 workaround 但不理想 | COO 1 工作日内响应 | 3 工作日内补全 |
+| P2 | 改进建议，当前可正常运行 | COO 1 周内响应 | 按排期补全 |
+
+---
+
+## 8. COO 审核标准
+
+COO 收到上报后，按以下标准审核：
+
+| 审核项 | 标准 |
+|--------|------|
+| 是否真的缺口 | 上报人是否已充分检索（检查已执行检索记录） |
+| 是否属于知识缺口 | 对照第3节定义判断 |
+| 优先级是否合理 | 根据影响范围和紧急程度判断 |
+| 补全方式是否可行 | 评估建议的合理性 |
+
+### 审核结果
+
+| 结果 | 处理方式 |
+|------|----------|
+| **接受** | 创建 WorkBoard 补全卡片，分配给合适 Agent |
+| **拒绝** | 说明理由，告知上报人自行解决 |
+| **升级** | 转交承哥决策（涉及预算、外部采购等） |
+
+---
+
+## 9. TOOLS.md 注入模板
+
+各 Agent 的 TOOLS.md 中需注入以下章节：
+
+```markdown
+## 📚 知识缺口上报
+
+> 完整 SOP 见 specs/SOP-017_知识缺口上报SOP.md
+
+### 触发条件
+执行 SOP-016 检索后，以下情况需上报知识缺口：
+1. 核心业务数据/SOP/决策依据缺失
+2. 缺失影响任务交付质量或决策准确性
+3. 无法通过 memory_search / wiki_search 检索到
+
+### 上报流程
+1. **记录**: 在 memory/当日日志.md 中记录缺口（标准格式见 SOP-017）
+2. **通知**: 飞书通知 COO（sessionKey: agent:coo:feishu:coo:direct:ou_9f73b4e54af59f038e2b754793ea0908）
+3. **创建 Issue**: Gitea 仓库创建 Issue（标题格式：知识缺口-<领域>-<关键词>）
+4. **跟进**: COO 评估后创建 WorkBoard 补全卡片
+5. **闭环**: 补全后 COO 通知可使用
+
+### 标准格式
+[见 SOP-017 第6节]
+
+### 不属于知识缺口的情况
+- 可通过 web_search 快速获取的公开信息 → 自行检索
+- 可通过 memory_search / wiki_search 检索到的现有知识 → 自行读取
+- 可通过联系对应 Agent 获得的信息 → 直接联系
+```
+
+---
+
+## 10. 生效与维护
+
+- **生效日期**: 2026-07-06
+- **维护人**: 胡蓉（projectmanager）
+- **revision 周期**: 每季度 review 一次，根据上报数据调整流程
+- **下次 review**: 2026-10-06
+
+---
+
+*本 SOP 由 projectmanager 胡蓉起草，经刘炜承批准后生效。*