diff --git a/README.md b/README.md
index 946e483..c0658f9 100644
--- a/README.md
+++ b/README.md
@@ -28,13 +28,31 @@ V1 采用：
 
 当前系统围绕以下注册申报审核闭环展开：
 
-1. 导入注册资料。
-2. 汇总文件目录与页数。
-3. 对照法规要求检查完整性。
-4. 抽取产品关键信息。
-5. 自动填入注册申报表格或对照清单。
-6. 核查跨文档一致性。
-7. 输出风险预警与处理建议。
+1. 导入注册资料包。
+2. 解析资料包并识别产品名称。
+3. 以解析后的产品名称创建或绑定对话会话。
+4. 汇总文件目录与页数。
+5. 对照法规要求检查完整性。
+6. 抽取产品关键信息。
+7. 自动填入注册申报表格或对照清单。
+8. 核查跨文档一致性。
+9. 输出风险预警、处理建议和飞书通知。
+
+## 当前产品形态
+
+当前原型和需求文档已经统一为 Agent 化产品形态，顶层入口固定为：
+
+1. `审核智能体`
+2. `资料包`
+3. `知识库`
+4. `处理历史`
+
+对应关系如下：
+
+1. `审核智能体` 是主执行入口，承载对话、模板提问、节点跳转和结构化结果。
+2. `资料包` 是主业务对象，资料包与会话绑定，对话标题采用解析后的产品名称，并支持按产品名称或批次号搜索。
+3. `知识库` 负责法规资料、业务资料、RAG 切片、字段 Schema、模板映射和飞书配置治理。
+4. `处理历史` 用于按批次回看历史任务、关联会话、风险状态和通知留痕。
 
 ## 模块划分
 
@@ -137,13 +155,14 @@ V1 暂不重点做：
 
 拿到题目后：
 
-1. 判断题目属于哪类模板。
-2. 复制最接近的 YAML 场景配置。
+1. 判断资料包、规则依据和核心审核链路。
+2. 调整最接近的任务 YAML 配置。
 3. 修改 Agent 角色、目标、指令和输出模板。
-4. 上传题目材料。
-5. 如需业务计算，新增一个工具函数。
-6. 用 2 到 3 个问题测试效果。
-7. 演示场景配置、知识库引用、工具调用、结构化输出和审计日志。
+4. 上传题目材料并生成资料包。
+5. 确认产品名称解析、资料包绑定和会话标题是否正确。
+6. 如需业务计算，新增一个工具函数。
+7. 用 2 到 3 个预设问题测试目录汇总、完整性检查和字段抽取。
+8. 演示对话节点、知识库引用、结构化输出、飞书通知和审计日志。
 
 ## 当前页面概览
 
@@ -151,12 +170,10 @@ V1 暂不重点做：
 
 | 页面 | 路径 | 当前能力 |
 |---|---|---|
-| 场景首页 | `/` | 展示场景名称、描述、适用题型、RAG 状态、工具数和配置异常摘要 |
-| 对话页 | `/chat/<scenario_id>/` | 输入问题、勾选已入库文档、查看结构化结果、引用片段、工具调用和审计入口 |
-| 文档列表页 | `/documents/` | 查看文档状态、错误信息、上传时间并手动触发入库 |
-| 文档上传页 | `/documents/upload/` | 选择场景并上传 `.txt`、`.md`、`.pdf`、`.docx` 文件 |
-| 审计列表页 | `/audit/` | 查看执行摘要并按场景筛选 |
-| 审计详情页 | `/audit/<log_id>/` | 查看输入、最终回答、结构化输出、引用、工具调用、原始输出和错误信息 |
+| 审核智能体 | `/chat/<scenario_id>/` 或后续统一工作台入口 | 输入问题、上传附件、触发任务模板、查看节点结果、结构化输出、引用片段、工具调用和审计入口 |
+| 资料包 | `/documents/` 及相关上传入口 | 查看资料包、文件状态、页数、解析结果、按产品名称搜索并跳转关联会话 |
+| 知识库 | 后续治理页 / 原型页 | 管理法规资料、业务资料、切片、模板映射、责任人映射和飞书配置 |
+| 处理历史 | `/audit/` 及详情页 | 查看执行摘要、最终回答、结构化输出、引用、工具调用、通知状态和错误信息 |
 
 ## 计划启动方式
 
@@ -249,9 +266,21 @@ docker compose config
 ## 文档入口
 
 - [V1 总需求文档](docs/需求分析/1.V1总需求文档.md)
-- [模块需求文档索引](docs/需求分析/2.模块需求索引.md)
-- [智能体总体设计](docs/设计文档/1.智能体总体设计.md)
-- [设计文档索引](docs/设计文档/0.设计文档索引.md)
+- [需求重构总览与待确认事项](docs/需求分析/0.需求重构总览与待确认事项.md)
+- [Config 模块需求分析](docs/需求分析/1.config模块需求分析.md)
+- [Scenarios 模块需求分析](docs/需求分析/2.scenarios模块需求分析.md)
+- [Documents 模块需求分析](docs/需求分析/3.documents模块需求分析.md)
+- [Chat 模块需求分析](docs/需求分析/4.chat模块需求分析.md)
+- [Audit 模块需求分析](docs/需求分析/5.audit模块需求分析.md)
+- [Agent Core 模块需求分析](docs/需求分析/6.agent_core模块需求分析.md)
+- [业务确认问答清单](docs/需求分析/9.业务确认问答清单.md)
+- [资料包导入与目录汇总详细设计](docs/详细设计/1.资料包导入与目录汇总.md)
+- [法规完整性检查详细设计](docs/详细设计/2.法规完整性检查.md)
+- [字段抽取与统一字段池详细设计](docs/详细设计/3.字段抽取与统一字段池.md)
+- [一致性核查详细设计](docs/详细设计/4.一致性核查.md)
+- [风险预警详细设计](docs/详细设计/5.风险预警.md)
+- [Word 回填导出详细设计](docs/详细设计/6.Word回填导出.md)
+- [飞书通知详细设计](docs/详细设计/7.飞书通知.md)
 - [注册审核平台整体原型设计](F:\PyCharm\DEMO-AGENT\docs\原型设计\1.整体原型设计.md)
 - [原型设计目录](F:\PyCharm\DEMO-AGENT\docs\原型设计)
 - [单文件演示站 HTML](F:\PyCharm\DEMO-AGENT\docs\原型设计\registration-prototype-demo.html)
@@ -262,5 +291,6 @@ docker compose config
 当前仓库已补充一套围绕注册申报审核主线的原型设计资产，供复试讲解、方案评审和后续页面实现直接参考：
 
 - 原型文档采用“总览 + 分页细设计”方式组织，覆盖资料包导入、审核任务工作台、法规完整性检查、字段抽取与字段池、一致性核查、风险预警、Word 回填导出、飞书通知视图和知识库治理台。
-- `docs/原型设计/registration-prototype-demo.html` 提供单文件可交互 mock 演示站，内含 8 个主页面视图和知识库 / 治理台 CRUD 抽屉。
+- `docs/原型设计/registration-prototype-demo.html` 提供单文件可交互 mock 演示站，当前已重构为 Agent 化界面，顶层为 `审核智能体 / 资料包 / 知识库 / 处理历史`。
+- 资料包与对话会话已在原型中绑定，对话标题采用解析后的产品名称，资料包页支持按产品名称搜索并跳转对应会话。
 - 该演示站仅使用 mock 数据，不依赖 Django 路由或真实 Agent Core 执行结果。
diff --git a/docs/需求分析/0.需求重构总览与待确认事项.md b/docs/需求分析/0.需求重构总览与待确认事项.md
index adf1593..46c4cc7 100644
--- a/docs/需求分析/0.需求重构总览与待确认事项.md
+++ b/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. 结论
 
diff --git a/docs/需求分析/1.config模块需求分析.md b/docs/需求分析/1.config模块需求分析.md
index d84bbce..c5d5af1 100644
--- a/docs/需求分析/1.config模块需求分析.md
+++ b/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. 本模块验收标准
 
diff --git a/docs/需求分析/2.scenarios模块需求分析.md b/docs/需求分析/2.scenarios模块需求分析.md
index 1ecca7c..737d8a8 100644
--- a/docs/需求分析/2.scenarios模块需求分析.md
+++ b/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 切换到具体业务题。
 
diff --git a/docs/需求分析/9.业务确认问答清单.md b/docs/需求分析/9.业务确认问答清单.md
index 3e5e1b0..d996bd0 100644
--- a/docs/需求分析/9.业务确认问答清单.md
+++ b/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 后台知识库更新入口由谁使用？
 
 建议提问方式：