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 检索

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

### 4.5 结构化输出

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

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

## 5.1 文件目录汇总能力

### 目标

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

### 需要的输入

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

### 处理逻辑

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

### 输出要求

结构化输出中至少包含：

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

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

### 目标

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

### 规则依据

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

- `附件 4 体外诊断试剂注册申报资料要求及说明`
- `CH1.2 监管信息目录`
- 题面中提及的 NMPA / CMDE 法规来源

### 处理逻辑

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

### 关键难点

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

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

### 输出要求

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

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

### 目标

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

### 目标字段建议

至少包括题面点名字段：

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

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

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

### 字段来源优先级

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

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

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

### 抽取逻辑

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

### 输出要求

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

## 5.4 自动回填准备能力

### 目标

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

### 首版建议范围

首版不必以“完整保真写回 Word 模板”为核心验收，而可以先实现：

- 申请表字段回填数据集
- 对照清单字段回填数据集
- 页面可视化回填预览

### 处理逻辑

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

### 后续扩展

如需求方确认需要真实文档导出，再增加 Word 模板写回。

## 5.5 一致性核查能力

### 目标

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

### 强一致字段

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

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

### 语义一致字段

可按语义一致或近似一致处理的字段包括：

- 预期用途 / 适用范围
- 储存条件描述
- 适用样本类型

### 结构核查

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

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

### 典型异常示例

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

- 说明书产品是“2019-nCoV”，申请表和产品列表是“呼吸道合胞病毒、肺炎支原体”。
- 这类冲突应被直接标记为高风险或至少中高风险。

### 输出要求

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

## 5.6 合规风险预警能力

### 目标

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

### 风险类型建议

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

### 风险分级建议

首版可采用：

- 高风险
- 中风险
- 低风险
- 待人工确认

### 处理建议生成逻辑

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

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

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

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

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

字段池至少记录：

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

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

## 7. 规则体系需求

### 7.1 完整性规则

用于判断：

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

### 7.2 抽取规则

用于：

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

### 7.3 一致性规则

用于定义：

- 哪些字段必须完全一致
- 哪些字段允许近似匹配
- 如何判断冲突严重度

### 7.4 风险映射规则

用于把缺失、冲突、不确定结果映射为风险级别和处理建议。

## 8. 工具体系需求

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

建议工具方向包括：

1. 文档页数统计工具
2. 章节点识别工具
3. 必交项检查工具
4. 字段抽取工具
5. 字段一致性比对工具
6. 风险汇总工具

这些工具都应通过 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. 将“回填准备结果”纳入正式输出结构。

## 13. 验收标准

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

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