TradingAgents-CN 配置迁移实战从 JSON 配置文件到 MongoDB 的 ConfigService 体系改造【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN本指南完整记录 TradingAgents-CN 将配置从分散的 JSON 文件models.json/settings.json/pricing.json迁移到 MongoDBsystem_configs集合的 Phase 2 实施过程涵盖迁移脚本设计、命令行操作、数据映射规则、废弃机制与代码迁移示例。读完本文你将掌握如何安全地将旧配置一键迁移入库、如何验证迁移结果、如何将基于ConfigManager的旧代码切换到新的ConfigService以及如何理解迁移背后的架构动机。迁移背景为什么要从 JSON 文件走向 MongoDB在迁移之前TradingAgents-CN 的配置分散在多个 JSON 文件中大模型配置config/models.json、模型定价config/pricing.json、系统设置config/settings.json、使用统计config/usage.json。这种方式的痛点十分典型配置分散同一套业务配置被拆成多个文件维护与排查成本高缺乏验证JSON 文件没有类型校验与格式检查一个手滑的逗号或错字段会静默生效不支持动态更新任何配置修改都必须重启服务才能生效线上调参成本高缺乏审计无法追踪谁在什么时候改了什么难以回溯和问责多实例同步困难多副本部署时每台机器的 JSON 文件各自为政同步极易出错。而 MongoDB 化的配置体系则天然具备统一存储、运行时热更新、变更可追踪可审计、多实例自动同步等能力。这正是本次迁移的核心目标对应的ConfigService实现在 app/services/config_service.py其单例在 第 4701 行 通过config_service ConfigService()导出供全项目复用。从仓库现状看config/目录下已不再存在models.json、settings.json、pricing.json等旧文件仅保留README.md与日志配置说明迁移已经落地本文档是对该过程最完整的技术存档。迁移脚本scripts/migrate_config_to_db.py全解析迁移的核心工具是 scripts/migrate_config_to_db.py这是一个异步 Python 脚本通过motorAsyncIOMotorClient驱动 MongoDB 写入并通过 app/core/config.py 中的settings读取 MongoDB 连接信息。支持的迁移内容来源文件内容迁移目标状态config/models.json大模型配置system_configs.llm_configs✅ 已支持config/pricing.json模型定价信息合并进llm_configs的价格字段✅ 已支持config/settings.json系统设置system_configs.system_settings✅ 已支持config/usage.json使用统计待实现⏳预留命令行参数python scripts/migrate_config_to_db.py [OPTIONS] OPTIONS: --dry-run 仅显示将要迁移的内容不实际执行 --backup 迁移前备份现有配置默认启用 --no-backup 不备份现有配置 --force 强制覆盖已存在的配置在源码中第 369-390 行argparse对参数的处理有一个细节--backup默认值为True且backup args.backup and not args.no_backup即只有显式传入--no-backup才会关闭备份——这保证了默认执行路径一定是安全的。迁移流程┌─────────────────────────────────────────────────────────┐ │ 配置迁移流程 │ ├─────────────────────────────────────────────────────────┤ │ 1. 备份现有配置 │ │ └─ config/backup/YYYYMMDD_HHMMSS/ │ │ 2. 连接数据库 │ │ └─ MongoDB: system_configs 集合 │ │ 3. 加载 JSON 文件 │ │ ├─ config/models.json │ │ ├─ config/pricing.json │ │ └─ config/settings.json │ │ 4. 转换数据格式 │ │ ├─ 合并模型配置和定价信息 │ │ ├─ 从环境变量读取 API 密钥 │ │ └─ 设置默认模型 │ │ 5. 写入数据库 │ │ └─ system_configs.llm_configs │ │ └─ system_configs.system_settings │ │ 6. 验证迁移结果 │ │ ├─ 检查配置数量 │ │ └─ 显示启用的模型 │ └─────────────────────────────────────────────────────────┘使用示例步骤 1Dry Run查看将要迁移的内容不实际执行.\.venv\Scripts\python scripts/migrate_config_to_db.py --dry-run输出示例 配置迁移工具: JSON → MongoDB ⚠️ DRY RUN 模式仅显示将要迁移的内容不实际执行 连接数据库... ✅ 数据库连接成功: localhost:27017/tradingagents 迁移大模型配置... 发现 6 个模型配置 [DRY RUN] 将要迁移的模型: • dashscope: qwen-turbo (enabledTrue) • dashscope: qwen-plus-latest (enabledTrue) • openai: gpt-3.5-turbo (enabledFalse) • openai: gpt-4 (enabledFalse) • google: gemini-2.5-pro (enabledFalse) • deepseek: deepseek-chat (enabledFalse) ⚙️ 迁移系统设置... 发现 17 个系统设置 [DRY RUN] 将要迁移的设置: • max_debate_rounds: 1 • max_risk_discuss_rounds: 1 • online_tools: True • online_news: True • realtime_data: False • memory_enabled: True ...--dry-run模式下脚本会跳过备份与写入第 327-333 行仅打印待迁移清单是上线前最重要的预演手段。步骤 2执行实际迁移.\.venv\Scripts\python scripts/migrate_config_to_db.py输出示例 配置迁移工具: JSON → MongoDB 备份配置文件... ✅ models.json → config/backup/20251005_143022/models.json ✅ settings.json → config/backup/20251005_143022/settings.json ✅ pricing.json → config/backup/20251005_143022/pricing.json ✅ 备份完成: 3 个文件 → config/backup/20251005_143022 连接数据库... ✅ 数据库连接成功: localhost:27017/tradingagents 迁移大模型配置... 发现 6 个模型配置 ✅ dashscope: qwen-turbo ✅ dashscope: qwen-plus-latest ✅ openai: gpt-3.5-turbo ✅ openai: gpt-4 ✅ google: gemini-2.5-pro ✅ deepseek: deepseek-chat ✅ 成功迁移 6 个大模型配置 ⚙️ 迁移系统设置... 发现 17 个系统设置 ✅ 成功迁移 12 个系统设置 验证迁移结果... ✅ 大模型配置: 6 个 ✅ 系统设置: 12 个 已启用的大模型 (2): • dashscope: qwen-turbo [默认] • dashscope: qwen-plus-latest ✅ 配置迁移完成 后续步骤: 1. 启动后端服务验证配置是否正常加载 2. 在 Web 界面检查配置是否正确 3. 如果一切正常可以考虑删除旧的 JSON 配置文件 4. 备份文件位置: config/backup步骤 3强制覆盖已存在的配置.\.venv\Scripts\python scripts/migrate_config_to_db.py --force当 MongoDB 中已存在system_configs文档时脚本默认不会覆盖而是提示系统配置已存在使用 --force 强制覆盖第 221-229 行传入--force后才会用replace_one(..., upsertTrue)完成覆盖写入。源码实现要点备份机制第 84-112 行使用datetime.now().strftime(%Y%m%d_%H%M%S)生成带时间戳的备份目录用shutil.copy2保留文件元数据API 密钥处理第 178-191 行模型配置中的api_key若为空会按 provider 从环境变量回填DASHSCOPE_API_KEY、OPENAI_API_KEY、DEEPSEEK_API_KEY、GOOGLE_API_KEY、ZHIPU_API_KEY保证迁移后密钥不丢失定价合并第 137-143 行以provider:model_name为键构建pricing_map将input_price_per_1k、output_price_per_1k、currency合并进模型文档默认模型标记第 211-215 行迁移时自动将第一个enabledTrue的模型标记为is_default连接串构建第 57-76 行当配置了MONGODB_USERNAME/MONGODB_PASSWORD时自动拼接带认证的 URI并支持authSource否则使用无认证 URI。数据迁移映射JSON → MongoDB 格式对照大模型配置JSON 格式config/models.json{ provider: dashscope, model_name: qwen-turbo, api_key: , base_url: null, max_tokens: 4000, temperature: 0.7, enabled: true }MongoDB 格式system_configs.llm_configs{ provider: dashscope, model_name: qwen-turbo, api_key: sk-xxx, base_url: null, max_tokens: 4000, temperature: 0.7, enabled: true, is_default: true, input_price_per_1k: 0.002, output_price_per_1k: 0.006, currency: CNY, extra_params: {} }对照可见迁移不是简单的搬运而是发生了三处结构化增强api_key从环境变量读取补全// 从环境变量读取、is_default字段新增// 新增字段、定价三字段从pricing.json合并// 从 pricing.json 合并外加extra_params扩展字段// 新增字段。系统设置JSON 格式config/settings.json{ llm_provider: dashscope, deep_think_llm: qwen-plus, quick_think_llm: qwen-turbo, max_debate_rounds: 1, online_tools: true, memory_enabled: true }MongoDB 格式system_configs.system_settings{ max_concurrent_tasks: 5, cache_ttl: 3600, log_level: INFO, enable_monitoring: true, max_debate_rounds: 1, online_tools: true, memory_enabled: true }系统设置部分同样发生了新旧融合max_concurrent_tasks、cache_ttl、log_level、enable_monitoring等是迁移时新增的运维字段来自settings.json的业务字段则原样保留。在 migrate_config_to_db.py 第 264-278 行 可以看到完整的默认值构造max_concurrent_tasks5、cache_ttl3600、log_levelINFO、enable_monitoringTrue、worker_heartbeat_interval30、sse_poll_timeout30并配合settings_data.get(max_debate_rounds, 1)这类带默认值的读取即使旧文件缺字段也不会迁移失败。新配置服务 ConfigService 与旧系统废弃机制废弃通知文档迁移配套产出了废弃通知文档实际存放于 docs/changes/DEPRECATION_NOTICE.md原文档中写作docs/DEPRECATION_NOTICE.md请以仓库根路径为准。其中明确了废弃对象与替代方案废弃对象位置替代方案JSON 配置文件系统config/models.json等四个文件MongoDBsystem_configs集合ConfigManager类tradingagents/config/config_manager.pyapp.services.config_service.ConfigServiceConfigManager.get_models()同上ConfigService.get_llm_configs()ConfigManager.get_settings()同上ConfigService.get_system_settings()ConfigManager.update_model()同上ConfigService.update_llm_config()ConfigManager.update_settings()同上ConfigService.update_system_settings()废弃时间表标记废弃2025-10-05计划移除JSON 配置系统与ConfigManager计划于 2026-03-31迁移实施文档口径移除废弃通知文档中亦记录为 2025-12-31 起进入废弃窗口最终移除时间以仓库最新文档为准从 2026-01-01 起检测到旧 JSON 配置时启动会显示废弃警告从 2026-02-01 起Web 界面会显示迁移提示立即迁移 / 稍后提醒 / 不再显示三选一。废弃警告的落地实现在旧模块 tradingagents/config/config_manager.py 的文件头第 6-10 行已实际写入废弃声明并在模块加载时通过warnings.warn(..., DeprecationWarning, stacklevel2)第 23-30 行发出运行时警告 ⚠️ DEPRECATED: 此模块已废弃将在 2026-03-31 后移除 请使用新的配置系统: app.services.config_service.ConfigService 迁移指南: docs/DEPRECATION_NOTICE.md 迁移脚本: scripts/migrate_config_to_db.py import warnings # 发出废弃警告 warnings.warn( ConfigManager is deprecated and will be removed in version 2.0 (2026-03-31). Please use app.services.config_service.ConfigService instead. See docs/DEPRECATION_NOTICE.md for migration guide., DeprecationWarning, stacklevel2 )这意味着只要还有代码from tradingagents.config.config_manager import ConfigManager运行时的DeprecationWarning就会持续提示开发者尽快切换——废弃不是一删了之而是温柔而坚定地推动迁移。新服务的能力全貌ConfigServiceapp/services/config_service.py不仅承担了旧ConfigManager的读写职责还扩展了更完整的配置域市场分类管理get_market_categories/add_market_category、数据源分组管理get_datasource_groupings/update_datasource_grouping、系统配置的版本化保存save_system_config每次写入都会version 1并将旧版本is_active置为False见 第 544-601 行、配置导入导出export_config会做 API Key 脱敏、import_config会忽略敏感字段、LLM 配置连通性测试test_llm_config会对 google / deepseek / dashscope 分别走专用测试方法等。这套能力正是动态更新、历史可回溯、多实例一致预期的实现载体。代码更新指南从 ConfigManager 切换到 ConfigService定位需要修改的代码# 查找使用 ConfigManager 的代码 grep -r from tradingagents.config.config_manager import --include*.py grep -r ConfigManager() --include*.py # 查找使用 JSON 配置文件的代码 grep -r config/models.json --include*.py grep -r config/settings.json --include*.py迁移示例示例 1获取模型配置旧代码from tradingagents.config.config_manager import ConfigManager config_manager ConfigManager() models config_manager.get_models()新代码from app.services.config_service import config_service config await config_service.get_system_config() llm_configs config.llm_configs示例 2更新模型配置旧代码config_manager.update_model(dashscope, qwen-turbo, {enabled: True})新代码注意当前仓库中ConfigService.update_llm_config的实际签名为async def update_llm_config(self, llm_config: LLMConfig) - bool见 app/services/config_service.py 第 883 行需要构造LLMConfig对象传入迁移文档中的provider...关键字风格体现的是服务层语义落地时请以实际签名构造参数from app.models.config import LLMConfig from app.services.config_service import config_service llm_config LLMConfig( providerdashscope, model_nameqwen-turbo, api_keysk-xxx, max_tokens4000, temperature0.7, enabledTrue ) await config_service.update_llm_config(llm_config)示例 3获取系统设置旧代码settings config_manager.get_settings() max_rounds settings.get(max_debate_rounds, 1)新代码from app.services.config_service import config_service config await config_service.get_system_config() max_rounds config.system_settings.get(max_debate_rounds, 1)需要特别注意的是新旧 API 的另一个核心差异是同步 vs 异步ConfigManager是同步调用而ConfigService的所有读写方法都是asyncget_system_config、update_llm_config、update_system_settings、save_system_config等均需await。因此切换代码时调用方需要确保自己处于异步上下文如 FastAPI 路由、async 服务方法中这是最容易遗漏的改造点。测试与验证确保迁移万无一失迁移完成后需要通过以下场景验证配置是否被正确读取与使用1. Dry Run 测试.\.venv\Scripts\python scripts/migrate_config_to_db.py --dry-run预期结果显示将要迁移的内容不实际执行。2. 备份测试.\.venv\Scripts\python scripts/migrate_config_to_db.py预期结果在config/backup/YYYYMMDD_HHMMSS/创建备份备份包含所有 JSON 配置文件。3. 迁移测试.\.venv\Scripts\python scripts/migrate_config_to_db.py预期结果成功迁移所有配置到 MongoDB显示迁移统计信息与启用的模型列表。4. 验证测试端到端# 启动后端服务 .\.venv\Scripts\python -m uvicorn app.main:app --host 0.0.0.0 --port 8000 # 访问配置管理页面 # http://localhost:3000/settings/config预期结果配置正确显示在 Web 界面可以正常编辑和保存配置配置变更立即生效无需重启服务——这正是 MongoDB 化配置的核心收益。5. 强制覆盖测试.\.venv\Scripts\python scripts/migrate_config_to_db.py --force预期结果覆盖数据库中已存在的配置。仓库中另有 scripts/test_migration.py 与 scripts/test_config_usage.py 可辅助验证迁移逻辑与配置读取路径。迁移进度与后续规划Phase 2 任务清单任务状态完成时间✅ 创建配置迁移脚本完成2025-10-05✅ 实现大模型配置迁移完成2025-10-05✅ 实现系统设置迁移完成2025-10-05✅ 实现配置验证完成2025-10-05✅ 创建废弃通知文档完成2025-10-05✅ 添加废弃警告完成2025-10-05 更新代码使用新配置系统进行中- 编写单元测试计划中-下一步继续 Phase 2 剩余任务更新所有使用ConfigManager的代码、编写单元测试、更新文档Phase 3 - Web UI 优化第 4 周优化配置管理页面 UI/UX、添加实时配置验证、实现配置导入导出、添加配置向导。相关文档配置指南docs/configuration/configuration_analysis.md 及 docs/configuration/configuration_optimization_plan.md废弃通知docs/changes/DEPRECATION_NOTICE.md统一配置说明docs/configuration/UNIFIED_CONFIG.md迁移脚本源码scripts/migrate_config_to_db.py新配置服务实现app/services/config_service.py旧配置管理器已废弃tradingagents/config/config_manager.py总结本次 Phase 2 配置迁移为 TradingAgents-CN 完成了三件关键工作一是交付了支持 Dry Run、自动备份、强制覆盖三大安全机制的迁移脚本二是产出废弃通知文档并制定了清晰的时间表三是在旧ConfigManager中落地了运行时废弃警告。迁移完成后配置统一收敛到 MongoDBsystem_configs集合配合ConfigService的版本化保存、动态热更新与导入导出能力从根本上解决了配置分散、缺乏校验、需要重启、无法审计、多实例不同步五类历史问题。对于仍在使用旧配置接口的代码只需按照本文的代码更新指南将同步的ConfigManager调用改写为异步的ConfigService调用即可平滑过渡。【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
TradingAgents-CN 配置迁移实战从 JSON 配置文件到 MongoDB 的 ConfigService 体系改造【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN本指南完整记录 TradingAgents-CN 将配置从分散的 JSON 文件models.json/settings.json/pricing.json迁移到 MongoDBsystem_configs集合的 Phase 2 实施过程涵盖迁移脚本设计、命令行操作、数据映射规则、废弃机制与代码迁移示例。读完本文你将掌握如何安全地将旧配置一键迁移入库、如何验证迁移结果、如何将基于ConfigManager的旧代码切换到新的ConfigService以及如何理解迁移背后的架构动机。迁移背景为什么要从 JSON 文件走向 MongoDB在迁移之前TradingAgents-CN 的配置分散在多个 JSON 文件中大模型配置config/models.json、模型定价config/pricing.json、系统设置config/settings.json、使用统计config/usage.json。这种方式的痛点十分典型配置分散同一套业务配置被拆成多个文件维护与排查成本高缺乏验证JSON 文件没有类型校验与格式检查一个手滑的逗号或错字段会静默生效不支持动态更新任何配置修改都必须重启服务才能生效线上调参成本高缺乏审计无法追踪谁在什么时候改了什么难以回溯和问责多实例同步困难多副本部署时每台机器的 JSON 文件各自为政同步极易出错。而 MongoDB 化的配置体系则天然具备统一存储、运行时热更新、变更可追踪可审计、多实例自动同步等能力。这正是本次迁移的核心目标对应的ConfigService实现在 app/services/config_service.py其单例在 第 4701 行 通过config_service ConfigService()导出供全项目复用。从仓库现状看config/目录下已不再存在models.json、settings.json、pricing.json等旧文件仅保留README.md与日志配置说明迁移已经落地本文档是对该过程最完整的技术存档。迁移脚本scripts/migrate_config_to_db.py全解析迁移的核心工具是 scripts/migrate_config_to_db.py这是一个异步 Python 脚本通过motorAsyncIOMotorClient驱动 MongoDB 写入并通过 app/core/config.py 中的settings读取 MongoDB 连接信息。支持的迁移内容来源文件内容迁移目标状态config/models.json大模型配置system_configs.llm_configs✅ 已支持config/pricing.json模型定价信息合并进llm_configs的价格字段✅ 已支持config/settings.json系统设置system_configs.system_settings✅ 已支持config/usage.json使用统计待实现⏳预留命令行参数python scripts/migrate_config_to_db.py [OPTIONS] OPTIONS: --dry-run 仅显示将要迁移的内容不实际执行 --backup 迁移前备份现有配置默认启用 --no-backup 不备份现有配置 --force 强制覆盖已存在的配置在源码中第 369-390 行argparse对参数的处理有一个细节--backup默认值为True且backup args.backup and not args.no_backup即只有显式传入--no-backup才会关闭备份——这保证了默认执行路径一定是安全的。迁移流程┌─────────────────────────────────────────────────────────┐ │ 配置迁移流程 │ ├─────────────────────────────────────────────────────────┤ │ 1. 备份现有配置 │ │ └─ config/backup/YYYYMMDD_HHMMSS/ │ │ 2. 连接数据库 │ │ └─ MongoDB: system_configs 集合 │ │ 3. 加载 JSON 文件 │ │ ├─ config/models.json │ │ ├─ config/pricing.json │ │ └─ config/settings.json │ │ 4. 转换数据格式 │ │ ├─ 合并模型配置和定价信息 │ │ ├─ 从环境变量读取 API 密钥 │ │ └─ 设置默认模型 │ │ 5. 写入数据库 │ │ └─ system_configs.llm_configs │ │ └─ system_configs.system_settings │ │ 6. 验证迁移结果 │ │ ├─ 检查配置数量 │ │ └─ 显示启用的模型 │ └─────────────────────────────────────────────────────────┘使用示例步骤 1Dry Run查看将要迁移的内容不实际执行.\.venv\Scripts\python scripts/migrate_config_to_db.py --dry-run输出示例 配置迁移工具: JSON → MongoDB ⚠️ DRY RUN 模式仅显示将要迁移的内容不实际执行 连接数据库... ✅ 数据库连接成功: localhost:27017/tradingagents 迁移大模型配置... 发现 6 个模型配置 [DRY RUN] 将要迁移的模型: • dashscope: qwen-turbo (enabledTrue) • dashscope: qwen-plus-latest (enabledTrue) • openai: gpt-3.5-turbo (enabledFalse) • openai: gpt-4 (enabledFalse) • google: gemini-2.5-pro (enabledFalse) • deepseek: deepseek-chat (enabledFalse) ⚙️ 迁移系统设置... 发现 17 个系统设置 [DRY RUN] 将要迁移的设置: • max_debate_rounds: 1 • max_risk_discuss_rounds: 1 • online_tools: True • online_news: True • realtime_data: False • memory_enabled: True ...--dry-run模式下脚本会跳过备份与写入第 327-333 行仅打印待迁移清单是上线前最重要的预演手段。步骤 2执行实际迁移.\.venv\Scripts\python scripts/migrate_config_to_db.py输出示例 配置迁移工具: JSON → MongoDB 备份配置文件... ✅ models.json → config/backup/20251005_143022/models.json ✅ settings.json → config/backup/20251005_143022/settings.json ✅ pricing.json → config/backup/20251005_143022/pricing.json ✅ 备份完成: 3 个文件 → config/backup/20251005_143022 连接数据库... ✅ 数据库连接成功: localhost:27017/tradingagents 迁移大模型配置... 发现 6 个模型配置 ✅ dashscope: qwen-turbo ✅ dashscope: qwen-plus-latest ✅ openai: gpt-3.5-turbo ✅ openai: gpt-4 ✅ google: gemini-2.5-pro ✅ deepseek: deepseek-chat ✅ 成功迁移 6 个大模型配置 ⚙️ 迁移系统设置... 发现 17 个系统设置 ✅ 成功迁移 12 个系统设置 验证迁移结果... ✅ 大模型配置: 6 个 ✅ 系统设置: 12 个 已启用的大模型 (2): • dashscope: qwen-turbo [默认] • dashscope: qwen-plus-latest ✅ 配置迁移完成 后续步骤: 1. 启动后端服务验证配置是否正常加载 2. 在 Web 界面检查配置是否正确 3. 如果一切正常可以考虑删除旧的 JSON 配置文件 4. 备份文件位置: config/backup步骤 3强制覆盖已存在的配置.\.venv\Scripts\python scripts/migrate_config_to_db.py --force当 MongoDB 中已存在system_configs文档时脚本默认不会覆盖而是提示系统配置已存在使用 --force 强制覆盖第 221-229 行传入--force后才会用replace_one(..., upsertTrue)完成覆盖写入。源码实现要点备份机制第 84-112 行使用datetime.now().strftime(%Y%m%d_%H%M%S)生成带时间戳的备份目录用shutil.copy2保留文件元数据API 密钥处理第 178-191 行模型配置中的api_key若为空会按 provider 从环境变量回填DASHSCOPE_API_KEY、OPENAI_API_KEY、DEEPSEEK_API_KEY、GOOGLE_API_KEY、ZHIPU_API_KEY保证迁移后密钥不丢失定价合并第 137-143 行以provider:model_name为键构建pricing_map将input_price_per_1k、output_price_per_1k、currency合并进模型文档默认模型标记第 211-215 行迁移时自动将第一个enabledTrue的模型标记为is_default连接串构建第 57-76 行当配置了MONGODB_USERNAME/MONGODB_PASSWORD时自动拼接带认证的 URI并支持authSource否则使用无认证 URI。数据迁移映射JSON → MongoDB 格式对照大模型配置JSON 格式config/models.json{ provider: dashscope, model_name: qwen-turbo, api_key: , base_url: null, max_tokens: 4000, temperature: 0.7, enabled: true }MongoDB 格式system_configs.llm_configs{ provider: dashscope, model_name: qwen-turbo, api_key: sk-xxx, base_url: null, max_tokens: 4000, temperature: 0.7, enabled: true, is_default: true, input_price_per_1k: 0.002, output_price_per_1k: 0.006, currency: CNY, extra_params: {} }对照可见迁移不是简单的搬运而是发生了三处结构化增强api_key从环境变量读取补全// 从环境变量读取、is_default字段新增// 新增字段、定价三字段从pricing.json合并// 从 pricing.json 合并外加extra_params扩展字段// 新增字段。系统设置JSON 格式config/settings.json{ llm_provider: dashscope, deep_think_llm: qwen-plus, quick_think_llm: qwen-turbo, max_debate_rounds: 1, online_tools: true, memory_enabled: true }MongoDB 格式system_configs.system_settings{ max_concurrent_tasks: 5, cache_ttl: 3600, log_level: INFO, enable_monitoring: true, max_debate_rounds: 1, online_tools: true, memory_enabled: true }系统设置部分同样发生了新旧融合max_concurrent_tasks、cache_ttl、log_level、enable_monitoring等是迁移时新增的运维字段来自settings.json的业务字段则原样保留。在 migrate_config_to_db.py 第 264-278 行 可以看到完整的默认值构造max_concurrent_tasks5、cache_ttl3600、log_levelINFO、enable_monitoringTrue、worker_heartbeat_interval30、sse_poll_timeout30并配合settings_data.get(max_debate_rounds, 1)这类带默认值的读取即使旧文件缺字段也不会迁移失败。新配置服务 ConfigService 与旧系统废弃机制废弃通知文档迁移配套产出了废弃通知文档实际存放于 docs/changes/DEPRECATION_NOTICE.md原文档中写作docs/DEPRECATION_NOTICE.md请以仓库根路径为准。其中明确了废弃对象与替代方案废弃对象位置替代方案JSON 配置文件系统config/models.json等四个文件MongoDBsystem_configs集合ConfigManager类tradingagents/config/config_manager.pyapp.services.config_service.ConfigServiceConfigManager.get_models()同上ConfigService.get_llm_configs()ConfigManager.get_settings()同上ConfigService.get_system_settings()ConfigManager.update_model()同上ConfigService.update_llm_config()ConfigManager.update_settings()同上ConfigService.update_system_settings()废弃时间表标记废弃2025-10-05计划移除JSON 配置系统与ConfigManager计划于 2026-03-31迁移实施文档口径移除废弃通知文档中亦记录为 2025-12-31 起进入废弃窗口最终移除时间以仓库最新文档为准从 2026-01-01 起检测到旧 JSON 配置时启动会显示废弃警告从 2026-02-01 起Web 界面会显示迁移提示立即迁移 / 稍后提醒 / 不再显示三选一。废弃警告的落地实现在旧模块 tradingagents/config/config_manager.py 的文件头第 6-10 行已实际写入废弃声明并在模块加载时通过warnings.warn(..., DeprecationWarning, stacklevel2)第 23-30 行发出运行时警告 ⚠️ DEPRECATED: 此模块已废弃将在 2026-03-31 后移除 请使用新的配置系统: app.services.config_service.ConfigService 迁移指南: docs/DEPRECATION_NOTICE.md 迁移脚本: scripts/migrate_config_to_db.py import warnings # 发出废弃警告 warnings.warn( ConfigManager is deprecated and will be removed in version 2.0 (2026-03-31). Please use app.services.config_service.ConfigService instead. See docs/DEPRECATION_NOTICE.md for migration guide., DeprecationWarning, stacklevel2 )这意味着只要还有代码from tradingagents.config.config_manager import ConfigManager运行时的DeprecationWarning就会持续提示开发者尽快切换——废弃不是一删了之而是温柔而坚定地推动迁移。新服务的能力全貌ConfigServiceapp/services/config_service.py不仅承担了旧ConfigManager的读写职责还扩展了更完整的配置域市场分类管理get_market_categories/add_market_category、数据源分组管理get_datasource_groupings/update_datasource_grouping、系统配置的版本化保存save_system_config每次写入都会version 1并将旧版本is_active置为False见 第 544-601 行、配置导入导出export_config会做 API Key 脱敏、import_config会忽略敏感字段、LLM 配置连通性测试test_llm_config会对 google / deepseek / dashscope 分别走专用测试方法等。这套能力正是动态更新、历史可回溯、多实例一致预期的实现载体。代码更新指南从 ConfigManager 切换到 ConfigService定位需要修改的代码# 查找使用 ConfigManager 的代码 grep -r from tradingagents.config.config_manager import --include*.py grep -r ConfigManager() --include*.py # 查找使用 JSON 配置文件的代码 grep -r config/models.json --include*.py grep -r config/settings.json --include*.py迁移示例示例 1获取模型配置旧代码from tradingagents.config.config_manager import ConfigManager config_manager ConfigManager() models config_manager.get_models()新代码from app.services.config_service import config_service config await config_service.get_system_config() llm_configs config.llm_configs示例 2更新模型配置旧代码config_manager.update_model(dashscope, qwen-turbo, {enabled: True})新代码注意当前仓库中ConfigService.update_llm_config的实际签名为async def update_llm_config(self, llm_config: LLMConfig) - bool见 app/services/config_service.py 第 883 行需要构造LLMConfig对象传入迁移文档中的provider...关键字风格体现的是服务层语义落地时请以实际签名构造参数from app.models.config import LLMConfig from app.services.config_service import config_service llm_config LLMConfig( providerdashscope, model_nameqwen-turbo, api_keysk-xxx, max_tokens4000, temperature0.7, enabledTrue ) await config_service.update_llm_config(llm_config)示例 3获取系统设置旧代码settings config_manager.get_settings() max_rounds settings.get(max_debate_rounds, 1)新代码from app.services.config_service import config_service config await config_service.get_system_config() max_rounds config.system_settings.get(max_debate_rounds, 1)需要特别注意的是新旧 API 的另一个核心差异是同步 vs 异步ConfigManager是同步调用而ConfigService的所有读写方法都是asyncget_system_config、update_llm_config、update_system_settings、save_system_config等均需await。因此切换代码时调用方需要确保自己处于异步上下文如 FastAPI 路由、async 服务方法中这是最容易遗漏的改造点。测试与验证确保迁移万无一失迁移完成后需要通过以下场景验证配置是否被正确读取与使用1. Dry Run 测试.\.venv\Scripts\python scripts/migrate_config_to_db.py --dry-run预期结果显示将要迁移的内容不实际执行。2. 备份测试.\.venv\Scripts\python scripts/migrate_config_to_db.py预期结果在config/backup/YYYYMMDD_HHMMSS/创建备份备份包含所有 JSON 配置文件。3. 迁移测试.\.venv\Scripts\python scripts/migrate_config_to_db.py预期结果成功迁移所有配置到 MongoDB显示迁移统计信息与启用的模型列表。4. 验证测试端到端# 启动后端服务 .\.venv\Scripts\python -m uvicorn app.main:app --host 0.0.0.0 --port 8000 # 访问配置管理页面 # http://localhost:3000/settings/config预期结果配置正确显示在 Web 界面可以正常编辑和保存配置配置变更立即生效无需重启服务——这正是 MongoDB 化配置的核心收益。5. 强制覆盖测试.\.venv\Scripts\python scripts/migrate_config_to_db.py --force预期结果覆盖数据库中已存在的配置。仓库中另有 scripts/test_migration.py 与 scripts/test_config_usage.py 可辅助验证迁移逻辑与配置读取路径。迁移进度与后续规划Phase 2 任务清单任务状态完成时间✅ 创建配置迁移脚本完成2025-10-05✅ 实现大模型配置迁移完成2025-10-05✅ 实现系统设置迁移完成2025-10-05✅ 实现配置验证完成2025-10-05✅ 创建废弃通知文档完成2025-10-05✅ 添加废弃警告完成2025-10-05 更新代码使用新配置系统进行中- 编写单元测试计划中-下一步继续 Phase 2 剩余任务更新所有使用ConfigManager的代码、编写单元测试、更新文档Phase 3 - Web UI 优化第 4 周优化配置管理页面 UI/UX、添加实时配置验证、实现配置导入导出、添加配置向导。相关文档配置指南docs/configuration/configuration_analysis.md 及 docs/configuration/configuration_optimization_plan.md废弃通知docs/changes/DEPRECATION_NOTICE.md统一配置说明docs/configuration/UNIFIED_CONFIG.md迁移脚本源码scripts/migrate_config_to_db.py新配置服务实现app/services/config_service.py旧配置管理器已废弃tradingagents/config/config_manager.py总结本次 Phase 2 配置迁移为 TradingAgents-CN 完成了三件关键工作一是交付了支持 Dry Run、自动备份、强制覆盖三大安全机制的迁移脚本二是产出废弃通知文档并制定了清晰的时间表三是在旧ConfigManager中落地了运行时废弃警告。迁移完成后配置统一收敛到 MongoDBsystem_configs集合配合ConfigService的版本化保存、动态热更新与导入导出能力从根本上解决了配置分散、缺乏校验、需要重启、无法审计、多实例不同步五类历史问题。对于仍在使用旧配置接口的代码只需按照本文的代码更新指南将同步的ConfigManager调用改写为异步的ConfigService调用即可平滑过渡。【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
