当前位置：首页 > news >正文

Dify本地部署构建AI Agent可信评测沙盒实战指南

news 2026/6/20 5:35:33

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-33B+Dify组合时，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限制、暴露调试端口。这不是为了炫技，而是为了满足三个硬性评测需求：
1. 可复现性：当评测发现某个Agent在下午3:15:22返回错误结果，你能立刻用docker logs -t --since "2024-06-15T15:15:20" worker精准定位那一秒的完整上下文；
2. 可干预性：评测过程中需要临时修改Agent的提示词温度值（temperature），你直接进Web容器执行echo 'TEMPERATURE=0.3' >> /app/.env再supervisorctl restart web，30秒生效，无需重启整个栈；
3. 可归因性：当评测报告指出“知识库检索准确率下降12%”，你能用docker stats postgresql确认是数据库连接池耗尽，还是用docker exec -it qdrant qdrant info查出向量库索引碎片率过高——而不是在SaaS后台看到一句“系统繁忙，请稍后再试”。

提示：不要迷信“一键部署脚本”。我测试过三个主流GitHub仓库的Dify一键脚本，其中两个在Windows WSL2环境下会因/dev/shm共享内存大小默认为64MB（Qdrant向量库最低要求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 Worker+Qdrant+PostgreSQL最低需4GB） free -h # 如果内存不足，编辑 C:\Users\<用户名>\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\wsl.conf # 添加以下内容并重启WSL： # [wsl2] # memory=6GB # 直接限制WSL2最大内存，避免宿主机卡死 # swap=2GB # localhostForwarding=true

第二项：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_PASSWORD=dify123：生产环境必须改，此处仅为演示 # -v ~/dify-deploy/db:/var/lib/postgresql/data：数据卷映射，确保重启不丢数据 # --memory=1g --cpus=1.5：硬性限制资源，防止DB吃光内存影响Worker # --health-cmd="pg_isready -U postgres -d dify"：健康检查，Dify Worker启动前会等待DB就绪 docker run -d \ --name dify-db \ --network dify-net \ -e POSTGRES_PASSWORD=dify123 \ -e POSTGRES_DB=dify \ -v ~/dify-deploy/db:/var/lib/postgresql/data \ -p 5432:5432 \ --memory=1g --cpus=1.5 \ --health-cmd="pg_isready -U postgres -d dify" \ --restart=unless-stopped \ -d postgres:15-alpine # 验证DB是否就绪（等待Health Status变为healthy） docker inspect --format='{{.State.Health.Status}}' dify-db

Redis缓存（会话与任务队列）

# Redis不设密码（Dify默认配置），但必须限制内存防止OOM # --maxmemory 512mb --maxmemory-policy allkeys-lru：强制内存上限与淘汰策略 docker run -d \ --name dify-redis \ --network dify-net \ --memory=512m \ --cpus=0.5 \ -v ~/dify-deploy/cache:/data \ --restart=unless-stopped \ redis:7-alpine \ redis-server --maxmemory 512mb --maxmemory-policy allkeys-lru

Qdrant向量数据库（知识库底层）

# Qdrant对共享内存（/dev/shm）要求严格，必须显式挂载且足够大 # --shm-size=2g：这是最关键的参数，缺它必报错 # -p 6333:6333：暴露HTTP端口供Dify Web调用 docker run -d \ --name dify-qdrant \ --network dify-net \ --shm-size=2g \ --memory=2g --cpus=2 \ -v ~/dify-deploy/vector:/qdrant/storage \ -p 6333:6333 \ --restart=unless-stopped \ qdrant/qdrant:v1.7.4

Dify 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 \ --memory=1.5g --cpus=1.5 \ -e SQLALCHEMY_DATABASE_URI="postgresql://postgres:dify123@dify-db:5432/dify" \ -e REDIS_URL="redis://dify-redis:6379/0" \ -e QDRANT_URL="http://dify-qdrant:6333" \ -e CONSOLE_WEB_URL="http://localhost:3000" \ -e API_URL="http://localhost:5001" \ -e SECRET_KEY="your-secret-key-change-in-production" \ -e SESSION_COOKIE_SAMESITE="Lax" \ -v ~/dify-deploy/web:/app/storage \ --restart=unless-stopped \ difyai/dify:latest

Dify Worker服务（Agent执行引擎）

# Worker是Agent实际运行的地方，也是评测的核心靶场 # 必须挂载/storage目录（存放临时文件、日志）、/models（存放本地模型） # WORKER_LOG_LEVEL=DEBUG：评测阶段必须开DEBUG，否则看不到Agent每一步的token消耗、API调用详情 docker run -d \ --name dify-worker \ --network dify-net \ --memory=3g --cpus=2 \ -e SQLALCHEMY_DATABASE_URI="postgresql://postgres:dify123@dify-db:5432/dify" \ -e REDIS_URL="redis://dify-redis:6379/0" \ -e QDRANT_URL="http://dify-qdrant:6333" \ -e WORKER_LOG_LEVEL="DEBUG" \ -v ~/dify-deploy/worker:/app/storage \ -v ~/dify-deploy/models:/app/models \ --restart=unless-stopped \ difyai/dify:latest \ celery -A app.worker.celery_worker.celery_worker worker --loglevel=info -Q high_priority,default,low_priority -c 2

注意：所有docker run命令中的--restart=unless-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"字段，且status=200 # 此时立刻查看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', encoding='utf-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 \ --memory=3g --cpus=2 \ -e SQLALCHEMY_DATABASE_URI="postgresql://postgres:dify123@dify-db:5432/dify" \ -e REDIS_URL="redis://dify-redis:6379/0" \ -e QDRANT_URL="http://dify-qdrant:6333" \ -e WORKER_LOG_LEVEL="DEBUG" \ -v ~/dify-deploy/worker:/app/storage \ -v ~/dify-deploy/models:/app/models \ -v ~/dify-deploy/plugins:/app/plugins \ # 挂载插件目录 -e PYTHONPATH="/app/plugins:/app" \ # 让Python能找到插件 --restart=unless-stopped \ difyai/dify:latest \ celery -A app.worker.celery_worker.celery_worker worker --loglevel=info -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, headers=headers, json=data) 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_output=True, text=True ) 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", encoding="utf-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' requests==2.31.0 psycopg2-binary==2.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 \ --restart=unless-stopped \ dify-eval-scheduler

这套流水线运行3个月后，客户法务部主动提出：“以后所有新上线的Agent，必须先过你们的评测流水线，再提交给我们审核。”——这才是评测框架真正的价值：它不证明技术多先进，而是证明业务风险可控。