feat(ui): 添加AI协作页签
新增AI协作功能模块,并在主界面中添加了对应的页签。 更新了OpenBB集成文档的路径,将其从单独的Markdown文件迁移到目录结构中。 为项目添加了新的测试依赖,包括pytest相关工具、locust和memory-profiler等。
This commit is contained in:
222
docs/AI_AGENT_TASKS/CLAUDE_CODE_IMPLEMENTATION.md
Normal file
222
docs/AI_AGENT_TASKS/CLAUDE_CODE_IMPLEMENTATION.md
Normal file
@@ -0,0 +1,222 @@
|
||||
# 💻 Claude AI - OpenBB核心代码实现工作说明书
|
||||
|
||||
## 🎯 任务概述
|
||||
作为核心开发工程师,您需要基于Qwen的架构设计,实现OpenBB与稷下学宫系统的深度集成代码。
|
||||
|
||||
## 📋 核心职责
|
||||
|
||||
### 1. 核心引擎实现
|
||||
**任务目标:** 增强现有OpenBB引擎,实现八仙智能数据获取
|
||||
|
||||
**关键文件实现:**
|
||||
```
|
||||
src/jixia/engines/
|
||||
├── enhanced_openbb_engine.py # 增强版OpenBB引擎
|
||||
├── immortal_data_router.py # 八仙数据路由器
|
||||
├── intelligent_fallback.py # 智能降级机制
|
||||
└── data_quality_monitor.py # 数据质量监控
|
||||
```
|
||||
|
||||
**核心代码需求:**
|
||||
```python
|
||||
class EnhancedOpenBBEngine:
|
||||
"""增强版OpenBB引擎 - 八仙专属"""
|
||||
|
||||
async def get_immortal_insight(self, immortal_name: str,
|
||||
symbol: str, analysis_type: str):
|
||||
"""为特定八仙获取专属金融洞察"""
|
||||
pass
|
||||
|
||||
async def orchestrate_debate_data(self, topic: str,
|
||||
participants: List[str]):
|
||||
"""为稷下学宫辩论准备数据"""
|
||||
pass
|
||||
```
|
||||
|
||||
### 2. 智能体数据适配器
|
||||
**任务目标:** 实现AI智能体与OpenBB数据的无缝对接
|
||||
|
||||
**具体实现:**
|
||||
- 八仙角色数据源适配
|
||||
- 实时数据流处理
|
||||
- 智能缓存机制
|
||||
- 异常处理和重试逻辑
|
||||
|
||||
**核心文件:**
|
||||
- `src/jixia/adapters/openbb_agent_adapter.py`
|
||||
- `src/jixia/adapters/immortal_data_processor.py`
|
||||
|
||||
### 3. Streamlit界面增强
|
||||
**任务目标:** 优化现有OpenBB标签页,增加八仙论道功能
|
||||
|
||||
**需要修改的文件:**
|
||||
- `app/tabs/openbb_tab.py` - 增强现有界面
|
||||
- `app/tabs/immortal_debate_tab.py` - 新增八仙辩论界面
|
||||
|
||||
**UI功能需求:**
|
||||
```python
|
||||
def render_immortal_debate_interface():
|
||||
"""渲染八仙辩论界面"""
|
||||
# 1. 股票/主题选择器
|
||||
# 2. 八仙角色选择器
|
||||
# 3. 实时数据展示
|
||||
# 4. 辩论结果可视化
|
||||
pass
|
||||
```
|
||||
|
||||
### 4. 数据质量保障
|
||||
**任务目标:** 确保数据准确性和系统稳定性
|
||||
|
||||
**实现重点:**
|
||||
- 数据验证机制
|
||||
- 异常数据处理
|
||||
- 性能监控埋点
|
||||
- 日志记录系统
|
||||
|
||||
## 🔧 实现规范
|
||||
|
||||
### 代码风格要求:
|
||||
```python
|
||||
# 1. 遵循项目现有代码风格
|
||||
# 2. 完整的类型注解
|
||||
# 3. 详细的docstring文档
|
||||
# 4. 异常处理机制
|
||||
|
||||
from typing import Dict, List, Optional, Union
|
||||
from dataclasses import dataclass
|
||||
from datetime import datetime
|
||||
|
||||
@dataclass
|
||||
class ImmortalInsight:
|
||||
"""八仙洞察数据模型"""
|
||||
immortal_name: str
|
||||
symbol: str
|
||||
insight_type: str
|
||||
data: Dict[str, any]
|
||||
confidence: float
|
||||
timestamp: datetime
|
||||
```
|
||||
|
||||
### 必须保持的特性:
|
||||
1. **向后兼容** - 不破坏现有功能
|
||||
2. **优雅降级** - OpenBB不可用时的备选方案
|
||||
3. **文化内核** - 保持八仙论道的文化特色
|
||||
4. **模块化设计** - 便于单元测试和维护
|
||||
|
||||
### 性能要求:
|
||||
- 数据获取响应时间 < 3秒
|
||||
- 并发处理能力 > 10个请求/秒
|
||||
- 内存使用 < 500MB
|
||||
- CPU使用率 < 30%
|
||||
|
||||
## 🎭 八仙特色功能实现
|
||||
|
||||
### 八仙数据偏好实现:
|
||||
```python
|
||||
IMMORTAL_PREFERENCES = {
|
||||
'吕洞宾': {
|
||||
'data_types': ['technical_indicators', 'chart_patterns'],
|
||||
'analysis_style': 'systematic',
|
||||
'risk_appetite': 'moderate'
|
||||
},
|
||||
'何仙姑': {
|
||||
'data_types': ['risk_metrics', 'volatility'],
|
||||
'analysis_style': 'conservative',
|
||||
'risk_appetite': 'low'
|
||||
},
|
||||
# ... 其他六仙
|
||||
}
|
||||
```
|
||||
|
||||
### 智能辩论数据准备:
|
||||
```python
|
||||
async def prepare_debate_data(self, topic_symbol: str) -> DebateDataSet:
|
||||
"""为八仙辩论准备差异化数据视角"""
|
||||
# 1. 获取基础数据
|
||||
# 2. 按八仙偏好处理数据
|
||||
# 3. 生成对比性观点
|
||||
# 4. 返回结构化辩论数据
|
||||
pass
|
||||
```
|
||||
|
||||
## 🧪 测试要求
|
||||
|
||||
### 必须实现的测试:
|
||||
```python
|
||||
# tests/test_enhanced_openbb_engine.py
|
||||
class TestEnhancedOpenBBEngine:
|
||||
def test_immortal_data_routing(self):
|
||||
"""测试八仙数据路由功能"""
|
||||
pass
|
||||
|
||||
def test_fallback_mechanism(self):
|
||||
"""测试降级机制"""
|
||||
pass
|
||||
|
||||
def test_concurrent_requests(self):
|
||||
"""测试并发请求处理"""
|
||||
pass
|
||||
```
|
||||
|
||||
### 集成测试:
|
||||
- 与现有八仙辩论系统的集成
|
||||
- Streamlit界面集成测试
|
||||
- 实际数据获取测试
|
||||
|
||||
## 🔄 协作接口
|
||||
|
||||
### 接收Qwen的架构输入:
|
||||
- [ ] 架构设计文档
|
||||
- [ ] 接口规范定义
|
||||
- [ ] 数据模型标准
|
||||
|
||||
### 为Gemini提供测试目标:
|
||||
- [ ] 完整的代码实现
|
||||
- [ ] 单元测试用例
|
||||
- [ ] 集成测试指南
|
||||
|
||||
### 为RovoDev提供文档素材:
|
||||
- [ ] 代码注释和文档
|
||||
- [ ] API使用示例
|
||||
- [ ] 故障排除指南
|
||||
|
||||
## 📅 开发里程碑
|
||||
|
||||
### 里程碑1(3天):
|
||||
- [ ] 核心引擎实现
|
||||
- [ ] 基础单元测试
|
||||
- [ ] 简单集成验证
|
||||
|
||||
### 里程碑2(2天):
|
||||
- [ ] Streamlit界面增强
|
||||
- [ ] 八仙特色功能
|
||||
- [ ] 性能优化
|
||||
|
||||
### 里程碑3(1天):
|
||||
- [ ] 完整测试覆盖
|
||||
- [ ] 代码审查和优化
|
||||
- [ ] 文档完善
|
||||
|
||||
## 💡 创新挑战
|
||||
|
||||
请在实现中展现创新:
|
||||
1. **智能数据融合算法**
|
||||
2. **八仙个性化数据处理**
|
||||
3. **实时性能监控机制**
|
||||
4. **用户体验优化**
|
||||
|
||||
## ⚠️ 特别注意
|
||||
|
||||
### 文化敏感性:
|
||||
- 确保八仙角色的准确性和尊重性
|
||||
- 保持传统文化与现代技术的平衡
|
||||
- 避免过度商业化的表达
|
||||
|
||||
### 技术债务控制:
|
||||
- 避免硬编码
|
||||
- 保持配置的灵活性
|
||||
- 确保代码的可维护性
|
||||
|
||||
---
|
||||
|
||||
**注意:** 代码是文化的载体,请让每一行代码都体现稷下学宫的智慧!
|
||||
274
docs/AI_AGENT_TASKS/GEMINI_TEST_VALIDATION.md
Normal file
274
docs/AI_AGENT_TASKS/GEMINI_TEST_VALIDATION.md
Normal file
@@ -0,0 +1,274 @@
|
||||
# 🧪 Gemini AI - OpenBB集成测试验证工作说明书
|
||||
|
||||
## 🎯 任务概述
|
||||
作为测试工程师,您需要为OpenBB与稷下学宫系统的集成功能设计并执行全面的测试验证方案。
|
||||
|
||||
## 📋 核心职责
|
||||
|
||||
### 1. 测试策略制定
|
||||
**任务目标:** 制定全面的测试策略和验证标准
|
||||
|
||||
**测试金字塔设计:**
|
||||
```
|
||||
[E2E Tests] # 端到端测试
|
||||
/ \
|
||||
[Integration Tests] # 集成测试
|
||||
/ \
|
||||
[Unit Tests] [API Tests] # 单元测试 + API测试
|
||||
```
|
||||
|
||||
**测试覆盖范围:**
|
||||
- 功能测试 (80%覆盖率)
|
||||
- 性能测试 (响应时间、并发)
|
||||
- 稳定性测试 (长时间运行)
|
||||
- 兼容性测试 (多数据源)
|
||||
|
||||
### 2. 八仙智能体测试
|
||||
**任务目标:** 验证八仙角色的数据获取和分析能力
|
||||
|
||||
**测试文件结构:**
|
||||
```
|
||||
tests/immortal_tests/
|
||||
├── test_immortal_data_routing.py # 八仙数据路由测试
|
||||
├── test_immortal_preferences.py # 八仙偏好测试
|
||||
├── test_debate_data_quality.py # 辩论数据质量测试
|
||||
└── test_cultural_accuracy.py # 文化准确性测试
|
||||
```
|
||||
|
||||
**关键测试用例:**
|
||||
```python
|
||||
class TestImmortalDataRouting:
|
||||
"""八仙数据路由测试"""
|
||||
|
||||
def test_lv_dongbin_technical_analysis(self):
|
||||
"""测试吕洞宾的技术分析数据获取"""
|
||||
pass
|
||||
|
||||
def test_he_xiangu_risk_metrics(self):
|
||||
"""测试何仙姑的风险指标数据"""
|
||||
pass
|
||||
|
||||
def test_immortal_data_consistency(self):
|
||||
"""测试八仙数据的一致性"""
|
||||
pass
|
||||
```
|
||||
|
||||
### 3. OpenBB集成测试
|
||||
**任务目标:** 验证OpenBB数据源的集成质量
|
||||
|
||||
**测试重点:**
|
||||
- OpenBB API调用稳定性
|
||||
- 数据格式标准化
|
||||
- 错误处理机制
|
||||
- 降级策略验证
|
||||
|
||||
**核心测试文件:**
|
||||
```python
|
||||
# tests/openbb_integration/
|
||||
class TestOpenBBIntegration:
|
||||
"""OpenBB集成测试套件"""
|
||||
|
||||
@pytest.mark.asyncio
|
||||
async def test_stock_data_retrieval(self):
|
||||
"""测试股票数据获取"""
|
||||
symbols = ['AAPL', 'TSLA', 'MSFT']
|
||||
for symbol in symbols:
|
||||
data = await engine.get_stock_data(symbol)
|
||||
assert data is not None
|
||||
assert 'close' in data.columns
|
||||
|
||||
def test_fallback_mechanism(self):
|
||||
"""测试OpenBB不可用时的降级机制"""
|
||||
# 模拟OpenBB不可用
|
||||
with mock.patch('openbb.obb', side_effect=ImportError):
|
||||
result = engine.get_data_with_fallback('AAPL')
|
||||
assert result.source == 'demo_data'
|
||||
```
|
||||
|
||||
### 4. 性能和稳定性测试
|
||||
**任务目标:** 确保系统在各种条件下的性能表现
|
||||
|
||||
**性能基准:**
|
||||
- 数据获取延迟 < 3秒
|
||||
- 并发处理 > 10 req/s
|
||||
- 内存使用 < 500MB
|
||||
- 99.9% 可用性
|
||||
|
||||
**负载测试方案:**
|
||||
```python
|
||||
# tests/performance/
|
||||
class TestPerformance:
|
||||
"""性能测试套件"""
|
||||
|
||||
def test_concurrent_data_requests(self):
|
||||
"""并发数据请求测试"""
|
||||
import concurrent.futures
|
||||
|
||||
with concurrent.futures.ThreadPoolExecutor(max_workers=10) as executor:
|
||||
futures = [executor.submit(self.get_test_data) for _ in range(100)]
|
||||
results = [f.result() for f in futures]
|
||||
|
||||
assert all(r.success for r in results)
|
||||
assert max(r.response_time for r in results) < 5.0
|
||||
```
|
||||
|
||||
## 🎭 文化特色测试
|
||||
|
||||
### 八仙文化准确性验证:
|
||||
```python
|
||||
class TestCulturalAccuracy:
|
||||
"""文化准确性测试"""
|
||||
|
||||
def test_immortal_characteristics(self):
|
||||
"""验证八仙特征的准确性"""
|
||||
immortals = get_immortal_configs()
|
||||
|
||||
# 验证吕洞宾的技术分析特色
|
||||
assert immortals['吕洞宾'].specialty == 'technical_analysis'
|
||||
assert immortals['吕洞宾'].element == '乾'
|
||||
|
||||
# 验证何仙姑的风险控制特色
|
||||
assert immortals['何仙姑'].specialty == 'risk_metrics'
|
||||
assert immortals['何仙姑'].element == '坤'
|
||||
|
||||
def test_debate_cultural_context(self):
|
||||
"""验证辩论的文化背景准确性"""
|
||||
debate = create_test_debate('AAPL')
|
||||
|
||||
# 确保辩论遵循稷下学宫的传统
|
||||
assert 'jixia' in debate.context
|
||||
assert len(debate.participants) == 8 # 八仙
|
||||
```
|
||||
|
||||
## 🔧 测试工具和框架
|
||||
|
||||
### 推荐工具栈:
|
||||
```python
|
||||
# 测试依赖
|
||||
pytest>=7.4.0 # 主测试框架
|
||||
pytest-asyncio>=0.21.0 # 异步测试支持
|
||||
pytest-mock>=3.11.0 # Mock功能
|
||||
pytest-cov>=4.1.0 # 覆盖率统计
|
||||
pytest-benchmark>=4.0.0 # 性能基准测试
|
||||
|
||||
# 性能测试
|
||||
locust>=2.15.0 # 负载测试
|
||||
memory-profiler>=0.60.0 # 内存分析
|
||||
|
||||
# 数据验证
|
||||
pydantic>=2.0.0 # 数据模型验证
|
||||
jsonschema>=4.19.0 # JSON架构验证
|
||||
```
|
||||
|
||||
### 测试配置文件:
|
||||
```yaml
|
||||
# pytest.ini
|
||||
[tool:pytest]
|
||||
testpaths = tests
|
||||
python_files = test_*.py
|
||||
python_classes = Test*
|
||||
python_functions = test_*
|
||||
addopts =
|
||||
--cov=src
|
||||
--cov-report=html
|
||||
--cov-report=term-missing
|
||||
--asyncio-mode=auto
|
||||
```
|
||||
|
||||
## 📊 测试报告和指标
|
||||
|
||||
### 测试报告模板:
|
||||
```
|
||||
tests/reports/
|
||||
├── unit_test_report.html # 单元测试报告
|
||||
├── integration_test_report.html # 集成测试报告
|
||||
├── performance_benchmark.json # 性能基准数据
|
||||
├── coverage_report/ # 代码覆盖率报告
|
||||
└── cultural_validation_report.md # 文化验证报告
|
||||
```
|
||||
|
||||
### 关键指标监控:
|
||||
```python
|
||||
# 自动化指标收集
|
||||
class TestMetrics:
|
||||
"""测试指标收集器"""
|
||||
|
||||
def collect_response_times(self):
|
||||
"""收集响应时间数据"""
|
||||
pass
|
||||
|
||||
def measure_memory_usage(self):
|
||||
"""监控内存使用情况"""
|
||||
pass
|
||||
|
||||
def validate_data_quality(self):
|
||||
"""验证数据质量指标"""
|
||||
pass
|
||||
```
|
||||
|
||||
## 🔄 协作流程
|
||||
|
||||
### 与Claude的协作:
|
||||
1. **接收代码实现** → 制定对应测试用例
|
||||
2. **执行测试验证** → 反馈BUG和优化建议
|
||||
3. **性能测试** → 提供优化方向
|
||||
|
||||
### 与Qwen的协作:
|
||||
1. **验证架构设计** → 确认技术指标可达成
|
||||
2. **测试架构决策** → 验证设计的合理性
|
||||
|
||||
### 与RovoDev的协作:
|
||||
1. **提供测试数据** → 支持文档编写
|
||||
2. **验证文档准确性** → 确保文档与实际一致
|
||||
|
||||
## 📅 测试里程碑
|
||||
|
||||
### 阶段一(2天):测试框架搭建
|
||||
- [ ] 测试环境配置
|
||||
- [ ] 基础测试框架
|
||||
- [ ] Mock数据准备
|
||||
|
||||
### 阶段二(3天):功能测试执行
|
||||
- [ ] 单元测试执行
|
||||
- [ ] 集成测试验证
|
||||
- [ ] 八仙特色功能测试
|
||||
|
||||
### 阶段三(2天):性能和稳定性测试
|
||||
- [ ] 负载测试执行
|
||||
- [ ] 性能基准建立
|
||||
- [ ] 稳定性验证
|
||||
|
||||
### 阶段四(1天):测试报告生成
|
||||
- [ ] 测试结果汇总
|
||||
- [ ] 问题清单整理
|
||||
- [ ] 优化建议制定
|
||||
|
||||
## 🎯 验收标准
|
||||
|
||||
### 功能验收:
|
||||
- [ ] 所有单元测试通过率 > 95%
|
||||
- [ ] 集成测试通过率 > 90%
|
||||
- [ ] 八仙特色功能100%验证通过
|
||||
|
||||
### 性能验收:
|
||||
- [ ] 响应时间 < 3秒
|
||||
- [ ] 并发处理 > 10 req/s
|
||||
- [ ] 内存使用稳定
|
||||
- [ ] 99%可用性达成
|
||||
|
||||
### 文化验收:
|
||||
- [ ] 八仙角色特征准确
|
||||
- [ ] 辩论逻辑符合传统
|
||||
- [ ] 文化表达尊重得体
|
||||
|
||||
## 💡 创新测试方法
|
||||
|
||||
### 智能化测试:
|
||||
1. **AI驱动的测试用例生成**
|
||||
2. **自适应性能基准调整**
|
||||
3. **文化语境的自动化验证**
|
||||
4. **用户行为模拟测试**
|
||||
|
||||
---
|
||||
|
||||
**注意:** 测试不仅是质量保障,更是文化传承的守护者!每一个测试用例都要体现对传统文化的尊重!
|
||||
122
docs/AI_AGENT_TASKS/QWEN_ARCHITECTURE_DESIGN.md
Normal file
122
docs/AI_AGENT_TASKS/QWEN_ARCHITECTURE_DESIGN.md
Normal file
@@ -0,0 +1,122 @@
|
||||
# 📐 Qwen AI - OpenBB架构设计师工作说明书
|
||||
|
||||
## 🎯 任务概述
|
||||
作为架构设计师,您需要为"炼妖壶-稷下学宫AI辩论系统"设计OpenBB集成的技术架构方案。
|
||||
|
||||
## 📋 核心职责
|
||||
|
||||
### 1. 系统架构设计
|
||||
**任务目标:** 设计OpenBB与稷下学宫系统的集成架构
|
||||
|
||||
**具体工作:**
|
||||
- 分析现有系统架构(`src/jixia/engines/`)
|
||||
- 设计OpenBB数据流架构
|
||||
- 制定模块间解耦策略
|
||||
- 设计故障转移和降级机制
|
||||
|
||||
**交付物:**
|
||||
```
|
||||
docs/architecture/
|
||||
├── openbb_integration_architecture.md
|
||||
├── data_flow_diagram.mermaid
|
||||
├── component_interaction_diagram.mermaid
|
||||
└── deployment_architecture.md
|
||||
```
|
||||
|
||||
### 2. 数据抽象层设计
|
||||
**任务目标:** 设计统一的金融数据抽象接口
|
||||
|
||||
**具体工作:**
|
||||
- 定义标准化数据模型
|
||||
- 设计Provider适配器模式
|
||||
- 制定数据缓存策略
|
||||
- 设计数据质量监控机制
|
||||
|
||||
**关键文件:**
|
||||
- `src/jixia/engines/data_abstraction.py`
|
||||
- `src/jixia/models/financial_data_models.py`
|
||||
|
||||
### 3. 性能优化架构
|
||||
**任务目标:** 确保系统在高并发下的稳定性
|
||||
|
||||
**具体工作:**
|
||||
- 设计异步数据获取架构
|
||||
- 制定缓存策略(Redis/Memory)
|
||||
- 设计负载均衡机制
|
||||
- 制定监控和告警策略
|
||||
|
||||
## 🔧 技术约束
|
||||
|
||||
### 必须遵循的原则:
|
||||
1. **渐进式集成** - 不破坏现有功能
|
||||
2. **可选依赖** - OpenBB失效时优雅降级
|
||||
3. **文化融合** - 保持八仙论道的文化特色
|
||||
4. **模块解耦** - 便于后续扩展其他数据源
|
||||
|
||||
### 技术栈限制:
|
||||
- Python 3.10+
|
||||
- 现有Streamlit界面
|
||||
- 八仙智能体系统
|
||||
- Vertex AI记忆银行
|
||||
|
||||
## 📊 成功标准
|
||||
|
||||
### 架构质量指标:
|
||||
- [ ] 模块耦合度 < 20%
|
||||
- [ ] 代码复用率 > 80%
|
||||
- [ ] 系统可用性 > 99%
|
||||
- [ ] 响应时间 < 2秒
|
||||
|
||||
### 文档完整性:
|
||||
- [ ] 架构图清晰易懂
|
||||
- [ ] 接口文档完整
|
||||
- [ ] 部署指南详细
|
||||
- [ ] 故障处理手册
|
||||
|
||||
## 🎭 与稷下学宫的结合
|
||||
|
||||
### 八仙角色映射:
|
||||
```python
|
||||
# 设计八仙与数据源的智能映射
|
||||
immortal_data_mapping = {
|
||||
'吕洞宾': 'technical_analysis', # 技术分析专家
|
||||
'何仙姑': 'risk_metrics', # 风险控制专家
|
||||
'张果老': 'historical_data', # 历史数据分析师
|
||||
'韩湘子': 'sector_analysis', # 新兴资产专家
|
||||
'汉钟离': 'market_movers', # 热点追踪
|
||||
'蓝采和': 'value_discovery', # 潜力股发现
|
||||
'铁拐李': 'contrarian_analysis', # 逆向思维专家
|
||||
'曹国舅': 'macro_economics' # 宏观经济分析师
|
||||
}
|
||||
```
|
||||
|
||||
## 🔄 协作接口
|
||||
|
||||
### 与其他AI的协作:
|
||||
- **Claude(代码实现)**: 提供详细的接口规范和实现指导
|
||||
- **Gemini(测试验证)**: 制定测试用例和验证标准
|
||||
- **RovoDev(文档整合)**: 提供架构决策文档和技术规范
|
||||
|
||||
## 📅 时间节点
|
||||
|
||||
### 阶段一(2天):
|
||||
- [ ] 现有系统分析
|
||||
- [ ] 架构方案设计
|
||||
- [ ] 核心接口定义
|
||||
|
||||
### 阶段二(1天):
|
||||
- [ ] 详细设计文档
|
||||
- [ ] 技术选型说明
|
||||
- [ ] 风险评估报告
|
||||
|
||||
## 💡 创新要求
|
||||
|
||||
作为架构师,请在以下方面展现创新:
|
||||
1. **传统文化与现代技术的融合**
|
||||
2. **智能化的数据路由策略**
|
||||
3. **自适应的性能优化机制**
|
||||
4. **面向未来的可扩展架构**
|
||||
|
||||
---
|
||||
|
||||
**注意:** 这是一个文化与技术深度融合的项目,请在技术设计中体现中国传统哲学思想!
|
||||
236
docs/AI_AGENT_TASKS/README.md
Normal file
236
docs/AI_AGENT_TASKS/README.md
Normal file
@@ -0,0 +1,236 @@
|
||||
# 🎭 四AI协作指南 - OpenBB稷下学宫集成项目
|
||||
|
||||
## 🎯 项目使命
|
||||
将OpenBB金融数据平台与稷下学宫八仙论道系统深度融合,创造传统文化与现代金融科技的完美结合。
|
||||
|
||||
## 👥 团队角色与协作关系
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Qwen - 架构设计师] --> B[Claude - 核心开发工程师]
|
||||
A --> C[Gemini - 测试验证专家]
|
||||
A --> D[RovoDev - 项目整合专家]
|
||||
B --> C
|
||||
B --> D
|
||||
C --> D
|
||||
|
||||
subgraph 协作流程
|
||||
E[架构设计] --> F[代码实现]
|
||||
F --> G[测试验证]
|
||||
G --> H[文档整合]
|
||||
H --> I[项目交付]
|
||||
end
|
||||
```
|
||||
|
||||
## 📋 各AI工作说明书链接
|
||||
|
||||
| AI角色 | 主要职责 | 工作说明书 |
|
||||
|--------|----------|------------|
|
||||
| **Qwen** | 架构设计师 | [`QWEN_ARCHITECTURE_DESIGN.md`](./QWEN_ARCHITECTURE_DESIGN.md) |
|
||||
| **Claude** | 核心开发工程师 | [`CLAUDE_CODE_IMPLEMENTATION.md`](./CLAUDE_CODE_IMPLEMENTATION.md) |
|
||||
| **Gemini** | 测试验证专家 | [`GEMINI_TEST_VALIDATION.md`](./GEMINI_TEST_VALIDATION.md) |
|
||||
| **RovoDev** | 项目整合专家 | [`ROVODEV_PROJECT_INTEGRATION.md`](./ROVODEV_PROJECT_INTEGRATION.md) |
|
||||
|
||||
## 🔄 协作工作流
|
||||
|
||||
### 第一阶段:设计与规划 (Day 1-3)
|
||||
```
|
||||
Qwen 主导:
|
||||
├── 系统架构设计
|
||||
├── 接口规范定义
|
||||
├── 技术选型方案
|
||||
└── 实施计划制定
|
||||
|
||||
其他AI配合:
|
||||
├── Claude: 技术可行性评估
|
||||
├── Gemini: 测试策略制定
|
||||
└── RovoDev: 项目框架搭建
|
||||
```
|
||||
|
||||
### 第二阶段:核心开发 (Day 4-8)
|
||||
```
|
||||
Claude 主导:
|
||||
├── 核心引擎实现
|
||||
├── API集成开发
|
||||
├── UI界面增强
|
||||
└── 功能模块编码
|
||||
|
||||
其他AI配合:
|
||||
├── Qwen: 架构指导和审查
|
||||
├── Gemini: 同步测试执行
|
||||
└── RovoDev: 代码集成管理
|
||||
```
|
||||
|
||||
### 第三阶段:测试验证 (Day 9-12)
|
||||
```
|
||||
Gemini 主导:
|
||||
├── 功能测试执行
|
||||
├── 性能基准测试
|
||||
├── 集成测试验证
|
||||
└── 文化准确性检查
|
||||
|
||||
其他AI配合:
|
||||
├── Qwen: 架构层面问题解决
|
||||
├── Claude: 代码BUG修复
|
||||
└── RovoDev: 测试结果整合
|
||||
```
|
||||
|
||||
### 第四阶段:整合交付 (Day 13-15)
|
||||
```
|
||||
RovoDev 主导:
|
||||
├── 文档体系整合
|
||||
├── 用户指南编写
|
||||
├── 项目质量检查
|
||||
└── 最终版本发布
|
||||
|
||||
其他AI配合:
|
||||
├── Qwen: 架构文档审核
|
||||
├── Claude: 技术文档完善
|
||||
└── Gemini: 测试报告整理
|
||||
```
|
||||
|
||||
## 🎭 文化核心要求
|
||||
|
||||
### 八仙角色特征(所有AI必须遵循):
|
||||
```python
|
||||
IMMORTAL_CHARACTERISTICS = {
|
||||
'吕洞宾': {
|
||||
'element': '乾', # 八卦方位
|
||||
'specialty': '技术分析', # 专业特长
|
||||
'personality': '系统性', # 性格特点
|
||||
'approach': '理性分析' # 分析方法
|
||||
},
|
||||
'何仙姑': {
|
||||
'element': '坤',
|
||||
'specialty': '风险控制',
|
||||
'personality': '稳健保守',
|
||||
'approach': '风险优先'
|
||||
},
|
||||
'张果老': {
|
||||
'element': '兑',
|
||||
'specialty': '历史数据',
|
||||
'personality': '博学深沉',
|
||||
'approach': '历史借鉴'
|
||||
},
|
||||
'韩湘子': {
|
||||
'element': '艮',
|
||||
'specialty': '新兴资产',
|
||||
'personality': '创新进取',
|
||||
'approach': '前瞻思维'
|
||||
},
|
||||
'汉钟离': {
|
||||
'element': '离',
|
||||
'specialty': '热点追踪',
|
||||
'personality': '敏锐活跃',
|
||||
'approach': '趋势跟踪'
|
||||
},
|
||||
'蓝采和': {
|
||||
'element': '坎',
|
||||
'specialty': '价值发现',
|
||||
'personality': '独立思考',
|
||||
'approach': '逆向分析'
|
||||
},
|
||||
'铁拐李': {
|
||||
'element': '巽',
|
||||
'specialty': '逆向思维',
|
||||
'personality': '犀利直接',
|
||||
'approach': '反向验证'
|
||||
},
|
||||
'曹国舅': {
|
||||
'element': '震',
|
||||
'specialty': '宏观经济',
|
||||
'personality': '高瞻远瞩',
|
||||
'approach': '宏观视角'
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 稷下学宫核心价值:
|
||||
- **开放包容**:各种观点都能得到尊重
|
||||
- **理性辩论**:基于数据和逻辑的讨论
|
||||
- **百家争鸣**:鼓励不同视角的碰撞
|
||||
- **求同存异**:在分歧中寻找共识
|
||||
|
||||
## 📊 质量标准(所有AI共同遵循)
|
||||
|
||||
### 技术质量:
|
||||
- [ ] 代码测试覆盖率 > 80%
|
||||
- [ ] API响应时间 < 3秒
|
||||
- [ ] 系统可用性 > 99%
|
||||
- [ ] 并发处理能力 > 10 req/s
|
||||
|
||||
### 文化质量:
|
||||
- [ ] 八仙特征准确性 100%
|
||||
- [ ] 传统文化表达尊重性 100%
|
||||
- [ ] 现代化融合自然度 > 90%
|
||||
- [ ] 教育价值体现度 > 85%
|
||||
|
||||
### 用户体验:
|
||||
- [ ] 界面直观度 > 90%
|
||||
- [ ] 功能易用性 > 85%
|
||||
- [ ] 文档完整性 > 95%
|
||||
- [ ] 错误处理友好度 > 90%
|
||||
|
||||
## 🔄 沟通协作机制
|
||||
|
||||
### 日常沟通:
|
||||
- **每日站会** (15分钟):进度同步,问题协调
|
||||
- **技术评审** (每2天):关键决策讨论
|
||||
- **质量检查** (每周):交叉审查工作成果
|
||||
|
||||
### 问题升级机制:
|
||||
```
|
||||
Level 1: AI间直接协商
|
||||
Level 2: RovoDev协调处理
|
||||
Level 3: 项目负责人决策
|
||||
```
|
||||
|
||||
### 文档共享约定:
|
||||
- 所有设计文档实时共享
|
||||
- 代码变更及时通知相关AI
|
||||
- 测试结果定期同步
|
||||
- 问题和解决方案公开透明
|
||||
|
||||
## 🎯 成功标准
|
||||
|
||||
### 项目成功的标志:
|
||||
1. **功能完整**:OpenBB数据与八仙论道完美融合
|
||||
2. **性能稳定**:各种场景下系统表现良好
|
||||
3. **文化准确**:传统文化表达准确尊重
|
||||
4. **用户满意**:最终用户体验优秀
|
||||
5. **可维护性**:代码和文档便于后续维护
|
||||
|
||||
### 团队协作成功的标志:
|
||||
1. **沟通顺畅**:各AI间协作无障碍
|
||||
2. **质量一致**:各模块质量标准统一
|
||||
3. **进度可控**:项目按时交付
|
||||
4. **创新突出**:在传统与现代结合上有所突破
|
||||
|
||||
## 💡 创新目标
|
||||
|
||||
### 技术创新:
|
||||
- 智能化的数据路由算法
|
||||
- 自适应的性能优化机制
|
||||
- 文化语境的AI理解能力
|
||||
|
||||
### 文化创新:
|
||||
- 传统文化的现代化表达
|
||||
- 金融科技的人文内涵
|
||||
- AI技术的文化责任
|
||||
|
||||
### 用户体验创新:
|
||||
- 沉浸式的文化体验
|
||||
- 智能化的学习辅助
|
||||
- 个性化的论道体验
|
||||
|
||||
---
|
||||
|
||||
## 📞 紧急联系
|
||||
|
||||
如遇到跨团队协调问题,请立即联系项目整合专家 RovoDev。
|
||||
|
||||
**记住**:我们不仅在构建技术产品,更在传承和发扬中华文化!每一行代码、每一个测试、每一份文档都承载着文化的使命!
|
||||
|
||||
---
|
||||
|
||||
*"稷下学宫,百家争鸣;开源精神,技术报国!"*
|
||||
289
docs/AI_AGENT_TASKS/ROVODEV_PROJECT_INTEGRATION.md
Normal file
289
docs/AI_AGENT_TASKS/ROVODEV_PROJECT_INTEGRATION.md
Normal file
@@ -0,0 +1,289 @@
|
||||
# 📚 RovoDev AI - OpenBB项目整合与文档管理工作说明书
|
||||
|
||||
## 🎯 任务概述
|
||||
作为项目整合专家,您需要协调四个AI团队的工作成果,整合OpenBB集成项目的完整文档体系,并确保项目的顺利交付。
|
||||
|
||||
## 📋 核心职责
|
||||
|
||||
### 1. 项目协调与整合
|
||||
**任务目标:** 统筹四个AI团队的工作,确保各模块无缝对接
|
||||
|
||||
**协调矩阵:**
|
||||
```
|
||||
Qwen Claude Gemini RovoDev
|
||||
架构设计 主导 配合 验证 整合
|
||||
代码实现 配合 主导 验证 监控
|
||||
测试验证 配合 配合 主导 汇总
|
||||
文档整合 配合 配合 配合 主导
|
||||
```
|
||||
|
||||
**关键协调点:**
|
||||
- 接口规范的一致性
|
||||
- 代码实现与架构设计的匹配度
|
||||
- 测试用例覆盖的完整性
|
||||
- 文档与实际功能的准确性
|
||||
|
||||
### 2. 完整文档体系构建
|
||||
**任务目标:** 建立OpenBB集成的完整文档生态
|
||||
|
||||
**文档架构:**
|
||||
```
|
||||
docs/openbb_integration/
|
||||
├── 00_PROJECT_OVERVIEW.md # 项目总览
|
||||
├── 01_ARCHITECTURE_DESIGN/ # 架构设计(Qwen输出)
|
||||
│ ├── system_architecture.md
|
||||
│ ├── data_flow_design.md
|
||||
│ ├── integration_patterns.md
|
||||
│ └── deployment_strategy.md
|
||||
├── 02_IMPLEMENTATION_GUIDE/ # 实现指南(Claude输出)
|
||||
│ ├── core_engine_implementation.md
|
||||
│ ├── api_integration_guide.md
|
||||
│ ├── ui_enhancement_guide.md
|
||||
│ └── troubleshooting_guide.md
|
||||
├── 03_TEST_DOCUMENTATION/ # 测试文档(Gemini输出)
|
||||
│ ├── test_strategy.md
|
||||
│ ├── test_results_report.md
|
||||
│ ├── performance_benchmarks.md
|
||||
│ └── quality_assurance_report.md
|
||||
├── 04_USER_GUIDES/ # 用户指南
|
||||
│ ├── getting_started.md
|
||||
│ ├── immortal_debate_tutorial.md
|
||||
│ ├── configuration_guide.md
|
||||
│ └── best_practices.md
|
||||
├── 05_CULTURAL_INTEGRATION/ # 文化融合文档
|
||||
│ ├── immortal_characteristics.md
|
||||
│ ├── jixia_philosophy_in_code.md
|
||||
│ └── cultural_accuracy_guidelines.md
|
||||
└── 06_MAINTENANCE/ # 维护文档
|
||||
├── release_notes.md
|
||||
├── upgrade_guide.md
|
||||
├── known_issues.md
|
||||
└── future_roadmap.md
|
||||
```
|
||||
|
||||
### 3. 用户体验设计
|
||||
**任务目标:** 确保最终用户能够轻松使用OpenBB集成功能
|
||||
|
||||
**用户旅程设计:**
|
||||
```mermaid
|
||||
graph TD
|
||||
A[用户启动应用] --> B[选择OpenBB标签页]
|
||||
B --> C[查看数据可用性状态]
|
||||
C --> D{OpenBB是否可用?}
|
||||
D -->|是| E[选择股票符号]
|
||||
D -->|否| F[使用演示数据]
|
||||
E --> G[启动八仙论道]
|
||||
F --> G
|
||||
G --> H[查看辩论结果]
|
||||
H --> I[导出分析报告]
|
||||
```
|
||||
|
||||
**交互设计文档:**
|
||||
- 界面原型设计
|
||||
- 用户流程图
|
||||
- 错误处理流程
|
||||
- 帮助文档集成
|
||||
|
||||
### 4. 质量保证与发布管理
|
||||
**任务目标:** 确保项目质量并管理发布流程
|
||||
|
||||
**质量检查清单:**
|
||||
- [ ] 代码规范一致性检查
|
||||
- [ ] 文档完整性验证
|
||||
- [ ] 功能集成测试通过
|
||||
- [ ] 性能指标达标
|
||||
- [ ] 文化准确性确认
|
||||
- [ ] 用户体验验证
|
||||
|
||||
## 🎭 文化融合专项工作
|
||||
|
||||
### 传统文化现代化表达:
|
||||
```markdown
|
||||
# 八仙论道的现代诠释
|
||||
|
||||
## 文化内核保持:
|
||||
- **稷下学宫精神**:开放包容、百家争鸣
|
||||
- **八仙特质**:各具特色、相互补充
|
||||
- **论道传统**:理性辩论、求同存异
|
||||
|
||||
## 现代技术表达:
|
||||
- **数据驱动**:用真实数据支撑观点
|
||||
- **智能化**:AI技术赋能传统智慧
|
||||
- **可视化**:现代界面展示古典思想
|
||||
```
|
||||
|
||||
### 文化准确性验证:
|
||||
```python
|
||||
# 文化审核检查点
|
||||
CULTURAL_CHECKPOINTS = {
|
||||
'immortal_names': '确保八仙姓名准确无误',
|
||||
'characteristics': '验证八仙特征描述的准确性',
|
||||
'philosophical_context': '确保稷下学宫背景的正确表达',
|
||||
'respectful_representation': '确保文化表达的尊重性',
|
||||
'educational_value': '验证文化教育价值的体现'
|
||||
}
|
||||
```
|
||||
|
||||
## 📊 项目管理仪表板
|
||||
|
||||
### 进度跟踪系统:
|
||||
```
|
||||
项目进度监控:
|
||||
├── 架构设计进度 [████████░░] 80%
|
||||
├── 代码实现进度 [██████░░░░] 60%
|
||||
├── 测试验证进度 [████░░░░░░] 40%
|
||||
└── 文档整合进度 [███████░░░] 70%
|
||||
|
||||
质量指标:
|
||||
├── 代码覆盖率: 85%
|
||||
├── 文档完整性: 90%
|
||||
├── 测试通过率: 92%
|
||||
└── 文化准确性: 95%
|
||||
```
|
||||
|
||||
### 风险管理:
|
||||
```markdown
|
||||
## 主要风险点识别:
|
||||
|
||||
### 技术风险:
|
||||
- OpenBB版本兼容性问题
|
||||
- 性能瓶颈风险
|
||||
- 数据质量不稳定
|
||||
|
||||
### 文化风险:
|
||||
- 八仙形象表达不当
|
||||
- 传统文化误读
|
||||
- 现代化过度商业化
|
||||
|
||||
### 项目风险:
|
||||
- 团队协调不畅
|
||||
- 进度延迟风险
|
||||
- 质量标准不一致
|
||||
```
|
||||
|
||||
## 🔄 协作工作流
|
||||
|
||||
### 日常协调流程:
|
||||
```
|
||||
每日站会 (15分钟):
|
||||
├── 各AI汇报昨日进展
|
||||
├── 今日工作计划
|
||||
├── 阻塞问题讨论
|
||||
└── 协作需求确认
|
||||
|
||||
每周回顾 (1小时):
|
||||
├── 整体进度回顾
|
||||
├── 质量指标检查
|
||||
├── 风险评估更新
|
||||
└── 下周计划调整
|
||||
```
|
||||
|
||||
### 交付物审核流程:
|
||||
```mermaid
|
||||
graph LR
|
||||
A[AI团队提交] --> B[RovoDev初审]
|
||||
B --> C[质量检查]
|
||||
C --> D{是否达标?}
|
||||
D -->|是| E[集成到主项目]
|
||||
D -->|否| F[反馈修改意见]
|
||||
F --> A
|
||||
E --> G[用户验证]
|
||||
G --> H[正式发布]
|
||||
```
|
||||
|
||||
## 📅 里程碑和时间线
|
||||
|
||||
### 第一周:框架建立
|
||||
- **Day 1-2**: 项目启动,框架搭建
|
||||
- **Day 3-4**: 各团队初始输出整合
|
||||
- **Day 5-7**: 首版原型验证
|
||||
|
||||
### 第二周:核心开发
|
||||
- **Day 8-10**: 核心功能开发
|
||||
- **Day 11-12**: 集成测试执行
|
||||
- **Day 13-14**: 问题修复和优化
|
||||
|
||||
### 第三周:完善和发布
|
||||
- **Day 15-17**: 文档完善和用户测试
|
||||
- **Day 18-19**: 最终质量检查
|
||||
- **Day 20-21**: 项目发布和交付
|
||||
|
||||
## 💡 创新整合方案
|
||||
|
||||
### 1. 智能文档生成
|
||||
```python
|
||||
class IntelligentDocGenerator:
|
||||
"""智能文档生成器"""
|
||||
|
||||
def generate_api_docs(self, code_modules):
|
||||
"""从代码自动生成API文档"""
|
||||
pass
|
||||
|
||||
def create_tutorial_from_tests(self, test_cases):
|
||||
"""从测试用例生成使用教程"""
|
||||
pass
|
||||
|
||||
def cultural_context_validator(self, content):
|
||||
"""文化内容准确性验证"""
|
||||
pass
|
||||
```
|
||||
|
||||
### 2. 多媒体文档体验
|
||||
- 交互式代码示例
|
||||
- 视频教程制作
|
||||
- 在线演示环境
|
||||
- 文化背景介绍动画
|
||||
|
||||
### 3. 社区协作平台
|
||||
```markdown
|
||||
## 开源社区建设:
|
||||
|
||||
### 贡献者指南:
|
||||
- 代码贡献流程
|
||||
- 文档改进指南
|
||||
- 文化咨询渠道
|
||||
- 反馈收集机制
|
||||
|
||||
### 社区活动:
|
||||
- 八仙论道比赛
|
||||
- 传统文化技术沙龙
|
||||
- 开源项目展示
|
||||
- 用户案例分享
|
||||
```
|
||||
|
||||
## 🎯 成功标准
|
||||
|
||||
### 项目交付标准:
|
||||
- [ ] 功能完整性 100%
|
||||
- [ ] 文档覆盖率 95%+
|
||||
- [ ] 用户满意度 90%+
|
||||
- [ ] 文化准确性 100%
|
||||
- [ ] 性能指标达标 100%
|
||||
|
||||
### 长期影响目标:
|
||||
- [ ] 成为传统文化与AI结合的示范项目
|
||||
- [ ] 推动开源社区的文化多元化
|
||||
- [ ] 为金融科技注入文化内涵
|
||||
- [ ] 建立可持续的维护生态
|
||||
|
||||
## 📈 后续运营规划
|
||||
|
||||
### 版本迭代计划:
|
||||
```
|
||||
v1.0: OpenBB基础集成
|
||||
v1.1: 性能优化和BUG修复
|
||||
v1.2: 更多数据源集成
|
||||
v2.0: 高级分析功能
|
||||
v2.1: 移动端适配
|
||||
v3.0: 企业级功能
|
||||
```
|
||||
|
||||
### 社区建设计划:
|
||||
- 建立用户社区
|
||||
- 定期发布教程
|
||||
- 举办线上活动
|
||||
- 收集用户反馈
|
||||
|
||||
---
|
||||
|
||||
**注意:** 作为项目整合者,您是传统文化与现代技术的桥梁!请确保每一个细节都体现对文化的尊重和技术的严谨!
|
||||
13
docs/architecture/component_interaction_diagram.mermaid
Normal file
13
docs/architecture/component_interaction_diagram.mermaid
Normal file
@@ -0,0 +1,13 @@
|
||||
graph LR
|
||||
A[Streamlit App] --> B[OpenBB Tab]
|
||||
A --> C[Debate System]
|
||||
C --> D[Immortal Agents]
|
||||
D --> E[OpenBB Engine]
|
||||
D --> F[Perpetual Engine]
|
||||
B --> G[_load_price_data]
|
||||
G --> H{OpenBB Available?}
|
||||
H -- Yes --> I[OpenBB obb]
|
||||
H -- No --> J[Demo/Synthetic Data]
|
||||
E --> K{OpenBB Available?}
|
||||
K -- Yes --> I
|
||||
K -- No --> L[Error Result]
|
||||
9
docs/architecture/data_flow_diagram.mermaid
Normal file
9
docs/architecture/data_flow_diagram.mermaid
Normal file
@@ -0,0 +1,9 @@
|
||||
graph TD
|
||||
A[User Request] --> B{OpenBB Installed?}
|
||||
B -- Yes --> C{OpenBB Data Available?}
|
||||
C -- Yes --> D[OpenBB Engine]
|
||||
C -- No --> E[Fallback to Demo/Synthetic Data]
|
||||
B -- No --> E
|
||||
D --> F[Format Data]
|
||||
E --> F
|
||||
F --> G[Return to Agent/UI]
|
||||
181
docs/architecture/deployment_architecture.md
Normal file
181
docs/architecture/deployment_architecture.md
Normal file
@@ -0,0 +1,181 @@
|
||||
# OpenBB Integration Deployment Architecture
|
||||
|
||||
## Environment and Dependencies
|
||||
|
||||
### Base Requirements
|
||||
- **Python Version**: 3.8 or higher
|
||||
- **Core Dependencies**: As specified in `requirements.txt` (Streamlit, etc.)
|
||||
|
||||
### Optional OpenBB Dependency
|
||||
- **OpenBB Library**: `openbb>=4.1.0`
|
||||
- **Installation**: Not included in default `requirements.txt` to maintain lightweight base installation
|
||||
- **Activation**: Install via `pip install "openbb>=4.1.0"` when needed
|
||||
|
||||
## Configuration Management
|
||||
|
||||
### Environment Variables
|
||||
- **Standard Project Variables**: Managed through Doppler (RAPIDAPI_KEY, GOOGLE_API_KEY, etc.)
|
||||
- **OpenBB Provider Variables**:
|
||||
- For public data sources (like yfinance): No specific configuration required
|
||||
- For premium data sources (e.g., Polygon, FMP):
|
||||
- Variables are managed by OpenBB internally
|
||||
- Follow OpenBB documentation for provider-specific setup
|
||||
- Example: `POLYGON_API_KEY` for Polygon.io data
|
||||
|
||||
### Feature Flags
|
||||
- **JIXIA_MEMORY_BACKEND**: When set to "cloudflare", enables Cloudflare AutoRAG as memory backend
|
||||
- **GOOGLE_GENAI_USE_VERTEXAI**: When set to "TRUE", enables Vertex AI for memory bank
|
||||
|
||||
## Deployment Scenarios
|
||||
|
||||
### 1. Base Deployment (OpenBB Not Installed)
|
||||
- **Characteristics**:
|
||||
- Lightweight installation
|
||||
- Relies on existing RapidAPI-based perpetual engine
|
||||
- UI falls back to demo or synthetic data in OpenBB tab
|
||||
- **Use Cases**:
|
||||
- Minimal environment setups
|
||||
- Systems where OpenBB installation is not feasible
|
||||
- Development environments focusing on other features
|
||||
|
||||
### 2. Full Deployment (With OpenBB)
|
||||
- **Characteristics**:
|
||||
- Enhanced data capabilities through OpenBB
|
||||
- Access to multiple data providers
|
||||
- Improved data quality and coverage
|
||||
- **Use Cases**:
|
||||
- Production environments requiring comprehensive market data
|
||||
- Advanced financial analysis and debate scenarios
|
||||
- Integration with premium data sources
|
||||
|
||||
### 3. Hybrid Deployment (Selective Features)
|
||||
- **Characteristics**:
|
||||
- Selective installation of OpenBB providers
|
||||
- Mix of OpenBB and perpetual engine data sources
|
||||
- Fallback mechanisms ensure continuous operation
|
||||
- **Use Cases**:
|
||||
- Cost optimization by using free providers where possible
|
||||
- Gradual migration from perpetual engine to OpenBB
|
||||
- Testing new data sources without full commitment
|
||||
|
||||
## Containerization (Docker)
|
||||
|
||||
### Base Image
|
||||
- Python 3.10-slim or equivalent
|
||||
|
||||
### Multi-Stage Build
|
||||
1. **Builder Stage**:
|
||||
- Install build dependencies
|
||||
- Install Python dependencies
|
||||
2. **Runtime Stage**:
|
||||
- Copy installed packages from builder
|
||||
- Copy application code
|
||||
- Install optional OpenBB dependencies if specified
|
||||
|
||||
### Docker Compose Configuration
|
||||
- Service definitions for main application
|
||||
- Optional service for database (if using persistent memory backends)
|
||||
- Volume mounts for configuration and data persistence
|
||||
|
||||
## Cloud Deployment
|
||||
|
||||
### Google Cloud Platform (GCP)
|
||||
- **App Engine**:
|
||||
- Standard environment with custom runtime
|
||||
- Environment variables configured through `app.yaml`
|
||||
- **Cloud Run**:
|
||||
- Containerized deployment
|
||||
- Secrets managed through Secret Manager
|
||||
- **Compute Engine**:
|
||||
- Full control over VM configuration
|
||||
- Persistent disks for data storage
|
||||
|
||||
### Considerations for Cloud Deployment
|
||||
- **API Key Security**:
|
||||
- Use secret management services (Google Secret Manager, Doppler)
|
||||
- Never store keys in code or environment files
|
||||
- **Memory Backend Configuration**:
|
||||
- For Vertex AI Memory Bank: Configure GOOGLE_CLOUD_PROJECT_ID and authentication
|
||||
- For Cloudflare AutoRAG: Configure CLOUDFLARE_ACCOUNT_ID and API token
|
||||
- **Scalability**:
|
||||
- Stateless application design allows horizontal scaling
|
||||
- Memory backends provide persistence across instances
|
||||
|
||||
## Memory Backend Integration
|
||||
|
||||
### Vertex AI Memory Bank (Default/Primary)
|
||||
- **Activation**: Requires GOOGLE_GENAI_USE_VERTEXAI=true and proper GCP authentication
|
||||
- **Dependencies**: `google-cloud-aiplatform` (installed with google-adk)
|
||||
- **Deployment**: Requires GCP project with Vertex AI API enabled
|
||||
|
||||
### Cloudflare AutoRAG (Alternative)
|
||||
- **Activation**: Requires JIXIA_MEMORY_BACKEND=cloudflare and Cloudflare credentials
|
||||
- **Dependencies**: `aiohttp` (already in requirements)
|
||||
- **Deployment**: Requires Cloudflare account with Vectorize and Workers AI enabled
|
||||
|
||||
## Monitoring and Observability
|
||||
|
||||
### Health Checks
|
||||
- Application startup verification
|
||||
- OpenBB availability check endpoint
|
||||
- Memory backend connectivity verification
|
||||
|
||||
### Logging
|
||||
- Structured logging for data access patterns
|
||||
- Error tracking for failed data retrievals
|
||||
- Performance metrics for data loading times
|
||||
|
||||
### Metrics Collection
|
||||
- API usage counters (both RapidAPI and OpenBB)
|
||||
- Fallback trigger rates
|
||||
- Memory backend operation statistics
|
||||
|
||||
## Security Posture
|
||||
|
||||
### Data Security
|
||||
- In-memory data processing
|
||||
- No persistent storage of sensitive financial data
|
||||
- Secure handling of API responses
|
||||
|
||||
### Access Control
|
||||
- Streamlit authentication (if enabled)
|
||||
- API key isolation per data provider
|
||||
- Memory backend access controls through provider mechanisms
|
||||
|
||||
### Network Security
|
||||
- HTTPS for all external API calls
|
||||
- Outbound firewall rules for API endpoints
|
||||
- Secure credential injection mechanisms
|
||||
|
||||
## Disaster Recovery and Business Continuity
|
||||
|
||||
### Data Source Redundancy
|
||||
- Multiple API providers through OpenBB
|
||||
- Fallback to perpetual engine when OpenBB fails
|
||||
- Synthetic data generation for UI continuity
|
||||
|
||||
### Memory Backend Failover
|
||||
- Local simulation mode when cloud backends are unavailable
|
||||
- Graceful degradation of memory features
|
||||
|
||||
### Recovery Procedures
|
||||
- Automated restart on critical failures
|
||||
- Manual intervention procedures for configuration issues
|
||||
- Rollback capabilities through version control
|
||||
|
||||
## Performance Optimization
|
||||
|
||||
### Caching Strategies
|
||||
- OpenBB's internal caching mechanisms
|
||||
- Streamlit's built-in caching for UI components
|
||||
- Memory backend for persistent agent knowledge
|
||||
|
||||
### Resource Management
|
||||
- Asynchronous data loading where possible
|
||||
- Memory-efficient data structures
|
||||
- Connection pooling for API requests
|
||||
|
||||
### Scaling Considerations
|
||||
- Horizontal scaling for handling concurrent users
|
||||
- Vertical scaling for memory-intensive operations
|
||||
- Load balancing for distributed deployments
|
||||
168
docs/architecture/openbb_integration_architecture.md
Normal file
168
docs/architecture/openbb_integration_architecture.md
Normal file
@@ -0,0 +1,168 @@
|
||||
# OpenBB Integration Architecture for 炼妖壶 (Lianyaohu) - 稷下学宫AI辩论系统
|
||||
|
||||
## Overview
|
||||
|
||||
This document outlines the architecture for integrating OpenBB v4 into the Lianyaohu 稷下学宫AI辩论系统. The integration aims to provide enriched financial data to the eight immortal agents while maintaining graceful degradation when OpenBB is not installed or available.
|
||||
|
||||
## System Context
|
||||
|
||||
The Lianyaohu system is a multi-AI-agent debate platform rooted in traditional Chinese philosophy. The eight immortals (八仙) debate investment topics, leveraging data from multiple financial APIs. The system currently uses a "perpetual engine" based on 17 RapidAPI subscriptions. This architecture adds OpenBB as an optional, higher-level data source.
|
||||
|
||||
## Key Components and Integration Points
|
||||
|
||||
### 1. Core Business Logic (`src/jixia/`)
|
||||
#### a. `engines/openbb_engine.py`
|
||||
- **Purpose**: Primary interface to OpenBB v4 data.
|
||||
- **Key Features**:
|
||||
- Lazy loading of `openbb` library to prevent import errors if not installed.
|
||||
- `ImmortalConfig` mapping each immortal to a primary data provider (initially `yfinance`).
|
||||
- `get_immortal_data` method for agent-specific data retrieval based on specialty.
|
||||
- `simulate_jixia_debate` for testing and demonstration.
|
||||
- **Integration Strategy**:
|
||||
- Uses `from openbb import obb` for unified routing.
|
||||
- Handles different data types (price, historical, profile, news, earnings, etc.).
|
||||
- Provides fallback error handling returning `APIResult` objects.
|
||||
|
||||
#### b. `engines/openbb_stock_data.py`
|
||||
- **Purpose**: Utility functions for fetching stock and ETF data.
|
||||
- **Key Features**:
|
||||
- `get_stock_data` and `get_etf_data` functions.
|
||||
- Lazy loading of `openbb`.
|
||||
- Time window configuration.
|
||||
- Data formatting utilities.
|
||||
|
||||
### 2. Application Entry Point (`app/`)
|
||||
#### a. `tabs/openbb_tab.py`
|
||||
- **Purpose**: Streamlit UI tab for visualizing market data.
|
||||
- **Key Features**:
|
||||
- `_check_openbb_installed` to detect availability.
|
||||
- `_load_price_data` with multi-level fallback (OpenBB -> demo JSON -> synthetic data).
|
||||
- KPI calculation from data.
|
||||
- Interactive charting with Plotly.
|
||||
- **Integration Strategy**:
|
||||
- Prioritizes `obb.equity.price.historical`, falling back to `obb.etf.price.historical`.
|
||||
- Handles various data frame formats and column names from different providers.
|
||||
- Graceful UI degradation with informative messages.
|
||||
|
||||
### 3. Data Models (`src/jixia/models/`)
|
||||
*(Note: This directory and specific model files were not found in the current codebase.)*
|
||||
- **Purpose**: Standardized data models for financial data.
|
||||
- **Proposed Implementation**:
|
||||
- Define `FinancialDataPoint`, `StockQuote`, `HistoricalPrice`, etc.
|
||||
- Used by both OpenBB engine and existing perpetual engine for data abstraction.
|
||||
|
||||
### 4. Configuration (`config/settings.py`)
|
||||
- **Purpose**: Centralized configuration management.
|
||||
- **Key Features**:
|
||||
- No direct OpenBB configuration currently, but designed for extensibility.
|
||||
- Validates environment for hybrid AI provider modes.
|
||||
|
||||
## Data Flow Architecture
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[User Request] --> B{OpenBB Installed?}
|
||||
B -- Yes --> C{OpenBB Data Available?}
|
||||
C -- Yes --> D[OpenBB Engine]
|
||||
C -- No --> E[Fallback to Demo/Synthetic Data]
|
||||
B -- No --> E
|
||||
D --> F[Format Data]
|
||||
E --> F
|
||||
F --> G[Return to Agent/UI]
|
||||
```
|
||||
|
||||
1. **Agent Request**: An immortal agent requests data via `OpenBBEngine.get_immortal_data`.
|
||||
2. **OpenBB Check**: The engine checks if OpenBB is available via lazy import.
|
||||
3. **Data Retrieval**: If available, the engine calls the appropriate `obb.*` function.
|
||||
4. **Data Processing**: The engine processes the result into a standardized `APIResult`.
|
||||
5. **Fallback**: If OpenBB is not installed or the call fails, an error result is returned.
|
||||
6. **UI Request**: The OpenBB tab requests data via `_load_price_data`.
|
||||
7. **UI Fallback Chain**:
|
||||
- Tries `obb.equity.price.historical`.
|
||||
- Falls back to `obb.etf.price.historical`.
|
||||
- Falls back to loading demo JSON files.
|
||||
- Finally falls back to generating synthetic data.
|
||||
8. **Data Formatting**: The UI formats the data for display, handling various column names and structures.
|
||||
|
||||
## Component Interaction Diagram
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A[Streamlit App] --> B[OpenBB Tab]
|
||||
A --> C[Debate System]
|
||||
C --> D[Immortal Agents]
|
||||
D --> E[OpenBB Engine]
|
||||
D --> F[Perpetual Engine]
|
||||
B --> G[_load_price_data]
|
||||
G --> H{OpenBB Available?}
|
||||
H -- Yes --> I[OpenBB obb]
|
||||
H -- No --> J[Demo/Synthetic Data]
|
||||
E --> K{OpenBB Available?}
|
||||
K -- Yes --> I
|
||||
K -- No --> L[Error Result]
|
||||
```
|
||||
|
||||
## Deployment Architecture
|
||||
|
||||
### Environment Requirements
|
||||
- Python 3.8+
|
||||
- Optional: `openbb>=4.1.0` (not in default requirements)
|
||||
- Standard project dependencies (Streamlit, etc.)
|
||||
|
||||
### Configuration
|
||||
- No specific OpenBB configuration required for basic `yfinance` use.
|
||||
- Advanced providers (e.g., Polygon) would require provider-specific environment variables.
|
||||
|
||||
### Scalability and Performance
|
||||
- OpenBB's provider system handles its own rate limiting and caching.
|
||||
- The lazy loading approach prevents unnecessary overhead if OpenBB is not used.
|
||||
- Fallback to demo/synthetic data ensures UI responsiveness.
|
||||
|
||||
## Failure Handling and Degradation
|
||||
|
||||
### OpenBB Not Installed
|
||||
- `ImportError` is caught in lazy loading.
|
||||
- Engine returns `APIResult(success=False, error="OpenBB not installed...")`.
|
||||
- UI falls back to demo/synthetic data gracefully.
|
||||
|
||||
### OpenBB API Call Failure
|
||||
- Exception is caught in `get_immortal_data`.
|
||||
- Engine returns `APIResult(success=False, error="OpenBB call failed...")`.
|
||||
- Agent can decide how to handle the failure (e.g., switch to another engine).
|
||||
|
||||
### UI Data Loading Failure
|
||||
- Multi-level fallback ensures data is always available for visualization.
|
||||
- Users are informed via UI messages if demo/synthetic data is being used.
|
||||
|
||||
## Monitoring and Observability
|
||||
|
||||
### Logging
|
||||
- OpenBB engine logs data requests and responses.
|
||||
- UI logs fallback events.
|
||||
|
||||
### Metrics
|
||||
- Not currently implemented, but could track:
|
||||
- OpenBB usage frequency.
|
||||
- Fallback trigger rates.
|
||||
- Data load times.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
### API Keys
|
||||
- OpenBB handles provider API keys internally.
|
||||
- Standard project security practices (Doppler, no hardcoded keys) apply.
|
||||
|
||||
### Data Handling
|
||||
- Data is processed in memory and not persisted by the OpenBB integration components.
|
||||
|
||||
## Future Enhancements
|
||||
|
||||
1. **Unified Data Model**: Create standardized data models in `src/jixia/models/` for seamless integration between OpenBB and other data sources.
|
||||
2. **Provider Configuration**: Allow dynamic configuration of data providers for each immortal.
|
||||
3. **Enhanced UI Components**: Add more detailed financial data visualizations and analysis tools.
|
||||
4. **Debate Integration**: Directly link debate outcomes to specific data points from OpenBB.
|
||||
5. **Advanced OpenBB Routes**: Integrate fundamental data, news, and alternative data sources from OpenBB.
|
||||
|
||||
## Conclusion
|
||||
|
||||
This architecture successfully integrates OpenBB v4 into the Lianyaohu system while maintaining its core principles of graceful degradation and modular design. The lazy loading approach ensures that the system remains functional and performant regardless of whether OpenBB is installed, providing a robust foundation for future enhancements.
|
||||
158
docs/architecture/performance_optimization.md
Normal file
158
docs/architecture/performance_optimization.md
Normal file
@@ -0,0 +1,158 @@
|
||||
# OpenBB Integration Performance Optimization Architecture
|
||||
|
||||
## Overview
|
||||
|
||||
This document outlines the performance optimization strategies for the OpenBB integration in the 炼妖壶 (Lianyaohu) - 稷下学宫AI辩论系统. The goal is to ensure the system can handle high concurrency while maintaining low latency and optimal resource utilization.
|
||||
|
||||
## Asynchronous Data Architecture
|
||||
|
||||
### 1. Asynchronous Data Retrieval
|
||||
- **Implementation**: Use Python's `asyncio` framework for non-blocking data access
|
||||
- **Key Components**:
|
||||
- `DataAbstractionLayer.get_quote_async()` method
|
||||
- Asynchronous providers (where supported by the underlying library)
|
||||
- Executor-based fallback for synchronous providers
|
||||
- **Benefits**:
|
||||
- Improved responsiveness for UI components
|
||||
- Better resource utilization for concurrent requests
|
||||
- Non-blocking operations for agent debates
|
||||
|
||||
### 2. Concurrent Provider Access
|
||||
- **Implementation**: Parallel requests to multiple providers with first-wins semantics
|
||||
- **Strategy**:
|
||||
- Launch requests to all configured providers simultaneously
|
||||
- Return the first successful response
|
||||
- Cancel remaining requests to conserve resources
|
||||
- **Benefits**:
|
||||
- Reduced perceived latency
|
||||
- Automatic failover without delay
|
||||
- Optimal use of available bandwidth
|
||||
|
||||
## Caching Strategy
|
||||
|
||||
### 1. Multi-Level Caching
|
||||
- **In-Memory LRU Cache**:
|
||||
- Decorator-based caching for frequently accessed data (quotes, profiles)
|
||||
- Configurable size limits to prevent memory exhaustion
|
||||
- Time-to-live (TTL) settings based on data volatility
|
||||
- **Shared Cache Layer** (Future):
|
||||
- Redis or Memcached for distributed deployments
|
||||
- Consistent cache invalidation across instances
|
||||
- Support for cache warming strategies
|
||||
|
||||
### 2. Cache Key Design
|
||||
- **Granular Keys**: Separate cache entries for different data types and time windows
|
||||
- **Parameterized Keys**: Include relevant parameters (symbol, date range, provider) in cache keys
|
||||
- **Versioned Keys**: Incorporate data schema version to handle model changes
|
||||
|
||||
### 3. Cache Invalidation
|
||||
- **Time-Based Expiration**: Automatic expiration based on TTL settings
|
||||
- **Event-Driven Invalidation**: Clear cache entries when underlying data sources are updated
|
||||
- **Manual Invalidation**: API endpoints for cache management
|
||||
|
||||
## Load Balancing Mechanism
|
||||
|
||||
### 1. Provider Selection Algorithm
|
||||
- **Priority-Based Routing**: Route requests to providers based on configured priorities
|
||||
- **Health-Based Routing**: Consider provider health metrics when selecting providers
|
||||
- **Round-Robin for Equal Priority**: Distribute load among providers with the same priority
|
||||
|
||||
### 2. Adaptive Load Distribution
|
||||
- **Real-Time Monitoring**: Track response times and error rates for each provider
|
||||
- **Dynamic Weight Adjustment**: Adjust provider weights based on performance metrics
|
||||
- **Circuit Breaker Pattern**: Temporarily disable poorly performing providers
|
||||
|
||||
## Resource Management
|
||||
|
||||
### 1. Connection Pooling
|
||||
- **HTTP Connection Reuse**: Maintain pools of HTTP connections for API clients
|
||||
- **Database Connection Pooling**: Reuse database connections for cache backends
|
||||
- **Provider-Specific Pools**: Separate connection pools for different data providers
|
||||
|
||||
### 2. Memory Management
|
||||
- **Efficient Data Structures**: Use memory-efficient data structures for caching
|
||||
- **Object Reuse**: Reuse objects where possible to reduce garbage collection pressure
|
||||
- **Streaming Data Processing**: Process large datasets in chunks to minimize memory footprint
|
||||
|
||||
### 3. Thread and Process Management
|
||||
- **Async-Appropriate Threading**: Use threads for I/O-bound operations that aren't natively async
|
||||
- **Process Isolation**: Isolate resource-intensive operations in separate processes
|
||||
- **Resource Limits**: Configure limits on concurrent threads and processes
|
||||
|
||||
## Monitoring and Performance Metrics
|
||||
|
||||
### 1. Key Performance Indicators
|
||||
- **Response Time**: Measure latency for data retrieval operations
|
||||
- **Throughput**: Track requests per second for different data types
|
||||
- **Error Rate**: Monitor failure rates for data access operations
|
||||
- **Cache Hit Ratio**: Measure effectiveness of caching strategies
|
||||
|
||||
### 2. Provider Performance Metrics
|
||||
- **Individual Provider Metrics**: Track performance for each data provider
|
||||
- **Health Status**: Monitor uptime and responsiveness of providers
|
||||
- **Cost Metrics**: Track usage and costs associated with different providers
|
||||
|
||||
### 3. System-Level Metrics
|
||||
- **Resource Utilization**: CPU, memory, and network usage
|
||||
- **Concurrency Levels**: Track active requests and queue depths
|
||||
- **Garbage Collection**: Monitor GC activity and its impact on performance
|
||||
|
||||
## Optimization Techniques
|
||||
|
||||
### 1. Data Pre-fetching
|
||||
- **Predictive Loading**: Pre-fetch data for likely subsequent requests
|
||||
- **Batch Operations**: Combine multiple requests into single batch operations where possible
|
||||
- **Background Refresh**: Refresh cached data proactively before expiration
|
||||
|
||||
### 2. Data Compression
|
||||
- **Response Compression**: Use gzip compression for API responses
|
||||
- **Cache Compression**: Compress cached data to reduce memory usage
|
||||
- **Efficient Serialization**: Use efficient serialization formats (e.g., Protocol Buffers, MessagePack)
|
||||
|
||||
### 3. Database Optimization
|
||||
- **Indexing Strategy**: Create appropriate indexes for cache lookup operations
|
||||
- **Query Optimization**: Optimize database queries for performance
|
||||
- **Connection Management**: Efficiently manage database connections
|
||||
|
||||
## Scalability Considerations
|
||||
|
||||
### 1. Horizontal Scaling
|
||||
- **Stateless Design**: Ensure data access components are stateless for easy scaling
|
||||
- **Load Balancer Integration**: Work with external load balancers for traffic distribution
|
||||
- **Shared Caching**: Use distributed cache for consistent data across instances
|
||||
|
||||
### 2. Vertical Scaling
|
||||
- **Resource Allocation**: Optimize resource usage for efficient vertical scaling
|
||||
- **Performance Tuning**: Tune system parameters for better performance on larger instances
|
||||
- **Memory Management**: Efficiently manage memory to take advantage of larger instances
|
||||
|
||||
### 3. Auto-scaling
|
||||
- **Metrics-Driven Scaling**: Use performance metrics to trigger auto-scaling events
|
||||
- **Graceful Degradation**: Maintain functionality during scaling operations
|
||||
- **Cost Optimization**: Balance performance with cost considerations
|
||||
|
||||
## Implementation Roadmap
|
||||
|
||||
### Phase 1: Core Async Implementation
|
||||
- Implement `DataAbstractionLayer.get_quote_async()`
|
||||
- Add async support to provider adapters where possible
|
||||
- Add executor-based fallback for synchronous providers
|
||||
|
||||
### Phase 2: Caching Layer
|
||||
- Implement in-memory LRU cache
|
||||
- Add cache key design and invalidation strategies
|
||||
- Integrate cache with data abstraction layer
|
||||
|
||||
### Phase 3: Monitoring and Metrics
|
||||
- Implement data quality monitoring
|
||||
- Add performance metrics collection
|
||||
- Create dashboards for monitoring key metrics
|
||||
|
||||
### Phase 4: Advanced Optimizations
|
||||
- Implement predictive pre-fetching
|
||||
- Add database optimization for cache backends
|
||||
- Implement distributed caching for scalability
|
||||
|
||||
## Conclusion
|
||||
|
||||
This performance optimization architecture provides a comprehensive approach to ensuring the OpenBB integration in the Lianyaohu system can handle high concurrency while maintaining optimal performance. By implementing asynchronous data access, multi-level caching, intelligent load balancing, and comprehensive monitoring, the system will be able to deliver fast, reliable financial data to the eight immortal agents even under heavy load.
|
||||
130
docs/architecture/technical_specification.md
Normal file
130
docs/architecture/technical_specification.md
Normal file
@@ -0,0 +1,130 @@
|
||||
# 炼妖壶-稷下学宫AI辩论系统 OpenBB集成文档整合
|
||||
|
||||
## 概述
|
||||
|
||||
本文档整合了"炼妖壶-稷下学宫AI辩论系统"中OpenBB集成的所有关键设计和实现文档,为开发团队提供一个全面的参考指南。
|
||||
|
||||
## 架构设计
|
||||
|
||||
### 1. 整体架构
|
||||
系统采用分层架构设计,将OpenBB集成在数据访问层,通过抽象层为上层应用提供统一的数据接口。
|
||||
|
||||
### 2. 核心组件
|
||||
- **OpenBB引擎** (`src/jixia/engines/openbb_engine.py`):主要的数据访问接口
|
||||
- **数据抽象层** (`src/jixia/engines/data_abstraction_layer.py`):统一的数据访问接口
|
||||
- **Provider适配器**:为不同数据源实现的适配器
|
||||
- **数据模型** (`src/jixia/models/financial_data_models.py`):标准化的数据结构定义
|
||||
|
||||
### 3. 数据流
|
||||
```
|
||||
[八仙智能体] -> [数据抽象层] -> [Provider适配器] -> [OpenBB引擎] -> [OpenBB库]
|
||||
\-> [永动机引擎] -> [RapidAPI]
|
||||
```
|
||||
|
||||
## 实现细节
|
||||
|
||||
### 1. 数据模型
|
||||
定义了标准化的金融数据结构:
|
||||
- `StockQuote`:股票报价
|
||||
- `HistoricalPrice`:历史价格数据
|
||||
- `CompanyProfile`:公司概况
|
||||
- `FinancialNews`:金融新闻
|
||||
|
||||
### 2. 抽象接口
|
||||
定义了`DataProvider`抽象基类,所有数据提供商都需要实现该接口:
|
||||
- `get_quote()`:获取股票报价
|
||||
- `get_historical_prices()`:获取历史价格数据
|
||||
- `get_company_profile()`:获取公司概况
|
||||
- `get_news()`:获取相关新闻
|
||||
|
||||
### 3. Provider适配器
|
||||
为OpenBB和RapidAPI分别实现了适配器:
|
||||
- `OpenBBDataProvider`:OpenBB数据提供商适配器
|
||||
- `RapidAPIDataProvider`:RapidAPI数据提供商适配器
|
||||
|
||||
### 4. 八仙数据映射
|
||||
定义了八仙与数据源的智能映射关系,每个八仙都有其专属的数据源和类型偏好。
|
||||
|
||||
## 性能优化
|
||||
|
||||
### 1. 异步处理
|
||||
实现了异步数据访问机制,提高系统并发处理能力。
|
||||
|
||||
### 2. 缓存策略
|
||||
采用多级缓存策略,包括内存LRU缓存和未来可扩展的分布式缓存。
|
||||
|
||||
### 3. 负载均衡
|
||||
实现了基于优先级和健康状态的数据源选择算法。
|
||||
|
||||
## 测试验证
|
||||
|
||||
### 1. 功能测试
|
||||
- Provider适配器测试
|
||||
- 数据抽象层测试
|
||||
- 引擎组件测试
|
||||
- UI组件测试
|
||||
- 集成测试
|
||||
|
||||
### 2. 性能测试
|
||||
- 响应时间测试
|
||||
- 并发访问测试
|
||||
|
||||
### 3. 验证标准
|
||||
- 功能验证标准
|
||||
- 性能验证标准
|
||||
- 兼容性验证标准
|
||||
|
||||
## 部署架构
|
||||
|
||||
### 1. 环境要求
|
||||
- Python 3.8+
|
||||
- 可选的OpenBB库 (>=4.1.0)
|
||||
|
||||
### 2. 配置管理
|
||||
- 通过环境变量管理配置
|
||||
- 支持多种部署场景(基础部署、完整部署、混合部署)
|
||||
|
||||
### 3. 安全考虑
|
||||
- API密钥安全管理
|
||||
- 数据安全处理
|
||||
- 访问控制
|
||||
|
||||
## 故障处理与降级
|
||||
|
||||
### 1. 故障转移机制
|
||||
当主数据源不可用时,系统能自动切换到备用数据源。
|
||||
|
||||
### 2. 优雅降级
|
||||
当OpenBB未安装时,系统能正常运行并使用演示数据。
|
||||
|
||||
## 监控与可观测性
|
||||
|
||||
### 1. 关键指标
|
||||
- 数据源可用性
|
||||
- 响应时间
|
||||
- 错误率
|
||||
- 缓存命中率
|
||||
|
||||
### 2. 告警策略
|
||||
定义了多维度的告警策略,确保系统稳定性。
|
||||
|
||||
## 未来发展规划
|
||||
|
||||
### 1. 统一数据模型
|
||||
创建更完善的标准化数据模型。
|
||||
|
||||
### 2. Provider配置
|
||||
实现动态配置数据提供商。
|
||||
|
||||
### 3. 增强UI组件
|
||||
添加更多详细的金融数据可视化和分析工具。
|
||||
|
||||
### 4. 辩论集成
|
||||
直接将辩论结果链接到OpenBB的具体数据点。
|
||||
|
||||
### 5. 高级路由
|
||||
集成OpenBB的更多数据源,如基本面数据、新闻和另类数据。
|
||||
|
||||
## 结论
|
||||
|
||||
通过以上架构设计和实现,OpenBB集成成功地为"炼妖壶-稷下学宫AI辩论系统"提供了丰富而可靠的金融数据支持,同时保持了系统的可扩展性和稳定性。这套集成方案不仅满足了当前需求,也为未来功能扩展奠定了坚实基础。
|
||||
287
docs/architecture/test_validation_plan.md
Normal file
287
docs/architecture/test_validation_plan.md
Normal file
@@ -0,0 +1,287 @@
|
||||
# 炼妖壶-稷下学宫AI辩论系统 OpenBB集成测试与验证方案
|
||||
|
||||
## 概述
|
||||
|
||||
本文档定义了"炼妖壶-稷下学宫AI辩论系统"中OpenBB集成的测试用例和验证标准,确保集成的正确性、可靠性和性能。
|
||||
|
||||
## 测试环境配置
|
||||
|
||||
### 基础环境
|
||||
- Python 3.8+
|
||||
- 系统依赖:如 requirements.txt 中定义
|
||||
- 测试框架:pytest
|
||||
|
||||
### OpenBB环境变体
|
||||
1. **未安装OpenBB**:测试降级机制
|
||||
2. **安装OpenBB但未配置提供商**:测试基本功能
|
||||
3. **完整配置OpenBB**:测试所有功能
|
||||
|
||||
## 测试用例
|
||||
|
||||
### 1. 数据抽象层测试
|
||||
|
||||
#### 1.1 Provider适配器测试
|
||||
```python
|
||||
# tests/test_provider_adapters.py
|
||||
|
||||
def test_openbb_provider_initialization():
|
||||
"""测试OpenBB提供商适配器初始化"""
|
||||
from src.jixia.engines.openbb_adapter import OpenBBDataProvider
|
||||
provider = OpenBBDataProvider()
|
||||
assert provider.name == "OpenBB"
|
||||
assert provider.priority == 1
|
||||
|
||||
def test_rapidapi_provider_initialization():
|
||||
"""测试RapidAPI提供商适配器初始化"""
|
||||
from src.jixia.engines.rapidapi_adapter import RapidAPIDataProvider
|
||||
provider = RapidAPIDataProvider()
|
||||
assert provider.name == "RapidAPI"
|
||||
assert provider.priority == 2
|
||||
|
||||
def test_provider_data_retrieval():
|
||||
"""测试提供商数据检索功能"""
|
||||
# 使用模拟数据测试各提供商的数据获取方法
|
||||
pass
|
||||
```
|
||||
|
||||
#### 1.2 数据抽象层管理器测试
|
||||
```python
|
||||
# tests/test_data_abstraction_layer.py
|
||||
|
||||
def test_dal_initialization():
|
||||
"""测试数据抽象层初始化"""
|
||||
from src.jixia.engines.data_abstraction_layer import DataAbstractionLayer
|
||||
dal = DataAbstractionLayer()
|
||||
# 验证提供商是否正确加载
|
||||
assert len(dal.providers) >= 1
|
||||
|
||||
def test_dal_quote_retrieval():
|
||||
"""测试数据抽象层报价获取"""
|
||||
from src.jixia.engines.data_abstraction_layer import DataAbstractionLayer
|
||||
dal = DataAbstractionLayer()
|
||||
quote = dal.get_quote("AAPL")
|
||||
# 验证返回数据结构
|
||||
if quote is not None:
|
||||
assert hasattr(quote, 'symbol')
|
||||
assert hasattr(quote, 'price')
|
||||
|
||||
def test_dal_fallback_mechanism():
|
||||
"""测试故障转移机制"""
|
||||
# 模拟主提供商失败,验证是否能正确切换到备用提供商
|
||||
pass
|
||||
```
|
||||
|
||||
### 2. 引擎组件测试
|
||||
|
||||
#### 2.1 OpenBB引擎测试
|
||||
```python
|
||||
# tests/test_openbb_engine.py
|
||||
|
||||
def test_openbb_engine_initialization():
|
||||
"""测试OpenBB引擎初始化"""
|
||||
from src.jixia.engines.openbb_engine import OpenBBEngine
|
||||
engine = OpenBBEngine()
|
||||
# 验证引擎是否正确初始化
|
||||
assert engine is not None
|
||||
|
||||
def test_openbb_engine_data_retrieval():
|
||||
"""测试OpenBB引擎数据获取"""
|
||||
from src.jixia.engines.openbb_engine import OpenBBEngine
|
||||
engine = OpenBBEngine()
|
||||
result = engine.get_immortal_data("吕洞宾", "price", "AAPL")
|
||||
# 验证返回结果结构
|
||||
assert hasattr(result, 'success')
|
||||
if result.success:
|
||||
assert result.data is not None
|
||||
|
||||
def test_openbb_engine_unavailable():
|
||||
"""测试OpenBB不可用时的行为"""
|
||||
# 通过模拟环境测试OpenBB未安装时的降级行为
|
||||
pass
|
||||
```
|
||||
|
||||
#### 2.2 永动机引擎测试
|
||||
```python
|
||||
# tests/test_perpetual_engine.py
|
||||
|
||||
def test_perpetual_engine_initialization():
|
||||
"""测试永动机引擎初始化"""
|
||||
from src.jixia.engines.perpetual_engine import JixiaPerpetualEngine
|
||||
# 注意:需要提供有效的RapidAPI密钥进行测试
|
||||
pass
|
||||
|
||||
def test_perpetual_engine_data_retrieval():
|
||||
"""测试永动机引擎数据获取"""
|
||||
pass
|
||||
```
|
||||
|
||||
### 3. UI组件测试
|
||||
|
||||
#### 3.1 OpenBB标签页测试
|
||||
```python
|
||||
# tests/test_openbb_tab.py
|
||||
|
||||
def test_openbb_tab_data_loading():
|
||||
"""测试OpenBB标签页数据加载"""
|
||||
# 验证在不同环境下的数据加载行为
|
||||
pass
|
||||
|
||||
def test_openbb_tab_fallback():
|
||||
"""测试OpenBB标签页降级机制"""
|
||||
# 验证当OpenBB不可用时是否正确显示演示数据
|
||||
pass
|
||||
```
|
||||
|
||||
### 4. 集成测试
|
||||
|
||||
#### 4.1 八仙智能体数据访问测试
|
||||
```python
|
||||
# tests/test_baxian_data_access.py
|
||||
|
||||
def test_immortal_data_mapping():
|
||||
"""测试八仙与数据源的映射关系"""
|
||||
from src.jixia.engines.baxian_data_mapping import immortal_data_mapping
|
||||
# 验证所有八仙都有正确的数据源映射
|
||||
assert len(immortal_data_mapping) == 8
|
||||
for immortal in ['吕洞宾', '何仙姑', '张果老', '韩湘子', '汉钟离', '蓝采和', '铁拐李', '曹国舅']:
|
||||
assert immortal in immortal_data_mapping
|
||||
|
||||
def test_immortal_data_retrieval():
|
||||
"""测试八仙智能体数据获取"""
|
||||
# 验证每个八仙都能通过数据抽象层获取到所需数据
|
||||
pass
|
||||
```
|
||||
|
||||
#### 4.2 端到端辩论流程测试
|
||||
```python
|
||||
# tests/test_debate_flow_with_openbb.py
|
||||
|
||||
def test_debate_with_openbb_data():
|
||||
"""测试使用OpenBB数据的完整辩论流程"""
|
||||
# 验证辩论系统能正确使用OpenBB提供的数据
|
||||
pass
|
||||
```
|
||||
|
||||
## 性能测试
|
||||
|
||||
### 1. 响应时间测试
|
||||
```python
|
||||
# tests/performance/test_response_time.py
|
||||
|
||||
def test_quote_retrieval_response_time():
|
||||
"""测试报价获取响应时间"""
|
||||
import time
|
||||
from src.jixia.engines.data_abstraction_layer import DataAbstractionLayer
|
||||
dal = DataAbstractionLayer()
|
||||
|
||||
start_time = time.time()
|
||||
quote = dal.get_quote("AAPL")
|
||||
end_time = time.time()
|
||||
|
||||
response_time = end_time - start_time
|
||||
# 验证响应时间在可接受范围内
|
||||
assert response_time < 2.0 # 假设2秒为阈值
|
||||
```
|
||||
|
||||
### 2. 并发访问测试
|
||||
```python
|
||||
# tests/performance/test_concurrent_access.py
|
||||
|
||||
def test_concurrent_quote_retrieval():
|
||||
"""测试并发报价获取"""
|
||||
import asyncio
|
||||
from src.jixia.engines.data_abstraction_layer import DataAbstractionLayer
|
||||
|
||||
async def get_quote(symbol):
|
||||
dal = DataAbstractionLayer()
|
||||
return await dal.get_quote_async(symbol)
|
||||
|
||||
async def get_multiple_quotes():
|
||||
symbols = ["AAPL", "GOOGL", "MSFT", "TSLA"]
|
||||
tasks = [get_quote(symbol) for symbol in symbols]
|
||||
return await asyncio.gather(*tasks)
|
||||
|
||||
# 运行并发测试
|
||||
quotes = asyncio.run(get_multiple_quotes())
|
||||
# 验证所有请求都成功返回
|
||||
assert len(quotes) == 4
|
||||
```
|
||||
|
||||
## 验证标准
|
||||
|
||||
### 功能验证标准
|
||||
1. **数据准确性**:返回的数据格式和内容符合预期
|
||||
2. **故障转移**:当主数据源不可用时,系统能自动切换到备用数据源
|
||||
3. **优雅降级**:当OpenBB未安装时,系统能正常运行并使用演示数据
|
||||
4. **八仙映射**:每个八仙都能访问其专属的数据源和类型
|
||||
|
||||
### 性能验证标准
|
||||
1. **响应时间**:单次数据请求响应时间不超过2秒
|
||||
2. **并发处理**:系统能同时处理至少10个并发数据请求
|
||||
3. **资源使用**:内存使用在合理范围内,无内存泄漏
|
||||
4. **缓存效率**:缓存命中率应达到80%以上
|
||||
|
||||
### 兼容性验证标准
|
||||
1. **Python版本**:支持Python 3.8及以上版本
|
||||
2. **OpenBB版本**:支持OpenBB v4.1.0及以上版本
|
||||
3. **环境变量**:正确处理各种环境变量配置
|
||||
4. **依赖管理**:OpenBB作为可选依赖,不影响主系统安装
|
||||
|
||||
## 持续集成/持续部署(CI/CD)集成
|
||||
|
||||
### GitHub Actions工作流
|
||||
```yaml
|
||||
# .github/workflows/openbb_integration_test.yml
|
||||
|
||||
name: OpenBB Integration Test
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [ main, develop ]
|
||||
pull_request:
|
||||
branches: [ main ]
|
||||
|
||||
jobs:
|
||||
test:
|
||||
runs-on: ubuntu-latest
|
||||
strategy:
|
||||
matrix:
|
||||
python-version: [3.8, 3.9, '3.10', '3.11']
|
||||
openbb-installed: [true, false]
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
- name: Set up Python ${{ matrix.python-version }}
|
||||
uses: actions/setup-python@v4
|
||||
with:
|
||||
python-version: ${{ matrix.python-version }}
|
||||
- name: Install dependencies
|
||||
run: |
|
||||
python -m pip install --upgrade pip
|
||||
pip install -r requirements.txt
|
||||
if [ "${{ matrix.openbb-installed }}" = "true" ]; then
|
||||
pip install "openbb>=4.1.0"
|
||||
fi
|
||||
- name: Run tests
|
||||
run: |
|
||||
pytest tests/test_openbb_*.py
|
||||
pytest tests/test_data_abstraction_*.py
|
||||
```
|
||||
|
||||
## 监控和告警
|
||||
|
||||
### 关键指标监控
|
||||
1. **数据源可用性**:监控各数据提供商的可用性
|
||||
2. **响应时间**:监控数据请求的平均响应时间
|
||||
3. **错误率**:监控数据访问的错误率
|
||||
4. **缓存命中率**:监控缓存的使用效率
|
||||
|
||||
### 告警策略
|
||||
1. **可用性告警**:当数据源可用性低于95%时触发告警
|
||||
2. **性能告警**:当平均响应时间超过阈值时触发告警
|
||||
3. **错误率告警**:当错误率超过1%时触发告警
|
||||
4. **缓存告警**:当缓存命中率低于70%时触发告警
|
||||
|
||||
## 结论
|
||||
|
||||
这套测试和验证方案确保了OpenBB集成的高质量交付,通过全面的功能测试、性能测试和持续集成,能够及时发现和修复潜在问题,保证系统的稳定性和可靠性。
|
||||
38
docs/openbb_integration/00_PROJECT_OVERVIEW.md
Normal file
38
docs/openbb_integration/00_PROJECT_OVERVIEW.md
Normal file
@@ -0,0 +1,38 @@
|
||||
# OpenBB 集成项目总览
|
||||
|
||||
本目录构建了本项目中 OpenBB v4 集成的完整文档生态,包括架构、实现、测试、用户指南、文化融合与维护。
|
||||
|
||||
## 目标
|
||||
- 以 OpenBB v4 作为统一市场数据路由入口(`from openbb import obb`)
|
||||
- 在未安装或不可用时,提供稳健的兜底策略(演示/合成数据)
|
||||
- 将集成能力与稷下学宫/八仙论道的产品体验深度融合
|
||||
|
||||
## 核心组件
|
||||
- UI:`app/tabs/openbb_tab.py`(自动检测 OpenBB 可用性,提供回退)
|
||||
- 引擎:`src/jixia/engines/openbb_engine.py`、`src/jixia/engines/openbb_stock_data.py`
|
||||
- 示例/演示数据:`examples/data/*.json`
|
||||
|
||||
## 用户旅程(摘要)
|
||||
```mermaid
|
||||
graph TD
|
||||
A[用户启动应用] --> B[选择OpenBB标签页]
|
||||
B --> C[查看数据可用性状态]
|
||||
C --> D{OpenBB是否可用?}
|
||||
D -->|是| E[选择股票符号]
|
||||
D -->|否| F[使用演示数据]
|
||||
E --> G[启动八仙论道]
|
||||
F --> G
|
||||
G --> H[查看辩论结果]
|
||||
H --> I[导出分析报告]
|
||||
```
|
||||
|
||||
## 快速链接
|
||||
- 实现指南(API 集成与回退策略):[02_IMPLEMENTATION_GUIDE/api_integration_guide.md](../openbb_integration/02_IMPLEMENTATION_GUIDE/api_integration_guide.md)
|
||||
- 故障排查:[02_IMPLEMENTATION_GUIDE/troubleshooting_guide.md](../openbb_integration/02_IMPLEMENTATION_GUIDE/troubleshooting_guide.md)
|
||||
- 测试策略与报告:[03_TEST_DOCUMENTATION/](../openbb_integration/03_TEST_DOCUMENTATION/)
|
||||
- 用户指南:[04_USER_GUIDES/](../openbb_integration/04_USER_GUIDES/)
|
||||
|
||||
## 维护与路线图
|
||||
- 版本说明与升级:见 [06_MAINTENANCE](../openbb_integration/06_MAINTENANCE/)
|
||||
|
||||
> 注:本结构与 docs/AI_AGENT_TASKS/ROVODEV_PROJECT_INTEGRATION.md 的“文档架构”保持一致,以便多团队协作与交付。
|
||||
@@ -0,0 +1,3 @@
|
||||
# 数据流设计
|
||||
|
||||
占位:将补充从 UI 输入 -> 引擎 -> OpenBB/provider -> DataFrame -> KPI/图表 的完整数据流与序列图。
|
||||
@@ -0,0 +1,7 @@
|
||||
# 部署策略
|
||||
|
||||
- OpenBB 作为可选依赖提供,默认不强制安装
|
||||
- 在需要时通过 `pip install "openbb>=4.1.0"` 启用
|
||||
- 国内网络场景建议使用镜像或代理
|
||||
|
||||
后续将补充 CI/CD、环境矩阵与缓存策略。
|
||||
@@ -0,0 +1,7 @@
|
||||
# 集成模式
|
||||
|
||||
- 路由优先:`obb.equity.price.historical`,必要时回退到 `obb.etf.price.historical`
|
||||
- 结果标准化:兼容 `.to_df()` / `.to_dataframe()` / 原始对象 -> DataFrame
|
||||
- 列规范化:Date / Close 归一化,保证后续图表与 KPI 计算稳定
|
||||
|
||||
后续将补充更多模式(基本面/新闻/宏观等)。
|
||||
@@ -0,0 +1,17 @@
|
||||
# 系统架构(Qwen 输出)
|
||||
|
||||
本章描述 OpenBB 集成在系统中的位置、边界与依赖。
|
||||
|
||||
## 组件边界
|
||||
- UI 层:`app/tabs/openbb_tab.py`
|
||||
- 引擎层:`src/jixia/engines/openbb_engine.py`、`openbb_stock_data.py`
|
||||
- 数据层:OpenBB provider(yfinance、polygon、fmp 等)与演示/合成数据
|
||||
|
||||
## 关键架构决策
|
||||
- 使用 OpenBB v4 统一路由
|
||||
- 延迟导入(lazy import)降低对未安装环境的侵入
|
||||
- 明确回退机制,保证用户体验连续性
|
||||
|
||||
## 后续补充
|
||||
- 数据流与上下行依赖
|
||||
- 与“八仙论道”系统的耦合点与解耦方案
|
||||
@@ -1,6 +1,6 @@
|
||||
# OpenBB 集成指南
|
||||
# OpenBB 集成指南(迁移版)
|
||||
|
||||
本指南帮助你在本项目中启用并使用 OpenBB v4 作为市场数据源,同时保证在未安装 OpenBB 的情况下,应用可平稳回退到演示/合成数据。
|
||||
本页介绍 OpenBB v4 在本项目中的安装、配置、代码结构、回退机制、开发与测试、典型问题与后续计划。
|
||||
|
||||
## 1. 为什么选择 OpenBB v4
|
||||
- 统一的路由接口:`from openbb import obb`
|
||||
@@ -0,0 +1,10 @@
|
||||
# 核心引擎实现(Claude 输出)
|
||||
|
||||
- 延迟导入 OpenBB
|
||||
- 统一结果转 DataFrame
|
||||
- 列/索引规范化与时间窗口裁剪
|
||||
- 失败时不影响其他功能(返回 success=False 或进入兜底路径)
|
||||
|
||||
参考代码位置:
|
||||
- `src/jixia/engines/openbb_engine.py`
|
||||
- `src/jixia/engines/openbb_stock_data.py`
|
||||
@@ -0,0 +1,8 @@
|
||||
# 故障排查指南
|
||||
|
||||
常见问题与解决方案:
|
||||
- ImportError: No module named 'openbb' → 安装 `openbb>=4.1.0`
|
||||
- 返回空数据 → 检查 symbol,尝试其他 provider 或缩短时间窗口
|
||||
- 列名/索引不匹配 → 打印原始 DataFrame,参考 UI 中的规范化逻辑
|
||||
|
||||
更多请参考:[api_integration_guide.md](./api_integration_guide.md) 第 7 节。
|
||||
@@ -0,0 +1,6 @@
|
||||
# UI 增强指南
|
||||
|
||||
- 状态提示(OpenBB 可用/不可用)
|
||||
- 动态参数(symbol、时间窗口)
|
||||
- KPI 卡片(最新价、近30日涨幅、最大回撤)
|
||||
- 未来扩展位:基本面、新闻、情绪、宏观等
|
||||
@@ -0,0 +1,3 @@
|
||||
# 性能基准
|
||||
|
||||
占位:记录不同 provider 与窗口设置下的响应时间、吞吐、内存曲线。
|
||||
@@ -0,0 +1,6 @@
|
||||
# 质量保证报告
|
||||
|
||||
- 代码规范检查
|
||||
- 文档完整性
|
||||
- 测试通过率
|
||||
- 文化准确性与用户体验评估(与 05_CULTURAL_INTEGRATION 联动)
|
||||
@@ -0,0 +1,3 @@
|
||||
# 测试结果报告
|
||||
|
||||
占位:记录关键用例、环境、通过率与截图/日志摘要。
|
||||
@@ -0,0 +1,6 @@
|
||||
# 测试策略(Gemini 输出)
|
||||
|
||||
- 未安装 OpenBB:UI 能回退到演示/合成数据
|
||||
- 已安装 OpenBB:能成功调用 `obb.equity.price.historical`
|
||||
- 数据清洗后具有 Date/Close 列,KPI 计算不报错
|
||||
- 覆盖边界:空数据、异常路由、索引为日期等
|
||||
6
docs/openbb_integration/04_USER_GUIDES/best_practices.md
Normal file
6
docs/openbb_integration/04_USER_GUIDES/best_practices.md
Normal file
@@ -0,0 +1,6 @@
|
||||
# 最佳实践
|
||||
|
||||
- 将 OpenBB 作为轻依赖,必要时再安装
|
||||
- 使用统一的 DataFrame 规范化逻辑
|
||||
- 谨慎处理长时间窗口与缺失数据
|
||||
- 提供清晰的状态反馈与兜底
|
||||
@@ -0,0 +1,5 @@
|
||||
# 配置指南
|
||||
|
||||
- 默认使用公共数据(yfinance)
|
||||
- 付费 provider(polygon/fmp 等)可通过 OpenBB provider 配置或环境变量设置
|
||||
- UI 参数:symbol、时间窗口、KPI 展示
|
||||
@@ -0,0 +1,8 @@
|
||||
# 入门指南
|
||||
|
||||
1) 可选安装:`pip install "openbb>=4.1.0"`
|
||||
2) 运行应用,进入 OpenBB 标签页
|
||||
3) 输入股票/ETF 代码(如 AAPL),选择时间窗口
|
||||
4) 若未安装 OpenBB,将自动使用演示数据
|
||||
|
||||
更多:见 [API 实现指南](../02_IMPLEMENTATION_GUIDE/api_integration_guide.md)。
|
||||
@@ -0,0 +1,3 @@
|
||||
# 八仙论道教程(占位)
|
||||
|
||||
将补充如何基于市场数据触发与解读“八仙论道”的步骤与最佳实践。
|
||||
@@ -0,0 +1,3 @@
|
||||
# 文化准确性指南(占位)
|
||||
|
||||
将补充文化审核检查点、示例与注意事项。
|
||||
@@ -0,0 +1,3 @@
|
||||
# 八仙特质(占位)
|
||||
|
||||
将列举八仙角色特性,并映射到数据分析风格/观点生成策略。
|
||||
@@ -0,0 +1,4 @@
|
||||
# 稷下学宫哲学在代码中的体现(占位)
|
||||
|
||||
- 开放包容、百家争鸣 → 多 provider 聚合与辩论系统
|
||||
- 求同存异、理性决策 → 数据驱动 + 观点对齐
|
||||
5
docs/openbb_integration/06_MAINTENANCE/future_roadmap.md
Normal file
5
docs/openbb_integration/06_MAINTENANCE/future_roadmap.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# 路线图
|
||||
|
||||
- v1.x:路由扩展、稳定性增强
|
||||
- v2.x:高级分析与移动端适配
|
||||
- v3.x:企业级能力与治理
|
||||
4
docs/openbb_integration/06_MAINTENANCE/known_issues.md
Normal file
4
docs/openbb_integration/06_MAINTENANCE/known_issues.md
Normal file
@@ -0,0 +1,4 @@
|
||||
# 已知问题
|
||||
|
||||
- 某些 symbol 在特定 provider 下返回为空或字段不齐
|
||||
- 长窗口数据清洗后为空的边界情况
|
||||
4
docs/openbb_integration/06_MAINTENANCE/release_notes.md
Normal file
4
docs/openbb_integration/06_MAINTENANCE/release_notes.md
Normal file
@@ -0,0 +1,4 @@
|
||||
# 发布说明
|
||||
|
||||
- 参考:`docs/development/RELEASE_v2.0.0.md`
|
||||
- 在此记录 OpenBB 集成相关的变更、修复与新增功能。
|
||||
5
docs/openbb_integration/06_MAINTENANCE/upgrade_guide.md
Normal file
5
docs/openbb_integration/06_MAINTENANCE/upgrade_guide.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# 升级指南
|
||||
|
||||
- OpenBB 版本升级注意事项
|
||||
- provider 配置兼容性
|
||||
- 本项目接口变化记录
|
||||
36
docs/openbb_integration/README.md
Normal file
36
docs/openbb_integration/README.md
Normal file
@@ -0,0 +1,36 @@
|
||||
# OpenBB 集成文档索引
|
||||
|
||||
本目录提供 OpenBB v4 在本项目中的完整集成文档。
|
||||
|
||||
- 00 项目总览:./00_PROJECT_OVERVIEW.md
|
||||
- 01 架构设计(Qwen 输出):
|
||||
- ./01_ARCHITECTURE_DESIGN/system_architecture.md
|
||||
- ./01_ARCHITECTURE_DESIGN/data_flow_design.md
|
||||
- ./01_ARCHITECTURE_DESIGN/integration_patterns.md
|
||||
- ./01_ARCHITECTURE_DESIGN/deployment_strategy.md
|
||||
- 02 实现指南(Claude 输出):
|
||||
- ./02_IMPLEMENTATION_GUIDE/core_engine_implementation.md
|
||||
- ./02_IMPLEMENTATION_GUIDE/api_integration_guide.md
|
||||
- ./02_IMPLEMENTATION_GUIDE/ui_enhancement_guide.md
|
||||
- ./02_IMPLEMENTATION_GUIDE/troubleshooting_guide.md
|
||||
- 03 测试文档(Gemini 输出):
|
||||
- ./03_TEST_DOCUMENTATION/test_strategy.md
|
||||
- ./03_TEST_DOCUMENTATION/test_results_report.md
|
||||
- ./03_TEST_DOCUMENTATION/performance_benchmarks.md
|
||||
- ./03_TEST_DOCUMENTATION/quality_assurance_report.md
|
||||
- 04 用户指南:
|
||||
- ./04_USER_GUIDES/getting_started.md
|
||||
- ./04_USER_GUIDES/immortal_debate_tutorial.md
|
||||
- ./04_USER_GUIDES/configuration_guide.md
|
||||
- ./04_USER_GUIDES/best_practices.md
|
||||
- 05 文化融合文档:
|
||||
- ./05_CULTURAL_INTEGRATION/immortal_characteristics.md
|
||||
- ./05_CULTURAL_INTEGRATION/jixia_philosophy_in_code.md
|
||||
- ./05_CULTURAL_INTEGRATION/cultural_accuracy_guidelines.md
|
||||
- 06 维护:
|
||||
- ./06_MAINTENANCE/release_notes.md
|
||||
- ./06_MAINTENANCE/upgrade_guide.md
|
||||
- ./06_MAINTENANCE/known_issues.md
|
||||
- ./06_MAINTENANCE/future_roadmap.md
|
||||
|
||||
快速入口:API 实现指南 → ./02_IMPLEMENTATION_GUIDE/api_integration_guide.md
|
||||
Reference in New Issue
Block a user