DEMO-AGENT/docs/需求分析/6.agent_core模块需求分析.md

# Agent Core 模块需求分析

## 1. 模块定位

`agent_core` 是整套系统的能力中枢。在本题中，它不应再被描述为“一个通用 Prompt + RAG + Tool 的抽象核心”，而应被明确定位为：

> 注册申报资料审核编排引擎

它负责把法规规则、文档解析结果、字段抽取逻辑、一致性核查逻辑、风险输出模板和大模型能力组织成一个可执行的审核流程。

## 2. 模块总目标

本模块需要完成以下目标：

1. 基于题面要求完成文件目录汇总、完整性核查、字段抽取、回填准备、一致性检查和风险预警。
2. 形成规则优先、模型辅助的审核框架，而不是完全依赖自由生成。
3. 提供结构化、可追溯、可测试的输出。
4. 保持与 Django 页面层和数据层的边界清晰。

## 3. 为什么 Agent Core 是本题真正的“答题核心”

本题的难点不在“接个大模型接口”，而在于以下几点如何落到一个统一编排里：

1. 资料目录与法规目录如何比对。
2. 产品说明书、申请表、产品列表、声明文件之间如何抽取统一字段。
3. 不同字段的“一致”与“不一致”如何定义。
4. 风险预警如何从规则结果和模型解释中生成。

这些都属于 `agent_core` 的职责范围。

## 4. 核心能力拆分

建议将 `agent_core` 的能力拆成以下几个子域理解。

### 4.1 任务编排

根据不同任务入口，组织不同处理链路。例如：

- 目录汇总链路
- 完整性检查链路
- 字段抽取链路
- 一致性核查链路
- 综合风险链路

### 4.2 规则引擎

对以下事项优先使用规则处理：

- 章节点完整性
- 必交文件判断
- 文件归类
- 固定字段抽取
- 强一致字段比对

### 4.3 LLM 辅助推理

对以下事项由 LLM 作为辅助：

- 长段文本中的字段归纳
- 风险说明文案生成
- 处理建议生成
- 无法通过简单规则覆盖的异常解释

### 4.4 RAG 检索

用于在文档较长、规则或用户问题较细时，从已入库资料中定位证据片段，为回答和审计提供支撑。

对本题而言，RAG 不仅要覆盖业务申报资料，也要覆盖公告附件包等法规原文资料。但它的职责应限定为：

1. 为规则判断提供证据定位。
2. 为结果解释提供法规引用。
3. 为审计留痕提供可追溯片段。

不能把 RAG 检索命中的段落直接等同于最终合规判断。

### 4.5 结构化输出

将每类任务输出为明确 schema，而不是一段随意文本。

## 5. 按题面要求拆解的能力需求

## 5.1 文件目录汇总能力

### 目标

自动汇总注册申报文件夹中的所有文件及页数。

### 需要的输入

- Documents 模块提供的文档记录
- 文件页数
- 文档归类信息

### 处理逻辑

1. 遍历当前项目 / 批次所有资料。
2. 汇总文件名、章节点、页数、状态。
3. 识别目录类文档与普通文档。
4. 输出目录总表。

### 输出要求

结构化输出中至少包含：

- 文件清单
- 文件数量
- 总页数
- 已识别章节点
- 待确认文档

## 5.2 法规完整性核查能力

### 目标

对照 NMPA 法规要求，检查所需资料是否齐全，并识别缺失项。

### 规则依据

当前材料已明确可用依据包括：

- `附件 4 体外诊断试剂注册申报资料要求及说明`
- `CH1.2 监管信息目录`
- 题面中提及的 NMPA / CMDE 法规来源
- `关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告` 附件包

结合新增公告附件包，法规规则来源建议分层管理：

1. 注册申报资料要求及说明
2. 医疗器械注册申报资料和批准证明文件格式要求（体外诊断试剂）
3. 体外诊断试剂安全和性能基本原则清单
4. 中华人民共和国医疗器械注册证（体外诊断试剂）格式
5. 变更备案 / 变更注册申报资料要求及说明
6. 延续注册申报资料要求及说明

### 处理逻辑

1. 装载法规目录模板。
2. 装载当前资料实际清单。
3. 以章节点和资料名称进行匹配。
4. 区分：
   - 已提供
   - 缺失
   - 疑似已提供但命名不规范
   - 需人工判断
5. 生成缺失项清单和建议动作。

### 关键难点

不是所有缺失都等价。需要区分：

- 监管强制项缺失
- 目录中声明有但实际文件找不到
- 文件存在但内容不符合该章节点用途

此外，还需要区分：

- 资料要求缺失
- 文件格式要求不满足
- 安全和性能基本原则映射不完整

### 输出要求

- 命中项列表
- 缺失项列表
- 风险等级
- 建议补充动作
- 规则依据

## 5.3 产品关键信息抽取能力

### 目标

从产品文件中提取关键信息并自动填写到目标文件或结构化结果中。

### 目标字段建议

至少包括题面点名字段：

- 产品名称
- 检测靶标
- 适用范围 / 预期用途
- 储存条件
- 性能指标

结合样例材料，建议进一步扩展：

- 包装规格
- 适用样本类型
- 适用仪器
- 分类编码
- 临床评价路径
- 申请人名称
- 生产地址
- 标准清单
- 申报日期

考虑到系统目标是“通用的试剂盒临床注册文件准备与审核智能体”，字段 schema 应优先沉淀通用注册字段，而不是只对某一具体产品定制。

### 字段来源优先级

需要明确来源优先级，例如：

1. 申请表
2. 产品说明书
3. 产品列表
4. 声明类文件
5. 其他说明材料

或根据字段类型分别设定优先级。

### 抽取逻辑

1. 规则抽取显式字段。
2. 表格抽取规格、组分、标准清单等。
3. 对长文本字段使用 LLM 归纳。
4. 将结果写入统一字段池。
5. 标记字段来源和置信状态。

### 输出要求

- 字段名
- 字段值
- 来源文档
- 来源片段
- 是否冲突
- 是否可直接回填

## 5.4 自动回填准备能力

### 目标

将抽取得到的信息填入目标文件或目标字段。

### 首版建议范围

首版可以分阶段建设，但目标应明确指向：

- 申请表字段回填数据集
- 对照清单字段回填数据集
- 页面可视化回填预览
- 新的 Word 文档生成与导出能力

### 处理逻辑

1. 根据目标模板定义字段映射。
2. 从统一字段池读取值。
3. 对冲突字段进行拦截或提示。
4. 生成回填预览结果。

### 后续扩展

Word 输出阶段建议逐步增强为：

1. 字段映射与预览
2. 模板占位写回
3. 尽量保留原始样式、表格和版式的高保真导出

结合新增公告附件包中的批准证明文件格式材料，回填能力的后续扩展方向应进一步明确为：

1. 按注册证 / 批准证明文件格式模板生成字段映射。
2. 按不同法规流程类型切换不同输出模板。

## 5.5 一致性核查能力

### 目标

核查不同文档间相同信息是否一致，检测章节结构和规范性问题。

### 强一致字段

建议首版按强一致处理的字段包括：

- 产品名称
- 申请人名称
- 规格型号 / 包装规格
- 分类编码
- 申报产品名称对应的章节点标题

结合最新确认，当前阶段不采用“语义一致即可通过”的宽松规则。对于被纳入同一审核范围的相同字段，默认按完全一致处理；如出现措辞差异，也应先判为冲突或待复核。

### 审核范围前置规则

一致性核查前必须先明确：

1. 哪些文档属于同一项目 / 批次 / 审核范围。
2. 哪些文档只是通用样本材料，不能直接混入同一轮一致性比对。

因此，一致性核查链路应包含“审核范围确认”这一步，而不是直接对全部文档做全量比较。

### 结构核查

除字段一致性外，还应检查：

- 说明书是否包含关键章节
- 目录页是否覆盖当前章节点
- 文档标题是否规范
- 是否存在不属于本产品的资料混入

### 典型异常示例

根据当前样例，系统应能识别：

- 若这些文档被划入同一审核范围，则“2019-nCoV”与“呼吸道合胞病毒、肺炎支原体”构成明确冲突。
- 若这些文档本身被认定属于不同资料组，则系统应提示“存在跨产品样例混入，不应直接合并审核”。

### 输出要求

- 一致字段列表
- 冲突字段列表
- 冲突明细
- 风险等级
- 处理建议

## 5.6 合规风险预警能力

### 目标

把完整性检查、字段抽取和一致性核查的结果汇总成可执行的风险清单。

### 风险类型建议

- 缺失风险
- 混档风险
- 字段冲突风险
- 章节不规范风险
- 历史申报事项风险
- 资料真实性 / 版本一致性风险
- 法规适用情形错误风险

### 风险分级建议

首版可采用：

- 高风险
- 中风险
- 低风险

另行保留“待人工复核”状态，但它不是风险等级，而是处理状态。

### 风险准入规则

风险判定应采用综合分析机制，对至少以下维度分别评分：

1. 法规完整性
2. 跨文档字段一致性
3. 文档结构与章节规范性
4. 历史事项与版本风险
5. 法规流程适用性风险

综合规则如下：

1. 任一维度出现高风险项，则本次审核直接判定为不通过。
2. 无高风险但存在多个中风险项时，应给出“待整改后复核”的建议。
3. 低风险项可进入整改建议清单，但不单独阻断。

### 处理建议生成逻辑

规则部分负责给出基础动作，例如：

- “补充缺失文件”
- “核对产品名称”
- “重新确认临床资料版本”

LLM 负责把这些动作组织成自然语言建议，但不能改变底层规则结论。

## 6. 统一字段池设计需求

为支撑抽取、回填和一致性核查，建议在 `agent_core` 内形成统一字段池概念。

字段池至少记录：

- 字段名
- 标准化字段值
- 原始字段值
- 来源文档
- 来源位置
- 置信度
- 冲突状态
- 最终推荐值

这是本题从“简单聊天 Demo”走向“资料审核系统”的关键能力之一。

## 7. 规则体系需求

### 7.1 完整性规则

用于判断：

- 某章节点是否必交
- 当前资料是否命中
- 缺失是否构成高风险

这里应进一步拆为三个子层：

1. 资料要求层完整性规则
2. 结构目录层完整性规则
3. 格式模板层完整性规则

### 7.2 抽取规则

用于：

- 标题识别
- 表格字段映射
- 固定格式声明提取

对于法规资料本身，还应支持抽取：

- 附件编号
- 法规流程类型
- 适用范围说明
- 批准证明文件格式字段

### 7.3 一致性规则

用于定义：

- 哪些字段必须完全一致
- 如何判断冲突严重度
- 如何在执行前确认审核范围

### 7.4 风险映射规则

用于把缺失、冲突、不确定结果映射为风险级别、综合得分、是否通过和处理建议。

新增公告材料后，风险映射还应能够体现“适用情形错误”的风险，例如：

1. 把变更备案规则误用于首次注册申报
2. 把延续注册格式误用于注册申报输出

同时，若系统生成 Word 输出失败、模板字段无法落位或导出格式破坏严重，也应形成独立的交付风险提示。

## 8. 工具体系需求

题面附加要求提到需要展示实际调用的关键工具/库。因此 `agent_core.tools` 中应逐步沉淀出与本题强相关的工具，而不是只保留通用样例工具。

建议工具方向包括：

1. 文档页数统计工具
2. 章节点识别工具
3. 必交项检查工具
4. 字段抽取工具
5. 字段一致性比对工具
6. 风险汇总工具
7. 审核范围确认工具
8. 法规流程识别工具
9. 格式模板映射工具
10. Word 模板回填与导出工具
11. 飞书消息摘要生成与通知载荷组装工具

这些工具都应通过 Tool Registry 注册，符合项目既有边界要求。

## 9. LLM Provider 需求

### 9.1 不允许业务代码散落模型调用

所有模型调用继续通过 Provider 统一处理。

### 9.2 模型在本题中的使用原则

本题应坚持：

1. 规则优先
2. 证据优先
3. 模型负责解释、补充和归纳
4. 模型不应凭空判断法规完整性

### 9.3 测试要求

所有核心编排逻辑应继续支持 Mock Provider，以保证回归测试离线可跑。

## 10. 结构化输出 Schema 需求

建议至少定义以下输出类型：

1. `registration_overview_report`
2. `registration_completeness_report`
3. `registration_field_extraction_report`
4. `registration_consistency_report`
5. `registration_risk_report`

每种输出都应有稳定字段，便于页面展示与测试覆盖。

## 11. 与其他模块的边界

### 11.1 与 Documents 模块

Documents 负责提供资料事实；Agent Core 负责把这些事实转化为审核结论。

### 11.2 与 Chat 模块

Chat 负责接收用户意图和展示结果；Agent Core 负责执行任务链路。

### 11.3 与 Audit 模块

Audit 负责记录过程和结果；Agent Core 负责产出可记录的结构化执行信息。

## 12. 当前代码基线下的重构建议

### 12.1 建议保留

- Prompt 编排机制
- 结构化结果对象
- Tool Registry
- RAG fallback / Chroma 双路径思路
- Mock Provider 测试策略

### 12.2 建议增强

1. 从通用场景输出转向注册审核专用输出 schema。
2. 增加法规完整性规则和目录模板匹配逻辑。
3. 增加统一字段池。
4. 增加一致性核查与风险汇总工具。
5. 将“回填准备结果”纳入正式输出结构。
6. 增加“是否通过”和“风险评分明细”输出字段。
7. 增加法规分层规则管理，以及注册申报 / 变更 / 延续三类流程的扩展边界。

## 13. 验收标准

本模块完成后，应至少满足：

1. 能支持目录汇总、完整性检查、字段抽取、一致性核查、风险预警五类核心任务。
2. 核心结论有结构化输出，不依赖随意文本。
3. 规则和模型分工清晰，法规判断不完全依赖大模型生成。
4. 输出能关联到具体文档和证据片段。
5. 测试环境下可以通过 Mock Provider 验证主要编排逻辑。
6. 法规原文可切片入 RAG，但最终完整性与准入判断仍由规则链路主导。