Files
SuperBizAgent-java/mvp/demo/ten-minute-interview-demo.md
T

238 lines
5.4 KiB
Markdown

# 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 结构。
因为这个项目的核心不是一次在线请求,而是诊断链路如何被记录、检查和回放。
```