量化项目研究学习（Hyper-Alpha-Arena）

SHI XIAOLONG

— 14 min read

交易系统架构对比分析报告

对比项目：Hyper-Alpha-Arena（582 stars / 186 forks）
分析日期：2026-02-08
最后更新：2026-02-04

一、参考项目概览

Hyper-Alpha-Arena 是一个全栈 AI 交易平台，支持 Hyperliquid 永续合约交易。核心特色是双引擎架构（AI Trader + Program Trader）+ 市场资金流信号监控。采用 FastAPI 后端 + React 前端 + PostgreSQL + Docker 一键部署的架构。

项目结构

backend/
├── main.py                              # FastAPI 入口（21+ 路由器）
├── models.py                            # 全局模型
├── version.py                           # 版本管理
├── api/                                 # 25 个 API 路由模块
│   ├── hyperliquid_routes.py            # Hyperliquid 数据查询
│   ├── hyperliquid_action_routes.py     # Hyperliquid 交易操作
│   ├── signal_routes.py                 # 信号管理
│   ├── market_flow_routes.py            # 资金流数据
│   ├── market_regime_routes.py          # 市场制度
│   ├── order_routes.py                  # 订单管理
│   ├── analytics_routes.py             # 归因分析
│   └── ...
├── services/                            # 40+ 服务模块
│   ├── auto_trader.py                   # 自动交易门面
│   ├── ai_decision_service.py           # AI 决策引擎
│   ├── trading_strategy.py              # 策略管理器（双触发）
│   ├── trading_commands.py              # 订单执行
│   ├── signal_detection_service.py      # 信号检测（边缘触发）
│   ├── market_regime_service.py         # 市场制度分类（7种）
│   ├── market_flow_collector.py         # WS 资金流采集
│   ├── market_flow_indicators.py        # 资金流指标计算
│   ├── market_events.py                 # 发布/订阅分发器
│   ├── market_stream.py                 # 市场数据流
│   ├── hyperliquid_trading_client.py    # 交易所客户端
│   ├── hyperliquid_environment.py       # testnet/mainnet 隔离
│   ├── order_executor.py               # 订单执行器
│   ├── order_monitor.py                # 订单监控
│   ├── order_matching.py               # 订单匹配
│   ├── price_cache.py                  # 双窗口价格缓存
│   ├── kline_realtime_collector.py     # 实时 K 线采集
│   ├── kline_data_service.py           # K 线数据服务
│   ├── ai_attribution_service.py       # 交易归因分析
│   ├── technical_indicators.py         # 技术指标
│   ├── asset_calculator.py             # 资产计算
│   ├── system_logger.py                # 系统日志
│   └── ...
├── backtest/                            # 回测引擎
│   ├── engine.py                        # 事件驱动回测
│   ├── execution_simulator.py           # 执行模拟器
│   ├── historical_data_provider.py      # 历史数据（防前视偏差）
│   ├── virtual_account.py              # 虚拟账户
│   └── models.py                        # 回测数据模型
├── program_trader/                      # 程序化交易
│   ├── executor.py                      # 沙箱执行器
│   ├── data_provider.py                 # 数据提供者
│   ├── validator.py                     # 代码验证器
│   └── backtest.py                      # 程序回测
├── database/                            # PostgreSQL + 40+ 迁移
│   ├── models.py                        # 40+ ORM 模型
│   ├── connection.py                    # 连接池管理
│   ├── migration_manager.py             # 渐进式迁移
│   └── migrations/                      # 40+ 迁移脚本
├── repositories/                        # 9 个 Repository
├── schemas/                             # 数据验证模型
├── config/
│   └── settings.py                      # 配置管理
└── utils/
    └── encryption.py                    # Fernet 私钥加密

frontend/                                # React + TypeScript + Vite
├── app/
│   ├── components/                      # 按领域分组的 UI 组件
│   ├── contexts/                        # 状态管理上下文
│   ├── lib/                             # API 客户端 + 工具
│   └── locales/                         # i18n（英/中）

核心数据流

Market Flow (WebSocket)
    ↓ (15s 聚合窗口)
MarketFlowCollector → DB (Upsert)
    ↓
SignalDetectionService (边缘触发)
    ↓ (回调)
TradingStrategy (双触发: 定时 + 信号)
    ↓
AIDecisionService / ProgramExecutor
    ↓ (结构化决策)
TradingCommands (IOC → GTC 回退)
    ↓
HyperliquidTradingClient (SDK + CCXT)
    ↓
Hyperliquid DEX

技术栈

层面 技术
后端框架 FastAPI（Python）
前端 React + TypeScript + Vite + Tailwind + shadcn/ui
数据库 PostgreSQL 14（40+ 迁移，连接池 20+20）
AI 引擎 OpenAI / Claude / Deepseek / Qwen（流式支持）
交易所 Hyperliquid SDK + CCXT
部署 Docker + docker-compose
加密 Fernet 对称加密（私钥保护）

二、值得借鉴的 8 大设计模式

1. 市场制度分类（Market Regime）⭐⭐⭐⭐⭐

参考项目做法：

# market_regime_service.py — 7 种市场制度分类
class MarketRegime(Enum):
    STOP_HUNT = "stop_hunt"       # 价格尖刺后反转
    ABSORPTION = "absorption"     # 强资金流无价格移动
    BREAKOUT = "breakout"         # 强 CVD + 价格移动 + 信号对齐
    CONTINUATION = "continuation" # CVD 和价格移动方向对齐
    EXHAUSTION = "exhaustion"     # RSI 极端值处的趋势衰竭
    TRAP = "trap"                 # 强资金流 + OI 减少 + 反转
    NOISE = "noise"               # 无清晰信号模式

def classify_regime(cvd_ratio, taker_ratio, price_atr, oi_change, rsi, depth_ratio):
    """基于多维度指标判断当前市场制度"""
    # 核心指标:
    #   CVD Ratio = CVD / Total Notional
    #   Taker Ratio = ln(buy_notional / sell_notional)
    #   Price ATR = 价格变化 / ATR 归一化
    #
    # 惩罚系统: 特征不对齐时降低置信度 (0.70-1.0 乘数)
    # 例: Breakout 要求 CVD + 价格移动 + OI 增加全部对齐
    #     如果 OI 未增加，置信度 × 0.85

当前项目现状：

  • 纯 Z-score + 协整检验驱动信号
  • 没有"市场环境"的概念 — 在趋势突破、流动性陷阱、噪音市中，Z-score 信号的可靠性完全不同
  • 极端市况下容易产生假信号

改进方向：

  • 引入市场制度分类作为配对交易信号的过滤层
  • 在 NOISE 和 TRAP 制度下抑制开仓信号（这两种情况 Z-score 均值回归预期不可靠）
  • 在 CONTINUATION 制度下提高信号阈值（趋势可能延续，均值回归概率低）
  • 在 ABSORPTION 和 EXHAUSTION 制度下降低信号阈值（这两种情况均值回归概率高）
  • 制度分类不需要全部 7 种，可简化为 3 种：趋势型（Breakout/Continuation）、均值回归型（Absorption/Exhaustion）、不确定型（Noise/Trap/StopHunt）

2. 资金流信号层（CVD / OI / Funding Rate）⭐⭐⭐⭐⭐

参考项目做法：

# market_flow_collector.py — WebSocket 15 秒聚合窗口
class MarketFlowCollector:
    """三路 WebSocket 数据订阅 + 15 秒聚合"""

    def __init__(self):
        self.aggregation_window = 15  # 秒
        self.ws_subscriptions = {
            "trades": self._on_trade,        # → CVD / Taker Volume
            "l2Book": self._on_orderbook,    # → 深度比率 / 不平衡
            "activeAssetCtx": self._on_ctx,  # → OI / Funding Rate
        }

    def _flush_buffer(self, symbol):
        """将聚合窗口数据写入 DB (Upsert 模式)"""
        # MarketTradesAggregated: 买卖量/笔数/名义/VWAP
        # MarketOrderbookSnapshots: 5/10档深度
        # MarketAssetMetrics: OI/资金费率/标记价格

# market_flow_indicators.py — 9 种资金流指标
def calc_indicators(symbol, timeframe="5m"):
    return {
        "cvd": cumulative_volume_delta,        # 累积买卖差
        "taker_ratio": ln(buy / sell),         # 对数买卖比
        "oi_change": oi_current - oi_prev,     # OI 变化
        "funding_rate": current_funding,       # 资金费率
        "depth_ratio": bid_depth / ask_depth,  # 深度比率
        "imbalance": (bid - ask) / (bid + ask),# 订单簿不平衡
        "price_change": pct_change,            # 价格变化率
        "volatility": stdev(returns),          # 波动率
    }

当前项目现状：

  • 信号完全基于 K 线数据（价格 → Z-score → 协整）
  • 不使用成交量、OI、资金费率等资金流数据
  • 无法感知"大资金在做什么" — Z-score 偏离可能是趋势突破而非均值回归机会

改进方向：

  • CVD（累积买卖差） 作为配对交易确认信号 — 当 Z-score 偏离但 CVD 显示单边大量买入时，可能是趋势突破，应抑制均值回归信号
  • OI（未平仓合约） 变化 — OI 急剧增加说明新资金进场，趋势可能延续；OI 减少说明在平仓，回归概率更高
  • Funding Rate — 极端资金费率（如 >0.1%/8h）暗示拥挤交易，均值回归概率高
  • 这些指标不需要 WebSocket 实时采集，可通过定时轮询 Hyperliquid info API 获取

3. 信号池 + 边缘触发（Signal Pool + Edge Triggering）⭐⭐⭐⭐

参考项目做法：

# signal_detection_service.py — 边缘触发逻辑
class SignalDetectionService:
    def _check_signal(self, definition, current_value):
        """边缘触发：仅在 False → True 转换时触发"""
        was_active = self._signal_states[definition.id]
        is_active = self._evaluate(current_value, definition.operator, definition.threshold)

        if is_active and not was_active:  # 边缘检测
            self._signal_states[definition.id] = True
            return True  # 触发！
        elif not is_active and was_active:
            self._signal_states[definition.id] = False  # 重置
        return False

    def _check_pool(self, pool, triggered_signals):
        """池级别逻辑"""
        if pool.logic == "OR":
            # 任一信号触发 AND 池处于非激活状态 → 触发
            return any(triggered_signals) and not pool.is_active
        elif pool.logic == "AND":
            # 所有信号全部触发 AND 池处于非激活状态 → 触发
            return all(triggered_signals) and not pool.is_active

# 运算符支持: >, >=, <, <=, ==, !=, abs_greater_than, abs_less_than

当前项目现状：

  • Z-score 信号是简单的阈值判断：z_score > threshold → 开仓
  • 每个周期都检查是否超阈值，可能在 Z-score 持续超阈值期间反复触发
  • 没有"边缘触发"的概念 — 应该只在首次越过阈值时触发一次

改进方向：

  • 边缘触发：Z-score 信号仅在首次穿越阈值时触发，避免持续超阈值期间重复开仓
  • 信号池：将 Z-score + 资金流 + 市场制度组合为一个信号池，用 AND 逻辑要求多维度确认
  • 例：Z-score > 2.0 AND CVD 不支持趋势 AND 市场制度 ≠ Breakout → 开仓

4. WebSocket 降级模式（Degraded Mode）⭐⭐⭐⭐

参考项目做法：

# market_flow_collector.py — 连接健康管理
class MarketFlowCollector:
    HEALTH_CHECK_INTERVAL = 30   # 秒
    STALE_DATA_THRESHOLD = 30    # 秒
    MAX_RECONNECT_ATTEMPTS = 5
    DEGRADED_RETRY_INTERVAL = 120  # 秒

    async def _health_check_loop(self):
        while self.running:
            await asyncio.sleep(self.HEALTH_CHECK_INTERVAL)
            if self._is_data_stale():
                self.reconnect_attempts += 1
                if self.reconnect_attempts <= self.MAX_RECONNECT_ATTEMPTS:
                    # 正常重连: 指数退避
                    delay = min(2 ** self.reconnect_attempts, 30)
                    await self._reconnect(delay)
                else:
                    # 降级模式: 无限重试，每 120 秒一次
                    logger.warning("进入降级模式")
                    await self._reconnect(self.DEGRADED_RETRY_INTERVAL)

    def _flush_buffer(self, symbol):
        # 过时数据跳过刷新（防止写入不新鲜的数据）
        if self._is_data_stale():
            logger.warning(f"跳过 {symbol} 刷新：数据过时")
            return

当前项目现状：

  • enhanced_ws_manager.py 有重连逻辑
  • 但没有"降级模式"的概念 — 重连失败后的行为不明确
  • 没有过时数据检测 — 可能使用过时数据做出交易决策

改进方向：

  • 引入数据新鲜度检测（last_data_time + stale_threshold）
  • 正常模式（5 次指数退避）→ 降级模式（每 120 秒无限重试）
  • 过时数据不做交易决策，只做告警
  • 与改进 7（TradingMode 状态机）结合：WS 降级时自动切换为 TP_ONLY 模式

5. TP/SL 订单去重机制 ⭐⭐⭐⭐

参考项目做法：

# hyperliquid_trading_client.py — 三步去重防止重复 TP/SL
def set_tp_sl(self, symbol, tp_price, sl_price):
    """三步验证防止重复 TP/SL 订单"""
    # Step 1: 从 Hyperliquid API 获取当前挂单（权威来源）
    existing_orders = self.info.open_orders(self.wallet_address)

    # Step 2: 比较请求价格与现有价格（0.1% 阈值）
    for order in existing_orders:
        if order["symbol"] == symbol and order["type"] == "tp":
            if abs(order["price"] - tp_price) / tp_price < 0.001:
                return  # 已存在相同 TP，跳过

    # Step 3: 内存缓存防止 API 延迟期间的重复
    cache_key = f"{symbol}_{tp_price}_{sl_price}"
    if cache_key in self._tpsl_cache:
        return
    self._tpsl_cache[cache_key] = time.time()

    # 执行 TP/SL 设置
    self._do_set_tp_sl(symbol, tp_price, sl_price)

当前项目现状：

  • executor.py 没有 TP/SL 订单去重
  • 如果策略在同一周期多次触发，可能创建重复的 TP/SL 订单
  • Hyperliquid 允许同一仓位设置多个 TP/SL，重复订单不会报错但会造成混乱

改进方向：

  • 在设置 TP/SL 前先查询现有挂单
  • 价格差在 0.1% 以内视为相同，跳过重复设置
  • 内存缓存作为 API 延迟期间的额外防重入屏障

6. 预言机价格保护（Oracle Price Clamping）⭐⭐⭐⭐

参考项目做法：

# trading_commands.py — 价格钳制
def _enforce_price_bounds(symbol, requested_price, side):
    """将下单价格钳制在 ±1% 预言机价格窗口内"""
    oracle_price = get_oracle_price(symbol)
    max_price = oracle_price * 1.01
    min_price = oracle_price * 0.99

    if side == "buy" and requested_price > max_price:
        return max_price
    elif side == "sell" and requested_price < min_price:
        return min_price
    return requested_price

当前项目现状：

  • 改进 2（IOC 限价单）已提出 mark_price ± slippage_bps 保护
  • 但没有独立的"预言机价格硬限制"作为最后防线

改进方向：

  • 作为 IOC 限价单的补充 — 即使 slippage_bps 设置不当，预言机 ±1% 硬限制确保价格不会偏离太远
  • 分层保护：IOC 限价（±0.25%） → 预言机硬限制（±1%）

7. 交易归因分析（Trade Attribution Analytics）⭐⭐⭐

参考项目做法：

# ai_attribution_service.py — 多维度归因分析
def analyze_performance(account_id, period):
    """交易绩效归因分析"""
    trades = get_trades(account_id, period)

    attribution = {
        # 按品种分解
        "by_symbol": group_pnl_by(trades, "symbol"),
        # 按触发类型分解（信号触发 vs 定时触发）
        "by_trigger": group_pnl_by(trades, "trigger_type"),
        # 按时段分解（亚洲/欧洲/美国时段）
        "by_session": group_pnl_by(trades, "session"),
        # 按持仓时间分布
        "by_duration": group_pnl_by(trades, "hold_duration_bucket"),
    }

    # AI 诊断：识别弱点并建议优化
    diagnosis = llm.analyze(attribution, prompt="识别策略弱点...")
    return attribution, diagnosis

当前项目现状：

  • trade_repository.py 记录了交易数据
  • 有日统计（DailyStats）
  • 但没有多维度归因分析 — 不知道盈利/亏损集中在哪个品种、哪个时段、哪种信号强度

改进方向：

  • 利用 TimescaleDB 中已有的历史数据做归因分析
  • 关键维度：按交易对（HYPE vs PURR 单独）、按信号强度、按持仓时间、按市场制度
  • 不需要 AI 诊断（过度复杂），简单的 SQL 聚合即可

8. 事件驱动回测 + 防前视偏差 ⭐⭐⭐

参考项目做法：

# backtest/engine.py — 事件驱动回测
class BacktestEngine:
    def run(self, config: BacktestConfig):
        """信号 + 定时双触发事件循环"""
        events = self._merge_trigger_events(signal_events, scheduled_events)
        events.sort(key=lambda e: e.timestamp)

        for event in events:
            # 更新虚拟账户的持仓标记价格
            account.update_market_prices(event.timestamp)
            # 检查 TP/SL 是否在 K 线高低价范围内触发
            self._check_tpsl(account, event.timestamp)
            # 执行策略决策
            decision = strategy.evaluate(event, market_data)
            account.execute(decision)

# backtest/historical_data_provider.py — 防前视偏差
class HistoricalDataProvider:
    def get_klines(self, symbol, timeframe, current_time_ms):
        """所有查询遵守 current_time_ms，防止前视偏差"""
        return [k for k in cached_klines
                if k.close_time <= current_time_ms]  # 只返回已完成的 K 线

# backtest/execution_simulator.py — 方向性滑点
def simulate_fill(order, market_price, slippage_bps):
    """买入增加价格、卖出减少价格"""
    if order.side == "buy":
        fill_price = market_price * (1 + slippage_bps / 10000)
    else:
        fill_price = market_price * (1 - slippage_bps / 10000)

当前项目现状：

  • 没有回测框架（已在改进 24 中提出）
  • 改进 24 的设计可借鉴此项目的具体实现细节

改进方向：

  • 事件驱动架构（信号事件 + 定时事件合并排序）
  • 防前视偏差：所有数据查询必须传入 current_time_ms，只返回此时间之前的数据
  • 方向性滑点：买入价格上浮、卖出价格下浮
  • K 线内 TP/SL 检测：不仅在触发时间检查，还检查该 K 线的高低价是否触及 TP/SL

三、当前项目的独有优势

以下是当前项目已有但 Hyper-Alpha-Arena 缺失的能力，不需要改动：

维度 当前项目优势 Hyper-Alpha-Arena
双腿配对交易 原生 pair mode（两腿对冲 + 回滚） 仅单腿方向性交易
多周期协整分析 5m/1h/4h Z-score + 协整检验 无协整分析（LLM 或用户自定义规则）
三层安全防护 KillSwitch + RateLimiter + CircuitBreaker 无 CircuitBreaker，无 RateLimiter
线程安全状态 Lock/RLock 保护共享状态 部分使用锁，但不如当前项目系统化
日损限额 UTC 日自动重置 无日损限额机制
时序数据库 TimescaleDB 优化时序查询 PostgreSQL（无时序优化）
WS 管理 enhanced_ws_manager 专业管理 基于 Hyperliquid SDK 的简单 WS

四、改进优先级建议

P0 — 高价值、可立即实施

改进项 来源模块 预估工作量 影响范围
市场制度分类（简化版） market_regime_service.py 4-6 小时 信号过滤，减少假信号
TP/SL 去重 hyperliquid_trading_client.py 2-3 小时 防止重复挂单
预言机价格保护 trading_commands.py 1-2 小时 价格硬限制，最后防线

P1 — 高价值、中等工作量

改进项 来源模块 预估工作量 影响范围
资金流信号层 market_flow_collector.py 1-2 天 Z-score 确认信号
信号边缘触发 signal_detection_service.py 3-4 小时 防止重复触发开仓
WS 降级模式 market_flow_collector.py 3-4 小时 提升 WS 故障容忍

P2 — 中价值、可延后

改进项 来源模块 预估工作量 影响范围
交易归因分析 ai_attribution_service.py 1-2 天 策略优化有数据支撑
回测防前视偏差 historical_data_provider.py 纳入改进24 回测结果更可靠

五、关键设计理念对比

理念 Hyper-Alpha-Arena 当前项目 借鉴建议
信号维度 多维度（价格+资金流+制度） 单维度（Z-score） ⭐ 增加资金流确认
信号触发 边缘触发（仅 False→True） 水平触发（每周期检查） ⭐ 改为边缘触发
市场认知 7 种制度分类 无市场环境感知 ⭐ 简化版制度分类
数据保护 防前视偏差 无（无回测） 回测时必须实现
订单保护 预言机±1%钳制 + IOC 市价单 ⭐ 分层价格保护
WS 容错 降级模式（无限重试） 有限次重连 ⭐ 增加降级模式

六、总结

Hyper-Alpha-Arena 是一个功能丰富的全栈交易平台（582 stars），其核心价值不在 AI（LLM 做交易决策的可靠性存疑），而在于其市场微观结构感知能力和信号系统设计。

最值得优先借鉴的 5 个点：

  1. 市场制度分类（4-6h）— 为配对交易信号增加"市场环境过滤"，在不利制度下抑制信号，在有利制度下降低阈值
  2. 资金流确认信号（1-2d）— CVD + OI + Funding Rate 作为 Z-score 信号的确认层，减少趋势突破期间的假信号
  3. 信号边缘触发（3-4h）— 仅在首次穿越阈值时触发，避免持续超阈值期间重复开仓
  4. TP/SL 去重（2-3h）— 三步验证防止重复 TP/SL 挂单
  5. 预言机价格保护（1-2h）— 作为 IOC 滑点保护的最后防线

Read more

跑步的技巧（滚动落地）

“滚动落地（rolling contact / rolling foot strike）”不是一种教条式的“脚法”，而是一种 让冲击沿着整只脚、整条后链逐级传递的落地机制。 它的核心不是“你先用哪儿着地”，而是： 你的脚落地之后，冲击是不是像轮子一样滚过去，而不是像锤子一样砸下去。 这就是滚动落地的本质。 一、什么叫“滚动落地”？ 你可以把它理解成两种完全不同的落地方式： 1. 砸地（撞击式） 脚像锤子一样拍到地上： * 要么后跟先砸 * 要么前掌先戳 * 冲击集中在一个点 * 一个结构瞬间吃掉大部分载荷 结果就是： * 后跟砸 → 膝盖难受 * 前掌戳 → 前脚掌磨烂 * 都不是长跑友好模式 这叫 撞击式着地（impact strike）。 2. 滚地（滚动式） 脚像轮胎一样“滚”过地面： * 不是某一点硬砸 * 而是外侧中足先轻触 * 再向前滚到前掌 * 最后从大脚趾蹬离

By SHI XIAOLONG

AMI的优越性

世界模型（World Models）的具体例子 如下，我按类型分类，便于理解。每类都附带实际实现、演示效果和应用场景。 1. Yann LeCun / Meta 的 JEPA 系列（最直接对应“世界模型”概念） 这些是 LeCun 主张的非生成式抽象预测世界模型代表。 * I-JEPA（Image JEPA，2023） 输入一张图像，模型把不同区域（context 和 target）编码成抽象表示，然后预测 target 的表示（不在像素级别重建）。 例子：给定一张遮挡了部分物体的图片，模型能预测“被遮挡物体的大致位置和属性”，构建对物体持久性和空间关系的理解。 这是一个“原始世界模型”，能学习物理常识（如物体不会凭空消失）。 * V-JEPA / V-JEPA 2（Video JEPA，

By SHI XIAOLONG

什么是：“世界模型（World Models）”

世界模型（World Models） 是人工智能领域的一个核心概念，尤其在 Yann LeCun 等研究者推动的下一代 AI 架构中占据中心位置。它指的是 AI 系统在内部构建的对现实世界的抽象模拟或内部表示，让机器能够像人类或动物一样“理解”物理世界、预测未来、规划行动。 简单比喻 想象你闭上眼睛也能“看到”房间里的物体会如何移动、碰撞或掉落——这就是你大脑里的世界模型。AI 的世界模型就是类似的“数字孪生”（digital twin）或“内部模拟器”：它不是简单记住数据，而是学习世界的动态、因果关系和物理直觉（如重力、物体持久性、遮挡、因果等）。 为什么需要世界模型？ 当前主流的大型语言模型（LLM） 擅长处理文本（统计模式预测），但存在根本局限： * 缺乏对物理世界的真正理解 → 容易“幻觉”、无法可靠规划。 * 样本效率低 → 人类/

By SHI XIAOLONG

K线周期可配置化设计方案

K线周期可配置化设计方案 1. 背景与目标 当前 Beta 套利策略的 K 线周期硬编码为 "1h"，分散在多个文件中。需要： 1. 将 K 线周期从 1h 改为 2h 2. 提取为环境变量 BETA_ARB_KLINE_INTERVAL，使其可在 .env 中配置 2. 影响范围分析 2.1 需要修改的文件（共 6 个） 文件 硬编码位置 修改内容 src/trading/config.py BetaArbConfig dataclass 新增 kline_interval 字段，

By SHI XIAOLONG