diff --git a/.gitignore b/.gitignore
index 96f7848..a9d9050 100644
--- a/.gitignore
+++ b/.gitignore
@@ -39,6 +39,9 @@ Thumbs.db
*.log
logs/
+# 数据分析 20 题 live battery 本地报告（不入库，见 scripts/dev/run_query_battery.py）
+scripts/dev/battery_report.json
+
# Milvus / Neo4j local
.milvus/
diff --git a/AGENTS.md b/AGENTS.md
index 0426fa7..2886e17 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -38,6 +38,6 @@ app/repository/core_ro.py # Core 只读 + check_suitability（R-02）
scripts/core/reset.ps1 # 本地灌 Core 模拟库
```
-**当前分支：** `merger` · **测试基线：** `python -m pytest` → 786 passed · **Redis：** Docker `6380` · **前端：** `cd web && npm run build/test`
+**当前分支：** `merger` · **测试基线：** `python -m pytest` → 795 passed · **Redis：** Docker `6380` · **前端：** `cd web && npm run build/test`
技术选型硬阀门见 MEMORY 第 3、7 节。Cursor 以 `.cursor/rules/project-memory.mdc` 为准。
diff --git a/app/service/dict_service.py b/app/service/dict_service.py
index 3c55625..c28b9fd 100644
--- a/app/service/dict_service.py
+++ b/app/service/dict_service.py
@@ -78,6 +78,12 @@ def default_registry() -> MetricRegistry:
"申购交易金额合计", "元", "近30天"))
reg.add(Metric("redeem_amount", "赎回金额", ["赎回金额", "赎回额"],
"赎回交易金额合计", "元", "近30天"))
+ # 「交易流水/流水」为多义指标（N-01）：同时命中「金额」与「笔数」两个口径，
+ # resolve() 返回 Ambiguity，Agent 反问「按金额还是按笔数」后绑定本轮口径。
+ reg.add(Metric("trade_flow_amount", "交易流水金额", ["交易流水", "流水", "流水金额"],
+ "交易流水按成交金额排序", "元", "近30天"))
+ reg.add(Metric("trade_flow_count", "交易流水笔数", ["交易流水", "流水", "流水笔数"],
+ "交易流水笔数合计", "笔", "近30天"))
reg.add(Metric("customer_count", "客户数", ["客户数量", "客户数"],
"客户数量", "个", "当前"))
reg.add(Metric("risk_count", "高风险客户数", ["高风险客户数", "高风险数量"],
diff --git a/app/service/guardrail.py b/app/service/guardrail.py
index 1edd2de..d408fed 100644
--- a/app/service/guardrail.py
+++ b/app/service/guardrail.py
@@ -7,10 +7,30 @@ from __future__ import annotations
import re
from dataclasses import dataclass, field
+from decimal import Decimal
-NUMBER_RE = re.compile(r"-?(?:\d{1,3}(?:,\d{3})+|\d+)(?:\.\d+)?")
+# 数字必须紧跟前一个字符不是「字母/数字/下划线」（\w 含中文），
+# 从而避免把「沪深300指数」「中证500」这类名称里的数字误当金额。
+NUMBER_RE = re.compile(r"(? list[float]:
- """提取文本中的数字（含小数、负数、千分位逗号）。"""
- return [float(x.replace(",", "")) for x in NUMBER_RE.findall(text or "")]
+ """提取文本中的数字（含小数、负数、千分位逗号）。
+
+ 先屏蔽 CUST-/TRD-/PROD-/STAFF- 编号与日期/时间 token，再用带左边界约束的正则匹配，
+ 避免「CUST-3001」「沪深300指数」「9月3日」这类标识被误提取为金额。
+ """
+ text = _ID_TOKEN.sub(" ", text or "")
+ text = _DATE_TIME_TOKEN.sub(" ", text)
+ text = _WINDOW_TOKEN.sub(" ", text)
+ return [float(x.replace(",", "")) for x in NUMBER_RE.findall(text)]
def extract_percent_numbers(text: str) -> list[float]:
@@ -32,6 +59,8 @@ def extract_percent_numbers(text: str) -> list[float]:
def _to_float(v) -> float | None:
if isinstance(v, bool):
return None
+ if isinstance(v, Decimal):
+ return float(v)
if isinstance(v, (int, float)):
return float(v)
if isinstance(v, str):
@@ -72,7 +101,8 @@ def _approx_in(n: float, allowed: set[float], tol: float = 0.01) -> bool:
def check_numbers(answer: str, table) -> list[float]:
"""返回解读中出现、但结果表推导不出的数字（视为疑似说错）。
- 支持常见单位换算：解读带「万/亿」时，同时尝试按 1e4 / 1e8 放大比对。
+ 支持单位换算：解读带「万/亿」时按 1e4 / 1e8 放大比对；
+ 结果列含比率(0~1)时，允许解读按百分比(n = 比率×100)表述，追加 0.01 刻度比对。
"""
allowed = result_numbers(table)
scales = [1.0]
@@ -80,6 +110,8 @@ def check_numbers(answer: str, table) -> list[float]:
scales.append(10000.0)
if "亿" in answer:
scales.append(100000000.0)
+ if any(0.0 < a < 1.0 for a in allowed):
+ scales.append(0.01)
issues: list[float] = []
for n in extract_numbers(answer):
if not any(_approx_in(n * s, allowed) for s in scales):
diff --git a/docs/course/jinrong-module-risk/_base.html b/docs/course/jinrong-module-risk/_base.html
index 054730d..048890a 100644
--- a/docs/course/jinrong-module-risk/_base.html
+++ b/docs/course/jinrong-module-risk/_base.html
@@ -33,6 +33,9 @@
+
+
+
diff --git a/docs/course/jinrong-module-risk/index.html b/docs/course/jinrong-module-risk/index.html
index 302faa0..8cf9f7e 100644
--- a/docs/course/jinrong-module-risk/index.html
+++ b/docs/course/jinrong-module-risk/index.html
@@ -33,6 +33,9 @@
+
+
+
@@ -46,6 +49,7 @@
风控专员 Demo STAFF-30001 带 risk_officer + risk_demo 角色：
能看预警台账、处置、跑 AML 扫描，还能在模拟交易页触发规则引擎。
本地登录页一键切换，改 JWT 角色后需重新登录。
+ 仓库基线 merger · python -m pytest → 795 passed。
@@ -56,8 +60,8 @@
GET /api/risk/alerts 分页查询；POST .../handle 人工处置（仅 risk_officer）。响应固定带 disclaimer。
-
适当性校验 FR-2
-
POST /api/risk/suitability/check：客户仅本人、理财师名下、风控全量。每次直调落 audit。
+
适当性校验 R-02 / FR-2
+
POST /api/risk/suitability/check 与网关共用 Core 只读层 的 check_suitability（旧 SUIT-001~008 已退役）。客户本人 / 理财师名下 / 风控全量。
AML 扫描 FR-5
@@ -199,6 +203,24 @@
+
+
R-02 阻断 vs R-01 大额待审（同网关、不同结果）
+
模拟写 Core 网关（trade_gateway.py）里先跑适当性：不过 → 交易写不进去（R-02）；过了 → 写入 core_trade → 规则引擎再扫 R-01 大额等 → 出 pending_review 预警。
+
+
+
A-1 · R-02 阻断
+
CUST-1001 + PROD-161725 · 风评与产品 R 档不匹配 → 网关拒绝 · 可有 suitability 类预警 · 无成交
+
+
+
A-3 · R-01 大额待审
+
CUST-3001 · 50 万申购 → 成交写入 Core → 引擎出大额类 pending_review · 台账可见
+
+
+
+ 指挥 AI 时： 别把「阻断交易」和「出预警待审」混成一个状态——前者在网关，后者在引擎聚合。
+
+
代码地图
@@ -260,11 +282,11 @@
模块 3 · REST 与对话 Tool
-
台账 REST 要带 risk 头
对话靠五只 Tool
+
台账 REST 要带 risk 头
对话靠六只 Tool
风控REST
- 走 get_auth_context，前端必须带 X-Agent-Type: risk。
- 风控对话则通过风控对话 Tool 注册表（chat_tools.py）注册五只只读 Tool + query_agent_behavior，由对话 Tool 编排（tool_service.py）统一分发。
+ 走模块鉴权工厂（deps.py 的 get_auth_context），前端必须带 X-Agent-Type: risk。
+ 风控对话走顾问通用编排（agent_service.py）的 risk 分支 + SSE；Tool 由风控对话 Tool 注册表（chat_tools.py）注册 六只只读 Tool，经对话 Tool 编排（tool_service.py）分发。
@@ -387,7 +409,7 @@
- 仓库现状（2026-09）：STAFF-30001 含 risk_demo；python -m pytest → 774 passed。
+ 仓库现状（2026-09-10）：STAFF-30001 含 risk_demo；python -m pytest → 795 passed。
@@ -439,7 +461,7 @@
- reset 后台账空： reset.ps1 只重建 jinrong_core；risk_alert 要跑 prepare_risk_demo.sql + AML 种子才有演示数据。
+ reset 后台账空： reset.ps1 只重建 jinrong_core；risk_alert 要跑 prepare_risk_demo.sql + AML 种子才有演示数据。完整步骤见 docs/项目框架设计/演示SOP-风控模块.md §2。
@@ -471,6 +493,390 @@
+
+
+
+
模块 5 · FR-8/9/10
+
集中度、超期升级
与代理人行为链
+
+ PRD v1.1 追加的三条能力（FR-8~10）已在 merger 落地。
+ 指挥 AI 改代码时要分清：规则引擎 / cron 脚本负责「出单、升级」；对话 Tool 只读查库，不能替运维跑定时任务。
+
+
+
+
三条规则 · 各管什么
+
+
+
FR-8 · RISK-006 集中度
+
客户持仓 R4+R5 占比 ≥ 阈值 → 并入事件类预警聚合（同客户同日一张事件单）。演示 A-10。
+
+
+
FR-9 · RISK-007 超期升级
+
pending_review 超阈值未处置 → 超期升级 cron（escalation_scan.py）写 payload 分级 · status 不变。
+
+
+
FR-10 · RISK-008 行为链
+
代理人 A/B/C 条件命中 → 按 actor_id 维度出单；明细仅 officer/manager 可见。演示 A-12。
+
+
+
+
+
+
数据流：引擎出单 vs Chat 只读查
+
+
+
⚙引擎 / cron
+
💬风控 Chat Tool
+
🗄risk_alert 表
+
+
点击「下一步」
+
+
+
+
+
+
+
+
+
+
+
对话 Tool · 超期查询（chat_tools.py）
+
+
+
+
+
+
白话
+
+
想让超期单「升级」→ 运维跑 scripts/cron/escalation_scan.py，不是改 prompt。
+
想让行为链出单 → 先积累 audit 痕迹，再跑 agent_behavior_scan.py。
+
Chat 里问「有哪些超期单」→ query_overdue_alerts 查现有数据即可。
+
+
+
+
+
+
+
FR-9 超期升级后，预警单的 status 会怎样？
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
模块 6 · L3 与角色
+
监测档怎么写
谁能看谁能处置
+
+ L3 监测画像写入服务（profile_l3.py）把 AML 命中、规则结果写入 customer_profile_l3（防降级合并）。
+ 模块鉴权工厂（deps.py）按 JWT 角色决定台账 REST 与对话 Tool 能看到什么——接前端或新 Tool 前先对这张矩阵。
+
+
+
+
L3 监测档 · 谁写、谁读
+
+
+
①
+
写入 · AML 扫描服务（aml_service.py）命中 → 写 L3 monitor_tier=high + 预警出单（R-03 通知不冻户）
+
+
+
②
+
合并 · 只升不降（normal < watch < high）；禁止 Agent 把 high 改回 normal
+
+
+
③
+
读取 · customer_context Tool：Core L0 + L3 + 待审预警摘要（只读，供风控 Chat 解读）
+
+
+
+ 铁律： L3 是 enrich 监测标签，不覆盖 Core 正式 C1~C5 风评；审计表只 INSERT。
+
+
+
+
+
角色矩阵（REST + 对话数据面）
+
+
+
risk_officer
+
台账全量 · POST .../handle 处置 · AML scan · 模拟 risk_demo · 行为链明细可见
+
+
+
risk_manager
+
台账全量 · 一般不 handle（按矩阵）· 行为链明细可见
+
+
+
compliance
+
台账强制 aml 域 · 无 simulate · 对话 Tool 仍只读
+
+
+
+
+
+
群聊：AML 命中后 L3 与台账
+
+
+
+
扫
+
+
aml_service.scan
+
CUST-1002 展示名命中名单 → 独立 aml 预警单
+
+
+
+
L3
+
+
profile_l3.upsert
+
monitor_tier → high（若原档更低则抬升，不降级）
+
+
+
+
Tool
+
+
customer_context
+
风控 Chat 问客户档案 → 返回 L0 + L3 high + 待审预警数
+
+
+
+
员
+
+
risk_officer
+
台账 handle 处置 · 不自动冻户 · 不改 Core 正式风评
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
L3 防降级 · profile_l3.py 口径
+
+
+
+
+
+
白话
+
+
指挥 AI 加「自动降档」= 违规；L3 只能抬监测强度或保持。
+
客户 Agent 不可读 L3 全文念给客户；只有风控/顾问 Tool 在 RBAC 内读。
+
处置预警用 REST handle，不是让 LLM 在对话里改库。
+
+
+
+
+
+
+
AML 扫描命中 CUST-1002 后，系统会做什么？
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
模块 7 · 写侧并发
+
同一天两笔交易
为什么还是一条预警？
+
+ 进程内聚合锁原语（locks.py）把「同一客户、同一聚合 key」串行化；L3 监测画像写入服务（profile_l3.py）用
+ computed_at 乐观锁防丢更新。指挥 AI 改写路径时，先分清悲观锁（串行）和乐观锁（版本戳比对）各管哪一段。
+
+
+
+
两层锁 · 各管什么
+
+
+ | 职责 | 代码入口 | 机制 |
|---|
+
+
+
+ | 预警同日聚合串行 |
+ 预警处置与聚合服务（alert_service.py）+ 锁原语（locks.py · run_locked） |
+ 单进程 threading.Lock；拿锁超时降级执行，冲突由锁内重查兜底 |
+
+
+ | L3 写侧防覆盖 |
+ L3 写入（profile_l3.py）+ 仓储更新（risk_repository.update_l3） |
+ 乐观锁：WHERE computed_at = :expected，失败重读重试（最多 3 次） |
+
+
+ | 处置 + 审计同事务 |
+ 人工处置（handle_alert）+ 风控仓储（risk_repository） |
+ 状态变更与 audit 同连接提交（B7 挂账⑦ 已收口） |
+
+
+
+
+ 不做： 风控线不接 L1/L2 画像 Redis 热缓存（归客服/顾问）；L3 读侧已有 profile:l3:{customer_id} cache-aside + 写后 DEL。
+
+
+
+
+
+
+
锁原语 · 预警聚合 key 示例
+
+run_locked(
+ f"agg:event:{customer_id}:{today}",
+ lambda locked: _merge_or_insert(...),
+)
+
+
+run_locked(f"l3:{customer_id}", _write_with_optimistic_retry)
+
+
+
白话
+
想象收银台叫号器：同一客户、同一天的「首单聚合」必须排队进窗口，窗口里再查「今天是否已有单」——两笔并发进来也不会开出两张重复首单。
+
L3 则是贴便签前先对表上的时间戳：若别人刚改过，你的 UPDATE 打不中，就重读再合并（只升不降监测档）。
+
+
+
+
+
+
群聊：并发两笔 · 聚合与 L3
+
+
+
+
T1
+
+
trade #1
+
引擎出单 → 请求 run_locked(agg:event:…)
+
+
+
+
T2
+
+
trade #2
+
同时到达 → 在锁外等待或超时降级；锁内重查并入同一 risk_alert
+
+
+
+
L3
+
+
profile_l3
+
upsert 前读 computed_at → UPDATE 带 expected → 失败则重试
+
+
+
+
审
+
+
audit
+
处置 handle：改 status + 写 audit_log 同一事务（避免「状态变了没审计」）
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
数据流：写侧三条线
+
+
+
🔒聚合锁
+
📋risk_alert
+
📊L3 + audit
+
+
点击「下一步」
+
+
+
+
+
+
+
+
+
+
+
指挥 AI「给风控加 L1 Redis 热读」合理吗？
+
+
+
+
+
+
+
+
+
+
+
+
STAFF-30001 带 risk_officer + risk_demo 角色：
能看预警台账、处置、跑 AML 扫描，还能在模拟交易页触发规则引擎。
本地登录页一键切换，改 JWT 角色后需重新登录。
+ 仓库基线 merger · python -m pytest → 795 passed。
@@ -16,8 +17,8 @@
GET /api/risk/alerts 分页查询；POST .../handle 人工处置（仅 risk_officer）。响应固定带 disclaimer。
-
适当性校验 FR-2
-
POST /api/risk/suitability/check：客户仅本人、理财师名下、风控全量。每次直调落 audit。
+
适当性校验 R-02 / FR-2
+
POST /api/risk/suitability/check 与网关共用 Core 只读层 的 check_suitability（旧 SUIT-001~008 已退役）。客户本人 / 理财师名下 / 风控全量。
AML 扫描 FR-5
diff --git a/docs/course/jinrong-module-risk/modules/02-engine.html b/docs/course/jinrong-module-risk/modules/02-engine.html
index 6bca6d8..4b79657 100644
--- a/docs/course/jinrong-module-risk/modules/02-engine.html
+++ b/docs/course/jinrong-module-risk/modules/02-engine.html
@@ -31,6 +31,24 @@
+
+
R-02 阻断 vs R-01 大额待审（同网关、不同结果）
+
模拟写 Core 网关（trade_gateway.py）里先跑适当性：不过 → 交易写不进去（R-02）；过了 → 写入 core_trade → 规则引擎再扫 R-01 大额等 → 出 pending_review 预警。
+
+
+
A-1 · R-02 阻断
+
CUST-1001 + PROD-161725 · 风评与产品 R 档不匹配 → 网关拒绝 · 可有 suitability 类预警 · 无成交
+
+
+
A-3 · R-01 大额待审
+
CUST-3001 · 50 万申购 → 成交写入 Core → 引擎出大额类 pending_review · 台账可见
+
+
+
+ 指挥 AI 时： 别把「阻断交易」和「出预警待审」混成一个状态——前者在网关，后者在引擎聚合。
+
+
代码地图
diff --git a/docs/course/jinrong-module-risk/modules/03-tools-rest.html b/docs/course/jinrong-module-risk/modules/03-tools-rest.html
index 8bfa841..117211a 100644
--- a/docs/course/jinrong-module-risk/modules/03-tools-rest.html
+++ b/docs/course/jinrong-module-risk/modules/03-tools-rest.html
@@ -1,11 +1,11 @@
模块 3 · REST 与对话 Tool
-
台账 REST 要带 risk 头
对话靠五只 Tool
+
台账 REST 要带 risk 头
对话靠六只 Tool
风控REST
- 走 get_auth_context，前端必须带 X-Agent-Type: risk。
- 风控对话则通过风控对话 Tool 注册表（chat_tools.py）注册五只只读 Tool + query_agent_behavior，由对话 Tool 编排（tool_service.py）统一分发。
+ 走模块鉴权工厂（deps.py 的 get_auth_context），前端必须带 X-Agent-Type: risk。
+ 风控对话走顾问通用编排（agent_service.py）的 risk 分支 + SSE；Tool 由风控对话 Tool 注册表（chat_tools.py）注册 六只只读 Tool，经对话 Tool 编排（tool_service.py）分发。
@@ -128,7 +128,7 @@
- 仓库现状（2026-09）：STAFF-30001 含 risk_demo；python -m pytest → 774 passed。
+ 仓库现状（2026-09-10）：STAFF-30001 含 risk_demo；python -m pytest → 795 passed。
diff --git a/docs/course/jinrong-module-risk/modules/04-gaps.html b/docs/course/jinrong-module-risk/modules/04-gaps.html
index 5486b19..a287ef8 100644
--- a/docs/course/jinrong-module-risk/modules/04-gaps.html
+++ b/docs/course/jinrong-module-risk/modules/04-gaps.html
@@ -45,7 +45,7 @@
- reset 后台账空： reset.ps1 只重建 jinrong_core；risk_alert 要跑 prepare_risk_demo.sql + AML 种子才有演示数据。
+ reset 后台账空： reset.ps1 只重建 jinrong_core；risk_alert 要跑 prepare_risk_demo.sql + AML 种子才有演示数据。完整步骤见 docs/项目框架设计/演示SOP-风控模块.md §2。
diff --git a/docs/course/jinrong-module-risk/modules/05-fr-extensions.html b/docs/course/jinrong-module-risk/modules/05-fr-extensions.html
new file mode 100644
index 0000000..827842c
--- /dev/null
+++ b/docs/course/jinrong-module-risk/modules/05-fr-extensions.html
@@ -0,0 +1,93 @@
+
+
+
模块 5 · FR-8/9/10
+
集中度、超期升级
与代理人行为链
+
+ PRD v1.1 追加的三条能力（FR-8~10）已在 merger 落地。
+ 指挥 AI 改代码时要分清：规则引擎 / cron 脚本负责「出单、升级」；对话 Tool 只读查库，不能替运维跑定时任务。
+
+
+
+
三条规则 · 各管什么
+
+
+
FR-8 · RISK-006 集中度
+
客户持仓 R4+R5 占比 ≥ 阈值 → 并入事件类预警聚合（同客户同日一张事件单）。演示 A-10。
+
+
+
FR-9 · RISK-007 超期升级
+
pending_review 超阈值未处置 → 超期升级 cron（escalation_scan.py）写 payload 分级 · status 不变。
+
+
+
FR-10 · RISK-008 行为链
+
代理人 A/B/C 条件命中 → 按 actor_id 维度出单；明细仅 officer/manager 可见。演示 A-12。
+
+
+
+
+
+
数据流：引擎出单 vs Chat 只读查
+
+
+
⚙引擎 / cron
+
💬风控 Chat Tool
+
🗄risk_alert 表
+
+
点击「下一步」
+
+
+
+
+
+
+
+
+
+
+
对话 Tool · 超期查询（chat_tools.py）
+
+
+
+
+
+
白话
+
+
想让超期单「升级」→ 运维跑 scripts/cron/escalation_scan.py，不是改 prompt。
+
想让行为链出单 → 先积累 audit 痕迹，再跑 agent_behavior_scan.py。
+
Chat 里问「有哪些超期单」→ query_overdue_alerts 查现有数据即可。
+
+
+
+
+
+
+
FR-9 超期升级后，预警单的 status 会怎样？
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
模块 6 · L3 与角色
+
监测档怎么写
谁能看谁能处置
+
+ L3 监测画像写入服务（profile_l3.py）把 AML 命中、规则结果写入 customer_profile_l3（防降级合并）。
+ 模块鉴权工厂（deps.py）按 JWT 角色决定台账 REST 与对话 Tool 能看到什么——接前端或新 Tool 前先对这张矩阵。
+
+
+
+
L3 监测档 · 谁写、谁读
+
+
+
①
+
写入 · AML 扫描服务（aml_service.py）命中 → 写 L3 monitor_tier=high + 预警出单（R-03 通知不冻户）
+
+
+
②
+
合并 · 只升不降（normal < watch < high）；禁止 Agent 把 high 改回 normal
+
+
+
③
+
读取 · customer_context Tool：Core L0 + L3 + 待审预警摘要（只读，供风控 Chat 解读）
+
+
+
+ 铁律： L3 是 enrich 监测标签，不覆盖 Core 正式 C1~C5 风评；审计表只 INSERT。
+
+
+
+
+
角色矩阵（REST + 对话数据面）
+
+
+
risk_officer
+
台账全量 · POST .../handle 处置 · AML scan · 模拟 risk_demo · 行为链明细可见
+
+
+
risk_manager
+
台账全量 · 一般不 handle（按矩阵）· 行为链明细可见
+
+
+
compliance
+
台账强制 aml 域 · 无 simulate · 对话 Tool 仍只读
+
+
+
+
+
+
群聊：AML 命中后 L3 与台账
+
+
+
+
扫
+
+
aml_service.scan
+
CUST-1002 展示名命中名单 → 独立 aml 预警单
+
+
+
+
L3
+
+
profile_l3.upsert
+
monitor_tier → high（若原档更低则抬升，不降级）
+
+
+
+
Tool
+
+
customer_context
+
风控 Chat 问客户档案 → 返回 L0 + L3 high + 待审预警数
+
+
+
+
员
+
+
risk_officer
+
台账 handle 处置 · 不自动冻户 · 不改 Core 正式风评
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
L3 防降级 · profile_l3.py 口径
+
+
+
+
+
+
白话
+
+
指挥 AI 加「自动降档」= 违规；L3 只能抬监测强度或保持。
+
客户 Agent 不可读 L3 全文念给客户；只有风控/顾问 Tool 在 RBAC 内读。
+
处置预警用 REST handle，不是让 LLM 在对话里改库。
+
+
+
+
+
+
+
AML 扫描命中 CUST-1002 后，系统会做什么？
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
模块 7 · 写侧并发
+
同一天两笔交易
为什么还是一条预警？
+
+ 进程内聚合锁原语（locks.py）把「同一客户、同一聚合 key」串行化；L3 监测画像写入服务（profile_l3.py）用
+ computed_at 乐观锁防丢更新。指挥 AI 改写路径时，先分清悲观锁（串行）和乐观锁（版本戳比对）各管哪一段。
+
+
+
+
两层锁 · 各管什么
+
+
+ | 职责 | 代码入口 | 机制 |
|---|
+
+
+
+ | 预警同日聚合串行 |
+ 预警处置与聚合服务（alert_service.py）+ 锁原语（locks.py · run_locked） |
+ 单进程 threading.Lock；拿锁超时降级执行，冲突由锁内重查兜底 |
+
+
+ | L3 写侧防覆盖 |
+ L3 写入（profile_l3.py）+ 仓储更新（risk_repository.update_l3） |
+ 乐观锁：WHERE computed_at = :expected，失败重读重试（最多 3 次） |
+
+
+ | 处置 + 审计同事务 |
+ 人工处置（handle_alert）+ 风控仓储（risk_repository） |
+ 状态变更与 audit 同连接提交（B7 挂账⑦ 已收口） |
+
+
+
+
+ 不做： 风控线不接 L1/L2 画像 Redis 热缓存（归客服/顾问）；L3 读侧已有 profile:l3:{customer_id} cache-aside + 写后 DEL。
+
+
+
+
+
+
+
锁原语 · 预警聚合 key 示例
+
+run_locked(
+ f"agg:event:{customer_id}:{today}",
+ lambda locked: _merge_or_insert(...),
+)
+
+
+run_locked(f"l3:{customer_id}", _write_with_optimistic_retry)
+
+
+
白话
+
想象收银台叫号器：同一客户、同一天的「首单聚合」必须排队进窗口，窗口里再查「今天是否已有单」——两笔并发进来也不会开出两张重复首单。
+
L3 则是贴便签前先对表上的时间戳：若别人刚改过，你的 UPDATE 打不中，就重读再合并（只升不降监测档）。
+
+
+
+
+
+
群聊：并发两笔 · 聚合与 L3
+
+
+
+
T1
+
+
trade #1
+
引擎出单 → 请求 run_locked(agg:event:…)
+
+
+
+
T2
+
+
trade #2
+
同时到达 → 在锁外等待或超时降级；锁内重查并入同一 risk_alert
+
+
+
+
L3
+
+
profile_l3
+
upsert 前读 computed_at → UPDATE 带 expected → 失败则重试
+
+
+
+
审
+
+
audit
+
处置 handle：改 status + 写 audit_log 同一事务（避免「状态变了没审计」）
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
数据流：写侧三条线
+
+
+
🔒聚合锁
+
📋risk_alert
+
📊L3 + audit
+
+
点击「下一步」
+
+
+
+
+
+
+
+
+
+
+
指挥 AI「给风控加 L1 Redis 热读」合理吗？
+
+
+
+
+
+
+
+
+
+
+
+
-
筛选状态
-