SuperBizAgent-java/interview/archive/2026-07-24-legacy/design-tradeoffs.md

关键设计取舍

1. 为什么先做 Trace，而不是只返回答案

普通 Chatbot 只关注最终回答，但故障诊断更需要可审计性。一次诊断至少要回答：

• 结论是什么。
• 证据来自哪里。
• 哪些步骤由哪个 Agent 完成。
• 如果答案不可靠，系统怎么降级。

因此项目把一次会话拆成：

• diagnosis_session：会话摘要、最终答案、自评估、用户反馈。
• agent_step：模型输入输出、耗时、token 和工具调用标记。
• tool_invocation：真实工具调用参数、输出预览、成功状态和检索元数据。

代价是实现复杂度上升，收益是可回放、可调试、可演示。

2. 为什么 RAG 不直接隐藏在 Advisor 里

Spring AI Advisor 可以让 RAG 更隐式，但本项目的核心是 Agent 证据链。lookup_knowledge 必须作为显式工具调用出现，这样 Trace 里才能看到：

• Agent 什么时候决定检索。
• 用了什么 query。
• 命中了哪些文档。
• 相关性等级是什么。
• 证据如何支撑最终答案。

所以当前设计是：

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

这牺牲了一点框架自动化，但保留了可审计性。

3. 为什么 L0 只做 hint，不直接返回

旧版 L0 关键词唯一命中时可能直接跳过 L1。这个策略速度快，但风险是：关键词子串命中不等于最终语义相关。

当前改成：

L0 = domain/entity hint
L1 = semantic retrieval
postprocess = evidence shaping + trace

L0 仍然有价值：错误码、服务名、告警名、指标名都很适合做精确 hint。但最终证据仍需要 L1 和后处理支撑。

4. 为什么保留 Milvus SDK fallback

Spring AI VectorStore 是当前读路径主方向，但 SDK fallback 没有删除，原因有三点：

• 迁移安全：旧 SDK 路径已经被验证过。
• 运行韧性：VectorStore 配置、schema、collection 出问题时可以回退。
• 面试稳定：检索抽象迁移不应该破坏主 demo。

这不是“没有迁完”，而是分阶段迁移：先稳定读路径，再决定是否迁移写入和索引。

5. 为什么 Chat 有 Verifier，AIOps 先用规则评估

Chat 问题更开放，容易出现跨领域推理，所以需要 LLM Verifier 做 groundedness 校验。

AIOps 当前优先解决更具体的问题：

• 最终报告是否存在。
• payload 模式是否聚焦输入告警。
• 是否使用了证据工具。
• 是否把无关活跃告警展开成主根因。

这些用规则就能稳定检查。后续可以在同一个 self_evaluation 容器下增加 AIOps LLM Verifier。

6. 为什么 AIOps payload scope 先用 Prompt + Rule

真实告警环境里可能同时有多个 active alerts。用户传入 HighCPUUsage/payment-service 时，Agent 如果把所有告警都展开分析，报告会跑偏。

当前选择：

• Prompt 中加入 PAYLOAD_TARGETED。
• 从 payload 生成 recommended lookup_knowledge query。
• 用 AiOpsRuleEvaluationService 检查报告是否聚焦输入告警。

没有先做硬过滤，是因为有些相关告警可以作为风险背景。目标不是屏蔽上下文，而是控制主诊断对象。

7. 为什么反馈不改 status

status 表示执行状态，feedback 表示用户评价。一个执行成功但用户觉得没用的诊断，应该是：

status = SUCCESS
feedback = not_useful

这样才能区分系统异常和质量问题。useful 反馈会沉淀 case_library，not_useful 作为 bad case 信号保留。

8. 可以主动承认的限制

• AIOps 还没有完整 LLM Verifier。
• RAG 还没有 hybrid search、rerank、邻居 chunk 扩展。
• case_library 的 rootCause/solution 仍需要结构化抽取。
• tool_invocation.step_id 关联还可以更严格。
• mvp-demo profile 使用 mock 日志和指标，主要服务稳定面试演示。

主动讲清这些限制，能体现工程判断：先把可追踪闭环打通，再逐步增强质量门和生产可靠性。