1. 为什么企业现在必须自己搭一个Agent评测平台——而不是继续用“试用版”或“SaaS界面点几下”最近三个月我帮六家不同行业的客户做过AI落地可行性评估其中五家在第二轮沟通时都抛出同一个问题“你们说的Agent能自动跑测试用例、能调API、能写报告那它到底靠不靠谱能不能先让我们自己测一测”不是问效果多好而是问——它在我们自己的数据、我们自己的流程、我们自己的错误容忍度下到底会犯多少错这恰恰戳中了当前AI应用落地最隐蔽的断层市面上90%的“低代码AI平台”宣传页上写着“开箱即用”但没人告诉你“开箱”之后的第一步其实是——你得先建一套能真实反映业务逻辑的评测体系。不是测它能不能回答“今天天气怎么样”而是测它在处理37个字段的ERP工单时会不会把“紧急等级高”误判成“普通”不是看它生成的SQL有没有语法错误而是看它在关联8张表、过滤条件含中文模糊匹配时返回结果的召回率是否低于92.3%。Dify之所以被反复搜索“本地部署”“Windows教程”“Ubuntu图文”根本原因就在这里它不是又一个让你上传PDF点几下就完事的玩具而是一个可拆解、可注入、可埋点、可回溯的Agent运行底座。它的“低代码”体现在工作流编排和知识库配置上但它的“可评测性”恰恰建立在你能完全掌控其执行环境、日志路径、模型输入输出管道的基础上。比如当你在Dify里配置一个“合同条款比对Agent”评测重点从来不是它生成的文字多漂亮而是它是否漏掉了“不可抗力条款中的地理范围限制”这个关键子项——这种细粒度断言必须依赖你本地部署后接入的自定义评测脚本而不是SaaS后台那个“成功率98.7%”的黑盒统计。我见过最典型的反面案例是一家做医疗器械合规的客户他们前期用某SaaS平台快速上线了一个FAQ问答Bot上线两周后法务部发现Bot在回答“CE认证有效期是否覆盖新修订标准”时有17%的概率把“不覆盖”答成“覆盖”。问题不是模型不行而是评测环节缺失——SaaS平台只提供“用户点击‘有用’的比例”而没提供“在237条含‘不覆盖’关键词的原始法规文本中Bot实际命中了多少条”的底层验证能力。等他们想补评测时才发现日志不可导出、响应无法打时间戳、历史请求无法重放——所有评测动作都卡在了平台边界之外。所以这篇教程的起点不是“怎么装Dify”而是“为什么必须本地装、必须自己配评测链路”。标题里写的“10分钟搭建”指的是从拉镜像到看到第一个Agent运行成功的操作耗时但真正让这个平台产生业务价值的是你在第11分钟开始写的第一个评测用例第23分钟加上的第一条断言规则第47分钟配置的第一次失败告警。后面所有章节都是围绕这个核心展开如何让Dify不只是一个“能跑Agent”的容器而是一个“能证明Agent值得信赖”的实验室。2. Dify本地部署的本质不是安装软件而是构建可审计的AI执行沙盒很多人把Dify部署理解成“下载安装包→双击下一步→打开浏览器”这是最大的认知偏差。Dify的本地化部署本质上是在你的物理机器上划出一块可完全观测、可精确控制、可重复验证的AI执行区域。它不像传统软件安装而是像给AI Agent建一个带显微镜和计时器的实验室——你不仅要让它动起来还要看清它每一步呼吸的节奏、每一次决策的依据、每一个错误发生的精确坐标。这就决定了部署方案的选择逻辑根本不是“哪个最简单”而是“哪个最透明”。目前主流有三类路径纯Docker Compose一键式官方推荐适合快速验证但所有服务Web、Worker、Redis、PostgreSQL挤在一个docker-compose.yml里日志混杂、资源争抢、故障隔离差。我实测过在MacBook M2上跑DeepSeek-Coder-33BDify组合时Worker进程偶尔因内存超限被OOM Killer干掉但日志里只显示“Connection refused”根本看不出是PostgreSQL还是Redis先扛不住。Kubernetes集群部署企业级选择但对中小团队属于“杀鸡用牛刀”。光是配置Ingress路由规则、PersistentVolume权限、ServiceAccount RBAC策略就能吃掉一个资深运维两天时间。更关键的是K8s的抽象层会掩盖很多底层细节——比如你想抓取Agent调用外部API时的原始HTTP请求头K8s的Service Mesh如Istio反而会增加一层代理跳转让trace链路变长且失真。Docker分服务手动部署本文采用把Web服务、Worker服务、数据库、缓存、向量库全部拆成独立容器用--network dify-net统一桥接每个容器挂载独立日志卷、设置明确内存/CPU限制、暴露调试端口。这不是为了炫技而是为了满足三个硬性评测需求可复现性当评测发现某个Agent在下午3:15:22返回错误结果你能立刻用docker logs -t --since 2024-06-15T15:15:20 worker精准定位那一秒的完整上下文可干预性评测过程中需要临时修改Agent的提示词温度值temperature你直接进Web容器执行echo TEMPERATURE0.3 /app/.env再supervisorctl restart web30秒生效无需重启整个栈可归因性当评测报告指出“知识库检索准确率下降12%”你能用docker stats postgresql确认是数据库连接池耗尽还是用docker exec -it qdrant qdrant info查出向量库索引碎片率过高——而不是在SaaS后台看到一句“系统繁忙请稍后再试”。提示不要迷信“一键部署脚本”。我测试过三个主流GitHub仓库的Dify一键脚本其中两个在Windows WSL2环境下会因/dev/shm共享内存大小默认为64MBQdrant向量库最低要求128MB导致启动失败报错信息却是“qdrant container exited with code 1”完全不提内存问题。真正的可控始于你亲手敲下的每一行docker run命令。下面以Windows 10 WSL2 Ubuntu 22.04环境为例展示如何构建这个沙盒。注意所有路径、端口、环境变量均按生产级评测需求设计而非演示用途。2.1 环境预检绕过90%部署失败的隐形地雷在敲任何docker命令前必须完成三项检查否则后续所有操作都在浪费时间第一项WSL2内核版本与内存分配# 检查内核版本必须≥5.10.102.1 uname -r # 检查当前内存分配Dify WorkerQdrantPostgreSQL最低需4GB free -h # 如果内存不足编辑 C:\Users\用户名\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\wsl.conf # 添加以下内容并重启WSL # [wsl2] # memory6GB # 直接限制WSL2最大内存避免宿主机卡死 # swap2GB # localhostForwardingtrue第二项Docker Desktop网络模式Windows Docker Desktop默认使用“WSL2 backend”但必须关闭“Use the WSL2 based engine”选项旁的“Enable integration with my default WSL distro”——否则Docker会劫持WSL2的DNS解析导致Dify Worker无法通过postgresql://db:5432正确连接数据库它会去查宿主机的127.0.0.1而非WSL2内部网络。正确做法是在Docker Desktop Settings → General → 取消勾选“Use the WSL2 based engine”改用“Windows containers”模式不那是另一套体系。实际应保持WSL2引擎启用但在Settings → Resources → WSL Integration → 只启用你当前使用的Ubuntu发行版并确保“Enable integration with my default WSL distro”处于关闭状态。第三项时区与文件系统兼容性WSL2的ext4文件系统对Linux权限支持完美但Windows宿主机创建的文件在WSL2中可能丢失x执行权限。Dify的某些Python脚本如scripts/init_db.py需要可执行权限。解决方案不是每次chmod x而是在WSL2中创建专用目录# 在WSL2中执行不要在Windows资源管理器里新建文件夹 mkdir -p ~/dify-deploy/{web,worker,db,cache,vector} # 所有Dify相关文件从此目录下操作规避Windows文件系统干扰这三项检查看似琐碎但覆盖了我协助客户部署时83%的“卡在第一步”问题。真正的效率永远来自对环境边界的清醒认知而不是盲目追求“一键”。2.2 核心服务分拆部署每个容器都是评测链路上的一个传感器现在开始逐个启动服务。关键原则每个容器只做一件事且这件事必须可监控、可日志、可限流。PostgreSQL数据库持久化层# 创建专用网络所有Dify服务将加入此网络 docker network create dify-net # 启动PostgreSQL关键参数说明 # -e POSTGRES_PASSWORDdify123生产环境必须改此处仅为演示 # -v ~/dify-deploy/db:/var/lib/postgresql/data数据卷映射确保重启不丢数据 # --memory1g --cpus1.5硬性限制资源防止DB吃光内存影响Worker # --health-cmdpg_isready -U postgres -d dify健康检查Dify Worker启动前会等待DB就绪 docker run -d \ --name dify-db \ --network dify-net \ -e POSTGRES_PASSWORDdify123 \ -e POSTGRES_DBdify \ -v ~/dify-deploy/db:/var/lib/postgresql/data \ -p 5432:5432 \ --memory1g --cpus1.5 \ --health-cmdpg_isready -U postgres -d dify \ --restartunless-stopped \ -d postgres:15-alpine # 验证DB是否就绪等待Health Status变为healthy docker inspect --format{{.State.Health.Status}} dify-dbRedis缓存会话与任务队列# Redis不设密码Dify默认配置但必须限制内存防止OOM # --maxmemory 512mb --maxmemory-policy allkeys-lru强制内存上限与淘汰策略 docker run -d \ --name dify-redis \ --network dify-net \ --memory512m \ --cpus0.5 \ -v ~/dify-deploy/cache:/data \ --restartunless-stopped \ redis:7-alpine \ redis-server --maxmemory 512mb --maxmemory-policy allkeys-lruQdrant向量数据库知识库底层# Qdrant对共享内存/dev/shm要求严格必须显式挂载且足够大 # --shm-size2g这是最关键的参数缺它必报错 # -p 6333:6333暴露HTTP端口供Dify Web调用 docker run -d \ --name dify-qdrant \ --network dify-net \ --shm-size2g \ --memory2g --cpus2 \ -v ~/dify-deploy/vector:/qdrant/storage \ -p 6333:6333 \ --restartunless-stopped \ qdrant/qdrant:v1.7.4Dify Web服务用户界面与API网关# 此处使用Dify官方镜像但关键在于环境变量注入 # SQLALCHEMY_DATABASE_URI指向dify-db容器名走内部DNS # REDIS_URL指向dify-redis容器名 # QDRANT_URL指向dify-qdrant容器名 # CONSOLE_WEB_URL必须设为http://localhost:3000前端访问地址 # API_URL必须设为http://localhost:5001前端调用后端API的地址 docker run -d \ --name dify-web \ --network dify-net \ -p 3000:3000 -p 5001:5001 \ --memory1.5g --cpus1.5 \ -e SQLALCHEMY_DATABASE_URIpostgresql://postgres:dify123dify-db:5432/dify \ -e REDIS_URLredis://dify-redis:6379/0 \ -e QDRANT_URLhttp://dify-qdrant:6333 \ -e CONSOLE_WEB_URLhttp://localhost:3000 \ -e API_URLhttp://localhost:5001 \ -e SECRET_KEYyour-secret-key-change-in-production \ -e SESSION_COOKIE_SAMESITELax \ -v ~/dify-deploy/web:/app/storage \ --restartunless-stopped \ difyai/dify:latestDify Worker服务Agent执行引擎# Worker是Agent实际运行的地方也是评测的核心靶场 # 必须挂载/storage目录存放临时文件、日志、/models存放本地模型 # WORKER_LOG_LEVELDEBUG评测阶段必须开DEBUG否则看不到Agent每一步的token消耗、API调用详情 docker run -d \ --name dify-worker \ --network dify-net \ --memory3g --cpus2 \ -e SQLALCHEMY_DATABASE_URIpostgresql://postgres:dify123dify-db:5432/dify \ -e REDIS_URLredis://dify-redis:6379/0 \ -e QDRANT_URLhttp://dify-qdrant:6333 \ -e WORKER_LOG_LEVELDEBUG \ -v ~/dify-deploy/worker:/app/storage \ -v ~/dify-deploy/models:/app/models \ --restartunless-stopped \ difyai/dify:latest \ celery -A app.worker.celery_worker.celery_worker worker --loglevelinfo -Q high_priority,default,low_priority -c 2注意所有docker run命令中的--restartunless-stopped至关重要。它确保宿主机重启后所有Dify服务自动恢复评测任务不会因意外断电中断。而-c 2参数限制Celery Worker并发数为2这是为了在评测时精确控制负载——如果你要测“高并发下Agent响应延迟”就改成-c 10要测“单Agent长时间运行内存泄漏”就保持-c 1。可控性就藏在这些数字里。2.3 部署验证不是看“能否访问”而是看“能否被评测”启动所有容器后别急着打开浏览器。真正的验证是用命令行确认每个环节都已准备好接收评测指令第一步确认网络连通性# 进入Web容器测试能否ping通所有依赖服务 docker exec -it dify-web sh -c ping -c 3 dify-db ping -c 3 dify-redis ping -c 3 dify-qdrant # 输出应为3 packets transmitted, 3 received证明内部DNS解析正常第二步验证数据库初始化# 进入DB容器检查Dify所需的表是否存在 docker exec -it dify-db psql -U postgres -d dify -c \dt # 应看到至少20张表包括accounts_account、datasets_dataset、apps_app等 # 若无表说明Dify Web首次启动时迁移失败需查看dify-web日志 docker logs --tail 50 dify-web | grep -i alembic第三步检查Worker任务队列健康度# 查看Worker是否成功连接Redis并监听队列 docker logs --tail 20 dify-worker | grep -i connected to redis # 应看到类似Connected to redis://dify-redis:6379/0的日志 # 再检查队列监听状态 docker logs --tail 20 dify-worker | grep -i ready to accept tasks第四步触发一次最小化Agent执行评测前的终极校验# 使用curl模拟一次最简Agent调用无需前端界面 curl -X POST http://localhost:5001/v1/chat-messages \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d { inputs: {}, query: 你好, response_mode: blocking, user: test-user } # 成功响应应包含answer字段且status200 # 此时立刻查看Worker日志 docker logs --tail 10 dify-worker | grep -E (llm|invoke|token) # 应看到类似LLM invoke start, token usage: 15 tokens的DEBUG日志只有当这四步全部通过你才拥有了一个可信任的评测沙盒。此时打开http://localhost:3000看到的不再是一个“能用的界面”而是一个随时准备接受你定制化压力测试、断言验证、性能剖析的精密仪器。接下来的所有操作都将围绕如何让这个仪器产出可信的评测报告展开。3. Agent评测框架设计从“它能回答”到“它必须答对”的质变部署完成只是拿到了一把钥匙而评测框架才是打开企业级AI信任之门的锁芯。很多团队卡在“不知道测什么”本质是混淆了“功能演示”和“业务验证”的界限。一个合格的Agent评测框架必须回答三个层次的问题基础层Can it run?Agent能否在给定输入下完成执行流程不崩溃、不超时、不返回空语义层Did it understand?Agent对输入意图的理解是否准确是否遗漏关键约束条件业务层Is it right for us?Agent的输出是否符合我司特定的合规要求、数据格式规范、风险容忍阈值Dify本身不提供评测模块但它的架构天然支持这三层验证——只要你把评测逻辑嵌入到它的执行管道中。下面是我为制造业客户设计的“供应商资质审核Agent”评测框架它已稳定运行8个月覆盖237个真实业务场景。3.1 构建可插拔的评测中间件在Dify Worker中注入断言钩子Dify Worker执行Agent时核心流程是接收消息 → 解析提示词 → 调用LLM → 解析响应 → 返回结果。评测的关键是在LLM响应解析后、结果返回前这个黄金窗口插入你的业务断言逻辑。Dify的源码结构清晰app/agents/manager.py中的AgentManager.run()方法是入口。我们不修改Dify源码避免升级冲突而是利用Python的importlib机制在Worker启动时动态注入评测模块步骤1创建评测插件目录# 在WSL2中创建插件目录与Dify Worker同级 mkdir -p ~/dify-deploy/plugins/agent_evaluator cd ~/dify-deploy/plugins/agent_evaluator # 创建评测主模块 cat __init__.py EOF from typing import Dict, Any from app.agents.agent_types import AgentStreamingResponse def post_process_response( response: AgentStreamingResponse, inputs: Dict[str, Any], user_id: str, app_id: str ) - Dict[str, Any]: Agent响应后置处理执行业务断言 :param response: Dify原生响应对象 :param inputs: 用户原始输入 :param user_id: 用户ID用于关联审计日志 :param app_id: Agent应用ID用于加载对应评测规则 :return: 增强后的响应字典含评测结果 # 1. 提取原始响应文本 answer_text response.answer if hasattr(response, answer) else # 2. 加载该Agent专属的评测规则JSON文件 rules_file f/app/plugins/rules/{app_id}.json try: with open(rules_file, r, encodingutf-8) as f: rules json.load(f) except FileNotFoundError: return {answer: answer_text, eval_result: NO_RULES_FOUND} # 3. 执行所有断言规则 eval_results [] for rule in rules.get(assertions, []): result _execute_assertion(rule, answer_text, inputs) eval_results.append(result) # 4. 汇总评测结论 overall_pass all(r[pass] for r in eval_results) return { answer: answer_text, eval_result: { overall_pass: overall_pass, details: eval_results, timestamp: response.created_at.isoformat() if hasattr(response, created_at) else } } def _execute_assertion(rule: Dict, answer: str, inputs: Dict) - Dict: 执行单条断言规则 rule_type rule.get(type) if rule_type contains: # 检查答案是否包含指定关键词 expected rule.get(expected, ) pass_flag expected in answer return {rule_id: rule.get(id), type: contains, expected: expected, pass: pass_flag} elif rule_type regex: # 正则匹配用于提取结构化数据 pattern rule.get(pattern, ) match re.search(pattern, answer) pass_flag bool(match) return {rule_id: rule.get(id), type: regex, pattern: pattern, pass: pass_flag, match: match.group() if match else None} elif rule_type length: # 长度约束 min_len rule.get(min, 0) max_len rule.get(max, 10000) actual_len len(answer) pass_flag min_len actual_len max_len return {rule_id: rule.get(id), type: length, min: min_len, max: max_len, actual: actual_len, pass: pass_flag} else: return {rule_id: rule.get(id), type: unknown, pass: False} EOF # 创建规则存储目录 mkdir -p ~/dify-deploy/plugins/rules步骤2修改Worker启动命令注入插件路径# 停止原有Worker docker stop dify-worker # 重新启动Worker挂载插件目录并设置PYTHONPATH docker run -d \ --name dify-worker \ --network dify-net \ --memory3g --cpus2 \ -e SQLALCHEMY_DATABASE_URIpostgresql://postgres:dify123dify-db:5432/dify \ -e REDIS_URLredis://dify-redis:6379/0 \ -e QDRANT_URLhttp://dify-qdrant:6333 \ -e WORKER_LOG_LEVELDEBUG \ -v ~/dify-deploy/worker:/app/storage \ -v ~/dify-deploy/models:/app/models \ -v ~/dify-deploy/plugins:/app/plugins \ # 挂载插件目录 -e PYTHONPATH/app/plugins:/app \ # 让Python能找到插件 --restartunless-stopped \ difyai/dify:latest \ celery -A app.worker.celery_worker.celery_worker worker --loglevelinfo -Q high_priority,default,low_priority -c 2步骤3为具体Agent编写评测规则以“供应商资质审核Agent”为例创建~/dify-deploy/plugins/rules/supplier_audit.json{ agent_name: 供应商资质审核, description: 审核供应商提供的营业执照、ISO证书、银行资信证明三类文件, assertions: [ { id: A001, type: contains, expected: 营业执照有效期至 }, { id: A002, type: contains, expected: ISO认证标准号 }, { id: A003, type: regex, pattern: 银行资信证明.*?信用等级[:]\\s*([A-Z]), description: 必须提取信用等级字母如AAA }, { id: A004, type: length, min: 300, max: 2000, description: 审核结论长度应在300-2000字符之间 } ] }步骤4在Dify Web中启用评测无需改前端Dify的API响应是JSON格式评测结果会自动附加在eval_result字段中。你只需在调用API时解析这个字段即可# Python评测脚本示例 import requests import json def run_agent_test(): url http://localhost:5001/v1/chat-messages headers {Authorization: Bearer YOUR_API_KEY} data { inputs: {supplier_name: XX科技有限公司}, query: 请审核该公司提供的资质文件, response_mode: blocking, user: test-audit } response requests.post(url, headersheaders, jsondata) result response.json() # 提取评测结果 eval_result result.get(eval_result, {}) print(f整体通过: {eval_result.get(overall_pass, False)}) for detail in eval_result.get(details, []): print(f {detail[rule_id]}: {✅ if detail[pass] else ❌} {detail.get(description, )}) run_agent_test()这个框架的价值在于评测逻辑与Agent业务逻辑完全解耦。当法务部要求新增一条规则“必须声明‘本审核不构成法律意见’”你只需在JSON里加一行无需重启服务、无需修改Python代码、无需协调前后端。真正的低代码是让业务规则的变更成本趋近于零。3.2 构建自动化评测流水线从单次测试到持续验证单次评测只能告诉你“此刻是否通过”而自动化流水线才能回答“它是否持续可靠”。我为客户搭建的流水线每天凌晨2点自动运行覆盖三大维度维度测试目标执行频率数据来源稳定性Agent连续72小时无崩溃、无超时每小时1次Worker日志中的ERROR/WARNING行数准确性对100个历史真实case的响应与专家标注答案的F1值每日1次本地CSV测试集含输入、期望输出、权重性能P95响应延迟 ≤ 8.5秒Token消耗波动率 15%每日1次PostgreSQL的task_execution_log表核心组件评测调度器scheduler.py#!/usr/bin/env python3 # 保存为 ~/dify-deploy/scripts/scheduler.py import subprocess import json import time from datetime import datetime, timedelta import psycopg2 from psycopg2.extras import RealDictCursor # 数据库连接配置复用Dify的DB DB_CONFIG { host: localhost, port: 5432, database: dify, user: postgres, password: dify123 } def run_stability_check(): 检查过去1小时Worker稳定性 # 读取Worker日志最后1000行统计ERROR数量 result subprocess.run( [docker, logs, --since, 1h, dify-worker], capture_outputTrue, textTrue ) error_count result.stdout.count(ERROR) result.stdout.count(Traceback) warning_count result.stdout.count(WARNING) # 写入评测结果表 conn psycopg2.connect(**DB_CONFIG) cur conn.cursor() cur.execute( INSERT INTO agent_eval_results (test_type, status, details, created_at) VALUES (%s, %s, %s, %s) , (stability, PASS if error_count 0 else FAIL, json.dumps({error_count: error_count, warning_count: warning_count}), datetime.now())) conn.commit() cur.close() conn.close() def run_accuracy_benchmark(): 运行准确率基准测试 # 读取本地测试集 with open(/app/test_cases/supplier_audit_cases.json, r, encodingutf-8) as f: cases json.load(f) total_cases len(cases) passed_cases 0 results [] for case in cases: # 调用Dify API response requests.post( http://localhost:5001/v1/chat-messages, headers{Authorization: Bearer YOUR_API_KEY}, json{ inputs: case[inputs], query: case[query], response_mode: blocking, user: benchmark-runner } ) result response.json() # 提取评测结果 eval_result result.get(eval_result, {}) if eval_result.get(overall_pass): passed_cases 1 results.append({ case_id: case[id], input: case[query], answer: result.get(answer, ), eval_pass: eval_result.get(overall_pass, False) }) # 计算F1并入库 accuracy passed_cases / total_cases if total_cases 0 else 0 conn psycopg2.connect(**DB_CONFIG) cur conn.cursor() cur.execute( INSERT INTO agent_eval_results (test_type, status, details, created_at) VALUES (%s, %s, %s, %s) , (accuracy, PASS if accuracy 0.95 else FAIL, json.dumps({accuracy: round(accuracy, 4), total: total_cases, passed: passed_cases}), datetime.now())) conn.commit() cur.close() conn.close() if __name__ __main__: # 每日凌晨2点执行 while True: now datetime.now() if now.hour 2 and now.minute 0: print(f[{now}] 开始执行每日评测...) run_stability_check() run_accuracy_benchmark() print(f[{now}] 评测完成) time.sleep(60) # 避免同一分钟内重复执行 time.sleep(30)数据库表结构在Dify DB中创建-- 创建评测结果表 CREATE TABLE IF NOT EXISTS agent_eval_results ( id SERIAL PRIMARY KEY, test_type VARCHAR(50) NOT NULL, -- stability, accuracy, performance status VARCHAR(20) NOT NULL, -- PASS, FAIL, WARNING details JSONB NOT NULL, -- 详细结果 created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW() ); -- 创建索引加速查询 CREATE INDEX idx_eval_type_time ON agent_eval_results(test_type, created_at);启动调度器作为独立容器# 构建轻量级调度器镜像 cat ~/dify-deploy/scripts/Dockerfile EOF FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [python, scheduler.py] EOF cat ~/dify-deploy/scripts/requirements.txt EOF requests2.31.0 psycopg2-binary2.9.7 EOF # 构建并运行 cd ~/dify-deploy/scripts docker build -t dify-eval-scheduler . docker run -d \ --name dify-eval-scheduler \ --network dify-net \ -v ~/dify-deploy/scripts:/app \ --restartunless-stopped \ dify-eval-scheduler这套流水线运行3个月后客户法务部主动提出“以后所有新上线的Agent必须先过你们的评测流水线再提交给我们审核。”——这才是评测框架真正的价值它不证明技术多先进而是证明业务风险可控。4. 实战避坑指南那些让90%团队卡住的“小问题”其实藏着大逻辑部署和评测框架搭建过程中我记录了137个具体问题其中前10个高频问题占了所有咨询量的76%。这些问题表面看是操作失误深挖下去却暴露了对AI系统本质的误解。下面挑出最具代表性的5个用真实排查过程还原“为什么这样解决”。4.1 问题Dify Web界面显示“知识库处理中...”但10分钟后仍无进展Worker日志空白现象还原客户在Dify Web上传一份50页PDF合同点击“处理”界面上一直显示“处理中”打开Worker日志docker logs dify-worker最后一行停在[INFO] Starting new HTTPS connection再无后续。排查链路首先确认Worker是否真的在运行docker ps | grep dify-worker→ 状态是Up 2 hours正常检查Worker是否连接Redisdocker exec -it dify-worker redis-cli -h dify-redis ping→ 返回