AI260626/group_fqcd_jr
13
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
69 Commits 12 Branches 0 Tags
ccf353901ab9d396fd55c2b2dc2e4cb92e336b65
Commit Graph
21 Commits
Author SHA1 Message Date
lzf_0626 ccf353901a docs(25): 更正我自己的上一条判断——behavior_score 是上游数据前提，不是本项目缺陷 
上一轮我把"behavior_score 初始值为 0"记为**真缺陷**，并说"修复点在画像创建侧"。
继续查后发现前提不成立：**本项目不创建 fin_customer_profile 行**。

证据：全仓搜索 FundCustomerProfile( 只命中类定义（app/model/fund.py:296）与测试文件；
没有任何 INSERT；grep in_customer_profile 在 app/ 下只有类定义与一处注释；
profile_assembly_service 走的是 ORM 读取 + 属性更新，行不存在时返回
profile_row_not_opened（说明它也不创建行）。所以画像行由**本项目之外的流程**写入，
是它把 behavior_score 设成了 0。

本项目的扣分逻辑本身是对的：min(满分, before) - deduction 再 max(0, ...) —— 给定 0，
任何扣分都只能得 0，这是算术必然，不是判断错误。

因此改为"上游数据前提缺失"，并给出处置建议：① 上游创建画像时按满分初始化；
② 若上游改不了，则需要一个能区分"未初始化"与"扣光了"的标记（例如新增列），
但仅为这个目的加列的成本收益需要权衡。

**在拿到上游口径之前，本项目不做任何"见 0 就补 20"的处理** —— 0 同样是合法的扣分结果，
那样会把真正扣到 0 的客户错误地抬回满分。
 2026-09-11 13:54:27 +08:00
lzf_0626 9005bd9a46 docs(25): 第 16 条复核——两项不成立，另有一项是真缺陷（原报告没写出来） 
原描述把三件事混成一条，逐项复核：

**a. exclude 不要求"调查中"** —— 这是**业务规则**，不是技术缺陷。exclude 要求
"已确认 + 未闭环"（:63-66），resolve 额外要求"调查中"（:90）；不对称是事实，但
"误报关闭是否必须先经调查"属于业务裁定，代码里那两道门是有意设置的，看不出实现偏差。
需业务方定，不由技术侧单方面加门禁。

**b. min(20, score_before)** —— **误报**。BEHAVIOR_SCORE_INITIAL = 20 是**满分**（:18），
扣分表 {"低":3, "中":5, "高":20}（:19）与之自洽（高危扣满归零），所以这个 min 是把越界
数据拉回合法上限的数据清洗；而且它**不是静默的** —— 审计里同时记了
behavior_score_before / deduction / after（:118-120）。原描述"静默改写"不成立。

**c. 真缺陷（原报告没写）**：ehavior_score 的初始值是 0 而不是满分 20，
**导致扣分机制整体失效**。实测：fin_customer_profile.behavior_score 定义为
int NOT NULL（无默认值），现有画像 customer_id=9001 的值是 **0**。

于是 :103 的计算恒为 min(20, 0) - deduction = -deduction → max(0, ...) = 0：
**扣分永远扣不动，行为分恒为 0**。且全仓只有 :109 一处给 behavior_score 赋值
（写入方只有风控结案），说明初始 0 来自插入画像时的显式赋值，没有任何地方初始化成 20。

影响：行为分是"预警结案 → 客户行为评分下降"这条链路的落点，现在这条链路**产出为零**。
修复点在**画像创建侧**（初始值应为满分），不在风控的扣分逻辑里。
 2026-09-11 13:52:57 +08:00
lzf_0626 d4e7e2672c docs(25): 更正 P1 #2 的定性——模型自建客户端是基座能力缺口，不是违规 
复核时发现原修复建议（"改走 ModelGenerationService，或用 self.generate_with_model"）
**前提不成立**：

- OpenAICompatibleGateway.generate(endpoint_code, prompt, timeout_ms) -> str
  （model_gateway.py:57）与 ModelDispatchService.generate(endpoints, prompt) -> ModelExecution
  （:248）都是"给一段 prompt、拿一段文本"；ModelExecution 的字段只有
  (endpoint_code, text, attempts, degraded)（:226-231）。
- 而风控需要的是 **messages 数组 + tools（function calling）+ 解析 tool_calls**，
  基座完全没有这种形态的入口。

所以这不是"绕过"，是基座缺能力时的补位，而且补得规矩：端点选择直接用基座的
DatabaseModelEndpointResolver；降级策略与 ModelDispatchService.generate 一致
（顺序尝试 + max_attempts 默认 2）；错误映射也复用基座同一套
UpstreamTimeoutError / DependencyUnavailableError。

仍成立的两点：① bootstrap.py:262-265 的 lambda 让 model_client 注入点形同虚设，
无论走哪条路都该改；② HTTP 调用逻辑与 gateway 重复了一份，gateway 将来的限流/成本统计
风控享受不到。

**正确的修法比原建议大**：给基座**新增** chat(messages, tools) 形态的入口
（ModelGateway → OpenAICompatibleGateway → ModelDispatchService → ModelGenerationService
→ BaseAgent），再让风控改用。因为只是新增方法、不改现有行为，对已有 Agent 零影响；
但涉及基座核心链路，是否做需要项目方定，**本轮未实施**。
 2026-09-11 13:43:46 +08:00
lzf_0626 3593a68ad1 docs(25): 撤回一条误报——ai_analysis 的并发控制一直存在 
复核 P1 #5 时发现 .with_for_update() 就在 
isk_analysis_service.py:121-125，
而初次报告只读到 :130-160、恰好漏看了锁所在的那几行，却把这条标成了"✅ 已验证"。

实测推翻（并发发起三种分析，各自独立 session —— 复用同一个 session 会天然串行、
测不出竞争）：
- 预警研判 1809 字 / 回访话术 2030 字 / 工单摘要 1088 字，三个请求全部成功
- 落库 ai_analysis 的键：['回访话术', '工单摘要', '预警研判'] —— **三个都在，未发生覆盖**

所以 P1 #5 只剩前半条（审计不经基座统一链路）仍然成立，并发那条撤回。

教训一并写进文档：标注"已验证"之前必须确认自己真的读到了关键那段代码，
否则标注本身就是误导 —— 这与 _topic_of 那几轮踩的是同一个坑。
 2026-09-11 13:42:32 +08:00
lzf_0626 d1a24b84b3 docs(25): 风控模块代码评审报告 
评审方式：4 个并行评审（架构接入 / 数据层与数据库基线 / 业务逻辑正确性 / API 规范），
关键结论由本人逐条核对代码或实测数据库复核。报告用三级标记区分可信度：
✅ 已亲自核对、🔁 两位评审独立发现同一问题、⚠️ 评审提出但未逐条复核。

总体结论：骨架合规（继承 BaseAgent、只实现 handle、工具统一走 call_tool、ORM 与数据库基线
逐列吻合且未改动任何已有表、全仓无字符串拼 SQL、权限默认拒绝、repository 严格只读），
问题集中在三条断线和一批业务正确性缺陷。

P0：意图配置与工具白名单一条未发布（实测 DB 确认）。白名单失败关闭 ⇒ 风控当前跑不起来。
P1：模型调用绕过基座的 generate_with_model；risk chat 的 task_type 未注册 capability，
      当前能用只因 deepseek-flash 恰好排在端点表第一行；邮件端点无权限校验（默认关闭，
      但开启 SMTP 后即为未授权邮件发送器）；Agent 在 handle 里直写 ai_analysis 且读-改-写
      无并发控制；时区口径不统一——定时规则把 UTC 0-6 点当"凌晨"，实际判的是北京时间
      08:00-14:00，会持续误报。
P2：日报误报原因恒为"未填写"、研判漏阈值条件、通知失败被静默吞掉、定时扫描重启后不再
      执行、一条脏数据中断整批等 10 项。
P3：分页元数据层级、游标未绑定用户与查询条件、无 limit 全量查询、索引失效、写操作无幂等、
      错误码超表、SSE 未协商 Accept、接口未登记 docs/05 §19。

另记录一项需要业务方裁定的制度冲突：适当性指南第十二条矩阵允许 C1 购买 R2，第十四条却
要求投资者等级 >= 产品等级，两者对同一情形结论相反（已核对原文）。
 2026-09-11 12:08:17 +08:00
zhangshy 870fd0d44e Merge branch 'RM2_develop' into qyqy_develop 2026-09-11 11:44:51 +08:00
zhangshy 6911dd98a7 fix: 修复证据上传审计并补充前端操作提示要求 2026-09-11 11:42:53 +08:00
zhangshy aad3005830 Merge branch 'RM2_develop' into qyqy_develop 2026-09-11 11:25:24 +08:00
zhangshy 47056792eb fix: 规范预警详情客户编号映射 2026-09-11 11:24:22 +08:00
lzf_0626 478b64e4d7 Merge remote-tracking branch 'origin/qyqy_develop' into qyqy_develop_1 
# Conflicts:
#	app/service/agent/bootstrap.py
 2026-09-11 10:43:08 +08:00
zhangshy ecd0627396 feat: 调整通知接口字段并补齐风控配置清单 2026-09-11 10:35:24 +08:00
zhangshy c2178a985d feat: 增加风控定时扫描 Worker 与环境配置 2026-09-11 09:49:21 +08:00
lzf_0626 d40d808dd0 docs(24): 客服 Agent 阶段性总结与下阶段计划 
覆盖区间：从"客服能答常见问题但换个说法就时灵时不灵"到"能对客户给出适当性结论"。

只写已经跑通并验证过的事实（附实测数据）与明确还没做的事，不含计划外推测。
内容：知识检索质量（字面兜底/行级切分/粒度选择，含两个我自己引入的回归）、
多轮上下文（换话题串味 / 只补主语不补内容）、适当性裁决接入、知识库内容补充、
调试前端；三个教训（_topic_of 反解文本咬了三次、"接口留好了线没接上"的模式、
阈值必须和数据规模与形状一起看）；当前状态；下阶段计划与待决策事项；遗留缺口清单。

同时更正此前口述的两处错误：领先远程是 12 个提交（不是 16），
闲聊提示词配置是"从未落库"（不是"某次发布弄丢"）。
 2026-09-11 09:33:48 +08:00
lzf_0626 962a0a116f feat: 记忆→画像打通（事实提升 + 画像组装 + 版本快照） 
补齐"记忆系统为画像服务"的断链，按 docs/23 的分层设计实现后三层。

1. 新增 app/model/profile.py：user_facts 与 profile_snapshots 的 ORM 映射。此前这两张表
   只有结构、没有 Model，实际没有任何代码在用。两处表结构特例在 docstring 里显式标注，
   避免后续有人按直觉写入踩坑：
   · user_facts.id 无 auto_increment，主键必须由应用提供（本实现用微秒时间戳，单调递增）；
   · profile_snapshots.current_customer_id 是生成列（IF(is_current=1, customer_id, NULL)），
     故意不映射——映射了反而会在写入时与之冲突。

2. 新增 app/service/profile_assembly_service.py，三段职责：
   · 事实提升（中期→长期）：evidence_count ≥ 2 或 confidence ≥ 0.90 才从 memory_unit
     提炼进 user_facts —— 这条门槛就是"客户随口一说不能变成画像结论"的落地方式；
   · 画像组装（长期→画像）：按白名单映射进 fin_customer_profile，未列入白名单的事实
     （如 profile:family）只进 user_facts，保证画像的信噪比；
   · 版本留痕：每次重建写一条 profile_snapshots，generation_basis 逐字段记录来源，
     用于回答"当时凭什么这么判断"。

3. 新增 tools/rebuild_profile.py：手工触发入口（单客户或 --all）。画像暂无自动触发，
   这是目前唯一的重建方式，也便于排查"画像为什么没更新"。

红线由代码保证而非约定：investor_type 只从 fin_risk_assessment 最新一条读取，实现中
不存在任何记忆路径能写它。实测——客户 9001 问卷为 C2、对话自述"稳健型"，重建后
investor_type 仍为 C2，自述信息进入 risk_tags 并标注"自述:"前缀。三方不一致保持可见，
但等级判定只认问卷，客户无法靠对话改变自己的可购范围。

另一处由实测修正的设计：fin_customer_profile 的 trade_account/real_name/total_asset/
behavior_score 均为 NOT NULL，说明画像行由开户流程创建（也印证了"注册时填问卷"是开户
前置条件）。原先"首次重建时创建画像行"的做法是错的——会写出一条假的开户记录，而画像
恰恰是风控要读的数据。已改为只更新已存在的画像，未开户时返回 reason=profile_row_not_opened
并如实报告，而不是静默成功。

同时新增 docs/23-记忆分层与画像设计.md：短期/中期/长期/画像四层各自存在哪里、谁写、
提升门槛、是否进画像，以及三条路径（问卷/行为/对话）在画像层汇合的设计。

验证：ruff 通过、mypy 109 文件无错；tools/rebuild_profile.py 对客户 9001 连续两次重建
产生 version=1/2 两条快照且 is_current 正确轮转（旧版本置 0）。
 2026-09-10 21:36:23 +08:00
zhangshy a94d5c754d feat: 迁移奶龙风控业务模块与演示文档 2026-09-10 21:03:44 +08:00
lzf_0626 a876e9ead7 docs: 新增四大 Agent 流程实现拆解（客服/投顾/风控/场外运营） 
对四份需求文档（智能客服方案 v1.3、基金运营流程、风控模块详细业务流程、投资顾问流程）
与现有底座逐项比对后的实现拆解，用于开工前明确边界、工作量与决策点。

核心结论：可实现。底座 52 张表与流程设计高度吻合——风控的
ack_status/is_escalated/close_reason/trigger_rule_codes、客服的 svc_handover_ticket.confidence、
投顾的 client_facing_content.review_status、biz_work_order 的双录与风险揭示字段均已在位；
客服方案的七步骨架与 BaseAgent 骨架完全一致；适当性 C1-C5/R1-R5 已实现且不接受调用方传值；
风控文档定义的 SSE 事件（start/tools/delta/replace/done）与底座现有实现完全一致。

文档内容：
1. 覆盖度总览 + 四模块逐项拆解（已就绪 / 需新写 / 必须业务补充）。
2. 指出两处真实缺口：邮件 SMTP 在 app/ 中零实现；规则引擎只有 trigger_rule_codes 字段
   而无引擎本体（风控明确要求"规则引擎产生预警、Agent 不产生"，属确定性逻辑，不能用模型代替）。
3. 指出场外运营是唯一需要新建表的模块（底座 15 张 fin_* 全为场内模拟交易，
   AGENTS.md 要求场外流程独立，不得写入场内交易表）。
4. 列出 6 个必须先决策的事项：接口形态（底座异步 + SSE vs 方案的同步 chat/customer）、
   模型与 embedding 维度（直接决定 Milvus 集合 schema）、RAG 混合判定公式（方案未给）、
   规则引擎的承载方式、场外运营排期、合规校验前置还是后置。
5. 建议开工顺序：客服 → 投顾 → 风控（规则引擎宜单独立项）→ 场外运营（缺真实单据样本）。

说明：本提交只含拆解文档，不含需求原文。需求原文的纯文本提取物位于 _flows/（未跟踪），
是否入库待定；临时提取脚本已删除。
 2026-09-10 18:35:52 +08:00
lzf_0626 2c5ef35d18 chore: 删除退役的旧 JWT 密钥，同步过时引用并记录登录接口决策 
1. 删除 config/jwt/jwt-private.pem 与 jwt-public.pem（旧密钥，配置已不再指向）。
   删除后复跑全量门禁以确认没有残留依赖：ruff 通过、unit+contract 447 passed、
   acceptance_check --production 7 PASS、demo_agent_e2e 9/9 PASS。
2. 修掉 4 处引用旧密钥路径的地方（它们会在删除密钥后直接失败或误导接入方）：
   - tests/unit/core/test_security.py 的三处硬编码路径改为单一常量 DEV_KEY_DIR，
     否则删除旧密钥后该测试会因读不到文件而失败；
   - tools/demo_agent_e2e.py 的 docstring 前置条件；
   - docs/09 的配置示例；docs/19 的手工自签说明（改为指向配置项与
     tools/generate_jwt_keys.py）。
3. docs/21 记录旧密钥已删除，并注明删除后已复跑验证无残留引用。
4. docs/19 未解决项新增第 5 条：无登录接口属于**有意识的推迟**（等业务 Agent 开发阶段
   结束后再补），写明补的时候只需动签发侧、验签侧与身份解析侧都不需要改，
   并附上当前私钥边界的实测结论（无法伪造不存在的用户、无法使用已禁用账号）。
 2026-09-10 18:18:00 +08:00
lzf_0626 c32d3dbd06 chore: 开发专用 JWT 密钥、密钥生成脚本与轮换文档 
背景：此前全环境共用一把 JWT 密钥（config/jwt/jwt-private.pem）。它相当于
"能冒充 9001/9002/9003 的万能钥匙"（实测边界：签名有效 + 用户存在且启用才通过，
伪造新用户与使用禁用账号都会被拒）。为避免同一把密钥将来又变成生产密钥，
本次引入开发专用密钥，并把签发侧收敛到配置。

改动：
1. 新增 tools/generate_jwt_keys.py：可复现地生成 RS256 密钥对（PKCS#8 / SPKI），
   打印公钥 SHA-256 指纹便于核对服务端加载的是否同一把；密钥已存在时默认拒绝
   覆盖，避免误操作导致所有已签发令牌立即失效。
2. 生成开发专用密钥到 config/jwt/dev/（该目录整体已被 .gitignore 忽略，不入库）。
3. 三个工具脚本不再硬编码私钥路径，改为读配置：acceptance_check 与 demo_agent_e2e
   走 get_settings().jwt_private_key_path，smoke_check 因刻意不依赖 app 包而读
   JWT_PRIVATE_KEY_PATH 环境变量。今后轮换密钥只需改 .env 一处。
4. .env、.env.example 与 Settings 默认值统一指向 config/jwt/dev/。
5. 新增 docs/21-JWT密钥管理与轮换.md：密钥分工（服务端只读公钥，
   JWT_PRIVATE_KEY_PATH 在 app/ 中无任何读取点，故生产机可只挂公钥）、
   克隆后必须自行生成、多人共用一个服务时必须共用同一把私钥、
   轮换的影响面与生产部署要点、安全红线。
6. 记录一处易被忽略的问题：生产环境的 JWT_ISSUER / JWT_AUDIENCE 也应与开发不同，
   否则开发环境签发的令牌在生产上依然有效——这比换密钥更容易漏。

说明：本次提交不含任何密钥文件（.env 与 config/jwt/ 均在 .gitignore 中）。
旧密钥 config/jwt/jwt-private.pem 已退役但保留未删，配置不再引用它，
用它签发的令牌会被拒绝。

验证：ruff 通过、mypy 103 文件无错、unit+contract 447 passed、integration 29 passed、
acceptance_check --production 7 PASS、demo_agent_e2e 9/9 PASS——均使用新密钥完成
签发与验签。
 2026-09-10 18:14:03 +08:00
lzf_0626 6516ccb385 feat: 第二版——接口契约对齐 docs/05，修复静默故障与数据库基线 
相对第一版 46fc976 的完整变更。组员迁移对照表见 docs/20。

一、对外契约对齐 docs/05（破坏性，共 4 处，组员需按 docs/20 调整）
1) 配置发布端点改为文档规定的复数资源名：submit→validations、
   approve→reviews（需 body decision）、activate→activations、
   rollback→rollbacks；第一版这 4 个动词式路径 docs/05 从未定义过。
2) 错误码由 8 个笼统码改为 15 个具体语义码（FORBIDDEN→AGENT_PERMISSION_DENIED、
   UNAUTHORIZED→AUTHENTICATION_REQUIRED、CONFLICT→RESOURCE_VERSION_CONFLICT、
   RESOURCE_NOT_FOUND→RUN_NOT_FOUND/SESSION_NOT_FOUND 等），
   输入类错误状态码 400→422。
3) POST /api/v1/agent-runs 与 GET /api/v1/agent-runs/{run_id} 统一为
   {data, meta} 信封（data 内字段名与语义未变）。
4) 错误响应体统一为 {error:{code,message,retryable,field_errors}, meta:{trace_id}}，
   不再返回 FastAPI 默认的 {"detail": ...}。

二、数据库基线与约束
新增 39 张表的基线迁移（链根）与联合唯一键纠偏（4 张表、删 8 增 4，幂等收敛）；
撤下 config_release 的双人复核 CHECK（应用层已允许自审，审核节点保留，
自审如实写入 reviewer_id）；记忆 active key 生成列与唯一键；
activate 开始记录 supersedes_release_id 使版本链可追溯。
docs/00 基线未修改，未重命名或删除任何表与字段。

三、修复会静默出错或无报错的缺陷
- 跑完集成测试后平台会静默失去生效配置：清理只删自己创建的版本，却没有恢复被它
  顶成 superseded 的原生效版本，且审计一并删除因而完全无痕，表现为所有工具被拒
  但没有任何报错。已修清理逻辑并加恢复。
- Worker 单轮异常导致进程退出；记忆抽取调用方的“事务已开始”异常；
  召回缓存丢失 degraded 标记；连接时区未生效导致 created_at/updated_at 差 8 小时；
  .env 与 os.getenv 密钥来源分裂导致“没有可用的已批准模型端点”。
- 记忆信号识别漏判与跨键误命中；SSE 未带 Accept 的协商行为。

四、功能补齐
记忆链路 P1/P2/P3（抽取、受控词表、召回与缓存、生命周期级联及投影事件）、
fin_* 场内交易只读 ORM 层、agent_intent_config 状态流转并在运行期真正生效、
限流（Redis 固定窗口、故障一律放行）、游标校验、trace_id 中间件、
示例业务 Agent fund_query_demo 与一键端到端验证脚本，以及审计/指纹/迁移状态工具。

五、文档与验证
新增 docs/19（业务 Agent 接入实操）、docs/20（第一版迁移指南）与 docs/evidence 证据；
docs/01/02/06/08/09/17 同步实现现状。

验证结果：ruff 通过、mypy 103 文件无错、unit+contract 447 passed、
integration 29 passed、acceptance_check --production 7 PASS、
demo_agent_e2e 9/9 PASS（含失败关闭反证）。
 2026-09-10 15:55:54 +08:00
lzf_0626 46fc976b24 feat: add shared fund quote capability 2026-09-09 23:40:35 +08:00
Codex b1497fd2c6 chore: initialize project repository 2026-09-09 21:55:37 +08:00