跳转至

name: tradingagents-astock-quick-recommend description: A股荐股分析的完整工作流。核心经验：不要死磕固定候选池 + 不要依赖单一LLM源 + 用实时数据替代LLM通用知识。用户空仓时偏好防御性/确定性强的标的。

TradingAgents-Astock 荐股分析

A股短线荐股工作流。基于 TradingAgents-astock 但经过大量修改。

⚡ 核心教训（最重要的经验）

1. 股票池必须动态，不能固定

用户强烈反感固定候选池（如硬编码5只龙头股）。正确的做法： - 先扫今日热门板块和资金流向 - 基于实际盘面选股，而不是凭主观判断选池 - 用腾讯财经API实时拉取行情排序

2. MiniMax API 频控是最大瓶颈

  • MiniMax Coding Plan (M2.7) 有严格的 RPM 限制
  • 一旦触发 Too Many Requests，需要等 15-30 分钟冷却，加大间隔也不能缓解
  • 最佳方案：用 DeepSeek（Hermes API Server localhost:8644）替代 MiniMax，无频控、速度快

3. 腾讯财经API是首选数据源

  • 免key、无频控、速度快
  • 支持批量行情（6只一次请求）
  • 支持K线数据（日/周/月）
  • 坑：f[36] 字段是昨收盘价，不是涨跌幅！涨跌幅必须自行计算

4. 用户状态决定选股方向

  • 空仓用户：优先高确定性/防御性标的（茅台、五粮液等消费股），而非纯题材追涨
  • 已有仓位：可考虑板块轮动、强势股
  • 用户说"不如之前" = 偏好信号，说明更看重确定性而非爆发力

5. 涨跌幅数据必须自行计算

腾讯财经API的 f[36] 是昨收盘价，不是涨跌幅。正确计算： 

pct = (realtime_price - yesterday_close) / yesterday_close * 100
涨跌幅失真会直接导致筛选池和评分全错。推荐从K线接口取 昨收(close[-2]) 和 K线末收盘价(close[-1]) 计算。

6. 筛选规则

  • 剔除涨跌停（涨>9.9%或跌>9.9%）
  • 剔除弱势股（调整后涨跌幅 < -7%）
  • 池子选6-8只最活跃、覆盖不同板块即可
  • 跌的票保留1-2只作为超跌反弹标的

📊 数据源

数据 接口 说明
实时行情 https://qt.gtimg.cn/q=sh{code},sz{code} 批量拉取，返回文本
K线 https://web.ifzq.gtimg.cn/appstock/app/minute/query?code=sz{code} 日K线，含均线/涨跌幅
板块 akshare stock_board_industry_name_em 同花顺行业板块

📝 工作流

y?code=sz{code}| 日K线，含均线/涨跌幅 | | 板块 | aksharestock_board_industry_name_em` | 同花顺行业板块 |

📝 工作流### 方案：动态热门股 + DeepSeek 分析（推荐）

File: /root/data/disk/tradingagents-astock/trade_recommend_v4.py

Step 1：扫盘面选股

用腾讯批量行情拉取30只龙头股，按涨幅排序，选涨幅3%~7%区间（剔除涨停的，排除弱势的），覆盖不同板块。

Step 2：获取K线和指标

对每只候选股获取日K线数据（近20个交易日），计算 1d/5d/20d 涨跌幅、均线位置、成交量变化。

Step 3：单次LLM分析（DeepSeek推荐）

构建包含所有候选股行情+K线数据的提示，用单次 LLM 调用完成： - 多空分析 - 评分排序 - 仓位建议 - 入场/止损参考价

为什么不用 TradingAgents 多 Agent 系统？ - MiniMax 频控无法绕过 - mootdx 模块缺失（技术指标无法计算） - akshare 新闻源 PyArrow 正则bug - 时间成本太高（单只2-3分钟，5只需15+分钟）

⚠️ 注意事项

  1. 彻底放弃 mootdx — 维护成本高、依赖本地数据、不如腾讯实时
  2. 彻底放弃 MiniMax 做分析 — 频控是硬伤，仅用于快速文本处理
  3. 腾讯财经数据格式不稳定 — 返回文本需要 robust 的解析逻辑，字段顺序可能变化
  4. 所有路径写绝对路径 — OpenClaw 执行时的工作目录不可控
  5. DeepSeek （localhost:8644） 是最佳分析 LLM — 无频控、速度快、处理长提示能力强