docs: add SOP-016 执行前检索强制规则 + SOP-017 知识缺口上报SOP (BIZ-83/84)
This commit is contained in:
@@ -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 胡蓉起草,经刘炜承批准后生效。*
|
||||||
Reference in New Issue
Block a user