# 10 分钟面试演示脚本

**用途**：面试现场按步骤演示  
**目标**：展示从问题到证据、验证、Trace、反馈的闭环  
**前置条件**：服务以 `mvp-demo` profile 启动

更完整的 runbook 见 [README.md](README.md)，字段检查见 [trace-inspection-checklist.md](trace-inspection-checklist.md)。

## 0. 开场话术

```text
我会演示一个支付超时诊断。
重点不是看模型给出一段答案，而是看这个答案背后的 Agent 执行链路：
Planner 怎么拆解，Executor 调了哪些工具，Verifier 如何判断证据是否支撑答案，以及最终如何通过 sessionId 回放。
```

## 1. 启动服务

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

服务地址：

```text
http://localhost:9900
```

说明：

- `mvp-demo` profile 使用 mock Prometheus 和 mock CLS。
- 演示不依赖真实线上故障。
- MySQL、Redis、Milvus/Zilliz 和模型配置仍需要可用。

## 2. 演示 Chat 诊断

推荐使用固定脚本：

```powershell
powershell -ExecutionPolicy Bypass -File mvp/demo/scripts/run-payment-timeout-demo.ps1
```

脚本会写出：

```text
mvp/demo/output/chat-response.json
mvp/demo/output/trace-response.json
mvp/demo/output/feedback-response.json
```

现场话术：

```text
这里我用固定 sessionId 跑一个支付接口超时问题。
固定 sessionId 的好处是，后面 trace 和 feedback 都能关联到同一次诊断。
```

## 3. 展示用户答案

打开：

```text
mvp/demo/output/chat-response.json
```

重点看：

```text
data.sessionId
data.answer
```

现场话术：

```text
这是用户看到的答案。
但这个项目的重点不是这段文字，而是这段文字是否有证据链。
接下来我用同一个 sessionId 查 trace。
```

## 4. 展示 Trace

打开：

```text
mvp/demo/output/trace-response.json
```

重点看：

```text
data.session.sessionId
data.session.agentFlow
data.steps[*].agentName
data.toolInvocations[*].toolName
data.toolInvocations[*].inputParams
data.toolInvocations[*].outputPreview
data.toolInvocations[*].retrievalLayer
data.toolInvocations[*].relevanceLevel
data.summary.hasVerifierEvaluation
```

现场话术：

```text
这里能看到三个层次：
第一，session 记录了这次诊断的问题、答案、耗时和自评估。
第二，agent_step 记录 Planner、Executor、Verifier 的模型步骤。
第三，tool_invocation 记录真实工具调用，包括 lookup_knowledge、日志和指标。

所以这不是一个黑盒 Chatbot，而是一条可以回放的诊断链路。
```

## 5. 展示知识库检索

在 trace 中找到 `lookup_knowledge`。

重点看：

```text
toolName = lookup_knowledge
inputParams.query
retrievalLayer
l0MatchCount
l1MatchCount
relevanceLevel
retrievalDetails
outputPreview
```

现场话术：

```text
知识库检索保留为显式工具，而不是藏在 Advisor 里。
这样面试官或线上排查人员能看到：Agent 查了什么 query，命中了哪个知识域，检索层是 L0/L1 还是混合，相关性等级是什么。

底层检索现在走 VectorSearchService，优先 Spring AI VectorStore，失败时 fallback 到 Milvus SDK。
```

## 6. 展示 Verifier

在 trace 中查看：

```text
data.session.selfEvaluation
data.summary.hasVerifierEvaluation
```

现场话术：

```text
Verifier 不做新检索，只看工具 trace 汇总。
它会把 Executor 答案里的关键事实拆出来，判断每条事实是 direct_evidence、indirect_support、no_evidence 还是 contradicted。

如果 PASS，就输出原答案。
如果 LOW_CONFID，可以补证据或加低置信提示。
如果 REJECT，就降级输出，只保留已确认信息。
```

## 7. 展示反馈闭环

打开：

```text
mvp/demo/output/feedback-response.json
```

重点看：

```text
success
caseId
```

现场话术：

```text
用户反馈 useful 会写回同一个 diagnosis_session。
后端会把这次诊断自动沉淀到 case_library，后续可以做案例检索或 bad case 分析。

这里 status 和 feedback 是分开的：
status 表示执行是否成功，feedback 表示用户是否认可。
```

## 8. 可选演示 AIOps

如果时间允许，再演示 AIOps payload。

请求示例见：

```text
mvp/demo/README.md
```

现场话术：

```text
AIOps 有两个模式。
有 payload 时进入 PAYLOAD_TARGETED，报告必须聚焦这个告警。
没有 payload 时进入 AUTO_DISCOVERY，先发现活跃告警再排查。

我专门加了 recommended lookup_knowledge query，把 alertName、service、severity、description 等字段稳定送入知识库检索，避免 Agent 随意扩展问题范围。
```

## 9. 结束总结

```text
这个 Demo 展示的是一个完整闭环：

用户问题
-> Agent 规划和执行
-> 显式工具证据
-> Verifier / self_evaluation
-> Trace 回放
-> 用户反馈
-> 案例沉淀

我把重点放在 Agent 工程能力：可追踪、可验证、可回归、可演进。
```

## 10. 如果现场失败

如果模型或外部组件不可用，不要硬跑。可以直接打开上一次输出：

```text
mvp/demo/output/chat-response.json
mvp/demo/output/trace-response.json
mvp/demo/output/feedback-response.json
```

降级话术：

```text
现场环境依赖 MySQL、Redis、Milvus 和模型服务。
如果外部服务不可用，我会用固定输出讲 trace 结构。
因为这个项目的核心不是一次在线请求，而是诊断链路如何被记录、检查和回放。
```