246 lines
5.9 KiB
Markdown
246 lines
5.9 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-interview-demo-check.ps1
|
|
```
|
|
|
|
脚本会写出：
|
|
|
|
```text
|
|
mvp/demo/output/chat-response.json
|
|
mvp/demo/output/trace-response.json
|
|
mvp/demo/output/feedback-response.json
|
|
mvp/demo/output/interview-demo-summary.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
|
|
data.session.selfEvaluation.verifier_evaluation.prompt_audit.version
|
|
data.session.selfEvaluation.verifier_evaluation.gatekeeper_result.rule_set_version
|
|
```
|
|
|
|
现场话术：
|
|
|
|
```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，就降级输出，只保留已确认信息。
|
|
|
|
Prompt 和 Gatekeeper 的版本也会进入 trace。
|
|
`prompt_audit.version` 用于说明本次 Chat 使用哪套 Prompt 契约，`gatekeeper_result.rule_set_version` 用于说明引用验真的规则版本。
|
|
固定 fixture baseline 是回归判断来源，live demo 主要证明当前环境链路可跑通。
|
|
```
|
|
|
|
## 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
|
|
mvp/demo/output/interview-demo-summary.json
|
|
```
|
|
|
|
降级话术：
|
|
|
|
```text
|
|
现场环境依赖 MySQL、Redis、Milvus 和模型服务。
|
|
如果外部服务不可用，我会用固定输出讲 trace 结构。
|
|
因为这个项目的核心不是一次在线请求，而是诊断链路如何被记录、检查和回放。
|
|
```
|