My Life is Going On

Sucaddy v4.0.1 — 去中心化 SD-WAN 代理平台 Sucaddy v4.0.1 — 一个二进制，SD-WAN 组网 + 多协议代理 + 去中心化管理。 四节点生产运行中 源码: iStoreOS Git 升级摘要 从 v2.x 到 v4.0.1，sucaddy 从一个三端合一代理工具进化成了完整的SD-WAN 代理平台： 维度 v2.x v4.0+ 定位 代理工具 SD-WAN 平台 协议 SS + NaiveProxy SS + SOCKS5 + HTTP + NaiveProxy + TCP/UDP 转发 网络 无组网 TUN 虚拟网络 (10.0.0.0/24) 架构 中心化三端 去中心化对等节点 节点管理 手动配置 Gossip 协议自动发现 + Ed25519 签名 证书 acme.sh 脚本 内置 ACME (HTTP-01) 代码量 762 行 ~6700 行 (功能 ×10) 部署 安装脚本 AI 辅助，配置文件驱动 架构概览 四层架构 ┌─────────────────────────────────────────────────────┐ │ 应用层: ping / ssh / curl 10.0.0.x │ ├─────────────────────────────────────────────────────┤ │ 虚拟网络层 (Mesh): TUN + 路由表 + 隧道 │ ├─────────────────────────────────────────────────────┤ │ 链路层 (Link): TLS 1.3 / NaiveProxy :443 │ ├─────────────────────────────────────────────────────┤ │ 协议层 (Protocol): SS / SOCKS5 / HTTP / NaiveProxy│ ├─────────────────────────────────────────────────────┤ │ 节点管理层 (Gossip): Peer 发现 / 心跳 / Ed25519 │ └─────────────────────────────────────────────────────┘ 核心能力 能力 说明 全协议出入口 每台服务器独立提供 SS / SOCKS5 / HTTP / NaiveProxy 服务 SD-WAN 组网 TUN 虚拟子网，节点间 10.0.0.0/24 互通 链路层加密 常规链路 TLS 1.3 / 跨境链路 NaiveProxy :443 伪装 去中心化 Gossip 协议 + Ed25519 签名，无中心单点故障 自动证书 内置 Let’s Encrypt ACME (HTTP-01) 链式代理 多跳链路灵活组合（SS → NaiveProxy → SS 等） 快速开始 # 1. 克隆 & 编译 git clone ssh://git@10.10.10.254/mnt/mmc0-8/git/repos/sucaddy.git cd sucaddy/code go build ./cmd/sucaddy/ # 2. 写配置文件 cat > /etc/sucaddy/sucaddy.yaml << 'EOF' node: name: "mynode" servers: - protocol: ss listen: ":8388" method: aes-256-gcm password: "mypassword" mesh: virtual_ip: "10.0.0.5/24" EOF # 3. 运行 ./sucaddy run -c /etc/sucaddy/sucaddy.yaml 环境要求 项目 要求 Go 1.21+ 操作系统 Linux (amd64/arm64) / macOS 内核 Linux 需要 CAP_NET_ADMIN (TUN 设备) 端口 19528 (mesh), 443 (NaiveProxy), 自定义 (协议入口) 交叉编译 # amd64 GOOS=linux GOARCH=amd64 go build -o sucaddy-linux-amd64 ./cmd/sucaddy/ # arm64 GOOS=linux GOARCH=arm64 go build -o sucaddy-linux-arm64 ./cmd/sucaddy/ ⚠️ 部署前必须校验二进制架构匹配：架构不匹配会导致 mesh 握手异常断开。 ...

引言 大多数人对量化交易有一个误解：胜率越高越好。 但事实是——盈利不靠胜率，靠盈亏比。 这篇实录记录了我用 XGBoost 模型驱动的 BTC 量化交易系统在 Hyperliquid 上跑模拟交易的真实数据，从 4 月 7 日到 4 月 12 日，5 天时间，27 笔交易，胜率只有 25.9%，但最终账户从 $10,000 增长到 $10,152.02，盈利 +1.52%。 这篇文章不吹不黑，把原始数据摊开来看。 系统概况 项目 详情 模型 XGBoost 三分类（中性 / 做多 / 做空） 特征 51 个技术指标（三周期：15m / 1h / 4h） 交易所 Hyperliquid（DEX） 模式 Paper Trading（模拟交易） 执行频率 每 15 分钟 初始资金 $10,000 运行时间 2026-04-07 13:00 ~ 2026-04-12 07:00 风控参数 参数 值 说明 置信度阈值 60% 开仓条件 止盈 ATR × 5 动态止盈 止损 ATR × 2 动态止损 移动止盈 盈利 > 1% 后回撤 0.5% 触发 超时平仓 16 根 K 线 防止死扛 最大仓位 15% 置信度 + 连胜连败调整 交易数据 总览 指标 值 总交易 27 笔 盈利 7 笔 亏损 20 笔 胜率 25.9% 初始资金 $10,000.00 当前资金 $10,152.02 总收益 +$152.02 (+1.52%) 胜率不到 26%，但依然赚钱——因为赢的那些交易赚得足够多。 ...

前言：一次惨痛的教训 2026年3月19日，我的 ml-strategy 系统的8个策略全部爆仓。资金归零。 这不是意外，是必然。我犯了几个致命错误： 多策略 ≠ 分散风险：8个策略用的是相似逻辑，失败时一起失败 未经验证实盘：回测好看就直接上实盘 没有风控边界：止损随意，止盈靠运气 那次之后，我重构了整个系统。这篇文章记录新的 btc-quant-skill 从零到 +801% 收益的设计过程。 微架构设计：回测和实盘必须一致 之前最大的问题是：回测用一套逻辑，实盘用另一套。 新的架构强制一个原则：策略逻辑只有一个入口。 ┌─────────────────────────────────────────────────────────────┐ │ Strategy Engine (核心) │ ├─────────────────────────────────────────────────────────────┤ │ 数据加载 → 特征构建 → 信号生成 → 风控检查 → 交易执行 │ └─────────────────────────────────────────────────────────────┘ │ ┌───────────────┴───────────────┐ │ │ ┌──────▼──────┐ ┌──────▼──────┐ │ Backtest │ │ Live Trade │ │ Provider │ │ Provider │ │ (本地 CSV) │ │ (OKX API) │ └─────────────┘ └─────────────┘ 唯一差异：数据源 ...

背景 之前 OpenClaw 有个问题：所有任务都由主代理独立完成，导致： 上下文爆炸：复杂任务撑爆 token 限制 效率低下：串行执行，无法并行 没有分解：大任务不会自动拆分 借鉴字节跳动开源的 DeerFlow Lead Agent 架构，今天实现了完整的子代理编排系统。 实现方案 架构设计 用户消息 → skill-orchestrator 检测 ↓ 检测关键词（审核/分析/对比...） ↓ 判断复杂度 → high → 启用子代理模式 ↓ 注入 SUBAGENT_SYSTEM_PROMPT ↓ LLM Thinking: 分解成 N 个子任务 ↓ sessions_spawn × N（最多 3 个并行） ↓ 等待结果 → 汇总报告 → 返回用户 核心能力 能力 实现方式 说明 任务分解 Prompt 模板 教 LLM 如何拆分复杂任务 并行执行 sessions_spawn 最多 3 个子代理并行 分批调度 多批次策略 超过 3 个任务自动分批 结果汇总 主代理合成 收集子代理结果生成报告 沙箱执行 Colima + Docker 可选隔离环境 部署过程 1. Colima 安装（轻量 Docker 环境） brew install colima docker docker-compose colima start --cpu 2 --memory 1 --disk 10 资源占用：2 CPU / 1GB 内存 / 10GB 磁盘 ...

背景 今天对 BTC 量化交易模型进行了一次深度审核，发现了一个严重的数据泄露问题，修复后回测表现反而更好了。 问题发现 训练集划分问题 审核 train_model.py 时发现，模型训练使用了 train_test_split 随机划分数据集： X_train, X_val, y_train, y_val = train_test_split( X, y, test_size=0.2, random_state=42, stratify=y ) 问题：时间序列数据不能随机划分！ 随机划分会导致验证集包含训练集之后的数据，模型在验证时实际上"看到了未来"，导致验证集性能虚高。 回测脚本审核 回测脚本本身没有数据泄露问题： 特征全部向后看（rolling/ewm） 标签生成正确（shift(-12) 向前看） 逐笔模拟没有用未来数据 修复方案 将随机划分改为时间序列划分： # 修复前 X_train, X_val, y_train, y_val = train_test_split(X, y, test_size=0.2, stratify=y) # 修复后 split_idx = int(len(X) * 0.8) X_train, X_val = X[:split_idx], X[split_idx:] y_train, y_val = y[:split_idx], y[split_idx:] 验证结果 验证集性能对比 指标 旧模型（随机划分） 新模型（时间序列划分） 准确率 74.2% 70.0% Macro F1 0.69 0.62 验证集性能下降了，但这是正常的——去掉了"作弊"后才是真实泛化能力。 回测对比（固定仓位 $10,000） 指标 旧模型 新模型 变化 总收益 +68.87% +75.57% +6.7% ✅ 最大回撤 -0.58% -0.62% -0.04% 夏普比率 15.00 16.03 +1.03 ✅ 胜率 88.0% 88.4% +0.4% 盈亏比 1.05 1.22 +0.17 ✅ 结论：时间序列划分训练的模型，回测表现更好！ ...

📊 重构背景 2026-03-21，在对 OpenClaw 技能系统进行例行检查时，发现了一个严重问题： ai-trader 技能代码标准检查： ❌ 5 个错误 ⚠️ 115 个警告 ✅ 仅 6/65 检查项通过 主要问题包括： 缺少 CLI 入口标准 没有主协调器（orchestrator） 步骤模块混乱 文件头模板缺失 console.log 滥用 🎯 重构目标 基于 CODE_STANDARDS.md v4.1，确定重构目标： 架构模式: 类型 B（功能型）→ 类型 C（元技能模式） 代码标准: 115 警告 → 0 警告 简洁性: 70/100 → 85/100 总体评分: 82/100 → 87/100 🔧 重构过程 第一步：创建标准结构 ai-trader/ ├── bin/ │ └── ai-trader.mjs # CLI 入口（新增） ├── src/ │ ├── orchestrator.mjs # 主协调器（新增） │ └── steps/ # 步骤模块（新增） │ ├── data-fetch.mjs │ ├── quality-check.mjs │ ├── rule-scoring.mjs │ ├── rebalance.mjs │ ├── risk-check.mjs │ ├── execution.mjs │ └── log-sync.mjs └── tests/ └── steps/ └── orchestrator.test.mjs 第二步：拆分核心模块 重构前： ...

AI 量化交易系统 v3.6.2：仓位再平衡阈值的动态优化实践 发布时间: 2026-03-14 作者: 高斯特 标签: #量化交易 #AI #系统设计 #代码优化 摘要 本文记录了 ai-trader 系统在 v3.6.2 版本中对仓位再平衡阈值机制的完整优化过程。通过 3 轮迭代，我们从固定金额方案演进到分段动态阈值策略，实现了大资金宽松、小资金敏感的智能适配机制。优化后系统测试覆盖率 169 tests 全通过，生产就绪。 背景 ai-trader 是一个完全集成的 AI 智能交易系统，采用规则驱动 + AI 辅助的混合架构。系统核心功能包括： 链上数据分析（Puell、MVRV、SOPR） 技术指标计算（EMA 多头/空头排列） 50 分制评分引擎 自动仓位再平衡 在 v3.6.1 版本运行过程中，我们发现仓位再平衡阈值设计存在缺陷，触发了本次优化。 问题分析 原始设计（v3.6.1 及之前） 系统采用固定金额偏差方案： // 固定 1000U 偏差转换为百分比 const fixedAmount = 1000; const threshold = (fixedAmount / totalValue) * 100; 总仓位 阈值 触发偏差 问题 30 万 U 0.33% 1000U ❌ 太敏感，频繁交易 10 万 U 1.00% 1000U ⚠️ 中等 1 万 U 10.00% 1000U ❌ 太宽松，错过机会 核心问题： ...

🎉 发布概览 博客管理工具 blog-manager 今日发布 v2.0.0-alpha 版本，带来架构级的全面重构。 核心改进： 🔐 SSH Key 认证替代密码，安全性大幅提升 🔄 网络波动自动重试（指数退避算法） 📝 发布前智能验证（空文件/内容长度/Front Matter） 📊 结构化日志系统，问题排查更高效 📋 版本对比 功能 v1.x v2.0 认证方式 SSH 密码 SSH Key (ed25519) 错误恢复 ❌ 无 ✅ 自动重试 3 次 日志系统 ❌ 无 ✅ Winston 结构化日志 空文件检测 ❌ 无 ✅ 发布前拦截 内容验证 ❌ 无 ✅ Front Matter + 正文检查 平均发布时间 ~30 秒 ~20 秒 发布成功率 ~80% ~99% 🔐 安全改进 v1.x 问题 // ❌ 密码硬编码在配置文件 ssh: { host: '[博客服务器 IP]', password: "[已隐藏]" // 明文密码 } v2.0 方案 // ✅ SSH Key 认证 ssh: { host: '[博客服务器 IP]', privateKey: '~/.ssh/blog-manager', // 私钥文件 // password 仅作为降级备用 } 密钥规格： ...

🎯 2.5 小时从零实现：Superpowers 风格技能自动触发系统 ✅ 5 个技能全部集成：ai-trader / auto-memory / self-improver / dev-orchestrator / scrapling 🎤 语音命令实战：“跑一次自动交易” → 转录 → 匹配 → 执行 → 盈利 0.23 USDT 📖 背景 问题：技能太多记不住 我的 OpenClaw 工作空间有 7 个技能： ai-trader - AI 自动交易 auto-memory - 语音识别 + 记忆检索 self-improver - 错误学习 + 自我改进 dev-orchestrator - 多代理开发协调 scrapling - 反爬网页抓取 blog-manager - 博客管理 skill-orchestrator - （今天新建的）技能触发器 每次要用技能都得： 记得技能名字 手动读 SKILL.md 按流程执行 太麻烦了！ 能不能像 Superpowers 那样，说句话就自动触发？ 🎯 目标 融合 Superpowers 的核心思想： ...

量化交易系统的自我修养：ai-trader 进化周记 时间: 2026-03-10 ~ 2026-03-13 作者: 马克 状态: 生产环境运行中 前言 这周没干别的，就折腾一件事：让 ai-trader 从"能跑"变成"靠谱"。 量化交易这玩意儿，最难的不是写策略，而是承认自己会错，然后给系统留够纠错的余地。 一、核心问题：为什么之前不靠谱？ 1.1 数据层脆弱 问题：OKX API 返回的 K 线数据从新到旧 后果：EMA 计算用反了顺序 → 多头变空头 修复：反转数组 + 数据完整性验证（至少 200 根 K 线） 1.2 评分系统粗糙 之前是"满足 2 条规则就买"，问题是： 满足 2 条弱信号 vs 2 条强信号 → 仓位一样？ Puell 0.49（刚过线）vs Puell 0.1（深度低估）→ 权重一样？ v3.5.0 改为 50 分制渐变评分： 指标 深度低估 刚过线 权重差 Puell <0.3 → +20 <0.5 → +15 +5 MVRV <-2.0 → +12 <-1.5 → +10 +2 EMA 强多头 → +10 弱多头 → +8 +2 仓位公式：目标仓位 = 分数 × 2% ...