项目是如何完成的，是否完全从零开发或基于开源项目？

核心回答示例

项目基于开源的电商问数开发，面向区域经理和门店运营提供自然语言查询。底座用 Python、FastAPI 和 LangGraph 组织服务与流程，已有元数据同步、字段、指标和取值三路召回、上下文整理，以及 SQL 生成、校验和执行，过程和结果通过 SSE 返回。

个人设计集中在门店指标与上下文适配：接收净销售额、退款归属、门店别名和字段映射，把业务定义写入元数据与查询上下文，接入门店数据源，并在执行层落实允许查询的门店范围。输出是供 SQL 生成使用的业务资料，以及可对照检查的查询结果。

开发从指标定义和人工对照 SQL 开始，再读通底座的一次查询，接入业务配置与数据，最后贯通生成和执行。验证固定数据与日期范围，保留问题、召回结果、上下文、SQL 和结果，检查门店筛选、退款计算与多表关联。这样能定位口径在哪一步丢失，也能说明哪些改动来自业务适配。

复用范围与开发路径

以“华北地区销售总额”为例，开发可以分为四步：

1. 确定指标。 明确销售总额与净销售额的区别，以及地区字段和统计日期。本例净销售额按本期实收减本期实际退款计算，退款按发生时间归属；这些定义形成指标配置和人工对照 SQL。
2. 读通查询。 沿字段、指标和取值三路召回，追到 merge_retrieved_info 与 SQL 生成。字段去重、指标依赖、取值关联和主外键补齐已有实现，先用中间结果确认底座怎样组织资料。
3. 接入门店业务。 配置指标与别名，适配数据源及业务身份对应的查询范围。需要调整合并逻辑时，具体说明原输入缺了什么、输出增加什么；执行层同时落实允许范围。
4. 对照交付。 用退款、日期边界、门店别名与跨表问题，对照业务定义、生成 SQL 和人工结果。保留业务配置、代码差异、问题集与请求记录，说明每项改动解决了什么问题。

这里的指标和别名属于配置，门店数据源与身份范围属于业务集成；若调整合并节点或执行代码，再对应说明源码改动。底座已有的去重和依赖补齐继续复用。

追问：哪些问题尚未由底座解决？

当前问数图在首次 SQL 校验失败后进入纠错，纠错后直接执行，未再次校验。若增加纠错后复验，需要调整图的连接并验证失败分支；数据库权限与查询预算也需分别实现、检查实际执行记录。已有校验节点的作用止于它实际经过的分支。

核心回答示例

项目基于 Ragent 的 Java 服务，采用固定知识问答流程，为售后工程师查询适用的设备维修资料。底座已有文档入库、知识库管理、多路检索、融合重排和引用，设备场景在这条链路上增加型号与版本规则。

个人设计是设备与手册匹配模块：输入设备型号、固件版本和手册生效范围，统一型号别名，判断资料是否适用，输出允许检索的文档或待补条件，再把这个范围接入各召回通道和后处理。

开发先整理设备档案与手册关系，再适配检索入口，贯通回答引用和工单反馈。验证用同故障不同型号、同型号新旧手册及无适用资料的问题，依次检查匹配范围、各路候选和最终引用，重点看补充检索是否又带入了旧手册。

为什么选择底座，怎样增加业务代码

本例以 ff93871 对应源码为基准，沿用 Java、Spring Boot 后端、MySQL 记录存储和 Milvus 向量检索。Ragent 同时提供固定知识问答与 AgentScope Agent 链路；设备手册查询选固定流程，将开发重点放在结构化设备规则怎样进入检索。

开发路径包括四步：

1. 整理设备档案、型号别名、手册版本与生效范围，用新旧资料明确适用关系。
2. 实现匹配模块，输入型号和版本，输出允许文档与待补条件；缺少会影响处理步骤的信息时先补问。
3. 将允许范围接入各实际召回通道及补充检索，后处理也保持该范围。底座按意图选择检索作用域，设备文档限制需另行接入；若原接口只能限制知识库，就补文档级接口或实现。
4. 关联问题、适用手册、答案引用与工单反馈，便于回查建议依据及采纳意见。

模型和知识库设置属于配置，设备档案与工单对接属于业务集成，匹配规则和范围适配属于业务开发。采用扩展接口时说明接入位置；确需修改上游检索入口或处理器时，再说明原接口的不足与具体代码差异。

追问：怎样证明改动起作用？

用同一组设备问题对比适配前后的候选范围与引用。正确手册未召回，先查匹配是否过窄；错误手册混入，查哪条通道绕过了范围；候选正确而引用错误，再查上下文与生成。每一步都有对应输入和中间结果，能看出业务规则究竟在哪一层生效。

核心回答示例

项目基于开源的深度研搜，为产业研究人员生成有出处的研究初稿。底座用 Python、FastAPI 提供任务接口，DeepAgents 和 LangGraph 组织主智能体与来源助手，已有规划、附件读取和报告交付，进度通过 WebSocket 返回。

个人设计集中在来源适配与证据组织：接收来源内容、原文位置、发布日期和事实时间，统一企业产品别名、合并转载线索、保留冲突，再把证据关联到结论与报告段落。输出包括证据记录和待复核位置，为后续局部更新提供依据。

开发先用一组研究任务和材料约定证据结构，再扩展来源输出，接入报告生成前的汇总过程。验证固定主题与材料，检查转载是否重复计入、时间是否混用、引用能否支持结论；再新增或替换材料，核对受影响的段落。

从来源产物到可追溯报告

网络、数据库与知识库助手负责获取不同来源，文件工具负责附件及 Markdown、PDF 交付。证据模块接在来源产物与报告之间，处理内容、URL 或文件位置、发布日期和事实时间，输出结论与段落可以回查的证据关系。

开发路径可以进一步展开：

1. 选定代表研究任务及时间范围，准备公开资料、数据库记录和上传文档，覆盖转载、时间差与冲突。
2. 读通主智能体、三个来源助手和文件工具，检查各来源实际返回什么。当前 RAGFlow 工具只返回拼接的 answer 文本，需扩展来源输出，才能把原文位置等信息交给证据模块。
3. 增加来源适配与证据关联，统一实体名称，分别保留转载、冲突与证据不足；报告生成时传入对应证据。
4. 对照材料与报告结论，再替换或新增一份材料，沿证据、结论和段落的关系标记待复核位置。局部重写另行实现，交付保留代码差异、任务材料与报告前后版本。

任务规划、助手调度、WebSocket 事件和 PDF 导出继续复用；来源输出适配属于业务集成或工具扩展，实体、证据与段落关联属于业务开发。报告能生成与材料更新后能定位影响，是两项不同的功能。

追问：长任务能否在重启后继续？

当前底座使用 InMemorySaver，检查点保存在进程内，报告文件则可以留在磁盘。重启后继续执行还需要持久化检查点、任务恢复与重复执行处理；验证时要检查恢复到了哪个状态、是否重复执行外部动作，文件仍在只是其中一项检查。

核心回答示例

项目采用 RAGFlow 平台集成路线，为设备售后工程师查询适用手册。文档入库、解析切分、索引与检索由平台提供，个人设计集中在外部 Python、FastAPI 服务中的设备资料适配。

这个模块输入型号、版本和故障问题，根据设备与手册关系匹配适用资料，再映射为平台知识库与文档范围。它构造受限检索请求，核对响应来源，把有效片段交给生成环节；条件缺失时补问，没有适用文档时返回资料缺口。

开发先整理资料映射，再贯通一次受限检索，最后接入答复与缺口处理。验证用同故障不同型号、新旧手册、版本冲突和无适用资料的问题，对照匹配结果、平台请求、返回片段与最终引用。这条路线的工作落在平台配置、业务规则和 API 集成。

从资料映射到查询交付

本例以 v0.27.2 为接口基准，开发分四步：

1. 整理设备型号、版本、手册生效范围与平台知识库、文档的对应关系，确定补问、冲突和资料缺口的分支。
2. 复用平台入库与解析，检查切分后的片段是否保留维修步骤及来源，作为后续检索的对照资料。
3. 接入片段检索接口，根据非空匹配结果构造知识库和文档范围，并核对响应来源。没有适用文档时直接停止请求：无额外元数据过滤时，空文档列表会失去文档限制，并不表示不返回资料。
4. 只把适用片段交给生成环节，保留来源文档与原文位置，再用同一问题集分别检查范围、证据与引用，形成请求记录。

设备映射、检索代理与答复集成属于业务代码，模型与知识库设置属于配置，解析和索引继续复用。本例通过外部服务代理片段检索；若采用平台现成聊天助手，可以按设备系列和兼容版本拆库，但共享手册的更新需要额外维护，且聊天入口有自己的绑定与参数约定。

追问：范围与答案分别由谁保证？

外部业务服务根据设备规则确定允许范围，平台在请求范围内检索并返回来源。业务服务再核对文档与版本，只将适用片段送入生成环节，最终检查引用能否支持建议。

没有适用手册时停在业务匹配，有手册却未召回证据时检查入库与检索，证据正确而答复错误时检查生成输入和引用。版本冲突则保留原因，暂停给出确定维修步骤，并补充设备条件。验证分别覆盖这些分支，才能定位资料范围和答复依据各自的问题。