BIZ-84: 知识缺口上报 SOP v1.0

- 定义知识缺口触发条件（6类场景） - 明确5步上报流程（记录→通知COO→评估→建卡→闭环） - 双渠道上报（WorkBoard评论+飞书 / Multica issue） - 责任矩阵：7类缺口对应责任人 - 质量监控指标：周度巡检+月度分析 - 已更新全部16个Agent TOOLS.md Co-authored-by: multica-agent <github@multica.ai>
2026-07-06 04:50:35 +08:00
3 changed files with 0 additions and 521 deletions
@@ -1,168 +0,0 @@
-# 淘宝 + 聚水潭自动化运营方案设计
-
-## 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
@@ -1,159 +0,0 @@
-# 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 胡蓉起草，经刘炜承批准后生效。*
@@ -1,194 +0,0 @@
-# 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 胡蓉起草，经刘炜承批准后生效。*