走一遍客服、工单、监控和自愈

2026-10-13,在现有 Dify 1.17 上把智能体和工作流都跑过。对话模型仍是 qwen3.6-27b。没有装第二个模型,也没有重启 vLLM。结束时 /health 仍是 200。

智能体由模型决定要不要查知识库、要不要调工具。工作流按画好的节点往下走:分类之后只进一个出口,监控按固定顺序读三条指标,客服先检索再回答。页面在 http://10.0.1.47:8088,账号 admin@example.com,密码 Dify-rag-2026。

登录口令按现网写在这里。Vault 根令牌、Langfuse 的加密项、Redis 口令、MinIO 口令、kubeadm 加入令牌,以及 Argo CD 的个人访问令牌,不写进本文。本文只供这台学习机对照,不要发到公网。

显存大约 86GB 是 vLLM 按 0.70 预先划出的缓存。结束时约 86323 MiB
智能体客服、工单、监控、只读自愈,加上原来的合同和巡检
工作流分流两条出口、监控三段 HTTP、客服先检索再回答

请求怎么走

  1. 1
    浏览器打开 Difyhttp://10.0.1.47:8088 。智能体和工作流都在这个页面里。
  2. 2
    需要生成文字时,请求到 New-API,再到 vLLM模型名 qwen3.6-27b。向量和重排仍走 Xinference 的 bge-m3、bge-reranker-v2-m3。
  3. 3
    监控数字来自 Prometheushttp://10.0.1.47:9090 。温度、显存、排队各查一次。
  4. 4
    自愈只给结论可以读 /health 和排队人数。没有重启、删除或改副本的工具。
nvidia-smi 里大约 86GB 是启动参数 gpu-memory-utilization 0.70 划给 KV 缓存的显存。短对话使用这块已经划出的缓存。这次结束时占用约 86323 MiB,/health 为 200。

六条智能体

脚本 scripts/10-试用主流场景.py 按名字复用应用。同名的客服说明知识库已索引完成,再跑不会另建一份。合同知识库不要重新做初始化,否则会再索引一遍。

应用它做了什么跑出来的结果
工单分流不调工具。分成咨询、投诉、故障、账号,并标高或低投诉 / 高 发票拖了三天,要求今天答复
监控检查调用 queryPrometheus,查温度、显存、排队真实指标 37°C,显存 86092 MB,排队 0
故障自愈读 /health 和排队。结论只有无需处理、观察、人工处理无需处理 空的 200 也算健康,排队 0
智能客服只根据知识库「平台客服说明」回答GitLab 地址 http://10.0.1.47:8929
合同问答原来的「阿里云合同条款」,混合检索加重排甲方是抖爸爸(杭州)电子商务服务有限公司
运维巡检调用原来的 getServerStatus演示数据 CPU 45%,内存 62%,GPU 利用率 78%,显存 18.2/24 GB

监控检查读的是 Prometheus 里这张 H20 的数。运维巡检读的是宿主机 8777 上的演示接口,那组百分比和监控检查不是同一路数据。

故障自愈第一次写成了「人工处理」。vLLM 的 /health 在正常时返回 200,响应体是空的,模型把空响应当成了故障。提示词改成「没有报错、空响应也算健康」并重新发布之后,结论是无需处理。排队大于 10 时,提示词要求写「观察」,并说明 KEDA 会把 Dify worker 扩到最多 3 个。这次排队是 0,没有走到那条。

三条工作流

脚本 scripts/11-试用工作流.py。工作流的模式是 workflow。节点顺序写死,模型只在被连上的节点里被调用。

工作流节点跑出来的结果
工单分流工作流分类 → 投诉出口或咨询出口 → 结束发票那句进投诉:高,今日内答复。问地址进咨询:普通,按平台说明答复
监控检查工作流三条 HTTP,再用代码抽出数字。这一条不调用对话模型温度 53°C,显存 86322 MiB,排队 0。温度比空闲时高,是刚才的生成把卡带起来了
客服检索工作流检索「平台客服说明」→ 模型按检索内容回答GitLab 的网页地址是 http://10.0.1.47:8929

分类节点第一次没有走出分支。模型把字数花在思考上,正文是空的,解析不到类别 JSON。回答预算改成 2048 之后,两个出口都走到了。客服检索第一次回答「不知道」,是因为提示词里没有放上检索结果。系统提示加入 {{#context#}} 之后,答出了地址。

沙箱写配置时的那次失败

在页面里让监控智能体整理检查结果时,queryPrometheus 能返回数据。红框里的失败是另一条路:本地沙箱要把笔记和配置写到 agent_backend:5050。沙箱的 HTTP_PROXY 指向 agent_ssrf_proxy:3128,NO_PROXY 里原来只有本机。短名字交给 Squid 之后解析失败,访问日志是 503。

agent-backend 这个 Service 一直是 1/1,端口 5050。Pod 自己的 DNS 能把带下划线的名字改写到 agent-backend。已经把沙箱的 NO_PROXY 补上 agent_backend、agent-backend、api、local_sandbox 和 .cluster.local,并只重启了 local-sandbox。不带登录信息再访问同一地址,后端返回 401,说明请求已经到达服务。vLLM 没有重启。

写文档时核对到的结果

检查结果
Difyhttp://10.0.1.47:8088 ,admin@example.com / Dify-rag-2026
对话模型qwen3.6-27b,经 New-API 到 vLLM
显存约 86323 MiB。/health 200
智能体六条都有回答。自愈结论是无需处理
工作流三条都已发布。分流两个出口、监控取数、客服检索都走到结束
自愈权限只读。没有重启、删除 Pod 或修改副本的工具
详细记录在同目录《用智能体和工作流把客服、工单、监控和自愈走一遍.md》。合同知识库的安装在同级目录 dify 的《用 Dify 做合同知识库:Qwen 对话、bge 重排和 Langfuse 工具追踪.md》。复习时看这两份即可,不必为了对照再跑一遍脚本。