项目背景：从手工盯盘到 AI 全自动交易
加密货币合约市场 7×24 小时不间断交易，人工盯盘面临响应延迟、情绪化决策、规则执行不一致三大核心难题。客户是一位拥有 10+ 年经验的量化交易开发者，此前使用规则策略 + 单一交易对的 1.0 版本，面临以下痛点：
- 响应延迟：行情瞬息万变，人工识别信号到下单通常需要 10-30 秒，极端行情（插针/闪崩）人工完全无法应对
- 情绪化决策：亏损会慌、盈利会贪，止损位被”再看看”的心理突破，规则一旦被打破就满盘皆输
- 多周期难兼顾：专业交易需同时看 5m/15m/30m/1h/4h/1d 六个周期，9 种技术指标人工计算耗时巨大，交易对超过 5 个就不可持续
解决思路：让 AI 承担所有决策与执行，人只负责系统设计与风控审计。AI 不睡觉、不情绪化，可以同时监控 9 个交易对 × 6 个周期 × 9 个指标，让量化策略摆脱”人”的瓶颈，回归”系统”的本质。
解决方案：五大 Agent 协同的智能交易闭环
不是单一模型包打天下，而是按”决策 → 仓位 → 执行 → 风控 → 复盘”全链路拆分为 5 个独立 Agent，每个 Agent 职责单一、解耦清晰、可独立升级。
| Agent | 职责 | 核心技术 |
|---|---|---|
| 开仓决策 Agent | 判断”该不该开仓”，综合 6 周期 K 线 + 9 种技术指标 + 盘口深度，输出 LONG / SHORT / NO_ACTION | 支持 4+ AI 模型、reasoning 思考模式、cache_hit 缓存 |
| 仓位管理 Agent | 持仓期间持续评估未实现盈亏、市场变化，决定”持有/平仓/调止损” | 独立 reasoning 链路、调整止盈止损位 |
| 追踪止盈 Agent | 已盈利时的保护机制，5 级阶梯式追踪，盈利回撤自动平仓 | 1 秒监控频率、每级独立配置 |
| 风控熔断 Agent | 交易对级 + 平台级双重熔断，连续亏损自动暂停 | algo order 止损单、开仓即挂 |
| 报告分析 Agent | 事后复盘，15 个页面 Web 看板，胜率/盈亏/置信度全可视化 | 每日 AI 调用统计、1 秒粒度盈亏历史 |
系统架构：四层解耦的生产级设计
系统采用四层架构：前端展示层、业务路由层、AI 模型层、数据与基础设施层，层层解耦，单点故障不蔓延。
| 层级 | 技术栈 | 核心组件 |
|---|---|---|
| 前端展示层 | Vue 3 SPA 单页应用 | 15 个核心页面（仪表盘/订单/K线/分析等）、TradingView 风格 K 线图、WebSocket 实时刷新、深色专业主题 |
| 业务路由层 | FastAPI + asyncio, 4 workers | 17 个路由模块、API + WebSocket 双通道、文件锁单实例、CORS 白名单、配置热更新 |
| AI 模型层 | 多模型 + 推理优化 | Qwen-Plus (200K context) + DeepSeek-V3 (reasoning) + Claude/GPT 可扩展、cache_hit 缓存命中节省 70-85% token |
| 数据基础设施层 | SQLite + Binance API + systemd | 25 张数据表全审计、Binance Futures WebSocket 双向通信、算法单自动止损、单实例 systemd 服务化 |
技术栈全景：从前端到 AI 推理
| 层级 | 技术选型 | 核心能力 |
|---|---|---|
| 前端层 | Vue 3 SPA | 15 个核心页面、TradingView 风格 K 线图、WebSocket 实时刷新、深色专业主题（涨红跌绿） |
| 后端层 | FastAPI + asyncio | 4 worker 并发、17 个路由模块、文件锁单实例、CORS 白名单 + 速率限制 |
| AI 层 | 多模型 + 推理优化 | 4+ AI 模型配置、reasoning 思考模式、cache_hit 缓存（节省 70-85% token）、9 种技术指标预计算、标签系统 |
| 数据层 | SQLite + MessagePack | 25 张数据表、K 线按需订阅、盈亏 1 秒粒度、每日余额快照 + AI 调用统计 |
| 交易所层 | Binance Futures API | 用户数据流 + 市场数据流、订单 5 秒同步、算法单自动止损、5-10x 杠杆 |
| 部署层 | Linux + systemd | install.sh/update.sh 一键脚本、配置热更新、journalctl 实时日志、2GB 可运行 |
管理后台：15 个核心页面
前端 SPA 覆盖交易全生命周期——从监控到决策追溯，从提示词调优到数据导出。
| 页面 | 路由 | 功能 |
|---|---|---|
| 仪表盘 | /dashboard | 账户总览、盈亏趋势、AI 调用统计，6 个时间维度切换 |
| 订单管理 | /orders | 订单列表 500 条，按状态/交易对筛选，手动平仓 |
| 订单详情 | /orders/:id | 盈亏走势图（含追踪止盈线）、AI 决策记录、仓位管理历史 |
| K 线分析 | /kline-analysis | 6 周期切换、9 种指标叠加、开仓/平仓/AI 决策标记 |
| 追踪止盈 | /trailing-stop | 5 级配置与实时状态监控，独立全局开关 |
| 提示词管理 | /prompts | 多版本并存、一键激活、激活日志追溯 |
| 提示词分析 | /analysis | 版本 A/B 对比、胜率分析、置信度分布 |
| 标签分析 | /tag-analysis | 订单标签统计、胜率排名（趋势共振/多头排列等） |
| AI 交互日志 | /logs/ai-interaction | K 线快照、提示词、模型输出、reasoning 思考链全保留 |
| 系统设置 | /settings | Binance/AI/引擎配置 + 连接测试 + 数据清理 |
风控体系：5 级追踪止盈 + 双重熔断器
“先活下来，再追求收益”——所有决策都附带多层风控保护。
5 级阶梯式追踪止盈
| 级别 | 触发条件 | 保护动作 |
|---|---|---|
| L1 | 浮盈 ≥ 1% | 止损移至开仓价（保本） |
| L2 | 浮盈 ≥ 3% | 锁定 50% 利润 |
| L3 | 浮盈 ≥ 5% | 锁定 70% 利润 |
| L4 | 浮盈 ≥ 8% | 锁定 85% 利润 |
| L5 | 浮盈 ≥ 12% | 追踪最高点回撤 2% 平仓 |
双重熔断器
| 维度 | 触发条件 | 动作 |
|---|---|---|
| 交易对级 | 连续 2 次亏损 / 4h 窗口 | 暂停该交易对 6 小时 |
| 交易对级 | 亏损金额超阈值 | 立即暂停该交易对 |
| 平台级 | 连续 5 次亏损 / 8h 窗口 | 全局暂停 12 小时 |
| 止损单 | 开仓即挂 | algo order 自动触发 |
| 风控指标 | 数值 |
|---|---|
| 追踪止盈监控频率 | 1 秒 |
| 订单状态同步 | 5 秒 |
| 默认止损比例 | 6% |
| 平仓后继续监控 | 30 分钟 |
数据库设计：25 张表全审计
每一笔交易、每一次 AI 决策、每一档止盈触发，全部持久化、可追溯、可分析。
| 分类 | 表数量 | 核心表 |
|---|---|---|
| 交易类 | 3 | orders · child_orders · tp_sl_orders |
| AI 决策 | 3 | model_records · position_management · ai_decisions |
| 提示词 | 2 | prompt_versions · prompt_activation_logs |
| 监控 | 4 | order_pnl_history · trailing_stop_configs · trailing_stop_states |
| 统计 | 4 | daily_ai_stats · daily_balance_snapshots · tag_statistics · tag_quality |
| 系统 | 8 | users · page_permissions · api_keys · device_sessions · system_logs |
| 市场 | 1 | trading_pairs |
部署与运维：2GB 内存即可生产
极简部署、配置热更新、systemd 服务化、完整日志。
- 最低内存需求：2GB（推荐 4GB）
- Python 3.10+（推荐 3.12），Node.js 18+（前端编译）
- SQLite 3.x系统自带，零运维成本
- 一键部署：install.sh / update.sh 脚本
- 配置热更新：通过 API 修改配置无需重启服务
- 实时日志：journalctl -u trading2.0 -f
开发历程：从 MVP 到生产级
| 版本 | 阶段 | 核心变化 |
|---|---|---|
| v1.0 | 起步 | 规则策略 + 单一交易对（BTC），验证自动下单 + 止损基础链路 |
| v1.5 | 扩展 | 多交易对（5 个）+ Vue Web 管理后台 + WebSocket 实时推送 |
| v2.0-alpha | AI 接入 | Qwen-Plus 替代规则引擎做开仓决策，reasoning 思考模式，cache_hit 缓存 |
| v2.0-beta | 多 Agent | 决策/仓位/止盈/风控拆为独立 Agent，5 级追踪止盈、双重熔断器 |
| v2.0-stable | 当前版本 | 9 交易对实盘、25 张数据表、15 管理页面、4 worker systemd 服务，稳定运行 |
开发者复盘
“从规则策略到 AI 大模型决策，最大的变化不是策略本身变强了，而是决策可追溯、可复盘、可调优。以前规则写死，改一个参数全盘推倒重测；现在每个 AI 决策都有完整的 reasoning 思考链、提示词版本、K 线快照，任何一次盈利或亏损都能精确归因。”
—— 张先生 · Trading System 2.0 作者 / 全栈独立开发者
三点核心思考
- 决策可解释：每个 AI 决策都附带 reasoning 思考链，告诉你”AI 为什么这样想”，而不是丢一个结论就跑
- 提示词可 A/B：多版本并存、随时切换，胜率差异一目了然。提示词迭代从”凭感觉”变成”看数据”
- 亏损可归因：熔断器、标签统计、置信度分析——亏损不再模糊，而是落到具体标签、具体时段、具体提示词
常见问题
AI 决策比规则策略到底好在哪里？
三点本质区别：① 多周期融合——AI 能同时理解 6 周期 K 线的共振，规则只能写死阈值；② 上下文记忆——AI 能结合历史决策、市场环境做出判断，规则是”近视眼”；③ 自适应——同一套提示词在不同行情阶段表现不同，标签系统能识别哪些场景胜率高，主动加权。
为什么用 SQLite 而不是 PostgreSQL / MySQL？
本系统单实例部署为主、写入并发可控（订单/决策写入峰值约 10 QPS），SQLite 在这种场景下运维成本为零、性能稳定、备份简单（一个文件）。如果未来需要多实例横向扩展，SQLite 可平滑迁移到 PostgreSQL（25 张表结构已抽象）。
cache_hit 模式能省多少 token？
缓存命中模式下，相同 K 线数据复用上次决策结果，只有当 N 根新 K 线出现时才重新请求 AI。实测节省 70-85% 的 AI 调用量，对应 token 成本大幅下降。这对按 token 计费的模型尤其重要。
5 级追踪止盈具体怎么触发？
每秒扫描所有活跃持仓，当浮盈达到 L1 阈值时把止损移至开仓价；达到 L2 锁定 50% 利润；以此类推。L5 启用”追踪最高点 + 回撤 N% 平仓”策略，捕捉大波段利润。一旦盈利回撤触及当前级别的保护位，立即市价平仓。
熔断器会不会误判导致错过大行情？
熔断器设计上有意保守优先：连续亏损就暂停，宁可错过也不重仓。实盘数据表明熔断后重新启动的胜率显著高于连续亏损期（+18% 胜率提升）。如果交易对连续 6 小时熔断期内行情大爆发，可在 dashboard 手动解除。
能否对接其他交易所（OKX / Bybit / Gate）？
当前版本绑定 Binance Futures API。架构上预留了 exchange_adapter 抽象层，新增交易所只需实现：下单/撤单/查询订单、订阅行情、订阅用户数据流三个接口。预计 1-2 周可完成一个交易所的对接。
交易有风险，这套系统如何保证资金安全？
三层防护：① API Key 权限最小化（仅开启合约交易，禁止提现）；② 开仓即挂止损 algo order，即使系统宕机止损仍生效；③ 平台级熔断 + 单笔最大仓位限制。即使系统全挂，最坏情况是当前持仓按预设止损单处理，不会无限亏损。