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

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:
2026-10-12 12:37:33 +08:00
parent a2a83f7d9e
commit a8c8dd8643
10 changed files with 240 additions and 158 deletions
@@ -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 分钟。
@@ -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);
}
@@ -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;
@@ -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;
+11
View File
@@ -9,6 +9,10 @@ spring:
driver-class-name: com.mysql.cj.jdbc.Driver
type: com.alibaba.druid.pool.DruidDataSource
redis:
database: 0
host: 127.0.0.1
port: 6379
# 日志配置
logging:
level:
@@ -27,3 +31,10 @@ config:
wxpay:
private-key-path: /Users/liangxin/Project/JAVA/guoxue-java/src/main/resources/cert/apiclient_key.pem
pub-key-path: /Users/liangxin/Project/JAVA/guoxue-java/src/main/resources/cert/44ad9c08a0ab46dd8fc555178df581c4.pem
# Dify 对接不在此覆盖。
#
# 2026-10-12 迁移后,application.yml 的默认值就是内网实例,开发与生产共用同一套
# 地址与密钥,这里再写一份只会造成两处维护、且极易与默认值漂移。
# VPN 已可直连 10.100.158.15,故本地开发无需再走另一套实例。
# 如确需覆盖(例如临时指向其它环境),在此加 dify.base-url 与对应密钥。
+6 -51
View File
@@ -38,55 +38,10 @@ wxpay:
private-key-path: /www/wwwroot/tuanwei/cert/apiclient_key.pem
pub-key-path: /www/wwwroot/tuanwei/cert/44ad9c08a0ab46dd8fc555178df581c4.pem
# Dify 平台对接(生产走内网实例)
# Dify 平台对接不在此覆盖。
#
# 2026-09-19 由公网 82.156.98.71 切至内网 10.100.158.15。
# 切换依据:内网实例 8 个应用全部可用且知识库内容更全
# (竞赛案例 146 篇 / GXMU团章 10 篇,公网侧仅挑战杯 5 篇 / GXMU团章 9 篇)。
#
# 两个实例的应用 Key 与知识库 ID 完全不通用,不可混用:
# 公网 Key 打到内网、或反之,一律返回 401。
# 因此下面每一项都必须成对覆盖,漏掉一项就会因公网 Key 失效而报错。
#
# 内网的 6 个存量应用变量名与公网一致(已由 probe-dify.sh 两轮实测比对),
# 故此处只需覆盖地址与密钥,不必动 workflows 变量映射。
dify:
base-url: http://10.100.158.15/v1
apps:
# 1 医科大团委智能知识库问答系统
chat: app-ZLUUbLkAX3FVzDubY06puxAo
# 2 活动策划大纲生成
activity-outline: app-4oBWB3HrdNlANdPFG8ZvVTkY
# 3 医科大智能文档处理系统
document-process: app-ohdIhk0lVfUwoy10xXRebmjD
# 4 AI 内容创作与宣传助手
manuscript: app-fhhz4fXMkEdVivAEiuWpycn6
# 5 AI 创意助手
creative-assistant: app-lAbpxMggNbIrByiDRDfckSSl
# 6 项目书质量初审
project-quality-review: app-J6h5I6Bo4oeBif2EofBGVrGs
# 7 申报书生成
declaration: app-k20aDmiQYh3LxqZSLuX8wjkU
# 8 竞赛文件预处理
competition-history-preprocess: app-UzVLKnGwg69uAUdbgFx6XNmc
dataset:
# 内网两个知识库各自签发独立密钥,注意与上面的应用 Key 不同前缀(dataset-)
api-key: dataset-jaqtnAQvYcQTEjECzxhQfNCv
# 注意:YAML 的 map 是"按键合并"而非整体替换 —— application.yml 里登记的
# 公网库密钥不会因为这里重写了 keys 就消失,而是与本段合并。
# 因此这里把公网那两个 ID 也显式指到内网密钥,避免残留一条指向公网实例的死密钥
# (残留后表现为"某个知识库接口偶发 401",很难查)。
keys:
# 内网知识库
181d58e3-78c2-4b7d-939c-57e780a8f7d6: dataset-jaqtnAQvYcQTEjECzxhQfNCv
3e0ac108-3a0d-41e2-8447-aa1c1044d3ac: dataset-f2a0Hjxix7lBcPNZtNMyKDTQ
# 公网知识库 ID:生产下同样指到内网密钥,杜绝残留公网密钥
b342f096-98b1-4a83-a296-f4ab60a6db0e: dataset-jaqtnAQvYcQTEjECzxhQfNCv
aa72c649-71a0-46e7-ac55-47f44b397a4e: dataset-f2a0Hjxix7lBcPNZtNMyKDTQ
ids:
# 内网知识库(生产实际使用)
competition-cases: 181d58e3-78c2-4b7d-939c-57e780a8f7d6
gxmu-constitution-internal: 3e0ac108-3a0d-41e2-8447-aa1c1044d3ac
# 公网知识库 ID 保留登记,便于切回时对照;生产下不应被业务引用
challenge-cup: b342f096-98b1-4a83-a296-f4ab60a6db0e
gxmu-constitution: aa72c649-71a0-46e7-ac55-47f44b397a4e
# 2026-10-12 迁移:原先此处整段覆盖为内网实例(因 application.yml 默认值指向公网)。
# 默认值已改为内网,生产与开发共用 application.yml 的同一套地址与密钥,
# 故本段整体移除 —— 保留一份"与默认值相同"的覆盖只会增加漏改风险。
# 注意 YAML 的 map 是按键合并而非整体替换:若在此只写部分 keys,
# 会与默认值合并出混合状态,这正是要避免的。
+39 -32
View File
@@ -105,70 +105,77 @@ wxpay:
# Dify 平台对接
#
# 注意这里有两套环境,Key 与知识库 ID 互不通用(实测:文档给的 Key 打到 82.156.98.71 上全部 401):
# 1) 公网实例 http://82.156.98.71/v1 —— 当前线上在用的实例,下列默认值即取自它
# 2) 内网实例 http://10.100.158.15/v1 —— 见《Dify API 文档》,已由服务器实测 8 个应用全部 200
# 切到内网实例时,在 application-prod.yml 覆盖 base-url 与全部 apps/dataset 密钥即可。
# 不要直接改这里的默认值,否则本地开发会一起被切走。
# 唯一的实例:内网 http://10.100.158.15/v1(见《Dify API 文档》)。
#
# 2026-10-12 完成迁移:此前代码连的是公网实例 http://82.156.98.71/v1,
# 因开发机连不上内网而一直保留双份配置;VPN 打通后已全部并入内网。
#
# 两套实例的应用 Key、知识库 ID、密钥完全不通用(实测互打一律 401),
# 因此公网那套配置已整体移除,遗留一份只会造成误用。若确需回退,
# 到 git 历史取本段即可,不要再在配置里维护两套。
dify:
base-url: http://82.156.98.71/v1
base-url: http://10.100.158.15/v1
timeout-ms: 600000
apps:
# 医科大团委智能知识库问答系统
chat: app-ou0qPesouiopaPpmxcFV2gFG
# 活动策划大纲生成
activity-outline: app-hp4PJknbejImmdDuMfziVcnN
chat: app-ZLUUbLkAX3FVzDubY06puxAo
# 活动策划大纲生成(advanced-chat,走 /chat-messages)
activity-outline: app-4oBWB3HrdNlANdPFG8ZvVTkY
# AI 内容创作与宣传助手
manuscript: app-hCzkdd6OsnMnwI2dQByLyNIN
manuscript: app-fhhz4fXMkEdVivAEiuWpycn6
# AI 创意助手
creative-assistant: app-l3accBEJLDAh9Pn8fLW8nNJ0
creative-assistant: app-lAbpxMggNbIrByiDRDfckSSl
# 项目书质量初审
project-quality-review: app-HiI2FrNjcwL0A7QOOf7GIP50
project-quality-review: app-J6h5I6Bo4oeBif2EofBGVrGs
# 竞赛文件预处理
competition-history-preprocess: app-bhyQLMAw2JEDXMTs2mzNRiIU
competition-history-preprocess: app-UzVLKnGwg69uAUdbgFx6XNmc
# 医科大智能文档处理系统
# 公网实例上该 Key 无效(实测 401),仅内网实例可用,故允许环境变量覆盖
document-process: ${DIFY_KEY_DOCUMENT_PROCESS:app-ohdIhk0lVfUwoy10xXRebmjD}
# 申报书生成,同上
# 申报书生成
declaration: ${DIFY_KEY_DECLARATION:app-k20aDmiQYh3LxqZSLuX8wjkU}
dataset:
# 知识库列表等不区分知识库的接口所用密钥
api-key: ${DIFY_DATASET_API_KEY:dataset-1n6MECRtQvEVGOL1o7SrSGfe}
# 知识库列表等不区分知识库的接口所用密钥。
# 实测该密钥对实例内全部知识库均可用,keys 里逐库登记仅为将来分权留口子。
api-key: ${DIFY_DATASET_API_KEY:dataset-jaqtnAQvYcQTEjECzxhQfNCv}
# 知识库 ID -> 独立密钥
keys:
b342f096-98b1-4a83-a296-f4ab60a6db0e: ${DIFY_DATASET_API_KEY:dataset-1n6MECRtQvEVGOL1o7SrSGfe}
aa72c649-71a0-46e7-ac55-47f44b397a4e: ${DIFY_DATASET_API_KEY:dataset-1n6MECRtQvEVGOL1o7SrSGfe}
# 内网实例的两个知识库各自签发独立密钥
181d58e3-78c2-4b7d-939c-57e780a8f7d6: ${DIFY_DATASET_KEY_COMPETITION:dataset-jaqtnAQvYcQTEjECzxhQfNCv}
3e0ac108-3a0d-41e2-8447-aa1c1044d3ac: ${DIFY_DATASET_KEY_GXMU:dataset-f2a0Hjxix7lBcPNZtNMyKDTQ}
# 业务代号 -> 知识库 ID
ids:
# 公网实例现用:挑战杯历史案例(5 篇)
challenge-cup: b342f096-98b1-4a83-a296-f4ab60a6db0e
gxmu-constitution: aa72c649-71a0-46e7-ac55-47f44b397a4e
# 内网实例:竞赛案例(146 篇)、GXMU 团章(10 篇)
# 竞赛案例(145 篇)。admin 端「竞赛历史」文档列表接口按此代号取库。
competition-cases: 181d58e3-78c2-4b7d-939c-57e780a8f7d6
gxmu-constitution-internal: 3e0ac108-3a0d-41e2-8447-aa1c1044d3ac
# GXMU 团章(10 篇)
gxmu-constitution: 3e0ac108-3a0d-41e2-8447-aa1c1044d3ac
# 工作流变量名映射。
# 左边是入参实体的业务字段(中划线),右边是 Dify 工作流开始节点的真实变量名。
#
# 下两段取自 2026-09-19 在内网实例上跑 probe-dify.sh 的实际输出,
# 注意它们与公网实例的命名习惯并不一致 —— 不要凭直觉推断,必须以探针输出为准。
# 以下取自 2026-10-12 在内网实例上重跑 probe-dify.sh 的实际输出。
# 该实例的变量名会随工作流编排调整而漂移,所以每次动工作流都要以探针输出为准,
# 不要凭直觉推断。
#
# 映射为空串 = 丢弃该字段(见 DifyProperties.VariableMapping 的约定),
# 下面的失效变量即用此法显式剔除:它们已不在开始节点上,
# 留着只会让人误以为仍在生效。注意不要直接删掉整行 —— 那会退回"按原名透传",
# 反而把 pdfUrl / parseValue 这种驼峰名发给 Dify。
workflows:
# 内网实测: query,pdf_url,pdf_file(文件类)
# 内网实测仅 pdf_file(文件类)。query/pdf_url 已从开始节点移除,故丢弃;
# 实体里仍保留这两个字段,是为了不破坏 /documentProcess/upload 的入参契约
# (前端仍可传,只是不再转发给 Dify)。
document-process:
fields:
query: query
pdf-url: pdf_url
query: ""
pdf-url: ""
pdf-file: pdf_file
# 内网实测: core_idea,tech_route,team_intro,upload_file(文件类),parse_value
# 内网实测 core_idea,tech_route,team_intro,upload_file(文件类)。
# parse_value 已从开始节点移除,故丢弃。
declaration:
fields:
core-idea: core_idea
tech-route: tech_route
team-intro: team_intro
upload-file: upload_file
parse-value: parse_value
parse-value: ""
# 医科大开放平台对接
gxmu: