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 验证主要编排逻辑。