2 Commits

Include renames

Author	SHA1	Message	Date
lzf_0626	36c7a9d8d2	文档：审查报告入库 + 全量校对补注 ... ## 新入库（`docs/演示用/`） - `代码库全面审查报告-2026-09-14.md` - `代码修改方案-2026-09-14.md` - `记忆系统排查报告-2026-09-14.md` - `记忆系统修复文档-2026-09-14.md` - `文档一致性审计报告-2026-09-14.md` - `多Worker接入方案-2026-09-14.md` ## 全量校对（32 个既有文档 + `AGENTS.md`） 跨 39 个文件、**1125 insertions / 148 deletions**。 ⚠️ **这批改动同样不是本次会话写的**。我抽样核对过性质：是**实质内容补充**而不是 格式/换行转换。例如 `docs/44-演示流程.md` 新增两条"2026-09-14 补注"： - `启动金融Agent平台.bat` 只在**桌面**上，仓库里只有 `启动平台.bat` 这一份 （两份由同一个 `tools/make_launcher_bat.py` 产出，改完 `start.ps1` 重跑它一起更新）； - `advisor_t`(9020) 与 `offsite_t`(9006) **不在 `tools/seed_test_rbac.py` 的演示用户里** （那里只有 `cust_t`/`risk_t`/`admin_t`/`review_t` 四个），由 `grant_*.py` 系列创建， **重跑种子不会重建它们** —— 换机器时这两个账号登录失败，要先查 `sys_user` 有没有这两行， 而不是查密码。 这两条都是对的地方，与我这一路踩到的现象一致（我确实用到了 `advisor_t`/`offsite_t`）。 **我没有逐字审阅全部 39 个文件**，只抽样确认了改动性质与规模。若其中有需要复核的段落， 请指明文件，我逐处核对。	2026-09-14 20:36:00 +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