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:
@@ -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:
|
||||
|
||||
Reference in New Issue
Block a user