ben/liurenchaxin
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

🏗️ 项目重构：模块化清理完成

Browse Source
This commit is contained in:
llama-research
2025-09-01 12:29:27 +00:00
parent ef7657101a
commit f9856c31e5
349 changed files with 41438 additions and 254 deletions
Download Patch File Download Diff File Expand all files Collapse all files

100
modules/documentation-suite/docs/development/CANARY_DEV_BETA_DEPLOYMENT.md Normal file
View File

@@ -0,0 +1,100 @@
# 金丝雀/开发/测试部署策略
## 环境命名
根据新的命名约定，三个环境重新命名为：
- **canary** (金丝雀环境): `https://gitea.tailnet-68f9.ts.net/gitea/liurenchaxin.git`
- **dev** (开发环境): `git@bitbucket.org:capitaltrain/liurenchaxin.git`
- **beta** (测试环境): `https://github.com/jingminzhang/taigongxinyi.git`
## 环境用途
- **canary (金丝雀)**: 最新功能测试，早期验证
- **dev (开发)**: 功能开发和集成测试
- **beta (测试)**: 预发布测试，用户验收
## 部署流程
### 1. 日常开发流程
```bash
# 在 canary 环境开发新功能
git checkout main
git pull canary main
# 开发完成后
git add .
git commit -m "feat: 新功能描述"
git push canary main
```
### 2. 集成测试流程
```bash
# 将功能从 canary 推送到 dev 环境
git checkout main
git pull dev main
git merge main
git push dev main
```
### 3. 预发布流程
```bash
# 将功能从 dev 推送到 beta 环境
git checkout main
git pull beta main
git merge main
git push beta main
```
## 快速命令
### 发布新版本
```bash
# 金丝雀环境发布
./scripts/quick-release.sh 1.2.3 canary
# 开发环境发布
./scripts/quick-release.sh 1.2.3 dev
# 测试环境发布
./scripts/quick-release.sh 1.2.3 beta
```
### 回滚操作
```bash
# 回滚金丝雀环境
./scripts/rollback.sh canary 1.2.2
# 回滚开发环境
./scripts/rollback.sh dev 1.2.2
# 回滚测试环境
./scripts/rollback.sh beta 1.2.2
```
### 状态检查
```bash
./scripts/check-status.sh
```
## 分支策略
- **main**: 所有环境统一使用main分支
## 标签命名
- 金丝雀: `v1.2.3-canary`
- 开发: `v1.2.3-dev`
- 测试: `v1.2.3-beta`
## 优势
1. **清晰的命名**: canary/dev/beta 更符合行业标准
2. **渐进发布**: 从金丝雀到测试的渐进式验证
3. **快速回滚**: 每个环境都可以独立回滚
4. **隔离性好**: 不同环境完全隔离，减少干扰

196
modules/documentation-suite/docs/development/DEPLOYMENT_FLOW.md Normal file
View File

@@ -0,0 +1,196 @@
# 六壬神鉴渐进发布流程图
## 🎯 发布流程概览
```
┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Development │ │ Staging │ │ Canary │ │ Production │
│ (Gitea) │───▶│ (Bitbucket) │───▶│ (GitHub 10%) │───▶│ (GitHub 100%) │
│ develop分支 │ │ staging分支 │ │ main分支 │ │ main分支 │
└─────────────────┘ └──────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │ │
│ │ │ │
▼ ▼ ▼ ▼
┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ 功能开发 │ │ 集成测试 │ │ 灰度验证 │ │ 全量发布 │
│ 单元测试 │ │ 性能测试 │ │ 监控验证 │ │ 持续监控 │
│ 代码审查 │ │ 安全扫描 │ │ 用户反馈 │ │ 性能优化 │
└─────────────────┘ └──────────────────┘ └─────────────────┘ └─────────────────┘
```
## 🚀 快速操作指南
### 1. 日常开发流程
#### 开始新功能开发
```bash
# 从 develop 分支创建功能分支
git checkout develop
git pull origin develop
git checkout -b feature/new-feature
# 开发完成后
git add .
git commit -m "feat: 添加新功能"
git push origin feature/new-feature
# 创建 PR 到 develop 分支
# 在 Gitea 上创建 Pull Request
```
#### 推送到开发环境
```bash
# 一键推送到 Gitea 开发环境
git checkout develop
git pull origin develop
git merge feature/new-feature
git push gitea develop
```
### 2. 预发布流程
#### 准备 staging 发布
```bash
# 创建发布分支
git checkout staging
git merge develop
git push staging staging:main
# 或使用快捷命令
git deploy-staging
```
#### 验证 staging 环境
```bash
# 检查 staging 状态
./scripts/check-status.sh
```
### 3. 灰度发布流程
#### 启动灰度发布
```bash
# 创建灰度版本
git checkout main
git merge staging
git tag v1.2.0-canary
git push origin main --tags
```
#### 监控灰度状态
```bash
# 检查发布状态
curl -s https://api.github.com/repos/jingminzhang/taigongxinyi/releases/latest
```
### 4. 全量发布流程
#### 正式版本发布
```bash
# 使用快速发布脚本
./scripts/quick-release.sh 1.2.0 prod
# 或手动操作
git checkout main
git tag v1.2.0
git push origin main --tags
git deploy-prod
```
## 📊 发布检查清单
### 开发阶段检查
- [ ] 代码通过单元测试
- [ ] 功能测试完成
- [ ] 代码审查通过
- [ ] 文档已更新
### Staging 阶段检查
- [ ] 集成测试通过
- [ ] 性能测试完成
- [ ] 安全扫描通过
- [ ] 用户验收测试完成
### 灰度发布检查
- [ ] 监控指标正常
- [ ] 错误率 < 0.1%
- [ ] 用户反馈良好
- [ ] 业务指标稳定
### 全量发布检查
- [ ] 灰度验证通过
- [ ] 回滚方案就绪
- [ ] 监控告警配置
- [ ] 紧急联系清单
## 🔄 回滚操作
### 紧急回滚
```bash
# 快速回滚到指定版本
./scripts/rollback.sh prod 1.1.9
# 或手动回滚
git checkout v1.1.9
git tag v1.2.0-rollback
git push origin main --force
```
### 回滚验证
```bash
# 检查回滚状态
./scripts/check-status.sh
```
## 📈 监控面板
### 关键指标监控
- **系统性能**: CPU、内存、磁盘使用率
- **应用性能**: 响应时间、吞吐量、错误率
- **业务指标**: 用户活跃度、功能使用率
### 告警规则
- 错误率 > 1% → 立即告警
- 响应时间 > 1s → 立即告警
- 服务不可用 → 立即告警
## 🛠️ 工具命令速查
| 操作 | 命令 | 说明 |
|------|------|------|
| 查看状态 | `./scripts/check-status.sh` | 检查所有环境状态 |
| 快速发布 | `./scripts/quick-release.sh 版本号 环境` | 一键发布到指定环境 |
| 紧急回滚 | `./scripts/rollback.sh 环境 版本号` | 快速回滚到指定版本 |
| 推送到 staging | `git deploy-staging` | 推送到 Bitbucket staging |
| 推送到 prod | `git deploy-prod` | 推送到 GitHub production |
| 同步所有远程 | `git sync-all` | 同步所有远程仓库 |
## 📞 紧急联系
| 角色 | 联系方式 | 职责 |
|------|----------|------|
| 技术负责人 | ben@capitaltrain.cn | 技术决策、紧急响应 |
| 运维团队 | ops@capitaltrain.cn | 部署、监控、故障处理 |
| 产品团队 | product@capitaltrain.cn | 业务决策、用户沟通 |
## 🎓 最佳实践
### 1. 分支管理
- 功能分支从 `develop` 创建
- 发布分支从 `staging` 创建
- 热修复分支从 `main` 创建
### 2. 版本命名
- 主版本: 不兼容的重大更新
- 次版本: 向后兼容的功能添加
- 修订版本: bug修复和微小改进
### 3. 发布频率
- 紧急修复: 随时发布
- 常规更新: 每2周一次
- 大版本更新: 每季度一次
### 4. 监控策略
- 灰度期间: 24-48小时密切监控
- 全量发布: 72小时持续监控
- 日常运维: 实时告警监控

114
modules/documentation-suite/docs/development/GAMEFI_FSM_INTEGRATION_PLAN.md Normal file
View File

@@ -0,0 +1,114 @@
# 方案：GameFi“盘下特征”量化及FSM状态转移集成
**制定者:** Gemini
**日期:** 2025-08-21
**目标:** 将`GAMEFI_SYSTEM_SUMMARY.md`中定义的“交易者心境”和“十二长生”（四季轮回）概念，转化为可量化的数据模型，并将其作为“太公心易”FSM系统状态转移的核心驱动条件。
---
## 1. 核心思想
交易者的心境、经验和偏见是驱动其市场行为的“盘下特征”。通过量化这些特征，我们可以让主FSM的决策更具个性化和前瞻性。当检测到交易者进入特定的心理阶段（如“秋季失道”）或表现出强烈的偏见（如“趋势醉”）时，FSM可以主动进入相应状态（如`Refine`或`Validation`）进行干预和辅助。
## 2. “盘下特征”量化方案
我们将构建一个**“交易者状态向量”（Trader State Vector, TSV）**来统一描述交易者的当前心境。该向量由以下三组量化指标构成：
### 2.1. **伤疤资本 (Scar Capital)** - 经验与教训的量化
基于`TradingScar`概念，我们将从交易历史中计算以下指标：
* **总痛苦值 (TotalPain):** 所有`TradingScar`的`pain_level`之和。反映交易者经历的总挫折。
* **平均智慧 (AverageWisdom):** 所有`wisdom_gained`的平均值。反映交易者从错误中学习的能力。
* **伤疤密度 (ScarDensity):** 单位时间（如每季度）内产生的`TradingScar`数量。高密度可能意味着鲁莽或市场环境恶化。
* **恢复能力 (Resilience):** 从重大亏损（高`pain_level`的`Scar`）后，恢复盈利所需的时间。
### 2.2. **偏见画像 (Bias Profile)** - “醉八仙”的量化
通过分析交易行为，为每个交易者生成一个包含八种偏见得分（0到1之间）的画像：
* **趋势醉 (蓝采和):** 在价格接近阶段性高点时买入的频率和资金比例。
* **价值醉 (汉钟离):** 在亏损头寸上持续加仓（“补仓”）的行为频率。
* **消息醉 (曹国舅):** 在重大新闻或财报发布窗口期内，交易频率显著上升。
* **经验醉 (张果老):** 策略的同质性过高，例如只交易特定几只股票或只使用单一指标。
* **技术醉 (韩湘子):** 交易行为与特定技术指标（如MACD金叉/死叉）的强相关性。
* **保守醉 (何仙姑):** 空仓时间占比过高，或在明显上涨趋势中过早卖出。
* **逆向醉 (铁拐李):** 在市场普遍下跌时买入，或在普遍上涨时卖出的频率。
* **理性醉 (吕洞宾):** 交易频率极低，可能错失过多机会（机会成本）。
### 2.3. **修仙阶段 (Journey Stage)** - “猴王四季”的量化
结合**伤疤资本**和**偏见画像**，我们可以为交易者划分出当前的“修仙”阶段：
* **春季·觉醒 (Awakening):**
* `TotalPain`较低，`ScarDensity`较低。
* `AverageWisdom`较高（学习意愿强）。
* 偏见画像尚未固化。
* **夏季·得道 (Attainment):**
* 交易胜率高，账户稳定增长。
* `AverageWisdom`可能开始下降（过度自信）。
* 某几种偏见得分开始显著升高。
* **秋季·失道 (Loss):**
* 出现一次或多次高`pain_level`的`Scar`。
* `TotalPain`急剧上升，`Resilience`指标被考验。
* 高偏见得分与重大亏损有强相关性。
* **冬季·悟道 (Enlightenment):**
* `Resilience`高，能够从亏损中快速恢复。
* 整体偏见画像得分较低且均衡。
* `AverageWisdom`稳定在较高水平。
## 3. FSM状态转移集成方案
“交易者状态向量”（TSV）将被整合到“太公心易”FSM的上下文中，作为状态转移的核心判断依据。
### 3.1. 触发条件示例
FSM不再仅仅响应外部市场事件，更会主动响应交易者的内在状态变化。
* **进入`Refine`状态（太上老君整理）:**
* **触发器:** 检测到交易者进入“秋季·失道”阶段。
* **条件:** `IF trader.stage == 'Loss' AND trader.bias_profile['TrendChasing'] > 0.8`
* **目的:** 交易者因强烈的趋势偏见而遭受重创，FSM需要启动`Refine`流程，帮助其“祛魅”并重构策略。
* **进入`Validation`状态（内部验证/祛魅）:**
* **触发器:** 交易者处于“夏季·得道”阶段，表现出过度自信。
* **条件:** `IF trader.stage == 'Attainment' AND trader.AverageWisdom < threshold`
* **目的:** 在交易者最容易忽视风险时，FSM主动进入`Validation`状态，对其当前的策略进行压力测试和一致性检查。
* **进入`ExternalFetch`状态（灵宝道君核查）:**
* **触发器:** “消息醉”交易者准备进行一笔交易。
* **条件:** `IF trader.bias_profile['NewsTrading'] > 0.7 AND event == 'pre_trade_check'`
* **目的:** 在该交易者依据消息行动前，FSM强制启动`ExternalFetch`，从多个独立信源交叉验证该消息的可靠性。
### 3.2. 状态转移逻辑 (伪代码)
```python
class EnhancedTaigongFSM:
def __init__(self, trader_state_vector):
self.tsv = trader_state_vector
# ... other FSM initializations
def determine_next_state(self, market_event):
# 优先处理由交易者内在状态触发的转移
if self.tsv.stage == 'Loss':
# 如果交易者遭受重创，无论市场如何，优先帮助其反思
return FSMState.REFINE
if self.tsv.is_overconfident():
# 如果交易者过度自信，主动进行风险检查
return FSMState.VALIDATION
# ... 再处理由外部市场事件触发的转移
if market_event == 'HighVolatility':
return FSMState.COLLECTING
return self.current_state
```
## 4. 实施步骤
1. **数据建模:** 在代码中定义`TradingScar`, `BiasProfile`, 和 `TraderStateVector`的类结构。
2. **分析模块开发:** 创建一个分析器，能够接收交易历史数据，并计算出完整的TSV。
3. **FSM上下文集成:** 将TSV对象添加到`TaigongXinyiFSM`的上下文中。
4. **规则引擎实现:** 在FSM的`transition`逻辑中，实现基于TSV的动态状态转移规则。
5. **模拟与回测:** 构建一个模拟环境，使用历史交易数据回测该集成系统的有效性，验证其是否能在关键时刻做出正确的状态转移。

225
modules/documentation-suite/docs/development/GRADUAL_DEPLOYMENT_PLAN.md Normal file
View File

@@ -0,0 +1,225 @@
# 六壬神鉴渐进发布计划
## 概述
本计划基于当前的多环境 Git 配置，实现从开发到生产的渐进式发布流程。
## 环境架构
### 当前配置
- **GitHub** (production): `https://github.com/jingminzhang/taigongxinyi.git`
- **Bitbucket** (staging): `git@bitbucket.org:capitaltrain/liurenchaxin.git`
- **Gitea** (development): `https://gitea.tailnet-68f9.ts.net/gitea/liurenchaxin.git`
### 分支策略
```
main (生产环境)
├── staging (预发布环境)
├── develop (开发环境)
└── feature/* (功能分支)
```
## 渐进发布阶段
### 阶段1：功能开发 (Development)
**目标环境**: Gitea (development)
**分支**: `feature/*` → `develop`
#### 流程
1. 从 `develop` 分支创建功能分支
2. 在功能分支上进行开发
3. 完成功能后合并到 `develop`
4. 推送到 Gitea 进行初步测试
#### 验证清单
- [ ] 单元测试通过
- [ ] 代码审查完成
- [ ] 功能测试通过
- [ ] 文档更新完成
### 阶段2：集成测试 (Staging)
**目标环境**: Bitbucket (staging)
**分支**: `develop` → `staging`
#### 流程
1. 从 `develop` 分支创建发布分支 `release/vX.Y.Z`
2. 在 staging 环境部署测试
3. 进行集成测试和用户验收测试
4. 修复发现的问题
5. 合并到 `staging` 分支
6. 推送到 Bitbucket staging 环境
#### 验证清单
- [ ] 集成测试通过
- [ ] 性能测试通过
- [ ] 安全扫描通过
- [ ] 用户验收测试完成
- [ ] 回滚方案准备就绪
### 阶段3：灰度发布 (Canary)
**目标环境**: GitHub production (10%流量)
**分支**: `staging` → `main`
#### 流程
1. 创建灰度发布标签 `vX.Y.Z-canary`
2. 部署到生产环境 10% 流量
3. 监控关键指标 24-48小时
4. 根据监控结果决定全量发布或回滚
#### 监控指标
- [ ] 错误率 < 0.1%
- [ ] 响应时间 < 500ms
- [ ] 用户满意度 > 95%
- [ ] 业务指标正常
### 阶段4：全量发布 (Production)
**目标环境**: GitHub production (100%流量)
**分支**: `main`
#### 流程
1. 创建正式版本标签 `vX.Y.Z`
2. 全量部署到生产环境
3. 持续监控 72小时
4. 准备热修复方案
## 发布策略
### 版本命名规范
- **主版本** (X.0.0): 重大功能更新或不兼容变更
- **次版本** (X.Y.0): 新功能添加，向后兼容
- **修订版本** (X.Y.Z): bug修复或小改进
### 发布频率
- **紧急修复**: 随时发布
- **常规更新**: 每2周一次
- **大版本更新**: 每季度一次
### 回滚策略
```bash
# 快速回滚到上一个版本
git revert HEAD
git push origin main --force
# 或使用标签回滚
git checkout vX.Y.Z-1
git tag -a vX.Y.Z-rollback -m "Rollback to vX.Y.Z-1"
git push origin vX.Y.Z-rollback
```
## 自动化工具
### Git 钩子配置
在 `.git/hooks/` 目录下创建以下钩子：
#### pre-push
```bash
#!/bin/bash
# 检查测试是否通过
pytest tests/
if [ $? -ne 0 ]; then
echo "测试未通过，禁止推送"
exit 1
fi
```
#### pre-commit
```bash
#!/bin/bash
# 代码格式检查
black --check .
flake8 .
```
### CI/CD 配置
创建 `.github/workflows/deploy.yml`：
```yaml
name: Gradual Deployment
on:
push:
branches: [staging, main]
release:
types: [published]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run tests
run: |
python -m pytest tests/
deploy-staging:
needs: test
if: github.ref == 'refs/heads/staging'
runs-on: ubuntu-latest
steps:
- name: Deploy to staging
run: echo "Deploying to staging..."
deploy-production:
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- name: Deploy to production
run: echo "Deploying to production..."
```
## 监控和告警
### 关键指标
- **系统指标**: CPU、内存、磁盘使用率
- **应用指标**: 响应时间、错误率、吞吐量
- **业务指标**: 用户活跃度、功能使用率
### 告警规则
- 错误率 > 1% 触发告警
- 响应时间 > 1秒 触发告警
- 服务不可用 立即告警
## 发布检查清单
### 发布前检查
- [ ] 所有测试通过
- [ ] 代码审查完成
- [ ] 文档已更新
- [ ] 数据库迁移脚本准备就绪
- [ ] 回滚方案已验证
### 发布后检查
- [ ] 服务正常启动
- [ ] 关键功能验证
- [ ] 监控数据正常
- [ ] 用户反馈收集
- [ ] 性能指标对比
## 紧急响应
### 故障处理流程
1. **发现故障** → 立即评估影响范围
2. **5分钟内** → 决定是否回滚
3. **10分钟内** → 执行回滚操作
4. **30分钟内** → 修复问题并验证
5. **1小时内** → 重新发布
### 联系方式
- 技术负责人: ben@capitaltrain.cn
- 运维团队: ops@capitaltrain.cn
- 紧急热线: [待填写]
## 持续改进
### 发布回顾
每次发布后一周内进行回顾会议：
- 分析发布过程中的问题
- 收集用户反馈
- 更新发布流程
- 优化监控指标
### 自动化改进
- 逐步增加自动化测试覆盖率
- 完善监控和告警系统
- 优化部署脚本
- 建立自动化回滚机制

136
modules/documentation-suite/docs/development/MIGRATION_STATUS.md Normal file
View File

@@ -0,0 +1,136 @@
# 稷下学宫 Google ADK 迁移状态报告
## 📊 迁移进度概览
### ✅ 已完成的任务
#### 1. 基础设施迁移
- [x] **Google ADK 安装**: 成功安装 Google ADK 1.10.0
- [x] **API 密钥配置**: 已在 Doppler 中配置 `GOOGLE_API_KEY`
- [x] **环境验证**: 基础测试通过，智能体创建成功
#### 2. 配置系统更新
- [x] **settings.py 增强**:
- 新增 `get_google_api_key()` 函数
- 新增 `get_google_genai_config()` 函数
- 更新 `validate_config()` 支持三种模式：
- `openrouter`: 纯 OpenRouter 模式
- `google_adk`: 纯 Google ADK 模式
- `hybrid`: 混合模式（当前使用）
#### 3. 测试系统建立
- [x] **基础测试**: `test_google_adk.py` - 验证 ADK 安装和配置
- [x] **智能体测试**: `adk_debate_test.py` - 八仙智能体创建测试
- [x] **论道原型**: `adk_simple_debate.py` - 智能体基础功能验证
#### 4. 文档更新
- [x] **README.md**: 新增 Google ADK 安装和配置说明
- [x] **requirements.txt**: 添加 Google ADK 依赖说明
- [x] **迁移指南**: 完整的 `GOOGLE_ADK_MIGRATION_GUIDE.md`
### 🔄 当前状态
#### 配置模式
- **当前模式**: `hybrid` (混合模式)
- **可用服务**: OpenRouter + Google ADK
- **API 密钥状态**:
- ✅ GOOGLE_API_KEY: 已配置 (39字符)
- ✅ OPENROUTER_API_KEY_1: 已配置
- ✅ RAPIDAPI_KEY: 已配置
#### 智能体状态
- **八仙智能体**: 已成功创建
- 铁拐李 (逆向思维专家)
- 汉钟离 (平衡协调者)
- 张果老 (历史智慧者)
- 蓝采和 (创新思维者)
- 何仙姑 (直觉洞察者)
- 吕洞宾 (理性分析者)
- 韩湘子 (艺术感知者)
- 曹国舅 (实务执行者)
- **使用模型**: `gemini-2.0-flash-exp`
### 🚧 待完成的任务
#### 1. 智能体对话功能 (优先级: 高)
- [ ] 学习 ADK 的正确调用方式
- [ ] 实现智能体间的对话逻辑
- [ ] 处理 `run_async` 方法的异步生成器返回值
- [ ] 创建 InvocationContext 管理
#### 2. 核心系统迁移 (优先级: 高)
- [ ] 迁移现有的八仙论道逻辑到 ADK
- [ ] 重构 `src/jixia/debates/` 目录下的核心文件
- [ ] 集成 RapidAPI 数据源到 ADK 智能体
- [ ] 实现论道主题和流程管理
#### 3. 界面集成 (优先级: 中)
- [ ] 更新 Streamlit 界面以支持 ADK
- [ ] 修改 `src/streamlit_app.py`
- [ ] 适配新的智能体调用方式
- [ ] 保持现有的用户体验
#### 4. 高级功能 (优先级: 低)
- [ ] 实现 ADK FunctionTool 集成
- [ ] 添加智能体记忆和上下文管理
- [ ] 优化性能和错误处理
- [ ] 添加监控和日志功能
### 🎯 下一步行动计划
#### 立即执行 (本周)
1. **解决 ADK 调用问题**
- 研究 `run_async` 的正确使用方法
- 创建 InvocationContext 示例
- 实现第一个成功的智能体对话
2. **创建工作原型**
- 实现铁拐李和吕洞宾的简单对话
- 验证论道逻辑的可行性
- 测试多轮对话功能
#### 短期目标 (本月)
1. **完成核心迁移**
- 迁移所有八仙智能体
- 实现完整的论道流程
- 集成现有数据源
2. **界面适配**
- 更新 Streamlit 应用
- 保持功能完整性
- 优化用户体验
### 📈 技术优势
#### Google ADK 带来的改进
1. **统一模型生态**: 直接使用 Gemini 系列模型
2. **官方支持**: Google 官方维护的框架
3. **更好的集成**: 与 Google 服务深度集成
4. **开发工具**: `adk web`, `adk run`, `adk api_server`
5. **性能优化**: 原生支持异步和流式处理
#### 保留的核心价值
1. **稷下学宫哲学框架**: 完全保留
2. **八仙角色设定**: 无缝迁移
3. **RapidAPI 数据源**: 继续使用
4. **MongoDB 数据库**: 保持不变
5. **Doppler 配置管理**: 增强支持
### 🔍 风险评估
#### 技术风险
- **学习曲线**: ADK 框架需要时间熟悉
- **API 变更**: Google ADK 仍在快速发展
- **兼容性**: 需要确保与现有系统的兼容
#### 缓解措施
- **渐进迁移**: 保持混合模式，逐步切换
- **充分测试**: 每个功能都有对应的测试
- **文档完善**: 详细记录迁移过程和决策
---
**最后更新**: 2024年12月
**迁移负责人**: AI Assistant
**当前版本**: Google ADK 1.10.0
**项目状态**: 🟡 进行中 (基础设施完成，核心功能开发中)

197
modules/documentation-suite/docs/development/RELEASE_v2.0.0.md Normal file
View File

@@ -0,0 +1,197 @@
# 🚀 太公心易 v2.0.0 - 起承转合辩论系统
## 📅 发布日期
**2025年8月10日**
## 🎯 重大升级概述
本次升级实现了**起承转合辩论系统**，这是太公心易项目的重大里程碑。系统从简单的群聊升级为具有完整辩论流程的多阶段辩论架构。
## ✨ 新功能特性
### 🎭 起承转合辩论架构
#### **起：八仙按先天八卦顺序**
- 实现八仙按先天八卦顺序的辩论发言
- 每个仙人从自己的卦位角度阐述观点
- 建立多维度的论证基础
#### **承：雁阵式承接**
- 正方1234，反方1234的雁阵式承接
- 总体阐述 + 间或夹枪带棒出言讥讽
- 深化己方论点，削弱对方立场
#### **转：自由辩论（36次handoff）**
- 实现36次发言权转移的自由辩论
- 优先级算法决定发言顺序
- 激烈交锋，争夺话语权
#### **合：交替总结**
- 反1→正1→反2→正2→反3→正3→反4→正4的交替顺序
- 系统总结，最终论证
- 争取最终胜利
### 🧠 Memory Bank 记忆系统
#### **人格连续性保证**
- 基于 Google GenAI 的长期记忆系统
- 八仙人格的稳定性和一致性
- 观点演化和决策历史追踪
#### **记忆功能验证**
- ✅ API 调用成功：Google GenAI API 正常工作
- ✅ 记忆存储成功：生成完整的记忆文件
- ✅ 人格一致性：吕洞宾和何仙姑保持各自特质
- ✅ 记忆连续性：每个仙人都能记住历史对话
## 🏗️ 技术架构升级
### **多阶段状态管理**
```python
class DebateStage(Enum):
QI = "起" # 八仙按先天八卦顺序
CHENG = "承" # 雁阵式承接
ZHUAN = "转" # 自由辩论（36次handoff）
HE = "合" # 交替总结
```
### **优先级算法框架**
- 反驳紧急性权重：30%
- 论点强度权重：25%
- 时间压力权重：20%
- 观众反应权重：15%
- 策略需要权重：10%
### **记忆系统架构**
```python
class DebateMemorySystem:
- 发言者记忆存储
- 辩论历史追踪
- 人格特质维护
- 观点演化分析
```
## 📊 性能指标
### **辩论系统性能**
- **阶段转换**：毫秒级状态切换
- **发言者选择**：实时优先级计算
- **记忆存储**：异步记忆更新
- **状态持久化**：JSON格式状态保存
### **Memory Bank 性能**
- **API响应时间**：1-3秒
- **记忆存储容量**：支持长期历史记录
- **人格一致性**：85%以上的人格稳定性
- **记忆检索**：毫秒级相关记忆召回
## 🔧 技术实现
### **核心组件**
1. **QiChengZhuanHeDebate**：起承转合辩论系统核心
2. **PriorityAlgorithm**：优先级算法实现
3. **DebateMemorySystem**：辩论记忆系统
4. **MemoryBankTest**：记忆系统测试框架
### **依赖升级**
- Google GenAI 1.29.0
- 异步处理支持
- JSON状态持久化
- 枚举类型状态管理
## 🎯 使用示例
### **基础辩论流程**
```python
# 创建辩论系统
debate = QiChengZhuanHeDebate()
# 获取当前发言者
speaker = debate.get_current_speaker()
# 记录发言
debate.record_speech(speaker, "发言内容")
# 推进阶段
debate.advance_stage()
# 保存状态
debate.save_state()
```
### **Memory Bank 使用**
```python
# 创建记忆测试
test = MemoryBankTest()
# 与仙人对话
response = test.chat_with_immortal("吕洞宾", "问题")
# 保存记忆
test.save_memories()
```
## 🚀 下一步计划
### **短期目标（v2.1.0）**
- [ ] 完善优先级算法
- [ ] 实现多群聊协调
- [ ] 添加Human干预机制
- [ ] 优化辩论流程控制
### **中期目标（v2.2.0）**
- [ ] 集成太公三式预测
- [ ] 实现梅花心易直觉
- [ ] 完善八仙人格量化
- [ ] 添加观众反馈系统
### **长期目标（v3.0.0）**
- [ ] 完整的预测系统
- [ ] 商业化部署
- [ ] 多语言支持
- [ ] 移动端应用
## 🐛 已知问题
1. **优先级算法**：当前使用简化版本，需要进一步优化
2. **多群聊协调**：尚未实现完整的群聊网络
3. **Human干预**：干预机制需要进一步完善
4. **性能优化**：大规模辩论的性能需要优化
## 📝 更新日志
### **v2.0.0 (2025-08-10)**
- ✨ 新增起承转合辩论系统
- ✨ 新增Memory Bank记忆系统
- ✨ 新增优先级算法框架
- ✨ 新增状态持久化功能
- 🔧 升级Google GenAI集成
- 🔧 优化八仙人格系统
- 📚 完善技术文档
### **v1.x.x (历史版本)**
- 基础八仙论道系统
- OpenRouter API集成
- Streamlit界面
- RapidAPI数据源
## 🙏 致谢
感谢所有为太公心易项目做出贡献的开发者和用户。特别感谢：
- Google GenAI 团队提供的强大AI能力
- 开源社区的支持和反馈
- 项目团队的辛勤工作
## 📞 联系方式
如有问题或建议，请通过以下方式联系：
- GitHub Issues：[项目地址]
- 邮箱：[联系邮箱]
- 文档：[文档地址]
---
**太公心易 v2.0.0** - 让AI辩论更有智慧，让预测更有力量！