主题
FDS-01 · 整体架构与数据/控制流
把"整体架构"一次讲完整讲清楚:分几层、谁是谁、数据怎么流、谁触发、出错怎么办、和 deer-flow 什么关系。配三张图。
1. 分层架构(谁负责什么)
一句话:用户在工作台操作 → 流水线(代码骨架,跑在 deer-flow 引擎上)按步处理,业务判断交给技能 → 确认事实进自建事实库 → 下游全从事实库读 → 回到用户。
层职责:
- ① 前端:已有项目工作台,加会议建档、结果查看(可点出处)、确认任务、待办/看板。
- ② 流水线骨架(代码):固定步骤、可中断可续跑——这是正确性与可控性的载体,不交给模型自由发挥。
- ③ 技能层:精修/抽取/纪要/复盘的"业务规则"写成技能文件,业务人能读改、git 版本。
- ④ 事实库(地基):全模块唯一真相,详 FDS-17。
- ⑤ 下游:只读事实库,不再重啃录音(这是"慢/不准/不可追溯"的根)。
- 引擎:只用不改其内核(红线)。
2. 数据流(一场会议的数据怎么走)
要点:每条信息从抽取起就带"原文第几字到第几字";程序校验真伪;只有确认/校验过的进事实库;下游只认事实库。 上游(纪要)被人改 → 触发该会重抽,版本化失效(单向数据流)。
3. 控制流(谁触发、怎么停怎么续)
- 触发(两种对等,来自 05 模型双触发):
- 用户主动:上传材料/点"分析"。
- 系统自动:新文件入库事件触发;定时(每周/月)触发复盘。
- 中断-续跑:流水线跑到"存疑"时,暂停并把状态存住,生成确认任务派给负责人;人答 → 从暂停处继续,只重算受影响项,不整场重来。此机制复用 deer-flow 已有、且已被线上功能 ba_report 验证过的做法,不自造。
- 失败处理:技术性失败(超时/解析失败)有限重试;语义不确定一律转人工(不让模型瞎猜)——对应原始需求"AI 与人共写"。
4. 与 deer-flow 的关系(边界清楚,不碰只读内核)
| 部分 | 归属 | 说明 |
|---|---|---|
| 跑图引擎、技能加载、中断/续跑机制、IM 通道、文件转换 | deer-flow 引擎,只用不改 | 红线:vendored 内核只读 |
| 会议处理流水线(把步骤串成图,注册进引擎) | 🟡 基于 deer-flow,新增在扩展位 | 照 ba_report 范式写(已上线验证) |
| 精修/抽取/纪要/复盘 技能文件 | 🟡 放进技能目录 | 业务人可改、git 版本 |
| 项目事实库、出处校验、存疑异步派人层、待办池、跨会真关联 | 🔴 acdm-backend 自建 | deer-flow 没有或不胜任(详 FDS-03/17) |
为什么不复用现有"会议聚合"代码:读过其真实源码——它是一次性请求跑完、无中断无持久、关联实际只按会议日期算(语义/实体比对被关掉),是"先能跑"的半成品。复用对象选已上线做对了的 ba_report 范式,不是它。
5. 运行时与落位(不新增重型组件)
- 流水线/技能:跑在现有
deer-flow-langgraph容器(引擎)。 - 事实库、出处校验、待办、确认层、跨会取数:在现有
acdm-backend服务 + 现有 PostgreSQL,新增表与接口,不新增中间件/消息队列等重组件。 - 通知:站内(项目工作台 / 待办面板提醒);不接飞书等外部 IM(见 FDS-00 〇)。
- ASR(B2):直接接 API,用 Qwen-3ASR 或 fun-ASR;后置专项,人工上传文字稿兜底,不阻塞其余。
6. 可逆与一致(对应原始需求"全链路可逆""单向数据流")
- 事实库写入走事务;对象软删 + 回收站(沿用项目已有可逆存储 substrate)。
- 唯一真相在事实库:上游(纪要/精修)变更 → 版本失效 → 受影响项重算并需重新确认;下游永远读事实库当前版本,不各存一份(杜绝多处数据打架)。
7. 现状(基于代码核查)
现有实现:会议聚合是一次性请求跑完、无中断/续跑/逐步持久化;跨会关联因实体表为空、相似度退化,实际只按"开会日期接近"算。本方案据此重建编排为 ba_report 范式(可中断、可续跑、按步存),并把唯一真相迁到自建事实库。
下一章 FDS-02:把原始需求逐层对到本架构,逐条给"期望 / 现状 / 怎么做 / 验收",确保一条不漏。