Files
SuperBizAgent-java/interview/demo-script.md
T

4.2 KiB
Raw Blame History

Interview Demo Script

30 秒开场

这是一个 Agent Engineering 项目,场景是企业故障诊断。它支持两类入口:用户主动提问的 Chat 诊断,以及告警事件驱动的 AIOps 诊断。项目重点不是单次回答,而是把多 Agent 执行、工具证据、Verifier 评估、最终报告和反馈都沉淀成可回放的 trace。

Demo 准备

启动服务:

mvn spring-boot:run "-Dspring-boot.run.profiles=mvp-demo"

确认服务地址:

http://localhost:9900

mvp-demo profile 下:

  • Prometheus 告警使用 mock 数据。
  • CLS 日志使用 mock 数据。
  • MySQL、Redis、Milvus/Zilliz 和模型配置仍使用当前项目配置。

Demo 1: Chat 诊断

目标:展示普通用户问题如何进入多 Agent 诊断、调用工具、经过 Verifier,并生成 trace。

请求:

$sessionId = "interview-chat-payment-timeout-001"
$body = @{
  Id = $sessionId
  Question = "支付接口最近出现超时,请结合知识库、日志和指标判断可能原因,并给出修复建议。"
} | ConvertTo-Json

Invoke-RestMethod `
  -Method Post `
  -Uri "http://localhost:9900/api/chat" `
  -ContentType "application/json" `
  -Body $body

讲解点:

  • ChatController 把请求交给 ChatService.executeChatWithStrategy(...)。
  • 简单问题走单 ReactAgent,复杂问题走 Planner -> Executor -> Verifier。
  • Executor 可以调用知识库、日志、指标等工具。
  • Verifier 会基于工具证据生成 groundedness 评估。
  • 最终会写入 diagnosis_session、agent_step、tool_invocation。

查询 trace:

Invoke-RestMethod `
  -Method Get `
  -Uri "http://localhost:9900/api/diagnosis/$sessionId/trace"

展示点:

  • data.session.agentFlow = CHAT
  • data.steps 中能看到 planner/executor/verifier
  • data.toolInvocations 中能看到证据工具
  • data.session.selfEvaluation 中有 verifier 结果

Demo 2: AIOps 告警诊断

目标:展示告警 payload 如何触发 AIOps 入口,并且报告只聚焦目标告警。

请求:

$aiopsSessionId = "interview-aiops-payment-cpu-001"
$aiopsBody = @{
  sessionId = $aiopsSessionId
  alertName = "HighCPUUsage"
  service = "payment-service"
  severity = "P1"
  description = "服务 payment-service 的 CPU 使用率持续超过 80%,当前值为 92%。实例: pod-payment-service-7d8f9c6b5-x2k4m。"
  timeRange = "last_15m"
  userRequest = "请结合 Prometheus 活动告警、system-metrics 日志和知识库生成告警分析报告。"
} | ConvertTo-Json

Invoke-WebRequest `
  -Method Post `
  -Uri "http://localhost:9900/api/ai_ops" `
  -ContentType "application/json" `
  -Body $aiopsBody

讲解点:

  • /api/ai_ops 接受可选 AIOpsRequest。
  • 首条 SSE 消息会返回 type=session。
  • AiOpsService 根据 payload 判断模式:
    • PAYLOAD_TARGETED:聚焦传入告警。
    • AUTO_DISCOVERY:没有 payload 时先查 active alerts。
  • AIOps 暂时不加 Verifier,先保证告警入口、证据工具和 trace 可用。

查询 trace:

Invoke-RestMethod `
  -Method Get `
  -Uri "http://localhost:9900/api/diagnosis/$aiopsSessionId/trace"

展示点:

  • data.session.agentFlow = AI_OPS
  • data.session.answer 有最终告警报告
  • data.toolInvocations 有 query_metrics、query_logs、lookup_knowledge
  • 报告有 HighCPUUsage/payment-service 的完整根因分析
  • 其他 active alerts 只作为相关风险出现,不展开成独立根因章节

MySQL 验证

python scripts/query_mysql.py "SELECT session_id, agent_flow, status, step_count, tool_call_count FROM diagnosis_session ORDER BY id DESC LIMIT 5"
python scripts/query_mysql.py "SELECT tool_name, COUNT(*) AS cnt FROM tool_invocation WHERE session_id='interview-aiops-payment-cpu-001' GROUP BY tool_name"

收尾总结

这套 Demo 展示的是一个完整 Agent 系统,而不是一次模型问答:入口有明确场景边界,Agent 负责规划和执行,工具提供证据,Verifier 提供质量门,trace API 提供审计和复盘能力。AIOps 入口进一步证明它可以从用户问答扩展到事件驱动诊断。