Files

liuguancen 87e571d9ec [全量] 初始化项目代码、配置、文档及Agent协同harness

2026-04-02 11:36:05 +08:00

44 KiB

Raw Blame History

说明：以下表格中的公网 IP 多为历史迁移前审计记录。当前仓库内 Spring / Langchain 默认已改为本机 127.0.0.1 与 Docker（镜像目录 /opt/docker-images），请以实际 application-*.yml 与 configs/kb_config.py 为准。

项目交接部署审计报告

审计日期: 2026-02-26 项目名称: LLM Chat 大模型智能问答系统 (冶金行业版) 原开发公司: 浪潮 (com.inspur) 我方服务器: 10.200.3.10

一、项目概述

本项目是一个基于大语言模型(LLM)的智能问答系统，主要面向冶金行业，提供政策查询、报告分析、期刊论文检索、智能写作辅助等功能。项目由三个主要服务组成：

服务	技术栈	端口	说明
chat_web_front	Vue 3 + TypeScript + Vite	3000	前端界面
chat_web_backend	Java Spring Boot 2.3.7	8099	业务后端 API
langchain-chat	Python FastAPI + LangChain	7861	LLM 推理 + 知识库

辅助基础设施：

组件	版本	端口	说明
MySQL	8.4.4 (Docker)	33306	主数据库
Milvus	2.6.4 (Docker)	19530	向量数据库
MinIO	2024-12-18 (Docker)	9002/9003	对象存储 (Milvus 依赖)
etcd	v3.5.18 (Docker)	2379	分布式配置 (Milvus 依赖)
Redis	-	6379	缓存/Session

二、交接时存在的主要问题

2.1 数据库仍连接原公司远程服务器 [严重]

交接时，Java 后端 (application-yj.yml, application-test.yml) 直接连接原公司的远程 MySQL 和 Redis，没有提供本地数据库的数据导出或迁移方案。

服务	原公司地址	说明
MySQL	`123.57.146.97:3306` (阿里云)	数据库名: `chat_LLM`，密码: `MYSQL!@#89765`
Redis	`123.57.146.97:6379` (阿里云)	密码: `Redis_897653`，database: 13

文件位置:

chat_web_backend/src/main/resources/application-yj.yml:29-36
chat_web_backend/src/main/resources/application-test.yml:18-36
chat_web_backend/src/main/resources/application-dev.yml:29-31 (Redis 仍指向远程)

风险: 一旦原公司关闭这些服务器或修改密码，系统将立即不可用。

2.2 无完整数据库 Schema 和数据迁移方案 [严重]

虽然 chat_web_backend/doc/sql/ 目录下有 SQL 脚本：

sys.sql, chat_gpt.sql, knowledge_base.sql, gpt_folder.sql, writter_docs.sql, quartz.sql 等

但这些脚本只有表结构，没有包含业务数据。原公司远程数据库 chat_LLM 中的用户数据、对话历史、知识库配置等数据没有导出交接。

2.3 Milvus 向量数据库数据未交接 [严重]

Python 后端依赖的 Milvus 向量知识库包含大量预处理好的行业数据集合：

t_policy_total_bge_new_v2 (政策库)
gydemo_report_v2 (报告库)
t_journal_article_bge_v1 (期刊论文库)
以及多个冶金行业专用知识库

这些向量数据需要重新入库或从原公司导出，否则知识库问答功能完全不可用。

文件位置: langchain-chat/configs/kb_config.py:8-41, langchain-chat/configs/model_config.py:28-31

2.4 多处硬编码原公司服务器 IP [严重]

代码中存在大量原公司基础设施的硬编码 IP，无法通过配置文件覆盖：

IP 地址	用途	文件位置
`123.57.146.97`	MySQL + Redis (阿里云)	多个 application-*.yml
`123.56.15.82:10326`	生产环境前端/搜索服务	`application-prod.yml:2`, `kb_config.py:97`
`39.97.197.219:10326`	测试环境	`application-test.yml:2`
`192.168.56.123`	内部 LLM 服务/画图服务	`application-prod.yml:71`, `kb_config.py:101-102,121`
`192.168.56.188:8081`	内部图片服务	`DocController.java:314`
`106.3.149.154:8081`	旧图片/文件下载服务	`DocController.java:313`, `kb_config.py:117,165`
`172.17.119.151:8327`	专业搜索服务	`kb_config.py:98`

特别注意: DocController.java:313-314 中硬编码了 IP 替换逻辑，说明原公司在迁移过程中就存在 IP 硬编码问题。

2.5 第三方 API Key 硬编码在源码中 [中等]

以下 API Key 直接写死在代码和配置文件中：

服务	Key	文件位置
阿里云 OSS Access Key	`LTAI5tKV3JEn6EX6eVeQjrYN`	`AliyunOSSUtil.java:48`, `oss_config.py:3`, 多个 yml
阿里云 OSS Secret	`CtMmajeabIVU6xjCVt6KCcWp9IcgD1`	`AliyunOSSUtil.java:53`, `oss_config.py:4`, 多个 yml
阿里云通义千问 API Key	`sk-672f9d1fc4404674bf1a713dfd130a14`	`model_config.py:75`
DeepSeek API Key	`sk-26858b50690a49828766fcfcf3290de9`	`model_config.py:83,88`
Metaphor API Key	`e09d3cdd-e7e1-41d7-...`	`kb_config.py:138`
心知天气 API Key	`STNmmw0iUKB96PNpJ`	`kb_config.py:141`

风险: 这些 Key 属于原公司账户。给客户部署时必须替换为客户自己的 Key，否则：

原公司可以随时吊销这些 Key
产生的 API 费用会计在原公司账户上
存在安全风险（原公司 OSS bucket 中可能有敏感数据）

2.6 Jasypt 加密密码泄露在源码注释中 [中等]

生产环境配置使用了 Jasypt 加密（ENC(...) 格式），但加密密钥直接写在了源代码的注释里：

文件位置: chat_web_backend/src/main/java/com/inspur/llm/chat/base/config/JasyptConfiguration.java

密钥	用途	行号
`HadIuTIooXd0C93`	prod/test 环境加解密	13, 27, 41, 55 行
`Z4d5vrOSlASf0MX`	yjprod (冶金生产) 环境加解密	59 行

同一文件中还暴露了原公司阿里云 RDS 连接信息（注释中）：

rm-2zer597iohnt2hik2.mysql.rds.aliyuncs.com (生产 RDS)
rm-2ze6u80a543d64vu0.mysql.rds.aliyuncs.com (测试 RDS)
用户名: inpur，密码: 987654321a! / 123456789a!

2.7 Java 源码中硬编码 API 地址 [中等]

KnowledgeBaseController.java 中，调用 langchain-chat 的地址直接写死在 Java 代码里而不是配置文件中：

// KnowledgeBaseController.java:50
String url = "http://127.0.0.1:7861/knowledge_base/list_knowledge_bases";
// :63
String url = "http://127.0.0.1:7861/knowledge_base/create_knowledge_base";
// :75
String url = "http://127.0.0.1:7861/knowledge_base/delete_knowledge_base";
// :88
String url = "http://127.0.0.1:7861/knowledge_base/list_files";
// :100
String url = "http://127.0.0.1:7861/knowledge_base/delete_docs";

如果 langchain-chat 部署在不同机器或不同端口，需要改源码并重新编译。

2.8 绝对路径硬编码 [低]

多处使用了原公司开发人员本机或服务器的绝对路径：

路径	文件位置	说明
`/opt/apps/logs/chat-server-backend-cast`	`logback-spring.xml:6`	日志路径
`/opt/logs/${server.name}/access`	`application.yml:16`	访问日志路径
`/opt/upload/${server.name}`	`application-test.yml:67`, `application-prod.yml:66`	文件上传路径
`/Users/master/Documents/upload/`	`application-dev.yml:82`, `application-ck.yml:77`	macOS 本地路径
`/home/albert/workspaces/modelSpaces/models/...`	`kb_config.py:164,166,168`	原开发者本机路径
`/usr/lib/jvm/java-11-openjdk-amd64`	`start.sh:5`	JDK 路径

2.9 OAuth2/SSO 集成指向外部系统 [低]

部分 profile 配置了 OAuth2 单点登录，指向外部系统：

https://kxsso.cast.org.cn/ (中国科协 SSO) - application-yj.yml:96-97, application-ck.yml:90-91
http://www.metalinfo.cn (冶金信息网) - application-yjprod.yml:15

如果客户不需要对接这些系统，需要关闭或替换 OAuth2 配置。

2.10 Docker 镜像使用代理源 [低]

MySQL Docker 镜像使用了第三方代理源 docker.1ms.run/mysql:8.4.4（mysql/docker-compose.yml:3），在客户内网环境中可能无法拉取。

三、我方已做的修改（为在 10.200.3.10 上启动）

根据 项目启动总结.md 和代码中的痕迹，我方已完成以下改动：

3.1 Java 编译环境修复

问题	解决方案	文件
Java 21 与 Lombok 不兼容	改用 Java 11 编译和运行	`start.sh`
Java 11 移除了 JAXB	在 pom.xml 中添加了 JAXB 依赖	`pom.xml`

3.2 新增 application-dev.yml 本地开发配置

创建/修改了 application-dev.yml，将 MySQL 指向本地 Docker：

MySQL: 127.0.0.1:33306/chat_gpt_yj (本地 Docker 容器)
密码: 1234567890

但 Redis 仍然指向原公司远程服务器 123.57.146.97:6379。

3.3 本地 MySQL Docker 部署

通过 mysql/docker-compose.yml 在本地部署了 MySQL 8.4.4：

端口映射: 33306 -> 3306
root 密码: 1234567890
默认数据库: chat_LLM
有一份数据库转储文件: mysql/mysql_bind/dump-chat_gpt_yj-202503051410.sql

3.4 本地 Milvus 向量数据库部署

通过 milvus/docker-compose.yml 部署了 Milvus 2.6.4 + MinIO + etcd 集群。

3.5 前端修改

禁用了 vueDevTools 插件避免启动错误
前端上下文路径改为 /metalinfo
前端通过 Vite 代理转发后端 API 请求到 localhost:8099

3.6 Python 后端配置

模型根路径设置为本地: /home/gc/gangyan/models
嵌入模型使用 CPU 运行: EMBEDDING_DEVICE = "cpu"
配置了在线 LLM 模型: deepseek-chat, qwen-max, deepseek-reasoner
Milvus 连接指向本地: 127.0.0.1:19530

3.7 启动脚本

创建了 start.sh 启动脚本，使用 --spring.profiles.active=dev 激活本地开发配置。

四、当前仍然缺失/需要解决的问题

4.1 Redis 服务 [必须解决]

当前状态: dev 配置仍然连接原公司远程 Redis 123.57.146.97:6379。

解决方案:

本地部署 Redis（推荐使用 Docker）
修改 application-dev.yml 中 Redis 配置指向本地

参考配置:

redis:
  host: 127.0.0.1
  port: 6379
  password: <自定义密码>

4.2 Milvus 向量数据 [必须解决]

当前状态: Milvus 服务已部署，但知识库集合（collections）可能为空。

需要做的:

确认 Milvus 中是否已有 t_policy_total_bge_new_v2 等集合
如果没有，需要重新导入向量数据（从原公司获取 Milvus 备份，或重新进行文档向量化入库）
知识库的文档源文件也需要确认是否齐全

4.3 MySQL 业务数据 [必须解决]

当前状态: 有表结构 SQL 和一份转储文件，但需确认：

dump-chat_gpt_yj-202503051410.sql 是否包含完整业务数据
本地数据库名 chat_gpt_yj 与远程 chat_LLM 不一致，是否有影响
系统用户账户数据是否已迁移

4.4 阿里云 OSS 存储 [需要解决]

当前状态: 代码中硬编码使用原公司的阿里云 OSS：

Bucket: bj-large-models / bg-large-models
Endpoint: oss-cn-beijing.aliyuncs.com

需要做的:

确认系统是否实际使用了 OSS（如果只在本地上传文件则不影响）
如需要 OSS，客户需准备自己的阿里云 OSS 账户
需修改 AliyunOSSUtil.java 中的硬编码值（需重新编译）
需修改 oss_config.py 和多个 application-*.yml 中的 key/secret

4.5 LLM API Key [需要解决]

当前状态: 使用原公司的 API Key 调用通义千问和 DeepSeek。

需要做的:

客户注册自己的通义千问账户，获取 API Key
客户注册自己的 DeepSeek 账户，获取 API Key
修改 langchain-chat/configs/model_config.py 中的 api_key 字段

4.6 搜索服务 [需要解决]

当前状态: 搜索功能依赖外部服务，目前不可用：

通用搜索: http://123.56.15.82:10326/search/search (原公司服务器)
专业搜索: http://172.17.119.151:8327/search/professionalSearch (内网)

文件位置: langchain-chat/configs/kb_config.py:97-98

需要做的: 确认搜索功能是否为核心需求，如是则需要部署自己的搜索服务或接入第三方搜索 API。

4.7 画图服务 [需要解决]

当前状态: 画图接口指向原公司内网服务器，不可用：

http://192.168.56.123:5000/generate
http://192.168.56.123:5000/generate-image

文件位置: langchain-chat/configs/kb_config.py:101-102

4.8 文件下载服务 [需要解决]

kb_config.py:117 中 DOWNLOAD_HOST_CK 指向 http://106.3.149.154:8081/cast_getfile，原公司旧服务器。

kb_config.py:165 中图片服务也指向旧 IP: http://106.3.149.154:8081/chat_backend_ck/get-image?file_name={}。

4.9 Python 依赖中的本机路径 [需要解决]

kb_config.py 中多处引用原开发者路径：

# kb_config.py:164
GENERATED_IMAGES_BASE_PATH = "/home/albert/workspaces/modelSpaces/models/text_to_pic/generated_images"
# kb_config.py:166
KB_CHAT_TEMP_DIR = "/home/albert/workspaces/modelSpaces/models/tmp"
# kb_config.py:168
CHROME_DIR = "/home/albert/workspaces/modelSpaces/models/chrome"

这些路径在当前服务器上不存在，相关功能会报错。

4.10 日志和上传路径 [建议解决]

需要确保以下目录存在并有写入权限：

/opt/apps/logs/chat-server-backend-cast (日志)
/opt/logs/metal_llm/access (访问日志)
/opt/upload/metal_llm (文件上传)

五、给客户新服务器部署的完整检查清单

第一步：基础环境准备

安装 Docker 和 Docker Compose
安装 Java 11 (OpenJDK)
安装 Python 3.8+ 和 Conda
安装 Node.js 16+ 和 npm
安装 Maven 3
确保服务器有足够磁盘空间（模型文件 + 向量数据，建议 50GB+）

第二步：数据库部署

启动 MySQL Docker (mysql/docker-compose.yml)
导入数据库 Schema (chat_web_backend/doc/sql/ 下的 SQL 文件)
导入业务数据（如有转储文件）
部署本地 Redis (新增 Docker 服务或单独安装)
启动 Milvus 向量数据库 (milvus/docker-compose.yml)
导入向量知识库数据

第三步：配置修改

Java 后端 (chat_web_backend/src/main/resources/):

修改 MySQL 连接地址和密码（指向本地或客户数据库）
修改 Redis 连接地址和密码（指向本地）
替换阿里云 OSS Key/Secret（如需要）
修改 serverUrlPrefix 为客户实际域名/IP
确认 OAuth2 配置（关闭或对接客户 SSO）
修改日志和上传路径
重新编译: mvn clean package -DskipTests

Python 后端 (langchain-chat/configs/):

model_config.py: 替换 LLM API Key（通义千问、DeepSeek）
model_config.py: 确认 MODEL_ROOT_PATH 路径正确
kb_config.py: 修改搜索服务 URL 或关闭搜索功能
kb_config.py: 修改画图服务 URL 或关闭画图功能
kb_config.py: 修改 MySQL 连接配置 (ck_mysql_config)
kb_config.py: 修改 GENERATED_IMAGES_BASE_PATH, KB_CHAT_TEMP_DIR, CHROME_DIR 路径
kb_config.py: 修改 DOWNLOAD_HOST_CK 和 IMAGE_SERVER_URL_TEMPLATE
oss_config.py: 替换阿里云 OSS 凭证

前端 (chat_web_front/):

.env: 修改 VITE_GLOB_FRONT_CTX (前端上下文路径)
.env: 修改 VITE_GLOB_API_DEV_IP (后端 API 地址)
生产环境需要 Nginx 反向代理配置

Java 源码中的硬编码 (需改代码并重新编译):

KnowledgeBaseController.java: 5 处 langchain-chat 地址硬编码
AliyunOSSUtil.java: OSS Key/Secret/Endpoint/Bucket 硬编码
DocController.java: IP 替换逻辑硬编码

第四步：启动验证

按顺序启动：

MySQL Docker -> 验证数据库连接
Redis -> 验证缓存连接
Milvus Docker -> 验证向量库连接
langchain-chat Python 后端 -> 验证 API 和模型加载
chat_web_backend Java 后端 -> 验证业务 API
chat_web_front 前端 -> 验证页面访问

六、二次开发可行性评估

6.1 整体评估: 中等可行 (有一定门槛)

维度	评分	说明
代码质量	中等	结构基本清晰，但存在大量硬编码，缺少注释
架构设计	中等偏上	前后端分离 + Python AI 后端，三层架构合理
可配置性	差	大量配置写死在代码/配置文件中，缺乏配置中心
文档完整性	差	几乎没有开发文档、API 文档、部署文档
技术栈现代性	中等	Vue 3 较新，Spring Boot 2.3.7 偏旧，Python 部分合理
测试覆盖	差	未发现单元测试和集成测试
安全性	差	API Key 明文硬编码、密码明文存储、Jasypt 密钥泄露

6.2 二次开发的优势

三层架构清晰: 前端、Java 后端、Python AI 后端职责分明，可以独立修改
主流技术栈: Vue 3、Spring Boot、FastAPI、LangChain 都是主流框架，开发人员容易上手
模块化设计: 知识库管理、对话管理、写作辅助等功能模块相对独立
LLM 模型可替换: 通过配置可以切换不同的在线 LLM 模型 (通义千问/DeepSeek/智谱等)
SQL 脚本齐全: 数据库建表脚本完整，可以在新环境重建
嵌入模型已包含: models/ 目录下已有 bge-m3 和 bge-reranker-large 模型文件

6.3 二次开发的风险和难点

配置管理混乱: 6 个 Spring Profile 配置文件 (dev/test/prod/yj/yjprod/ck)，每个都有不同的硬编码，难以统一管理
Java 代码中硬编码: KnowledgeBaseController.java 和 AliyunOSSUtil.java 中的硬编码需要改源码
Python 配置散落: Python 端配置分散在多个 py 文件中，修改需要理解每个配置的作用
缺乏 API 文档: 前后端交互接口没有文档(没有 Swagger 等)，需要阅读源码
缺乏测试: 修改代码后无法通过自动化测试验证正确性
行业耦合度高: 知识库名称、分类等与冶金行业强绑定(如 "冶金行业新闻库"、"冶金中文期刊库" 等)，如果客户是其他行业需要大量修改
第三方依赖: 搜索服务、画图服务等外部依赖没有源码，需要自行实现或替代
Jasypt 加密: 生产配置使用了 Jasypt 加密，需要理解加密机制才能修改生产配置
自定义 JAR 包: lib/ 目录下有两个非公开 JAR (aspose-words-21.1-jdk17.jar, app-sign-sdk-0.0.2.jar)，无源码，功能不明确

6.4 建议的二次开发优先级

P0 - 必须首先完成 (部署基础):

将所有远程服务替换为本地服务 (MySQL、Redis)
替换所有第三方 API Key 为客户自有
将 Java 源码中的硬编码 URL 改为可配置

P1 - 尽快完成 (稳定性):

统一配置管理，清理不需要的 Profile
将敏感信息移入环境变量
添加 Nginx 反向代理配置
编写部署文档

P2 - 按需完成 (功能增强):

根据客户行业修改知识库分类和名称
替换或重新实现搜索服务
添加 API 文档 (Swagger/OpenAPI)
添加基本的单元测试

七、各配置文件完整 IP/凭证清单

以下是需要检查和替换的所有外部依赖的完整清单：

原公司 IP 地址

IP	出现文件	需要改为
`123.57.146.97`	application-dev.yml, application-yj.yml, application-test.yml	本地 MySQL/Redis 地址
`123.56.15.82`	application-prod.yml, kb_config.py	客户服务器 IP 或删除
`39.97.197.219`	application-test.yml	客户测试服务器或删除
`192.168.56.123`	application-prod.yml, kb_config.py	客户内网 AI 服务器或删除
`192.168.56.188`	DocController.java	客户图片服务地址或删除
`106.3.149.154`	DocController.java, kb_config.py	客户文件服务地址或删除
`172.17.119.151`	kb_config.py	客户搜索服务地址或删除

凭证清单

凭证	类型	文件	操作
`LTAI5tKV3JEn6EX6eVeQjrYN`	阿里云 OSS AK	多处	替换为客户 AK
`CtMmajeabIVU6xjCVt6KCcWp9IcgD1`	阿里云 OSS SK	多处	替换为客户 SK
`sk-672f9d1fc4404674bf1a713dfd130a14`	通义千问 Key	model_config.py	替换为客户 Key
`sk-26858b50690a49828766fcfcf3290de9`	DeepSeek Key	model_config.py	替换为客户 Key
`Redis_897653`	Redis 密码	多个 yml	替换为本地密码
`MYSQL!@#89765`	远程 MySQL 密码	多个 yml	替换为本地密码
`1234567890`	本地 MySQL 密码	application-dev.yml, docker-compose	建议修改为强密码
`HadIuTIooXd0C93`	Jasypt 加密密钥	JasyptConfiguration.java	如需 Jasypt 则更换密钥
`Z4d5vrOSlASf0MX`	Jasypt 加密密钥	JasyptConfiguration.java	如需 Jasypt 则更换密钥
`nstlBj454x93w6n8rll3`	OAuth2 Client ID	application-yjprod.yml	替换或删除
`minioadmin/minioadmin`	MinIO 凭证	milvus/docker-compose.yml	建议修改

八、运行时启动测试结果 (2026-02-26 实测)

以下是在 10.200.3.10 服务器上实际启动全部服务后的测试结果。

8.1 基础设施状态

组件	状态	说明
MySQL (Docker, 33306)	正常运行	数据库 `chat_gpt_yj` 已有 21 张表，含业务数据
Redis (Docker portal-redis, 6379)	正常运行	本地运行，无密码，但 Java 后端配置未指向本地
Milvus (Docker, 19530)	正常运行	健康检查通过，但核心知识库集合缺失
MinIO (Docker, 9002/9003)	正常运行	Milvus 依赖
etcd (Docker, 2379)	正常运行	Milvus 依赖

8.2 三大服务启动状态

服务	端口	状态	问题
langchain-chat (Python)	7861	正常运行	API 服务正常；WebUI (Streamlit) 未安装，8501 不可用
chat_web_backend (Java)	8099	运行但有报错	启动正常，但 Redis 连远程导致部分 API 返回 500
chat_web_front (Vue)	3000	正常运行	http://10.200.3.10:3000/metalinfo 可访问

8.3 实际 API 测试结果

登录测试

测试项	结果	说明
登录端点	`/app/api/oauth/token` (GET)	需要 `client-id: app` 请求头
新手机号自动注册	部分成功	用户会被创建到 `gpt_user` 表，但 Spring Security 认证有时序问题
已有手机号登录	需正确密码	`loginByTel` 对已存在用户不校验密码直接返回，但 Spring Security 会校验 BCrypt
loginType	`3`=手机号, `4`=用户名密码	前端使用 loginType=3

逐项 API 实测结果 (curl 调用验证)

模块一: 问答

功能	测试方式	实际返回	结论
新建对话	`POST /gpt/chat` prompt="什么是碳达峰"	code=200, 返回 chatNumber	正常
历史对话	`GET /gpt/chat/listbyuserid`	code=200, data=[] (新用户无数据)	正常
多轮对话	`POST 7861/chat/chat_test` history=[]	返回 DeepSeek 回答 + Q1/Q2/Q3 推荐	正常
术语解释	`POST 7861/word_explain` word="碳中和"	返回碳中和详细解释(流式)	正常
政策问答	`POST 7861/chat/knowledge_base_chat` kb=t_policy_total_bge_new_v2	404: 未找到知识库	不可用
大模型切换	`POST 7861/llm_model/list_config_models`	返回 qwen-max/deepseek-chat/deepseek-reasoner 三个模型	正常
深度思考	`POST 7861/chat/chat_test` model=deepseek-reasoner	返回回答+推荐问题+摘要	正常
问题推荐	包含在 chat_test 返回中	返回 Q1/Q2/Q3 三个推荐问题	正常
知识库列表	`GET /knowledgeChat/knowledgeBaseList`	返回报告库/政策库/期刊论文 3 条配置	正常(但 Milvus 中无实际数据)

模块二: 写作

功能	测试方式	实际返回	结论
AI编辑器(Java→Python)	`POST /writer/answer` type=1	500: 生成失败 (Python返回422参数不匹配)	不可用
智能大纲	`POST /outlines/getOutlines` title="钢铁行业碳达峰"	流式返回 Markdown 大纲内容	正常
续写	`POST 7861/rewrite/con_rewrite`	返回续写段落(约200字)	正常
扩写	`POST 7861/rewrite/exp_write`	返回扩写内容	正常
缩写	`POST 7861/rewrite/abb_write`	返回异常(仅返回"缩写"两字)	有 Bug
风格调整(正式)	`POST 7861/rewrite/formal_style`	返回提示模板文本而非转换结果	有 Bug
关键词提取	`POST 7861/gen_keywords`	返回 "钢铁, 粗钢产量, 高耗能, 高排放"	正常
章节解析	`POST 7861/gen_paragraph`	返回结构化的三章解析	正常

模块三: 研读

功能	测试方式	实际返回	结论
关键词提取	`POST 7861/gen_keywords`	正确返回关键词列表	正常
章节解析	`POST 7861/gen_paragraph`	正确返回章节结构	正常
名词解释	`POST 7861/word_explain`	返回碳中和详细解释	正常
引用问答	`POST 7861/chat/self_kb_chat` quote=文本	返回基于引用文本的分析	正常
翻译	`POST 7861/chat/translate_text`	调用成功但返回格式异常(返回query值)	有 Bug
笔记	`POST /gpt/file/addFileNote`	code=400 需要笔记位置参数	接口存在,参数复杂

模块四: 应用广场

功能	测试方式	实际返回	结论
实用工具	`GET /config/getConfig?type=0`	code=200, data=[] (空数组)	页面框架有,配置数据为空
知识应用	同上	空	无数据无实现

关键发现的运行时问题

问题 1: Redis 配置不匹配 [导致 500 错误]

本地已有 Redis 服务 (portal-redis, 端口 6379, 无密码)，但 application-dev.yml 中 Redis 配置仍指向远程：

# application-dev.yml:29-31 当前配置 (错误)
host: 123.57.146.97
port: 6379
password: Redis_897653

应改为：

# 正确的本地配置
host: 127.0.0.1
port: 6379
password: ""  # 本地 Redis 无密码
database: 0   # 本地 Redis 使用 database 0 而非 13

影响范围: 历史对话列表、登录日志保存、Session 管理等依赖 Redis 的功能全部返回 500 错误。

问题 2: Milvus 核心知识库缺失 [导致知识问答不可用]

Milvus 当前仅有 3 个集合，均非核心业务库：

samples (示例数据)
p_d6c3b2030a094a84ad5f626eecfd13b4 (个人知识库)
p_43ea5da26f504a838e10cf09d68bb68d (个人知识库)

缺失的核心知识库 (MySQL knowledge_base_config 表中配置的):

集合名	用途	状态
`t_policy_total_bge_new_v2`	政策库	不存在
`t_strategy_report_bge_v2`	报告库	不存在
`t_journal_article_bge_v1`	期刊论文库	不存在

知识库问答调用会直接返回 404: 未找到知识库。

问题 3: Java 后端 MySQL 连接池告警

Java 后端自 2026-02-05 启动至今已运行 3 周，Druid 连接池出现大量 Communications link failure 错误（连接超时断开）。建议定期重启或配置连接池保活参数。

问题 4: Python WebUI (Streamlit) 未安装

Python 后端的 WebUI 进程启动失败：FileNotFoundError: No such file or directory: 'streamlit'。需要在 conda 环境中安装：pip install streamlit。WebUI 仅用于调试，不影响核心 API。

问题 5: 岗位智能体无数据

数据库中 gpt_assistant 和 gpt_assistant_type 表均为空，岗位智能体功能完全不可用。需要配置智能体类型和预设智能体数据。

8.4 MySQL 数据库数据量统计

表名	记录数	说明
sys_user	149	系统管理员账户
gpt_user	226	前台用户 (手机号注册)
gpt_chat	3,931	对话会话
gpt_chat_message	12,126	对话消息
gpt_upload_file	403	上传文件
gpt_knowledge_base	330	知识库记录
outlines	956	写作大纲
writer_docs	235	写作文档
gpt_assistant	0	智能体 (空)
gpt_assistant_type	0	智能体类型 (空)
knowledge_base_config	3	知识库配置 (报告库/政策库/期刊)

数据库已有大量业务数据，说明转储文件 dump-chat_gpt_yj-202503051410.sql 已成功导入。

九、业务需求表 vs 代码实现功能对比

以下对比基于客户提供的业务需求表（4 大模块 39 项功能）与代码实际实现情况。

9.1 模块一：问答

序号	功能	代码实现	运行时状态	差距分析
1	新建对话	已实现 - `ChatController` + `chat_test.py`	正常	无差距
2	历史对话	已实现 - `ChatHistory.vue` + `ChatController.listChatByUserId()`	不可用	Redis 连接失败导致 500 错误；修复 Redis 配置即可恢复
3	内容溯源	部分实现 - `knowledge_base_chat.py` 返回 `source_documents`	不可用	依赖知识库问答，Milvus 集合缺失
4	多轮对话	已实现 - `ChatMessage.parentMessageId` + 历史对话缓冲	正常	无差距
5	文档问答	已实现 - `FileController.fileTalk()` + `file_chat.py` + `self_kb_chat.py`	正常	支持 Word/PDF/Excel/图片上传和问答
6	术语解释	已实现 - `word_explain.py` 端点 `/word_explain`	正常	无差距
7	选题推荐	已实现 - `policy_fun_iast.py` 的 `question_recommend` 模板	部分可用	与知识库关联的推荐不可用
8	政策问答	部分实现 - `policy_fun_iast.py` + 编译的 `policy_fun.so`	不可用	政策库 `t_policy_total_bge_new_v2` 在 Milvus 中不存在，互联网实时数据搜索服务 (123.56.15.82) 不可达
9	大模型切换	已实现 - `/llm_model/change` + 前端模型选择	正常	需求表要求 Qwen3+DeepSeek；当前配置 qwen-max+deepseek-chat+deepseek-reasoner，基本满足
10	深度思考	部分实现 - `thinking_generator()` + 前端 `thinkContent` 显示	部分可用	仅 deepseek-reasoner 模型支持，需要通过 `enable_thinking` 标志触发
11	岗位智能体	框架存在 - `AgentController` + `agent_chat.py`	不可用	`gpt_assistant` 和 `gpt_assistant_type` 表为空，无预设智能体数据，需要配置"战略咨询助理""办公辅助"等角色
12	问题推荐	已实现 - 对话结束后推荐 3 个相关问题 (Q1/Q2/Q3)	正常	无差距

问答模块总结: 12 项功能中，5 项正常可用，2 项部分可用，5 项不可用。核心问题是 Milvus 知识库缺失和 Redis 配置错误。

9.2 模块二：写作

序号	功能	代码实现	运行时状态	差距分析
1	AI编辑器	部分实现 - `DocWriting.vue` + UEditor 集成	部分可用	编辑器基础功能可用，但 AI 辅助写作依赖的部分功能受限
2	智能大纲	已实现 - `OutlinesController` + `write_article.py`，支持 3 种模板	正常	需求要求 3 种大纲模板，代码已支持
3	内容生成	已实现 - `write_article.py` 根据大纲自动生成报告章节	正常	流式响应实时生成
4	要点提炼	已实现 - `gen_abstract.py` 端点 `/gen_abstract`	正常	无差距
5	风格调整	已实现 - `/rewrite/formal_style`, `/rewrite/party_style`, `/rewrite/col_style`	正常	需求要求"政风/学术/口语/自定义"4种，代码有正式/党政/口语 3 种，缺少"学术风格"和"自定义风格"
6	段落推荐	已实现 - `sentence_reference.py` 端点 `/sentence_reference`	部分可用	依赖知识库检索，Milvus 集合缺失时退化为纯 LLM 生成
7	合写续写	已实现 - `con_rewrite.py` 端点 `/rewrite/con_rewrite`	正常	无差距
8	扩写缩写	已实现 - `exp_rewrite.py` + `abb_rewrite.py`	正常	无差距
9	文档溯源	部分实现 - `relevant_articles.py`	部分可用	溯源功能依赖知识库数据
10	报告导出	已实现 - `FileController.downloadFile()` 导出 Word	正常	使用 Aspose-Words 库生成 docx；注意该库为商业授权

写作模块总结: 10 项功能中，7 项正常可用，3 项部分可用。整体完成度较高。

9.3 模块三：研读

序号	功能	代码实现	运行时状态	差距分析
1	要点提炼	已实现 - `gen_abstract.py`，结果存入 `UploadFile.articleAbstract`	正常	无差距
2	关键词提取	已实现 - `gen_keywords.py` 端点 `/gen_keywords`	正常	无差距
3	全文章节解析	已实现 - `gen_paragraph.py` 端点 `/gen_paragraph`	正常	无差距
4	语言翻译	已实现 - `translate.py` + `FileTranslateController`，支持 25+ 语言	正常	自动语种识别 + 文件翻译均已实现
5	名词解释	已实现 - `word_explain.py`	正常	无差距
6	相关文献	已实现 - `relevant_articles.py`	部分可用	依赖知识库向量检索，Milvus 缺失时仅靠 LLM 生成
7	引用问答	已实现 - `self_kb_chat.py` 端点 `/chat/self_kb_chat`，支持 `quote` 参数	正常	无差距
8	复制	已实现 - 前端各组件均有复制按钮	正常	无差距
9	个人文献库	已实现 - `FileController` + `KnowledgeBase` 实体，CRUD 完整	正常	支持上传/删除/下载/批量操作
10	笔记	已实现 - `FileNoteController` 端点 `/gpt/file/addFileNote`	正常	CRUD 完整

研读模块总结: 10 项功能中，9 项正常可用，1 项部分可用。完成度最高的模块。

9.4 模块四：应用广场

序号	功能	代码实现	运行时状态	差距分析
1	实用工具	仅有框架 - `applications/index.vue` 页面存在	不可用	需求要求"战略决策咨询、实用科研工具、标准库、AI 应用工具集"，代码仅有页面壳子，无实际工具实现
2	知识应用	未实现	不可用	需求要求"行业专用知识工具和应用"，代码中完全没有找到对应实现

应用广场模块总结: 2 项功能均不可用。此模块基本未开发。

9.5 功能覆盖率总结

模块	总功能数	正常可用	部分可用	不可用	覆盖率
问答	12	5	2	5	42% (运行时)
写作	10	7	3	0	70% (运行时)
研读	10	9	1	0	90% (运行时)
应用广场	2	0	0	2	0%
合计	34	21	6	7	62% (运行时)

注："部分可用"指代码已实现但因 Milvus 数据缺失等依赖问题导致功能降级。如果修复 Redis 配置 + 导入 Milvus 知识库数据，覆盖率可提升至约 80%。剩余 20% 主要差距在：岗位智能体无数据、应用广场未开发、风格调整缺少学术/自定义选项。

9.6 修复优先级（提升覆盖率的最快路径）

修复 Redis 配置 (影响: +3 项功能恢复) - 将 application-dev.yml 中 Redis 指向本地 127.0.0.1:6379，去掉密码
导入 Milvus 知识库数据 (影响: +5 项功能恢复) - 需要原始文档 + 重新向量化入库，或从原公司获取 Milvus 备份
配置岗位智能体 (影响: +1 项功能) - 在 gpt_assistant_type 和 gpt_assistant 表中插入预设数据
开发应用广场 (影响: +2 项功能) - 需要从零开发实用工具和知识应用模块

十、总结

这个项目的核心问题在于配置管理极度混乱：大量外部依赖以硬编码方式分散在 Java 源码、YAML 配置文件、Python 配置文件中，没有统一的配置管理方案。交接时也没有提供完整的数据迁移方案和部署文档。

给客户新服务器部署时，最大的坑是：

Redis 没有本地部署方案，仍依赖原公司远程服务
Milvus 向量数据缺失，知识库功能无法使用
Java 源码中有硬编码，改配置不够还需要改代码重新编译
所有第三方 API Key 都是原公司的，需要全部替换
搜索服务、画图服务等外部依赖完全不可用，需要自行解决

二次开发是可行的，但需要先花精力解决上述配置和基础设施问题。建议在动手开发新功能之前，先完成一次完整的配置治理和独立部署验证。

十一、AI 编辑器详细问题分析

当前状态

AI 编辑器模块存在以下层次：

前端 UI: DocWriting.vue + UEditor 富文本编辑器集成 -- 存在
Java 后端: WriterAssistantController.writerAnswer() -- 存在但有 Bug
Python API: /rewrite/con_rewrite, /rewrite/exp_write, /gen_abstract 等 -- 部分可用

核心 Bug: Java→Python 参数格式不匹配

Java 后端 WriterAssistantController 在调用 Python API 时，将参数包装在 {"data": {...}} 结构中：

// WriterAssistantController.java:77-78
Map map = new HashMap();
map.put("data", writerAnswerVo);  // Python端期望的是扁平参数，不是嵌套在data字段里

但 Python 端各 endpoint 期望的是扁平参数格式（如 {"context":"...", "paragraph_content":"...", "query":"..."}），导致 Python 返回 422 Unprocessable Entity。

影响: 通过 Java 后端调用的所有写作辅助功能（续写、扩写、缩写、风格调整、要点提炼等）全部返回 500。

但直接调用 Python API 的续写、扩写功能是正常的。说明 Python 端代码没问题，是 Java→Python 的对接层出了问题。

可能的原因

原公司的 Python 后端可能有一个中间件来解析 data 字段，而我们部署的版本缺少这个中间件
或者 HttpUtil1.post() 方法在原版本中有不同的参数序列化方式
或者 Python API 在某次更新中改了参数格式但 Java 端没有同步更新

修复难度: 中等

需要修改 WriterAssistantController.java 的参数组装方式，使之匹配 Python API 的预期格式，然后重新编译 Java 后端。

十二、自行部署 vs 需要原公司支持的问题清单

我们自己能解决的问题

问题	解决方式	难度
Redis 配置错误	修改 `application-dev.yml` 指向本地 Redis (127.0.0.1:6379, 无密码)	简单
Java→Python 参数不匹配 (AI编辑器)	修改 `WriterAssistantController.java` 参数格式，重新编译	中等
`KnowledgeBaseController.java` 硬编码 URL	改为从配置文件读取 `chat.host`，重新编译	简单
`AliyunOSSUtil.java` 硬编码 Key	改为从配置文件读取或使用环境变量，重新编译	简单
`DocController.java` IP 硬编码	改为可配置，重新编译	简单
Python 路径硬编码 (`/home/albert/...`)	修改 `kb_config.py` 中的路径	简单
日志/上传路径不存在	创建目录或修改配置	简单
LLM API Key 替换	客户注册通义千问/DeepSeek 账户，修改 `model_config.py`	简单
阿里云 OSS 替换	客户准备自己的 OSS 账户，修改配置	简单
缩写/风格调整等 Python API Bug	调试 Python 端参数解析逻辑	中等
翻译功能返回格式异常	调试 `translate.py` 参数映射	中等
岗位智能体无数据	自行设计角色并插入 `gpt_assistant_type` 和 `gpt_assistant` 表	中等
应用广场无数据	自行设计工具卡片数据插入 `common_config` 表	中等
Streamlit WebUI 缺失	`pip install streamlit` (非核心, 仅调试用)	简单
Java 连接池超时告警	定期重启或优化 Druid 保活配置	简单
OAuth2/SSO 配置	关闭或对接客户自己的 SSO	中等
Nginx 反向代理	自行编写 Nginx 配置文件	简单
Docker 镜像源问题	替换为客户可访问的镜像源或提前拉取	简单

一定需要原公司支持（或需要客户提供内容）的问题

问题	为什么需要	替代方案
Milvus 向量知识库数据	三个核心知识库（政策库、报告库、期刊论文库）的向量数据是原公司用行业文档通过 bge-m3 模型向量化后存入 Milvus 的。我们没有原始文档。	替代方案 A: 要求原公司提供 Milvus 数据备份（最快）；替代方案 B: 要求原公司提供原始文档（PDF/Word），我们用本地 bge-m3 模型重新向量化入库（代码已有 `/knowledge_base/upload_docs` 接口）；替代方案 C: 客户自己收集行业文档，从零建库（最慢但完全自主）
搜索服务	原公司自建的搜索服务 (`123.56.15.82:10326/search`)，我们没有源码	可以用第三方搜索 API（如 Bing Search API）替代，或者直接去掉搜索功能
画图服务	原公司部署在内网的 AI 画图服务 (`192.168.56.123:5000`)，我们没有源码	可以接入其他 AI 画图 API（如通义万相、Stable Diffusion API），或去掉画图功能
`policy_fun.so` 编译文件	政策问答的核心逻辑被编译为 `.so` 文件，无法修改	有对应的 `policy_fun_iast.py` 可作为替代，功能基本等价
`aspose-words-21.1-jdk17.jar`	商业授权的 Word 文档处理库，用于报告导出	需要客户购买 Aspose 授权，或替换为免费的 Apache POI
`app-sign-sdk-0.0.2.jar`	无源码的签名 SDK，功能不明	需要确认是否在 dev 环境实际使用

关于知识库的详细说明

这是最核心的依赖项。知识库问答（政策问答、内容溯源、段落推荐、相关文献等）占业务需求表的约 30% 功能。

当前状态:

本地 Milvus 已部署并运行正常
嵌入模型 bge-m3 已在 /home/gc/gangyan/models/bge-m3 目录
Python 端有完整的向量化入库代码 (/knowledge_base/upload_docs)
缺的只是原始文档内容

自建知识库的可行性:

技术上完全可行：langchain-chat 已有文档上传→分段→向量化→入库的完整流程
但行业文档本身需要客户提供：政策文件、行业报告、期刊论文等
如果客户能提供 PDF/Word 格式的行业文档，我们可以自行完成向量化入库
预计需要数百到数千份文档才能达到原系统的知识库规模

建议向原公司索要的最小数据集:

Milvus 的数据备份（volumes 目录打包），或
原始文档文件列表及文件本身，或
至少提供知识库的文档来源说明（从哪些网站/数据库采集的）

十三、功能覆盖率修正 (基于实测数据)

之前的覆盖率评估部分基于代码分析推断，现修正为实际 API 调用验证的结果：

模块	总功能	实测正常	有 Bug 但可修	依赖缺失不可用	未实现
问答	12	6	0	5(知识库/智能体)	1(内容溯源)
写作	10	3	4(Java→Python对接Bug)	2(溯源/段落推荐依赖KB)	1(报告导出未测)
研读	10	5	2(翻译Bug/笔记参数)	1(相关文献依赖KB)	2(复制/文献库未测)
应用广场	2	0	0	0	2
合计	34	14(41%)	6(18%)	8(23%)	6(18%)

解读:

41% 可直接使用: 普通对话、多轮对话、深度思考、大模型切换、术语解释、问题推荐、智能大纲、续写、扩写、关键词提取、章节解析、名词解释、引用问答等
18% 有 Bug 但我们可以自行修复: AI编辑器参数对接、缩写/风格调整的Python参数、翻译返回格式等
23% 因知识库/智能体数据缺失不可用: 政策问答、知识库问答、内容溯源、段落推荐、相关文献、岗位智能体等 -- 需要原始文档数据
18% 未实现或未充分测试: 应用广场2项完全未开发，报告导出/复制/文献库管理未在API层面验证

44 KiB Raw Blame History Unescape Escape

项目交接部署审计报告

一、项目概述

二、交接时存在的主要问题

2.1 数据库仍连接原公司远程服务器 [严重]

2.2 无完整数据库 Schema 和数据迁移方案 [严重]

2.3 Milvus 向量数据库数据未交接 [严重]

2.4 多处硬编码原公司服务器 IP [严重]

2.5 第三方 API Key 硬编码在源码中 [中等]

2.6 Jasypt 加密密码泄露在源码注释中 [中等]

2.7 Java 源码中硬编码 API 地址 [中等]

2.8 绝对路径硬编码 [低]

2.9 OAuth2/SSO 集成指向外部系统 [低]

2.10 Docker 镜像使用代理源 [低]

三、我方已做的修改（为在 10.200.3.10 上启动）

3.1 Java 编译环境修复

3.2 新增 application-dev.yml 本地开发配置

3.3 本地 MySQL Docker 部署

3.4 本地 Milvus 向量数据库部署

3.5 前端修改

3.6 Python 后端配置

3.7 启动脚本

四、当前仍然缺失/需要解决的问题

4.1 Redis 服务 [必须解决]

4.2 Milvus 向量数据 [必须解决]

4.3 MySQL 业务数据 [必须解决]

4.4 阿里云 OSS 存储 [需要解决]

4.5 LLM API Key [需要解决]

4.6 搜索服务 [需要解决]

4.7 画图服务 [需要解决]

4.8 文件下载服务 [需要解决]

4.9 Python 依赖中的本机路径 [需要解决]

4.10 日志和上传路径 [建议解决]

五、给客户新服务器部署的完整检查清单

第一步：基础环境准备

第二步：数据库部署

第三步：配置修改

第四步：启动验证

六、二次开发可行性评估

6.1 整体评估: 中等可行 (有一定门槛)

6.2 二次开发的优势

6.3 二次开发的风险和难点

6.4 建议的二次开发优先级

七、各配置文件完整 IP/凭证清单

原公司 IP 地址

凭证清单

八、运行时启动测试结果 (2026-02-26 实测)

8.1 基础设施状态

8.2 三大服务启动状态

8.3 实际 API 测试结果

登录测试

逐项 API 实测结果 (curl 调用验证)

关键发现的运行时问题

8.4 MySQL 数据库数据量统计

九、业务需求表 vs 代码实现功能对比

9.1 模块一：问答

9.2 模块二：写作

9.3 模块三：研读

9.4 模块四：应用广场

9.5 功能覆盖率总结

9.6 修复优先级（提升覆盖率的最快路径）

十、总结

十一、AI 编辑器详细问题分析

当前状态

核心 Bug: Java→Python 参数格式不匹配

可能的原因

修复难度: 中等

十二、自行部署 vs 需要原公司支持的问题清单

我们自己能解决的问题

一定需要原公司支持（或需要客户提供内容）的问题

关于知识库的详细说明

十三、功能覆盖率修正 (基于实测数据)

44 KiB

Raw Blame History