task-analysis-pipeline-overhaul

# 任务分析：qclaw公式管线全面修复 **任务来源：** Hermes (trae_task_qclaw_pipeline_overhaul.md) **接收时间：** 2026-06-09 10:00 **优先级：** P0 - 阻塞 ## 任务拆解 ### 问题1: bridge Gitee通道断裂 **现状：** `git pull --ff-only` 持续失败 (rc=128) **原因：** qclaw的Gitee push可能用了rebase/force push **修复方案：** 改为 `git fetch origin && git reset --hard origin/master` **状态：** ✅ Hermes已修复 ### 问题2: qclaw公式未接入知量3.0 ⚠️ 待处理 **现状：** - MySQL `fanrujin_market.formula_registry` 存了157条公式（qclaw 70+条） - KnowQuant `engine/factor_registry.py` 是纯Python内存注册表（180+因子槽位） - 两系统完全隔离 **需要评估的方案：** - 方案A：factor_registry.py 扩展从MySQL动态加载因子 - 方案B：建立同步管道，SQL导出→转Python代码 - 方案C：两系统保持独立（MySQL展示/交易，Python回测研究） **我的初步建议：** 方案C（短期）+ 方案A（长期） - 短期内保持独立，避免引入复杂性 - 长期看，动态加载更优雅，但需要仔细设计 ### 问题3: Hermes已处理事项 - ✅ 修复 bridge git pull - ✅ 创建 qclaw-review-cron（每6小时LLM cron） - ✅ 给qclaw写首批反馈 ## 实施计划 ### 第一阶段：环境调研（今天） 1. 检查 formula-bot 服务器上的相关文件 - `/home/agentuser/formula-bot/qclaw_bridge.py` - MySQL formula_registry 表结构 - KnowQuant factor_registry.py 代码 2. 评估三个对接方案的技术可行性和维护成本 ### 第二阶段：决策与实施（明天） 1. 确定最终方案 2. 实施代码修改 3. 测试验证 ### 第三阶段：报告与验收 1. 向 Hermes 提交实施报告 2. 等待验收 ## 需要的信息 为了做出正确决策，我需要访问： 1. KnowQuant 服务器的代码访问权限 2. MySQL 数据库只读权限（查看 formula_registry） 3. formula-bot 服务器上 qclaw_bridge.py 的当前代码 ## 下一步行动 1. 立即开始环境调研 2. 今天内完成方案评估 3. 明天实施并测试 4. 完成后通知 Hermes 验证 --- **处理人：** Q1 **开始时间：** 2026-06-09 10:05