Skip to content
BranchesTags

Repository files navigation

AutoTrading

Owning a Hedge Fund: AutoTrading as an AI-Native Trading Firm

Gemini_Generated_Image_9ufot79ufot79ufo

Acknowledgement

AutoTrading 的整体架构设计参考了 TradingAgents，这里也对该项目致敬。

TradingAgents 更偏向围绕单个股票展开多代理分析与决策，而 AutoTrading 更强调一条每天运行的自动化链路：从选股、送审、交易，到执行状态同步和看板展示，尽量放进同一套日常工作流里。

AutoTrading 是在 TradingAgents 提供的架构方向上，进一步扩展成了从候选发现到交易执行的完整自动化系统。

What It Does

  • Market Regime
    • 判断当前市场所处环境，生成风险偏好、开仓上限、顺逆势约束，并把这套上下文传给 Screener、Investment Committee 与 Execution
    • 当前回答的问题是：未来 1-5 个交易日，市场更奖励哪一侧表达，这种奖励环境有多强
  • Screener
    • 同步行情、结合 Market Regime 运行多策略候选池、补充公司与动态信息、导出候选池、综合排名与终选队列快照
    • 共享 profile cache + daily enrichment cache 已接入正式链路：公司简介长期复用，近期动态 / 强势原因 / 事件基本面按交易日复用
  • InvestmentCommittee
    • 以多分析师视角完成基本面、技术面、风险面与总结性评审，并在 Regime 约束下判断仓位、确认门槛与风险暴露
    • 输出完整报告、交易计划、失效条件与最终裁决，而不是只给一个简单打分
  • Execution
    • 读取 Regime 风险边界与 IC 结论，组合送审名单、生成执行计划、同步 paper trading 挂单/成交/持仓状态
    • 支持持仓监控、退出规则、空仓补位和主动换仓
  • web
    • 统一展示 Regime / Screener / Investment Committee / Execution / Reflection 页面
    • 首页已经收口为更紧凑的交易工作台总控入口：总览、状态、五步链路和五个工作台入口合并在同一首屏里，不再把首页拆成多段解释型展示页
    • Reflection 页面负责把 outcomes、IC uplift、策略归因和 batch replay 放回同一套日常看板
    • 全局 shell 对首页不再额外重复渲染 System Overview 说明，避免壳层与正文首屏信息打架

Architecture Overview

Technical Architecture
From market regime sensing to execution orchestration and dashboard visibility

autotrading-system-overview

Current Strategy Layout

当前 Screener 的候选式策略分为两类：

  1. base_6m_high 六个月新高强势股。作为基础候选池策略，偏趋势、强势延续和近期动态。
  2. hot_theme X 热门主题池。聚合过去 24 小时的 X 列表内容，提取 ticker、热度、逻辑硬度和 X Thesis Pack。

Execution 当前默认采用多策略送审模式：

  • 策略一与新策略二共同进入组合候选池
  • Gemini 综合打分层统一重排两条策略的候选
  • 综合打分 V2 只保留交易向维度：爆发力、早期爆发、买入即盈利、弹性重估、趋势持续、科技主线相关度、逻辑硬度与关注度
  • Top 5 排序优先满足“买入即盈利 / 早期爆发 / 弹性重估 / 趋势持续”四项中至少两项强的候选
  • 科技主线相关度仍是强约束；非核心主线票必须有显著更高的即时收益或弹性重估，才允许压过 AI/半导体/光通信/存储/数据中心/电力基建候选
  • 综合排名 Top 10 送入 Investment Committee
  • 后续 Execution 只消费这份 Top 10 review queue 对应的 IC 决策

当标的来自新策略二，或携带 x_thesis_pack 时，Investment Committee 会额外启用第七位分析师 X 舆情与观点分析师。

Module Deep Dive

1. Market Regime

Market Regime 不是一个装饰性指标，而是整个系统的上游环境层。

它当前会输出：

  • label
    • STRONG_UP / UP / NEUTRAL / DOWN / STRONG_DOWN
  • score
    • 当前市场方向强弱分
  • drivers
    • 广度、follow-through、setup quality 等驱动项
  • trade_profile
    • 执行层真正会用到的风控参数，例如：
    • direction_bias
    • entry_selectivity
    • aligned_size_multiplier
    • counter_size_multiplier
    • reserve_cash_multiplier
    • max_open_positions

它主要影响三件事：

  1. Screener
    • 策略二综合排名接入 regime_fit_score
    • 候选解释会展示当前环境和方向适配关系
  2. InvestmentCommittee
    • 提示词中会注入 Market Regime 约束包
    • 分析师不能只讨论个股，也要判断当前表达是否顺势、是否需要降仓或等待确认
  3. Execution
    • 开仓上限、现金保留、逆势仓位折扣等，都由 trade_profile 约束

当前 Market Regime 的核心脚本已经抽到独立模块里，消费入口暂时仍跨模块分布：

  • MarketRegime/src/market_regime/__init__.py
  • MarketRegime/src/market_regime/legacy_strategy.py
  • Execution/src/execution/market_regime.py
  • Screener/src/strategy.py
  • InvestmentCommittee/.../agents/utils/prompting.py
  • web/app/regime/page.tsx

也就是说，当前目录已经独立，核心计算脚本也已经进入 MarketRegime/，只是为了兼容现有日常任务，旧入口还保留了一层兼容转发。

2. Screener

Screener 负责做候选式策略，不负责直接下单。

它当前统一复用的能力包括：

  • 行情与基础数据同步
  • 多策略候选池生成
  • 公司信息、近期动态、强势原因或策略特征补充
  • 主题分组、综合排名、Top 10 IC 送审队列导出
  • 向 Investment Committee 交付统一送审上下文

当前两类候选式策略：

  1. base_6m_high
    • 六个月新高强势股
    • 偏趋势延续、强势确认、近期动态和交易可买性
  2. hot_theme
    • X 热门主题池
    • 聚合过去 24h 的 X 列表内容，提取 ticker、热度、逻辑硬度、证据质量与 X Thesis Pack

当前送审口径：

  • 策略一与新策略二共同参与组合候选池与 Gemini 综合打分
  • 最终形成综合排名 Top 10 的统一送审队列
  • 内部数据库字段仍沿用历史 top5 / SelectionStage.TOP5 命名，但当前业务含义是 IC Top 10 review queue
  • 综合打分不再输出流动性分、风控分或风险等级；Grounding Search 只补充最新催化、产业链位置、同板块联动和关注扩散四类证据

当前两条策略的信息补全也已经统一：

  • base_6m_high
    • 负责批量生成公司简介、近期动态、强势原因、事件基本面与市场总摘要
  • hot_theme
    • 继续以 X Thesis Pack 为主，但会额外拼接外部新闻 / 事件 / 基本面补充；当前 extractor 和 selector 默认使用 GA gemini-3.1-flash-lite

对外展示时，每只票当前都会统一暴露：

  • company_cn
  • news_summary
  • strength_reason
  • event_fundamental
  • strategy_context_note
  • news_points / strength_points / event_fundamental_points / strategy_context_points

3. Investment Committee

661

Investment Committee 不是单一模型打分器，而是一条分层研究链。

当前正式链路按快慢模型分层运行，和新策略二的 X 热点池内容生成模型分开：

  • Quick 阶段默认使用 gemini-3-flash-preview
  • Deep / executive 阶段当前也默认使用 gemini-3-flash-preview，作为成本观察模式运行
  • google_thinking_level 默认提升到 high
  • Quick 阶段不允许降级到 flash-lite
  • Deep / executive 仍保留独立字段与更长 timeout，但默认不再先打 Pro；如需恢复 Pro，可通过 INVESTMENT_COMMITTEE_DEEP_MODEL=gemini-3.1-pro-preview 显式覆盖
  • 503 UNAVAILABLE / high demand 会等待后重试同一模型；重试耗尽后失败并阻断下游，不再产出降级 completed review
  • 每一份角色报告落盘时都会自动写入 Provider / Model / Family / Thinking Level 来源头
  • Execution 只接受“关键分析师 + 研究经理 + 交易员 + Fund Manager 都不是 degraded”的完整评审结果；降级兜底不再当成有效 completed review 入库

当前 Dashboard 展示口径：

  • Run 切换 会直接标出每只票来自哪条候选池策略，使用轻量数字 1 / 2 对应策略一 / 新策略二
  • 最终动作与执行建议 会保留 交易结论 与 执行动作 的完整段落，不再只截第一句
  • 模型调用阶段与 Token 统计 必须按真实阶段归因，逐角色展示实际输入 / 输出 Token，不允许出现整列 0
  • 单角色报告正文默认收敛为一张卡片，model-source 注释不会直接暴露在正文里，只以结构化模型信息展示

基础分析师层

默认启用 6 位基础分析师：

  1. 市场结构分析师
  2. 技术指标分析师
  3. 新闻事件与披露分析师
  4. 社区叙事分析师
  5. 基本面分析师
  6. 宏观与外部风险分析师

若标的来自新策略二，额外启用第 7 位：

  1. X 舆情与观点分析师

研究与裁决层

基础分析师之后，链路继续往下流转：

  • Bull Researcher
    • 从多头角度整合全部分析师结论
  • Bear Researcher
    • 从空头角度整合全部分析师结论
  • Research Manager
    • 作为研究经理与裁判，综合全部报告，识别共识、分歧、盲区和关键闸门
  • Trader
    • 把研究判断翻译成执行计划、分批方案、触发条件和失效条件
  • Fund Manager
    • 形成最终裁决，例如 买入 / 增持 / 持有 / 减持 / 卖出

Investment Committee Runtime

Investment Committee 当前已经不再适合继续把业务主链绑死在通用 Agent 框架上。

当前仓库内并存 4 种运行模式：

  1. legacy
    • 旧版 LangGraph / LangChain 风格链路，仍是现网兼容兜底
  2. agents_sdk_shadow
    • 只并行记录 Phase 1 基础分析师结果，用于和 runtime_v2 主执行做对照
  3. agents_sdk
    • 本地化的完整 IC 编排，已经支持 Phase 1 独立分析师并发
  4. runtime_v2
    • 当前默认的 IC 生产运行时
    • 保留当前角色体系和报告结构
    • 把运行时模式、候选输入包、LLM Gateway、阶段编排与 Dashboard 分发拆成独立层

runtime_v2 的目标不是“再包一层框架”，而是把下面这些能力变成 AutoTrading 自己可维护的基础设施：

  • 候选输入包 CandidatePacket
  • 统一 runtime launch bridge、LLM Gateway 与 provider 参数注入
  • Phase 1 基础分析师并发执行
  • 后续 Bull / Bear / Research Manager / Trader / Fund Manager 串行收敛
  • Dashboard 侧的多 runtime 选择与可观测性

Dashboard / RuntimeManager 这一层现在也不再让 agents_sdk 与 runtime_v2 各自维护整套事件落盘和 finalize 逻辑，而是共用一条结构化 runner bridge；现在默认 production runtime 已经切到 runtime_v2，因此后续收敛主路径时不需要再同时维护两套 dashboard 主控。

同时，legacy runtime 也已经收口到独立 legacy_bridge，避免 RuntimeManager 同时承担 chunk ingest、final merge、artifact 落盘和 runtime dispatch 四类职责。

Execution -> Investment Committee 的正式链路现在也已经显式 pin 到 runtime_v2，不会再把生产 runtime 的选择留给本地环境变量偶然决定。

当前 Phase 1 并发不是“把 worker 调大就行”，而是按运行时策略自动收敛：

  • 只允许 market_structure / technical_indicators / event_and_disclosure / community_narrative 进入并发段
  • x_sentiment_and_view 以及后续 fundamentals / macro / synthesis / decision 全部保持串行
  • worker 数同时受 agents_sdk_phase1_max_workers、provider transport 上限，以及模型级 cap 约束
  • 默认 Google / Gemini 路径会保留一部分并发余量，避免单一 ticker 占满 transport slot
  • 默认策略下，当前 IC 成本观察模式主要使用 Gemini 3 Flash，Phase 1 最多 4 并发；Gemini 3.1 Pro 的 3 并发 cap 仅在显式恢复 Pro 时生效

同时，正式 review 链路现在已经额外收紧了 Google / Gemini 的真实请求放大问题：

  • Execution 层 review worker 默认 1
  • review 级 retry 默认 1
  • Google provider retry 默认 1
  • transport retry 默认 1
  • gemini-3.1-pro-preview 仍保留 24 RPM / 240 RPD 安全边际配置，但当前默认链路不会主动使用 Pro
  • 命中 429 / 503 时会进入共享 cooldown，而不是继续并发重打上游
  • 如果 Google 明确返回 retryDelay / Please retry in ...，本地共享预算会直接记住这段长冷却时间，后续 review 进程会立刻停手，不再把同一天剩余 ticker 轮流撞到日额度上

这也是后续继续抽离 Execution、清理长链路耦合、补稳态保障的基础。

Investment Committee 流程图

investment-committee-flow

对外可以把它理解为：

  • 上游先把事实拆开看
  • 中游再做多空辩论
  • 下游把结论翻译成可执行交易计划

4. Execution

execution-lifecycle

Execution 的职责不是“重复研究”，而是把 Investment Committee 结论真正落到可追踪的执行状态上。

当前它负责：

  • 组合多策略送审名单
  • 读取 Market Regime 的仓位与风险边界
  • 解析 Investment Committee 的执行动作、触发条件、失效条件
  • 生成 execution plan
  • 同步 paper trading 的 intent / order / fill / position
  • 在真正进入执行前校验 review queue 与实际 decision 集合是否完整对齐
  • 监控当前持仓是否继续持有、观察、减仓或退出
  • 在满足条件时做空仓补位与主动换仓

Execution 当前覆盖的执行能力

  1. 建仓
    • 不是简单“IC 说可以买就直接市价买入”
    • 会保留分批、价格区间、禁追高、失效条件等执行语义
  2. 退出
    • 同时看 Investment Committee 失效条件与 Execution 默认风险规则
    • 当前包含止损、盈利后跌破 MA10 的止盈逻辑等
  3. 空仓补位
    • 有空余仓位时，从当日 Top 10 已评审候选中挑选可执行标的补位
  4. 主动换仓
    • 当仓位已满且强弱差距足够大时，允许做 rotation_exit + replacement_entry
    • 会记录建议换仓、实际执行结果、挂单状态和最终持仓变化

当前 Execution 内部主服务也已经按职责拆开：

5. Reflection & Dashboard

这套系统现在不只关注“今天选了什么、下了什么”，也开始回答“过去这批评审到底有没有持续产生价值”。

当前 Dashboard 已经补上独立的 Reflection 页面，核心能力包括：

  1. Reflection Overview
    • 按 batch 展示不同 horizon 的 outcome completion 进度
    • 显示 IC uplift，比较 accepted / rejected / shortlist 的 forward return 差异
  2. Reflection Batch Detail
    • 以单个 batch 为中心回看 ticker、IC 结论、执行状态与 replay 摘要
    • 支持按日期与 horizon 切换，不再只盯最新一天
  3. Strategy Summary
    • 从策略维度聚合 signal outcomes，帮助判断 base_6m_high / hot_theme 的真实表现
  4. Scheduler Telemetry
    • 在看板里直接显示 plan / reconcile / reflection-refresh 的最近执行状态
    • 不用再翻日志确认每天早上的回补有没有跑完

reflection-refresh

Execution 侧现在提供了独立命令：

python main.py reflection-refresh

这个命令会：

  • 批量刷新最近 candidate batches 的 1 / 3 / 5 / 10 / 20 日 outcomes
  • 重新生成对应 batch 的 IC uplift
  • 自动把最大 horizon 仍未成熟的旧批次一起纳入回补窗口，而不是只处理最新几天

这意味着即使最新 batch 还没有完整 forward return，更早已经成熟的批次也会被持续补齐，Reflection 页会优先呈现那些已经有完整窗口的数据。

每日调度

Dashboard 的统一 scheduler 现在默认包含四段日常动作：

  1. plan-and-submit
    • 新交易日生成候选、送审并尝试执行
    • longbridge_paper 模式下会在批次执行后立即跟一轮 sync-paper，确保当日结果里就能看到挂单 / 补位 / 换仓结论，而不是只留下空白的基础 intent 计数
  2. sync-paper
    • 早晨同步 paper trading 的订单、成交和持仓状态
    • 若存在满仓但候选明显更强的场景，也会继续产出 rotation_exit -> replacement_entry 的执行结果
  3. rotation-followup
    • 只在美东开盘后 09:31-09:35 的 5 分钟窗口内启用
    • 每分钟检查一次已提交的 rotation_exit
    • 若卖单已由 broker 确认成交，则当天立刻补挂 rotation_entry，不再等到第二天早晨
    • 换仓补买只引用同一交易日的候选决策，避免旧候选被跨日恢复流程重新激活
    • 时间判断统一基于 America/New_York 市场时区，夏令时 / 冬令时自动跟随切换
  4. reflection-refresh
    • 在 reconcile 之后自动刷新 outcomes / uplift / strategy rollup

默认本地时间窗口：

  • plan: 13:00
  • reconcile: 06:15
  • rotation follow-up: 美东 09:31-09:35 每分钟一次
  • reflection: 06:30

可通过环境变量调整：

  • AUTOTRADING_SCHEDULER_PLAN_TIME

  • AUTOTRADING_SCHEDULER_RECONCILE_TIME

  • AUTOTRADING_SCHEDULER_REFLECTION_TIME

  • CandidatePipelineService

    • 统一处理候选抓取、组合策略去重、LLM ranking 与持久化

  • SyncPaperService

    • 统一处理初始同步、卖出同步、缺失换仓买单补齐、空仓补位、主动换仓与结果汇总

  • PipelineCheckpointService

    • 在 execution 前阻断不完整的 IC 批次，避免缺报告或缺 decision 的队列继续下沉

当前 Execution 的 review 保障口径：

  • IC review retry 已从硬编码常量迁移到 ExecutionConfig
  • 默认 review 层 Quick / Deep 均使用 gemini-3-flash-preview；Pro 只在显式设置 INVESTMENT_COMMITTEE_DEEP_MODEL=gemini-3.1-pro-preview 后进入主路径
  • 可通过 INVESTMENT_COMMITTEE_RETRY_ATTEMPTS 与 INVESTMENT_COMMITTEE_RETRY_DELAYS_SECONDS 调整
  • ExecutionOrchestrator 现在更偏向装配层，review / paper pipeline / checkpoint / sync broker 逻辑都下沉到独立 service

Execution 状态机

当前页面与账本会区分这些执行状态：

  • 待挂单
  • 挂单中
  • 部分成交
  • 已建仓
  • 持仓中
  • 已止损
  • 已止盈
  • 已失效撤单
  • 已清仓

也就是说，Investment Committee 有结论 不等于 已经成交。 Longbridge 已确认成交 还必须通过本地订单数量上限校验：同一 order_id 的累计成交量不得超过 paper_orders.quantity，超量 execution 只进入审计 metadata，不会污染本地账本。

Repository Layout

.
├── MarketRegime/          # Market Regime 模块说明与后续抽离入口
│   └── src/market_regime/ # Market Regime 核心计算与 legacy helper
├── Screener/              # 候选池生成、导出、策略运行时
├── InvestmentCommittee/   # 多分析师评审、报告与 API
├── Execution/             # 送审队列、执行计划、paper trading 编排
├── web/                   # Next.js 看板
├── docs/                  # 项目文档与运行说明
├── scripts/               # 辅助脚本
└── main.py                # 根 CLI，串联 Screener / IC / Execution

其中 Market Regime 相关逻辑当前主要分布在：

  • MarketRegime/src/market_regime/__init__.py
  • MarketRegime/src/market_regime/legacy_strategy.py
  • Execution/src/execution/market_regime.py
  • InvestmentCommittee/.../market_structure_analyst.py
  • web/app/regime/page.tsx

Daily Pipeline

标准链路如下：

  1. Market Regime 先汇总指数、广度、事件与市场结构，生成当天的市场环境与交易边界
  2. Screener 同步并更新行情，在 Market Regime 上下文中运行两路候选策略并导出快照
  3. Execution 组合多策略结果，并由 Gemini 综合打分层统一选出当天 Top 10 送审队列
  4. InvestmentCommittee 对送审标的做完整评审，并结合 Market Regime 判断是否顺势、是否需要降仓或等待确认
  5. Execution 生成执行计划并同步 paper trading 状态，卖出 / 调仓 / 持仓上限同样受 Regime 约束
  6. web 展示 Regime、候选池、评审结果、执行计划与持仓变化

Further Reading

Requirements

  • Python 3.11+
  • Node.js 20+
  • 一个可用的虚拟环境
  • 可选：
    • Google / Gemini API Key，用于 Screener 与 Investment Committee 的 LLM 任务
    • Longbridge 纸面账户凭据，用于 paper trading
    • Google / Gemini API Key，用于新策略二的高频 X Thesis Pack 提取
    • 一个已生成的 X digest 数据目录，用于新策略二

Setup

git clone https://github.com/jacksong19/AutoTrading.git
cd Autotrading

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

cd web
npm install
cd ..

如果你为 InvestmentCommittee 或 Execution 单独维护了虚拟环境，也可以继续沿用；根 CLI 会优先读取显式配置的 Python 路径。

Environment Variables

下面是当前公开版 README 建议保留的最小环境变量集合。所有值都应由本地环境注入，不要提交到仓库。

# Root CLI
export AUTO_TRADING_ROOT="/path/to/Autotrading"
export AUTO_TRADING_PYTHON="/path/to/Autotrading/.venv/bin/python"

# LLM
export GOOGLE_API_KEY="your_google_api_key"
export OPENAI_API_KEY="your_openai_api_key"

# Longbridge paper trading
export LONGBRIDGE_APP_KEY="your_longbridge_app_key"
export LONGBRIDGE_APP_SECRET="your_longbridge_app_secret"
export LONGBRIDGE_PAPER_ACCESS_TOKEN="your_longbridge_paper_access_token"
export LONGBRIDGE_ACCOUNT_MODE="paper"

# Strategy 2 / X digest
export X_INFO_DIGEST_REPORT_ROOT="/path/to/x_info_digest/data/reports/stock_digest"

# Optional strategy 2 overrides
export HOT_THEME_EXTRACTOR_PROVIDER="google"
export HOT_THEME_EXTRACTOR_MODEL="gemini-3.1-flash-lite"
export HOT_THEME_SELECTOR_MODEL="gemini-3.1-flash-lite"
export HOT_THEME_LLM_PIPELINE_TIMEOUT_SECONDS="7200"

说明：

  • GOOGLE_API_KEY 是当前 Screener 与部分排名 / 研究流程的主要云端 LLM 入口。
  • OPENAI_API_KEY 目前用于部分价格解析与文本清洗任务。
  • 如果不跑 paper trading，可以先不配置 Longbridge。
  • 新策略二当前默认使用 GA google/gemini-3.1-flash-lite 做 per-ticker thesis 提取和统一主排名。
  • 这个 flash-lite 只属于 Screener 新策略二内容生成；正式 IC review 的 Quick / Deep 模型不使用 flash-lite。
  • 如果需要覆盖默认模型，可以显式设置 HOT_THEME_EXTRACTOR_* / HOT_THEME_SELECTOR_* 环境变量。
  • 如果不跑新策略二，可以先不配置 X_INFO_DIGEST_REPORT_ROOT。

Core Commands

根 CLI 当前提供以下正式命令：

  • screener-daily
  • run-daily
  • plan-and-submit
  • recover-reviews
  • sync-paper
  • reconcile
  • dashboard-dev
  • dashboard-release
  • dashboard-status

常见用法：

# 仅运行 Screener
$AUTO_TRADING_PYTHON main.py screener-daily --date 2026-04-15

# 运行全链路：Screener -> IC -> Execution
$AUTO_TRADING_PYTHON main.py run-daily --date 2026-04-15

# 对最新可交易日生成并提交一批 paper 计划
$AUTO_TRADING_PYTHON main.py plan-and-submit --date 2026-04-15

# 单独补跑 broker 同步 / 空仓补位 / 主动换仓
$AUTO_TRADING_PYTHON main.py sync-paper --date 2026-04-15

# 回补已存在批次中缺失的 IC 评审
$AUTO_TRADING_PYTHON main.py recover-reviews --date 2026-04-15 --ticker NVDA.US

# 启动开发看板
$AUTO_TRADING_PYTHON main.py dashboard-dev

Phase 3 Reflection Loop Commands

Phase 3 这批能力属于 Execution 研究闭环，不挂在根 main.py，而是通过 Execution CLI 单独运行。

推荐入口：

./scripts/execution <command> ...

当前新增命令：

  • compute-outcomes
  • replay-batch
  • report-ic-uplift

常见用法：

# 为一个已有批次计算 forward returns / benchmark / excess return
./scripts/execution compute-outcomes --batch-id <batch_id> --horizons 1,5,10,20

# 按交易日为最新批次计算 outcomes
./scripts/execution compute-outcomes --date 2026-04-15

# 回放某个 batch 的候选、评审、执行、成交与 outcomes
./scripts/execution replay-batch --batch-id <batch_id>

# 看 IC 对 shortlist 的增量价值，默认看 5 个交易日
./scripts/execution report-ic-uplift --batch-id <batch_id> --horizon 5

这些命令的主要作用：

  • compute-outcomes
    • 把 candidate_signals 扩展成可研究的历史结果，写入 candidate_signal_outcomes
    • 输出 forward_return_pct / benchmark_return_pct / excess_return_pct / data_asof
  • replay-batch
    • 把单日 batch 的 candidate_signals / review_decisions / order_intents / paper_orders / paper_fills / outcomes 一次性拉出来
    • 用于复盘、调试、看板扩展和后续 replay
  • report-ic-uplift
    • 对比 shortlist / accepted / rejected 在指定 horizon 下的平均收益与超额收益
    • 用来回答 “IC 到底有没有带来增量价值”

更完整的使用说明见 docs/phase3_reflection_loop_usage_2026-04-19.md。

Strategy Notes

Strategy 1: base_6m_high

  • 定位：基础候选池策略
  • 特征：偏趋势延续、强势确认、近期动态和交易可买性
  • 送审：参与统一综合打分；综合 Top 10 才进入 IC

Strategy 2: hot_theme

  • 定位：X 热门主题 / 热门观点池
  • 输入：过去 24 小时的 X digest 数据
  • 输出：ticker 聚合、热度、逻辑硬度、证据质量、X Thesis Pack
  • 送审：参与统一综合打分；综合 Top 10 才进入 IC

策略二不是简单的“热度榜”，而是综合以下维度排序：

  • 提及频次
  • 来源数量
  • 高质量样本数量
  • 逻辑硬度
  • 证据质量
  • LLM 选择器的综合判断

Composite Scoring V2

  • 定位：策略一与新策略二之后、Investment Committee 之前的全量综合排序层
  • 编排：第一次用 gemini-3.1-pro-preview 只输出全量评分；第二次用 gemini-3-flash-preview 只输出全量摘要解释
  • 保留维度：爆发力、早期爆发、买入即盈利、弹性重估、趋势持续、科技主线相关度、逻辑硬度、关注度
  • 删除维度：流动性、风控、风险等级
  • 交易门槛：Top 5 优先满足“买入即盈利 / 早期爆发 / 弹性重估 / 趋势持续”四项中至少两项强
  • 主线门槛：科技主线相关度作为强约束参与最终排序，避免非主线强趋势杂票挤占送审前排
  • 输出约束：每个候选带稳定 id，评分和摘要两次输出都必须全量覆盖；评分漏项会先做全量重试，再做降级补漏
  • UI：不再展示“追涨方式”，只展示中文分数字段和摘要理由

综合打分层仍然输出全量 rank；Top 3 / Top 5 / Top 10 / Top 20 都只是数据库查询口径，不单独生成榜单。

Dashboard

web/ 目录提供统一看板，覆盖：

  • 市场状态与 Regime 概览
  • Screener 两路策略候选池
  • Investment Committee 多分析师报告
  • Execution 的送审、计划、挂单、成交与持仓状态

对外建议把开发环境地址、反向代理地址和本地 host 规则放在私有运维文档中；本 README 不再绑定任何个人机器上的固定端口或本地域名。

Sensitive Data Policy

仓库默认不应提交以下内容：

  • .env、私钥、token、cookie、会话文件
  • 本地数据库、订单回写库、paper trading 账本
  • Screener / InvestmentCommittee / Execution 的运行时结果目录
  • web/public/data/*.json 这类每日快照

当前 .gitignore 已排除主要运行时数据目录，但在准备公开仓库前，仍建议再做一次完整审查。

License

This repository is released under the MIT License.

Disclaimer

This repository is an autonomous stock-selection, market-regime, research, and paper-trading workflow for personal research and simulation. It automates candidate discovery, multi-analyst review, execution planning, portfolio monitoring, and rotation in a paper-trading setup by default. It is not investment advice, and any live-trading use would still require separate risk controls, broker safeguards, and compliance review.

About

Autonomous trading agent for stock screening, research, and paper-trading execution with continuous rotation workflows

Topics

automationllmnextjspaper-tradingpythonquanttradingtrading-agent

Resources

Readme
MIT license

Contributing

Contributing

Security policy

Security policy
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors

Languages