AI Trading Matrix Current Practice Profile

状态：Draft / Batch 1-6 已填充入口、对象接口、核心编排、执行反馈、执行治理与前端体验证据 最后更新：2026-05-12 项目：AI Trading Matrix 本地仓库：/Users/mlabs/Programs/trading-matrix

1. 本文档定位

本文档用于建立 AI Trading Matrix 当前本地实践版本画像。

它应先于最新 NOFX gap 评估、其他第三方参考项目筛选 / 深度评估和项目实施方案产生，用来回答：

• 当前实践到底已经实现了什么；
• 哪些能力已体现为当前 Trading Matrix 实践，哪些历史来源只需要追溯；
• 哪些能力是 Trading Matrix 自身迁移、改造、替代或新增；
• 当前交易执行、回测、策略、虚拟交易员、赛马机制、授权、审计、风控和反馈能力实际处于什么状态；
• 哪些事实可以进入后续最新 NOFX gap 评估和其他第三方参考评估，哪些仍需核验。

本文档不是产品定义、MVP 定义、系统设计或正式需求。

2. 分批画像协议

为避免上下文爆炸，当前实践画像按批次完成。

每批只读取必要文件，并输出：

• evidence；
• current capability；
• gap；
• risk；
• next read targets。

建议批次：

批次	范围	目标
Batch 1	仓库结构、README、docs/prd/trading-matrix、server/web 入口	建立当前实践总体地图和后续读取路线，不进入 backtest / strategy / trader 细节
Batch 2	数据模型、SQL、API、server internal model / logic	建立对象和接口地图
Batch 3	backtest、event backtest、strategy、trader、arena / competition	建立核心交易执行能力画像
Batch 4	order、position、exchange、account、execution feedback	建立执行链路和反馈画像
Batch 5	auth、audit、risk、permission、logs、config	建立授权、审计、风控和责任边界画像
Batch 6	web 页面、用户路径、截图或本地体验	建立产品体验画像

Batch 1 读取边界

允许读取：

• /Users/mlabs/Programs/trading-matrix/README.md
• /Users/mlabs/Programs/trading-matrix/server/README.md
• /Users/mlabs/Programs/trading-matrix/web/README.md
• /Users/mlabs/Programs/trading-matrix/docs/prd/trading-matrix/*
• server / web 的入口文件、目录结构和配置入口

暂不读取：

• backtest 具体实现；
• strategy / trader 具体实现；
• arena / competition 具体实现；
• order / position / exchange 深层实现；
• NOFX 子模块；
• 最新 NOFX 仓库；
• 外部参考候选项目。

Batch 1 输出只回答：

• 当前实践版本的产品 / 系统入口是什么；
• server / web 大致承担什么；
• 已有产品文档如何描述 Trading Matrix；
• 后续应按什么顺序进入 Batch 2 到 Batch 6；
• 哪些问题需要在后续批次核验。

Batch 1 只填充本文档中的：

• 3. 当前实践摘要；
• 4. 仓库与运行状态；
• 7. 后续对照输入；
• 8. 待复核问题。

Batch 1 不填完整 5. 能力画像 和 6. 执行治理画像；这两部分由 Batch 2 到 Batch 6 分批补齐。

3. 当前实践摘要

Batch 1 入口级读取显示，当前本地实践版本已经不是单纯的概念文档或外部参考集合，而是一个包含后端服务、前端应用、产品文档和早期 NOFX / Data Horizon 参考目录的本地工程实践仓库。

当前仓库内的旧有产品文档仍大量使用 AI 量化交易中枢、大脑与手、Hands & Brain、AI as Brain, Code as Body 等表述。这些表述可以作为历史工程语境保留在画像证据中，但不应直接上升为生态定位；在当前已对齐的生态语义下，AI Trading Matrix 的准确定位应回到金融信息逻辑链路 感知 -> 认知 -> 执行 中的 执行 环节。

当前实践的实际产品入口主要体现在：

• 后端：server/tmserver.go 启动 go-zero REST 服务，加载配置，初始化 i18n、ServiceContext、HTTP handlers、TraderManager 自动启动、CronManager 定时任务，并在服务退出时停止交易员和 cron。
• 后端上下文：server/internal/svc/service_context.go 初始化 MySQL models、可选 Redis/session、BacktestManager 和 TraderManager。
• 配置入口：server/internal/config/config.go 暴露服务、MySQL、Redis、JWT、Backtest、Admin、Proxy、MarketData、DataHorizon 等配置结构；本批次只确认配置类别，不记录任何本地密钥或敏感值。
• 前端：web/src/main.tsx 挂载 React 应用，web/src/components/Providers.tsx 组合 React Query、i18n、BrowserRouter、全局 unauthorized 事件和 Toaster，web/src/routes/index.tsx 暴露登录/注册及受保护的 traders、strategy、dashboard、competition、debate-arena、dev-tracker、backtest、strategy-market、admin 等页面入口。
• 文档：docs/prd/trading-matrix/unified_product_doc.md 和 docs/prd/trading-matrix/architecture_design.md 明确记录了 Fork & Evolve NOFX、接入 Data Horizon、混合轮询 + 事件驱动、反馈闭环等早期设计意图。

Batch 1 只能确认这些是“入口级事实”。策略、虚拟交易员、赛马机制、回测、订单、持仓、交易所适配、风控、审计、授权和反馈闭环的真实完成度，必须在 Batch 2 到 Batch 6 中继续核验。

4. 仓库与运行状态

项目	当前事实	证据	状态
本地路径	/Users/mlabs/Programs/trading-matrix	当前任务上下文	已知
分支 / commit	main / 6710eb0a6f6f739c7c152d2af969e34a5c5e0c57	git -C /Users/mlabs/Programs/trading-matrix branch --show-current；git rev-parse HEAD	已核验
仓库形态	Go 后端、React 前端、docs、other 参考目录并存	/Users/mlabs/Programs/trading-matrix/README.md 目录结构	已核验
server 运行方式	README 记录 cd server && go run tmserver.go -f ../docs/config/config.dev.yaml；Makefile 记录 server-run 使用 server/config/config.dev.yaml	/Users/mlabs/Programs/trading-matrix/README.md；/Users/mlabs/Programs/trading-matrix/Makefile	已核验但存在配置路径差异，待后续运行验证
server 实际入口	go-zero REST 服务；启动 HTTP handlers、TraderManager 自动启动和 CronManager	/Users/mlabs/Programs/trading-matrix/server/tmserver.go	已核验
web 运行方式	README 记录 cd web && npm install && npm run dev；Makefile 记录 web-run 使用 npm run dev	/Users/mlabs/Programs/trading-matrix/README.md；/Users/mlabs/Programs/trading-matrix/Makefile	已核验，待后续运行验证
web 实际入口	React 入口经 Providers 注入 React Query、i18n、BrowserRouter，并进入 AppRoutes	/Users/mlabs/Programs/trading-matrix/web/src/main.tsx；/Users/mlabs/Programs/trading-matrix/web/src/components/Providers.tsx；/Users/mlabs/Programs/trading-matrix/web/src/routes/index.tsx	已核验
产品页面入口	traders、strategy、dashboard、competition、debate-arena、dev-tracker、backtest、strategy-market、admin	/Users/mlabs/Programs/trading-matrix/web/src/routes/index.tsx	已核验入口存在，功能完成度待后续批次
数据库 / 配置依赖	配置结构包含 MySQL、Redis、JWT、Backtest、Admin、Proxy、MarketData、DataHorizon	/Users/mlabs/Programs/trading-matrix/server/internal/config/config.go	已核验配置类别；不记录敏感配置值
后端核心上下文	ServiceContext 初始化 MySQL models、Redis/session、BacktestManager、TraderManager	/Users/mlabs/Programs/trading-matrix/server/internal/svc/service_context.go	已核验入口级依赖，内部能力待后续批次
API 聚合入口	tmserver.api 聚合 admin、auth、ai_model、exchange、strategy、trader、tracker、competition、debate、backtest、market、health、event、event_backtest 等 API	/Users/mlabs/Programs/trading-matrix/server/api/tmserver.api	已核验
路由注册	routes.go 由 goctl 生成，按 /api/* prefix 注册 API；多数业务 API 使用 JWT，/api/event/receive 和部分 /api/admin/* 未在路由层使用 JWT	/Users/mlabs/Programs/trading-matrix/server/internal/handler/routes.go；/Users/mlabs/Programs/trading-matrix/server/api/event.api；/Users/mlabs/Programs/trading-matrix/server/api/admin.api	已核验路由形态，安全语义待 Batch 5
MySQL 模型管理	Models 集中管理 User、AiModel、Exchange、Strategy、Trader、Order、Position、Fill、Equity、Decision、EventLog、EventSignal、EventBacktest、EventReplay、Debate 等模型	/Users/mlabs/Programs/trading-matrix/server/internal/model/mysql/models.go	已核验对象地图
SQL schema	docs/sql 包含 tm_* 表 schema；docs/migrate 包含 trader is_dev/is_test、event execution replay 相关迁移	/Users/mlabs/Programs/trading-matrix/docs/sql；/Users/mlabs/Programs/trading-matrix/docs/migrate	已核验 schema 索引，迁移执行状态待复核

5. 能力画像

能力域	当前实践	证据	来源判断	状态
产品入口	前端路由已暴露 traders、strategy、dashboard、competition、debate-arena、backtest、strategy-market、admin；后端 API 聚合入口覆盖同类对象	/Users/mlabs/Programs/trading-matrix/web/src/routes/index.tsx；/Users/mlabs/Programs/trading-matrix/server/api/tmserver.api	Trading Matrix 改造	Batch 1-2 入口已确认，体验待 Batch 6
Market / Exchange	API 层支持 market kline；exchange 配置支持 supported/list/add/update/delete/server-ip/test；模型层有 tm_exchange；执行适配层抽象为 pkg/trader.Trader，已覆盖 balance、position、open/close long/short、leverage、margin mode、market price、SL/TP、limit order、cancel、order status、trade sync 等接口；适配器索引显示 Binance、Bybit、OKX、Bitget、Hyperliquid、Aster、Lighter V2 等交易所实现	/Users/mlabs/Programs/trading-matrix/server/api/market.api；/Users/mlabs/Programs/trading-matrix/server/api/exchange.api；/Users/mlabs/Programs/trading-matrix/server/internal/model/mysql/exchange_model_gen.go；/Users/mlabs/Programs/trading-matrix/server/pkg/trader/interface.go；/Users/mlabs/Programs/trading-matrix/server/pkg/trader/*	历史 NOFX 来源 + Trading Matrix 改造待最新 NOFX gap 评估	Batch 4 已确认多交易所执行接口存在；各 adapter 的行为一致性、testnet 覆盖和异常语义仍需逐个验证
Strategy / Trader	Strategy API 支持策略 CRUD、激活、复制、默认配置、prompt preview、test run、public-list；Trader API 支持交易员 CRUD、start/stop、competition/test 开关、账户、持仓、决策、Kline、订单、成交、同步余额、position-event；TraderManager 会加载 trader/exchange/AI model/strategy config，创建 exchange client 与 LLM client，并以 goroutine 启动 AutoTrader；AutoTrader runCycle 会构造交易上下文、调用 LLM、解析决策、执行 actionable decisions 并保存决策记录	/Users/mlabs/Programs/trading-matrix/server/api/strategy.api；/Users/mlabs/Programs/trading-matrix/server/api/trader.api；/Users/mlabs/Programs/trading-matrix/server/internal/engine/trader_manager.go；/Users/mlabs/Programs/trading-matrix/server/internal/engine/auto_trader.go；/Users/mlabs/Programs/trading-matrix/server/internal/engine/decision_executor.go；/Users/mlabs/Programs/trading-matrix/server/internal/logic/trader/start_trader_logic.go	大量注释显示来自早期 NOFX；TraderManager.StartTrader 属 Trading Matrix go-zero 改造点	Batch 3 证明存在核心编排；真实交易所下单与状态一致性待 Batch 4
Backtest / Simulation	API 层存在 run/status/equity/trades/metrics/klines/trace/decisions/export/start/pause/resume/stop/label/delete；BacktestManager.Start 会校验配置、保存 config、创建 LLM client、加载历史 DataFeed、创建 Runner 并后台运行；BacktestStart 支持从 strategy 动态解析 symbols 并解析 AI model 凭据	/Users/mlabs/Programs/trading-matrix/server/api/backtest.api；/Users/mlabs/Programs/trading-matrix/server/pkg/backtest/manager.go；/Users/mlabs/Programs/trading-matrix/server/internal/logic/backtest/backtest_start_logic.go	待最新 NOFX gap 评估	Batch 3 证明存在可运行回测编排；数据源、runner 细节和结果可靠性待后续运行验证
Event Backtest / Replay	EventBacktestTaskCreate 创建 pending task；CronManager 每 10 秒扫描 pending task；signal_quality 模式同步 Data Horizon 信号、LLM 解析信号、运行 EventRunner；execution_replay 模式通过 replay runner 调 LLM、解析决策、模拟订单并保存 state/decision/trade	/Users/mlabs/Programs/trading-matrix/server/internal/logic/event_backtest/event_backtest_task_create_logic.go；/Users/mlabs/Programs/trading-matrix/server/internal/job/cron_manager.go；/Users/mlabs/Programs/trading-matrix/server/internal/job/event_backtest_job.go；/Users/mlabs/Programs/trading-matrix/server/internal/job/event_replay_runner.go；/Users/mlabs/Programs/trading-matrix/server/pkg/event_backtest/event_runner.go	Trading Matrix 新增或改造待判断	Batch 3 证明存在事件回测/回放编排；Data Horizon 访问、幂等和任务恢复待 Batch 4/5
Arena / Competition	Competition API 提供排行榜与权益历史批量查询；Debate API 和模型层存在 debate session/message/participant/vote；DebateEngine 可多轮调用 AI、投票、聚合 consensus 并保存 FinalDecision；但 DebateExecute 和 DebateEngine 的 AutoExecute 都仍是 TODO，仅返回“execution not yet implemented”或日志	/Users/mlabs/Programs/trading-matrix/server/api/competition.api；/Users/mlabs/Programs/trading-matrix/server/api/debate.api；/Users/mlabs/Programs/trading-matrix/server/pkg/debate/engine.go；/Users/mlabs/Programs/trading-matrix/server/internal/logic/debate/debate_execute_logic.go；/Users/mlabs/Programs/trading-matrix/server/internal/logic/competition/get_competition_list_logic.go	Trading Matrix 新增或改造待判断	Debate/arena 具备认知赛马表面，但未形成交易执行闭环；competition 更像榜单/权益排名
Execution / Order / Position	已存在真实执行链：decision executor 调用 open/close/limit order；开仓链路检查最大持仓、同向重复持仓、余额/equity、risk ratio、最小下单量、数量格式化、margin mode、market/limit order、订单确认、SL/TP；平仓链路优先查 DB position，fallback exchange position，调用 CloseLong/CloseShort，确认订单，计算 realized PnL；OrderSyncer 从交易所 trades 同步到 tm_order、tm_fill、tm_position，并通过 PositionBuilder 构建/更新持仓；EventOrderWatcher 监控 event limit order 过期并取消；账户/持仓 API 对 running trader 读 exchange 实时数据，stopped trader 使用 DB snapshot / DB position	/Users/mlabs/Programs/trading-matrix/server/internal/engine/trade_open.go；/Users/mlabs/Programs/trading-matrix/server/internal/engine/trade_close.go；/Users/mlabs/Programs/trading-matrix/server/internal/engine/order_confirm.go；/Users/mlabs/Programs/trading-matrix/server/internal/engine/order_sync.go；/Users/mlabs/Programs/trading-matrix/server/internal/engine/event_order_watcher.go；/Users/mlabs/Programs/trading-matrix/server/internal/engine/position_builder.go；/Users/mlabs/Programs/trading-matrix/server/internal/logic/trader/get_trader_account_logic.go；/Users/mlabs/Programs/trading-matrix/server/internal/logic/trader/get_trader_positions_logic.go	多处注释和模式显示继承早期 NOFX；Trading Matrix 增加 event order / replay / go-zero 侧反馈整合	Batch 4 证明执行链路真实存在；但交易状态一致性依赖 OrderSync、adapter GetTrades、订单 action 推断、event_id 回填和运行时验证
Risk / Audit / Authorization	策略配置含 RiskControlConfig；执行链路已有余额/equity、max positions、重复持仓、risk ratio、min size 等下单前检查；读账户/持仓/订单/成交多数使用 authz.CanReadTrader，同步余额、start/stop/close/update/delete/toggle 等 trader 写操作使用 authz.CanWriteTrader；admin overview 使用 JWT + admin email whitelist；event log、decision、order、fill、position 提供部分审计事实；但 /api/event/receive 无路由层 JWT，两个 admin debug/sync 路由无 JWT 且只靠 QuerySecret，SessionMiddleware 未在 server 注册，OTP 校验逻辑打印 secret，部分 event-backtest task/signal 接口按 task id 直接读取/删除/解析，未见对象级 user 校验	/Users/mlabs/Programs/trading-matrix/server/api/strategy.api；/Users/mlabs/Programs/trading-matrix/server/api/admin.api；/Users/mlabs/Programs/trading-matrix/server/api/event.api；/Users/mlabs/Programs/trading-matrix/server/internal/handler/routes.go；/Users/mlabs/Programs/trading-matrix/server/internal/engine/trade_open.go；/Users/mlabs/Programs/trading-matrix/server/internal/authz/authz.go；/Users/mlabs/Programs/trading-matrix/server/internal/logic/admin/admin_traders_overview_logic.go；/Users/mlabs/Programs/trading-matrix/server/internal/logic/admin/admin_test_query_logic.go；/Users/mlabs/Programs/trading-matrix/server/internal/logic/admin/admin_sync_all_balances_logic.go；/Users/mlabs/Programs/trading-matrix/server/tmserver.go；/Users/mlabs/Programs/trading-matrix/server/internal/middleware/session_middleware.go；/Users/mlabs/Programs/trading-matrix/server/internal/logic/auth/verify_otp_logic.go	Trading Matrix 改造待判断	Batch 5 已确认存在基础授权与审计对象，但执行治理仍未达到真实交易/商业化门槛；webhook 鉴权、admin 暴露面、session 生效、敏感日志、对象级权限和限流需要优先整改或设计
UI / UX	前端已形成主要产品路径：登录/注册、trader/model/exchange 配置、strategy studio、dashboard、event log、position-event modal、competition、debate arena、backtest/event replay、admin overview；trader start/stop 是列表一键动作，dashboard close position 有浏览器 confirm，admin overview 有只读 banner，debate execute 有 modal warning；但前端未显式展示 webhook 可信来源/签名状态、自动恢复交易员风险、SL/TP 设置失败或未保护仓位状态、session 是否强校验、admin debug/sync 后门、debate execute 后端未闭环等治理事实	/Users/mlabs/Programs/trading-matrix/web/src/routes/index.tsx；/Users/mlabs/Programs/trading-matrix/web/src/features/traders/components/AiTradersPage.tsx；/Users/mlabs/Programs/trading-matrix/web/src/features/traders/components/traders/TraderList.tsx；/Users/mlabs/Programs/trading-matrix/web/src/features/dashboard/routes/DashboardRoute.tsx；/Users/mlabs/Programs/trading-matrix/web/src/features/dashboard/components/EventLog.tsx；/Users/mlabs/Programs/trading-matrix/web/src/features/dashboard/components/EventOrderModal.tsx；/Users/mlabs/Programs/trading-matrix/web/src/features/debate-arena/components/DebateArenaPage.tsx；/Users/mlabs/Programs/trading-matrix/web/src/features/backtest/components/BacktestPage.tsx；/Users/mlabs/Programs/trading-matrix/web/src/features/admin/components/AdminPage.tsx	Trading Matrix 改造	Batch 6 证明页面体验较完整且可构建；但风险状态展示和危险动作确认不足，真实本地联调仍依赖 backend/db/env
Architecture / Roadmap	README / PRD / 架构文档描述 Fork & Evolve NOFX、Data Horizon、混合驱动和反馈闭环；实际对象层已有事件、事件日志、事件回放、事件回测表	/Users/mlabs/Programs/trading-matrix/README.md；/Users/mlabs/Programs/trading-matrix/docs/prd/trading-matrix/*；/Users/mlabs/Programs/trading-matrix/docs/sql	待最新 NOFX gap 评估	文档意图与对象地图已确认，落地程度待后续批次

来源判断取值：

• 历史 NOFX 来源
• Trading Matrix 迁移
• Trading Matrix 改造
• Trading Matrix 新增
• 待判断

6. 执行治理画像

治理对象	当前实践	证据	风险
用户授权	多数业务路由使用 JWT；authz.CanReadTrader 允许 owner 或 admin 读取 trader；authz.CanWriteTrader 仅允许 owner 写 trader；admin overview 使用 JWT actor email 与 Admin.Emails 白名单判断	/Users/mlabs/Programs/trading-matrix/server/internal/handler/routes.go；/Users/mlabs/Programs/trading-matrix/server/internal/authz/authz.go；/Users/mlabs/Programs/trading-matrix/server/internal/logic/admin/admin_traders_overview_logic.go	读取/写入边界初步存在；但 event receive、admin test-query、admin sync-all-balances 未走 JWT；event-backtest 多个接口未见对象级 user 校验
关键确认	StartTrader、StopTrader、CloseTraderPosition、SyncTraderBalance 均需要 JWT + owner 权限；AutoStartRunningTraders 会在 server 启动时自动恢复 DB 中 is_running=1 的 trader，不需要当次人工确认	/Users/mlabs/Programs/trading-matrix/server/internal/logic/trader/start_trader_logic.go；/Users/mlabs/Programs/trading-matrix/server/internal/logic/trader/stop_trader_logic.go；/Users/mlabs/Programs/trading-matrix/server/internal/logic/trader/close_trader_position_logic.go；/Users/mlabs/Programs/trading-matrix/server/internal/logic/trader/sync_trader_balance_logic.go；/Users/mlabs/Programs/trading-matrix/server/internal/engine/trader_manager.go	人工 start/stop 有权限边界；自动恢复是高风险默认行为，缺少环境开关、确认策略或 dry-run 证据
审计记录	tm_event_log 记录 event_id、message、status、reject_reason、decision_id、received_at；tm_decision 记录 prompt、raw response、decision_json、execution_log、success/error、event_id；tm_order/tm_fill/tm_position 记录订单、成交、持仓事实	/Users/mlabs/Programs/trading-matrix/docs/sql/tm_event_log.sql；/Users/mlabs/Programs/trading-matrix/docs/sql/tm_decision.sql；/Users/mlabs/Programs/trading-matrix/docs/sql/tm_order.sql；/Users/mlabs/Programs/trading-matrix/docs/sql/tm_fill.sql；/Users/mlabs/Programs/trading-matrix/docs/sql/tm_position.sql；/Users/mlabs/Programs/trading-matrix/server/internal/engine/auto_trader.go	有交易/事件/决策事实记录，但缺少统一 audit log：谁触发、来源 IP、请求头指纹、权限判定、admin 操作、人工确认、风险告警等未形成独立审计面
风控检查	开仓前已有余额/equity、max positions、重复持仓、risk ratio、min size、margin mode、SL/TP 设置等技术检查；DrawdownMonitor 存在 emergency close 逻辑	/Users/mlabs/Programs/trading-matrix/server/internal/engine/trade_open.go；/Users/mlabs/Programs/trading-matrix/server/internal/engine/drawdown_monitor.go	技术性风控存在，但缺少产品级 risk policy：真实交易开关、环境隔离、最大日损、全局 kill switch、异常订单处理、SL/TP 失败处置等仍未对齐
可回滚条件	StopTrader 可停止 engine 并保存 final snapshot；CloseTraderPosition 可由 owner 触发单仓平仓；EventOrderWatcher 可取消过期 event limit order	/Users/mlabs/Programs/trading-matrix/server/internal/logic/trader/stop_trader_logic.go；/Users/mlabs/Programs/trading-matrix/server/internal/logic/trader/close_trader_position_logic.go；/Users/mlabs/Programs/trading-matrix/server/internal/engine/event_order_watcher.go	具备局部停止/平仓/取消能力；未见全局暂停、全账户撤单、失败补偿、自动恢复禁用、灾难回滚 runbook
责任边界	人工 trader 写操作限定 owner；admin 可读 overview；event receive 根据 trader_id 触发 running + event_trading trader；Data Horizon token 用于本系统调用 Data Horizon，不用于接收 webhook 校验	/Users/mlabs/Programs/trading-matrix/server/internal/authz/authz.go；/Users/mlabs/Programs/trading-matrix/server/internal/logic/receive_event_logic.go；/Users/mlabs/Programs/trading-matrix/server/internal/config/config.go；/Users/mlabs/Programs/trading-matrix/server/internal/job/event_backtest_job.go	外部事件源、系统操作者、trader owner、admin、自动恢复任务之间的责任边界未完全显式化
风险提示	代码层有错误返回和日志，但未见统一用户风险提示、真实交易确认、未保护仓位提示、event webhook 来源提示、admin debug 能力提示	/Users/mlabs/Programs/trading-matrix/server/internal/logic/trader/start_trader_logic.go；/Users/mlabs/Programs/trading-matrix/server/internal/engine/trade_open.go；/Users/mlabs/Programs/trading-matrix/server/internal/logic/admin/admin_test_query_logic.go	产品体验和治理文档需要补齐风险状态展示，否则“执行环节”会被用户误解为已完成生产级安全闭环

Batch 4 初步治理观察：

• 执行路径已具备技术性风控检查，但主要是下单参数和账户约束，不等于产品级执行确认、风险披露或权限治理已经成立。
• tm_order_pre 同时承担 event limit order pending ledger 与 market order event_id placeholder 两类用途；这有利于 OrderSync 回填事件关联，但语义上存在混用风险。
• market order 的即时 DB 写入路径被注释，当前 canonical record 依赖 OrderSyncer 从交易所成交回灌；如果 sync 延迟、adapter 返回不完整或服务重启窗口异常，UI/DB 反馈可能滞后或不一致。
• EventOrderWatcher 主要监控 event_trading limit order 的过期取消；非 event_id 的 limit order 当前不进入该 watcher。
• SL/TP 设置失败在开仓链路中是非致命日志，不阻断已经完成的开仓；这会产生“已开仓但未受止损/止盈保护”的风险状态。
• 账户/持仓反馈在 running trader 下优先读交易所实时数据，stopped trader 下回退到 DB snapshot / DB positions；这会导致不同运行状态下的数据新鲜度和可信度不同。

Batch 5 初步治理观察：

• JWT 是主要 API 保护机制，但当前 SessionMiddleware 没有在 tmserver.go 注册；Redis session 只在 login/OTP/logout 写删，未形成请求期强制校验。
• VerifyOtpLogic 存在 TODO: Remove sensitive log，并打印 OTP secret 与输入 code；这是明确的敏感日志风险。
• /api/event/receive 既无 route-level JWT，也未读取 DataHorizon.Token 或其他 shared secret；它只校验 trader_id、event_id 去重、trader running 和 strategy_type=event_trading，然后异步触发 event cycle。
• /api/admin/test-query 与 /api/admin/sync-all-balances 无 route-level JWT，依赖 request body password 对比 Admin.QuerySecret；AdminTestQuery 仅以 strings.HasPrefix(trimmed, "SELECT") 限制 SQL，仍可能暴露敏感数据或被复杂 SELECT 滥用。
• GetPositionEvent 已在 Batch 4 标记风险；Batch 5 复核后仍未看到显式 authz.CanReadTrader，它通过 position_id 反查 event/order，存在跨用户读取风险。
• event-backtest 多个 task/signal 接口使用 JWT 路由，但部分逻辑按 task_id / signal_id 直接读写，未见基于 user_id 的对象级权限校验；这属于回测/研究数据侧风险，虽然不直接触发真实交易。

Batch 6 初步体验观察：

• web/src/routes/index.tsx 将 traders、strategy、dashboard、competition、debate-arena、backtest、strategy-market、admin 等核心页面置于 ProtectedRoute 下；ProtectedRoute 仅检查前端 auth store 中的 token 是否存在。
• Admin 页面有前端 user.is_admin gate，且当前页面只调用 /admin/traders/overview；Batch 5 中发现的 /admin/test-query 与 /admin/sync-all-balances 没有在当前 admin 页面暴露。
• Trader list 中 start/stop 是直接按钮，未见二次确认、真实交易模式确认、自动恢复提示或“live/test/dev”强阻断；delete 有 ConfirmModal。
• Dashboard 对人工 close position 使用 window.confirm，admin readonly view 会隐藏 close 操作并展示 readonly banner；这与后端 admin read/write 边界基本一致。
• Dashboard 已展示 event log 和 position-event modal，可把 event、decision、order 关联展示给用户；但它依赖 Batch 5 标记为缺显式权限校验的 GetPositionEvent。
• Debate Arena 前端提供 Execute modal 和 warning，且会选择 running trader 执行；但后端 DebateExecute 当前未真正执行交易，mock 数据却返回 “Trade executed successfully”，存在体验层误导风险。
• Backtest 页面支持 KOL execution_replay 模式、模型选择、任务删除确认和任务状态展示；它更像研究/回放体验，而非真实交易执行体验。
• Strategy RiskControlEditor 提供 max positions、leverage、position sizing、margin usage、min confidence、event signal window 等控件；这是“策略级参数配置”体验，不等于产品级 execution governance。
• 前端构建验证通过：使用 npx pnpm@10.22.0 -C web install --frozen-lockfile 安装依赖后，npx pnpm@10.22.0 -C web build 成功；Vite 报告 JS chunk > 500 kB 警告，但不是构建失败。
• npm ci 失败，因为 package.json 与 package-lock.json 不同步；仓库 packageManager 指向 pnpm，后续本地体验应优先使用 pnpm lock。

7. 后续对照输入

本文档完成后，应作为以下工作的输入：

• ../../references/trading-matrix/nofx-reference-evaluation.md
• ../../references/trading-matrix/external-reference-candidate-analysis.md
• 后续方案阶段的 projects/trading-matrix/CONTEXT.md
• 后续方案阶段的产品定义、MVP 定义、执行治理方案或系统设计

Batch 1 已提供的后续对照输入：

• 当前实践中仍存在旧定位语言：AI 量化交易中枢、大脑与手、Hands & Brain、AI as Brain, Code as Body。后续最新 NOFX gap 评估、其他第三方参考评估和产品定义不得直接继承这些生态定位，应统一修正为 执行 环节。
• 术语迁移决定：上述 Brain / 大脑 类表述暂作为当前实践画像中的历史工程语境保留，不立即从源仓库旧文档删除；进入后续产品定义、CONTEXT 或生态事实源时，应迁移为 执行 环节，并避免把 AI Trading Matrix 重新描述成生态大脑。
• 当前实践已经具备工程入口：go-zero 后端、React 前端、配置结构、服务上下文、产品路由和 PRD/架构文档。后续评估应基于这些实际入口逐层核验，而不是只根据 README 或 PRD 判断。
• 当前实践中的 Data Horizon、NOFX、混合驱动、反馈闭环语义主要来自 README / PRD / 架构文档和启动入口，真实接口、事件、执行反馈和交易状态一致性需要后续批次核验。
• 当前实践与 NOFX 的关系不能只看 other/nofx 或最新 NOFX 仓库；必须先用本画像建立 Trading Matrix 当前实践事实，再进入当前实践 vs 最新 NOFX 的 gap 评估。
• 当前产品页面入口已经暴露 backtest、competition、debate-arena、strategy-market 等表面；这些入口是否对应可用能力，应在 Batch 3 和 Batch 6 中结合代码与本地体验验证。

Batch 2 已提供的后续对照输入：

• 当前实践对象地图已经覆盖执行产品的关键对象：User、AiModel、Exchange、Strategy、Trader、Order、Position、Fill、Equity、Decision、EventLog、EventSignal、EventBacktest、EventReplay、Debate。后续最新 NOFX gap 评估可以以这些对象为主索引，而不是从目录名或页面名开始。
• OrderModel、PositionModel、TraderModel 中有多处注释直接标明 Ported from nofx/...，说明早期 NOFX 继承点不仅在文档层，也进入了数据访问和执行状态逻辑层。
• 事件路径已经有三种对象形态：实时 webhook/event log、event signal/event backtest、event replay state/decision。后续需要区分它们分别对应 Data Horizon 实时事件、历史信号回测、执行回放，而不是混成一个“事件能力”。
• AdminTestQuery 和 AdminSyncAllBalances 在 API 定义中有 password 字段，但路由注册未显示 JWT；/api/event/receive 也未显示 JWT。后续 Batch 5 必须核验其真实鉴权、密钥校验、重放保护、审计和暴露面。
• Strategy API 的 RiskControlConfig 是配置级风控，不等于执行前风控已经生效；必须在 Batch 3 / Batch 4 核验策略配置如何进入 TraderManager、订单生成和下单链路。

Batch 3 已提供的后续对照输入：

• 当前实践已经具备核心 AutoTrader 编排：启动、自动恢复、周期轮询、事件触发、交易上下文构建、LLM 调用、决策解析、决策执行和决策记录保存；因此后续不能把它仅视为 UI/API 壳。
• event_trading 是当前实践中最贴近已对齐定位的能力形态：外部事件提供上游意图，Trading Matrix 侧负责 Parse / Complete / Validate / Execute 的执行环节；这与“不是生态大脑，而是执行环节”一致。
• runCycle 注释中仍出现 “AI decision + execution will be added in T3” 之类历史注释，但代码后续已包含 LLM 调用、解析和 executeDecisions；后续 gap 评估需要区分历史注释与当前代码事实。
• BacktestManager 和 EventBacktestJob 证明回测不是单纯页面入口，而是有后台 runner / cron 编排；但其数据源、任务恢复、结果可靠性和运行依赖仍需通过运行验证确认。
• Debate/arena 不能被归入已完成交易执行能力：DebateEngine 能产出 consensus，但 DebateExecute 与 AutoExecute 仍未接入 trader 执行逻辑。
• Batch 3 已足以证明必须继续 Batch 4：真实下单、订单确认、成交同步、持仓构建、交易所适配、event order watcher 和账户反馈是当前能力真伪的关键，不应跳过直接进入参考项目对照。

Batch 4 已提供的后续对照输入：

• 当前实践已经具备从 Decision -> exchange client -> order confirmation / trade sync -> order/fill/position/equity feedback 的真实执行链路，后续最新 NOFX gap 评估和其他第三方参考评估应以这条链路为主轴，而不是只比较页面、API 或 README。
• OrderSyncer 是当前执行反馈的核心可信源：Binance 路径使用 symbol discovery + fromId 增量同步，generic 路径使用近 24 小时 trade 拉取 + dedup；后续必须和早期 NOFX、最新 NOFX 分别比较同步策略、恢复窗口和失败补偿。
• PositionBuilder 是 DB 持仓事实的核心构建器，负责 open/average/partial close/full close 和 realized PnL 处理；它应进入最新 NOFX gap 评估与运行测试重点。
• tm_order_pre 的双重用途需要在后续设计中明确：它可以继续作为 event order pending ledger，也可以拆分出 event/order correlation placeholder，避免将 pending order 状态和事件关联状态混为一个对象。
• 多交易所支持已经有接口和 adapter 表面，但后续不能直接宣称“多市场稳定支持”；需要逐 adapter 验证 Open/Close/PlaceLimitOrder/Cancel/GetOrderStatus/GetTrades/FormatQuantity 的语义一致性。
• 当前实现里，执行反馈对交易所 adapter、OrderSync 时序和成交 action 推断的依赖很高；本阶段先把 execution-state reconciliation 上收为边界问题和待决问题，而不是直接形成设计方案。
• 执行链路已触发更高等级治理要求：真实交易、自动恢复交易员、event webhook 触发交易、admin SQL 和批量余额同步，都必须在 Batch 5 建立授权、审计、重放保护、限流、确认和禁用策略。

Batch 5 已提供的后续对照输入：

• 当前实践不能直接进入真实交易或商业化环境；必须先把 execution governance 上收为治理边界和待决问题，而不是把鉴权、审计、限流和确认视为后续运维细节。
• 最新 NOFX gap 评估时，需要单独比较 AutoStartRunningTraders 的默认行为：当前实践会按 DB is_running=1 在 server startup 自动恢复交易员，这是执行系统的高风险生命周期入口。
• webhook 触发路径应作为独立对照对象：当前 /api/event/receive 不使用 route JWT，也不校验 DataHorizon token，只靠 trader_id/event_id/strategy_type/running 状态控制；这与“Data Horizon 作为上游感知输入”之间还缺少可信边界。
• admin debug/sync 能力需要从产品能力中剥离成运维/内部工具：当前 test-query 和 sync-all-balances 无 JWT，仅 QuerySecret 保护，不适合作为普通后端 API 暴露。
• 现有审计事实分散在 event_log、decision、order、fill、position 和普通 logx 日志中；本阶段只记录为审计边界问题，是否建立统一 execution_audit_log 或等价审计对象留给后续方案阶段。
• Session 单设备设计存在实现素材，但未挂载中间件；后续如果保留该语义，必须让 SessionMiddleware 进入 server middleware chain 并补齐测试，否则不要在产品定义中宣称 session 强校验。
• event-backtest 虽不直接下真实单，但它可能包含 strategy config、AI model、信号解析结果和研究资产；对象级权限也应进入治理整改列表。

Batch 6 已提供的后续对照输入：

• 当前实践前端不是简单壳，已经覆盖执行产品的主要工作台：配置 trader/model/exchange、启动/停止 trader、查看 dashboard、关闭仓位、查看事件与订单关联、运行回测/执行回放、查看 admin overview、使用 debate arena。
• 体验层目前强化了“可执行性”，但没有同等强度展示“执行治理状态”；后续产品定义必须把 risk state、execution mode、event source trust、session/security posture、auto-restore state 作为一等 UI 对象。
• Debate arena 应在参考项目对照前标记为“认知赛马 + 未闭环执行表面”，否则前端 Execute 入口和 mock success 会把未实现后端能力误读为真实交易执行。
• Dashboard 是当前最接近执行反馈闭环的页面：account/positions/decisions/event logs/position-event/order modal 都在此汇合；后续运行体验和截图验证应优先从 Dashboard 开始。
• Trader start/stop、close position、toggle live/dev、sync balance 是高风险交互点；后续设计建议应增加分级确认、环境/账户标识、真实交易提示和操作审计回显。
• Admin 页面当前只暴露 readonly overview，这一点好于后端 admin debug/sync 暴露面；后续应保持 admin UI 不暴露 debug SQL，或把 debug SQL 移出普通服务 API。
• 前端构建已通过，说明可以进入后续本地联调；但由于本轮未启动 backend/MySQL/Redis/交易所凭据，不能把“build passed”解释为端到端可用。

8. 待复核问题

1. 是否需要为 Brain / 大脑 到 执行环节 的术语迁移单独建立迁移记录或 ADR？
2. server 启动配置路径存在 README 与 Makefile 差异：../docs/config/config.dev.yaml vs server/config/config.dev.yaml。后续运行验证时应确认当前有效启动方式。
3. ServiceContext 已初始化 BacktestManager 和 TraderManager，但其真实能力、状态恢复、安全边界和失败处理尚未核验，应进入 Batch 3 / Batch 4 / Batch 5。
4. 前端已暴露 competition、debate-arena、backtest、strategy-market 等页面入口，但页面完整度、API 连通性和体验闭环尚未核验，应进入 Batch 6。
5. 配置结构已包含 DataHorizon，但真实事件接入、认证方式、反馈写回和容错机制尚未核验，应进入 Batch 2 / Batch 4。
6. 当前实践画像至少应完成 Batch 2 和 Batch 3 后，再开始最新 NOFX gap 评估；是否需要先完成 Batch 4 的执行链路画像，取决于 Batch 3 是否能证明核心执行能力边界。
7. 涉及真实下单、账户、订单、持仓、交易所 API、自动启动交易员、定时任务的能力，一旦确认存在，必须触发执行治理和风险边界核验。
8. docs/sql schema 与实际运行数据库是否一致尚未确认；后续运行验证前不能假设所有迁移已执行。
9. AdminTestQuery 标注为 read-only SQL query，但需要在逻辑层确认是否真的限制为只读，以及 password 校验来源和失败审计。
10. AutoExecute、ExecutionResult、position-event、sync-balance 等字段或接口显示潜在执行副作用，必须在 Batch 3 / Batch 4 / Batch 5 分别核验触发条件、权限和回滚/审计证据。
11. DebateExecute 当前返回成功但实际未执行交易，这在产品体验和风险提示上都可能造成误导，应在后续设计中明确标注为未闭环或禁用执行入口。
12. TraderManager.AutoStartRunningTraders 会在服务启动时恢复 DB 中 is_running=1 的交易员；这属于高风险自动执行入口，Batch 5 必须核验默认配置、启动环境和用户确认边界。
13. event_trading webhook 没有路由层 JWT 且可异步触发 trader event cycle；Batch 5 必须核验是否存在内部 token、来源校验、重放保护和限流，否则不能进入商业化或真实交易场景。
14. Batch 4 应优先核验 trade_open.go、trade_close.go、order_confirm.go、order_sync.go、event_order_watcher.go、position_builder.go 和 pkg/trader/*，因为它们决定执行链路是否真实、可审计、可恢复。
15. Batch 4 已确认真实执行链路存在；后续运行验证前，不能把它等同于“生产可用执行系统”，还需 sandbox/testnet 级下单、取消、成交同步、服务重启恢复、长时间停机恢复和异常订单状态测试。
16. 是否应将 tm_order_pre 拆成两个概念对象：event_pending_order 与 event_order_correlation？当前混用能工作，但会增加后续审计、状态机和 UI 解释成本。
17. generic OrderSyncer 近 24 小时 trade 拉取窗口是否足以覆盖真实停机、网络异常和交易所 API 限制？若不足，后续设计需要 exchange-specific cursor / checkpoint / replay 策略。
18. 开仓成功但 SL/TP 设置失败时，系统应进入什么风险状态：继续运行、暂停该 trader、触发人工确认、还是自动平仓？当前代码倾向继续运行并记录日志，治理语义需要在 Batch 5 对齐。
19. GetPositionEvent 当前通过 position -> orders -> event_id -> event log 构造事件关联反馈，但未看到显式读权限校验；Batch 5 需要确认该接口是否可能跨用户泄露 event/order 信息。
20. 多交易所 adapter 的接口覆盖不等于行为一致；后续需要建立 adapter conformance test 或最小 sandbox smoke matrix。
21. SessionMiddleware 是否应作为正式安全边界？如果是，需要在 server 注册并补齐 session invalidation 测试；如果不是，应删除或降级其产品语义。
22. /api/event/receive 是否必须只接受 Data Horizon 或内部网关调用？如果是，需要 shared secret/JWT/mTLS/IP allowlist、timestamp/replay window、rate limit 和签名验证。
23. AdminTestQuery 是否应继续存在于服务 API 中？如果保留，至少应纳入 JWT admin、QuerySecret、SQL allowlist/AST 只读解析、结果脱敏、审计记录和环境禁用开关。
24. AutoStartRunningTraders 是否应默认开启？真实交易环境可能需要显式配置开关、环境白名单、启动时人工确认或只恢复 paper/test trader。
25. VerifyOtpLogic 的敏感日志应作为安全缺陷处理，不应等到商业化前才清理。
26. event-backtest task/signal 接口需要统一对象级权限模型；否则用户可能通过 task_id/signal_id 访问或修改他人回测资产。
27. 当前执行治理画像已足以支撑后续最新 NOFX gap 评估和其他第三方参考评估，但 Batch 6 仍需检查前端是否把这些风险状态、未完成执行闭环和危险操作显示给用户。
28. Trader start/stop 是否应增加二次确认和真实交易风险提示？当前前端一键触发，后端会启动/停止真实 AutoTrader。
29. Debate Execute 前端是否应禁用或明确标注“后端未接入真实执行”？当前后端未执行，但前端存在 Execute modal，mock 还返回成功。
30. Dashboard 是否应展示“未保护仓位”或 SL/TP 设置失败状态？Batch 4 发现 SL/TP 失败不阻断开仓，但前端未见对应风险状态。
31. Event webhook 的可信来源、签名状态、重放拦截和来源系统是否应在 event log 中展示？当前前端只展示 event 状态和内容。
32. Auto-start restored trader 是否应在前端展示为“server startup restored”，并要求用户确认继续运行？当前前端只显示 running/stopped。
33. 前端是否应将 DEV、TEST、LIVE 三种状态标准化为执行环境模型？当前存在 is_dev toggle，但其治理语义不足以覆盖真实交易环境。
34. 本地前端构建应使用 pnpm lock；package-lock.json 与 package.json 不同步，后续应决定是否删除 package-lock 或恢复 npm lock 一致性。
35. Batch 1-6 已完成当前实践画像；下一阶段应进入当前 Trading Matrix 实践 vs 最新 /Users/mlabs/Programs/nofx 仓库的 gap 评估，并并行启动其他第三方参考项目筛选 / 评估。