b2894lxlx/tuanwei-java
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(dify): 全部迁移到内网实例，统一为单份配置

Browse Source 
VPN 打通后开发机可直连内网，原先「默认公网 + prod 覆盖内网」的双份配置
已无必要，且两套 Key/知识库 ID 完全不通用（实测互打一律 401），
留着只会造成误用。公网那套整体移除，回退到 git 历史取。

- application.yml：base-url 与 8 个应用 Key、全部知识库密钥/ID 改指内网；
  原默认值来自公网，其注释同步改写
- application-dev.yml / application-prod.yml：删除 dify 覆盖段。
  YAML map 是按键合并而非整体替换，保留一份与默认值相同的覆盖
  只会在将来漏改时混出「一半内网一半公网」的状态
- DifyProperties：默认 baseUrl 改内网，类注释同步

修复一个上线起就坏的接口：

- admin 端「竞赛历史」文档列表按 challenge-cup 取库，而该 ID
  b342f096-… 在**公网实例上也返回 404**（公网真实的挑战杯库是
  7c812029-…，从未登记），故该接口一直不可用。改指内网「竞赛案例」
  库（181d58e3-…，145 篇），实测已能列出文档。对外路径保持
  /challenge-cup/documents 不变，以免影响 admin 端调用

清理失效的工作流变量（内网实测已从开始节点移除）：

- document-process 的 query / pdf_url，declaration 的 parse_value。
  三者配置为空串以显式丢弃 —— 直接删行会退回「按原名透传」，
  反而把 pdfUrl / parseValue 这类驼峰名发给 Dify。实体字段保留，
  不破坏 /documentProcess/upload 的入参契约（pdfUrl 仍参与
  「必须提供文件或 pdfUrl」的校验，只是不再转发）
- 注：Dify 对多传变量静默忽略，故此前不报错、功能未受影响，
  属「看着对其实无效」的配置

测试：改断言为内网值，并新增「不残留任何公网配置」「失效变量必须
配成空串」等防回归用例；变异验证（base-url 改回公网 / 空串改回生效名）
确认用例有真实判别力。Dify 相关 44 例全绿。

Refs: .scratch/dify-probe/README.md, .scratch/ai-assistant/map.md
This commit is contained in:
weicw1996
2026-10-12 12:37:33 +08:00
parent a2a83f7d9e
commit a8c8dd8643
10 changed files with 240 additions and 158 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/main/java/com/gxwebsoft/ai/config/DifyProperties.java
+5 -4
View File
@@ -13,9 +13,10 @@ import java.util.Map;
* 中，换环境要改代码、Key 还会进版本库。此处统一外置到 {@code application.yml} 的
* {@code dify} 节点，各环境可在 {@code application-{profile}.yml} 中按需覆盖。
*
* <p>关于两套环境：文档《Dify API 文档》给出的是内网实例 {@code http://10.100.158.15/v1}
* （与开放平台 IP 白名单同机），当前代码里连的是公网实例 {@code http://82.156.98.71/v1}。
* 二者应用 Key、知识库 ID 均不通用，因此这里按环境分别配置，默认沿用现有公网实例以保证在跑的功能不受影响。
* <p>关于实例：2026-10-12 起统一使用内网实例 {@code http://10.100.158.15/v1}
* （见《Dify API 文档》，与开放平台 IP 白名单同机）。此前因开发机无法直连内网，
* 默认值曾指向公网实例 {@code http://82.156.98.71/v1}，现已随 VPN 打通一并迁移；
* 两套实例的应用 Key 与知识库 ID 互不通用（互打一律 401），故不再保留双份配置。
*
* @author Codex
* @since 2026-09-19
@@ -27,7 +28,7 @@ public class DifyProperties {
/**
* 接口地址前缀，不含结尾斜杠
*/
private String baseUrl = "http://82.156.98.71/v1";
private String baseUrl = "http://10.100.158.15/v1";
/**
* 单次请求超时时间(毫秒)。AI 工作流耗时较长，默认 10 分钟。
src/main/java/com/gxwebsoft/ai/controller/KnowledgeBaseController.java
+14 -3
View File
@@ -164,15 +164,26 @@ public class KnowledgeBaseController extends BaseController {
// ---------------------------------------------------------------- 兼容旧接口
@ApiOperation("挑战杯历史案例知识库文档列表")
/**
* 竞赛历史案例知识库文档列表。
*
* <p>路径里的 {@code challenge-cup} 是历史遗留的对外接口名，admin 端仍按此调用，
* 故保留路径不动；实际取的是「竞赛案例」库（内网实例，145 篇）。
*
* <p>2026-10-12 迁移修复：原先这里解析 {@code dify.dataset.ids.challenge-cup}，
* 而该 ID 指向公网实例的挑战杯库 —— 经实测它在公网、内网两侧**都返回 404**
* （公网真实的挑战杯库是 7c812029-…，从未登记），也就是说这个接口从上线起就是坏的。
* 迁移到内网后改按 {@code competition-cases} 解析，接口才真正可用。
*/
@ApiOperation("竞赛历史案例知识库文档列表")
@GetMapping("/challenge-cup/documents")
public ApiResult<?> challengeCupDocuments(
@RequestParam(value = "page", defaultValue = "1") Integer page,
@RequestParam(value = "limit", defaultValue = "20") Integer limit,
@RequestParam(value = "keyword", required = false) String keyword) {
String datasetId = difyProperties.getDataset().idOf("challenge-cup");
String datasetId = difyProperties.getDataset().idOf("competition-cases");
if (StrUtil.isBlank(datasetId)) {
return fail("未配置 challenge-cup 知识库 ID，请检查 dify.dataset.ids.challenge-cup");
return fail("未配置竞赛案例知识库 ID，请检查 dify.dataset.ids.competition-cases");
}
return documents(datasetId, page, limit, keyword);
}
src/main/java/com/gxwebsoft/ai/entity/DeclarationInputs.java
+9 -6
View File
@@ -13,9 +13,12 @@ import java.io.Serializable;
* <p>业务说明：根据项目核心创意、技术路线和团队情况生成申报书初稿；
* 已提供初稿时可结合前沿资料优化完善。
*
* <p><b>字段名对齐 Dify 工作流开始节点的真实变量名</b>，取自 2026-09-19
* 在内网实例 10.100.158.15 上跑 probe-dify.sh 的实测输出：
* {@code core_idea, tech_route, team_intro, upload_file(文件类), parse_value}。
* <p><b>字段名对齐 Dify 工作流开始节点的真实变量名</b>，取自内网实例
* 10.100.158.15 上 probe-dify.sh 的实测输出（2026-10-12 重测）：
* {@code core_idea, tech_route, team_intro, upload_file(文件类)}。
* 早先实测还有 {@code parse_value}，现已从开始节点移除；{@link #parseValue}
* 仍在入参实体上（外部调用方可继续传，避免破坏接口契约），但映射表已把它
* 配置为空串，**不会下发给 Dify**。
*
* <p>发送时仍会经 {@code dify.workflows.declaration.fields} 映射一次，
* 保留这一层是为了让变量名再次变动时只改 yml、不改代码。
@@ -55,10 +58,10 @@ public class DeclarationInputs implements Serializable {
private Object uploadFile;
/**
* 解析取值开关。对应 Dify 变量 parse_value。
* 解析取值开关。
*
* <p>类型未在探针中确定（探针只给变量名不给类型），
* 故用 Object 承接，传布尔、字符串或数字均可，由 Dify 侧决定语义。
* <p><b>当前不会下发给 Dify</b>：原对应变量 {@code parse_value} 已从工作流开始
* 节点移除，映射表把它配置为空串以显式丢弃。字段保留是为了不破坏入参契约。
*/
@TableField(exist = false)
private Object parseValue;
src/main/java/com/gxwebsoft/ai/entity/DocumentProcessInputs.java
+15 -5
View File
@@ -13,9 +13,11 @@ import java.io.Serializable;
* <p>业务说明：对上传的 PDF 或网络文件进行解析、清洗、分段、关键词提取，
* 处理结果导入「GXMU 团章」知识库。因此文件来源有二：上传文件或网络 PDF 地址。
*
* <p><b>字段名对齐 Dify 工作流开始节点的真实变量名</b>，取自 2026-09-19
* 在内网实例 10.100.158.15 上跑 probe-dify.sh 的实测输出：
* {@code query, pdf_url, pdf_file(文件类)}。
* <p><b>字段名对齐 Dify 工作流开始节点的真实变量名</b>，取自内网实例
* 10.100.158.15 上 probe-dify.sh 的实测输出（2026-10-12 重测）：
* {@code pdf_file(文件类)}。
* 早先实测还有 {@code query, pdf_url}，现均已从开始节点移除；映射表已把这两个
* 字段配置为空串（丢弃），故 {@link #query} 与 {@link #pdfUrl} 不会被下发给 Dify。
*
* <p>发送时仍会经 {@code dify.workflows.document-process.fields} 映射一次，
* 保留这一层是为了让变量名再次变动时只改 yml、不改代码。
@@ -29,13 +31,21 @@ import java.io.Serializable;
public class DocumentProcessInputs implements Serializable {
/**
* 处理指令或补充说明。对应 Dify 变量 query
* 处理指令或补充说明。
*
* <p><b>当前不会下发给 Dify</b>：原对应变量 {@code query} 已从工作流开始节点移除，
* 映射表把它配置为空串以显式丢弃。字段保留是为了不破坏
* {@code /api/ai/documentProcess/upload} 的入参契约。
*/
@TableField(exist = false)
private String query;
/**
* 网络 PDF 地址。对应 Dify 变量 pdf_url
* 网络 PDF 地址。
*
* <p><b>当前不会下发给 Dify</b>：原对应变量 {@code pdf_url} 已从开始节点移除，
* 映射表配置为空串以显式丢弃。注意 {@code /documentProcess/upload} 仍接受
* {@code pdfUrl} 参数并参与"必须提供文件或 pdfUrl"的校验，只是不再转发给 Dify。
*/
@TableField(exist = false)
private String pdfUrl;