Bruce/DEMO-AGENT
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(需求分析): 按Agent原型重写核心需求

Browse Source
This commit is contained in:
bruce
2026-06-03 23:55:27 +08:00
parent 7836690303
commit ea9ad57a5f
5 changed files with 502 additions and 1492 deletions
Download Patch File Download Diff File Expand all files Collapse all files

315
docs/需求分析/1.V1总需求文档.md
View File

@@ -2,199 +2,252 @@
## 1. 文档目的
本文档作为当前项目 V1 阶段的总需求索引文档，用于统一说明本轮笔试题对应的产品定位、目标用户、核心业务闭环、模块拆分方式和后续阅读路径。
本文档用于基于最新版演示原型、现有原始材料和项目边界，重新定义 V1 阶段的需求基线。
与历史“通用 AI Agent Demo 框架”定位不同，本轮 V1 需求以 `docs/` 目录中的真实题面与资料样本为准，系统目标已经切换为：
当前系统不再按“传统审核系统多页面菜单”叙事，而是明确采用：
> 试剂盒临床注册文件准备与审核智能体平台
> 以 Agent 对话为核心的试剂盒临床注册文件准备与审核平台
V1 需要同时满足三类目标：
1. 能用对话驱动审核任务。
2. 能把资料包、知识库、审核记录和飞书通知纳入统一闭环。
3. 能以可讲解、可追溯、可扩展的方式支撑后续 Django 实现。
## 2. 产品定位
本系统面向 **NMPA 境内第三类体外诊断试剂注册申报资料准备与审核** 场景，服务于需要整理、核查、抽取、回填和追踪注册资料的业务人员。
本系统面向 NMPA 境内第三类体外诊断试剂注册申报资料准备与审核场景，服务对象包括：
系统主体围绕注册申报审核场景展开，但能力目标是沉淀为“通用的试剂盒临床注册文件准备与审核智能体”，而不是只绑定某一个具体试剂盒产品。
1. 注册申报专员
2. 注册资料负责人
3. 质量/法规专员
4. 审核复核人员
5. 平台治理管理员
系统不再以“适配任意业务题”的通用 Demo 作为对外主叙事，而是聚焦以下业务价值：
产品不再只是“上传文件后生成报表”的审核系统，也不只是“自由聊天的问答机器人”，而是一个围绕资料包审核任务编排的 Agent 工作台。
1. 自动汇总注册资料目录与页数。
2. 对照法规要求检查资料完整性。
3. 抽取产品关键信息并形成统一字段池。
4. 支持将产品核心信息自动填入注册申报表格或对照清单。
5. 核查跨文档信息一致性与章节规范性。
6. 输出合规风险预警和处理建议。
## 3. 最新版原型对应的产品形态
## 3. 原始材料依据
基于当前最新版原型，V1 顶层产品形态固定为 4 个一级入口：
当前需求分析主要基于以下材料整理：
1. `审核智能体`
2. `资料包`
3. `知识库`
4. `处理历史`
1. `docs/【模拟题二】试剂盒临床注册文件准备与审核Agent/【模拟题二】试剂盒临床注册文件准备与审核Agent.md`
2. `docs/目标产品说明书.docx`
3. `docs/附件 4 体外诊断试剂注册申报资料要求及说明.doc`
4. `docs/第1章 监管信息/` 下的监管目录、申请表、产品列表、声明与沟通记录样例
5. `docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/` 下的公告附件包
这 4 个入口分别承担：
其中新增公告附件包使法规依据不再只是单篇“资料要求说明”，而是扩展为一组正式规则来源，包括：
### 3.1 审核智能体
1. 体外诊断试剂注册申报资料要求及说明
2. 医疗器械注册申报资料和批准证明文件格式要求（体外诊断试剂）
3. 体外诊断试剂安全和性能基本原则清单
4. 中华人民共和国医疗器械注册证（体外诊断试剂）格式
5. 体外诊断试剂变更备案 / 变更注册申报资料要求及说明
6. 体外诊断试剂延续注册申报资料要求及说明
作为统一任务入口，承接：
当前 V1 默认以“公告附件包”作为主规则来源，并将 `附件 4 体外诊断试剂注册申报资料要求及说明` 视作同源补充材料，而不是独立的第二套规则来源。
1. 资料上传
2. 自然语言提问
3. 任务模板选择
4. 节点式审核执行
5. 结构化结论查看
6. 风险与整改建议输出
## 4. V1 范围
### 3.2 资料包
V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环，不追求一次性做成完整商业平台。
作为资料治理入口，承接：
### 4.1 V1 必须覆盖
1. 资料包导入
2. 按产品名称建立资料包记录
3. 资料包与对话会话关联
4. 目录、页数、章节点、异常结果查看
5. 按产品名称或批次号搜索资料包
1. 资料上传与管理
2. 资料包导入、压缩包解包、文件目录与页数汇总
3. 法规完整性检查
4. 产品关键信息抽取
5. 跨文档一致性核查
6. 风险预警输出
7. 审计留痕
8. 本地可运行与 Docker 演示启动
### 3.3 知识库
其中第 3 项“法规完整性检查”在 V1 中建议明确分为三层：
作为治理入口，承接：
1. 资料齐套性检查
2. 章节点和结构合规性检查
3. 批准证明文件格式与输出映射检查
1. 法规资料上传
2. 业务资料上传
3. RAG 文档源管理
4. 切片解析与向量入库
5. 字段 Schema 管理
6. 模板映射管理
7. 飞书通知配置与责任人映射
### 4.2 V1 可接受的简化
其中“法规依据”不再单独作为顶级页面存在，而是作为知识库中的法规资料，通过 RAG 命中在 Agent 对话中返回。
1. 首版可优先覆盖第 1 章监管信息，并为全章扩展预留结构。
2. 首版即要求具备“生成新的 Word 文档并支持导出”的能力，且输出版式必须达到可直接报送级别。
3. 首版法规校验可以本地规则为主，不强依赖联网抓取最新法规。
4. 首版需要支持飞书内完成任务选择、结果查看和责任人通知，并支持群聊机器人入口及手动维护责任人 / 飞书账号映射。
5. 首版法规任务边界以“注册申报”主流程为核心，变更备案和延续注册暂作为规则扩展方向。
6. DOCX 页数必须精确统计，不能以估算页数作为 V1 验收结果；DOC 如受格式限制无法精确统计，应标记为待复核。
7. 回填目标已确认为注册申报表格或对照清单，首版应输出结构化回填结果，并支持按模板生成 Word 文件。
### 3.4 处理历史
## 5. 业务闭环
作为留痕入口，承接：
建议按以下业务闭环理解整套系统：
1. 按批次回看历史任务
2. 查看资料规模和任务类型
3. 查看最终结论和风险状态
4. 查看关联会话、附件和摘要
5. 支撑审计与复核
1. 导入注册申报资料。
2. 识别文档、统计页数、构建目录。
3. 依据法规目录进行完整性核查。
4. 从说明书、申请表、产品列表等材料中抽取统一字段。
5. 将产品名称、检测靶标、适用范围、储存条件、性能指标等核心信息自动填入注册申报表格或对照清单。
6. 对同名字段进行跨文档一致性比对。
7. 形成风险清单、回填结果和审计记录。
## 4. 原始材料依据
在规则执行层，建议采用“双层知识底座”：
当前需求分析以以下资料为主：
1. 结构化规则文件负责完整性判断、强一致比对和风险映射。
2. 公告附件原文切片入 RAG，负责条款引用、证据检索和解释说明。
1. `docs/原始材料/【模拟题二】试剂盒临床注册文件准备与审核Agent.docx`
2. `docs/原始材料/目标产品说明书.docx`
3. `docs/原始材料/附件 4 体外诊断试剂注册申报资料要求及说明.doc`
4. `docs/原始材料/第1章 监管信息/` 下样例资料
5. `docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/` 下公告附件包
6. 最新版原型文件 `docs/原型设计/registration-prototype-demo.html`
其中法规知识维护方式应固定为：
## 5. V1 核心业务闭环
1. 按“章 -> 条 -> 要求项 -> 模板字段”四级结构维护。
2. 同步建设结构化规则文件，避免让完整性校验完全依赖检索文本。
3. 提供后台管理页面，支持人工校订和知识库更新。
V1 需要围绕以下闭环展开：
资料导入层需要按“资料包”而不是“单文件”设计。V1 至少应支持批量文件上传、文件夹导入和压缩包导入能力。压缩包导入支持 `zip`、`rar`、`7z`，解包后保留原始相对路径，并将压缩包内多层目录按原目录作为章节点识别依据。`rar`、`7z` 解压必须采用纯 Python 实现，允许增加第三方依赖包，避免服务器部署时依赖系统级解压工具。
1. 导入资料包。
2. 解析资料包并识别产品名称。
3. 以解析后的产品名称建立资料包记录和对话会话。
4. 汇总目录、页数和章节点。
5. 基于法规规则和 RAG 证据执行完整性检查。
6. 抽取统一字段池并执行一致性核查。
7. 汇总风险并给出是否允许正式导出的结论。
8. 在任务完成或出现异常时，通过飞书 `@` 对应处理人。
9. 将过程结果写入处理历史与审计留痕。
第 2 至第 6 章首版不补充企业真实样本，先以公告附件包进行资料要求、章节点结构和模板口径的规则级初步确认。责任人首版通过后台或配置文件手动维护，并按资料章节配置。
## 6. V1 必须覆盖的能力
在法规维度上，建议把完整流程理解为：
### 6.1 Agent 对话驱动
1. 识别当前审核任务属于“注册申报”主流程。
2. 匹配对应的资料要求与章节点模板。
3. 检查资料齐套性与章节结构。
4. 对需要回填或输出的批准证明文件格式做字段映射准备。
1. 支持通过对话发起审核任务。
2. 支持上传附件并结合当前会话继续执行。
3. 支持推荐提示词模板。
4. 支持以节点方式展示目录汇总、完整性检查、字段抽取、一致性核查和风险结论。
## 6. 模块拆分
### 6.2 资料包中心
V1 需求分析按项目现有主模块拆分，不做过度细分：
1. 支持批量文件、文件夹、压缩包导入。
2. 支持资料包与会话一一关联。
3. 对话名称默认采用解析后的产品名称。
4. 支持按产品名称和批次号搜索资料包。
5. 支持从资料包跳转回对应对话。
1. [1.config模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\1.config模块需求分析.md)
2. [2.scenarios模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\2.scenarios模块需求分析.md)
3. [3.documents模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\3.documents模块需求分析.md)
4. [4.chat模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\4.chat模块需求分析.md)
5. [5.audit模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\5.audit模块需求分析.md)
6. [6.agent_core模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\6.agent_core模块需求分析.md)
### 6.3 知识库与 RAG
另附一份待确认事项文档，供与需求方沟通时直接使用：
1. 支持法规资料和业务资料分层管理。
2. 支持 RAG 文档源 CRUD。
3. 支持切片解析、重建向量和召回状态管理。
4. 支持在对话中返回法规命中依据。
5. 支持字段 Schema、模板映射、责任人映射和飞书配置治理。
- [0.需求重构总览与待确认事项.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\0.需求重构总览与待确认事项.md)
### 6.4 风险与导出
## 7. 当前识别出的关键业务特征
1. 支持完整性风险、字段冲突风险、混档风险、低置信度风险统一汇总。
2. 支持草稿导出与正式导出阻断。
3. 支持结构化整改建议。
### 7.1 审核对象是“资料包”
### 6.5 飞书协同
本题输入对象是整套注册申报资料，不是单篇文档问答。
1. 支持飞书群聊/机器人通知。
2. 风险任务执行完成或执行异常时，可直接 `@` 处理人。
3. 责任人信息中必须包含飞书账号相关字段。
4. 支持通过 Web 详情链接回到平台查看完整结果。
### 7.2 审核标准是“法规目录 + 资料内容”
## 7. 关键业务对象
系统既要看是否有文件，也要看是否放对章节点、内容是否对应。
### 7.1 资料包
### 7.3 系统必须具备“冲突识别”
资料包是 V1 的一级业务对象，不再把“单文件”视为默认审核对象。
当前样例中已经存在不同产品资料混入的迹象。这不要求系统默认把全部材料视为同一个产品，而是要求系统具备以下能力：
资料包至少包含：
1. 支持按项目批次或文档范围界定审核对象。
2. 对被划入同一审核对象的资料执行严格一致性检查。
3. 对混档、错归类和跨产品资料混入给出风险提示。
1. `batch_id`
2. `product_name`
3. `conversation_id`
4. `workflow_type`
5. `file_count`
6. `page_count`
7. `chapter_summary`
8. `import_status`
### 7.4 系统必须具备“可解释性”
### 7.2 对话会话
所有缺失判断、字段抽取和风险预警都应尽量有证据、有来源、有审计记录。
会话与资料包绑定，至少包含：
### 7.5 系统必须具备“法规分层引用”
1. `conversation_id`
2. `product_name`
3. `batch_id`
4. `task_status`
5. `messages`
6. `node_results`
结合新增公告附件包，系统应能区分并引用不同层级的规则来源，而不是把所有法规依据混成一条说明：
### 7.3 角色信息
1. 资料要求类依据
2. 格式要求类依据
3. 安全和性能基本原则类依据
4. 批准证明文件格式类依据
角色信息需要从“只有角色名”升级为“可通知的责任人实体”，至少包含：
### 7.6 系统需要具备“多入口访问能力”
1. `owner_role`
2. `owner_name`
3. `department`
4. `chapter_scope`
5. `risk_scope`
6. `feishu_user_id`
7. `feishu_open_id`
8. `feishu_name`
9. `notify_enabled`
V1 除 Web 工作台外，还需要实际支持飞书入口能力，使审核任务可以从浏览器工作台扩展到飞书会话和飞书群聊机器人场景。
### 7.4 飞书通知任务
### 7.7 系统需要具备“后台治理能力”
飞书通知对象至少包含：
除前台审核能力外，V1 还需要提供后台管理能力，用于维护规则包、模板库、责任人映射和知识库更新入口。
1. `batch_id`
2. `conversation_id`
3. `trigger_source`
4. `notify_reason`
5. `owner_role`
6. `feishu_user_id`
7. `message_status`
8. `web_detail_url`
## 8. 后续文档与实现衔接建议
## 8. 需求约束
后续若继续推进设计与开发，建议按如下顺序展开：
### 8.1 规则优先
1. 先确认待确认事项中的产品范围、回填目标和法规范围。
2. 基于模块需求文档输出设计文档。
3. 按 `config -> scenarios -> documents -> agent_core -> chat -> audit` 顺序推进重构。
4. 同步更新 README、AGENTS 和场景配置命名。
完整性检查、强一致判断、导出阻断必须规则优先，LLM 只做解释和补充。
当前仓库已补充一组演示型原型设计文档与单文件 HTML，作为设计到实现之间的中间层交付：
### 8.2 RAG 职责边界
- [整体原型设计](F:\PyCharm\DEMO-AGENT\docs\原型设计\1.整体原型设计.md)
- [分页原型设计目录](F:\PyCharm\DEMO-AGENT\docs\原型设计)
- [单文件演示站 HTML](F:\PyCharm\DEMO-AGENT\docs\原型设计\registration-prototype-demo.html)
RAG 负责：
该组原型资产覆盖：
1. 法规依据定位
2. 业务资料证据定位
3. 对话解释支撑
1. 资料包导入页
2. 审核任务工作台
3. 法规完整性检查页
4. 字段抽取与字段池页
5. 一致性核查页
6. 风险预警页
7. Word 回填导出页
8. 飞书通知视图
9. 知识库与治理台 CRUD 设计
RAG 不直接代替规则引擎输出最终合规结论。
## 9. 结论
### 8.3 飞书通知触发方式
当前 V1 需求已经从“通用 Agent Demo 基座”重构为“注册申报资料审核系统”。后续所有设计、实现和讲解，建议都围绕以下四个关键词展开：
当前 Demo 要求固定支持两类通知时机：
1. 文件夹级资料治理
2. 法规目录级完整性校验
3. 统一字段池与跨文档一致性检查
4. 可追溯的风险预警与审计留痕
1. 任务执行完成后发送结果摘要并 `@` 处理人。
2. 任务执行异常后发送异常摘要并 `@` 处理人。
### 8.4 本地可演示
V1 必须保持：
1. Web 可访问
2. 关键流程可离线演示
3. 不依赖真实大模型在线调用才能完成基础演示
## 9. 模块拆分建议
仍按现有模块边界推进，但职责解释需要更新：
1. `config`：配置、静态资源、环境变量、飞书集成基础配置
2. `documents`：资料包、文档、页数、目录、章节点、资料搜索
3. `chat`：Agent 对话工作台、节点执行区、提示词模板、会话历史
4. `audit`：处理历史、审计链路、通知留痕
5. `agent_core`：审核编排、规则执行、RAG 检索、结构化输出
## 10. 本轮重写结论
V1 现在的正确叙事应是：
1. 以资料包为审核对象。
2. 以 Agent 对话为主要执行入口。
3. 以知识库/RAG 为法规和业务依据底座。
4. 以处理历史和飞书协同保证可追溯和可协同。
这意味着后续需求分析和详细设计都应围绕“Agent 工作台式产品”继续重写，而不再沿用旧的固定报表式多页面系统思路。