基于Prometheus与Grafana构建智能体评估监控体系

当你的智能体在实验室里跑得风生水起准确率报表一片飘绿时你是否真的敢把它推向生产环境或者说你如何证明它不只是“看起来”很聪明而是能在真实、复杂、多变的场景下稳定、可靠地工作这正是“前沿实验室如何监控智能体评估”这个问题的核心。它不是一个简单的技术选型问题而是一个关乎AI工程化落地的系统工程。很多团队在智能体开发上投入巨大却卡在了从“Demo可用”到“生产可靠”的最后一公里。传统的模型评估比如看个准确率、召回率对于智能体这种具备自主规划、工具调用、多轮交互能力的复杂系统已经完全不够用了。你需要监控的是它的“行为”而不仅仅是“输出”。本文将为你拆解一套可落地的智能体评估监控体系。我们不会空谈理论而是聚焦于如何搭建一个从数据采集、指标定义、实时监控到问题归因的完整闭环。你会看到如何利用Prometheus、Grafana等成熟的开源监控栈结合自定义的评估器Evaluator将智能体的每一次对话、每一个决策都变成可度量、可分析、可优化的数据点。读完本文你将能为自己实验室的智能体项目构建起一道可靠的质量防线。1. 智能体评估监控到底在解决什么问题在深入技术细节之前我们必须先厘清一个根本问题对智能体进行监控和评估与传统软件或单一模型有何不同其独特挑战是什么传统软件监控关注的是资源CPU、内存、可用性服务是否在线、错误率HTTP 5xx和延迟。这些很重要但对智能体来说只是“生存指标”。一个智能体服务可能CPU使用率正常、响应也快但给出的建议完全是错误的或者陷入了死循环。传统模型评估如分类模型关注的是准确率、F1-score等静态指标。这些指标基于一个有标准答案的测试集。而智能体的任务往往是开放性的没有唯一标准答案。例如一个客服智能体处理用户投诉其回复的“恰当性”、“同理心”、“问题解决率”很难用一个简单的对错来衡量。因此智能体评估监控的核心是解决以下三个层面的问题能力层面它“会不会”这是最基本的评估。智能体能否正确理解指令能否调用正确的工具如搜索API、数据库查询规划的逻辑是否合理这需要一套针对其设计目标的“能力测试集”。性能层面它“快不快、稳不稳”这结合了软件和模型监控。包括单次推理耗时、工具调用的网络延迟、多轮对话的上下文长度增长对性能的影响、在高并发下的稳定性等。行为层面它“安不安全、可不可控”这是智能体独有的、也是最重要的监控维度。智能体是否会产生有害、偏见或幻觉内容是否会在未经授权的情况下执行危险操作如删除数据其决策过程是否在一定程度的可解释范围内一个完整的监控体系必须能同时覆盖这三个层面并将监控数据转化为可行动的洞察。否则你的智能体就是一个在实验室里表现良好但一进入现实就可能“行为失常”的黑盒。2. 核心概念与监控体系架构在开始搭建之前我们需要定义几个关键概念并描绘出整体架构蓝图。2.1 核心概念定义智能体Agent本文指基于大语言模型LLM具备规划Planning、工具调用Tool Calling、记忆Memory等能力的自治系统。它接收用户输入自然语言或结构化指令经过一系列内部决策和外部交互最终产生输出。评估Evaluation衡量智能体在特定任务或通用能力上表现的过程。可分为离线评估使用预先准备好的测试集一组(输入期望输出)对进行批量测试生成汇总报告。适合版本发布前的能力回归。在线评估对生产环境或仿真环境中的真实用户交互进行实时或近实时的评估。关注动态表现。监控Monitoring持续地收集、聚合、可视化智能体系统的各项指标和日志并在异常时告警。评估是监控的数据来源之一监控是评估结果的持续观察窗口。轨迹Trace记录一次智能体调用从开始到结束的完整生命周期数据包括用户输入、模型内部思考Chain of Thought、工具调用请求与响应、最终输出等。这是进行分析和评估的原始材料。评估器Evaluator一个程序或模块它接收智能体的轨迹或输入输出对根据预定义的规则或模型输出一个评估结果如分数、标签、评语。评估器可以是基于规则的如关键词匹配、基于模型的用另一个LLM来评判或基于真实业务结果的如是否成功下单。2.2 监控体系架构蓝图一个典型的智能体评估监控体系包含以下层次如下图所示概念图[ 数据采集层 ] -- [ 计算与存储层 ] -- [ 可视化与告警层 ] -- [ 分析与行动层 ] | | | | 智能体服务 指标计算/日志聚合 Grafana仪表盘 问题定位/模型迭代 评估器打分 时序数据库(Prometheus) 告警规则(Alertmanager) A/B测试 业务日志 分布式追踪(Jaeger) 日志平台(ELK/Loki)数据采集层智能体服务在关键节点埋点发射指标Metrics和日志Logs。评估器对每次交互或批量任务进行打分结果也作为指标上报。计算与存储层使用Prometheus抓取和存储时间序列指标使用Loki或ELK收集和索引日志使用Jaeger存储分布式追踪轨迹。可视化与告警层使用Grafana从上述存储中查询数据绘制面向不同角色开发者、算法工程师、产品经理的仪表盘。配置Alertmanager规则当关键指标异常如错误率飙升、平均分骤降时通过邮件、钉钉、企业微信等渠道告警。分析与行动层基于监控数据定位问题。例如通过日志找到导致低分的具体对话通过对比不同版本智能体的指标进行A/B测试决策根据评估弱点定向补充训练数据。3. 环境准备与工具选型我们将基于最流行的开源技术栈来构建这套监控体系。这套方案轻量、可扩展适合实验室及中小型团队。基础运行环境操作系统Linux (Ubuntu 20.04/22.04 LTS 或 CentOS 7/8)或 macOS用于开发测试。容器环境Docker 与 Docker Compose。这是简化部署的关键。硬件至少4核CPU8GB内存50GB磁盘空间。监控数据积累会占用存储。核心组件选型与版本Prometheus(v2.45.0): 负责抓取和存储时间序列指标数据。Grafana(v10.0.0): 负责指标数据的可视化展示和告警配置。Alertmanager(v0.25.0): 与Prometheus配合负责处理告警通知。Loki(v2.8.0): 由Grafana Labs开发的日志聚合系统与Grafana集成度极高适合存储和查询智能体的文本日志。Promtail(v2.8.0): Loki的日志收集代理部署在智能体服务所在机器上负责推送日志到Loki。Jaeger(v1.47.0): 分布式追踪系统用于记录单次请求在智能体内部各模块的详细调用链和耗时。智能体服务本文将以一个基于Python使用LangChain或LlamaIndex框架的智能体为例。你需要准备Python 3.9环境。我们使用docker-compose来一键启动监控基础设施。这避免了复杂的本地安装和配置。4. 部署监控基础设施首先在你的工作目录例如~/agent-monitor下创建docker-compose.yml文件。# docker-compose.yml version: 3.8 networks: monitor-net: driver: bridge volumes: prometheus_data: {} grafana_data: {} loki_data: {} jaeger_data: {} services: # Prometheus 时序数据库 prometheus: image: prom/prometheus:v2.45.0 container_name: prometheus restart: unless-stopped volumes: - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml - prometheus_data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --web.console.libraries/etc/prometheus/console_libraries - --web.console.templates/etc/prometheus/consoles - --storage.tsdb.retention.time30d # 数据保留30天 - --web.enable-lifecycle ports: - 9090:9090 networks: - monitor-net # Grafana 可视化 grafana: image: grafana/grafana:10.0.0 container_name: grafana restart: unless-stopped environment: - GF_SECURITY_ADMIN_PASSWORDadmin123 # 首次登录密码请在生产环境修改 volumes: - grafana_data:/var/lib/grafana - ./grafana/provisioning:/etc/grafana/provisioning ports: - 3000:3000 networks: - monitor-net # Alertmanager 告警管理 alertmanager: image: prom/alertmanager:v0.25.0 container_name: alertmanager restart: unless-stopped volumes: - ./alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml command: - --config.file/etc/alertmanager/alertmanager.yml - --storage.path/alertmanager ports: - 9093:9093 networks: - monitor-net # Loki 日志聚合 loki: image: grafana/loki:2.8.0 container_name: loki restart: unless-stopped volumes: - loki_data:/loki - ./loki/loki-config.yaml:/etc/loki/local-config.yaml command: -config.file/etc/loki/local-config.yaml ports: - 3100:3100 networks: - monitor-net # Promtail 日志收集客户端 promtail: image: grafana/promtail:2.8.0 container_name: promtail restart: unless-stopped volumes: - /var/log:/var/log # 挂载宿主机日志目录按需调整 - ./promtail/promtail-config.yaml:/etc/promtail/config.yaml - /var/lib/docker/containers:/var/lib/docker/containers:ro # 收集Docker容器日志 command: -config.file/etc/promtail/config.yaml networks: - monitor-net # Jaeger 分布式追踪 jaeger: image: jaegertracing/all-in-one:1.47.0 container_name: jaeger restart: unless-stopped environment: - COLLECTOR_OTLP_ENABLEDtrue volumes: - jaeger_data:/tmp ports: - 16686:16686 # Jaeger UI - 4317:4317 # OTLP gRPC - 4318:4318 # OTLP HTTP networks: - monitor-net接下来创建各个组件的配置文件。1. Prometheus 配置 (prometheus/prometheus.yml)global: scrape_interval: 15s # 每15秒抓取一次指标 evaluation_interval: 15s # 每15秒评估一次告警规则 alerting: alertmanagers: - static_configs: - targets: - alertmanager:9093 # 告警发送到Alertmanager rule_files: - alert_rules.yml # 告警规则文件稍后创建 scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: agent-service # 这是你的智能体服务假设暴露指标在8000端口 static_configs: - targets: [host.docker.internal:8000] # 在Docker内访问宿主机服务 metrics_path: /metrics scrape_interval: 10s # 对业务服务可以抓取更频繁 - job_name: node-exporter # 可选监控宿主机资源 static_configs: - targets: [host.docker.internal:9100]2. Loki 配置 (loki/loki-config.yaml)auth_enabled: false server: http_listen_port: 3100 common: path_prefix: /loki storage: filesystem: chunks_directory: /loki/chunks rules_directory: /loki/rules replication_factor: 1 ring: instance_addr: 127.0.0.1 kvstore: store: inmemory schema_config: configs: - from: 2020-10-24 store: boltdb-shipper object_store: filesystem schema: v11 index: prefix: index_ period: 24h3. Promtail 配置 (promtail/promtail-config.yaml)server: http_listen_port: 9080 grpc_listen_port: 0 positions: filename: /tmp/positions.yaml clients: - url: http://loki:3100/loki/api/v1/push scrape_configs: - job_name: system static_configs: - targets: - localhost labels: job: varlogs __path__: /var/log/*log # 收集系统日志按需调整 - job_name: agent-app static_configs: - targets: - localhost labels: job: agent-service-logs app: my-ai-agent __path__: /path/to/your/agent/logs/*.log # 重要指向你的智能体应用日志目录4. Alertmanager 配置 (alertmanager/alertmanager.yml)global: smtp_smarthost: smtp.qq.com:465 # 以QQ邮箱为例 smtp_from: your-emailqq.com smtp_auth_username: your-emailqq.com smtp_auth_password: your-smtp-auth-code # 注意是授权码非登录密码 smtp_require_tls: true route: group_by: [alertname] group_wait: 10s group_interval: 10s repeat_interval: 1h receiver: email-notifications receivers: - name: email-notifications email_configs: - to: team-alertsyourcompany.com send_resolved: true # 发送恢复通知创建好所有文件和目录后在docker-compose.yml所在目录执行docker-compose up -d等待所有容器启动。之后你可以访问Grafana:http://localhost:3000(用户名admin, 密码admin123)Prometheus:http://localhost:9090Jaeger UI:http://localhost:16686Alertmanager:http://localhost:9093至此监控基础设施已就绪。接下来我们需要让智能体服务接入这个体系。5. 智能体服务埋点与指标上报智能体服务需要暴露两类数据指标(Metrics)和日志(Logs)。我们以Python FastAPI应用为例使用prometheus_client和structlog库。5.1 依赖安装pip install fastapi uvicorn prometheus-client structlog python-json-logger5.2 核心代码实现埋点与评估创建一个简单的智能体服务文件agent_service.py# agent_service.py import time import random from typing import Dict, Any, List from fastapi import FastAPI, Request from prometheus_client import Counter, Histogram, Gauge, generate_latest, REGISTRY from prometheus_client.openmetrics.exposition import CONTENT_TYPE_LATEST import structlog import asyncio # 初始化结构化日志 logger structlog.get_logger() # 定义Prometheus指标 # 1. 请求相关指标 REQUEST_COUNT Counter(agent_requests_total, Total number of requests, [endpoint, status]) REQUEST_LATENCY Histogram(agent_request_duration_seconds, Request latency in seconds, [endpoint]) ACTIVE_REQUESTS Gauge(agent_requests_in_progress, Number of requests in progress) # 2. 智能体能力评估指标 # 假设我们有几个评估维度 EVALUATION_SCORE Gauge(agent_evaluation_score, Score for a specific evaluation dimension, [dimension, session_id]) TOOL_CALL_COUNT Counter(agent_tool_calls_total, Total number of tool calls, [tool_name, status]) HALLUCINATION_DETECTED Counter(agent_hallucination_events_total, Total hallucination events detected) # 3. 业务/模型相关指标 INPUT_TOKEN_COUNT Histogram(agent_input_tokens, Number of input tokens per request, buckets[10, 50, 100, 200, 500]) OUTPUT_TOKEN_COUNT Histogram(agent_output_tokens, Number of output tokens per request, buckets[10, 50, 100, 200, 500]) app FastAPI(titleAI Agent Evaluation Service) # 模拟一个简单的智能体处理函数 async def process_agent_request(user_input: str, session_id: str) - Dict[str, Any]: 模拟智能体处理流程包括思考、工具调用、生成回复。 在实际项目中这里会是你的LangChain/LlamaIndex Agent执行逻辑。 # 模拟一些处理步骤 await asyncio.sleep(random.uniform(0.1, 0.5)) # 模拟思考时间 # 模拟工具调用例如搜索 tools_used [] if 天气 in user_input: tools_used.append((weather_api, success)) TOOL_CALL_COUNT.labels(tool_nameweather_api, statussuccess).inc() elif 计算 in user_input: tools_used.append((calculator, success)) TOOL_CALL_COUNT.labels(tool_namecalculator, statussuccess).inc() # 模拟生成回复 response f这是对{user_input}的模拟回复。Session: {session_id} # 模拟评估器打分在实际中这可能是一个独立的模型或规则引擎 evaluation_results { relevance: random.uniform(0.7, 1.0), # 相关性分数 safety: random.uniform(0.9, 1.0), # 安全性分数 helpfulness: random.uniform(0.6, 1.0) # 有帮助性分数 } # 上报评估分数指标 for dim, score in evaluation_results.items(): EVALUATION_SCORE.labels(dimensiondim, session_idsession_id).set(score) # 模拟检测到幻觉低概率事件 if random.random() 0.05: # 5%的概率模拟幻觉 HALLUCINATION_DETECTED.inc() logger.warning(hallucination_detected, session_idsession_id, inputuser_input) return { response: response, session_id: session_id, tools_used: tools_used, evaluation: evaluation_results } app.post(/chat) REQUEST_LATENCY.labels(endpoint/chat).time() async def chat_endpoint(request: Request): 智能体聊天接口 ACTIVE_REQUESTS.inc() session_id request.headers.get(X-Session-ID, unknown) try: data await request.json() user_input data.get(message, ) # 记录输入长度模拟token计数 input_len len(user_input.split()) INPUT_TOKEN_COUNT.observe(input_len) # 处理请求 result await process_agent_request(user_input, session_id) # 记录输出长度 output_len len(result[response].split()) OUTPUT_TOKEN_COUNT.observe(output_len) # 记录成功请求 REQUEST_COUNT.labels(endpoint/chat, statussuccess).inc() # 记录结构化日志 logger.info(request_processed, endpoint/chat, session_idsession_id, input_lengthinput_len, output_lengthoutput_len, tools_usedlen(result[tools_used]), eval_scoresresult[evaluation]) return {success: True, data: result} except Exception as e: # 记录失败请求 REQUEST_COUNT.labels(endpoint/chat, statuserror).inc() logger.error(request_failed, endpoint/chat, session_idsession_id, errorstr(e)) return {success: False, error: str(e)} finally: ACTIVE_REQUESTS.dec() app.get(/metrics) async def metrics(): 暴露Prometheus指标端点 return Response(generate_latest(REGISTRY), media_typeCONTENT_TYPE_LATEST) if __name__ __main__: import uvicorn # 配置结构化日志输出到文件和控制台 structlog.configure( processors[ structlog.stdlib.filter_by_level, structlog.stdlib.add_logger_name, structlog.stdlib.add_log_level, structlog.stdlib.PositionalArgumentsFormatter(), structlog.processors.TimeStamper(fmtiso), structlog.processors.StackInfoRenderer(), structlog.processors.format_exc_info, structlog.processors.UnicodeDecoder(), structlog.stdlib.render_to_log_kwargs, ], context_classdict, logger_factorystructlog.stdlib.LoggerFactory(), cache_logger_on_first_useTrue, ) # 启动服务暴露在8000端口 uvicorn.run(app, host0.0.0.0, port8000)5.3 配置日志输出到文件为了让Promtail收集日志我们需要将日志写入文件。修改日志配置部分或使用以下方式启动服务并将输出重定向到文件# 启动服务并将日志输出到文件 python agent_service.py /path/to/your/agent/logs/agent.log 21 更好的方式是在代码中直接配置structlog输出到文件这里为了简洁使用重定向。5.4 更新Promtail配置确保你在第4步中创建的promtail/promtail-config.yaml文件里的__path__指向了正确的日志文件路径例如- job_name: agent-app static_configs: - targets: - localhost labels: job: agent-service-logs app: my-ai-agent __path__: /path/to/your/agent/logs/agent.log # 确保路径正确重启Promtail以加载新配置docker-compose restart promtail6. 集成与验证让数据流动起来现在我们有了运行中的监控基础设施和一个模拟的智能体服务。接下来让它们联动起来。6.1 启动智能体服务并验证指标启动智能体服务python agent_service.py验证指标端点访问http://localhost:8000/metrics你应该能看到Prometheus格式的指标输出。验证服务接口使用curl或Postman发送一个测试请求。curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -H X-Session-ID: test-session-123 \ -d {message: 今天北京的天气怎么样}再次检查http://localhost:8000/metrics应该能看到agent_requests_total,agent_evaluation_score等指标计数发生变化。6.2 配置Prometheus抓取智能体指标更新prometheus/prometheus.yml确保job_name: agent-service的targets指向正确的主机和端口。如果你在宿主机运行智能体服务在Docker容器内需要通过host.docker.internal访问。确认后重启Prometheus。docker-compose restart prometheus在Prometheus UI (http://localhost:9090) 的“Status - Targets”页面查看agent-service目标是否为“UP”状态。6.3 配置Grafana数据源与仪表盘登录Grafana(http://localhost:3000)初始用户名密码为admin/admin123。添加数据源点击左侧齿轮图标 -Data Sources-Add data source。选择Prometheus。URL填写http://prometheus:9090(在Docker网络内)。点击Save Test应显示“Data source is working”。再次添加数据源选择Loki。URL填写http://loki:3100。点击Save Test。导入仪表盘点击左侧“”号 -Import。在“Import via grafana.com”输入框中输入11074这是一个流行的Node Exporter基础仪表盘ID用于监控主机资源可选。更关键的是我们需要创建自定义的智能体监控仪表盘。点击左侧“”号 -Dashboard-Add new panel。我们来创建几个核心图表Panel 1: 请求量与延迟Metrics:rate(agent_requests_total[5m])或sum(rate(agent_requests_total[5m])) by (status)Visualization: 选择Time series可以拆分图例按状态(status)显示成功/失败率。再添加一个查询histogram_quantile(0.95, rate(agent_request_duration_seconds_bucket[5m]))显示95分位延迟。Panel 2: 评估分数趋势Metrics:avg_over_time(agent_evaluation_score[5m])。在“Legend”处使用{{dimension}}来按维度relevance, safety, helpfulness显示多条线。Panel 3: 工具调用统计Metrics:sum(rate(agent_tool_calls_total[5m])) by (tool_name)。选择Bar gauge或Stat可视化。Panel 4: 活跃请求与异常Metrics:agent_requests_in_progress(当前活跃请求数)。另一个查询rate(agent_hallucination_events_total[5m])(幻觉事件发生率)。Panel 5: 日志查看器将可视化类型切换为Logs。在数据源选择Loki。查询语句可以写{appmy-ai-agent} | error查看错误日志或者{appmy-ai-agent}查看所有日志。将这些Panel排列好保存仪表盘命名为“AI Agent Production Monitor”。6.4 配置告警规则在prometheus/目录下创建alert_rules.yml文件# prometheus/alert_rules.yml groups: - name: agent_alerts rules: - alert: HighErrorRate expr: rate(agent_requests_total{statuserror}[5m]) / rate(agent_requests_total[5m]) 0.05 for: 2m labels: severity: critical service: ai-agent annotations: summary: 智能体服务错误率过高 description: 过去5分钟错误率超过5%当前值: {{ $value }} runbook_url: https://your-wiki/runbooks/high-error-rate - alert: HighLatency expr: histogram_quantile(0.95, rate(agent_request_duration_seconds_bucket[5m])) 3 for: 3m labels: severity: warning service: ai-agent annotations: summary: 智能体服务95分位延迟过高 description: 过去5分钟95分位延迟超过3秒当前值: {{ $value }}s - alert: SafetyScoreDropped expr: avg_over_time(agent_evaluation_score{dimensionsafety}[10m]) 0.8 for: 5m labels: severity: critical service: ai-agent annotations: summary: 智能体安全性评估分数持续偏低 description: 安全性评估分数在过去10分钟平均值低于0.8当前值: {{ $value }} - alert: HallucinationRateHigh expr: rate(agent_hallucination_events_total[10m]) 0.01 for: 2m labels: severity: warning service: ai-agent annotations: summary: 智能体幻觉事件发生率升高 description: 过去10分钟幻觉事件发生率超过1%需关注。更新prometheus/prometheus.yml中的rule_files指向这个文件并重启Prometheus。docker-compose restart prometheus在Prometheus UI的“Alerts”标签页你应该能看到这些告警规则并根据当前指标值处于“Pending”或“Firing”状态。触发的告警会被发送到Alertmanager进而通过邮件通知。7. 运行结果与效果验证完成以上步骤后你的监控系统应该已经全面运行。让我们系统地验证一下生成负载并观察仪表盘 使用一个简单的脚本模拟用户请求持续几分钟。# simulate_traffic.py import requests import time import random sessions [sess-1, sess-2, sess-3] messages [今天天气如何, 帮我计算一下圆周率, 讲个笑话, 什么是机器学习, 写一首关于春天的诗] for i in range(100): session random.choice(sessions) msg random.choice(messages) try: resp requests.post(http://localhost:8000/chat, json{message: msg}, headers{X-Session-ID: session}, timeout5) print(fRequest {i}: {resp.status_code}) except Exception as e: print(fRequest {i} failed: {e}) time.sleep(random.uniform(0.1, 0.5))运行此脚本后刷新Grafana仪表盘。你应该能看到“请求量与延迟”面板请求速率曲线上升延迟有相应变化。“评估分数趋势”面板relevance, safety, helpfulness三条曲线在随机值附近波动。“工具调用统计”面板weather_api和calculator工具被调用。“活跃请求与异常”面板活跃请求数有波动幻觉事件可能偶尔出现。“日志查看器”面板滚动显示着request_processed和可能的hallucination_detected日志。验证告警 你可以手动触发一个告警。例如修改simulate_traffic.py让所有请求都带上一个容易引发“错误”的关键字或者在评估器逻辑中临时降低safety分数。观察Prometheus Alerts页面和你的收件箱如果配置了邮件看告警是否正常触发和通知。追踪一次请求 虽然本文示例未集成OpenTelemetry进行完整的分布式追踪但你可以通过日志中的session_id在Grafana的Loki日志面板中过滤出某一次会话的所有相关日志从而复现该次智能体调用的完整轨迹。这是排查复杂问题的重要手段。8. 常见问题与排查思路在搭建和运行过程中你可能会遇到以下问题问题现象可能原因排查方式解决方案Prometheus Targets 中agent-service状态为DOWN1. 网络不通。2. 智能体服务未运行或端口不对。3. Prometheus配置中targets地址错误。1. 在Prometheus容器内curl http://host.docker.internal:8000/metrics。2. 检查宿主机防火墙。3. 确认智能体服务/metrics端点可访问。1. 确保使用正确的网络别名或IP。2. 使用docker network inspect monitor-net查看网络。3. 将targets改为智能体服务的实际IP。Grafana 中查询不到 Prometheus 数据1. Grafana数据源配置错误。2. Prometheus中尚无对应指标数据。1. 在Grafana数据源配置页面点击Save Test。2. 在Grafana中使用Explore功能查询up指标看是否有agent-servicejob。1. 检查数据源URL和访问权限。2. 确保智能体服务已产生指标并成功被Prometheus抓取。Loki 中查询不到应用日志1. Promtail配置中__path__指向错误。2. 应用日志未输出到指定文件。3. 日志格式不被识别。1. 检查Promtail容器日志docker logs promtail。2. 确认日志文件存在且有写入权限。3. 在Grafana Explore中选择Loki数据源查询{jobagent-service-logs}。1. 修正promtail-config.yaml中的路径并重启Promtail。2. 确保应用以追加模式写入日志文件。3. 考虑在Promtail配置中添加pipeline_stages进行日志解析。评估分数指标agent_evaluation_score没有维度标签在定义Gauge指标时labelnames参数与labels方法调用不匹配。检查agent_service.py中EVALUATION_SCORE的定义和使用。确保labelnames列表与labels()方法传入的参数顺序和数量一致。正确定义Gauge(..., ..., [dimension, session_id])。正确设置.labels(dimensionrelevance, session_idabc).set(0.9)告警规则未触发或未通知1. Prometheus未加载告警规则文件。2. Alertmanager配置错误如SMTP。3. 告警表达式条件太苛刻。1. 访问http://localhost:9090/rules查看规则状态。2. 查看Alertmanager日志docker logs alertmanager。3. 在Prometheus的Graph页面手动执行告警表达式看结果是否为真。1. 检查prometheus.yml中rule_files路径重启Prometheus。2. 检查Alertmanager配置的SMTP信息使用curl测试。3. 调整expr阈值或for持续时间。仪表盘图表显示 “No data”1. 查询的时间范围没有数据。2. 指标名称拼写错误。3. 查询使用了不存在的标签。1. 调整Grafana右上角的时间范围如最近1小时。2. 在Prometheus UI的Graph页面输入指标前缀agent_查看自动补全的正确名称。3. 使用{__name__~agent.*}在Explore中模糊查询。1. 确保在所选时间范围内有流量产生。2. 核对代码中的指标名称与查询语句。3. 使用Prometheus的label_values()函数查看现有标签值。9. 最佳实践与工程建议将监控体系投入实际生产环境前请考虑以下最佳实践指标设计原则少即是多不要过度埋点。优先监控能直接反映系统健康度、用户体验和业务目标的核心指标如错误率、延迟、关键业务动作成功率、评估分数。标签Labels慎用标签可以维度化数据但每个标签组合都会创建新的时间序列可能导致Prometheus存储和查询压力剧增。避免使用高基数如用户ID、会话ID作为标签。对于这类数据应使用日志或追踪系统。评估指标标准化为你的智能体定义清晰、可衡量的评估维度如correctness、safety、helpfulness、efficiency。这些指标应尽可能自动化计算并作为黄金指标纳入监控告警。日志与追踪结构化日志如示例中使用structlog确保所有日志都是键值对的结构化格式便于Loki等系统索引和查询。关联性在日志、指标和追踪数据中使用统一的trace_id、span_id和session_id。这能让你在发现问题时快速从仪表盘上的异常指标定位到具体的错误日志和完整的请求调用链。考虑集成OpenTelemetry SDK来实现完整的分布式追踪。评估器的实现离线与在线结合离线评估使用精心构建的测试集用于模型迭代和版本发布。在线评估即本文实现的实时打分用于监控生产环境表现漂移。多样化评估手段基于规则的评估器快速、确定性强适合检查格式、安全性、禁忌词等。基于模型的评估器LLM-as-a-Judge使用另一个通常更强的LLM来评估智能体的输出在开放性任务上更灵活但成本高、延迟大。基于人工反馈的评估RLAIF/RLHF收集用户反馈如点赞/点踩作为评估信号是最真实的指标但需要产品设计配合。影子模式Shadow Mode在新评估器或新智能体版本上线初期让其并行运行但不影响线上结果只进行数据收集和对比评估是降低风险的有效手段。安全与权限监控系统自身的安全为Grafana、Prometheus等管理界面设置强密码考虑启用HTTPS。避免将监控端点暴露在公网。敏感数据脱敏智能体的输入输出可能包含用户隐私信息。在记录到日志或发送到评估器前必须进行脱敏处理如替换、哈希。最小权限原则评估器和监控组件访问数据库、API等资源时应使用具有最小必要权限的服务账户。告警的智慧避免告警疲劳只对需要立即人工干预的事情告警。将指标分为“需要告警”、“需要查看仪表盘”、“仅需记录”等级别。设置多级通知critical级别告警发短信或电话warning级别发邮件或即时通讯工具。附带上下文如示例中runbook_url告警信息应包含指向应急预案或排查文档的链接加速问题解决。成本与性能优化数据保留策略根据需求在Prometheus和Loki配置中设置合理的数据保留时间如7天、30天。长期历史数据可归档到对象存储如S3。采样对于极高流量的场景可以考虑对评估指标或日志进行采样只记录一部分数据以控制成本。评估器异步化复杂的模型评估可能耗时较长应设计为异步任务避免阻塞智能体的主响应链路。构建智能体的评估监控体系是一个从“艺术”走向“工程”的关键步骤。它让你从对模型输出的模糊感知转变为对系统行为的精确度量与持续优化。这套以PrometheusGrafanaLoki为核心的开源方案提供了一个强大、灵活且成本可控的起点。你可以在此基础上根据智能体的具体能力如视觉理解、代码执行和业务场景如客服、编程助手、游戏NPC定制更丰富的评估维度和监控面板。真正的挑战不在于搭建这套系统而在于如何定义出那些真正能反映智能体价值与风险的“黄金指标”。这需要算法工程师、开发工程师和产品经理的紧密协作。开始行动吧为你实验室里那个充满潜力的智能体装上眼睛和仪表盘让它更稳健地走向更广阔的世界。