group_xinghuo_jinrong/docs/项目框架设计/表设计/00-架构总览.md

四 Agent 数据库底座 · 架构总览（可读版）

写给：项目经理、产品、刚接手的开发
目的：说明 四个 Agent 并行开发时，数据存哪儿、谁写谁读、为什么要分 L0~L3 画像
技术细节（建表 SQL、Redis Key）见同目录其他文件。

---

⭐ 要先搭底座？看这一份

按「多 Agent 一起用」划分的完整清单（含 16 表 × 4 Agent 矩阵）：
👉 05-多Agent共用底座清单.md

你要建的	包含什么	SQL
共用底座（先建）	MySQL 11 张 + Redis 会话/画像 + Milvus 产品库 + Neo4j	01-mysql-共用底座.sql
各 Agent 专用（后建）	MySQL 5 张	02-mysql-agent专用.sql
技术栈与版本	组件版本、Windows 原生部署	01-技术栈与版本.md
业务记忆管理	短期/长期记忆、Redis vs SQL vs 图 vs 向量	业务记忆管理手册.md

---

先读这一页：这份文档在讲什么？

我们要做 4 个智能助手（Agent），服务 4 类人：

Agent	给谁用	干什么（一句话）
客户财富	买理财的客户	查持仓、看产品规则、亏多了提醒一下
代理人助手	一线理财经理	查客户情况、查产品规则、帮忙起草合规话术
数据分析	公司内部同事	用大白话问数据，系统查库后用普通话回答
风控监测	风控专员	大额/异常交易预警，买不匹配的产品要拦住

四个 Agent 不互相「打电话」问 AI，而是 往同一套数据库里读写。
这样四个组可以 同时开发，只要事先约定好 哪张表谁写、谁只能读。

---

五种「仓库」分别是干什么的？

可以把它想成 五种不同用途的仓库：

仓库	技术名	通俗理解	里面主要放什么	丢了会怎样
短期记事本	Redis	对话时临时用的草稿纸	最近几轮聊天、刚查过的客户画像副本	丢了可以从 MySQL 恢复，只是慢一点
正式档案柜	MySQL	必须长期保存、能审计的记录	聊天记录归档、客户画像、预警单、合规审计	不能丢，监管和纠纷都要查
产品说明书索引	Milvus	按意思搜文档（向量检索）	基金产品手册、交易规则、内部办事流程	更新了重新导入即可
关系图谱	Neo4j	「谁持有啥、谁管谁」的关系图	客户↔产品↔持仓、客户↔代理人、产品风险等级	从原有业务系统同步重建
原有业务系统	Core（只读）	公司本来就有的一套账	真实持仓、流水、正式 KYC、C1~C5、C×R 矩阵	Agent 不复制一份，只读

记忆分层（和 Agent 文档里的说法对应）

• Redis = 短期记忆（聊完这一阵可能就不用了）
• MySQL = 权威记忆（落库、可审计、跨 Agent 共享）
• Milvus = 知识库记忆（产品/制度文档，语义搜索）
• Neo4j = 关系记忆（客户-产品-代理人之间的网）

---

用户画像：L0 / L1 / L2 / L3 是什么意思？

一句话

同一位客户，档案分四层；每层由不同的人/系统填写，给别人用，但谁也不能替官方改「正式风险等级」。

用「客户档案袋」来理解

想象一个客户档案袋，里面有 4 个插槽：

┌─────────────────────────────────────────────────────────────┐
│  L0 · 官方底稿（原有业务系统，Agent 只读，不能改）              │
│  姓名、年龄、职业、正式风险等级 C1~C5、真实资产规模              │
├─────────────────────────────────────────────────────────────┤
│  L1 · 客户自己聊出来的（客户财富 Agent 写入）                  │
│  投资风格、资金规划比例、亏损多少要提醒、平时关注什么            │
├─────────────────────────────────────────────────────────────┤
│  L2 · 代理人服务记录的（代理人助手 Agent 写入）                │
│  沟通诉求、待跟进事项、资产概况摘要、「最近在问赎回」等服务标签    │
├─────────────────────────────────────────────────────────────┤
│  L3 · 风控监测结论（风控监测 Agent 写入）                      │
│  正常 / 关注 / 高风险、监测评分、名单命中待复核等（不改 L0 等级） │
└─────────────────────────────────────────────────────────────┘

为什么要分 L1 / L2 / L3，不合成一张表？

层级	谁产生这些信息	为什么要单独一层
L0	开户、测评、交易系统	法律效力最强：正式能不能买高风险产品，以它为准
L1	客户和「客户 Agent」聊天、做问卷	客户 自己表达 的偏好和规划；代理人、风控可以 参考，但不能当成官方测评
L2	代理人和「代理人 Agent」服务客户	服务过程 里才知道的诉求；客户本人 看不到 这层（隐私和服务记录）
L3	风控系统监测	风险视角 的标签；只用于监测和统计， 不会自动改 L0 的正式等级

如果合成一张表会怎样？

• 客户说「我比较激进」和正式测评 C1 保守 混在一起，容易误当成可以买高风险产品 → 合规风险
• 代理人写的「客户想赎回」和客户自己填的「投资规划」 权限不同，客户不应看到服务侧备注
• 风控的「重点关注」 不能反写 进官方测评记录

所以：三层 enrich（L1/L2/L3）+ 一层官方底稿（L0），各写各的、各读各的（在权限范围内）。

谁读谁写（不用记表名，记关系就行）

层级	谁写入	谁读取
L0	原有系统（Agent 不写）	四个 Agent 都只读
L1	客户财富 Agent	客户本人、代理人、风控、数据分析
L2	代理人助手 Agent	代理人、风控、数据分析（客户不看）
L3	风控监测 Agent	风控、代理人（只看）、数据分析

对应 MySQL 表名（给开发对照）：customer_profile_l1 / l2 / l3
详细 JSON 约定与 L0 边界： 06-用户画像L1-L3设计.md

---

系统长什么样？（一张图）

        客户 Agent    代理人 Agent    数据分析 Agent    风控 Agent
              │              │              │              │
              └──────────────┴──────┬───────┴──────────────┘
                                    │
                         平台公共能力（登录、权限、审计）
                                    │
         ┌──────────┬───────────────┼───────────────┬──────────┐
         ▼          ▼               ▼               ▼          ▼
      Redis      MySQL          Milvus          Neo4j    原有业务系统
     临时聊天    正式档案      搜产品文档      关系图谱    真实持仓/测评

---

MySQL 16 张表：每张表 干什么（无编号版）

共用 vs 专用 的完整矩阵见 05-多Agent共用底座清单.md 第九节。

一、四个 Agent 共用的「基础设施」（6 张）🔴 底座第一批

表名	干什么	举例
agent_session	记录一次对话会话	「张三月 5 日下午 3 点开了客户 Agent」
agent_message	保存每条聊天内容	客户问了什么、Agent 答了什么
agent_tool_call	记录 Agent 调用了哪些查数接口	查持仓、查产品规则
audit_log	合规审计总账（只增不改不删）	出问题时追溯「谁、何时、依据什么」
input_guard_log	拦截恶意输入、注入攻击	有人试图让 Agent 越权查别人数据
customer_advisor_rel	这个客户归哪个代理人管	代理人 A 只能看自己名下客户

二、跨 Agent 交换：用户画像（3 张）🟡 底座第二批

表名	对应层级	干什么
customer_profile_l1	L1	风格标签、资金规划、亏损提醒阈值、行为偏好
customer_profile_l2	L2	资产概况快照、沟通诉求、待办、服务标签
customer_profile_l3	L3	监测分层（正常/关注/高风险）、监测评分

三、跨 Agent 交换：风控产出（2 张，也在底座第二批）🟡

表名	谁写	谁读	干什么
risk_alert	风控 Agent	分析 Agent、风控专员	预警单（待人工审核）
risk_suitability_log	风控 Agent	客户、代理人 Agent	买的产品是否匹配、可否拦截

四、各 Agent 专用（5 张）⚪ 各组自建，不算公共底座

表名	哪个 Agent	干什么
customer_threshold_config	客户	亏损阈值配置
customer_notify_log	客户	提醒留痕
advisor_draft	代理人	话术/跟进草稿
compliance_hit_log	代理人	违规话术检测
analytics_query_log	分析	查数 SQL 留痕

完整 DDL 见 01-mysql-共用底座.sql + 02-mysql-agent专用.sql
适当性 log 字段契约：07-risk_suitability_log说明.md

---

四个 Agent 各自管哪块数据？

Agent	主要负责 写入	主要 读取 别人的什么
客户财富	L1 画像、亏损阈值、提醒记录	原有系统持仓；风控的适当性结论（只读）
代理人助手	L2 画像、话术草稿、违规记录	L1 画像（了解客户偏好）；产品文档（Milvus）
数据分析	查数日志	L1/L2/L3 做统计；预警单做「还有多少条没处理」
风控监测	L3 画像、预警单、适当性记录	L1/L2 辅助判断；原有系统交易流水
平台	会话、审计、权限关系	—

---

三条最常见的业务流程

1. 客户和 Agent 聊天

客户说话
  → Redis 记住最近几轮（聊完可过期）
  → MySQL 永久保存聊天记录 + 审计
  → 若问产品规则 → 去 Milvus 搜官方文档，回答必须能溯源
  → 若问持仓 → 去原有系统查真实数据（金额以原系统为准）
  → 若客户说了偏好/设了阈值 → 更新 L1 画像

2. 代理人服务客户前「做功课」

代理人输入客户 ID
  → 读 L1（客户自己侧的偏好）
  → 读 L2（之前服务记录，没有就新建）
  → 读原有系统持仓 + Neo4j 看持有哪些产品
  → 生成话术草稿 → 存 advisor_draft → 代理人改完、审核后才能发给客户

3. 风控发现大额交易

原有系统传来一笔交易
  → 风控 Agent 判断是否触发规则（如单笔 ≥50 万）
  → MySQL 生成预警单，状态 =「待人工审核」
  → Redis 推一条消息给风控工作台（实时弹窗）
  → 数据分析 Agent 可以统计「还有多少条没审」，但不能替风控审
  → 风控专员在系统里人工处理，改预警状态

---

搭建底座 vs 开发 Agent（两回事）

	搭建共用底座	四个 Agent 并行开发
目标	把多 Agent 要一起用的表/缓存/向量库建好	各组写自己的 Agent 逻辑
谁做	平台组统一做	客户/代理人/分析/风控 四组
建什么	MySQL 11 张 + Redis + Milvus(产品) + Neo4j	各自专用 5 张表 + 业务代码
详细清单	05-多Agent共用底座清单.md	同上第五节「专用」

---

必须遵守的 6 条规矩（合规）

1. 审计日志只能追加，不能删改。
2. 正式风险等级 C1~C5 只有原有测评系统能改；L1/L2/L3 都不能覆盖它。
3. 全系统只有「买的产品和风险等级不匹配」这一种情况可以拦截购买；其他 Agent 不能冻户、不能拦交易。
4. 代理人 Agent 生成的话术，不能直接发给客户，必须人工审核。
5. 数据分析只能查数（SELECT），不能改业务数据。
6. Redis 里的可以丢；MySQL 里的是准的。

---

附录：需求编号对照（给开发追溯用）

阅读正文 不需要 记这些编号；联调需求文档时用。

编号	业务含义
F-01	登录权限、代理人只能看名下客户
F-02	所有对话和操作可审计
F-03	输入安全、防注入
F-04	Agent 只读业务账，不改账
C-01~C-05	客户 P0：持仓、产品、规则、阈值提醒、行情
C-07/C-08	客户 P1：风格测评、资金规划
A-01~A-07	代理人：客户概况、规则答疑、话术草稿、合规检测等
D-01~D-04	数据分析：人话查数、SQL 留痕
R-01~R-03	风控 P0：大额预警、适当性拦截、反洗钱名单

---

其他文件去哪看？

文件	什么时候看
05-多Agent共用底座清单.md	先搭底座：哪些表多 Agent 共用
01-mysql-共用底座.sql	执行建库：共用 11 张
02-mysql-agent专用.sql	各 Agent 专用 5 张
06-用户画像L1-L3设计.md	L0/L1/L2/L3 边界、JSON schema、适当性分工
07-risk_suitability_log说明.md	R-02 落库字段契约
02-redis-keys.md	做会话缓存、画像缓存
03-milvus-collections.md	做产品/制度文档检索
04-neo4j-model.md	做持仓关系、适当性关系查询
docs/需求拆解/	完整业务场景与合规细则