药材谷 · 融合方案 V1

生成时间：2026-10-06　｜　依据：21 批隔离验收 + 差异提取（164 份单模块差异）　｜　本方案只出方案·不动代码·等王先生拍板
王先生指令锚点：「要融合，端到端的全部要打通，下沉到底部」·「避免踩坑，不然来回修 bug、来回修端口」·「各个板块都要归各个板块，功能键互相打通，链全部要打通」·「调度、监控、日志、角色权限、财务归档、总看」·「外部项目的要去除」·「把方案拿出来」

一、基准面核验（融合前地基确认）

53
路由文件
84
数据文件
197
业务页面
75
路由前缀
连续八批实测恒定，主工程结构零改动。融合将以「只加不减」方式挂载，不触碰现有 75 前缀。

二、★ 我方底座盘点（决定能否"端到端打通"）

王先生点名六个治理面，实测我方主工程底座如下 —— 有底座的补"面"，无底座的建"全链"：

王先生点名全站实测我方底座融合评级
日志61 命中✅ write_operate_log 五字段 JSONL 底座有底座·缺查询面
总看看板 40 · 总控 46✅ dashboard.py + 2 看板页有底座·缺聚合
调度任务调度 = 0❌ 无真空白·建全链
监控实例监控 0 · 心跳 0❌ 无真空白·建全链
角色权限权限 11⚠️ 仅 system_dict 有权限字样·无 RBAC 表半空白·先建底座
财务归档归档 131❌ 命中词全在金融页面 → 撞死命令直接剔除
★ 关键发现：operate_log.jsonl 里「智能体集群 / Agent」高频出现（161 + 93 条）→ 我方日志已在记录 Agent 行为。这是调度/监控/总看三个治理面唯一现成的数据源，融合治理层应复用此底座，绝不另起炉灶。

三、融合候选总表（23 模块 · 四级分类）

8
A 类·有底座补面
8
B 类·补链中风险
5
C 类·治理建全链
3
D 类·待激活
编号模块(前缀)所属板块我方现有承载增量点合并方式风险优先
A1 log_query 治理·日志 write_operate_log + operate_log.jsonl ✅有底座 日志查询/检索/筛选/异常识别面（155+条已有数据） 新增查询路由 query_log.py + 1 管理页，读现有 JSONL 低 P0
A2 ops_monitor 治理·监控 operate_log.json 已记 Agent 行为 ✅部分底座 服务器状态总览/系统告警/备份状态（CPU/内存/在线数） 新增 ops_monitor.py 读 psutil + 现有日志 低 P0
A3 total_board 治理·总看 dashboard.py + gf_kanban.html ✅有底座 总控聚合看板（跨板块指标汇总/各模块健康度） 扩展 dashboard.py 加聚合端点 + 1 总看页 低 P0
A4 global_config 治理·配置 module_switches.json + system_dict.py ✅有底座 配置中心面（基础参数/服务协议/全局开关/公告模板） 扩展 system_dict.py 加配置面页面 低 P0
A5 help_center 用户·服务 无（真空白） FAQ/帮助文档/在线客服 新增 help_center.py + 帮助页（静态+搜索） 低 P1
A6 favorite 用户·行为 无（真空白） 收藏/关注/足迹 新增 favorite.py + 页面 低 P1
A7 browse_history 用户·行为 无（真空白） 浏览历史/浏览记录 并入 favorite 模块（同属用户行为面） 低 P1
A8 feedback 用户·服务 无（真空白） 意见反馈/建议/投诉工单 新增 feedback.py + 页面 低 P1
B1 address_book 交易·基础 无（真空白·全站收货地址=0） 收货地址簿（增删改/默认地址） 新增 address_book.py + 页面，为订单链补前置 中 P1
B2 user_setting 用户·账号 auth_service 鉴权底座（非业务面） 个人资料/改密/绑定/通知偏好 新增 user_setting.py 业务面（复用 auth 底座） 中 P1
B3 goods_publish 交易·撮合 trade.py/bulk_trade.py（订单式撮合） C2C 商品发布台（上架中/审核中/已下架） 新增 goods_publish.py，对接现有撮合底盘 中 P1
B4 mall_cart 交易·商城 无（真空白·全站购物车=0） ★购物车/加购/去结算（交易闭环最大断点） 新增 mall_cart.py，独立于订单式撮合 中 P0
B5 logistics_trans 交易·物流 admin_storage_logistics.py（仓储语义）✅半底座 ★运输链：服务商比价→托运→轨迹→签收→异常（五现成立） 新增 logistics_trans.py，与 storage 分家 中 P0
B6 account_mgr 用户·账号 auth_service 鉴权底座 商户入驻/资质上传/审核进度/资质到期预警 新增 account_mgr.py（资质面） 中 P1
B7 complaint 用户·服务 mediation 系劳务调解（职责不同） 平台交易维权工单/举证/调解/仲裁 新增 complaint.py（区别于劳务调解） 中 P1
B8 trace 交易·溯源 live_trace/live_trace_v2（直播溯源）✅半底座 溯源码分配/扫码核验/产区点位/六段全链路上链 扩展 live_trace + 新溯源查询面 中 P1
C1 agent_dispatch 治理·调度 ❌ 全站任务调度=0 Agent 任务调度工作台（分发/排队/优先级） 新建全链：路由+数据+上链+日志+开关 高 P0
C2 agent_instance 治理·监控 ❌ 全站实例监控=0·心跳=0 Agent 实例监控（负载/心跳/GPU/生命周期） 新建全链（复用 operate_log 数据源） 高 P0
C3 agent_audit 治理·日志 ✅ operate_log 底座（Agent 行为已记录 161+93） Agent 任务审计日志（与 operate_log 分层） 扩展日志底座 + 审计查询面 中 P0
C4 agent_role 治理·权限 ⚠️ 半空白（无 RBAC 表） Agent 角色权限配置（角色/权限/边界） ★须先建 RBAC 底座，再配权限面 高 P1
C5 artifact_archive 治理·归档 ❌ 全站产物归档=0（归档词撞金融面） 产物文件归档库（产物/版本/检索） 新建全链（注意勿撞金融归档） 高 P2
D1 short_video 内容·视频 live_trade 直播（互补不冲突） 短视频点播/作品/上传审核 新增 short_video.py（与直播互补） 中 P2
D2 ad_slot 运营·广告 无（真空白） 广告位资源/投放/曝光统计（去结算） 新增 ad_slot.py（只取投放面） 中 P2
D3 plant_base 交易·基地 半空白 种植基地档案/点位 并入 trace/account_mgr 低 P2

四、★ 端到端链路（每个模块必须六环全通）

王先生最怕"半截链路 → 来回修 bug/端口"。融合后每个模块必须走通这条标准链：

页面(HTML) → 接口(routes/新模块.py · 前缀 /api/...) → 数据层(data/新模块.json 落盘) → 上链(chain_hash/prev_hash 前块串联) → 日志(write_operate_log 五字段) → 开关(module_switches.json module_xxx 管控)

示例：A1 日志查询 · 端到端打通

1. 页面：新增 日志审计中心.html（管理端，表格式检索）
2. 接口：新增 routes/log_query.py → 前缀 /api/admin/log_query（list/search/filter/export）
3. 数据层：不新建 —— 直接读现有 操作日志/operate_log.jsonl（155+ 条真数据）
4. 上链：日志本身即审计证据，导出时补 chain_hash
5. 日志：查询动作本身也写 write_operate_log（自洽）
6. 开关：挂 module_log_query，可一键关停
→ 全链无缺口，零风险（因数据层复用现有底座，不碰 84 个数据文件）

五、★★ 避坑清单（前置·防"来回修"）

坑 1 · 数据层地基不同（最致命）

对方稿是 SQLAlchemy ORM + db_service/db_model 分层 + JWT；我方是 JSON 落盘 + SHA256 上链 + write_operate_log。绝不整体替换 —— 所有融合模块的数据层必须按我方五段式重写。

坑 2 · 底层依赖全缺

对方 6 项依赖（db_service / db_model / auth_service / agent_global_monitor / chain_hash_util / live_community_master_api）在我方全不存在。直接搬代码必 ImportError → 服务起不来。

坑 3 · 端口占用冲突

冻结端口：80 药材谷网页端 · 8979 FastAPI · 8000 外部项目（保护令·绝不动）。2026-10-06 端口整合后收敛为两服务模型（8978 老原型 / 4000 老 demo 后端已下线并入），融合不新增端口，全部并入 8979 的 include_router。

坑 4 · 路由名撞车（假命中）

我方 agent_service=产业中介代办、agent_broker=经纪人，≠ Agent 集群。新建 agent_* 路由时须避开语义碰撞，命名加 agentops_ 前缀区分。

坑 5 · 关键词统计被自产报告污染

工程根目录 16+ 份 验收对照报告 复述关键词 → count() 虚高。任何统计必须 if f.startswith('验收对照报告'): continue。

坑 6 · 上游构建脚本回生成

卦象清理必须连同 _build_compass.py（上游构建脚本）一起清 —— 只清成品页面，脚本会持续回生成。

坑 7 · Windows 路径编码

非 ASCII 路径脚本写入易乱码。临时脚本统一放 C:/Users/asus/AppData/Local/Temp/b_fuse/，不写 .bat/.ps1。

六、★★ 死命令执行清单（三类一律剔除）

类别涉及范围处置
八八六十四卦292 全息罗盘导航中心整段剔除 + 反向清理我方 13 文件（含上游 _build_compass.py，不清会回生成）
金融板块296 财务对账结算 / 297 积分权益商城 / 308 平台账单结算 / 323 发票 / 338 余额账户 / 339 提现整段剔除·不入库（我方定位：撮合交易·只收信息费/服务费）
金融夹带316 售后(赔付结算) / 319 账户安全(资金二次验证) / 348 账户与安全(支付密码)剔金融留业务
外部项目/外部项目360 项目任务总看板（含对方自家「外部项目APP」）整段剔除（跨项目污染）
财务归档治理层「财务归档」面★剔除——归档词全撞金融页面，只保留非金融产物归档 C5

七、板块归位对照（不新起孤岛）

新模块归入现有板块对接的功能键
A1 日志查询 / C3 Agent审计治理·日志operate_log 底座 · system_dict 审计入口
A2 运维监控 / C2 实例监控治理·监控dashboard 看板 · 服务器状态
A3 总看板 / C1 调度 / C5 归档治理·总看dashboard.py 聚合 · 各模块健康度
A4 全局配置 / C4 角色权限治理·配置权限system_dict · module_switches
B4 购物车 / B3 商品发布 / B1 地址交易·商城链对接 trade.py / bulk_trade.py 撮合底盘
B5 物流运输交易·物流与 admin_storage_logistics 分家（仓储→运输）
B6 账号管理 / B7 投诉 / B8 溯源用户·服务auth 底座 · mediation 区分 · live_trace 扩展

八、分批实施顺序（先低风险后高风险）

第一批 P0 有底座补面（零新增依赖·最安全）

第二批 P1 补链（中风险·需对接现有底盘）

第三批 P0/P1 治理层建全链（高风险·王先生点名）

第四批 P2 待激活 + 存量清理

药材谷 · 融合方案 V1 · 2026-10-06 · 本方案为规划稿，主工程一行未改
等王先生拍板后，按「分批实施顺序」逐步融合 · 每步先验端到端再进下一步