6.0 KiB
6.0 KiB
10 分钟面试演示脚本
用途：面试现场按步骤演示
目标：展示从问题到证据、验证、Trace、反馈的闭环
前置条件：服务以 mvp-demo profile 启动
更完整的 runbook 见 README.md，字段检查见 trace-inspection-checklist.md。
0. 开场话术
我会演示一个支付超时诊断。
重点不是看模型给出一段答案，而是看这个答案背后的 Agent 执行链路：
Planner 怎么拆解，Executor 调了哪些工具，Verifier 如何判断证据是否支撑答案，以及最终如何通过 sessionId 回放。
1. 启动服务
mvn spring-boot:run "-Dspring-boot.run.profiles=mvp-demo"
服务地址：
http://localhost:9900
说明：
mvp-demoprofile 使用 mock Prometheus 和 mock CLS。- 演示不依赖真实线上故障。
- MySQL、Redis、Milvus/Zilliz 和模型配置仍需要可用。
2. 演示 Chat 诊断
推荐使用固定脚本：
powershell -ExecutionPolicy Bypass -File mvp/demo/scripts/run-interview-demo-check.ps1
脚本会写出：
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
现场话术：
这里我用固定 sessionId 跑一个支付接口超时问题。
固定 sessionId 的好处是保留多轮上下文；每次诊断还会返回 runId，后面 trace 和 feedback 都用这个 runId 精确关联到同一次运行。
3. 展示用户答案
打开：
mvp/demo/output/chat-response.json
重点看：
data.sessionId
data.runId
data.answer
现场话术：
这是用户看到的答案。
但这个项目的重点不是这段文字，而是这段文字是否有证据链。
接下来我用同一个 sessionId 加 runId 查 trace。
4. 展示 Trace
打开：
mvp/demo/output/trace-response.json
重点看：
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
现场话术：
这里能看到三个层次：
第一，session 记录了这次诊断的问题、答案、耗时和自评估。
第二，agent_step 记录 Planner、Executor、Verifier 的模型步骤。
第三，tool_invocation 记录真实工具调用，包括 lookup_knowledge、日志和指标。
所以这不是一个黑盒 Chatbot，而是一条可以回放的诊断链路。
5. 展示知识库检索
在 trace 中找到 lookup_knowledge。
重点看：
toolName = lookup_knowledge
inputParams.query
retrievalLayer
l0MatchCount
l1MatchCount
relevanceLevel
retrievalDetails
outputPreview
现场话术：
知识库检索保留为显式工具，而不是藏在 Advisor 里。
这样面试官或线上排查人员能看到：Agent 查了什么 query，命中了哪个知识域，检索层是 L0/L1 还是混合，相关性等级是什么。
底层检索现在走 VectorSearchService，优先 Spring AI VectorStore，失败时 fallback 到 Milvus SDK。
6. 展示 Verifier
在 trace 中查看：
data.session.selfEvaluation
data.summary.hasVerifierEvaluation
现场话术：
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. 展示反馈闭环
打开：
mvp/demo/output/feedback-response.json
重点看：
success
caseId
现场话术：
用户反馈 useful 会写回当前 diagnosis_run。
后端会把这次诊断自动沉淀到 case_library，后续可以做案例检索或 bad case 分析。
这里 status 和 feedback 是分开的：
status 表示执行是否成功，feedback 表示用户是否认可。
8. 可选演示 AIOps
如果时间允许，再演示 AIOps payload。
请求示例见：
mvp/demo/README.md
现场话术：
AIOps 有两个模式。
有 payload 时进入 PAYLOAD_TARGETED，报告必须聚焦这个告警。
没有 payload 时进入 AUTO_DISCOVERY，先发现活跃告警再排查。
我专门加了 recommended lookup_knowledge query，把 alertName、service、severity、description 等字段稳定送入知识库检索，避免 Agent 随意扩展问题范围。
9. 结束总结
这个 Demo 展示的是一个完整闭环：
用户问题
-> Agent 规划和执行
-> 显式工具证据
-> Verifier / self_evaluation
-> Trace 回放
-> 用户反馈
-> 案例沉淀
我把重点放在 Agent 工程能力：可追踪、可验证、可回归、可演进。
10. 如果现场失败
如果模型或外部组件不可用，不要硬跑。可以直接打开上一次输出：
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
降级话术：
现场环境依赖 MySQL、Redis、Milvus 和模型服务。
如果外部服务不可用，我会用固定输出讲 trace 结构。
因为这个项目的核心不是一次在线请求，而是诊断链路如何被记录、检查和回放。