Dify_专题九_其它配置问题解决_cursor.md

这是基于原文生成的 Cursor 版文档。

原文件未改动；本版只做三件事：统一阅读入口、修正已审出的明显问题、补充更适合快速排障的提示。

Cursor 版修订说明

• 修正“已独立成专题七 / 八 / 九”为“已独立成专题六 / 七 / 八”。
• 保留原汇总定位，但在 Cursor 版中加强索引页属性。

阅读提示

• 若正文中的容器名、目录名、IP 与你的环境不一致，请以实际 docker ps、docker compose ps、目录结构为准。
• 若正文属于“本次实战记录”，应理解为环境实录，不等同于所有环境的唯一正确默认值。

运行环境：业务脚本均在 207 固定目录 /opt/workbuddy 执行，Python 为 /usr/bin/python3。 Windows 开发机仅保留 _probe_* 调试脚本；同步命令：python scripts_cursor/完整代码约定/00_部署_workbuddy到207.py。

原文主体（已纳入 Cursor 版纠错）

专题九：八个专题之外的配置期问题解决汇总

阅读导航（何时打开 · 报错往哪查）

本文是单点修复/排障专题，配合《安装配置手册》使用；下文实战步骤与代码全部保留，此处只做索引。

本文汇总专题一~八未单独展开、但在本次部署中同样被"问到并解决"的配置类问题：

Dify 控制台登录、vLLM 启动命令的两次崩溃 + 一次告警与最终参数、共享 GPU 显存保护、

context_size 对齐 64000。

（原收录的「Agent 应用 shell provider 修复」「插件 patch 的 from __future__ 顺序子坑」「weaviate 中继」三节，

已独立成《Dify_专题六_weaviate中继.md》（专题六）、《Dify_专题七_Agent_shell_provider修复.md》（专题七）、

《Dify_专题八_插件patch_future顺序子坑.md》（专题八）。）所有涉及命令/代码/脚本均直接附上。

一、Dify 控制台登录凭据与登录机制

1.1 登录凭据

1.2 登录机制（脚本化调用须知）

Dify 控制台 API 不是简单 POST 表单，而是：

1. 密码要先做 base64 编码再提交；
2. POST /console/api/login 成功后，在响应 cookie 里返回 access / refresh / csrf_token；
3. 后续所有控制台/工作区请求都要带请求头 X-CSRF-Token: <csrf_token cookie 值>，否则 403。

本环境封装在 dify_api.py（复用客户端）里：

完整程序：/opt/workbuddy/scripts_cursor/Dify_专题九_其它配置问题解决/专题九_内联_01.py

运行/引用：/usr/bin/python3 /opt/workbuddy/scripts_cursor/Dify_专题九_其它配置问题解决/专题九_内联_01.py

# dify_api.py 关键逻辑（示意）
import base64, requests

class Dify:
    def login(self):
        pw_b64 = base64.b64encode(self.password.encode()).decode()
        s = requests.Session()
        r = s.post(f"{self.host}/console/api/login",
                   json={"email": self.email, "password": pw_b64,
                         "language": "zh-Hans", "remember_me": True},
                   timeout=30)
        # 从 cookies 取 csrf_token
        self.csrf = s.cookies.get("csrf_token")
        s.headers.update({"X-CSRF-Token": self.csrf})
        return r.ok

API 端点调用统一走 /v1（应用层）、/console/api（控制台层）、/workspaces/current/...（工作区层）。

二、vLLM 启动命令的三次报错与最终正确参数

Qwen3.6-27B 是标准 Qwen3 instruct，模型的 config.json 里 model_type = qwen3_5（较新架构）。

启动 vLLM 容器时连续踩了三个坑，下面按出现顺序说明。

2.1 报错 1：KeyError: invalid tool call parser: qwen3

日志关键行：

KeyError: 'invalid tool call parser: qwen3 (chose from { ... qwen3_coder, qwen3_xml, ... })'

根因：vLLM 里从来没有 qwen3 这个 parser 名。标准 Qwen3 instruct 的正确 parser 是 qwen3_xml； qwen3_coder 仅给 Qwen3-Coder；hermes 是 Qwen3 MoE 默认。误填 qwen3 直接崩溃。

解决：--tool-call-parser qwen3_xml。

2.2 报错 2：model type qwen3_5 not recognized by Transformers

日志关键行：

ValueError: Model type 'qwen3_5' not recognized. ... (Should you mean 'qwen3'?)
pydantic_core._pydantic_core.ValidationError: ...

根因：启动时一度尝试固定 vllm/vllm-openai:0.10.2，但该版本自带的 transformers 不认 qwen3_5 架构 → 启动崩溃。 （注：qwen3_5 是 Qwen3.6 的较新架构名，老版本 vLLM 没登记。）

解决：镜像必须用 latest（实测拉到 vLLM 0.25.1），它原生支持 qwen3_5 架构，且内置 qwen3_xml 与 qwen3 推理解析器。 不要 pin 0.10.2。

2.3 告警：--model 选项已弃用

WARNING: With `vllm serve`, you should provide the model as a positional argument
instead of via the `--model` option. The `--model` option will be removed in a future version.

根因：vLLM 新版本推荐把模型路径作为位置参数而不是 --model。只是告警，不影响启动。

解决：--model /model 改为位置参数 /model（写在镜像名之后）。

2.4 最终正确启动脚本（已落盘 vllm_qwen_run.sh）

完整脚本：scripts_bash_cursor/Dify_专题九_其它配置问题解决/专题九_内联_01.sh

运行/引用：bash /opt/workbuddy/scripts_bash_cursor/Dify_专题九_其它配置问题解决/专题九_内联_01.sh

#!/usr/bin/env bash
# vLLM 启动 qwen3.6-27b —— H20(96GB) 共享 GPU、业务进程不可受影响 优化版
#
# 模型 model_type = qwen3_5；镜像必须用 latest(实测 vLLM 0.25.1) 才能识别该架构。
# 工具解析器：标准 Qwen3 instruct 必须用 --tool-call-parser qwen3_xml（qwen3 不存在，qwen3_coder/hermes 不适用）。
# 另加 --reasoning-parser qwen3：把思考块从工具调用中分离。
# GPU 约束：业务(mxh_env/mxh_live)已占 ~11.3GB，必须留余量。

# 先清理同名旧容器（含上次崩溃的 exited 容器），保证可重复运行
docker rm -f vllm-qwen3.6-27b 2>/dev/null || true

docker run -d \
  --name vllm-qwen3.6-27b \
  --restart always \
  --gpus all \
  --shm-size=8g \
  -p 8000:8000 \
  -v /models/Qwen3.6-27B:/model \
  -e HF_HUB_OFFLINE=1 \
  --log-opt max-size=100m \
  --log-opt max-file=3 \
  docker.m.daocloud.io/vllm/vllm-openai:latest \
  /model \
  --trust-remote-code \
  --dtype bfloat16 \
  --tensor-parallel-size 1 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_xml \
  --reasoning-parser qwen3 \
  --max-model-len 65536 \
  --gpu-memory-utilization 0.75 \
  --max-num-seqs 8 \
  --served-model-name qwen3.6-27b \
  --enable-prefix-caching \
  --host 0.0.0.0 \
  --port 8000

2.5 关键参数含义表

三、共享 GPU 显存保护（H20，业务不可受影响）

3.1 问题

vLLM 跑在 H20（约 95.5GB 显存）上，但该卡同时跑业务进程 mxh_env / mxh_live（占约 11.3GB），这些业务不能被影响。

最初 --gpu-memory-utilization 0.80 偏高，会挤压业务显存导致业务 OOM。

3.2 解决

• gpu-memory-utilization 压到 0.75（≈71.6GB）：权重约 54GB + KV 约 17GB，留约 24GB 给业务；
• max-num-seqs 压到 8：共享 GPU 下降低并发 KV 压力，65536 上下文 / 8 并发下 KV 仅需约 5GB；
• --shm-size=8g + --log-opt max-file=3：避免共享内存不足与日志无限增长。

验证：nvidia-smi 看业务进程显存稳定、vLLM 进程占用在 ~71GB 区间，业务不受影响即达标。

四、context_size 对齐 64000（Dify 凭据与 vLLM 匹配）

4.1 问题

Dify 里 Qwen 凭据的 context_size 来自克隆的通用 schema，默认是 1.05M（1048576），但 vLLM 的 --max-model-len 只有 65536。 两者不匹配会导致：长上下文提问时 Dify 拼的消息超过 65536 被 vLLM 拒绝；或不匹配引发不可预期行为。

4.2 解决：脚本化对齐

用 align_qwen_ctx.py（已落盘）把 context_size 改为 64000，与 vLLM 对齐。注意：不要把 max_tokens 写进 model_properties——Dify 的 ModelPropertyKey 枚举不含 MAX_TOKENS，加了会导致 API 端解析 schema 时 Pydantic 校验失败、GET /models/model-types/llm 返回空列表、创建 Agent 报错。

完整程序：/opt/workbuddy/scripts_cursor/Dify_专题九_其它配置问题解决/专题九_内联_02.py

运行/引用：/usr/bin/python3 /opt/workbuddy/scripts_cursor/Dify_专题九_其它配置问题解决/专题九_内联_02.py

import json
from dify_api import Dify

EMAIL = "38205036@qq.com"
PW = "Difyai123456"
PROVIDER = "langgenius/openai/openai"
MODEL = "qwen3.6-27b"
NEW_CTX = 64000
# 不要在这里加 max_tokens；max_tokens 是 parameter_rule，不是 model_properties。
# Dify API 端 ModelPropertyKey 枚举不含 MAX_TOKENS，写进去会触发 schema 校验失败。
d = Dify(EMAIL, PW)
ok, resp, csrf = d.login()
print("LOGIN ok=%s" % ok)
if not ok:
    d.close(); raise SystemExit("login failed")

# 1) GET current credential (decrypted) + credential_id
r = d.get("/workspaces/current/model-providers/%s/models/credentials?model_type=llm&model=%s"
          % (PROVIDER, MODEL))
js = r["json"] or {}
print("GET cred HTTP", r["code"])
cur_cred = js.get("credentials") or {}
cid = js.get("current_credential_id")
print("current_credential_id:", cid)
print("existing model_properties:", cur_cred.get("model_properties"))

# 2) inject/overwrite model_properties (只保留 context_size)
cred = dict(cur_cred)
cred["model_properties"] = {
    "context_size": NEW_CTX,
}
name = js.get("current_credential_name") or "Qwen3.6-27b"

# 3) PUT update
r = d.req("PUT", "/workspaces/current/model-providers/%s/models/credentials" % PROVIDER,
          body={
              "model": MODEL,
              "model_type": "llm",
              "credential_id": cid,
              "credentials": cred,
              "name": name,
          })
print("\nPUT cred HTTP", r["code"], r["text"][:200])

# 4) verify schema context_size via model list
import time; time.sleep(2)
r = d.get("/workspaces/current/models/model-types/llm")
js = r["json"] or {}
for p in js.get("data", []):
    if p.get("provider") == PROVIDER:
        for m in p.get("models", []):
            if m.get("model") == MODEL:
                mp = m.get("model_properties") or {}
                print("\nVERIFY model=%s status=%s mode=%s context_size=%s"
                      % (m.get("model"), m.get("status"), mp.get("mode"),
                         mp.get("context_size")))

d.close()
print("\nALIGN_DONE")

运行：

python align_qwen_ctx.py

注意（前置条件）：脚本执行时 vLLM 端点 116.62.10.183:8000 必须已通。Dify 在保存凭据前会做连通性校验， 若端口不通会报 Connection error。所以务必先让 vLLM 起来、端口可达，再跑本脚本（这正好对应专题五第 2 层）。

4.3 一个深坑：凭据级 model_properties 不持久化 + schema 缓存

上面 4.2 的 align_qwen_ctx.py 只是"第一层"修复，不保证列表里看到 64000。本次实测踩到的深层问题：

- Dify 保存凭据时会丢弃凭据级 model_properties（PUT 回显 200，但下次 GET 回来没有 context_size）——即"凭据级字段不持久化"；

- 于是改成在插件 llm.py 的 get_customizable_model_schema 里强制兜底 context_size=64000（见本文 4.x 代码位置，备份 llm.py.bak_qwenfix）；

- 但模型列表（GET models）时该函数不被调用：schema 在模型 add 时缓存，列表只回放缓存（值来自插件模板 gpt-5.6.yaml 的 1050000），并不按 llm.py 当前逻辑重算；

- 故要让列表真正显示 64000，还需用 align_qwen_ctx.py 的 PUT 再次触发 schema 重算。完整排查过程与当前状态见 9.6。

另外，把 max_tokens 误写进 model_properties 会触发 API 端 Pydantic 校验失败（ModelPropertyKey 不含 MAX_TOKENS），表现为 GET /models/model-types/llm 返回空列表、创建 Agent 时报错。正确的 max_tokens 应只作为 parameter_rule 存在。

五、已独立成专题六 / 七 / 八（本节仅留索引）

以下三节已从本专题独立出去，成为各自独立的完整专题（含详细代码与配置，请直接打开对应文件）：

• 专题七 · Agent 应用 shell provider 修复（DifyShellLayer） → Dify_专题七_Agent_shell_provider修复.md

（现象、sandbox / ssrf_proxy / plugin_daemon 三层确认、SANDBOX_URL 指向 compose 服务名、控制台启用步骤、验证）

• 专题八 · 插件 patch 的 from __future__ 顺序子坑 → Dify_专题八_插件patch_future顺序子坑.md

（SyntaxError 日志、根因、chat.py 正确代码位置与完整补丁、调用处、重启与 py_compile 校验、升级风险）

• 专题六 · weaviate 中继（IPv4→[::] 套接字投递 bug） → Dify_专题六_weaviate中继.md

（socat 中继 compose 配置、network_mode: host、ENTRYPOINT 注意、WEAVIATE_ENDPOINT 变更、验证）

八、落地清单（配置期问题自查）

• [ ] Dify 登录用 base64 密码 + X-CSRF-Token 头（脚本化时）；
• [ ] vLLM 镜像用 latest（不 pin 0.10.2），--tool-call-parser qwen3_xml；
• [ ] 模型用位置参数 /model，--reasoning-parser qwen3；
• [ ] H20 共享 GPU：gpu-memory-utilization 0.75、max-num-seqs 8、--shm-size=8g；
• [ ] vLLM 起来、端口通后，跑 align_qwen_ctx.py 把 context_size 对齐 64000；脚本里只写 context_size，不要把 max_tokens 写进 model_properties。
• [ ] 改插件 chat.py/llm.py 后，新增函数写在 from __future__ 之后，并 restart plugin_daemon（详见专题八）；
• [ ] Agent 应用按需启用 shell provider（DifyShellLayer）→ 见专题七《Dify_专题七_Agent_shell_provider修复.md》；
• [ ] 若 weaviate 有 IPv4→[::] 投递问题，见专题六《Dify_专题六_weaviate中继.md》。

关联文档：专题一（接入 Qwen3.6-27B）、专题二（Xinference 跑 bge-m3）、专题三（Agent 知识库选不到）、

专题四（问答报错排查）、专题五（大模型运行成功但 Dify 仍不可用）。

本专题原含的「Agent shell provider 修复」「from __future__ 顺序子坑」「weaviate 中继」三节已独立为

专题七《Dify_专题七_Agent_shell_provider修复.md》、专题八《Dify_专题八_插件patch_future顺序子坑.md》、

专题六《Dify_专题六_weaviate中继.md》。

九、实战记录（本次部署真实遇到的情况）

本专题每一节都对应本次真实踩过的坑。下面按统一维度把每处"改了什么 / 怎么重启 / 怎么看日志 / 怎么判断正常"补全。

9.1 vLLM 启动连踩三个

现象：bash vllm_qwen_run.sh 后容器 Exited，日志报 KeyError / ValueError。

改了什么（逐坑）：

• 误填 --tool-call-parser qwen3 → 改 qwen3_xml；
• 一度 pin vllm-openai:0.10.2 → model type qwen3_5 not recognized，改回 latest（实测 0.25.1）；
• --model /model 弃用告警 → 改位置参数 /model（写在镜像名之后）。

怎么重启：bash vllm_qwen_run.sh（脚本先 docker rm -f 旧容器再起）。

怎么看日志 / 判断正常： 完整脚本：scripts_bash_cursor/Dify_专题九_其它配置问题解决/专题九_内联_02.sh

运行/引用：bash /opt/workbuddy/scripts_bash_cursor/Dify_专题九_其它配置问题解决/专题九_内联_02.sh

#!/usr/bin/env bash
set -euo pipefail

docker logs --tail 30 vllm-qwen3.6-27b
curl -s http://116.62.10.183:8000/v1/models        # 列出 qwen3.6-27b
# 看到 "Application startup complete" 即 OK

9.2 共享 GPU 显存

现象：H20 上 --gpu-memory-utilization 0.80 会挤压 mxh_env/mxh_live 业务进程（OOM 风险）。

改了什么：压到 0.75（≈71.6GB）+ max-num-seqs 8 + --shm-size=8g。

怎么判断正常： 完整脚本：scripts_bash_cursor/Dify_专题九_其它配置问题解决/专题九_内联_03.sh

运行/引用：bash /opt/workbuddy/scripts_bash_cursor/Dify_专题九_其它配置问题解决/专题九_内联_03.sh

#!/usr/bin/env bash
set -euo pipefail

nvidia-smi   # 业务进程显存稳定、vLLM 占用在 ~71GB 区间，业务不受影响即达标

9.3 context_size 不匹配

现象：Dify 里 qwen 凭据 context_size 默认 1.05M，与 vLLM --max-model-len 65536 不符。

改了什么：跑 align_qwen_ctx.py 把 context_size 对齐成 64000（脚本只写 context_size；max_tokens 不在 model_properties 里设置，否则 API 端 schema 校验失败）。

python align_qwen_ctx.py

怎么看日志 / 判断正常：脚本末尾 VERIFY 打印 context_size=64000；也可在控制台模型供应商里看 qwen3.6-27b 的上下文上限已变 64000。

9.4 / 9.5 另两坑

• from __future__ 顺序子坑 → 详见专题八（含改了什么 / 重启 / 日志 / 判断）。
• weaviate IPv4→[::] 投递 → 详见专题六（含改了什么 / 重启 / 日志 / 判断）。

9.6 context_size 对齐的深层坑（凭据级不持久化 + schema 缓存）

现象：按 4.2 跑 align_qwen_ctx.py（PUT model_properties.context_size=64000）脚本显示 ALIGN_DONE、HTTP 200，但控制台模型列表里 qwen3.6-27b 的 context_size 仍是 1050000。

定位（逐层查）：

1. 先怀疑脚本没写进去 → 在 llm.py 加临时调试日志，打印 GET credentials 返回的 model_properties，发现 PUT 的 context_size=64000 没被保存：Dify 在保存凭据时会丢弃凭据级 model_properties（凭据级字段不持久化）。
2. 于是 patch llm.py 的 get_customizable_model_schema：在克隆通用 schema 后强制兜底 props["context_size"] = VLLM_MAX_CTX(64000)；不依赖凭据级字段。
3. 重启 plugin_daemon 后列表还是 1050000 → 再加调试日志，发现模型列表（GET models）时 get_customizable_model_schema 根本不被调用：schema 是在模型 add（首次保存）时缓存的，列表只回放缓存值（该值来自插件模板 gpt-5.6.yaml 的 1050000），并不按 llm.py 当前逻辑重算。

改了什么：

• llm.py：get_customizable_model_schema 里对克隆出的 props 强制 context_size=64000（备份 llm.py.bak_qwenfix）。
• 注意：不要把 max_tokens 写进 model_properties。API 端 ModelPropertyKey 枚举不含 MAX_TOKENS，加了会导致 Pydantic 校验失败、GET /models/model-types/llm 返回空列表、创建 Agent 报错；max_tokens 应只作为 parameter_rule 存在。
• 验证手段：在 llm.py 写临时日志到容器 /tmp/llm_ctx.log，docker exec docker-plugin_daemon-1 cat /tmp/llm_ctx.log 查看（宿主机 /tmp 看不到，日志在容器内）。

怎么重启：cd /dify/dify-main/docker && docker compose restart plugin_daemon（改 llm.py 必须重启插件守护进程才生效）。

怎么看日志 / 判断正常： 完整脚本：scripts_bash_cursor/Dify_专题九_其它配置问题解决/专题九_内联_04.sh

运行/引用：bash /opt/workbuddy/scripts_bash_cursor/Dify_专题九_其它配置问题解决/专题九_内联_04.sh

#!/usr/bin/env bash
set -euo pipefail

docker logs docker-plugin_daemon-1 2>&1 | tail -20        # 无 SyntaxError / Traceback
docker exec docker-plugin_daemon-1 cat /tmp/llm_ctx.log   # 看 schema 计算时的 ctx 值
python align_qwen_ctx.py                                   # 末尾 VERIFY 打印 context_size
# 控制台：模型供应商 → qwen3.6-27b → 上下文上限应显示 64000

当前状态：llm.py 强制 64000 已打上、plugin_daemon 已重启；用 align_qwen_ctx.py 的 PUT 触发 schema 重算后，GET /models/model-types/llm 已正确返回 qwen3.6-27b 且 model_properties.context_size=64000。但注意：若把 max_tokens 误写进 model_properties，API 端会 Pydantic 校验失败，列表仍为空。

9.7 控制台 API 登录 403：缺 base64 密码 / X-CSRF-Token

现象：第一次用脚本（dify_api.py）调 POST /console/api/login 想拿 cookie 做后续管理操作，返回 403，拿不到 access / refresh / csrf_token，后续所有 /console/api、/workspaces/current/... 请求也被拒。

定位：Dify 控制台登录不是简单表单——①密码必须 base64 编码后提交；②登录成功后 csrf_token 在 cookie 里，后续请求必须带请求头 X-CSRF-Token: <csrf_token>。两者缺一则 403。

改了什么：在 dify_api.py 的 login() 里先 base64.b64encode(password)，再把 csrf_token cookie 取出来写进 session 的 X-CSRF-Token 头（完整代码见本文 1.2）。

怎么判断正常： 完整脚本：scripts_bash_cursor/Dify_专题九_其它配置问题解决/专题九_内联_05.sh

运行/引用：bash /opt/workbuddy/scripts_bash_cursor/Dify_专题九_其它配置问题解决/专题九_内联_05.sh

#!/usr/bin/env bash
set -euo pipefail

python - <<'PY'
from dify_api import Dify
d = Dify("38205036@qq.com", "Difyai123456")
ok, *_ = d.login()
print("LOGIN ok =", ok)   # 应 True；之后 d.get(...)/d.put_json(...) 均能 200
PY

一句话对照：专题九前面是"各问题的方法论+代码"，本节是"这些坑本次一个不落都真实发生了"的清单。9.1–9.3 是启动/显存/表面对齐；9.4–9.5 指专题七/八/六；9.6 补了 context_size 对齐的真实深坑（不持久化+schema 缓存），9.7 补了控制台登录 403 的真实成因——每处都按"现象 / 改了什么 / 怎么重启 / 怎么看日志 / 怎么判断正常"写全。

本专题 Python 程序一览

| 文件 | 用途 | |---|---|| 专题九_01_验证控制台登录.py | 专题九 · 步骤 1：验证控制台登录（base64 密码 + X-CSRF-Token）。 | | 专题九_02_对齐context_size_修改后.py | 专题九 · 步骤 2 · 修改后：对齐 qwen3.6-27b 凭据 context_size=64000（不写 max_tokens）。 |

专题九_01_验证控制台登录.py

运行：/usr/bin/python3 /opt/workbuddy/scripts_cursor/Dify_专题九_其它配置问题解决/专题九_01_验证控制台登录.py

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
"""专题九 · 步骤 1：验证控制台登录（base64 密码 + X-CSRF-Token）。"""
from __future__ import annotations

import sys

import _bootstrap  # noqa: F401
import _config as C
from dify_api import Dify, pp


def main() -> int:
    d = Dify(C.DIFY_EMAIL, C.DIFY_PASSWORD)
    try:
        ok, _, csrf = d.login()
        print("LOGIN ok =", ok, "csrf =", bool(csrf))
        if not ok:
            return 1
        r = d.get("/datasets")
        pp("datasets（登录后会话可用）", r)
        return 0 if r.get("code") == "200" else 1
    finally:
        d.close()


if __name__ == "__main__":
    sys.exit(main())

专题九_02_对齐context_size_修改后.py

运行：/usr/bin/python3 /opt/workbuddy/scripts_cursor/Dify_专题九_其它配置问题解决/专题九_02_对齐context_size_修改后.py

完整补丁：patches_cursor/Dify_专题九_其它配置问题解决/专题九_内联_01.py

运行/引用：见 patches_cursor/Dify_专题九_其它配置问题解决/专题九_内联_01.py

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
"""专题九 · 步骤 2 · 修改后：对齐 qwen3.6-27b 凭据 context_size=64000（不写 max_tokens）。"""
from __future__ import annotations

import sys
import time

import _bootstrap  # noqa: F401
import _config as C
from dify_api import Dify


def main() -> int:
    d = Dify(C.DIFY_EMAIL, C.DIFY_PASSWORD)
    try:
        ok, _, _ = d.login()
        print("LOGIN ok=%s" % ok)
        if not ok:
            return 1
        r = d.get(
            "/workspaces/current/model-providers/%s/models/credentials?model_type=llm&model=%s"
            % (C.OPENAI_PROVIDER, C.LLM_MODEL)
        )
        js = r.get("json") or {}
        print("GET cred HTTP", r.get("code"))
        cur_cred = js.get("credentials") or {}
        cid = js.get("current_credential_id")
        print("current_credential_id:", cid)
        print("existing model_properties:", cur_cred.get("model_properties"))
        cred = dict(cur_cred)
        cred["model_properties"] = {"context_size": C.VLLM_MAX_CTX}
        name = js.get("current_credential_name") or "Qwen3.6-27b"
        r2 = d.req(
            "PUT",
            "/workspaces/current/model-providers/%s/models/credentials" % C.OPENAI_PROVIDER,
            body={
                "model": C.LLM_MODEL,
                "model_type": "llm",
                "credential_id": cid,
                "credentials": cred,
                "name": name,
            },
        )
        print("PUT cred HTTP", r2.get("code"), (r2.get("text") or "")[:200])
        time.sleep(2)
        r3 = d.get("/workspaces/current/models/model-types/llm")
        js3 = r3.get("json") or {}
        for p in js3.get("data", []):
            if p.get("provider") == C.OPENAI_PROVIDER:
                for m in p.get("models", []):
                    if m.get("model") == C.LLM_MODEL:
                        mp = m.get("model_properties") or {}
                        print(
                            "VERIFY model=%s status=%s context_size=%s"
                            % (m.get("model"), m.get("status"), mp.get("context_size"))
                        )
        print("ALIGN_DONE")
        return 0 if r2.get("code") == "200" else 1
    finally:
        d.close()


if __name__ == "__main__":
    sys.exit(main())