refactor documentation structure and consolidate TODO tracking
This commit is contained in:
sam
parent
1eaf0fd69a
commit
2678ec6942
203
README.md
203
README.md
@ -1,155 +1,106 @@
|
|||||||
# 多智能体个人投资助理
|
# 多智能体量化投资个人助理
|
||||||
|
|
||||||
## 项目简介
|
面向 A 股日线级别的多智能体投资研究平台，整合数据采集、因子工程、部门化 LLM 决策、强化学习调参与可视化展示，帮助投研团队快速搭建可落地的策略助手。
|
||||||
|
|
||||||
本仓库提供一个面向 A 股日线级别的多智能体个人投资助理原型，覆盖数据采集、特征抽取、策略博弈、回测展示和 LLM 解释链路。代码以模块化骨架形式呈现，方便在单机环境下快速搭建端到端的量化研究和可视化决策流程。
|
## 快速了解
|
||||||
|
|
||||||
## 架构总览
|
- **端到端闭环**：从行情/新闻抓取、特征存储到多智能体协同决策、回测评估与可视化一体化。
|
||||||
|
- **多角色博弈**：主持、预测、风险、执行等角色按轮次协同，支持 LLM 与规则代理混合。
|
||||||
|
- **强化学习调参**：`DecisionEnv` 将回测引擎包装为 RL 环境，已接入 PPO/SAC 等连续动作算法。
|
||||||
|
- **风险优先**：风险回合可调整最终指令并记录风控证据，提供复核与告警通道。
|
||||||
|
- **模块化扩展**：数据层、因子库、代理、Prompt、实验脚本均以独立模块维护，便于替换或二次开发。
|
||||||
|
|
||||||
- **数据与存储层**：`app/ingest` 封装 TuShare/RSS 拉数与限频处理，`app/data/schema.py` 初始化 SQLite 表结构，所有模块通过 `app/utils/db.py` 的 `db_session` 访问 `app/data/llm_quant.db`，数据抽象层由 `app/utils/data_access.py` 的 `DataBroker` 统一提供字段查询与时间序列切片。
|
## 系统构成
|
||||||
- **工具与配置层**：`app/utils` 聚合配置、日志、交易日历及 provider 管理，`app/utils/config.py` 定义 LLM/部门/代理权重等全局设置。
|
|
||||||
- **特征与策略层**：`app/features` 负责信号构建（当前为占位实现），`app/agents` 实现六类规则型代理与部门级 LLM 协同，`app/backtest/engine.py` 通过 `DataBroker` 装配特征/上下文后运行多智能体博弈并将结果写入 `agent_utils`。
|
|
||||||
- **LLM 与协作层**：`app/llm` 提供统一的模型调用与 Prompt 构建，支持 single/majority/leader 策略，部门输出再与规则代理共同决策。
|
|
||||||
- **可视化层**：`app/ui/streamlit_app.py` 提供今日计划、回测、设置、自检四大页签，实时读取 `agent_utils`、`run_log` 追踪决策链路。
|
|
||||||
|
|
||||||
> 经典模块划分仍保留在文末《实施步骤》中，便于对照逐项推进。
|
- **数据管线**（`app/ingest`, `app/utils/data_access.py`）
|
||||||
|
TuShare/RSS 拉取与限频处理，`DataBroker` 统一提供行情、特征与派生字段，支持健康监控与回退。
|
||||||
|
|
||||||
## 智能体策略速览
|
- **因子与特征**（`app/features`）
|
||||||
|
`compute_factors()` 负责批量计算与持久化，包含动量、估值、情绪、风险等因子，并预留增量模式与公式校验。
|
||||||
|
|
||||||
- **动量 (`A_mom`)**：基于 `mom_20/mom_60` 的 Sigmoid 强度判定买卖梯度。
|
- **多智能体协作**（`app/agents`）
|
||||||
- **价值 (`A_val`)**：组合 PE/PB/ROE 分位，低估值与高质量越倾向买入。
|
规则代理与部门 LLM 通过 `DepartmentManager`、`ProtocolHost` 参与博弈，风险回合可否决或调整仓位。
|
||||||
- **新闻 (`A_news`)**：按新闻热度与情绪正负分配买卖权重，热度低时偏好持有。
|
|
||||||
- **流动性 (`A_liq`)**：衡量 `liquidity_score` 与交易成本惩罚，约束加仓节奏。
|
|
||||||
- **宏观 (`A_macro`)**：关注行业热度与相对强弱，多头动能越强，则买入级别越高。
|
|
||||||
- **风险 (`A_risk`)**：根据 `risk_penalty` 调整信心，并在停牌/涨停/仓位限制场景下行使否决权。
|
|
||||||
|
|
||||||
部门级智能体通过 `DepartmentManager` → `DepartmentAgent` → `department_prompt()` 的链路向 LLM 请求 JSON 化决策（动作、置信度、摘要、信号、风险），输出在 `app/agents/game.py` 中与规则代理共同参与纳什谈判或加权投票。
|
- **强化学习/优化**（`app/backtest/decision_env.py`, `scripts/train_ppo.py` 等）
|
||||||
|
将参数搜索、权重调节、提示版本选择统一抽象为动作，回测指标写入 `tuning_results` 便于对比。
|
||||||
|
|
||||||
## 当前瓶颈
|
- **可视化 UI**（`app/ui/streamlit_app.py`）
|
||||||
|
今日计划、回测复盘、监控、自检页面提供策略轨迹、风险监控、实验结果与配置管理。
|
||||||
|
|
||||||
- **数据获取**：`BacktestEngine.load_market_data()` 仍为空实现，规则型代理依赖外部写入的 `AgentContext.features`，缺乏统一的取数协议。
|
架构调用链示意可参考 `docs/architecture_call_graph.md`。
|
||||||
- **角色提示**：部门 `description` 尚未注入 Prompt，代理职责依旧“写死”在 Python 逻辑中。
|
|
||||||
- **过程记录**：缺少对“请求了哪些数据、执行了哪些 SQL、LLM 收到什么上下文”的显式追踪，不利于复盘。
|
|
||||||
|
|
||||||
## 提示词驱动的改造方向
|
|
||||||
|
|
||||||
1. **配置声明角色**：在 `config.json`/`DepartmentSettings` 中补充 `description` 与 `data_scope`，`department_prompt()` 拼接角色指令，实现职责以 Prompt 管理而非硬编码。
|
|
||||||
2. **统一数据层**：新增 `DataBroker`（或同类工具）封装常用查询，代理与部门通过声明式 JSON 请求所需表/字段/窗口，由服务端执行并返回特征。
|
|
||||||
3. **函数式工具调用**：通过 DeepSeek/OpenAI 的 function calling 暴露 `fetch_data` 工具，LLM 只需声明所需表（如 `daily`、`daily_basic`）及窗口，系统用 `DataBroker` 拉取整行数据、回传结果，形成“请求→取数→复议”闭环。
|
|
||||||
4. **审计与前端联动**：把角色提示、数据请求与执行摘要写入 `agent_utils` 附加字段，使 Streamlit 能完整呈现“角色 → 请求 → 决策”的链条。
|
|
||||||
|
|
||||||
目前部门 LLM 通过 function calling 暴露的 `fetch_data` 工具触发追加查询：模型只需按 schema 声明 `daily` / `daily_basic` 等表名与窗口，系统使用 `DataBroker` 一次性返回指定交易日的全部列，再带着查询结果进入下一轮提示，从而形成闭环。
|
|
||||||
|
|
||||||
上述调整可在单个部门先行做 PoC，验证闭环能力后再推广至全部角色。
|
|
||||||
|
|
||||||
## 核心技术原理
|
|
||||||
|
|
||||||
- **多智能体博弈**：通过 `app/agents` 定义六类风格化代理，利用纳什谈判与加权投票在 `app/agents/game.py` 中聚合交易动作与信心水平。
|
|
||||||
- **数据覆盖自检**：`app/ingest/tushare.py` 封装 TuShare 拉取、增量更新与覆盖统计，`app/ingest/checker.py` 提供强制补数与窗口化覆盖报告。
|
|
||||||
- **事件驱动回测**：`app/backtest/engine.py` 构建日频回测循环，将代理决策与投资组合状态解耦，便于扩展成交撮合与绩效统计。
|
|
||||||
- **可视化与解释**：`app/ui/streamlit_app.py` 提供四大页签（今日计划、回测与复盘、数据与设置、自检测试），结合 Plotly 图形展示和 `app/llm` 提示卡片生成器，支撑人机协作分析。
|
|
||||||
- **统一日志与持久化**：SQLite 统一存储行情、回测与日志，配合 `DatabaseLogHandler` 在 UI/抓数流程中输出结构化运行轨迹，支持快速追踪与复盘。
|
|
||||||
- **跨市场数据扩展**：`app/ingest/tushare.py` 追加指数、ETF/公募基金、期货、外汇、港股与美股的增量拉取逻辑，确保多资产因子与宏观代理所需的行情基础数据齐备。
|
|
||||||
- **部门化多模型协作**：`app/agents/departments.py` 封装部门级 LLM 调度，`app/llm/client.py` 支持 single/majority/leader 策略，部门结论在 `app/agents/game.py` 与六类基础代理共同博弈，并持久化至 `agent_utils` 供 UI 展示。
|
|
||||||
- **LLM Provider 管理**：`app/utils/config.py` 集中维护供应商的 URL、API Key、可用模型及默认参数，Streamlit UI 可视化配置，全局与部门直接在 Provider 基础上设置模型、温度与 Prompt。
|
|
||||||
|
|
||||||
## LLM + 多智能体最佳实践
|
|
||||||
|
|
||||||
- **强化结构化特征**：除 A 股行情外，引入资金流、因子、宏观等数据，为六类代理提供更丰富上下文。
|
|
||||||
- **场景化 Prompt**：在 `app/llm` 中注入代理贡献、宏观状态和风险事件，让 LLM 输出的策略解释与信号一致。
|
|
||||||
- **闭环反馈机制**：将回测或实盘的真实收益、成交等结果写回 SQLite，用于调整代理权重与 Prompt 语料。
|
|
||||||
- **多层日志监控**：保留代理评分、决策信心、LLM 提示与 UI 操作日志，帮助定位“谁做的决策、为何失败”。
|
|
||||||
- **人机协同流程**：在 UI 呈现代理分歧与 LLM 风险提示，分析师可调权、重跑或复核，实现人在环路的策略流程。
|
|
||||||
|
|
||||||
## 环境依赖与安装
|
|
||||||
|
|
||||||
建议使用 Python 3.10+，并在虚拟环境中安装依赖。
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# 1. 创建并激活 Conda 环境
|
|
||||||
conda create -n llm-quant python=3.11 -y
|
|
||||||
conda activate llm-quant
|
|
||||||
|
|
||||||
# 2. 安装项目依赖
|
|
||||||
pip install -r requirements.txt
|
|
||||||
|
|
||||||
# 3. 设置 TuShare Token
|
|
||||||
export TUSHARE_TOKEN="<your-token>"
|
|
||||||
```
|
|
||||||
|
|
||||||
`requirements.txt` 当前涵盖运行框架所需的核心三方库：
|
|
||||||
|
|
||||||
- Pandas：数据表结构与指标处理
|
|
||||||
- Streamlit：交互式前端
|
|
||||||
- Plotly：行情与指标可视化
|
|
||||||
- TuShare：行情与基础面数据源
|
|
||||||
- Requests：统一访问 Ollama / OpenAI 兼容 API
|
|
||||||
|
|
||||||
### LLM 配置与测试
|
|
||||||
|
|
||||||
- 通过 Provider 管理供应商连接参数（Base URL、API Key、默认温度/超时/Prompt 模板），并支持在界面内一键调用 `client.models.list()` 拉取可用模型列表，便于扩展本地 Ollama 或各类云端服务（DeepSeek、文心一言、OpenAI 等）。
|
|
||||||
- 全局与部门配置直接选择 Provider，并根据需要覆盖模型、温度、Prompt 模板、投票策略；保存后写入 `app/data/config.json`，下次启动自动加载。
|
|
||||||
|
|
||||||
Note: Ollama's `/api/chat` endpoint supports function/tool calling. The client forwards `tools` and optional `tool_choice` when the provider is configured as `ollama`, enabling function calls and tool-based workflows similar to OpenAI-compatible providers.
|
|
||||||
- Streamlit “数据与设置” 页提供 Provider/全局/部门三栏编辑界面，保存后即时生效，并通过 `llm_config_snapshot()` 输出脱敏检查信息。
|
|
||||||
- 支持使用环境变量注入敏感信息：`TUSHARE_TOKEN`、`LLM_API_KEY`。
|
|
||||||
|
|
||||||
## 快速开始
|
## 快速开始
|
||||||
|
|
||||||
|
### 1. 环境准备
|
||||||
|
|
||||||
|
- Python 3.10+（建议使用虚拟环境）
|
||||||
|
- TuShare Token（环境变量 `TUSHARE_TOKEN`）
|
||||||
|
- 可选：LLM 供应商 API Key（`LLM_API_KEY` 等，具体参见 `config.json` 中的 provider 定义）
|
||||||
|
|
||||||
|
```bash
|
||||||
|
python -m venv .venv
|
||||||
|
source .venv/bin/activate # Windows 使用 .venv\Scripts\activate
|
||||||
|
pip install -r requirements.txt
|
||||||
|
|
||||||
|
export TUSHARE_TOKEN="your-token" # 必填
|
||||||
|
export LLM_API_KEY="your-api-key" # 如需调用 LLM
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. 初始化数据与回测
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# 拉取最新行情、特征或新闻（示例脚本，可按需修改参数）
|
||||||
|
python scripts/run_ingestion_job.py --mode daily --date 2024-01-05
|
||||||
|
|
||||||
|
# 运行示例决策环境，验证 RL 闭环
|
||||||
|
python scripts/run_decision_env_example.py
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3. 启动 Streamlit 应用
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
# 启动交互界面（内含数据库初始化、开机检查、样例回测入口）
|
|
||||||
streamlit run app/ui/streamlit_app.py
|
streamlit run app/ui/streamlit_app.py
|
||||||
```
|
```
|
||||||
|
|
||||||
Streamlit `自检测试` 页签提供：
|
应用启动后可在侧边栏配置 LLM Provider、提示模板或监控指标；今日计划页会读取 `agent_utils`、`portfolio_*` 等表展示最新决策。
|
||||||
- 数据库初始化快捷按钮；
|
|
||||||
- TuShare 小范围拉取测试；
|
|
||||||
- 一键开机检查（可自动补数并展示覆盖摘要）；
|
|
||||||
- 股票行情可视化（自动加载近段时间价格、成交量，并展示核心指标）。
|
|
||||||
- 开机检查带进度指示与详细日志，便于排查 TuShare 拉取问题。
|
|
||||||
|
|
||||||
`回测与复盘` 页签提供快速回测表单，可调整时间区间、股票池与参数并即时查看回测输出。
|
## 典型工作流
|
||||||
|
|
||||||
## 下一步
|
1. **数据补全**：定时运行 `scripts/run_ingestion_job.py`，确保行情、基本面、新闻数据齐备。
|
||||||
|
2. **因子计算**：按交易日触发 `compute_factors()`（可通过脚本或定时任务），结果写入 SQLite。
|
||||||
|
3. **代理决策**：规则代理 + LLM 部门协商输出交易建议，风险回合进行复核。
|
||||||
|
4. **回测与调参**：使用 `scripts/train_ppo.py`、`scripts/run_bandit_optimization.py` 等脚本探索参数空间，成果写入 `tuning_results`。
|
||||||
|
5. **可视化复盘**：Streamlit 展示多版本策略表现、风险事件与日志明细，支持“一键重评估”等待办项。
|
||||||
|
6. **上线前验证**：沿线下回测 → 前向测试 → 影子运行的节奏推进，必要时接入外部告警。
|
||||||
|
|
||||||
1. 在 `app/features` 和 `app/backtest` 中完善信号计算、事件驱动撮合与绩效指标输出。
|
## 自动化与实验工具
|
||||||
2. 丰富 `DepartmentContext`（行情快照、风险指标），让部门评估拥有更完整的上下文。
|
|
||||||
3. 使用轻量情感分析与热度计算填充 `news`、`heat_daily` 与热点指数。
|
|
||||||
4. 在 Streamlit 今日计划页增加“重新评估”与日志追踪能力，串联实时调度链路。
|
|
||||||
|
|
||||||
## License
|
- `scripts/train_ppo.py`：使用 PPO 在 `DecisionEnv` 上训练策略。
|
||||||
|
- `scripts/run_bandit_optimization.py`：黑箱调参示例。
|
||||||
|
- `scripts/apply_best_weights.py`：将实验权重写回配置。
|
||||||
|
- `scripts/render_architecture_diagram.py`：根据代码结构渲染架构图。
|
||||||
|
- `scripts/migrations/`：数据库迁移脚本与示例。
|
||||||
|
|
||||||
本项目采用定制的 “LLM Quant Framework License v1.0”。个人使用、修改与分发需保留出处，任何商业用途须事先与版权方协商并签署付费协议。详情参见仓库根目录的 `LICENSE` 文件。
|
更多示例请查看 `scripts/README` 或脚本内联说明。
|
||||||
|
|
||||||
## 多智能体 LLM 投资流程
|
## 文档索引
|
||||||
|
|
||||||
- **部门化结构**：动量、价值、新闻、流动性、宏观、风险等代理视作独立业务部门，利用项目现有的数据/特征处理流程向每个部门提供上下文。
|
- 工作项总览：`docs/TODO.md`
|
||||||
- **多 LLM 协作**：每个部门内部可配置多家 LLM 提供商（如 DeepSeek、OpenAI、文心等）作为智能体助手，分别生成分析意见和风险提示；可通过多数投票、仲裁等策略确定部门结论。
|
- 多智能体原理：`docs/principles/multi_agent_decision.md`
|
||||||
- **部门输出**：统一返回部门行动（买入/卖出/持有）、信心水平以及核心理由 (context + LLM 摘要)，当前实现会将摘要、风险提示与票权写入 `agent_utils`。
|
- 强化学习与调参原理：`docs/principles/reinforcement_learning_tuning.md`
|
||||||
- **跨部门协调**：沿用 `app/agents/game.py` 的纳什谈判/投票结构，将各部门的结论与六类基础代理共同建模，必要时触发冲突检测并标记复核。
|
- 风险控制原理：`docs/principles/risk_management.md`
|
||||||
- **日志与可视化**：Streamlit 今日计划页读取 `agent_utils` 展示部门意见、投票细节与全局行动，可快速核查部门分歧与置信度。
|
- 架构调用示意：`docs/architecture_call_graph.md`
|
||||||
|
|
||||||
## 实施步骤
|
上述文档保持与代码同步，请在功能迭代后一并更新。
|
||||||
|
|
||||||
1. **配置扩展** (`app/utils/config.py` + `config.json`) ✅
|
## 路线图与贡献
|
||||||
- 引入 `llm_providers` 集中管理供应商参数，全局与部门直接绑定 Provider 并自定义模型/温度/Prompt，Provider 页面提供模型列表自动获取；Streamlit 提供可视化维护表单。
|
|
||||||
|
|
||||||
2. **部门管控器** ✅
|
- 当前路线图统一维护在 `docs/TODO.md`。欢迎在 Issue 或 PR 中反馈新的需求与优先级。
|
||||||
- `app/agents/departments.py` 提供 `DepartmentAgent`/`DepartmentManager`，封装 Prompt 构建、多模型协商及异常回退。
|
- 修改代码前建议阅读 `app/utils/config.py`、`app/agents/game.py`、`app/backtest/engine.py` 了解关键路径。
|
||||||
|
- 提交代码请附带必要的单元测试：
|
||||||
|
|
||||||
3. **集成决策链** ✅
|
```bash
|
||||||
- `app/agents/game.py` 将部门评分嵌入纳什谈判/加权投票，并对冲突设置复核标记；`app/backtest/engine.py` 将结果落库。
|
pytest
|
||||||
|
```
|
||||||
|
|
||||||
4. **UI 与日志**（进行中）
|
如有新的模块或实验脚本，请在对应文档与工作项中补充说明，确保团队成员可以快速上手。
|
||||||
- 今日计划页展示部门意见、票权与全局策略，后续补充一键重评估、日志钻取。
|
|
||||||
|
|
||||||
5. **测试与验证**（待补充）
|
|
||||||
- 需完善部门上下文构造与多模型调用的单元/集成测试，结合回测指标对比多 LLM 策略收益差异。
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
TODO
|
|
||||||
1. 在选股时，因子都已经提前算好，不需要再计算了，直接用就行。
|
|
||||||
2. 因子计算的公式再确认下
|
|
||||||
3. 审查整个项目的代码逻辑，从app/ui/streamlit_app.py开始，逐字逐句检查。如一些重复的安全检查可以去掉；明显果实的临时性代码请删除掉；未实现的功能请标记TODO，并给出实现思路；错误的、低效率的调用请修正；代码结构性的问题请指出并尝试修正；复杂不清晰的代码结构请尝试重构；
|
|
||||||
4. 梳理整个项目的所有业务逻辑。针对每个业务，从业务实现角度评估代码功能是否存在问题，是否需要优化，是否需要重构。
|
|
||||||
|
|||||||
@ -1,41 +1,7 @@
|
|||||||
# 风险代理集成规划
|
# 风险代理规划（已汇总）
|
||||||
|
|
||||||
## 目标
|
风险控制相关的原理说明、数据需求与迭代里程碑已迁移至：
|
||||||
- 将 `risk_guard` 回合由占位消息升级为可执行决策：低置信度的部门共识需自动进入复核流程，根据风险因子、仓位约束、外部告警调整最终指令。
|
|
||||||
- 兼容历史回测与实时监控，确保补数、验证和告警闭环共享风险上下文。
|
|
||||||
|
|
||||||
## 数据与信号需求
|
- `docs/principles/risk_management.md`
|
||||||
- **输入特征**：`risk_penalty`、`position_limit`、`is_suspended` 等现有布尔/得分信号；新增日内波动、VaR、行业集中度、外部事件标签（停牌预警、合规黑名单）。
|
|
||||||
- **实时事件**：补数触发的异常、执行失败回报、仓位越界日志；需要通过 `DataBroker.register_refresh_callback()` 和交易执行层的回调管理。
|
|
||||||
- **上下文结构**：在 `AgentContext.raw` 中携带 `risk_flags`、`compliance_notes`，供主持器和前端展示。
|
|
||||||
|
|
||||||
## 决策流程改造
|
请在维护风险策略或更新风控流程时直接修改上述文档，本文件仅作为历史索引保留。
|
||||||
1. **风险评估阶段**
|
|
||||||
- 在部门回合后触发 `risk_round`，由 `RiskAgent` 复写 `Decision` 的 `requires_review` 与 `target_weight`，必要时生成“回滚/减仓”建议。
|
|
||||||
- 引入 `RiskAssessment` 数据类，存储风险来源、建议操作、置信度，序列化到 `Decision.rounds`。
|
|
||||||
2. **执行协调阶段**
|
|
||||||
- 若风险回合给出回滚指令，则 `execution_round` 应记录“冻结执行”或“调整仓位”而非直接落地。
|
|
||||||
- 将风险回合结论写入 `risk_events` 表（或新建），供 UI 与监控使用。
|
|
||||||
3. **日志与监控**
|
|
||||||
- 在 `risk_round` 中附加 `annotations` 字段：`{"breach_metrics": {...}, "actions": [...]}`。
|
|
||||||
- 通过补数回调和执行回调，将风险事件推送到监控指标，如“复核触发率”“回滚成功率”。
|
|
||||||
|
|
||||||
## 实施里程碑
|
|
||||||
1. **原型阶段**
|
|
||||||
- ✅ 重构 `RiskAgent` 以返回策略建议（持仓调整、止损触发）。
|
|
||||||
- ✅ 扩展 `Decision` 结构，增加 `risk_assessment` 字段。
|
|
||||||
- ✅ 更新 `ProtocolHost` 将风险建议纳入 `risk_round.notes`。
|
|
||||||
2. **集成验证**
|
|
||||||
- 在回测环境构造冲突样例，验证“冲突→风险建议→执行调整”链路。
|
|
||||||
- 新增测试：模拟停牌、仓位超限、黑名单事件，确认风险代理逻辑。
|
|
||||||
3. **实盘准备**
|
|
||||||
- 接入实时告警渠道（如风控系统/合规接口）。
|
|
||||||
- 监控接入：统计复核频率、回滚动作、失败告警。
|
|
||||||
4. **上线迭代**
|
|
||||||
- 影子运行记录风险建议与实际执行差异。
|
|
||||||
- 评估模型表现，迭代规则或引入强化学习风险控制策略。
|
|
||||||
|
|
||||||
## 未决事项
|
|
||||||
- 风险代理与执行模块的数据同步接口（数据库/消息队列）。
|
|
||||||
- 与合规团队确认风险阈值与回滚条件。
|
|
||||||
- 定义UI展示：风险回合的建议、证据引用、执行结果。
|
|
||||||
|
|||||||
174
docs/TODO.md
174
docs/TODO.md
@ -1,120 +1,82 @@
|
|||||||
# 记住，我们在开发可实战的投资助理工具，其业务水平要处在投资的前列。不要单纯只实现些简单的功能
|
# 项目工作总览
|
||||||
|
|
||||||
|
> 汇总全局工作项，统一标记完成情况，避免重复维护；如需细化请在同一条目下更新备注。状态含义：✅ 已完成｜🔄 进行中｜⏳ 待启动。
|
||||||
|
|
||||||
|
## 数据与特征
|
||||||
|
|
||||||
# 项目待办清单
|
| 工作项 | 状态 | 说明 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 因子计算流水线 | 🔄 | `compute_factors()` 及持久化流程已可用，仍需支持增量模式与公式复核。 |
|
||||||
|
| DataBroker 弹性 | 🔄 | 自动重试、健康监控已接入；数据质量评分体系待设计。 |
|
||||||
|
| 因子库扩展 | 🔄 | 动量/估值/流动性/情绪因子已上线；权重优化与组合评估待补。 |
|
||||||
|
| 新闻数据接入 | 🔄 | RSS 解析与情感分析可用；实体识别与时效评分仍缺。 |
|
||||||
|
| 数据完整性体系 | ⏳ | 需建立巡检脚本、异常告警与补数流程。 |
|
||||||
|
| 选股使用预计算因子 | ⏳ | 调整选股流程以直接消费持久化因子，避免重复计算。 |
|
||||||
|
| 因子公式复核 | ⏳ | 梳理现有公式、补充可视化验证与文档沉淀。 |
|
||||||
|
|
||||||
> 用于跟踪现阶段尚未完成或需要后续完善的工作，便于规划优先级。
|
## 决策优化与强化学习
|
||||||
|
|
||||||
## 1. UI 与日志增强
|
| 工作项 | 状态 | 说明 |
|
||||||
- 今日计划页增加“一键重评估”入口，以及日志钻取 / 历史对比视图（对齐 README 中的架构目标）。
|
| --- | --- | --- |
|
||||||
- 回测页面支持多版本实验管理（对比不同提示/温度的收益曲线），与 `tuning_results` 记录联动。
|
| DecisionEnv 扩展 | 🔄 | 已支持多步 episode 与部分动作维度，需继续覆盖提示版本、function 策略等。 |
|
||||||
- Streamlit 聚焦监控场景，补充实时指标面板、异常日志钻取与“仅监控不干预”模式的一键复评策略。
|
| 强化学习基线 | ✅ | PPO/SAC 等连续动作算法已接入并形成实验基线。 |
|
||||||
|
| 奖励与评估体系 | ⏳ | 需将 `portfolio_trades`/`portfolio_snapshots` 等指标纳入奖励与评估。 |
|
||||||
|
| 实时持仓链路 | ⏳ | 建立线上持仓/成交写入与离线调参与监控共享的数据源。 |
|
||||||
|
| 全局参数搜索 | ⏳ | 引入 Bandit、贝叶斯优化或 BOHB 提供权重/参数候选。 |
|
||||||
|
|
||||||
## 2. 数据与特征层
|
## 多智能体协同与 LLM
|
||||||
- 实现 `app/features/factors.py` 中的 `compute_factors()`，补齐因子计算与持久化流程。
|
|
||||||
- 完成 `app/ingest/rss.py` 的 RSS 拉取与写库逻辑，打通新闻与情绪数据源。
|
|
||||||
- 强化 `DataBroker` 的取数校验、缓存与回退策略，确保行情/特征补数统一自动化，减少人工兜底。
|
|
||||||
- 围绕动量、估值、流动性等核心信号扩展轻量高质量因子集，全部由程序生成，满足端到端自动决策需求。
|
|
||||||
|
|
||||||
## 3. 决策优化与强化学习
|
| 工作项 | 状态 | 说明 |
|
||||||
- ✅ 扩展 `DecisionEnv` 的动作空间（提示版本、部门温度、function 调用策略等），不仅限于代理权重调节。
|
| --- | --- | --- |
|
||||||
- 引入 Bandit / 贝叶斯优化或 RL 算法探索动作空间，并将 `portfolio_snapshots`、`portfolio_trades` 指标纳入奖励约束。
|
| Provider 与 function 架构 | ✅ | Provider 管理、function-calling 降级与重试策略已收敛。 |
|
||||||
- 将 `DecisionEnv` 改造为多步 episode，逐日输出状态（行情特征、持仓、风险事件）与动作，充分利用历史序列训练强化学习策略。
|
| 提示模板治理 | ⏳ | 待建立模板版本管理、成本监控与性能指标。 |
|
||||||
- ✅ 基于多步环境接入 PPO / SAC 等连续动作算法，结合收益、回撤、成交成本设定奖励与约束，提升收益最大化的稳定性。
|
| 部门遥测可视化 | ⏳ | `_telemetry` / `_department_telemetry` 字段需在 UI 中完整展示。 |
|
||||||
- 在整段回测层面引入并行贝叶斯优化（TPE/BOHB）或其他全局搜索，为强化学习提供高收益初始权重与参数候选。
|
| 多轮逻辑博弈框架 | ⏳ | 需实现主持/预测/风险/执行分轮对话、信念修正与冲突解决。 |
|
||||||
- 建立离线验证与滚动前向测试流程，对新策略做回测 vs. 实盘对照，防止收益最大化策略过拟合历史数据。
|
| LLM 稳定性提升 | ⏳ | 持续优化限速、降级、成本控制与缓存策略。 |
|
||||||
- 构建实时持仓/成交数据写入链路，使线上监控与离线调参共用同一数据源。
|
|
||||||
- 借鉴 TradingAgents-CN 的做法：拆分环境与策略、提供训练脚本/配置，并输出丰富的评估指标（如 Sharpe、Sortino、基准对比）。
|
|
||||||
- 完善 `BacktestEngine` 的成交撮合、风险阈值与指标输出，让回测信号直接对接执行端，形成无人值守的自动闭环。
|
|
||||||
- 新增多智能体多轮逻辑博弈线路：把投资场景建成重复博弈，设定主持、预测、风险等角色分轮交换信号、提出假设、相互反驳，再由执行代理落地操作；通过信念修正规则与合规约束驱动策略共识，而非依赖优化搜索。
|
|
||||||
|
|
||||||
### 3.2 多智能体多轮逻辑博弈实施方案
|
## UI 与监控
|
||||||
1. 角色与知识库建模
|
|
||||||
- 定义主持（议程控制）、预测（市场观点）、风险（合规阈值）、执行（指令生成）等核心代理，并划分共享/私有信息。
|
|
||||||
- 为每个代理建立信号源与知识库接口（行情、新闻、风险限额），设计可信度权重与更新频率。
|
|
||||||
- 预设重复博弈、信号博弈、贝叶斯博弈等多种结构模板，支持根据市场场景切换或组合，保障架构拓展性。
|
|
||||||
2. 对话协议与消息格式
|
|
||||||
- 设计多轮流程：议程发布→观点陈述→证据提交→反驳与驳回→共识决议→执行提示。
|
|
||||||
- 约定消息 schema（动作类型、置信度、引用证据）及主持代理的轮次控制逻辑，确保所有代理均可追踪历史发言。
|
|
||||||
3. 信念修正与逻辑推理引擎
|
|
||||||
- 实现迭代信念修正模块，结合可信度权重与显式逻辑规则更新各代理的市场信念。
|
|
||||||
- 引入论证框架（Argumentation Framework）或模态逻辑规则库，支持观点检验、冲突解决与风险约束自动否决。
|
|
||||||
4. 模拟与测试环境
|
|
||||||
- 搭建历史回测驱动的多轮博弈仿真环境，让代理在真实行情序列上互动。
|
|
||||||
- 编写回放脚本记录每轮对话、信念轨迹与最终行动，产出可视化报告用于策略审查。
|
|
||||||
5. 执行映射与风控集成
|
|
||||||
- 将共识决议映射到具体操作（换仓、对冲、仓位调节），并与 `BacktestEngine`/实盘执行接口打通。
|
|
||||||
- 风险代理负责实时校验 VaR、仓位集中度等阈值，违规时触发主持代理重新议程或引入驳回指令。
|
|
||||||
6. 监控与评估指标
|
|
||||||
- 设计协作质量指标（轮次收敛时间、冲突率、执行合规度）和业绩指标（收益、回撤、超额收益稳定性）。
|
|
||||||
- 将指标纳入监控面板，与现有回测、实盘监控体系统一展示。
|
|
||||||
7. 增量迭代计划
|
|
||||||
- 从线下模块联调 → 回测闭环 → 影子运行 → 小资金试点的节奏推进，每阶段设定成功退出标准。
|
|
||||||
- 收集各阶段的失败案例与风险事件，迭代规则库、信念修正规则与角色职责。
|
|
||||||
|
|
||||||
### 3.3 代码改造计划（多轮博弈适配）
|
| 工作项 | 状态 | 说明 |
|
||||||
1. 架构基线评估
|
| --- | --- | --- |
|
||||||
- ✅ 绘制代理/部门/回测调用图并补充日志字段（见 docs/architecture_call_graph.md）。
|
| 一键重评估入口 | ⏳ | 今日计划页需支持重新触发评估流程。 |
|
||||||
- ✅ 定义多轮博弈上下文结构（消息历史、信念状态、引用证据），输出数据类与通信协议草稿。
|
| 回测实验对比 | ⏳ | 提供提示/温度多版本实验管理与曲线对比。 |
|
||||||
- ✅ 在 `app/agents/protocols.py` 基础上补充主持/执行状态管理，实现 `DialogueTrace` 与部门上下文的对接路径。
|
| 实时指标面板 | ✅ | Streamlit 监控页已具备核心实时指标。 |
|
||||||
- ✅ 扩展 `Decision.rounds` 与 `RoundSummary` 采集策略，用于串联部门结论与多轮议程结果。
|
| 异常日志钻取 | ⏳ | 待补充筛选、定位与历史对比能力。 |
|
||||||
- ✅ 基于 `ProtocolHost` 设计主持驱动的议程模板，明确多结构策略扩展方式。
|
| 仅监控模式 | ⏳ | 支持“监控不干预”场景的一键复评策略。 |
|
||||||
- ✅ 扩展主持对风险复核、执行总结等议程的支持，规划风控代理与回滚逻辑。
|
| 风险预警面板 | ✅ | 风险预警能力已落地，仍需持续扩充指标。 |
|
||||||
- ✅ 落地风险议程触发条件（冲突阈值、风控代理信号、外部警报），同步更新回测策略。
|
|
||||||
- ✅ 结合 `docs/RISK_AGENT_PLAN.md` 明确 RiskAgent 升级里程碑、数据接口及前端展示需求。
|
|
||||||
- ✅ 定义 `risk_assessment` 数据结构（状态、原因、建议动作），在决策输出与存储层保持一致。
|
|
||||||
- ✅ 将风险建议与执行回合对齐，执行阶段识别 `risk_adjusted` 并记录原始动作。
|
|
||||||
2. 数据与因子重构
|
|
||||||
- ✅ 拆分 `DataBroker` 查询层（`BrokerQueryEngine`），补数逻辑独立于查询管道。
|
|
||||||
- ⏳ 按主题拆分因子模块，存储缺口/异常标签。
|
|
||||||
- ✅ `load_market_data()` 标注缺失字段并写入原始日志（`missing_fields`、`derived_fields`）。
|
|
||||||
- ✅ 维护博弈结构 → 数据 scope 映射（`app/agents/scopes.py`，`BacktestEngine.required_fields`）。
|
|
||||||
- ✅ 基于 `_RefreshCoordinator` 落地刷新队列与监控事件，拆分查询与补数路径。
|
|
||||||
- ✅ 暴露 `DataBroker.register_refresh_callback()` 钩子，结合监控系统记录补数进度与失败重试。
|
|
||||||
- ⏳ 统一补数回调日志格式（`LOG_EXTRA.stage=data_broker`），为后续指标预留数据源。
|
|
||||||
3. 多轮博弈框架
|
|
||||||
- ✅ 在 `app/agents/game.py` 抽象 `GameProtocol` 接口，扩展 `Decision` 记录多轮对话。
|
|
||||||
- ✅ 实现主持调度器驱动议程（信息→陈述→反驳→共识→执行），挂载风险复核机制。
|
|
||||||
- ✅ 引入基础信念修正规则（`app/agents/beliefs.py`），汇总信念并记录冲突。
|
|
||||||
4. 执行与回测集成
|
|
||||||
- ✅ 将回测循环改造成“每日多轮→执行摘要”，完成风控校验与冲突重议流程。
|
|
||||||
- ⏳ 擦合订单映射层，明确多轮结果对应目标仓位、执行节奏、异常回滚策略。
|
|
||||||
- ✅ 回测执行根据 `risk_assessment` 调整动作与目标权重，记录执行状态。
|
|
||||||
5. 监控与可视化
|
|
||||||
- ⏳ 在数据库/UI 增补轮次日志、信念轨迹、冲突原因与执行结果的可视化。
|
|
||||||
- ⏳ 定义多结构绩效指标并纳入监控面板（回测视图已提供风险事件统计与分布图）。
|
|
||||||
- ⏳ 补充补数回调监控告警策略（成功率、排队时长、重试次数）。
|
|
||||||
- ✅ 回测视图展示 `_risk_assessment` 与 `execution_status`，后续扩展到实时监控面板。
|
|
||||||
- ⏳ 完善风险告警（`alerts.backtest_risk`）阈值与通知策略并扩展至实盘。
|
|
||||||
6. 测试与迭代治理
|
|
||||||
- ⏳ 构建历史行情驱动的多轮仿真回放，覆盖结构切换与异常场景。
|
|
||||||
- 新增单元/集成测试：议程流程、信念修正、补数竞态、执行映射。
|
|
||||||
- ✅ 风险执行集成测试完成（`tests/test_decision_risk_integration.py`），验证风险调节与执行日志。
|
|
||||||
- 规划上线节奏：线下 PoC → 回测闭环 → 影子运行 → 小资金试点，记录失败案例反馈改进。
|
|
||||||
- 在测试计划中涵盖风险/执行议程的触发条件与回滚路径，确保主持扩展的行为可验证。
|
|
||||||
- 新增针对风险复核和执行议程的集成测试场景，覆盖“冲突→复核→执行/回滚”链路。
|
|
||||||
- 对照 `docs/RISK_AGENT_PLAN.md` 拆解阶段性验收项：数据校验、监控指标、影子运行报告。
|
|
||||||
- 为 `risk_assessment` 输出设计单元测试（冲突触发、无冲突、外部告警模拟），确保状态与原因正确覆盖。
|
|
||||||
- 编写执行阶段测试，验证 `risk_adjusted` 状态下的目标仓位与日志记录。
|
|
||||||
|
|
||||||
### 3.1 实施步骤（建议顺序）
|
## 风险控制与执行
|
||||||
1. 环境重构：扩展 `DecisionEnv` 支持逐日状态/动作/奖励，完善 `BacktestEngine` 的状态保存与恢复接口，并补充必要的数据库读写钩子。
|
|
||||||
2. 训练基线：实现基于多步环境的 PPO（或 SAC）训练脚本，定义网络结构、奖励项（收益/回撤/成交成本）和超参，先在小规模标的上验证收敛。
|
|
||||||
3. 全局搜索：在整段回测模式下并行运行 TPE/BOHB 等贝叶斯优化，产出高收益参数作为 RL 的初始化权重或候选策略。
|
|
||||||
4. 验证闭环：搭建滚动前向测试流水线，自动记录训练策略的回测表现与准实时对照，接入监控面板并输出风险/收益指标。
|
|
||||||
5. 上线准备：结合实时持仓/成交链路，完善回滚与安全阈值机制，准备 A/B 或影子跟投实验，确认收益最大化策略的稳健性。
|
|
||||||
|
|
||||||
## 4. 测试与验证
|
| 工作项 | 状态 | 说明 |
|
||||||
- 补充部门上下文构造、多模型调用、回测指标生成等核心路径的单元 / 集成测试。
|
| --- | --- | --- |
|
||||||
- 建立决策流程的回归测试用例，确保提示模板或配置调整后行为可复现。
|
| 风险代理决策闭环 | ✅ | `risk_round` 可调整决策并写入 `risk_assessment`。 |
|
||||||
- 编写示例 Notebook / end-to-end 教程，参照 TradingAgents-CN 的教学方式，覆盖“数据→回测→调参→评估”全流程。
|
| 风险事件持久化 | 🔄 | 风险建议已写入决策结构，待落库至 `risk_events` 并完善 UI 呈现。 |
|
||||||
- 针对数据摄取、策略主干与回测指标建立自动化验证管线，作为无人干预运行的质量护栏。
|
| 实时告警接入 | ⏳ | 需对接外部告警渠道，支撑影子运行与上线验证。 |
|
||||||
|
| 风险场景测试 | ⏳ | 补充停牌、仓位超限、黑名单等自动化测试样例。 |
|
||||||
|
|
||||||
## 5. 文档同步
|
## 测试与质量保障
|
||||||
- 随功能推进，更新 README 与讨论文档，确保描述与实际实现保持一致。
|
|
||||||
|
|
||||||
## 6. LLM 协同与配置
|
| 工作项 | 状态 | 说明 |
|
||||||
- 精简 Provider 列表、强化 function-calling 架构，完善降级和重试策略，并用配置化的角色提示与数据 Scope 提高模型行为可控性。
|
| --- | --- | --- |
|
||||||
|
| 单元/集成测试覆盖 | ⏳ | 补充部门上下文、LLM 调用、回测指标等核心路径测试。 |
|
||||||
|
| 决策流程回归集 | ⏳ | 建立提示模板调整后的回归用例，确保行为可复现。 |
|
||||||
|
| 数据质量验证 | ⏳ | 针对 ingest、特征写库建立自动化验证管线。 |
|
||||||
|
| 教程与示例 | ⏳ | 编写 Notebook 或 End-to-End 教程覆盖“数据→回测→调参→评估”。 |
|
||||||
|
| 日志收集机制 | ⏳ | 完善日志聚合与查询工具，支撑问题定位。 |
|
||||||
|
|
||||||
（最后更新：2025-09-29）
|
## 文档与知识库
|
||||||
|
|
||||||
|
| 工作项 | 状态 | 说明 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| README 对外化 | 🔄 | 重写支持快速了解定位、功能、部署方式（本轮更新进行中）。 |
|
||||||
|
| 原理文档分册 | 🔄 | 多智能体、强化学习调参、风险控制等原理文档按专题拆分。 |
|
||||||
|
| 业务流程手册 | ⏳ | 梳理投研/交易流程，评估代码实现是否吻合业务需求。 |
|
||||||
|
| 文档同步机制 | ⏳ | 建立功能迭代后的文档更新流程与责任人。 |
|
||||||
|
|
||||||
|
## 架构与代码整洁
|
||||||
|
|
||||||
|
| 工作项 | 状态 | 说明 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 全量代码审查 | ⏳ | 自 `app/ui/streamlit_app.py` 起逐模块审查，剔除重复安全检查与临时代码。 |
|
||||||
|
| TODO 标记治理 | ⏳ | 为未实现功能补充 TODO 与实现思路，并清理过期逻辑。 |
|
||||||
|
| 业务逻辑体检 | ⏳ | 梳理业务链路，识别需要重构或优化的模块。 |
|
||||||
|
|||||||
@ -1,98 +1,3 @@
|
|||||||
# 多智能体个人投资助理项目待开发与待优化项
|
# 统一待办已迁移
|
||||||
|
|
||||||
基于对项目代码库和文档的分析，现将项目中的待开发、待优化项整理如下：
|
项目的待开发与优化项已合并至 `docs/TODO.md`，该文档是当前唯一的工作项来源。请在更新计划时直接维护该文件。
|
||||||
|
|
||||||
## 1. UI 与日志增强
|
|
||||||
- **今日计划页**：增加"一键重评估"入口，以及日志钻取/历史对比视图
|
|
||||||
- **回测页面**：支持多版本实验管理，可对比不同提示/温度的收益曲线，与`tuning_results`记录联动
|
|
||||||
- **Streamlit界面优化**：补充实时指标面板、异常日志钻取与"仅监控不干预"模式的一键复评策略
|
|
||||||
- **部门意见详情页**：展示已添加的`_telemetry`与`_department_telemetry`JSON字段信息
|
|
||||||
|
|
||||||
## 2. 数据与特征层
|
|
||||||
- **因子计算模块完善**：`app/features/factors.py`中的`compute_factors()`函数需要进一步优化因子计算与持久化流程
|
|
||||||
- **新闻数据源打通**：完成`app/ingest/rss.py`的RSS拉取与写库逻辑，强化新闻与情绪数据处理
|
|
||||||
- **DataBroker增强**：强化取数校验、缓存与回退策略，确保行情/特征补数统一自动化，减少人工兜底
|
|
||||||
- **因子集扩展**：围绕动量、估值、流动性等核心信号扩展轻量高质量因子集，全部由程序生成，满足端到端自动决策需求
|
|
||||||
|
|
||||||
## 3. 决策优化与强化学习
|
|
||||||
- **动作空间扩展**：扩展`DecisionEnv`的动作空间，包括提示版本、部门温度、function调用策略等
|
|
||||||
- **强化学习算法集成**：引入Bandit/贝叶斯优化或RL算法探索动作空间，并将`portfolio_snapshots`、`portfolio_trades`指标纳入奖励约束
|
|
||||||
- **实时数据链路构建**：构建实时持仓/成交数据写入链路，使线上监控与离线调参共用同一数据源
|
|
||||||
- **环境与策略拆分**：借鉴TradingAgents-CN的做法，拆分环境与策略、提供训练脚本/配置，并输出丰富的评估指标
|
|
||||||
- **回测引擎完善**：完善`BacktestEngine`的成交撮合、风险阈值与指标输出，让回测信号直接对接执行端
|
|
||||||
|
|
||||||
## 4. 测试与验证
|
|
||||||
- **测试覆盖率提升**：补充部门上下文构造、多模型调用、回测指标生成等核心路径的单元/集成测试
|
|
||||||
- **回归测试用例**：建立决策流程的回归测试用例，确保提示模板或配置调整后行为可复现
|
|
||||||
- **教程与示例**：编写示例Notebook/end-to-end教程，覆盖"数据→回测→调参→评估"全流程
|
|
||||||
- **自动化验证管线**：针对数据摄取、策略主干与回测指标建立自动化验证管线
|
|
||||||
|
|
||||||
## 5. 文档同步
|
|
||||||
- 随功能推进，更新README与讨论文档，确保描述与实际实现保持一致
|
|
||||||
|
|
||||||
## 6. LLM协同与配置
|
|
||||||
- **Provider优化**：精简Provider列表，强化function-calling架构，完善降级和重试策略
|
|
||||||
- **提示工程**：用配置化的角色提示与数据Scope提高模型行为可控性
|
|
||||||
- **日志增强**：增强日志功能，记录完整的提示参数与决策结果，便于分析
|
|
||||||
|
|
||||||
## 7. 风险闭环强化
|
|
||||||
- 回测引擎中调整撮合逻辑，统一考虑仓位上限、换手约束、滑点与手续费
|
|
||||||
- 完善`bt_risk_events`表及落库链路，回测报告输出风险事件统计
|
|
||||||
- `DecisionEnv`的Episode观测新增换手、风险事件等字段，默认奖励将回撤、风险与换手纳入惩罚项
|
|
||||||
|
|
||||||
## 8. 其他优化点
|
|
||||||
- **模型调用稳定性**：完善LLM调用的错误处理和重试机制
|
|
||||||
- **响应速度优化**：优化数据查询和计算逻辑，提高系统整体响应速度
|
|
||||||
- **配置管理优化**：优化配置存储和加载机制，支持更灵活的配置管理
|
|
||||||
|
|
||||||
这些待开发和待优化项涵盖了系统的各个层面，从前端UI到后端数据处理，从策略优化到测试验证，可以根据项目优先级和资源情况逐步实施。
|
|
||||||
|
|
||||||
## 9. 数据与特征层具体优化建议
|
|
||||||
根据系统现状分析，以下是数据与特征层的详细优化建议及实施优先级：
|
|
||||||
|
|
||||||
### 优先级一：因子计算模块优化
|
|
||||||
- **现有问题**：当前`factors.py`中的`compute_factors()`函数在计算过程中缺少足够的错误处理和边界条件检查
|
|
||||||
- **优化方向**：
|
|
||||||
- 添加因子计算过程中的数据有效性校验机制
|
|
||||||
- 实现因子值的异常值检测与处理逻辑
|
|
||||||
- 增加计算进度显示和日志记录
|
|
||||||
- 优化`_persist_factor_rows`函数的批处理性能
|
|
||||||
- **预期收益**：提高因子计算的准确性和稳定性，减少因数据质量问题导致的决策偏差
|
|
||||||
|
|
||||||
### 优先级二：DataBroker数据访问层增强
|
|
||||||
- **现有问题**：`data_access.py`中的DataBroker类在数据获取失败时缺乏有效回退机制
|
|
||||||
- **优化方向**：
|
|
||||||
- 实现多级缓存策略，减少重复数据请求
|
|
||||||
- 开发数据请求失败的自动重试机制
|
|
||||||
- 增加数据源健康状态监控
|
|
||||||
- 设计数据质量评估指标
|
|
||||||
- **预期收益**：提高数据获取的稳定性和效率，增强系统对数据源波动的适应能力
|
|
||||||
|
|
||||||
### 优先级三：新闻数据源接入完善
|
|
||||||
- **现有问题**：`rss.py`中的新闻处理逻辑较为简单，情感分析和实体提取能力有限
|
|
||||||
- **优化方向**：
|
|
||||||
- 扩展支持的RSS源数量和类型
|
|
||||||
- 增强情感分析模型，提高情绪识别准确率
|
|
||||||
- 改进实体提取算法，更准确地识别新闻中的股票代码
|
|
||||||
- 实现新闻时效性评分机制
|
|
||||||
- **预期收益**：提升新闻数据对投资决策的参考价值，丰富决策依据
|
|
||||||
|
|
||||||
### 优先级四：数据完整性检查体系
|
|
||||||
- **现有问题**：缺乏系统性的数据完整性检查机制
|
|
||||||
- **优化方向**：
|
|
||||||
- 建立数据完整性规则和指标体系
|
|
||||||
- 开发定时执行的数据质量检查脚本
|
|
||||||
- 实现异常数据的自动告警机制
|
|
||||||
- 设计数据补全和修复流程
|
|
||||||
- **预期收益**：确保数据质量，减少因数据问题导致的决策错误
|
|
||||||
|
|
||||||
### 优先级五：因子库扩展
|
|
||||||
- **现有问题**：当前`DEFAULT_FACTORS`列表中的因子类型相对有限
|
|
||||||
- **优化方向**：
|
|
||||||
- 研究并实现更多高质量的技术因子
|
|
||||||
- 开发基本面因子计算逻辑
|
|
||||||
- 设计因子组合和因子权重优化算法
|
|
||||||
- 建立因子绩效评估框架
|
|
||||||
- **预期收益**：丰富决策模型的输入特征，提高投资决策的准确性和多样性
|
|
||||||
|
|
||||||
这些具体的优化建议可以作为项目团队在推进数据与特征层优化工作时的详细指导，按照优先级顺序逐步实施，将有助于系统性地提升系统的数据处理能力和决策支持水平。
|
|
||||||
|
|||||||
@ -1,113 +1,3 @@
|
|||||||
# LLM量化交易助理系统开发计划
|
# 统一待办已迁移
|
||||||
|
|
||||||
> 项目愿景：开发一个可实战的投资助理工具，其业务水平要处在投资的前列。核心是通过多智能体协作提供高质量的投资决策支持。
|
所有工作计划与进度跟踪已整合至 `docs/TODO.md`。请将新的优先级和状态更新集中维护在该文件，避免重复记录。
|
||||||
|
|
||||||
> 开发进度（2025-10-05）：
|
|
||||||
> ✓ 基础因子计算框架
|
|
||||||
> ✓ 数据访问与监控
|
|
||||||
> ✓ 核心回测系统
|
|
||||||
> ✓ LLM基础集成
|
|
||||||
> ✓ LLM模板与上下文管理
|
|
||||||
> △ RSS新闻处理
|
|
||||||
> △ UI与监控系统
|
|
||||||
|
|
||||||
## 一、核心功能模块优先级排序
|
|
||||||
|
|
||||||
### 1. 数据与特征层（P0）
|
|
||||||
#### 1.1 因子计算模块优化
|
|
||||||
- [x] 完善 `compute_factors()` 函数实现：
|
|
||||||
- [x] 添加数据有效性校验机制
|
|
||||||
- [x] 实现异常值检测与处理逻辑
|
|
||||||
- [x] 增加计算进度显示和日志记录
|
|
||||||
- [x] 优化因子持久化性能
|
|
||||||
- [ ] 支持增量计算模式
|
|
||||||
|
|
||||||
#### 1.2 DataBroker增强
|
|
||||||
- [x] 开发数据请求失败的自动重试机制
|
|
||||||
- [x] 增加数据源健康状态监控
|
|
||||||
- [ ] 设计数据质量评估指标系统
|
|
||||||
|
|
||||||
#### 1.3 因子库扩展
|
|
||||||
- [x] 扩展动量类因子群
|
|
||||||
- [x] 开发估值类因子群
|
|
||||||
- [x] 设计流动性因子群
|
|
||||||
- [x] 构建市场情绪因子群
|
|
||||||
- [ ] 开发因子组合和权重优化算法
|
|
||||||
|
|
||||||
#### 1.4 新闻数据源完善
|
|
||||||
- [x] 完成RSS数据获取和解析
|
|
||||||
- [x] 增强情感分析能力
|
|
||||||
- [ ] 改进实体识别准确率
|
|
||||||
- [ ] 实现新闻时效性评分
|
|
||||||
|
|
||||||
### 2. 决策优化（P1）
|
|
||||||
#### 2.1 决策环境增强
|
|
||||||
- [x] 扩展DecisionEnv动作空间：
|
|
||||||
- [x] 支持提示版本选择
|
|
||||||
- [x] 允许调节部门温度
|
|
||||||
- [ ] 优化function调用策略
|
|
||||||
- [x] 增加环境观测维度：
|
|
||||||
- [x] 加入换手率指标
|
|
||||||
- [x] 纳入风险事件统计
|
|
||||||
- [ ] 补充市场情绪指标
|
|
||||||
|
|
||||||
#### 2.2 回测系统完善
|
|
||||||
- [x] 优化成交撮合逻辑：
|
|
||||||
- [x] 统一仓位限制
|
|
||||||
- [x] 考虑换手约束
|
|
||||||
- [x] 加入滑点模拟
|
|
||||||
- [x] 计算交易成本
|
|
||||||
- [x] 完善风险控制：
|
|
||||||
- [x] 实现止损机制
|
|
||||||
- [x] 添加波动率限制
|
|
||||||
- [x] 设置集中度控制
|
|
||||||
|
|
||||||
### 3. LLM协同（P1）
|
|
||||||
- [x] 精简和优化Provider管理
|
|
||||||
- [x] 增强function-calling架构
|
|
||||||
- [x] 完善错误处理和重试策略
|
|
||||||
- [x] 优化提示工程：
|
|
||||||
- [x] 设计配置化角色提示
|
|
||||||
- [x] 优化数据范围控制
|
|
||||||
- [x] 改进上下文管理
|
|
||||||
- [ ] 增强系统稳定性：
|
|
||||||
- [ ] 实现提示模板版本管理
|
|
||||||
- [ ] 增加系统级性能监控
|
|
||||||
- [ ] 优化模型调用成本控制
|
|
||||||
|
|
||||||
### 4. UI与监控（P2）
|
|
||||||
#### 4.1 功能增强
|
|
||||||
- [ ] 实现"一键重评估"功能
|
|
||||||
- [ ] 开发多版本实验对比
|
|
||||||
- [x] 添加实时指标面板
|
|
||||||
- [ ] 设计异常日志钻取功能
|
|
||||||
|
|
||||||
#### 4.2 监控增强
|
|
||||||
- [ ] 开发"仅监控不干预"模式
|
|
||||||
- [x] 实现策略实时评估
|
|
||||||
- [x] 添加风险预警功能
|
|
||||||
- [ ] 设计绩效归因分析
|
|
||||||
|
|
||||||
### 5. 测试与部署（P2）
|
|
||||||
- [x] 补充核心路径单元测试
|
|
||||||
- [ ] 建立端到端集成测试
|
|
||||||
- [ ] 完善日志收集机制
|
|
||||||
|
|
||||||
## 二、近期开发重点（2025 Q4）
|
|
||||||
|
|
||||||
1. ✓ 完成因子计算模块的优化和重构
|
|
||||||
2. ✓ 实现基础因子库的扩展
|
|
||||||
3. ✓ 优化DataBroker的数据访问性能
|
|
||||||
4. △ 完善RSS新闻数据源的接入
|
|
||||||
5. ✓ 开始着手决策环境的增强
|
|
||||||
6. ✓ 改进LLM模板与上下文管理
|
|
||||||
7. △ 启动LLM性能与成本优化
|
|
||||||
|
|
||||||
## 三、开发原则
|
|
||||||
|
|
||||||
1. 保持简单：每个模块只实现最核心的功能
|
|
||||||
2. 重视可靠性：核心功能必须稳定可靠
|
|
||||||
3. 易于使用：交互界面简单直观
|
|
||||||
4. 容错设计：关键节点预留人工介入的可能
|
|
||||||
|
|
||||||
> 注：此计划将根据实际使用体验持续优化，始终保持简单实用的原则。上次更新：2025-10-05
|
|
||||||
|
|||||||
@ -1,46 +1,7 @@
|
|||||||
# 决策优化讨论记录
|
# 决策优化讨论记录（已归档）
|
||||||
|
|
||||||
## 核心目标
|
原始的强化学习与决策优化笔记已整理为专题文档，详见：
|
||||||
- 在 `app/agents` 现有规则型与部门 LLM 协同框架上，定义“收益最大化 + 风险约束”的统一指标，用于评估提示词、温度、多智能体博弈和调用策略的优劣。
|
|
||||||
- 借助 `app/backtest/engine.py` 的日频回测环境，构建可重复的仿真闭环，为强化学习或策略搜索提供离线训练与验证数据。
|
|
||||||
- 通过优化高层策略（Prompt 模板、对话轮次、function 调用模式），而不是直接干预底层行情预测，使 RL 学习关注“决策流程调度”。
|
|
||||||
|
|
||||||
## 关键挑战
|
- `docs/principles/reinforcement_learning_tuning.md`
|
||||||
- 状态空间：每轮博弈涉及市场因子、代理信号、历史行为与日志状态（`app/data/logs`）；需压缩为 RL 训练可用的紧凑向量或摘要。
|
|
||||||
- 奖励设计：直接使用策略收益会导致梯度稀疏，可考虑收益、回撤、成交约束、信心一致性等多目标加权。
|
|
||||||
- 数据效率：真实交易可探索次数有限，必须依赖离线仿真 + 反事实评估，或引入模型驱动的世界模型缓解分布偏移。
|
|
||||||
- 多智能体非定常性：规则代理 + LLM 的组合策略随参数调整而漂移，需要稳定 Nash 聚合或引入对手建模。
|
|
||||||
|
|
||||||
## 建议路径
|
如需更新相关内容，请直接维护上述原理文档，此文件仅保留以兼容历史链接。
|
||||||
- **数据记录**：扩展 `app/agent_utils` 写入 Prompt 版本、温度、function 调用次数、部门信号等元数据，形成 RL 可用轨迹；同时让日志文件（如 `app/data/logs/agent_20250929_0754.log`）对齐这些字段。
|
|
||||||
- **环境封装**：在 `app/backtest/engine.py` 外层定义 `DecisionEnv`，让“动作”映射到策略配置（Prompt 选择、温度、投票权重），`step()` 调用现有引擎完成一日博弈并返回奖励。
|
|
||||||
- **层级策略**：先做 Bandit 或 CMA-ES 等黑箱优化调参（温度、权重）建立基线，再过渡到 PPO/SAC 等连续动作 RL；提示词可以编码成可学习 embedding 或有限候选集合。
|
|
||||||
- **博弈协同**：针对部门间权重、否决策略，引入 centralized training, decentralized execution (CTDE) 思路，共享一个 critic 评估全局奖励，actor 负责单部门参数。
|
|
||||||
- **安全约束**：用 penalty 方法或 Lagrangian 处理仓位/风控约束，确保训练过程中遵守 `A_risk` 设定的停牌、涨跌停逻辑。
|
|
||||||
|
|
||||||
## 强化学习框架
|
|
||||||
- 状态构建：拼接市场特征（因子矩阵降维）、历史动作、日志中 LLM 置信度；必要时用 LSTM/Transformer 编码。
|
|
||||||
- 动作定义：连续动作控制 `temperature`/`top_p`/投票权重，离散动作选择 Prompt 模板/协作模式（majority vs leader）；组合动作可分解成参数化策略。
|
|
||||||
- 奖励函数：`收益净值提升 - λ1*回撤 - λ2*成交成本 - λ3*冲突次数`，可把 LLM 置信度一致性或 function 调用成本作为正负项。
|
|
||||||
- 训练流程：循环“采样配置 → 回放到 BacktestEngine → 记入 Replay Buffer → 更新策略”，必要时采用离线 RL（CQL、IQL）以利用历史轨迹。
|
|
||||||
- 评估：对比默认提示/温度设定的收益分布，统计策略稳定性、反事实收益差，并在 `app/ui/streamlit_app.py` 加入实验版本切换和可视化。
|
|
||||||
|
|
||||||
## 下一步
|
|
||||||
- 先补齐日志与数据库字段，确保能完整记录提示参数与决策结果。
|
|
||||||
- 搭建轻量 Bandit 调参实验，验证不同提示与温度组合对回测收益的影响。
|
|
||||||
- 设计 RL 环境接口，与现有 BacktestEngine 集成，规划训练与评估脚本。
|
|
||||||
|
|
||||||
## 已完成的日志改进
|
|
||||||
- `agent_utils` 表新增 `_telemetry` 与 `_department_telemetry` JSON 字段（存于 `utils` 列内部），记录每个部门的 provider、模型、温度、回合数、工具调用列表与 token 统计，可在 Streamlit “部门意见”详情页展开查看。
|
|
||||||
- `app/data/logs/agent_*.log` 会追加 `telemetry` 行，保存每轮函数调用的摘要，方便离线分析提示版本与 LLM 配置对决策的影响。
|
|
||||||
- Streamlit 侧边栏监听 `llm.metrics` 的实时事件，并使用原位组件刷新“系统监控”，避免增量追加或节流导致的失效，同时确保实时数据推送稳定。
|
|
||||||
- 新增投资管理数据层：SQLite 中创建 `investment_pool`、`portfolio_positions`、`portfolio_trades`、`portfolio_snapshots` 四张表；`app/utils/portfolio.py` 提供访问接口，今日计划页可实时展示候选池、持仓与成交。
|
|
||||||
- 回测引擎 `record_agent_state()` 现同步写入 `investment_pool`，将每日全局决策的置信度、部门标签与目标权重落库，作为后续提示参数调优与候选池管理的基础数据。
|
|
||||||
- `app/backtest/decision_env.py` 引入 `DecisionEnv`，用单步 RL/Gym 风格接口封装回测：动作 → 权重映射 → 回测 → 奖励（收益 - 0.5×回撤），同时输出 NAV、交易与行动权重，方便与 Bandit/PPO 等算法对接。
|
|
||||||
- Streamlit “回测与复盘” 页新增离线调参模块，可即点即用 DecisionEnv 对代理权重进行实验，并可视化收益、回撤、成交与权重结果，支持一键写入 `config.json` 成为新的默认权重。
|
|
||||||
- 所有离线调参实验（单次/批量）都会存入 SQLite `tuning_results`，包含实验 ID、动作、奖励、指标与权重，便于后续分析与对比。
|
|
||||||
|
|
||||||
## 下一阶段路线图
|
|
||||||
- 在 `DecisionEnv` 中扩展动作映射（Prompt 版本、部门温度、function 调用策略等），把当前权重型动作升级为多参数协同调整。
|
|
||||||
- 接入 Bandit/贝叶斯优化，对动作空间进行探索，并把 `portfolio_snapshots`、`portfolio_trades` 输出纳入奖励约束（收益、回撤、换手率）。
|
|
||||||
- 构建持仓/成交写入流程的实时入口，使线上监控与离线调参共用同一数据源，支撑增量训练与策略回放。
|
|
||||||
|
|||||||
65
docs/principles/multi_agent_decision.md
Normal file
65
docs/principles/multi_agent_decision.md
Normal file
@ -0,0 +1,65 @@
|
|||||||
|
# 多智能体决策原理
|
||||||
|
|
||||||
|
本篇总结项目中多智能体博弈式决策的设计理念，覆盖角色建模、对话协议、信念修正与评估方法，为后续实现与复盘提供统一参照。
|
||||||
|
|
||||||
|
## 设计目标
|
||||||
|
|
||||||
|
- 让主持、预测、风险、执行等角色围绕相同市场场景进行多轮交互，形成可追踪的共识。
|
||||||
|
- 用可解释的数据引用和信念修正规则替代纯黑盒优化，确保决策链路可审计、可回放。
|
||||||
|
- 保持策略拓展性：能够按需引入新的部门或逻辑规则，而无需重写整体流程。
|
||||||
|
|
||||||
|
## 角色与知识建模
|
||||||
|
|
||||||
|
1. **主持（Moderator）**：负责议程控制、轮次推进、冲突降级，持有全局上下文与流程规则。
|
||||||
|
2. **预测（Forecaster）**：聚合行情、因子与新闻信号，给出趋势判断及置信度。
|
||||||
|
3. **风险（Risk）**：掌握仓位限制、合规阈值、风险事件库，可提出否决与回滚建议。
|
||||||
|
4. **执行（Execution）**：将共识映射为具体指令（调仓、对冲、风控动作），并反馈执行状态。
|
||||||
|
5. **扩展角色**：支持引入情绪、宏观、行业等专业代理，每个代理绑定专属数据域与可信度模型。
|
||||||
|
|
||||||
|
每个角色需注册：
|
||||||
|
|
||||||
|
- **信号源接口**：行情、特征、风险指标或外部知识库。
|
||||||
|
- **知识缓存**：共享信息（全体可见）与私有信息（角色独享）的区分。
|
||||||
|
- **可信度权重**：依据历史表现动态调整，参与信念融合与冲突解决。
|
||||||
|
|
||||||
|
## 多轮对话协议
|
||||||
|
|
||||||
|
1. **议程发布**：主持宣布议题、目标与约束（标的、持仓限制、复审阈值）。
|
||||||
|
2. **观点陈述**：各角色按顺序提交观点、置信度与引用证据。
|
||||||
|
3. **证据扩展**：若信息不足，可调用数据工具（如 `fetch_data`）补充证据。
|
||||||
|
4. **反驳与驳回**：角色可针对他人观点给出反驳，主持负责仲裁冲突、记录理由。
|
||||||
|
5. **风险复核**：风险代理综合内部指标与外部告警，对共识进行校验并给出限制/驳回。
|
||||||
|
6. **共识决议**：主持生成决议草案，执行代理将其转化为交易动作。
|
||||||
|
7. **执行反馈**：执行结果、风险事件与日志写入数据库，供后续回放。
|
||||||
|
|
||||||
|
消息采用结构化 Schema，至少包含：`role`、`action`、`confidence`、`evidence_refs`、`annotations`，确保 UI 与日志可追踪。
|
||||||
|
|
||||||
|
## 信念修正与推理
|
||||||
|
|
||||||
|
- **权重更新**：基于可信度、历史绩效和证据充足性调整角色影响力。
|
||||||
|
- **逻辑规则库**：引入 Argumentation Framework / 模态逻辑，对冲突观点做合法性校验。
|
||||||
|
- **风险否决**：风险节点可触发降级流程（减仓、冻结执行、重新议程）。
|
||||||
|
- **记忆管理**：保留每轮发言与修正历史，支持回放与监督学习。
|
||||||
|
|
||||||
|
## 与执行层的衔接
|
||||||
|
|
||||||
|
- 决策结果写入 `Decision.rounds`、`risk_assessment` 等结构，记录动因与建议动作。
|
||||||
|
- 执行模块需识别“冻结执行”“调仓幅度”“回滚原因”等指令，确保风险闭环。
|
||||||
|
- 多轮博弈记录同步到 UI，便于运营侧审查“提出→反驳→定案”的全过程。
|
||||||
|
|
||||||
|
## 关键指标
|
||||||
|
|
||||||
|
- **协作效率**：轮次收敛时间、冲突率、复核次数。
|
||||||
|
- **合规度**：风险否决覆盖率、违规触发率、回滚成功率。
|
||||||
|
- **业绩表现**：收益、回撤、超额收益稳定性，与默认策略对比。
|
||||||
|
- **解释追踪**：证据覆盖率、引用数据准确性、决策重放完整度。
|
||||||
|
|
||||||
|
## 迭代路线图
|
||||||
|
|
||||||
|
1. 线下 PoC：以固定历史样本验证多轮流程可行性。
|
||||||
|
2. 回测闭环：接入 BacktestEngine，对多轮策略做收益/风险对比。
|
||||||
|
3. 影子运行：实时记录建议但不执行，验证告警与回滚逻辑。
|
||||||
|
4. 小资金试点：在严格风控下上线，收集失败案例与反馈。
|
||||||
|
5. 正式上线：完善监控指标，形成常规运营与文档更新流程。
|
||||||
|
|
||||||
|
若后续扩展新的代理或推理组件，应在此文档补充角色说明与协议变更，确保团队共享统一原理。
|
||||||
46
docs/principles/reinforcement_learning_tuning.md
Normal file
46
docs/principles/reinforcement_learning_tuning.md
Normal file
@ -0,0 +1,46 @@
|
|||||||
|
# 强化学习调参与决策优化原理
|
||||||
|
|
||||||
|
本篇整理多智能体投资助理中使用强化学习与黑箱优化改进决策流程的核心思路，涵盖环境建模、动作设计、奖励函数、训练流程与评估方法。
|
||||||
|
|
||||||
|
## 总体目标
|
||||||
|
|
||||||
|
- 在既有规则型代理与部门 LLM 框架上，引入可迭代的策略搜索机制，最大化收益并控制风险。
|
||||||
|
- 通过可重复的回测闭环记录数据、提示参数与执行结果，为强化学习/贝叶斯优化提供高质量轨迹。
|
||||||
|
- 关注高层策略调度（Prompt、温度、投票权重、function 调用），而非直接预测行情，保持模型解释性。
|
||||||
|
|
||||||
|
## 环境建模
|
||||||
|
|
||||||
|
- **基础环境**：`app/backtest/engine.py` 提供日频循环，将代理决策、持仓状态与行情数据解耦。
|
||||||
|
- **DecisionEnv**：封装成 Gym 风格接口，`step()` 接受策略动作，运行回测并返回奖励与观察。
|
||||||
|
- **状态设计**：拼接市场特征、历史动作、LLM 置信度、风险事件、日志指标，可进一步用 RNN/Transformer 编码。
|
||||||
|
- **动作空间**：包含连续参数（温度、权重、阈值）与离散选择（Prompt 模板、协作模式、function 策略）；必要时拆分为多头动作向量。
|
||||||
|
|
||||||
|
## 奖励函数
|
||||||
|
|
||||||
|
- 基础指标：净值增长、最大回撤、换手率、成交成本。
|
||||||
|
- 风险约束：将仓位超限、冲突次数、风险事件纳入惩罚项，可采用拉格朗日或 penalty 方法。
|
||||||
|
- 信息一致性：对 LLM 置信度一致性、提示调用成本等补充奖励/惩罚，提高策略可解释性与效率。
|
||||||
|
|
||||||
|
## 训练策略
|
||||||
|
|
||||||
|
1. **数据记录**：在 `agent_utils`、`tuning_results` 等表中写入 Prompt 版本、温度、function 调用次数与回测指标，形成可复用轨迹。
|
||||||
|
2. **黑箱优化基线**：先用 Bandit、CMA-ES、贝叶斯优化等方法探索高价值参数区域，为 RL 提供 warm start。
|
||||||
|
3. **强化学习算法**：在多步 `DecisionEnv` 上使用 PPO/SAC/DDPG 等连续动作算法，必要时采用分层或多智能体（CTDE）训练。
|
||||||
|
4. **离线/离策略训练**：利用历史轨迹进行 CQL、IQL 等离线 RL；对分布偏移显著的场景考虑模型驱动或模拟生成数据。
|
||||||
|
5. **安全约束**：训练过程中强制执行仓位/风险限制，确保策略不会违反合规规则。
|
||||||
|
|
||||||
|
## 评估与对比
|
||||||
|
|
||||||
|
- **回测指标**：收益、回撤、夏普、Sortino、换手、成交成本、超额收益稳定性。
|
||||||
|
- **超参敏感度**：记录不同 Prompt/温度组合的表现，形成雷达图或分布可视化。
|
||||||
|
- **实验管理**：所有实验写入 `tuning_results`，支持在 UI 中按实验 ID 对比。
|
||||||
|
- **上线前验证**：离线回测 → 滚动前向测试 → 影子运行 → 小规模实盘，逐步扩大影响范围。
|
||||||
|
|
||||||
|
## 实施建议
|
||||||
|
|
||||||
|
- 先补齐日志字段和数据记录，确保每次实验可重现。
|
||||||
|
- 在单个部门或少量参数上做 PoC，验证闭环后再推广。
|
||||||
|
- 将 RL 与规则策略结合：RL 提供权重建议，规则层负责安全边界。
|
||||||
|
- 持续复盘失败案例，迭代奖励函数与状态设计。
|
||||||
|
|
||||||
|
后续如扩展新的动作维度或奖励项，请同步更新本原理文档，保持训练框架透明可追踪。
|
||||||
56
docs/principles/risk_management.md
Normal file
56
docs/principles/risk_management.md
Normal file
@ -0,0 +1,56 @@
|
|||||||
|
# 风险控制原理与风险代理设计
|
||||||
|
|
||||||
|
本文档梳理项目中的风险控制理念，覆盖风险代理的职责、数据需求、决策流程、日志策略与实施里程碑，为风控改造提供统一依据。
|
||||||
|
|
||||||
|
## 目标与定位
|
||||||
|
|
||||||
|
- 将 `RiskAgent` 从占位角色升级为具备实质决策能力的安全阀，保障所有交易建议在执行前通过风险复核。
|
||||||
|
- 提供回测与实盘一致的风险上下文，使补数、验证、告警等环节共享信息。
|
||||||
|
- 支持“风险否决 → 重新议程或减仓”的闭环，并将决策记录到数据库和可视化界面。
|
||||||
|
|
||||||
|
## 数据与信号
|
||||||
|
|
||||||
|
- **基础字段**：`risk_penalty`、`position_limit`、`is_suspended`、涨跌停状态等。
|
||||||
|
- **高级指标**：日内波动、VaR、行业集中度、黑名单或外部告警标签。
|
||||||
|
- **实时事件**：补数异常、执行失败、仓位越界等，需要通过 `DataBroker` 回调或交易执行层回传。
|
||||||
|
- **上下文结构**：在 `AgentContext.raw` 携带 `risk_flags`、`compliance_notes`，并在 UI 中展示。
|
||||||
|
|
||||||
|
## 决策流程
|
||||||
|
|
||||||
|
1. **风险评估阶段**
|
||||||
|
- 部门共识形成后触发 `risk_round`，由 `RiskAgent` 调整 `Decision.requires_review`、`target_weight` 等字段。
|
||||||
|
- 输出 `RiskAssessment` 数据（风险来源、建议动作、置信度），序列化进 `Decision.rounds`。
|
||||||
|
|
||||||
|
2. **执行协调阶段**
|
||||||
|
- 若风险建议为“冻结”或“减仓”，执行模块需遵循风险指令。
|
||||||
|
- 风险事件写入 `risk_events`（或同类表），供监控与审计使用。
|
||||||
|
|
||||||
|
3. **日志与监控**
|
||||||
|
- `risk_round` 应附加 `annotations`：违规指标、处置动作、证据引用。
|
||||||
|
- UI 与监控面板展示复核触发率、回滚成功率、风险热点等指标。
|
||||||
|
|
||||||
|
## 实施里程碑
|
||||||
|
|
||||||
|
1. **原型阶段（已完成）**
|
||||||
|
- 重构 `RiskAgent` 以返回策略建议。
|
||||||
|
- 扩展 `Decision` 结构新增 `risk_assessment`。
|
||||||
|
- `ProtocolHost` 将风险建议写入 `risk_round.notes`。
|
||||||
|
|
||||||
|
2. **集成验证（进行中）**
|
||||||
|
- 在回测环境构造停牌、仓位超限、黑名单等样例，验证闭环。
|
||||||
|
- 补充单元/集成测试覆盖典型风险场景。
|
||||||
|
|
||||||
|
3. **实盘准备（待启动）**
|
||||||
|
- 对接外部告警渠道（风控系统、合规接口等）。
|
||||||
|
- 统计复核频率、回滚动作、失败告警，形成运营指标。
|
||||||
|
|
||||||
|
4. **上线与迭代（待启动）**
|
||||||
|
- 影子运行对比建议与执行差异，收集风控策略表现。
|
||||||
|
- 依据反馈迭代规则、阈值与风险指标库。
|
||||||
|
|
||||||
|
## 后续关注
|
||||||
|
|
||||||
|
- 风险代理与执行模块的数据同步方式（数据库/消息队列）需明确。
|
||||||
|
- 与合规团队协作确定阈值、回滚条件与审核流程。
|
||||||
|
- UI 需支持展示风险建议原文、引用证据与执行结果。
|
||||||
|
- 随业务扩展及时更新本原理文档，保持风险策略可解释、可追踪。
|
||||||
Loading…
Reference in New Issue
Block a user