Agent SRE 可视化观测面板：基于 Streamlit 监控 AI 代理可靠性、成本与混沌实验-平芜编程栈

Agent SRE 可视化观测面板：基于 Streamlit 监控 AI 代理可靠性、成本与混沌实验

【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit

本篇技术指南以 Agent Governance Toolkit 仓库中agent-sre包的官方示例仪表盘为核心，讲解如何用 Streamlit 搭建面向 AI 代理系统的一站式可靠性观测界面，覆盖 SLO 健康度、成本治理、混沌工程、事件管理与渐进式交付六大视图。读完本文，你将掌握该仪表盘的启动方法、六大 Tab 的数据模型与交互逻辑，以及它如何与 agent-sre SDK 的真实类型（SLO、CostGuard、ChaosExperiment、IncidentDetector）衔接，为后续接入真实遥测数据打下基础。

仪表盘概览：AI 代理的 SRE 作战室

Agent SRE Dashboard 是一个可独立运行的交互式 Streamlit 应用，用于监控 AI 代理（Agent）的可靠性（Reliability）、成本（Cost）、混沌实验（Chaos Experiments）、事件（Incidents）与渐进式交付（Progressive Delivery）。它位于仓库的 agent-sre/examples/dashboard 目录，核心文件包括：

README.md —— 官方使用说明（本文的主体依据）；
app.py —— 1081 行的完整仪表盘实现；
requirements.txt —— 依赖清单。

该面板的设计动机来自传统 SRE 实践向 AI 代理场景的迁移：传统 APM 只能告诉你"HTTP 200、延迟正常"，却无法捕获代理"自信地给出错误答案"、"工具调用失控烧钱"或"Agent A 信任了产生幻觉的 Agent B 导致级联故障"这类问题。这个仪表盘把 agent-sre 的七大可靠性能力（SLO、错误预算、混沌测试、成本护栏、渐进式交付、事件管理与回放）浓缩成一个可视化界面，让你一眼看清整个代理群的运行健康度。

从 app.py 的源码可以看到，仪表盘实际包含6 个 Tab（比 README 描述的 5 个多出"Policy Heatmap"）：

Tab	展示内容
SLO Health	错误预算、燃烧率（Burn Rate）、合规时间线、指标分解
Cost Management	每代理预算、成本趋势、告警、Top 消费方
Chaos Engineering	实验列表、韧性雷达图、故障注入时间线
Incidents	按严重级别分类的活动事件、MTTR、信号关联
Progressive Delivery	分阶段发布进度、预览测试匹配率
Policy Heatmap	策略评估/违规热力图（OpenTelemetry 治理指标密度）

仪表盘内置 8 个模拟代理（support-bot、code-reviewer、data-pipeline、billing-agent、search-indexer、deploy-agent、qa-tester、onboarding-flow），见 app.py，开箱即可演示，无需任何后端服务。

快速开始：两条命令启动面板

按照官方 README 的 Quick Start，只需两步即可启动：

# 1. 安装依赖 pip install -r agent-governance-python/agent-sre/examples/dashboard/requirements.txt # 2. 运行仪表盘 streamlit run agent-governance-python/agent-sre/examples/dashboard/app.py

依赖清单非常轻量（见 requirements.txt）：

streamlit>=1.54.0 plotly>=5.18.0 pandas>=2.0.0 numpy>=1.24.0

启动后，面板在http://localhost:8501打开。它独立运行、自带模拟数据；如果环境中已安装agent-sre包，则会使用真实的 SDK 类型进行更丰富的展示（这一点下文详述）。

双模式架构：模拟数据 + 真实 SDK 类型

仪表盘在启动时先尝试加载 agent-sre SDK，这段逻辑位于 app.py：

try: sys.path.insert(0, str(Path(__file__).parent.parent.parent / "src")) from agent_sre.slo.objectives import SLO, SLOStatus from agent_sre.slo.indicators import ( TaskSuccessRate, CostPerTask, ResponseLatency, HallucinationRate, ) from agent_sre.slo.dashboard import SLODashboard from agent_sre.cost.guard import CostGuard from agent_sre.chaos.engine import ChaosExperiment from agent_sre.incidents.detector import IncidentDetector _SDK = True except Exception: _SDK = False

这段代码有两点值得注意：

优雅降级：SDK 加载失败时置_SDK = False，仪表盘照常以纯模拟数据运行，不会崩溃；
SDK 可见性提示：侧边栏会显示SDK detected: Yes / No (simulated)（app.py），方便你确认当前运行模式。

其中导入的SLODashboard来自 src/agent_sre/slo/dashboard.py，它负责收集 SLO 快照（SLOSnapshot）、记录合规历史（ComplianceRecord）并生成健康摘要（health_summary，输出 total/healthy/warning/critical/exhausted/unknown 计数）——这正是仪表盘 SLO Health Tab 中 KPI 指标卡的字段来源。而SLO、SLOStatus、ErrorBudget定义在 src/agent_sre/slo/objectives.py，其中SLOStatus枚举了HEALTHY / WARNING / CRITICAL / EXHAUSTED / UNKNOWN五档状态，与仪表盘状态徽章一一对应。

另一个实现细节是确定性随机种子：app.py 把首次加载时间写入st.session_state["seed"]，并用np.random.default_rng(seed)生成所有模拟数据，保证会话内刷新时数据保持一致、图表连续可读。

六大 Tab 深度拆解

SLO Health：错误预算与燃烧率

SLO Health Tab（app.py）围绕 4 个 SLO 指标构建：task-success（任务成功率，目标 99.5%）、p95-latency（P95 延迟，目标 99%）、cost-per-task（单任务成本，目标 98%）、hallucination-rate（幻觉率，目标 95%），与 SDK 中 indicators.py 提供的TaskSuccessRate、CostPerTask、ResponseLatency、HallucinationRate四类 SLI 一一对应。

视图组成：

KPI 指标卡：Total SLOs / Healthy / Warning / Critical / Exhausted 五联卡片，直观反映错误预算健康分布；
Error Budget Burn Rates：为每个 SLO 渲染 1 小时与 6 小时两个燃烧率仪表盘（Gauge）。燃烧率（Burn Rate）= 实际错误率 / 允许错误率，1.0 表示按预期速度消耗预算，大于 1.0 表示消耗过快。源码中的_gauge()函数（app.py）以(2.0, 6.0)为默认阈值分级着色：绿色（<2x）、黄色（2x–6x）、红色（>6x）；
SLO Compliance Timeline：Plotly 折线图展示各 SLO 随时间变化的合规率，并用虚线标出每个 SLO 的目标线（fig_slo.add_hline(y=snap["target"], ...)），偏离目标线的部分一目了然；
Indicator Breakdown：按代理列出成功率、P95 延迟（ms）、单任务成本（$）、幻觉率（%）的数据表。

这些概念与 objectives.py 中ErrorBudget的实现完全对应：burn_rate(window_seconds)在指定窗口内统计错误事件占比与允许错误率的比值，firing_alerts()依据burn_rate_alert=2.0与burn_rate_critical=10.0两个阈值产出 warning/critical 告警——仪表盘上的黄/红状态正是这两档阈值的可视化。

Cost Management：成本护栏与告警

Cost Tab（app.py）回答"代理群今天花了多少钱、谁在超支"：

KPI 卡片：Total Spent Today（今日总花费）、Daily Budget（日预算）、Avg Utilization（平均利用率）、Active Alerts（活动告警）；
Per-Agent Budget Utilization：堆叠横向条形图，绿色代表已花费、灰色代表剩余额度；利用率 >90% 标红、>70% 标黄（与COLOR_CRITICAL/COLOR_WARNING常量对应）；
Top Spenders：消费 Top 5 代理表格；
Cost Trend：按代理分色的成本趋势折线；
Daily Cost Breakdown by Agent：按日分组的堆叠柱状图；
Cost Alerts：带严重级别徽章（🔴 critical / 🟡 warning / 🔵 info）的告警表，告警消息如"Budget exceeded / Approaching limit / Cost recorded for "。

这些模拟告警背后对应 SDK 的 cost/guard.py（CostGuard）——真实的CostGuard支持每任务硬上限、每代理每日上限、组织月度预算、异常检测（Z-score / IQR / EWMA）与自动节流（auto-throttle）甚至 kill switch。仪表盘以可视化的方式呈现了这些护栏的"消费视图"。

Chaos Engineering：主动打破代理

Chaos Tab（app.py）演示混沌工程闭环：

KPI 卡片：Experiments（实验数）、Running（运行中）、Faults Injected（注入故障总数）；
Experiments 列表：以可折叠面板展示每个实验的故障类型（如tool_timeout、llm_degraded、cost_spike）、时长与注入故障数，运行中的实验自动展开（expanded=exp["state"] == "running"）；
Resilience Radar：针对已完成的实验绘制雷达图，四个维度为 Fault Tolerance（故障容忍度）、Recovery Time（恢复时间）、Degradation（劣化程度）、Cost Impact（成本影响）——与 SDK 中ChaosExperiment.calculate_resilience()返回的韧性评分结构一致；
Fault Injection Timeline：用散点条带图（px.strip）把每次故障注入标记在时间轴上，观察故障密度与分布；
Before / After Comparison：对比实验前后成功率、P95 延迟、平均成本的退化程度；
Run Chaos Test 按钮：点击后模拟向support-bot注入tool_timeout故障，带进度条与结果反馈（"Resilience: 78.3%"），完整演示"注入 → 测量 → 评分"的流程。

Incidents：事件管理与 MTTR

Incidents Tab（app.py）围绕 4 个示例事件（INC-1039 ~ INC-1042）展开：

KPI 卡片：Active Incidents、Resolved (window)、MTTR (avg)、P1 Open；
Active Incidents 卡片流：每条事件以左侧彩色边框（P1 红、P2 橙、P3 黄、P4 蓝）展示严重级别、标题、状态（investigating / mitigating / resolved）与代理归属；
Incident Timeline：散点图标记每条事件的 Detected → Acknowledged → Resolved 三个时间点；
MTTR by Severity：按严重级别分组的平均修复时间柱状图；
Signal Correlation：信号（slo_breach、error_budget_exhausted、cost_anomaly、latency_spike、tool_failure_spike）与触发事件 ID 的关联表——这与 SDK incidents/detector.py 中IncidentDetector的信号关联（correlation_window_seconds）概念一致，便于发现"多个事件共享同一根因"的模式。

Progressive Delivery：安全发布代理版本

Delivery Tab（app.py）模拟一次名为deploy-agent-v2.4.0的金丝雀（Canary）发布：

KPI 卡片：Rollout 名称、Strategy（CANARY）、Current Weight（当前流量权重）、Shadow Match（影子模式匹配率）；
Rollout Progress：横向条形图展示 Shadow(0%) → Canary 5% → Canary 25%（active）→ Canary 50%（pending）→ Full rollout(100%) 的五个阶段，绿色=complete、蓝色=active、灰色=pending；
Canary vs Baseline：分组柱状图对比金丝雀与基线版本的成功率、P95 延迟、单任务成本；
Shadow Test Match Rate：仪表盘显示影子模式输出与生产输出的一致率（阈值 90%，>90% 绿色）；
Rollout Event Timeline：事件表记录"Shadow started → Shadow passed (match 95.2%) → Canary 5% started → Canary 5% passed analysis → Canary 25% started"的完整发布节奏。

这套阶段模型与 SDK delivery/ 模块（rollout.py、gitops.py）的渐进式交付能力吻合：影子模式验证 → 小流量金丝雀 → 逐步放量 → 全量发布，每个阶段都有分析闸门（analysis gates）与自动回滚条件（如错误预算燃烧率 >5.0、策略违规 >0、成本异常）。

Policy Heatmap：治理指标密度热力图

README 未提及、但 app.py 中完整实现的第六个 Tab，将治理可观测性纳入同一面板：

视图切换：agent_x_time（代理 × 时间桶）或policy_x_time（策略 × 时间桶），时间桶宽度自适应（1 小时或 4 小时桶，最多 48 列）；
颜色指标：Evaluation Count（评估次数，蓝色系）或 Violation Count（违规次数，红色系）；
内置策略列表：content-safety、rate-limit、cost-budget、pii-filter、tool-access、hallucination-guard、auth-scope、output-filter八类策略；
KPI 条：Total Evaluations、Total Violations（含违规率 delta）、Peak Activity（单桶评估数最高的实体及其时间点）、Violation Rate（相对 5% 基线的偏差）；
分布图与汇总表：评估/违规分布横向条形图，以及按违规总数排序的汇总表（Total Evaluations、Total Violations、Violation Rate、Peak Bucket）。

源码注释明确说明（app.py）：该热力图的数据形态对应 OpenTelemetry 治理指标管道（OTel conventions），模拟数据采用与 OTel exporter 相同的结构生成。结合 integrations/otel 目录下的metrics.py、conventions.py等实现，你可以把它视作把策略评估密度可视化到面板上的参考范式。

配置与交互：侧边栏控制台

仪表盘的交互配置集中在侧边栏（app.py）：

Time range（时间范围）：下拉框选择Last 1 h / Last 6 h / Last 24 h / Last 7 d / Last 30 d，默认 24 小时；数据点数量由N_POINTS = min(HOURS[time_range], 200)决定，长范围自动降采样；
Filter agents（代理过滤）：多选框默认选中全部 8 个代理，所有 Tab 的数据生成都会以selected_agents为输入，实现全局联动过滤；
Auto-refresh（自动刷新）：勾选后每 30 秒自动重载（time.sleep(30); st.rerun()，见 app.py），适合投放到大屏或值班监控场景；
SDK detected：提示当前运行模式。

页面整体采用layout="wide"宽屏布局与plotly_dark深色主题（app.py），状态色板统一：健康绿#2ecc71、警告黄#f1c40f、严重红#e74c3c、预算耗尽紫#8e44ad、信息蓝#3498db。

从模拟到生产：如何对接真实数据

当前仪表盘默认使用模拟数据生成器（gen_slo_data()、gen_cost_data()、gen_chaos_data()、gen_incident_data()、gen_rollout_data()、gen_policy_heatmap_data()），它们的输出结构与 SDK 的真实类型字段对齐，因此替换为真实数据的路径是清晰的：

接入 agent-sre 引擎：安装agent-sre后，用 quickstart.py 等示例中的方式创建真实的SLO、CostGuard、ChaosExperiment、IncidentDetector实例，把take_snapshot()（见 slo/dashboard.py）产出的SLOSnapshot直接喂给仪表盘的 SLO Tab；
对接 OpenTelemetry：agent-sre 原生支持 OTLP 导出（integrations/otel），也可将 Prometheus exporter 的数据写入仪表盘的数据层，替换 Policy Heatmap 的模拟数据源；
保留交互骨架：侧边栏的时间范围、代理过滤与自动刷新逻辑无需改动，只需替换各gen_*函数的内部实现为真实查询。

整个 dashboard 目录是 agent-sre 生态中"开箱即用的可视化参考实现"，与仓库 examples/ 下的cost_guard.py、chaos_test.py、canary_rollout.py等可运行示例互为补充——前者解决"怎么看"，后者解决"怎么用"。对照 agent-sre/README.md 的架构图（SLO Engine → Error Budget → Chaos Engine → Circuit Breaker → Canary Deploy → Cost Guard → Incident Manager 的可靠性生命周期），这个仪表盘正是该生命周期全部环节的统一观测入口。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考