Tender Service 智能标书系统架构设计¶

文档版本：V1.0 编制日期：2026-07-23 文档性质：系统架构设计 事实基线：Tender Service 当前代码、数据模型、任务队列与部署结构 配套文档：系统架构与完整功能清单、MVP v1 接口总览

1. 概述¶

招投标业务是一类典型的知识密集型、时间约束型和强合规型业务。

一份招标文件通常包含项目背景、采购需求、技术参数、商务条款、资格条件、评分标准、交付要求等大量信息。不同内容分散在正文、表格、附件和补充文件中，既有明确条款，也存在需要结合上下文才能判断的隐含约束。

标书编制并不是简单的文字生成，而是一个连续的业务过程：

1. 准确理解招标文件。
2. 识别必须响应的要求。
3. 规划投标文件结构。
4. 调用企业知识与项目素材。
5. 完成不同章节的内容编制。
6. 持续检查内容完整性和一致性。
7. 形成可编辑、可交付的正式文档。

Tender Service 围绕这一过程构建智能标书生产体系，将文档解析、大模型生成、企业知识检索、产品与图片素材、任务调度和文档输出整合为统一系统。

系统的核心目标不是用一次模型调用生成整本标书，而是把招标文件理解、内容规划、知识调用、正文生成和成果输出拆解为可管理、可追踪、可恢复的业务链路，使 AI 能力真正进入标书编制流程。

2. 业务背景与问题分析¶

2.1 招标文件理解成本高¶

招标文件篇幅长、格式复杂，内容可能同时存在于 PDF、Word、Excel 和附件中。项目概况、评分标准、技术要求、资格条件和关键时间节点分散在不同章节，人工研读容易出现遗漏。

传统处理方式通常存在以下问题：

• 文件格式和排版差异导致内容提取困难。
• 关键信息依赖人工逐页查找。
• 结构化结果与原始文件脱节。
• 不同人员对同一条款的理解不一致。
• 文件发生替换后，历史解析结果难以安全更新。

2.2 标书编制周期长¶

标书正文由多个章节组成，每个章节需要结合招标要求、评分标准、企业能力、产品参数和历史案例进行编写。

如果只使用通用文本生成，容易出现：

• 目录结构与招标要求不匹配。
• 正文缺少项目上下文。
• 各章节表述重复或相互矛盾。
• 产品、资质和案例信息无法准确引用。
• 长时间生成任务中断后需要从头开始。

2.3 企业知识分散¶

企业知识通常分散在历史标书、产品资料、资质文件、案例材料、图片素材和个人经验中。缺少统一管理时，编制人员需要反复寻找和复制内容，难以形成组织级知识资产。

知识管理面临的不只是“文件能否上传”，还包括：

• 文件能否稳定解析。
• 内容能否被切分和检索。
• 新版本能否安全替换旧版本。
• 检索结果能否进入生成上下文。
• 不同用户之间能否保持数据隔离。

2.4 AI 长任务需要工程化保障¶

文档解析、知识向量化和全文生成都属于长时间任务，不能依赖单个 HTTP 请求持续执行。

系统需要处理：

• 任务排队和并发限制。
• 任务进度实时反馈。
• 用户主动取消。
• Worker 异常退出。
• 网络、模型和存储临时故障。
• 重试时的数据幂等。
• 生成额度的预占和结算。
• 服务重启后的任务恢复。

2.5 输出成果必须可编辑、可交付¶

AI 生成的内容最终必须进入正式投标文件，而不是停留在对话框中。

系统需要保持目录、正文、样式和素材之间的结构关系，并输出符合办公场景要求的 Word 文档，支持用户继续编辑、审阅和提交。

3. 建设目标¶

Tender Service 的建设目标可以归纳为五个方面。

3.1 建立招标文件智能理解能力¶

将不同格式的招标文件统一转换为可处理文本，并进一步提取项目概况、采购需求、评分标准等结构化信息，为后续目录规划和正文生成提供统一事实基础。

3.2 建立端到端标书编制能力¶

覆盖标书创建、文件解析、目录生成、编写思路、章节正文、一键全文生成和 Word 输出，形成连续的标书生产流程。

3.3 建立企业知识融合能力¶

统一管理知识文档、产品数据、清单附件和图库素材，在生成正文前按项目和章节语义检索相关内容，使生成结果建立在企业真实资料之上。

3.4 建立可靠的 AI 任务运行体系¶

通过持久化任务、独立 Worker、任务状态机、租约、心跳、重试和恢复机制，使耗时 AI 任务具备可追踪、可取消、可恢复和可结算能力。

3.5 建立可运营、可演进的平台能力¶

将 Prompt、模型、场景绑定、额度、套餐、支付、日志和管理功能平台化，使系统能够在不同项目类型和业务阶段持续调整，而不依赖频繁修改核心代码。

4. 设计原则¶

4.1 业务流程优先¶

AI 能力必须服从标书编制流程。系统首先明确业务状态、输入输出和人工决策点，再决定模型在哪个环节参与。

4.2 结构化优先¶

招标文件不是一段普通文本。项目概况、采购要求、评分项、目录节点、编写思路和章节正文必须分别建模，避免把全部业务状态压缩到一个 Prompt 中。

4.3 确定性流程与概率性模型分离¶

任务流转、权限、额度、版本切换和数据写入由确定性代码控制；文档理解、语义检索和内容生成由模型完成。

模型可以提出结果，但不能直接决定系统事务是否完成。

4.4 生成前组织上下文¶

系统不把所有资料无差别塞入模型，而是根据标书、目录节点和业务场景组装上下文。上下文工程是生成质量的核心组成部分。

4.5 人机协同¶

AI 负责降低阅读、检索和初稿编制成本，用户保留目录调整、编写思路确认、正文修改、素材选择和最终交付权。

4.6 长任务异步化¶

文档解析、知识摄取、图片理解、产品解析和全文生成均通过任务队列执行。API 只负责创建任务、查询状态和传递事件。

4.7 数据可恢复¶

重要任务状态必须写入 PostgreSQL。Redis 用于队列、实时事件、缓存和临时协调，不作为关键业务结果的唯一存储。

4.8 多租户安全¶

用户数据从数据库查询、对象存储路径、缓存 key、向量检索到任务执行全过程保持隔离。

5. 系统边界¶

5.1 系统负责¶

• 用户登录、身份识别和数据隔离。
• 招标文件与业务附件上传。
• PDF、DOC、DOCX、XLS、XLSX 内容提取。
• 项目概况、需求和评分标准解析。
• 标书目录规划和人工调整。
• 编写思路生成与维护。
• 单章和全文正文生成。
• 企业知识库管理与语义检索。
• 产品资料解析和结构化。
• 图库管理、图片理解和文档抽图。
• 清单附件解析。
• Word 文档输出。
• Prompt 模板、版本和场景绑定。
• AI 任务调度、进度、取消、重试和恢复。
• 字数额度、订阅、订单和支付。
• 管理与运行审计。

5.2 系统当前不直接负责¶

• 招标公告采集和商机发现。
• CA 签章和电子投标平台提交。
• 投标报价决策。
• 法律意义上的自动合规结论。
• 完全无人参与的投标决策。

这些能力可以通过后续集成或独立领域服务扩展，但不应与当前标书生产核心链路混在一起。

6. 业务能力架构¶

6.1 一页式系统能力总图¶

flowchart TB
    subgraph Access["用户与接入层"]
        direction LR
        UserWeb["用户端前台<br/>项目、解析、目录、正文"]
        AdminWeb["管理后台<br/>Prompt、用户、套餐、日志"]
        API["统一 API / SSE<br/>认证、查询、实时进度"]
        MainFlow["标书生产主流程<br/>解析 → 规划 → 生成 → 编辑 → 导出"]
    end

    subgraph Business["业务能力层"]
        direction TB
        subgraph TenderDomain["智能标书生产"]
            direction LR
            Parse["招标文件智能解析<br/>概况、需求、评分标准"]
            Outline["目录与编写规划<br/>骨架、节点、思路"]
            Generate["内容智能生成<br/>单章、全文、AI 对话"]
            Deliver["成果输出<br/>正文编辑、Word 导出"]
        end

        subgraph AssetDomain["企业知识与素材"]
            direction LR
            Knowledge["知识库与 RAG<br/>解析、切块、向量检索"]
            Product["企业产品库<br/>Excel 解析、产品结构化"]
            Image["智能图库<br/>文档抽图、图片理解"]
            Checklist["清单附件<br/>PDF、Word、Excel 解析"]
        end

        subgraph PlatformDomain["平台运营与治理"]
            direction LR
            Tenant["用户与多租户<br/>JWT、角色、数据隔离"]
            PromptOps["Prompt 运营<br/>模板、版本、场景绑定"]
            TaskOps["任务运营<br/>状态、进度、取消、恢复"]
            Billing["额度与商业化<br/>订阅、订单、支付、流水"]
        end
    end

    subgraph Intelligence["智能编排与 AI 能力层"]
        direction LR
        Workflow["业务工作流编排<br/>FastAPI + Service + 状态机"]
        Context["上下文工程<br/>ContextAssembler"]
        PromptEngine["Prompt 解析引擎<br/>行业、角色、场景匹配"]
        RAGEngine["RAG 引擎<br/>Chunk + Embedding + Retrieval"]
        ModelGateway["模型网关<br/>路由、限流、重试、回退"]
        Worker["异步执行集群<br/>8 类 ARQ Worker"]
    end

    subgraph Foundation["数据与基础设施层"]
        direction LR
        PostgreSQL[("PostgreSQL<br/>业务事实与任务状态")]
        Redis[("Redis<br/>队列、SSE、锁、缓存")]
        OSS[("S3 兼容 OSS<br/>文档与图片")]
        Vector[("Qdrant / DashVector<br/>知识向量")]
        Models["LLM / Embedding<br/>文本、视觉、向量模型"]
        External["外部业务服务<br/>短信、支付宝、微信支付"]
    end

    UserWeb --> API
    AdminWeb --> API
    API --> MainFlow
    MainFlow --> Parse
    Parse --> Outline --> Generate --> Deliver

    Knowledge --> Generate
    Product --> Generate
    Image --> Generate
    Checklist --> Generate

    API --> Tenant
    PromptOps --> Parse
    PromptOps --> Outline
    PromptOps --> Generate
    TaskOps --> Parse
    TaskOps --> Generate
    Billing --> Generate

    Business --> Workflow
    Workflow --> Context
    Context --> PromptEngine
    Context --> RAGEngine
    PromptEngine --> ModelGateway
    RAGEngine --> ModelGateway
    Workflow --> Worker

    Workflow --> PostgreSQL
    Worker --> PostgreSQL
    Worker --> Redis
    Worker --> OSS
    RAGEngine --> Vector
    ModelGateway --> Models
    Tenant --> External
    Billing --> External

这张图从上到下表达四个层次：

1. 用户通过前台、管理后台和 API 进入标书生产流程。
2. 业务能力围绕标书生产、企业知识和平台治理组织。
3. 智能编排层负责上下文、Prompt、RAG、模型调用和异步任务。
4. PostgreSQL、Redis、OSS、向量库和外部模型构成运行基础。

flowchart LR
    Project["项目与标书管理"]
    Upload["文件与素材接入"]
    Understand["招标文件智能理解"]
    Plan["目录与编写规划"]
    Knowledge["企业知识与素材检索"]
    Generate["章节与全文生成"]
    Review["人工校对与内容调整"]
    Deliver["Word 成果输出"]
    Operate["Prompt、任务、额度与运营"]

    Project --> Upload
    Upload --> Understand
    Understand --> Plan
    Plan --> Generate
    Knowledge --> Generate
    Generate --> Review
    Review --> Deliver
    Operate -.支撑.-> Understand
    Operate -.支撑.-> Knowledge
    Operate -.支撑.-> Generate

系统能力分为四个层次。

6.2 标书生产能力¶

• 标书项目管理。
• 招标文件解析。
• 项目要点和评分标准提取。
• 目录骨架生成。
• 目录节点编辑和排序。
• 编写思路生成。
• 单章正文生成。
• 一键全文生成。
• 正文人工编辑。
• Word 文档输出。

6.3 企业知识能力¶

• 知识库与知识文件管理。
• 文档提取、切块和向量化。
• 语义检索。
• 知识库助手。
• 产品库与产品资料解析。
• 图库与图片理解。
• 清单附件解析。
• 标书与知识、产品、图片的引用关系。

6.4 AI 运行能力¶

• 模型配置与调用适配。
• Prompt 模板和版本。
• 场景绑定。
• 上下文组装。
• 流式生成。
• 模型限流、重试和回退。
• usage 记录和字数结算。

6.5 平台支撑能力¶

• 用户认证和多租户隔离。
• 通用文件上传。
• 异步任务和 SSE。
• 对象存储。
• 订阅、额度和支付。
• 管理后台。
• 健康检查和运行日志。

7. 核心业务设计¶

7.1 招标文件智能解析¶

招标文件解析采用“文档提取 + 语义理解”两阶段设计。

第一阶段解决文件能否稳定转换为统一文本的问题：

• 客户端通过预签名 URL 将文件直接上传至对象存储。
• API 创建解析任务并将轻量任务 ID 写入 ARQ。
• Worker 从对象存储下载文件。
• 隔离子进程执行 PDF、Word 或 Excel 解析。
• 结果统一转换为 Markdown。
• 原始提取内容写入 PostgreSQL。

第二阶段解决文本如何转换为业务信息的问题：

• 根据场景解析已发布 Prompt。
• 调用解析模型提取项目概况。
• 识别采购需求和关键约束。
• 解析评分标准及评分项。
• 将结构化结果写入独立业务表。
• 通过 Redis Pub/Sub 向前端持续发送解析进度。

两阶段设计使文件解析故障与模型解析故障相互隔离，也使原始 Markdown 可以独立保存、复用和人工检查。

flowchart TD
    Upload["OSS 直传"]
    Confirm["确认上传并创建任务"]
    Extract["隔离进程提取 Markdown"]
    Source["保存原始文本"]
    Analyze["LLM 语义解析"]
    Overview["项目概况"]
    Requirement["采购需求"]
    Scoring["评分标准"]
    Edit["人工校对与修正"]

    Upload --> Confirm --> Extract --> Source --> Analyze
    Analyze --> Overview
    Analyze --> Requirement
    Analyze --> Scoring
    Overview --> Edit
    Requirement --> Edit
    Scoring --> Edit

7.2 目录规划¶

目录是连接招标要求与正文生成的中间结构。

系统先根据项目解析结果生成一二级目录骨架，再允许用户通过以下方式完善：

• 手工创建目录节点。
• 导入外部目录。
• AI 补全不完整目录。
• 调整章节标题和顺序。
• 生成章节候选并确认应用。
• 设置页数和字数预估。
• 为节点生成编写思路。
• 根据编写思路进一步生成子目录。

每个目录节点使用稳定 node_uid 作为业务标识。章节编号发生变化时，编写思路、正文和历史记录仍能关联到同一节点。

目录设计避免将“用户看到的编号”当作永久主键，使目录编辑和正文持久化可以独立演进。

7.3 编写思路¶

编写思路承担招标要求到正文内容之间的规划作用。

它描述一个章节应该回答什么问题、采用什么结构、引用哪些素材、突出哪些能力，而不是直接生成最终正文。

系统支持：

• 按章节标题预览编写思路。
• 按行业和货物角色选择不同 Prompt。
• 保存结构化编写思路 block。
• 用户确认后应用。
• 根据编写思路生成下级目录。
• 在正文生成时将编写思路作为核心上下文。

这一设计把内容规划与内容表达分离，有助于提高长文档结构稳定性。

7.4 章节正文生成¶

正文生成不是单一 Prompt 调用，而是一个上下文装配过程。

ContextAssembler 根据当前章节组装：

• 项目基础信息。
• 当前节点及目录路径。
• 兄弟章节信息。
• 节点编写思路。
• 关联评分标准。
• 手工清单。
• 已解析的清单附件。
• 知识库检索片段。
• 产品资料。
• 图片素材及其理解结果。

组装完成后，系统解析 section_content 场景 Prompt，调用写作模型流式生成，并将最终正文保存到章节表。

flowchart LR
    Node["目录节点"]
    Hint["编写思路"]
    Score["评分要求"]
    Checklist["清单附件"]
    RAG["知识检索"]
    Product["产品资料"]
    Image["图片素材"]
    Context["章节上下文"]
    Prompt["场景 Prompt"]
    LLM["写作模型"]
    Content["章节正文"]

    Node --> Context
    Hint --> Context
    Score --> Context
    Checklist --> Context
    RAG --> Context
    Product --> Context
    Image --> Context
    Context --> Prompt --> LLM --> Content

7.5 一键全文生成¶

全文生成可能包含几十个章节，并持续较长时间，因此使用持久化运行模型。

系统创建：

• 一个 GenerationRun 表示整次全文生成。
• 多个 GenerationSectionJob 表示叶子章节生成任务。

运行过程包括：

1. 读取当前目录树。
2. 找出需要生成的叶子章节。
3. 估算总字数。
4. 预占用户额度。
5. 创建章节任务。
6. 按目录顺序分批入队。
7. Worker 加载章节上下文并生成。
8. 持续更新心跳和进度。
9. 按实际生成字数结算。
10. 收口全文运行和标书状态。

Worker 只接收 run ID 和 job ID，不在 Redis 中保存完整业务上下文。

该设计具有以下优势：

• 队列消息轻量。
• 任务状态可以持久化。
• 服务重启后可以恢复。
• 单章失败可以独立重试。
• 用户可以取消全文运行。
• SSE 丢失时可以从数据库读取最新状态。
• 额度可以按整次运行预占和结算。

7.6 文档成果输出¶

系统将目录、正文、图片和文档样式组合为正式 DOCX。

输出内容包括：

• 封面。
• 项目名称和项目编号。
• 系统免责声明。
• 多级目录标题。
• 章节正文。
• Markdown 表格和列表。
• 富文本内容。
• 图片。
• 用户选择或保存的文档样式。

文档输出与 AI 生成解耦。模型只负责生成内容，Word 服务负责文档结构、样式和文件格式。

8. 知识与素材架构¶

8.1 知识资产分类¶

系统将企业知识按使用方式划分为不同资产：

不同资产采用不同的数据模型和处理方式，不强行统一为一种“知识文件”。

8.2 知识文件摄取¶

知识文件采用版本化摄取：

flowchart TD
    File["知识文件"]
    Parse["文档提取"]
    Chunk["文本切块"]
    Embed["Embedding"]
    Candidate["写入候选版本"]
    Verify["完整性检查"]
    Switch["切换 active_version"]
    Cleanup["清理旧版本"]

    File --> Parse --> Chunk --> Embed --> Candidate --> Verify --> Switch --> Cleanup

关键机制：

• 文件解析在隔离进程执行。
• chunk 元数据保存在 PostgreSQL。
• 向量写入 Qdrant 或 DashVector。
• 新任务使用独立版本。
• 全部写入成功后再切换 active_version。
• 通过版本 fencing 防止旧 Worker 覆盖新任务。
• 定时任务协调长时间未完成的解析任务。

这保证了知识文件重新解析期间，旧版本仍可继续提供检索，不会因半成品索引造成知识库不可用。

8.3 语义检索¶

语义检索流程：

1. 接收用户问题或章节检索请求。
2. 根据配置决定是否改写查询。
3. 生成 query embedding。
4. 在指定知识库和活跃版本范围内检索。
5. 按相似度和业务过滤条件筛选。
6. 控制 top-k 和上下文长度。
7. 返回片段、文件信息和引用元数据。

检索服务同时支撑：

• 知识库助手。
• 正文生成。

公开搜索接口不是必要前提，检索能力作为内部领域服务被不同业务流程复用。

8.4 产品资料结构化¶

产品资料通常来自 Excel，既包含单元格文本，也包含嵌入图片。

产品解析按照阶段执行：

1. 提取文本。
2. 提取图片。
3. 识别产品字段。
4. 分类图片用途。
5. 关联图片与产品。
6. 上传有效图片。
7. 持久化产品。

每个阶段保存执行记录，便于定位错误和恢复任务。产品信息以结构化数据参与正文生成，不依赖全文向量检索。

8.5 图片素材理解¶

图片上传后可异步执行 AI 理解，提取：

• 标题。
• 内容描述。
• 标签。
• 分类。
• 使用场景。
• 建议章节。
• OCR 文本。

系统还支持从 PDF、DOC、DOCX 中抽取图片，先建立短期 extraction session，用户确认后再写入图库。

该设计避免未经确认的大量临时图片污染正式素材库。

9. AI 能力架构¶

9.1 场景化模型调用¶

不同业务任务具有不同的准确率、上下文长度、速度和成本要求。系统通过模型 profile 为以下场景分别配置模型：

• 文档解析。
• 项目概况提取。
• 评分标准提取。
• 目录骨架。
• 编写思路。
• 章节正文。
• AI 对话。
• 产品字段提取。
• 产品图片分类。
• 图库图片理解。
• Embedding。

系统不假设单一模型适合全部任务。

9.2 Prompt 运行平台¶

Prompt 使用数据库模板和版本管理：

• 模板与业务场景解耦。
• 每个模板维护多个版本。
• 草稿版本可编辑。
• 已发布版本进入运行时。
• 单个模板只保留一个当前发布版本。
• 场景绑定支持行业、货物角色和优先级。
• 运行时选择最具体的匹配规则，再回退到通用规则。

当前主要场景包括：

• 招标文件解析。
• 项目概况。
• 评分标准。
• 目录骨架。
• 通用和分类编写思路。
• 根据编写思路生成目录。
• 章节正文。
• 图片理解。

Prompt 管理使业务人员可以在不修改主流程代码的情况下调整模型行为，同时保留版本和发布边界。

9.3 上下文工程¶

系统把上下文分为四类：

上下文由服务端按场景组织，避免客户端自行拼装 Prompt，也避免不同接口形成不一致的知识调用方式。

9.4 工作流式智能协同¶

从系统能力看，招标解析、目录规划、知识检索、正文生成、图片理解和质量控制可以视为多个专业智能能力。

Tender Service 采用“受控工作流”协调这些能力：

flowchart LR
    Orchestrator["业务状态机 / 任务编排"]
    Parser["文档理解能力"]
    Planner["目录规划能力"]
    Retriever["知识检索能力"]
    Writer["内容生成能力"]
    Vision["图片理解能力"]
    Exporter["文档输出能力"]

    Orchestrator --> Parser
    Orchestrator --> Planner
    Orchestrator --> Retriever
    Orchestrator --> Writer
    Orchestrator --> Vision
    Orchestrator --> Exporter

这些能力不直接相互修改状态，而是由 API、Service 和 Worker 组成的业务编排层控制。

这种设计保留了智能能力的专业分工，同时保证任务状态、权限、数据写入和费用结算仍由确定性系统管理。

10. 技术架构¶

10.1 总体技术架构¶

flowchart TB
    subgraph Access["接入层"]
        Web["用户端 Web"]
        Admin["管理后台"]
        Callback["支付平台回调"]
    end

    subgraph Application["应用层"]
        FastAPI["FastAPI Router"]
        Auth["认证与租户上下文"]
        Domain["领域 Service"]
        SSE["SSE 事件接口"]
    end

    subgraph Intelligence["智能能力层"]
        ParseAI["解析模型"]
        OutlineAI["目录与思路模型"]
        WritingAI["正文模型"]
        ChatAI["对话模型"]
        VisionAI["图片理解模型"]
        Embedding["Embedding"]
        Prompt["Prompt 场景平台"]
    end

    subgraph Async["异步执行层"]
        ARQ["Redis + ARQ"]
        Workers["领域 Worker"]
        Cron["Cron 与任务协调"]
    end

    subgraph Data["数据与知识层"]
        PostgreSQL[("PostgreSQL")]
        Redis[("Redis")]
        OSS[("S3 兼容 OSS")]
        Vector[("Qdrant / DashVector")]
    end

    Web --> FastAPI
    Admin --> FastAPI
    Callback --> FastAPI
    FastAPI --> Auth --> Domain
    FastAPI --> SSE
    Domain --> Prompt
    Domain --> ParseAI
    Domain --> OutlineAI
    Domain --> WritingAI
    Domain --> ChatAI
    Domain --> VisionAI
    Domain --> Embedding
    Domain --> ARQ
    ARQ --> Workers
    Cron --> Workers
    Workers --> Domain
    Domain --> PostgreSQL
    Domain --> Redis
    Domain --> OSS
    Domain --> Vector
    SSE --> Redis
    SSE --> PostgreSQL

10.2 模块化单体¶

系统采用模块化单体架构：

• API、Service、模型和 Worker 位于同一代码仓库。
• 业务域通过目录和 Service 边界组织。
• PostgreSQL 是统一事务边界。
• Worker 复用领域 Service。
• 不同 Worker 进程按资源类型独立部署。

这种架构适合当前业务阶段：

• 核心领域之间存在大量事务和上下文共享。
• 单体部署降低跨服务契约和运维复杂度。
• Worker 拆分已经隔离主要计算负载。
• 未来可以按稳定领域边界进一步拆分，而不需要提前引入分布式事务。

10.3 API 与 Worker 分离¶

API 进程负责：

• 请求校验。
• 用户认证。
• 资源所有权检查。
• 轻量事务。
• 创建任务。
• 查询状态。
• SSE 输出。

Worker 进程负责：

• 文档解析。
• 快速结构化解析。
• 章节生成。
• 知识摄取。
• 产品解析。
• 清单解析。
• 图片理解。
• 订阅维护。

不同 Worker 使用独立 Redis queue，防止耗时任务相互阻塞。

10.4 存储分工¶

关键业务完成状态不能只存在 Redis 中。

11. 数据架构¶

系统当前包含 46 张 SQLModel 表，按领域分为：

• 用户与系统。
• 通用任务。
• 标书、解析、目录和正文。
• 全文生成运行和章节 job。
• 知识库、文件、内容和 chunk。
• 产品库、产品和解析阶段。
• 图库和图片。
• Prompt 模板、版本和绑定。
• 订阅、额度、订单和支付。

11.1 标书聚合¶

Tender 是标书业务的聚合根，关联：

• 原始文件与解析内容。
• 项目概况、需求和评分标准。
• 目录 JSON 和目录节点业务标识。
• 编写思路。
• 章节正文。
• 清单附件。
• 知识库、产品和图片引用。
• 文档样式。
• 全文生成运行。

11.2 任务模型¶

系统同时使用两类任务模型：

• IngestionTask：面向通用解析和日志。
• 领域任务表：面向知识、产品、清单和全文生成等需要专门状态的数据。

通用任务提供统一查询和事件能力，领域任务保存业务专属阶段、版本和恢复信息。

11.3 版本模型¶

需要安全替换的内容使用显式版本：

• Prompt 模板版本。
• 知识文件 active version。
• 产品解析 job version。
• 全文生成 run/job。

版本不是展示字段，而是并发控制和运行隔离的一部分。

12. 异步任务与状态设计¶

12.1 任务状态机¶

长任务一般包含：

PENDING
→ QUEUED
→ RUNNING
→ COMPLETED

RUNNING
→ RETRY / FAILED / CANCELLED

不同领域可以增加处理阶段，但必须具备明确终态。

12.2 幂等与并发控制¶

系统通过以下机制控制重复任务：

• 数据库唯一约束。
• Redis claim。
• 任务版本号。
• 行锁和事务。
• 订单状态锁定。
• Worker job ID。
• active version 切换。

任务重试必须读取当前数据库状态，不能默认上一次执行没有产生任何结果。

12.3 租约与心跳¶

全文生成 job 使用租约和心跳判断 Worker 是否仍在处理任务。

Worker 异常退出后，协调任务可以识别过期租约并重新调度。这样既能恢复任务，又能避免两个 Worker 同时写入同一章节。

12.4 取消¶

取消请求先写入数据库状态，Worker 在安全检查点读取取消标记。

系统不依赖强制终止进程来实现业务取消，避免在文件上传、数据库事务或外部模型调用中留下不可预测状态。

12.5 启动恢复¶

API 和 Worker 启动时执行必要协调：

• 检查遗留运行任务。
• 将无法恢复的任务收口为失败。
• 重新协调可恢复 job。
• 迁移旧缓存 key。
• 执行订阅维护补偿。

13. 实时反馈设计¶

系统通过 SSE 向客户端反馈：

• 招标文件解析进度。
• 通用任务日志。
• 子目录生成增量。
• 单章正文生成增量。
• 全文生成进度。
• 知识文件解析。
• 产品文件解析。
• 清单解析。
• 图片分析批次。
• AI 对话。

实时事件主要来自 Redis Pub/Sub。对于全文生成等关键流程，API 同时轮询 PostgreSQL 作为兜底。

SSE 只承担信息传递，不承担业务状态存储。客户端断线重连后，仍可以从任务查询接口恢复当前状态。

14. 额度与交易一致性¶

AI 生成会产生可计量成本，因此额度设计进入任务事务。

14.1 额度来源¶

• 永久额度。
• 月付或年付套餐额度。
• 不限量订阅。
• 年付套餐的周期额度。

14.2 扣减顺序¶

1. 活跃不限量权益。
2. 最早到期的有限套餐额度。
3. 永久额度。

14.3 全文生成结算¶

flowchart LR
    Estimate["估算字数"]
    Reserve["预占额度"]
    Generate["执行生成"]
    Actual["统计实际字数"]
    Settle["结算"]
    Release["释放剩余预占"]
    Extra["补扣超出部分"]

    Estimate --> Reserve --> Generate --> Actual --> Settle
    Settle --> Release
    Settle --> Extra

额度预占避免用户同时启动多个全文任务导致超额使用。所有额度变化写入字数交易流水。

15. 安全架构¶

15.1 身份认证¶

• JWT 访问 token。
• Bearer Authorization。
• SSE 支持 query token。
• 密码使用 PBKDF2-SHA256。
• 短信验证码保存在 Redis。
• 验证码具备冷却、次数和失败限制。

15.2 多租户隔离¶

• 当前用户写入 ContextVar。
• SQLModel 查询钩子自动追加 user_id 条件。
• 关键资源执行显式所有权检查。
• OSS key 包含用户或业务范围。
• Redis key 包含用户和资源标识。
• 向量检索限制知识库和活跃版本。

15.3 管理权限¶

管理员权限通过依赖显式控制，不以 URL 前缀作为唯一依据。

跨租户后台任务和管理查询必须显式声明绕过租户过滤，并在业务层限定查询范围。

15.4 文件安全¶

• 客户端使用短期预签名 URL。
• 服务端确认对象存在和文件元数据。
• 按业务限制扩展名和 MIME。
• 临时抽图和未绑定附件设置过期时间。
• 对象存储密钥不返回客户端。

15.5 密钥管理¶

• 本地环境使用 env 文件。
• 开发和测试可通过 Vault 注入。
• Docker 运行环境依赖外部注入。
• 日志和部署检查只验证配置存在，不输出密钥值。

16. 可靠性设计¶

16.1 故障隔离¶

• API 与计算 Worker 分离。
• 不同业务使用独立 queue。
• Office/PDF 解析运行在隔离子进程。
• 模型调用设置超时和重试。
• 向量版本切换避免半成品索引上线。
• 支付回调使用事务和幂等状态。

16.2 数据一致性¶

• PostgreSQL 事务保护业务写入。
• 任务终态与业务对象状态共同收口。
• 全文生成按实际字数结算。
• 支付成功、支付记录和订阅发放在事务内处理。
• Prompt 发布保证单一生效版本。

16.3 降级¶

• SSE 实时事件不可用时读取数据库状态。
• AI Chat 支持模型回退。
• 知识新版本构建期间继续使用旧版本。
• Vault 不可用时开发命令可以回退到本地 env。

16.4 健康检查¶

• /health/live 用于进程存活。
• /health/ready 检查数据库、Redis 和核心写作模型配置。
• Compose 为 API 和 Worker 配置进程级健康检查。

OSS 和向量库仍需要通过部署脚本或独立监控补充检查，不能只依赖单一 HTTP 健康接口。

17. 可观测性¶

系统当前可观测信息包括：

• API 和 Worker 结构化日志。
• 通用任务日志。
• 解析阶段和进度。
• 产品解析阶段记录。
• 全文生成 run/job 状态。
• Worker 心跳和租约。
• 模型 usage。
• 字数交易流水。
• 支付流水。
• 订阅维护日志。
• 用户操作日志。

建议观测指标按三类组织：

17.1 业务指标¶

• 标书创建量。
• 文件解析成功率。
• 目录生成成功率。
• 单章和全文生成完成率。
• 平均生成字数。
• 知识库引用率。
• Word 导出次数。

17.2 AI 指标¶

• 模型调用成功率。
• 首 token 延迟。
• 总生成耗时。
• token 和字数消耗。
• Prompt 场景错误率。
• RAG 检索耗时和有效召回数。

17.3 运行指标¶

• 各队列积压量。
• Worker 活跃数。
• job 重试率。
• 过期租约数量。
• PostgreSQL 连接与慢查询。
• Redis、OSS、向量库可用性。

18. 部署架构¶

flowchart TB
    Gateway["反向代理 / 网关"]
    API["FastAPI API"]
    GenWorker["Generation Worker"]
    ParseWorker["Tender Parse Worker"]
    KnowledgeWorker["Knowledge Worker"]
    ProductWorker["Product Worker"]
    ChecklistWorker["Checklist Worker"]
    ImageWorker["Image Worker"]
    SubscriptionWorker["Subscription Worker"]
    PostgreSQL[("PostgreSQL")]
    Redis[("Redis")]
    OSS[("OSS")]
    Qdrant[("Qdrant")]
    Model["外部或私有化模型服务"]

    Gateway --> API
    API --> PostgreSQL
    API --> Redis
    API --> OSS
    Redis --> GenWorker
    Redis --> ParseWorker
    Redis --> KnowledgeWorker
    Redis --> ProductWorker
    Redis --> ChecklistWorker
    Redis --> ImageWorker
    Redis --> SubscriptionWorker
    GenWorker --> PostgreSQL
    ParseWorker --> PostgreSQL
    KnowledgeWorker --> PostgreSQL
    ProductWorker --> PostgreSQL
    ChecklistWorker --> PostgreSQL
    ImageWorker --> PostgreSQL
    SubscriptionWorker --> PostgreSQL
    KnowledgeWorker --> Qdrant
    API --> Model
    GenWorker --> Model
    ParseWorker --> Model
    KnowledgeWorker --> Model
    ProductWorker --> Model
    ImageWorker --> Model

部署特点：

• API 与各 Worker 独立容器。
• migration 使用独立执行容器。
• PostgreSQL、Redis、OSS 和向量库作为外部基础设施。
• Worker 可按队列负载单独扩容。
• LibreOffice 安装在需要文档解析的运行镜像中。
• 配置通过 Vault 或部署环境注入。

19. 当前架构能力总结¶

Tender Service 已形成以下完整主链路：

用户登录
→ 创建标书
→ 上传招标文件
→ 文档提取
→ 项目与评分解析
→ 生成并调整目录
→ 生成编写思路
→ 关联知识、产品、图片与清单
→ 单章或全文生成
→ 人工编辑
→ Word 输出

同时具备知识摄取、产品解析、图片理解、Prompt 运营、任务恢复和额度结算等平台能力。

系统的主要架构特征是：

• 以结构化标书数据为核心，而不是只保存对话和生成文本。
• 以业务工作流控制模型，而不是让模型直接控制系统状态。
• 以持久化任务支撑长时间生成。
• 以多类型企业资产构建生成上下文。
• 以数据库 Prompt 版本和场景绑定支撑持续运营。
• 以多租户、额度和支付能力形成完整 SaaS 运行基础。

20. 演进设计¶

后续演进应继续围绕“理解更准确、生成有依据、审核可闭环、协作可追踪”展开。

20.1 原文证据链¶

在文档提取阶段保存：

• 页码。
• 段落和表格位置。
• 文本块标识。
• 原始坐标或锚点。

项目概况、需求和评分项记录来源 block，使结构化结果可以定位回原文。

20.2 招标要求响应矩阵¶

建立独立响应项模型：

响应矩阵成为解析、目录、生成和审核之间的统一连接层。

20.3 智能审核中心¶

审核能力按照确定性规则与语义检查分层：

• 必填章节和附件检查。
• 招标要求覆盖检查。
• 评分项响应检查。
• 项目名称、编号和主体信息一致性。
• 产品参数冲突。
• 禁用词和风险表述。
• 格式与篇幅检查。
• LLM 辅助的语义偏离识别。

审核结果必须包含问题类型、严重程度、位置、原因、修改建议和处理状态。

20.4 协作与版本¶

在稳定 node_uid 基础上扩展：

• 章节负责人。
• 评论与批注。
• 草稿和发布版本。
• 修改记录。
• 审核流。
• 章节锁。
• 最终导出版本快照。

20.5 受控 Agent 编排¶

当响应矩阵和审核中心建立后，可以引入受控的 Agent 工作流：

解析能力生成要求
→ 规划能力建立章节映射
→ 检索能力寻找企业证据
→ 生成能力完成初稿
→ 审核能力发现问题
→ 人工确认或触发定向修订

Agent 负责选择已有能力和提出下一步建议，业务状态机仍负责权限、事务、任务终态和人工确认。

21. 结语¶

智能标书系统的价值不在于“生成一篇长文章”，而在于把招标文件、企业知识、目录规划、正文生产和成果交付连接成一个可运行的业务系统。

Tender Service 通过结构化数据、场景化 Prompt、知识检索、异步任务和文档输出，将 AI 能力嵌入标书编制的关键节点。

系统架构坚持确定性流程控制与智能能力协同：让模型负责理解和生成，让系统负责状态、数据、权限、恢复与交付。由此形成一套可管理、可扩展、可运营的智能标书生产基础。