bid总结
项目总架构
评标项目设计为两个平台 一个是 AIOS，负责AI能力的管理，包括：
- 知识库管理
- 提示词管理
- 模型管理
- 智能体管理
- 基础服务
另一个是 BID，负责具体的评标工作。包括：
- 评标项目管理
- 评标流程驱动
- 专家评审
- 基础服务
先说一下项目的一个评标流程： 首先是前期准备，对所有项目生效的：
- 构建基础知识库，就是静态知识库，包括行业的法规、以前的评标示例等，作为评标时的参考
- 构建 提示词，我们对每一个评分点都有不同的提示词，因为每个评分点的判别方式不同，所以有一个提示词库，根据评分点+版本存储
- 智能体管理，在我们
- 模型管理，对接 vllm 和 litellm，管理模型上下架和默认参数
然后就是一个项目的流程
- 运营人员在bid上开始同步项目，填写标段号后，开始自动从国能拉取招投标文件
- 招投标文件获取成功后，进入清洗阶段，就是动态知识库
- 使用我们的 knowdoc 服务构建知识库，融合了 minerU 和 qwen-vl，解决了标书材料的OCR问题
- 知识库构建后，触发 kv task，根据项目id、招投标、文件名、评审因素构建 kv，因为 评审过程要大量多次的查询 知识库，还都是重复查询，之前在没有 kv 的时候性能很差
- 接下来开始 多个评标 agent ，包括 AI预警、初评、商务、技术、价格
- 我们的 agent 设计没有用 langchain、langgraph这些框架，我们CTO说我们任务太复杂，要考虑到 任务时长、可重试、可观测、人工介入 等，设计了一套 基于 Temporal 的工作流
- 然后就是多智能体，每个阶段有多个指标，每个指标都有一个子agent来完成。也是基于 Temporal ，通过 fan-out 并行。
- 然后就是执行过程中的问题，Temporal 本身的边界处理就很完备，我们对于执行中的业务日志都有保留
- 对于专家审查阶段，触发 Temporal 的 signal，专家确认后 发送 Signal
价格评分 Code Agent
首先是一个 Temporal Workflow 启动时传入项目信息 然后启动 agent
读取评分标准、读取招投标文件、读取提示词库、组装提示词、生成代码、运行代码、生成结果
其中有一些边界处理，如：投标人太多导致上下文溢出、代码运行错误、代码安全性