用智能体和工作流把客服、工单、监控和自愈走一遍本文记录 2026-10-13 在现有 Dify 1.17 上跑过的场景。智能体六条工单分流、监控检查、故障自愈、智能客服加上原来的合同问答和运维巡检。工作流三条工单分流、监控检查、客服检索。本章目录是场景。机器是prod102地址10.0.1.47。合同知识库的安装写在同级目录dify的《用 Dify 做合同知识库Qwen 对话、bge 重排和 Langfuse 工具追踪.md》。流程对照页是同目录的《走一遍客服、工单、监控和自愈.html》。页面是http://10.0.1.47:8088登录adminexample.com/Dify-rag-2026。对话模型是qwen3.6-27b请求从 Dify 到 New-API再到 vLLM。向量是bge-m3重排是bge-reranker-v2-m3由 Xinference 提供。scripts/10-试用主流场景.py和scripts/11-试用工作流.py已经在现网执行过。同名应用会复用或覆盖草稿。复习时看本文即可。不要重新初始化「阿里云合同条款」那会再索引一份。不要为了对照文档重启 vLLM 或 New-API。登录口令沿用现网值。Vault 根令牌、Langfuse 的NEXTAUTH_SECRET、SALT、ENCRYPTION_KEY、Redis 口令、MinIO 口令、kubeadm 加入令牌以及 Argo CD 仓库 Secret 里的个人访问令牌不写进本文。不要把本文发到公网。一、两条用法一条请求路径浏览器打开 Dify。需要生成文字时路径仍是Dify → New-API → vLLM qwen3.6-27b → GPU知识库检索走 Xinference。监控数字走 Prometheushttp://10.0.1.47:9090。智能体由模型决定下一步要不要查知识库要不要调工具要不要再查一次。工作流的模式是workflow。节点和连线写在图里分类之后只进入一个出口监控按固定顺序发三次 HTTP。监控那条工作流不调用对话模型。nvidia-smi里大约 86GB 是 vLLM 启动参数gpu-memory-utilization 0.70预先划出的 KV 缓存。短对话使用这块已经划出的显存。全部跑完时占用约 86323 MiB/health为 200。二、智能体脚本scripts/10-试用主流场景.py。新注册的工具工具地址作用queryPrometheushttp://10.0.1.47:9090/api/v1/query只读 PromQLOpenAPI 在config/prometheus-openapi.yamlcheckVllmHealthhttp://10.0.1.47:8000/health只读健康检查OpenAPI 在config/vllm-health-openapi.yaml客服说明知识库的名字是「平台客服说明」编号b2dd0af3-d73c-4983-9348-8b25ca502ef2。里面是平台入口Dify、GitLab、Argo CD、模型名和导航页。索引状态是 completed。口令没有写进这份说明客服被要求不要编造口令。1. 工单分流不挂工具。提示词要求分成咨询、投诉、故障、账号之一并给出紧急程度高或低输出三行类别、紧急程度、摘要。来话是合同发票三天未收到、语气急、要求今天答复。结果类别投诉 紧急程度高 摘要客户称合同发票已等待三天仍未收到语气急切并要求今日内答复应用编号3155e433-60f0-496b-bd48-d055a6cca385。2. 监控检查必须调用queryPrometheus依次查询DCGM_FI_DEV_GPU_TEMP DCGM_FI_DEV_FB_USED sum(vllm:num_requests_waiting{model_nameqwen3.6-27b})结果温度 37°C显存 86092 MB排队 0。这是 Prometheus 里这张 H20 的数。应用编号a747a108-8520-4358-9900-ed792d20ca90。3. 故障自愈只读。必须调用checkVllmHealth和queryPrometheus。结论只允许三个词无需处理、观察、人工处理。排队大于 10 时写观察并说明 KEDA 会把 Dify worker 扩到最多 3 个。提示词禁止输出重启、删除 Pod、kubectl或改镜像的命令。没有给它这些工具。vLLM 的/health在正常时返回 200响应体是空的。第一次模型把空响应当成故障写成了「人工处理」。提示词改为「没有报错、空响应也算健康」重新发布后再判断结论是无需处理排队仍是 0。应用编号31154f0a-0fa3-4a85-9e00-809b29bc2c11。4. 智能客服只根据「平台客服说明」回答。问题是 GitLab 的网页地址。回答是http://10.0.1.47:8929。应用编号8db6337b-efc6-4554-a51a-2950de4b66c0。5. 合同问答这是原来的应用知识库「阿里云合同条款」编号71042108-5f9a-4856-a0db-4359e8e7fa98高质量索引混合检索重排模型bge-reranker-v2-m3。问题是这份合同的客户是谁。回答是甲方抖爸爸(杭州)电子商务服务有限公司。应用编号d2e3f57b-3901-45de-bd9a-d51feb849f6e。6. 运维巡检调用原来的getServerStatus地址http://172.17.0.1:8777。问的是gpu-server-01。返回的是演示接口里的固定数CPU 45%内存 62%GPU 利用率 78%显存 18.2/24 GB。这组数和监控检查里的温度、显存不是同一路数据。应用编号e4d614f6-de22-4f4c-b58e-caeb0504b121。接口程序是server-status/app.py不要为了这次场景重启它。三、工作流脚本scripts/11-试用工作流.py。三条都已发布。模型节点的max_tokens是 2048温度 0.2。分类和客服检索会调用qwen3.6-27b。监控这条只有 HTTP 和代码节点。1. 工单分流工作流编号4e30ef60-44ee-40a6-928a-a1f4bd76da7d。开始工单文本 → 问题分类投诉 / 咨询 → 投诉出口类别、紧急程度高、今日内答复 → 咨询出口类别、紧急程度普通、按平台说明答复「合同发票已经三天没收到请今天给一个答复」进入投诉出口。「GitLab 的网页地址在哪里」进入咨询出口。分类节点第一次失败错误是could not find json block in the output。模型把当时 256 的回答预算花在思考上正文是空的后面的出口没有类别可以接。预算改成 2048 之后两个出口都走到结束。2. 监控检查工作流编号f0b6357e-e9fe-43c4-ba16-a9b23cfdf78f。开始 → HTTP 查 DCGM_FI_DEV_GPU_TEMP → HTTP 查 DCGM_FI_DEV_FB_USED → HTTP 查 sum(vllm:num_requests_waiting{model_nameqwen3.6-27b}) → 代码节点抽出每条结果里的数值 → 结束三次请求都打到http://10.0.1.47:9090/api/v1/query。SSRF 允许10.0.0.0/8这个地址可以通。跑完的输出温度 53 C 显存 86322 MiB 排队 053°C 高于前面智能体监控时的 37°C是中间几次生成把卡带起来了。显存仍在预先划出的那一块附近。排队是 0KEDA 不会因此去加 worker。3. 客服检索工作流编号8b6dbeff-0d83-434a-b16e-b0cd5e460cac。开始问题 → 知识检索「平台客服说明」top_k 3重排 bge-reranker-v2-m3 → 对话模型系统提示里放 {{#context#}} → 结束问题是 GitLab 的网页地址是什么。检索节点已经拿到含有http://10.0.1.47:8929的片段。第一次回答是「不知道」因为提示词只写了「根据检索内容回答」图里没有把检索结果放进提示。系统提示加上{{#context#}}并重新发布之后回答是GitLab 的网页地址是http://10.0.1.47:8929。四、沙箱写配置时碰到的 DNS在页面里让监控智能体整理结果时queryPrometheus能返回三条数据。同一页红框写的是agent_backend:5050DNS 解析失败笔记和配置写不进去。agent-backend的 Deployment 和 Service 都在ClusterIP10.107.0.77端口 5050Pod 1/1。CoreDNS 有一条改写把agent_backend.dify.svc.cluster.local指到agent-backend.dify.svc.cluster.local。从 Pod 里解析这个短名字是通的。写配置的进程跑在local-sandbox。它的HTTP_PROXY是http://agent_ssrf_proxy:3128NO_PROXY原来只有localhost,127.0.0.1。于是http://agent_backend:5050被交给 Squid。Squid 不做 Kubernetes 的搜索域补全短名字在访问日志里是TCP_MISS_ABORTED/503HIER_NONE。带完整后缀的agent-backend.dify.svc.cluster.local可以从代理直连到 Service。现网已经把local-sandbox的NO_PROXY补成localhost,127.0.0.1,agent_backend,agent-backend,agent_backend.dify.svc.cluster.local,agent-backend.dify.svc.cluster.local,local_sandbox,local-sandbox,api,api.dify.svc.cluster.local,agent_ssrf_proxy,agent-ssrf-proxy,.cluster.local这个值在 Vault 路径apps/dify/local-sandbox-env由 ExternalSecretlocal-sandbox-env同步到同名 Secret。改完后只删掉了local-sandbox的 Pod让它读到新环境变量。不带令牌再访问http://agent_backend:5050/agent-stub/config/manifest后端返回 401。401 说明请求已经到达agent-backend空请求没有登录信息。vLLM 的/health在这次重启之后仍是 200。代码执行用的另一个沙箱sandbox走的是ssrf_proxy:3128NO_PROXY仍是空的。这次三条工作流里的代码节点已经成功抽出监控数字没有改那一份环境变量。五、文件文件作用scripts/10-试用主流场景.py注册两个只读工具准备客服说明发布四条新智能体并各问一次scripts/11-试用工作流.py发布三条工作流并各跑一次config/prometheus-openapi.yamlPrometheus 即时查询config/vllm-health-openapi.yamlvLLM/health走一遍客服、工单、监控和自愈.html本阶段的流程对照页原来的合同脚本和巡检脚本仍在dify/scripts分别是05-合同知识库.py和08-注册服务器状态工具.py。这次场景没有重跑它们。