Files
SuperBizAgent-java/mvp/architecture/archive/2026-07-22-legacy/data-model.md
T

5.4 KiB
Raw Blame History

数据模型总览

更新日期:2026-07-10 状态:当前可运行架构

1. 定位

本文从架构角度说明当前 MVP 的核心数据模型。详细字段以 Flyway migration、实体类和 mvp/tables/ 为准。

核心数据分三组:

  • 会话与诊断 Trace:chat_session、diagnosis_run、agent_step、tool_invocation
  • 知识库:api_document、knowledge_domain、Milvus/Zilliz metadata
  • 反馈沉淀:case_library

diagnosis_session 仍保留为历史兼容和回滚表,不再是新执行写入的主模型。

2. 总体关系

erDiagram
    chat_session ||--o{ diagnosis_run : owns
    diagnosis_run ||--o{ agent_step : has
    diagnosis_run ||--o{ tool_invocation : has
    diagnosis_run ||--o| case_library : creates_when_useful
    api_document ||--o{ milvus_chunk : indexed_as
    knowledge_domain ||--o{ api_document : groups

    chat_session {
        bigint id
        varchar session_id
        varchar status
        int message_pair_count
        datetime last_active_at
        datetime expires_at
    }

    diagnosis_run {
        bigint id
        varchar run_id
        varchar session_id
        text query
        varchar status
        varchar agent_flow
        longtext answer
        json self_evaluation
        varchar feedback
    }

    agent_step {
        bigint id
        varchar session_id
        varchar run_id
        int step_index
        varchar agent_name
        text model_input
        text model_output
        boolean has_tool_call
    }

    tool_invocation {
        bigint id
        varchar session_id
        varchar run_id
        bigint step_id
        varchar tool_name
        json input_params
        text output_preview
        json retrieval_details
    }

    case_library {
        bigint id
        varchar case_id
        varchar diagnosis_id
        varchar source_type
        varchar fault_category
        text root_cause
        text solution
    }

说明:Milvus/Zilliz collection 不是 MySQL 表,图中的 milvus_chunk 是逻辑模型。

3. 会话与运行模型

chat_session

chat_session 是会话目录表,保存 sessionId 的元数据:

字段 说明
session_id 外部会话 ID,用于多轮上下文和 run 列表
status 会话目录状态
message_pair_count Redis 对话轮次数快照
last_active_at 最近活跃时间
expires_at 可为空的目录 TTL 元数据

它不保存完整对话历史,正文消息仍由 Redis SessionContext.messageHistory 管理。

diagnosis_run

diagnosis_run 是一次可回放诊断执行的主记录:

字段 说明
run_id 运行 ID,格式为 run- + UUID
session_id 所属 chat_session.session_id
query 本次 Chat 问题或 AIOps 告警摘要
status 本次执行状态
agent_flow CHAT / AI_OPS
answer 本次运行最终答复或告警报告
self_evaluation 本次运行的 rule/verifier/aiops 自评估容器
feedback 本次运行的用户反馈

同一个 sessionId 可以有多个 runId。Trace、反馈、评测和案例沉淀都应优先使用 runId,避免多轮同 session 下的数据混合。

4. Trace 明细模型

agent_step

agent_step 记录模型调用步骤。新写入同时保留 session_id 和 run_id,其中 run_id 是回放边界。Trace 页面和评测应先按 run_id 隔离取数,展示顺序以 Trace API 返回顺序为准。

tool_invocation

tool_invocation 记录显式工具调用事实。retrieval_details.evidence_refs 是 Chat 证据链路的关键字段:

{
  "evidence_status": "supported",
  "evidence_refs": [
    {
      "raw_path": "$.logs[0]",
      "text": "2026-07-08 23:05:28 ERROR order-service HikariPool-1 - Connection is not available..."
    }
  ]
}

$.no_evidence 只表示“本次工具查询未检索到匹配证据”,不能被解释为“问题不存在”或“根因已排除”。

5. 反馈沉淀模型

useful 反馈会触发 CaseLibraryService.createFromRun。

当前自动映射:

字段 来源
case_id UUID
diagnosis_id 新数据为 diagnosis_run.run_id;历史数据可能为 diagnosis_session.session_id
source_type AUTO
fault_category 当前默认 GENERAL
title run query 前 100 字符
root_cause run answer
solution run answer
created_by system

6. self_evaluation 结构

diagnosis_run.self_evaluation 是运行级 JSON 容器:

{
  "rule_evaluation": {},
  "verifier_evaluation": {},
  "aiops_rule_evaluation": {}
}

Chat 通常写入 rule_evaluation 和 verifier_evaluation;AIOps 写入 aiops_rule_evaluation。

7. 当前边界和后续

当前边界:

  • chat_session 只存会话元数据,不存完整正文历史。
  • diagnosis_run 存一次运行的长期审计状态。
  • agent_step.run_id 和 tool_invocation.run_id 是 Trace、Verifier、Eval 的运行边界。
  • 当前实现主要使用逻辑关联,不依赖数据库外键。
  • case_library.diagnosis_id 是过渡字段,新值按 run_id 解释,旧值可能按 session_id 解释。
  • diagnosis_session 只作为历史兼容和回滚表保留。

后续可增强:

  1. 强化 tool_invocation.step_id 关联。
  2. 将 Gatekeeper 规则配置化时的规则元数据保存为可审计版本。
  3. 将 case_library 的 rootCause/solution 从完整 answer 中结构化抽取。