docs(需求分析): 同步Agent原型与资料包会话绑定

docs/需求分析/0.需求重构总览与待确认事项.md

@@ -123,19 +123,33 @@
 
 为了后续 Demo 更贴合复试陈述，建议整个系统的业务主线固定为：
 
-1. 导入一批注册资料。
-2. 系统自动形成申报目录与页数清单。
-3. 系统根据法规目录检查缺失项、错放项、待补项。
-4. 系统抽取产品核心信息并形成字段总表。
-5. 系统检查说明书、申请表、产品列表、声明文件之间的一致性。
-6. 系统输出风险清单、建议动作以及需要人工确认的问题。
-
-如果演示时间允许，建议再增加一个“法规依据展示”环节：
-
-7. 系统展示当前完整性结论所依据的公告附件、资料要求和模板来源。
+1. 在 `审核智能体` 中上传一批注册资料或直接进入一个已有资料包。
+2. 系统解析资料包，识别产品名称，并以该产品名称创建或绑定对话会话。
+3. 系统自动形成申报目录、页数清单和章节点识别结果。
+4. 系统根据法规目录检查缺失项、错放项、待补项。
+5. 系统抽取产品核心信息并形成字段总表。
+6. 系统检查说明书、申请表、产品列表、声明文件之间的一致性。
+7. 系统输出风险清单、建议动作以及需要人工确认的问题。
+8. 在对话中返回命中的法规依据、模板约束和资料来源说明。
 
 导入环节已确认支持两种演示路径：一是直接批量上传样例文件，二是上传包含多级目录的压缩包并由系统自动解压。压缩包格式覆盖 `zip`、`rar`、`7z`，其中 `rar` 和 `7z` 必须采用纯 Python 实现，允许增加第三方 Python 包依赖，以便后续部署到服务器时不依赖系统级解压工具。
 
+## 6.1 顶层产品形态补充说明
+
+最新版原型已固定顶层 4 个入口：
+
+1. `审核智能体`
+2. `资料包`
+3. `知识库`
+4. `处理历史`
+
+其中：
+
+1. `审核智能体` 是唯一主执行入口，以对话和节点式结果承接完整审核流程。
+2. `资料包` 负责按产品名称管理资料集合，并支持按产品名称或批次号搜索。
+3. `知识库` 统一承载法规资料、业务资料和 RAG 治理能力，因此“法规依据”不再单独成页。
+4. `处理历史` 负责按批次、按产品回看任务执行与通知留痕。
+
 ## 7. 已确认事项
 
 以下内容已根据最新沟通结果确认，并已同步进入后续模块需求：
@@ -180,6 +194,9 @@
 - `rar`、`7z` 解压必须采用纯 Python 实现，允许增加第三方依赖包。
 - 责任人先通过后台或配置文件手动维护，按资料章节配置责任人。
 - 系统需要自动提取产品名称、检测靶标、适用范围、储存条件、性能指标等核心信息，并自动填入注册申报表格或对照清单。
+- 资料包记录必须与对话会话绑定。
+- 对话标题默认采用解析后的 `product_name`。
+- `资料包` 页面必须提供按产品名称搜索入口，并支持从资料包跳转到关联会话。
 
 ### 7.6 输出文档形式
 
@@ -257,6 +274,9 @@
 16. 责任人首版按资料章节手动配置。
 17. 第 2 至第 6 章首版不补充企业样本，按公告附件包做规则级初步确认。
 18. 产品核心信息抽取后必须自动填入注册申报表格或对照清单。
+19. 顶层导航固定为 `审核智能体 / 资料包 / 知识库 / 处理历史`。
+20. 资料包与会话一一关联，对话标题取解析后的产品名称。
+21. “法规依据”作为知识库中的法规资料与 RAG 命中结果呈现，不再单列顶级页面。
 
 ## 10. 结论
 

docs/需求分析/1.config模块需求分析.md

@@ -28,6 +28,13 @@
 - 压缩包处理链路需要支持 `zip`、`rar`、`7z`，其中 `rar` 和 `7z` 必须使用纯 Python 依赖实现，不能依赖服务器系统级解压工具。
 - 审计数据不能只保留“问答日志”，还要能关联具体资料批次和审核任务。
 
+但与此同时，最新版原型已经明确本系统不是“传统多页面审核后台”，而是“以 Agent 对话为核心、资料包为主要业务对象”的产品形态。因此配置层不仅要支撑资料处理和规则加载，还要支撑以下对象级配置：
+
+- 资料包与会话绑定规则
+- 会话标题生成规则
+- 资料包列表默认搜索字段
+- 顶层导航与功能开关
+
 ### 3.2 Demo 与真实业务之间要有明确边界
 
 复试时允许 Demo 版做适度简化，但配置层必须明确什么是“演示默认值”，什么是“未来真实化扩展口”。否则系统很容易出现代码里写死演示路径、文档目录、模型名称、法规版本的情况，后续一改题就要整体返工。
@@ -130,6 +137,17 @@
 - `CHROMA_PATH`
   向量库目录。
 
+建议增加：
+
+- `CONVERSATION_TITLE_SOURCE`
+  会话标题来源。V1 默认使用解析后的 `product_name`。
+
+- `MATERIAL_SEARCH_FIELDS`
+  资料包列表默认搜索字段。V1 默认包含 `product_name,batch_id`。
+
+- `TOP_LEVEL_TABS`
+  顶层页面开关。V1 默认固定为 `chat,materials,knowledge,history`。
+
 ### 5.2 模型级配置项
 
 - `LLM_PROVIDER`
@@ -266,11 +284,11 @@ admin/
 
 ### 7.1 与 Documents 模块的边界
 
-`config` 只负责定义上传目录、抽取目录、导出目录和允许格式，不负责具体解析逻辑。
+`config` 只负责定义上传目录、抽取目录、导出目录、搜索字段和允许格式，不负责具体解析逻辑。
 
 ### 7.2 与 Agent Core 的边界
 
-`config` 负责提供模型参数、向量库参数、规则目录和功能开关，不负责具体提示词、抽取模板和审核规则实现。
+`config` 负责提供模型参数、向量库参数、规则目录、会话标题规则和功能开关，不负责具体提示词、抽取模板和审核规则实现。
 
 ### 7.3 与 Audit 模块的边界
 
@@ -333,6 +351,7 @@ admin/
 6. 增加 Word 导出目录和飞书应用接入相关配置。
 7. 增加模板库目录、规则管理目录和责任人映射配置。
 8. 增加纯 Python 压缩包解包依赖与策略配置，覆盖 `zip`、`rar`、`7z`。
+9. 增加资料包与会话绑定、会话命名和资料包搜索字段相关配置。
 
 ## 11. 本模块验收标准
 

docs/需求分析/2.scenarios模块需求分析.md

@@ -8,6 +8,8 @@
 
 也就是说，系统仍然可以保留配置化入口，但配置的对象不再是“知识问答、工单助手、财务审核”等通用 Agent，而是围绕注册申报业务拆分的若干子任务或工作模式。
 
+需要特别说明的是：最新版原型已经把顶层导航收敛为 `审核智能体 / 资料包 / 知识库 / 处理历史`，因此 `apps.scenarios` 不再承担“首页大卡片导航中心”的产品角色，而是退回为 Agent 工作台中的任务模板与流程节点配置中心。
+
 ## 2. 重构目标
 
 本模块需要完成以下目标：
@@ -16,6 +18,7 @@
 2. 用配置化方式定义不同审核任务的目标、输入、输出和可调用能力。
 3. 支撑后续 Demo 演示时快速切换不同任务视角，而不是频繁改代码。
 4. 保持与 `agent_core` 的边界清晰，即场景模块只定义任务，不实现任务逻辑。
+5. 支撑 `审核智能体` 页面中的预设提问模板、流程节点和执行卡片实时更新。
 
 结合新增公告材料，场景模块还应承担“法规流程类型选择器”的角色，避免把注册申报、变更备案、延续注册三类任务混成一个入口。
 
@@ -55,11 +58,11 @@
 
 ### 4.2 是否需要多个场景还是一个总场景
 
-建议首版保留“一个主场景 + 若干子任务配置”的思路：
+建议首版保留“一个主 Agent 会话 + 若干子任务配置”的思路：
 
-- 页面上可以展示多个任务入口。
+- 顶层页面不再展示多个独立业务页面，而是在 `审核智能体` 中展示多个任务模板与节点入口。
 - 底层可共享同一个项目资料池和统一字段池。
-- Demo 演示时可以先点“完整性检查”，再点“一致性核查”，展示系统分工明确。
+- Demo 演示时可以先触发“目录汇总”，再继续执行“完整性检查”“一致性核查”，展示 Agent 沿节点推进。
 
 ## 5. 场景配置应包含的内容
 
@@ -106,9 +109,9 @@
 
 ## 6. 页面层需求
 
-### 6.1 首页需要表达的内容
+### 6.1 `审核智能体` 页面需要表达的内容
 
-首页不应只展示“这是几个 YAML 场景”，而应展示当前系统已支持的注册审核任务。建议每个任务卡片至少包含：
+`审核智能体` 页不应只展示“这是几个 YAML 场景”，而应展示当前系统已支持的注册审核任务。建议每个任务卡片至少包含：
 
 - 任务名称
 - 任务目标
@@ -125,7 +128,7 @@
 - 已上传未入库：目录汇总可执行，RAG 相关任务应提示需先入库。
 - 规则文件缺失：完整性检查场景显示不可执行或部分能力不可用。
 
-这类状态说明非常适合复试演示，因为它体现了系统不是“死调用大模型”，而是有明确任务前置条件。
+这类状态说明非常适合复试演示，因为它体现了系统不是“死调用大模型”，而是有明确任务前置条件，并能驱动右侧任务卡片从“待执行”实时更新为“解析中”“已完成”“待复核”等状态。
 
 ## 7. 配置驱动的业务能力
 
@@ -206,7 +209,7 @@
 - 责任归属字段
 - 飞书通知目标字段
 
-### 7.6 法规依据展示任务或结果区
+### 7.6 法规依据展示结果区
 
 基于新增公告材料，建议在任务配置中增加法规依据展示能力，至少能让系统说明：
 
@@ -214,6 +217,12 @@
 2. 使用了哪份资料要求说明。
 3. 使用了哪份格式要求或批准证明文件模板。
 
+但该能力不应再通过单独一级“法规依据页”承载，而应：
+
+1. 作为知识库中的法规资料被维护。
+2. 在对话结果中以 RAG 命中依据卡片返回。
+3. 在任务节点详情或右侧能力卡中展示引用来源。
+
 ## 8. 与原始材料对应的任务设计要点
 
 ### 8.1 要能体现“资料结构化目录”的任务价值
@@ -249,7 +258,7 @@
 
 ### 9.1 与 Chat 模块的边界
 
-场景模块定义任务卡片和执行入口，Chat 模块负责用户进入任务后的具体交互与结果展示。
+场景模块定义任务模板、节点配置和执行入口，Chat 模块负责用户进入任务后的具体交互与结果展示。
 
 ### 9.2 与 Documents 模块的边界
 
@@ -294,6 +303,7 @@ configs/registration/
 3. 任务配置变更主要通过 YAML 完成，不需要频繁改 Python 代码。
 4. 至少能清楚区分“目录汇总、完整性检查、字段抽取、一致性核查、风险预警”五类任务。
 5. 字段抽取任务必须能表达“抽取核心信息并自动填入注册申报表格或对照清单”的输出目标。
+6. 任务配置能够驱动会话中的节点式执行和右侧状态卡实时更新。
 
 ## 12. 当前代码基线下的重构建议
 
@@ -313,7 +323,7 @@ configs/registration/
 
 如果场景模块重构到位，复试时可以很自然地说明：
 
-1. 为什么不是把所有能力塞进一个聊天机器人。
+1. 为什么虽然以对话为核心，但仍然保留配置化任务模板和节点编排。
 2. 为什么用配置驱动的任务入口更适合监管审核场景。
 3. 如何在不推翻现有系统结构的情况下，快速从通用 Demo 切换到具体业务题。
 

docs/需求分析/9.业务确认问答清单.md

@@ -38,6 +38,8 @@
 13. `rar`、`7z` 解压必须纯 Python 实现，允许增加第三方依赖包。
 14. 责任人先手动配置，按资料章节维护。
 15. 第 2 至第 6 章不补充企业真实样本，先按公告附件包进行规则级初步确认。
+16. 顶层入口按 `审核智能体 / 资料包 / 知识库 / 处理历史` 组织，法规依据纳入知识库并通过 RAG 在对话中返回。
+17. 资料包必须和会话绑定，会话标题默认采用解析后的产品名称，资料包页支持按产品名称搜索。
 
 ---
 
@@ -189,6 +191,38 @@
 
 - 决定 Documents 模块的上传、解包、目录还原和异常提示实现。
 
+### Q6-2 资料包与会话是否固定绑定？
+
+建议提问方式：
+
+> 当前我们准备采用“一个资料包绑定一个主会话”的方式，并把会话标题直接使用解析后的产品名称。请确认这个口径是否符合您期望的使用方式？
+
+建议记录答案：
+
+- 是否一包一会话：
+- 会话标题是否使用产品名称：
+- 是否允许后续在同一资料包下追加子会话：
+
+为什么要问：
+
+- 这会直接影响资料包页、审核智能体页和处理历史页的主键设计。
+
+### Q6-3 资料包页是否以产品名称作为主搜索字段？
+
+建议提问方式：
+
+> 在资料包列表里，您更习惯通过产品名称、批次号还是项目编号来查找资料？我们当前默认以产品名称和批次号作为主搜索条件。
+
+建议记录答案：
+
+- 主搜索字段：
+- 次搜索字段：
+- 是否需要模糊搜索：
+
+为什么要问：
+
+- 这会影响资料包列表页和历史页的默认检索体验。
+
 ---
 
 ## 4.3 自动审核与人工复核边界
@@ -354,6 +388,22 @@
 
 - 决定知识库首版范围。
 
+### Q14-1 法规依据是否可以完全收敛到知识库页面维护？
+
+建议提问方式：
+
+> 当前原型里我们不再单独做“法规依据”一级页面，而是把法规资料统一放进知识库，由 Agent 对话通过 RAG 命中后返回依据说明。请确认这种呈现方式是否符合您的预期？
+
+建议记录答案：
+
+- 是否接受：
+- 是否仍需单独法规页：
+- 是否需要在结果里展示来源版本：
+
+为什么要问：
+
+- 这会影响顶层导航是否继续精简，以及法规解释的展示形态。
+
 ### Q15 后台知识库更新入口由谁使用？
 
 建议提问方式：