dify封装接口；服务器防火墙放开端口；dify中处理LLM的自然语言输出；

1.dify封装接口schema
👉 schema =「机器能调用接口的合同」
Dify 用的是 OpenAPI 3.0.x 的子集，本质上只关心 4 件事：
接口地址（POST / GET）
入参怎么传（query / json / form-data / file）
返回 JSON 长什么样
operationId（函数名）

OpenAPI schema 写法触发了 Dify 的一个已知坑；
👉所有参数都是 Form(...)（即纯文本输入）、没有真正的 file 字段、 Dify 认为这是“普通表单”，不是“文件上传”

场景	Content-Type
纯文本	application/x-www-form-urlencoded
单/多文件	multipart/form-data
JSON Body	❌（Dify Tool 基本不稳定）
📌 只要不是上传文件，一定不要用 multipart

2.服务器防火墙放开端口
在写好接口后，让运维代理了接口：
👉 Nginx

location /ollama_api/ {
    proxy_pass http://127.0.0.1:8003/ollama_api/;
    proxy_set_header Host $host;
    client_max_body_size 100m;
}

👉 发出请求：
https://oa1.gxlky.com.cn/ollama_api/chat/pdf
👉 返回502：
502 Bad Gateway = 网关（nginx）能接到请求，但连不上“后端服务”
👉 验证Uvicorn / FastAPI（其实是活的）：
👉 得出结论：
问题根因：GPU 服务器防火墙（firewalld / iptables）阻断了端口 8003

问题解决：
放行端口 8003（firewalld）
firewall-cmd --add-port=8003/tcp --permanent
firewall-cmd --reload
验证：
firewall-cmd --list-ports

3.dify中处理LLM的自然语言输出
👉 在处理LLM输出问题上，我发现LLM模型基本输出的都是字符串，dify调取ollama接口后获取的都是字符串，没办法使用。
👉 进一步研究发现。因为LLM模型输出是不稳定的，现在都是基于以下步骤来解决不稳定问题：
（1）LLM 原始输出 （2）提取 JSON 片段 （3）宽松解析（json5 / ast） （4）自动修复 （5） Schema 校验 （6） 最终 JSON
👉其中（2~4）可以使用json-repair直接解决。
json-repair 是一个宽松 JSON 修复器
能够修复单引号 → 双引号、尾逗号、缺引号的 key、True / False / None、多余文本前后包裹、非法转义
👉（5） Schema 校验在Dify 的 Parameter Extractor 节点进行校验