生产仪表盘设计
1. 定义与边界
生产仪表盘是面向不同角色展示 Agent 质量、稳定性、成本、安全和用户反馈的可视化入口。它不是把所有指标堆在一页,而是帮助团队快速判断系统是否健康、问题在哪里、是否需要行动。
2. 为什么重要
Agent 的健康状态不能只看服务 200 率。一个系统可能 API 正常,但任务成功率下降、人工接管上升、成本暴涨或高风险工具被频繁拒绝。仪表盘要把这些信号放在同一张生产视图里。
3. 核心机制
建议按角色设计:
| 角色 | 关注指标 |
|---|---|
| On-call 工程师 | 错误率、延迟、依赖、告警、trace 示例 |
| Agent 开发者 | 任务成功、失败原因、工具错误、回归变化 |
| 产品负责人 | 解决率、用户反馈、转人工、业务结果 |
| 安全负责人 | 越权调用、注入命中、敏感数据访问、高风险动作 |
| FinOps | token、费用、单位成功成本、预算消耗 |
4. 工程实现
核心面板结构:
Overview
- Task Success Rate
- Error Rate
- P95 Latency
- Cost per Successful Task
- Unsafe Action Count
Quality
- by task_type
- by agent_version
- by failure_reason
Tooling
- tool call volume
- tool error rate
- policy denial rate
- top slow tools
Cost
- token by model
- cost by task_type
- retry cost ratio
Safety
- prompt injection detections
- high-risk tool calls
- data exfiltration blocks
5. 生产实践
- 首页只放能驱动行动的指标,细节放 drill-down。
- 每个异常图表应能跳转到 trace 样本。
- 指标按 agent_version 和 prompt_version 切分,便于判断发布影响。
- 使用 SLO、预算和基线,而不是只看当前绝对值。
6. 常见反模式
- 仪表盘有很多图,但没有 owner 和阈值。
- 只展示系统指标,不展示任务成功和安全。
- 不能从指标跳转到 trace,定位仍需手工拼日志。
- 指标命名不稳定,跨版本无法比较。
7. 评测方法
| 检查项 | 标准 |
|---|---|
| Actionability | 指标异常后是否知道下一步 |
| Drill-down | 能否从总览进入 trace 和失败案例 |
| Coverage | 质量、成本、延迟、安全、反馈是否齐全 |
| Freshness | 数据延迟是否满足 on-call 需要 |
| Role Fit | 不同角色是否有对应视图 |
8. 安全与治理
仪表盘访问要分级。普通产品视图不应展示敏感 prompt、工具参数或用户信息;安全和审计视图要有访问记录。
9. 权威资料
- OpenTelemetry metrics: https://opentelemetry.io/docs/concepts/signals/metrics/ (核对日期:2026-05-09)
- OpenTelemetry traces: https://opentelemetry.io/docs/concepts/signals/traces/ (核对日期:2026-05-09)
- LangSmith Observability docs: https://docs.langchain.com/langsmith/observability (核对日期:2026-05-09)
- Google SRE Workbook - Alerting on SLOs: https://sre.google/workbook/alerting-on-slos/ (核对日期:2026-05-09)
16. 主控验收清单
- 是否总览页能在 1 分钟内判断是否用户受影响。
- 是否质量、成本、安全、工具、平台都有独立视图。
- 是否每个图表都有 owner 和数据来源。
- 是否能按 agent_version、prompt_version、tool_version 过滤。
- 是否有 P95/P99,而不是只有平均值。
- 是否展示错误预算或 SLO 状态。
- 是否展示安全事件和高危工具审批。
- 是否隐藏 prompt 全文、用户输入和工具明文参数。
- 是否所有 page 告警都能跳转 runbook。
- 是否能从仪表盘跳转到 trace。
- 是否展示数据延迟和采样率。
- 是否定期清理无人使用的图表。
- 是否有发布前后的版本对比面板。
10. 二次精修:Agent 生产仪表盘布局
仪表盘要按值班决策设计,而不是把所有指标堆在一页。
| 面板 | 核心图表 | 主要用户 |
|---|---|---|
| 总览 | SLO、错误预算、今日成本、安全事件 | 值班和负责人 |
| 质量 | TSR、负反馈、人工接管、回归趋势 | 产品和工程 |
| 工具 | 工具调用量、错误率、P95、审批率 | 平台工程 |
| 成本 | cost per success、token、预算 burn | FinOps/负责人 |
| 安全 | forbidden tool、PII、policy decision | 安全和审计 |
| 平台 | queue lag、worker、trace drop | SRE |
11. 仪表盘数据模型
dashboard_dimensions:
required:
- agent_id
- agent_version
- prompt_version
- model
- tool_name
- tenant_id
- risk_level
- environment
protected:
- user_id
- raw_prompt
- tool_args
12. 值班视图
| 问题 | 需要看到 |
|---|---|
| 用户是否受影响 | TSR、P95、错误率、投诉 |
| 是否安全事件 | unsafe action、policy deny、PII |
| 是否成本事故 | cost per success、预算 burn |
| 哪个版本引入 | agent/prompt/tool/model 维度 |
| 能否回滚 | 最近发布、灰度比例、回滚按钮或 runbook |
| 是否观测缺失 | trace/log drop、字段完整率 |
13. 仪表盘反模式
- 只看 HTTP 指标,不看任务成功和工具错误。
- 所有指标混在同一页,值班时找不到关键问题。
- 没有版本维度,无法判断发布影响。
- 暴露完整 prompt、用户输入和工具参数。
- 只有平均值,没有 P95/P99 和失败切片。
- 没有 runbook 链接,告警后仍靠人猜。
14. 验收指标
| 指标 | 目标 |
|---|---|
| Dashboard Load Time | 值班可快速打开 |
| Critical Panel Coverage | SLO/安全/成本/工具/队列齐全 |
| Version Slice Coverage | 可按版本定位 |
| Sensitive Field Exposure | 目标 0 |
| Runbook Link Coverage | page 级告警 100% |
| Decision Time | 从告警到定位缩短 |
15. 补充权威资料
- OpenTelemetry metrics: https://opentelemetry.io/docs/concepts/signals/metrics/ (核对日期:2026-05-09)
- Google SRE Workbook - Alerting on SLOs: https://sre.google/workbook/alerting-on-slos/ (核对日期:2026-05-09)