SuperBizAgent-java/interview/archive/2026-07-24-legacy/story-cases.md

面试故事案例

用途：把项目能力讲成可被面试官理解的工程故事
使用方式：按问题选择一个故事，不需要从头到尾背诵

故事 1：从黑盒 Chatbot 到可追踪 Agent

面试官问题

这个项目和普通调用大模型有什么区别？

30 秒回答

普通 Chatbot 只给最终答案，出了问题很难解释答案怎么来的。
我这个项目把诊断过程拆成 Planner、Executor、Verifier，并把每个 Agent 步骤和每次工具调用落库。
最后通过 Trace API 可以回放：模型怎么规划、调用了哪些工具、工具返回了什么证据、Verifier 怎么判断答案可信。

展开讲法

一开始最容易做的是：用户问题进来，直接让模型回答。但故障诊断场景不能只看答案，因为答案可能看起来合理却没有证据支撑。

所以我把系统拆成三层：

• diagnosis_session 记录一次诊断的主状态和最终答案。
• agent_step 记录 Planner、Executor、Verifier 的模型调用。
• tool_invocation 记录知识库、日志、指标等真实工具证据。

这样就能做到：答案不是孤立文本，而是一条可审计的执行链。

可展示文件

• mvp/architecture/interview-one-pager.md
• mvp/architecture/session-trace-lifecycle.md
• mvp/demo/output/trace-response.json

主动说不足

当前 tool_invocation.step_id 还不是每次都强绑定具体 agent_step，后续可以加 runId 和更严格的 step 关联，让多轮同 session 诊断更清晰。

故事 2：RAG 从自研 SDK 检索迁移到 Spring AI VectorStore

面试官问题

你的 RAG 是怎么设计的？为什么不用框架全包？

30 秒回答

我把 RAG 分成两部分：通用检索基础设施尽量交给 Spring AI VectorStore，业务可观测链路留在项目里。
所以 Agent 仍然显式调用 lookup_knowledge，底层通过 VectorSearchService 走 Spring AI VectorStore，失败时 fallback 到原 Milvus SDK。
这样既能减少自研检索代码，又不会丢失工具调用 trace。

展开讲法

旧实现里，Milvus SDK 查询、topK、filter、score 映射都在业务代码里。它能跑，但后续扩展成本高。

我没有直接把 RAG 隐藏进 Advisor，因为这个项目的核心是 Agent 工程，需要知道 Agent 何时检索、检索了什么、证据怎么支撑诊断。

于是我保留了边界：

Executor -> lookup_knowledge -> VectorSearchService -> VectorStore / SDK fallback

同时把 L0 从“直接返回结果”降级为 domain/entity hint，降低关键词误召回的风险。

可展示文件

• mvp/architecture/rag-architecture.md
• mvp/architecture/retrieval-observability.md
• interview/rag-refactor-story.md

主动说不足

当前还没有完整 hybrid search 和 rerank。
我先做 golden cases、VectorStore 主路径和 SDK fallback，是为了让每一步迁移都能被验证。

故事 3：Verifier 如何降低幻觉风险

面试官问题

Agent 怎么保证不胡说？

30 秒回答

我没有假设模型天然可靠，而是加了 Verifier。
Executor 给出答案后，Verifier 只拿 executor_final_answer 和 tool_trace_summary，不允许做新检索。
它把答案里的关键事实逐条校验，输出 PASS、LOW_CONFID 或 REJECT。
这个结果会写回 self_evaluation，Trace API 可以看到。

展开讲法

Verifier 的关键不是再问一次模型“你觉得对吗”，而是让它基于真实工具调用做 groundedness 检查。

ToolTraceSummaryService 会从 tool_invocation 里整理证据索引，包含：

• 工具名。
• 输入摘要。
• 输出摘要。
• evidence level。
• source invocation ids。

Verifier 输出结构化 JSON，ChatService 根据 verdict 决定是否输出、补证据或降级。

可展示文件

• mvp/architecture/harness-quality-gates.md
• mvp/architecture/feedback-architecture.md
• src/main/resources/prompts/chat-verifier-prompt.md

主动说不足

AIOps 当前还是轻量 rule evaluation，不是完整 LLM Verifier。
这是有意收敛：先用规则保证 payload 聚焦和工具证据使用，后续再加 AIOps LLM Verifier。

故事 4：AIOps 告警为什么要做 payload scope control

面试官问题

AIOps 场景和普通 Chat 有什么区别？

30 秒回答

AIOps 告警有一个很关键的问题：环境里可能同时有很多活跃告警，Agent 容易跑偏。
所以我把 AIOps 分成 PAYLOAD_TARGETED 和 AUTO_DISCOVERY。
如果请求带 alert payload，最终报告必须聚焦输入告警，并且会把 alertName、service、severity、description 拼成 recommended lookup_knowledge query。

展开讲法

没有 payload 时，Agent 可以先查询活跃告警，再选择目标排查。

但有 payload 时，用户已经告诉系统“我要查这个告警”。这时如果 Agent 把其他活跃告警写成主根因，产品体验会很差。

所以我做了两件事：

• Prompt 中明确 PAYLOAD_TARGETED 范围。
• AiOpsRuleEvaluationService 检查最终报告是否聚焦输入告警，以及是否使用证据工具。

可展示文件

• mvp/architecture/agent-orchestration.md
• mvp/architecture/current-mvp-architecture.md
• interview/aiops-query-augmentation.md
• interview/aiops-lightweight-verifier.md

主动说不足

当前 scope control 主要靠 prompt 和规则评估。
后续可以把 AIOps 也接入类似 Chat Verifier 的事实校验，让告警报告的每个根因和建议都有 evidence refs。

故事 5：反馈不是点赞按钮，而是案例沉淀入口

面试官问题

用户反馈在系统里有什么用？

30 秒回答

反馈不只是前端按钮。
用户提交 useful 后，系统会把同一个 diagnosis_session 沉淀为 case_library。
not_useful 不会改执行状态，而是作为 bad case 信号保留。
这样 status、self_evaluation、feedback 三个维度是分开的。

展开讲法

我刻意没有把 not_useful 写成 FAILED。因为失败表示系统执行异常，而用户觉得不好用是质量标签。

当前设计里：

status          -> 执行是否成功
self_evaluation -> 系统自己判断证据和事实支撑度
feedback        -> 用户是否认可

useful 会进入 CaseLibraryService.createFromSession，生成可复用案例。后续可以做相似案例推荐或高质量样本积累。

可展示文件

• mvp/architecture/feedback-architecture.md
• mvp/architecture/data-model.md
• mvp/demo/output/feedback-response.json

主动说不足

当前 case_library 的 rootCause 和 solution 还直接使用完整 answer。
后续应该从报告中结构化抽取 rootCause、solution、errorCode 和 service，提高案例复用质量。

结尾万能总结

这个项目我最想展示的不是某一个模型效果，而是 Agent 工程化能力：
一个诊断答案从哪里来、用了什么证据、是否被验证、用户是否认可、后续怎么沉淀和回归。
这些链路都被结构化记录下来，所以它可以继续演进，而不是一次性 demo。