From Files to Ledgers: How We Evolved Freqtrade's SQLite Data Layer

你的交易系统每天都在产生数据。每笔交易的开仓原因、平仓原因、盈亏比例、持仓时长。每次风控触发的原因和上下文。每次 AI 决策的延迟和 token 消耗。

这些数据安静地躺在 SQLite 数据库里。问题是：有人在读吗？

在我们的系统中，答案是"没有"。四个 Agent 技能读的都是"快照"——当前持仓状态、当前风控状态、最新市场情报、最新提案文件。没有任何 Agent 在读历史交易数据。

这就像你开了一家公司，每天记账，但从来不翻看账本。

这篇文章是 research only，not financial advice；backtests are not live performance；not an instruction to trade。

如果你刚来 ProBitForge，可以先看系统定位：<https://www.probitforge.com/what-probitforge-is-building/>

1) 数据资产盘点：你已经有的比你以为的多

Freqtrade 有两个核心 SQLite 数据库：

tradesv3.db（主交易库）

| 表 | 关键字段 | 用途 | | --- | --- | --- | | trades | pair, strategy, open_reason, close_reason, profit_ratio, trade_duration | 每笔交易完整生命周期 | | orders | order_id, ft_trade_id, status, filled, amount | 订单级别明细 | | pairlock | pair, lock_time, reason | 当前锁定交易对 |

sentinel_memory.db（哨兵库）

| 表 | 关键字段 | 用途 | | --- | --- | --- | | sentinel_recovery_state | status, last_fast_action, consecutive_restore_signals | 恢复状态机 | | sentinel_llm_metrics | channel, decision, latency_ms, tokens_used | 每次 LLM 决策指标 | | sentinel_logs | action, reason, timestamp | 哨兵历史决策日志 | | sentinel_slow_reports | summary, recommendation, timestamp | 慢道完整报告 |

这两个数据库包含了完整的交易历史和决策历史。它们是系统的事实来源（source of truth）。但在原始架构中，它们只是"写入后等待被人类手动查看"的存档。

2) 数据盲区：Agent 看不见的地方

现有四个 Agent 技能的数据源：

| Agent 技能 | 数据源 | 类型 | | --- | --- | --- | | ft-status-read | REST API | 当前持仓快照 | | ft-risk-read | sentinel_recovery_state | 当前状态行 | | ft-market-read | latest_tg_intel.txt | 文本文件 | | ft-approval-submit | mutation_proposals.json | 提案文件 |

核心盲区：没有历史交易分析能力。

这意味着：

• 策略工程师无法回答"哪些交易对应该暂停开仓"
• 审计角色无法生成周期性绩效报告
• 风控哨兵无法做历史风险事件回溯
• AI 进化闭环无法启动——没有数据，就没有分析；没有分析，就没有改进依据

3) 解决方案：一个只读的分析技能

解决方案出奇简单：新增一个 ft-trade-analytics 技能，直接查询 SQLite，输出结构化分析报告。

六种查询能力：

| 查询类型 | 说明 | 使用者 | | --- | --- | --- | | summary | 总体绩效摘要（胜率、盈亏、平均持仓） | 所有角色 | | by_pair | 按交易对分组的胜率与盈亏排名 | 策略工程师 | | by_signal | 按开仓信号分组的质量分析 | 策略工程师 | | recent | 最近 N 天的每日盈亏趋势 | 审计角色 | | worst_trades | 最大亏损交易列表 | 风控哨兵 | | duration_analysis | 持仓时长分布 | 策略工程师 |

关键设计原则：只读优先。 分析技能只读 SQLite，不写入任何数据。它是一面镜子，不是一个扳手。

4) 首次数据洞察：数据库里埋着什么

分析技能上线后，第一次查询就发现了六个关键洞察：

| 发现 | 数据 | 后续动作 | | --- | --- | --- | | 旧版超时标签 | 18 笔 timeout_loss_12h，胜率 0% | 已核实：旧版策略历史数据，当前已改为 48h 超时 | | 长持仓低胜率 | 持仓 >24h 胜率仅 20% | 已核实：当前 48h 超时斩仓机制已覆盖此风险 | | 单日极端亏损 | 3/4 单日 -56.92% | 2/28 开启 master_short 集中踩到反弹行情 | | 紧急退出均损 | 3 笔，平均 -10.59% | 紧急触发条件需复查 | | 交易对胜率差异 | DOGE 63.64% vs XRP 28.57% | 考虑对低胜率品种降权 | | 主力信号总亏 | master_short 75 笔，总亏 -63.12% | 大亏损集中在少数极端行情 |

注意前两个发现后面的标注："已核实"。这是因为分析技能提供了数据，但数据本身需要被正确解读。timeout_loss_12h 看起来是严重问题（18 笔全输），但实际上当前策略已经修复了这个问题——这是历史遗留数据，不是当前问题。

数据分析技能给你的不是答案，是提问的起点。 每个数字都需要被放在正确的上下文中理解。

5) 四层进化：从数据挖掘到策略进化

有了数据基础设施之后，进化分四层推进：

第 1 层：数据挖掘（立即可做）

ft-trade-analytics 提供结构化查询。策略工程师可以回答"哪些交易对拖累了总收益"，风控哨兵可以回答"历史上最大单笔亏损发生在什么条件下"。

第 2 层：策略分析闭环

有了数据之后，策略工程师的工作流变成：

`` 数据分析 → 发现弱点（如 XRP 胜率 28.57%） ↓ 市场情报 → 当前环境（鲸鱼动向、宏观情绪） ↓ 风控状态 → 当前状态（HOLD / READY） ↓ 生成策略调整建议 → 具体参数变更 ↓ 提交提案 → 等待审批 ↓ 审批通过 → 执行落地 ``

每一层都有人在环（human-in-the-loop）。 AI 提议，人类审批。

第 3 层：参数进化

扩展 mutation_engine 白名单，支持更多参数热更新。当前支持 stoploss、max_open_trades、stake_amount。建议扩展 minimal_roi（ROI 表）、trailing_stop_positive（追踪止损触发阈值）、max_entry_position_adjustment（加仓次数上限）。

扩展原则：每次只改一个参数；变更必须提供数据依据；变更后观察 24h。

第 4 层：策略代码进化（需严格门禁）

生成新策略 Python 文件，经过完整验证后上线灰度。流程：候选生成 → 本地回测 → 阈值门禁 → 提交审批 → 线上灰度（小仓位） → 观察 48h → 通过替换 / 不通过回滚。

回测门禁最低要求：

| 指标 | 要求 | | --- | --- | | 总盈利 | > 0 | | 胜率 | > 45% | | Sharpe Ratio | > 0.8 | | 最大回撤 | < 25% | | 交易笔数 | > 30（统计显著性） |

6) 回测验证：数据驱动的参数调整有用吗

我们用两个真实案例验证了数据驱动方法的有效性：

案例 1：minimal_roi 收紧（失败）

基于数据分析，策略工程师建议收紧 ROI 表。回测对比：

| 指标 | 基准（宽松 ROI） | 方案 A（收紧 ROI） | | --- | --- | --- | | 总盈利 | +10.92% | -3.97% | | Sharpe | 2.32 | -0.99 | | ROI 触发笔数 | 7 笔 | 119 笔 |

收紧 ROI 后，盈利单被过早止盈（119 笔 ROI 触发 vs 原来 7 笔），但亏损单未减少。结论：当前策略的核心问题不是止盈太晚，而是极端亏损单未被拦截。 数据分析告诉我们"不该做什么"——这同样有价值。

案例 2：ATR 减仓修正（成功）

数据分析发现 adjust_trade_position 方法写了但从未生效（position_adjustment_enable 默认 False）。更严重的是：原方法返回正值（加仓），但原意是减仓（应返回负值）——这是一个逻辑 bug。

修正后回测：

| 指标 | 基准 | 修正后 | | --- | --- | --- | | 总盈利 | +10.92% | +11.25% | | Sharpe | 2.32 | 2.40 | | Sortino | 3.75 | 3.87 | | 最大回撤 | 25.76% | 25.77% |

全面优于基准，无指标变差。

7) 风险控制原则

四层进化的每一步都遵循五条红线：

1. 只读优先：分析技能只读 SQLite，不写入任何数据。 2. 人工审批门禁：所有参数变更和策略上线必须经过人类审批。 3. 备份先行：每次变更前自动备份当前配置。 4. 灰度隔离：新策略用独立小仓位，不影响主策略运行。 5. 回滚随时可用：每个变更都有对应备份路径。

8) 给想用数据驱动策略进化的人

如果你也在跑自动化交易系统，想让数据发挥更大价值：

1. 先盘点数据资产：你的数据库里有什么表、什么字段？你可能比自己以为的拥有更多数据。 2. 找到数据盲区：谁在读数据？谁没有在读？盲区往往是最有价值的改进方向。 3. 从只读分析开始：不要急着改参数。先用数据回答问题，再决定要不要行动。 4. 区分历史数据和当前问题：一个看起来很严重的数字可能是旧版本的历史遗留，不是当前 bug。 5. 回测验证"不该做什么"：有时候数据最大的价值是告诉你"这个方向没用"，帮你避免浪费时间。 6. 红线不可逾越：只读、审批、备份、灰度、回滚。这五条不是建议，是底线。

9) 再次强调

这篇文章是 research only，not financial advice；backtests are not live performance；not an instruction to trade。

数据是交易系统的石油。但石油不是动力——引擎才是。数据本身不做决策，但它让你做出更好的决策。从"文件"到"账本"的转变不是技术升级，是认知升级：你的系统不再只是执行交易，它开始理解自己的交易。

不要只交易。要阅读你自己的交易。