线上故障排查 Agent · 演示平台

把业务系统第一轮故障诊断
变成可控的工程系统

从用户描述故障,到根因分析报告,全程可观测、可评测、可复盘。
不是聊天机器人,而是工程化的 Agent 系统。
从 Router、Workflow、ToolRegistry,到 Working Memory、Trace、Eval,每个环节都有设计。

核心能力
🔀

Hybrid Router

先用 heuristic 处理确定性信号(trace_id / 504 / 500),高置信直接路由;低置信输入才调 LLM,节省 token 又保持灵活。

🗂

Workflow-First 控制

每条 route 对应显式 workflow,每个 step 声明 allowedTools 白名单。关键路径由代码控制,LLM 是可替换的能力接口。

🧰

Tool Registry

统一注册 resolve_app、日志查询、慢 SQL、表结构、代码问答、restart_service 等工具,并绑定 schema、allowedTools 和 risk level,避免 Agent 乱调用。

🔁

Agent Loop & Self-Correction

工具执行结果反馈到 Policy,Policy 决定继续、收窄重试还是终止。Loop 有三种明确退出条件:completed(满足)、max_iterations(超限)、tool_error(出错),全程写入 Trace 可回溯。

🧾

Working Memory

Agent 的结构化工作记忆。工具调用后先由 evidence_summarizer(小模型)语义压缩,再以带 source / kind / confidence 标注的 EvidenceItem 写入。报告 LLM 只消费高质量摘要,而非原始输出——这是 Context Engineering 的核心实践。

🛡

HITL 人工审批

高风险工具(如 restart_service)进入 pending 状态,run 暂停等待人工 approve / reject,结果写入 Trace 可复盘。

🔒

安全边界

手机号、邮箱、Secret 在进入 LLM / report 前脱敏;日志里的 prompt injection 文本作为数据处理,不作为指令执行。

📊

结构化 Trace

每次 run 保存 JSON trace,含 router decision / tool traces / LLM calls / approvals / evidence / report,支持离线复盘和 eval 回归。

Eval Runner

13 个回归 case 覆盖核心路径、调用链耗时定位、失败降级、脱敏、注入防护和高风险工具审批。eval 检查 route / tool order / evidence keywords / token budget / approval status。

系统设计

控制层架构

LLM 作为可替换能力接入,关键路径由代码显式控制 · 点击左侧卡片内的彩色标签,可展示实现详情

入口
用户输入

自然语言故障描述,支持 trace_id / 错误码 / 服务名 / 时间窗口。CLI 或 POST /api/diagnose 均可。

路由
Hybrid Router

先用 Rule 处理确定性信号,高置信不调 LLM;低置信交给 LLM Router,输出经 zod schema 校验。

Rule LLM Fallback
工作流
Workflow Engine

五条 workflow,每条显式声明 steps[] 和 allowedTools 白名单。ToolRegistry 拒绝白名单外的调用。

trace-diagnosis performance condition-log latency clarification
工具层
ToolRegistry + ApprovalPolicy

工具统一注册,metadata 含 risk level。low/medium 自动审批;high/critical 由风险策略自动触发 HITL 暂停。

resolve_app query_logs_by_trace_id query_logs_by_condition query_mysql_slow_log query_table_schema ask_codebase restart_service
Working Memory / 安全
Working Memory + Redaction + Prompt Injection Guard

Agent 的结构化工作记忆。工具结果经 evidence_summarizer 语义压缩后以结构化 EvidenceItem 写入,控制送入 LLM 的 context 质量。手机号、邮箱、Secret 进 LLM 前脱敏;日志中的 prompt injection 文本作为数据处理。

redaction injection guard
报告
Report Generator

基于 Working Memory 生成结构化报告。默认 mock,配置 LLM_MODE=openai 后走 OpenAI-compatible API。

mock mode openai-compatible
可观测
TraceStore + Eval Runner

每次 run 保存完整 JSON trace。Eval Runner 对核心路径做回归检查。

JSON trace eval replay
← 点击左侧卡片内的彩色标签,展示详情
例如 heuristicperformancerestart_service
Demo Cases
troubleshooting-agent · harness v3
Run Summary idle
Workflow
trace-diagnosis有 trace_id,精确查链路日志
performance504 / timeout,走性能排查路径
condition-log有错误码但无 trace_id,条件查日志
clarification信息不足,追问用户补充上下文
-
Problem
-
Router
Rule启发式规则直接路由,高置信,不消耗 LLM token
LLM输入模糊,调用 LLM 判断路由方向
FallbackLLM 置信不足,降级到追问 workflow
-
Confidence
≥ 0.85高置信,Rule 直接路由,不调 LLM
0.45–0.85中置信,交给 LLM Router 判断
< 0.45低置信,LLM 也判断不了,降级追问
-
Tool Path 0
  • 暂无工具调用
Working Memory 0
  • 暂无记录

Eval Coverage

13 个回归 Case 覆盖什么

这组离线回归使用 mock adapter,将 Agent 的关键风险拆成可复现检查: 诊断路径、路由成本、Agent Loop、失败降级、安全边界、高风险控制。 真实模型质量使用独立在线评测,不与这里的通过率混报。

13/13
Offline Regression
6
Coverage Groups
5
Route Checks
7
Tool Checks

Eval 检查维度

每个 case 都从 trace 中抽取 route、tool order、working memory keywords、confidence、LLM token budget、tool status、approval status 做断言。

route · tool order · working memory · confidence · token budget · approval

项目演进

从 Workflow 到 Agent Harness

三轮迭代,每轮解决一个工程化问题

V1 AI 辅助的硬编码 Workflow

验证 AI 辅助排障的可行性。把故障排查拆成固定步骤,调用 Claude Code CLI 做根因分析,Streamlit 展示结果。

  • 固定流程:trace_id → 查日志 → 分析异常栈 → 定位代码 → 生成报告
  • 证明了故障排查可以被拆成可重复 workflow
  • 日志 + 异常栈 + 源码 + LLM 可以组合成工程师可读的诊断报告
问题:workflow 写死,工具职责耦合,没有结构化 trace 和 eval,LLM 调用缺少 timeout / fallback。
V2 基于 agno 的 Tool-Using Agent

使用 Agent 框架快速验证 tool-using 形态。把排障步骤拆成工具,由 Agent 根据自然语言选择调用顺序。

  • 自然语言入口替代固定表单,更符合真实排障方式
  • 工具列表 + instructions 验证 tool-using 方向可行
  • 前端双栏 workbench 展示工具路径和证据摘要
问题:控制权在框架和 prompt 中,关键路径不显式;工具选择依赖 Agent 行为,难以限制;安全边界和 eval 不成体系。
V3 Workflow-First Lightweight Agent Harness

把控制层拿回来。LLM 作为可替换能力接入,关键路径由代码显式控制。

  • Hybrid Router:heuristic 优先,低置信才调 LLM,输出经 zod 校验
  • Workflow 显式声明 allowedTools,ToolRegistry 拒绝白名单外调用
  • Agent Loop:显式三种终止条件(completed / max_iterations / tool_error),终止原因写入 Trace
  • Self-Correction Policy:工具返回 too_many_results 时在 loop 内收窄重试,可复现可 eval
  • HITL Pending-Resume:高风险工具进入 waiting_approval,approve/reject 写入 trace
  • Redaction + Prompt Injection Guard:安全边界由代码保证
  • Eval Runner:13 个离线回归 case,覆盖核心路径 + 调用链耗时定位 + 失败路径 + Agent Loop + 安全边界 + 高风险工具控制
核心认知:Agent 的价值不在于"调了 LLM",而在于把不确定的排障流程变成可控、可观测、可评测的工程系统。