OpsPilot 智能运维诊断平台

展示重点

这页先看中文功能流程，再看真实控制台截图。重点不是“Agent 会调用工具”，而是每一步在页面上能看到什么输入、什么证据、什么结论和什么人工动作。

固定故障 -> 事故队列 -> 只读诊断 -> 指标 / 日志 / 调用链 / 运行手册
        -> 根因假设 + 证据引用 -> 报告与审计 -> 人工接手

The project is a local diagnosis lab, not an autonomous remediation system. Every conclusion must cite stored evidence, and every production action remains outside the Agent boundary.

实现细节

演示先从故障实验室开始。这里列出下游超时、数据库连接池耗尽、Redis 延迟和配置不一致四类固定场景，并把服务、预期症状、已记录结果和预期根因放在同一张表里。

进入事故工作台后，左侧按风险排列四条事件。选择“订单网关下游超时”后，右侧能直接看到事件摘要、严重级别、状态、根因假设和工具审计，不需要在多个系统之间切换。

点击“运行只读诊断”后，Agent 最多进行 12 次受限读取。Prometheus 指标、Loki 日志、Tempo 调用链和运行手册会作为独立 evidence item 写入时间线，模型只能返回引用 evidence ID 的结构化假设。

如果证据不足，诊断状态会明确返回 needs_more_evidence；证据足够时，页面显示领先假设、置信度、支持证据和工具调用结果。平台 API 再把诊断会话、20 条证据、4 个假设和 20 条工具审计记录保存到 PostgreSQL。

值班工程师最后填写姓名和接手说明。确认后只更新负责人、状态和审计时间线，不触发重启、回滚、扩容或配置修改；没有配置模型时，页面也会明确显示 bounded-fallback。

OpsPilot's Java workload provides four lab faults: downstream timeout, database-pool exhaustion, Redis latency and configuration mismatch. Each scenario has a deterministic trigger, expected metric symptom, log evidence and root cause.

The Agent reads incident context first, then allowlisted Prometheus metrics, Loki logs and Tempo traces; calls are capped at 12 and query windows and payload sizes are bounded. The model can return only structured hypotheses with evidence IDs.

The Platform API stores diagnosis sessions, evidence, hypotheses, tool calls and audit events in PostgreSQL. Repeated requests are idempotent by correlation ID, and secret-like fields are rejected or redacted.

All four faults passed end-to-end verification: four diagnosis sessions, 20 evidence items, four hypotheses and 20 tool-call audit records were persisted, with no remediation triggered.

The Vue workbench keeps the incident, Agent judgement, evidence basis, audit trail and human acknowledgement in one reading path. Without a configured provider it explicitly reports bounded-fallback instead of pretending a model ran.