docs(需求分析): 按Agent原型重写核心需求
This commit is contained in:
@@ -2,261 +2,103 @@
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
`apps.audit` 在本题中绝不能只被理解为“对话历史”。对于注册申报资料准备与审核系统，它的定位应当是：
|
||||
`apps.audit` 在最新版产品形态中对应：
|
||||
|
||||
> 合规审查留痕与复核中心
|
||||
> 处理历史与审计留痕中心
|
||||
|
||||
因为本题输出的是“资料是否齐套、字段是否一致、哪里有合规风险”，这类结果天然需要留痕、可回溯、可解释。
|
||||
它不仅保存对话历史，还要保存资料包、节点执行、风险结论和飞书通知的完整链路。
|
||||
|
||||
## 2. 模块目标
|
||||
|
||||
本模块需要实现以下目标：
|
||||
1. 记录每次 Agent 审核任务。
|
||||
2. 记录资料包与会话绑定关系。
|
||||
3. 记录节点执行结果与最终风险状态。
|
||||
4. 记录飞书通知触发、接收人和回执。
|
||||
5. 支持处理历史页按批次回看任务。
|
||||
|
||||
1. 对每一次资料审核、字段抽取、完整性检查和风险预警形成可查询记录。
|
||||
2. 保留输入条件、处理范围、输出结果、证据来源和失败原因。
|
||||
3. 为演示“系统不是黑盒”提供直接支撑。
|
||||
4. 在不泄露敏感信息的前提下，支持问题追溯和结果复核。
|
||||
5. 为 Web 端与飞书端的多入口执行留存统一审计链路。
|
||||
## 3. 审计对象
|
||||
|
||||
## 3. 为什么本题对审计要求更高
|
||||
V1 至少需要覆盖：
|
||||
|
||||
在普通问答 Demo 中，审计模块往往只是锦上添花。但在本题里，审计本身就是业务可信度的一部分，原因包括：
|
||||
1. 资料包导入任务
|
||||
2. 目录汇总任务
|
||||
3. 完整性检查任务
|
||||
4. 字段抽取任务
|
||||
5. 一致性核查任务
|
||||
6. 风险预警任务
|
||||
7. 飞书通知任务
|
||||
|
||||
1. 注册申报属于强监管场景，任何自动结论都应能追溯。
|
||||
2. 题面明确要求输出风险预警和处理建议，这些建议后续可能影响资料补正方向。
|
||||
3. 当前样例中已经出现跨文档冲突、二次申报、历史临床资料替换等复杂情境，没有审计留痕会很难解释系统为何得出某个结论。
|
||||
## 4. 关键字段
|
||||
|
||||
## 4. 核心职责
|
||||
### 4.1 基础字段
|
||||
|
||||
### 4.1 执行留痕
|
||||
1. `audit_id`
|
||||
2. `batch_id`
|
||||
3. `conversation_id`
|
||||
4. `product_name`
|
||||
5. `task_type`
|
||||
6. `status`
|
||||
7. `created_at`
|
||||
|
||||
记录每次任务执行的基本信息：
|
||||
### 4.2 节点结果字段
|
||||
|
||||
- 执行时间
|
||||
- 操作人
|
||||
- 任务类型
|
||||
- 使用场景
|
||||
- 输入问题
|
||||
- 选中文档范围
|
||||
- 申报批次
|
||||
1. `node_name`
|
||||
2. `node_status`
|
||||
3. `node_summary`
|
||||
4. `source_report_ids`
|
||||
|
||||
### 4.2 处理结果留痕
|
||||
### 4.3 飞书留痕字段
|
||||
|
||||
记录：
|
||||
1. `trigger_source`
|
||||
2. `notify_reason`
|
||||
3. `owner_role`
|
||||
4. `feishu_user_id`
|
||||
5. `feishu_open_id`
|
||||
6. `feishu_name`
|
||||
7. `feishu_message_id`
|
||||
8. `message_status`
|
||||
9. `error_message`
|
||||
|
||||
- 最终自然语言回答
|
||||
- 结构化结果
|
||||
- 风险清单
|
||||
- 回填字段结果
|
||||
- 缺失文件清单
|
||||
## 5. 处理历史页要求
|
||||
|
||||
### 4.3 证据留痕
|
||||
处理历史页应展示：
|
||||
|
||||
记录：
|
||||
1. 批次号
|
||||
2. 产品名称
|
||||
3. 任务名称
|
||||
4. 时间
|
||||
5. 风险状态
|
||||
6. 资料规模
|
||||
7. 最终结果
|
||||
8. 节点链路
|
||||
|
||||
- 引用文档
|
||||
- 引用片段
|
||||
- 命中的法规条目或目录项
|
||||
- 使用的规则版本
|
||||
- 工具调用过程
|
||||
## 6. 飞书协同留痕要求
|
||||
|
||||
### 4.4 异常留痕
|
||||
在 V1 中，飞书通知有两个固定触发时机：
|
||||
|
||||
记录：
|
||||
1. 审核任务执行完成
|
||||
2. 审核任务执行异常
|
||||
|
||||
- 解析失败
|
||||
- 入库失败
|
||||
- 规则缺失
|
||||
- 模型调用失败
|
||||
- 输出冲突待人工确认
|
||||
两类通知都必须在审计中保留：
|
||||
|
||||
本题尤其需要保留失败和不确定状态，而不只是保存成功记录。
|
||||
1. 谁被 `@`
|
||||
2. 为什么被 `@`
|
||||
3. 发送是否成功
|
||||
4. 是否有 Web 详情页回链
|
||||
|
||||
## 5. 审计对象定义
|
||||
## 7. 与角色信息的关系
|
||||
|
||||
建议将审计对象扩展为以下几类：
|
||||
审计模块必须能记录责任人实体中的飞书字段，至少包括：
|
||||
|
||||
1. 资料目录汇总任务
|
||||
2. 完整性检查任务
|
||||
3. 字段抽取任务
|
||||
4. 一致性核查任务
|
||||
5. 风险预警任务
|
||||
6. 手工重试、重新入库、重新核查等操作
|
||||
1. `owner_role`
|
||||
2. `owner_name`
|
||||
3. `feishu_user_id`
|
||||
4. `feishu_open_id`
|
||||
5. `feishu_name`
|
||||
|
||||
这样可以避免审计模块只能记录“聊天问答”，却看不到文件处理和重跑过程。
|
||||
## 8. 验收标准
|
||||
|
||||
## 6. 审计记录字段需求
|
||||
|
||||
### 6.1 基础字段
|
||||
|
||||
- `audit_id`
|
||||
- `task_type`
|
||||
- `scenario_id`
|
||||
- `project_id`
|
||||
- `submission_batch_id`
|
||||
- `created_at`
|
||||
- `status`
|
||||
|
||||
### 6.2 输入字段
|
||||
|
||||
- 用户输入问题
|
||||
- 执行参数
|
||||
- 选中文档 ID 列表
|
||||
- 章节点范围
|
||||
- 规则版本
|
||||
- 模型名称
|
||||
- 触发入口类型（Web / 飞书群聊 / 飞书评论 / 飞书应用会话）
|
||||
- 飞书会话或消息标识
|
||||
|
||||
### 6.3 输出字段
|
||||
|
||||
- 最终摘要
|
||||
- 结构化输出 JSON
|
||||
- 风险等级
|
||||
- 是否通过
|
||||
- 是否存在人工复核项
|
||||
- 缺失项数量
|
||||
- 冲突项数量
|
||||
|
||||
### 6.4 证据字段
|
||||
|
||||
- 引用文档信息
|
||||
- 引用片段
|
||||
- 工具调用结果
|
||||
- 命中规则项
|
||||
- 风险评分明细
|
||||
|
||||
### 6.5 错误字段
|
||||
|
||||
- 错误类型
|
||||
- 错误信息
|
||||
- 失败阶段
|
||||
- 是否可重试
|
||||
|
||||
## 7. 与题面强相关的审计需求
|
||||
|
||||
### 7.1 对完整性检查结果留痕
|
||||
|
||||
当系统判断“缺少临床评估报告”或“缺少某项监管声明”时，应能回查：
|
||||
|
||||
- 是依据哪一版规则判断的
|
||||
- 当前已识别到哪些资料
|
||||
- 哪些资料被判定未命中
|
||||
|
||||
### 7.2 对一致性冲突留痕
|
||||
|
||||
当系统判定：
|
||||
|
||||
> 说明书与申请表中的产品名称不一致
|
||||
|
||||
则审计中必须保留：
|
||||
|
||||
- 冲突字段名
|
||||
- 冲突值
|
||||
- 对应来源文档
|
||||
- 判定时间
|
||||
- 所属审核范围
|
||||
|
||||
当前项目目标是通用试剂盒注册审核智能体，因此审计还必须能够说明“这些文档为什么会被纳入同一轮一致性核查”，否则冲突结论容易失真。
|
||||
|
||||
### 7.3 对历史申报说明的审计价值
|
||||
|
||||
`CH1.9` 涉及历史受理号、撤回、临床数据替换等事项，若系统在风险报告中引用这部分内容，应在审计中保留相关证据链，方便后续说明“为什么标记为历史事项风险”。
|
||||
|
||||
## 8. 页面需求
|
||||
|
||||
### 8.1 审计列表页
|
||||
|
||||
列表页不应仅展示“问了什么问题”，还应体现业务摘要。建议展示：
|
||||
|
||||
- 执行时间
|
||||
- 任务类型
|
||||
- 项目 / 批次
|
||||
- 状态
|
||||
- 风险等级
|
||||
- 缺失项数
|
||||
- 冲突项数
|
||||
- 是否需人工复核
|
||||
|
||||
### 8.2 审计详情页
|
||||
|
||||
详情页建议展示：
|
||||
|
||||
- 输入问题与参数
|
||||
- 结果摘要
|
||||
- 结构化结果
|
||||
- 引用证据
|
||||
- 工具调用
|
||||
- 原始输出
|
||||
- 错误信息
|
||||
- 脱敏后的上下文信息
|
||||
|
||||
## 9. 脱敏与安全要求
|
||||
|
||||
### 9.1 不能写入敏感密钥
|
||||
|
||||
这一点与 AGENTS 约定一致，日志中不能保存：
|
||||
|
||||
- API Key
|
||||
- 密钥类环境变量
|
||||
- 不必要的鉴权头
|
||||
|
||||
### 9.2 业务敏感信息控制
|
||||
|
||||
虽然当前题目材料以产品注册资料为主，但后续真实环境中可能包含：
|
||||
|
||||
- 企业联系人
|
||||
- 手机号 / 邮箱
|
||||
- 临床机构信息
|
||||
- 受理号
|
||||
|
||||
首版至少要具备“展示层脱敏”的设计意识。
|
||||
|
||||
### 9.3 原始输出保留边界
|
||||
|
||||
如果 LLM 原始输出中包含大量无效 prompt 内容或潜在敏感字段，应允许：
|
||||
|
||||
- 存摘要，不存完整原文
|
||||
- 或仅对管理员展示原始输出
|
||||
|
||||
## 10. 与其他模块的边界
|
||||
|
||||
### 10.1 与 Chat 模块
|
||||
|
||||
Chat 是主要触发入口；Audit 负责把执行结果沉淀为可追踪记录。
|
||||
|
||||
### 10.2 与 Documents 模块
|
||||
|
||||
Documents 提供文档处理事实；Audit 负责记录这些事实如何被某次审核任务引用。
|
||||
|
||||
### 10.3 与 Agent Core 模块
|
||||
|
||||
Agent Core 负责产出结论与证据；Audit 负责记录这些产出及其上下文。
|
||||
|
||||
## 11. 当前代码基线下的重构建议
|
||||
|
||||
### 11.1 建议保留
|
||||
|
||||
- 审计列表与详情页骨架
|
||||
- 原始输出展示能力
|
||||
- 敏感信息脱敏思路
|
||||
- 成功与失败均记录的机制
|
||||
|
||||
### 11.2 建议增强
|
||||
|
||||
1. 将“对话日志”扩展为“任务执行审计”。
|
||||
2. 增加项目批次、任务类型、章节点范围、规则版本等字段。
|
||||
3. 增加缺失项数、冲突项数、人工复核标记等业务指标。
|
||||
4. 增加法规命中项、字段来源和风险依据的留痕。
|
||||
5. 增加飞书触发来源、回传状态和责任人通知记录。
|
||||
|
||||
## 12. 验收标准
|
||||
|
||||
本模块验收时，应达到以下状态：
|
||||
|
||||
1. 每次关键审核任务都能形成完整审计记录。
|
||||
2. 审计详情足以解释“系统为什么得出这个结论”。
|
||||
3. 成功、失败和待人工复核都可记录。
|
||||
4. 页面层可快速筛选高风险或异常记录。
|
||||
5. 敏感密钥不会进入审计内容。
|
||||
6. 审计中能够明确体现“任一高风险即不通过”的最终判定依据。
|
||||
1. 处理历史页能回看历史审核任务。
|
||||
2. 能从历史中看出资料包、产品名称和对话的对应关系。
|
||||
3. 飞书通知的完成态和异常态都能留痕。
|
||||
4. 审计详情足以解释“为什么通知了这个处理人”。
|
||||
|
||||
Reference in New Issue
Block a user