拓冰网站定制 
TradingAgents-CN 统一日志改造print 转 logger 的规模化迁移实践与实现解析【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN导读TradingAgents-CN 是基于多智能体 LLM 的中文金融交易框架其代码库横跨核心交易代理tradingagents/、Web 界面web/、CLIcli/、脚本工具scripts/与示例examples/等大量模块。随着模块数量膨胀散落各处的print()调试输出不仅污染终端、无法分级过滤也无法被统一采集与分析。本文基于仓库中的 print_to_log_conversion_report.md 与配套的 convert_prints_to_logs.py 转换器实现完整讲解本次「print 转日志」批量迁移的统计结果、转换规则、日志器命名规范以及底层 logging_manager.py 与 logging.toml 构成的统一日志体系。读完本文你将掌握如何在一个多模块 Python 仓库中安全、自动化地把 print 替换为分级日志输出并理解其背后的配置机制。一、迁移概览一次覆盖 100 个文件的自动化改造本次 print 转日志改造以「批量扫描 规则化转换 报告留痕」的方式执行转换器由PrintToLogConverter类实现见 scripts/convert_prints_to_logs.py。官方报告记录的最终结果为成功转换文件100错误数量0报告全文以「转换统计 转换的文件清单」两部分构成文件清单覆盖了项目内从入口到工具脚本的全部 Python 代码按目录归类主要包括目录代表性文件职责根目录main.py、quick_syntax_check.py、syntax_checker.py主入口与语法检查工具cli/cli/main.py、cli/utils.py命令行接口examples/examples/batch_analysis.py、examples/cli_demo.py演示与集成示例scripts/scripts/log_analyzer.py、scripts/setup-docker.py运维与构建脚本tradingagents/tradingagents/dataflows/akshare_utils.py、tradingagents/graph/trading_graph.py核心数据流与交易图web/web/app.py、web/components/analysis_form.pyWeb 界面utils/utils/check_version_consistency.py工具函数可以看到这次改造不是局部修补而是对全仓库日志基建的一次系统性收口目的是让所有模块统一走 logging_manager.py 提供的get_logger()通道。二、转换器的核心实现规则驱动的 print 检测与改写转换器以PrintToLogConverter为核心类scripts/convert_prints_to_logs.py#L13-L45工作流程分为三步跳过规则判定 → 注入日志导入 → 改写 print 语句。2.1 安全的文件过滤规则迁移必须避免误伤测试与虚拟环境因此转换器维护了两套排除清单should_skip_file排除目录tests、env、.env、__pycache__、.git、.github排除文件模式test_*.py、*_test.py、conftest.py、setup.py以及转换器自身convert_prints_to_logs.py这一设计保证了测试代码中的print辅助输出不受影响同时避免转换器处理自身导致无限递归式改写。2.2 自动注入统一日志导入对每个待转换文件转换器会在所有 import 语句结束后插入日志导入与 logger 初始化add_logging_import# 导入日志模块 from tradingagents.utils.logging_manager import get_logger logger get_logger(default)其中 logger 名称并非写死而是根据文件相对路径自动推导脚本 L109-L129规则如下路径特征logger 名称含webweb含tradingagents且含agentsagents含tradingagents且含dataflowsdataflows含tradingagents且含llm_adaptersllm_adapters含tradingagents且含utilsutils含tradingagents其他tradingagents含clicli含scriptsscripts其他default该命名规范与 config/logging.toml 中[logging.loggers]各命名空间tradingagents、web、dataflows、llm_adapters等一一对应从而保证每个模块的日志可以被按命名空间独立调节级别。2.3 print 语句的匹配与级别判定转换器通过正则匹配四种 print 形态convert_print_statementsprint_patterns [ rprint\s*\(\s*f?([^]*?)([^)]*)\), # print(...) rprint\s*\(\s*f?([^]*?)([^)]*)\), # print(...) rprint\s*\(\s*f?([^]*?)([^)]*)\), # print(...) rprint\s*\(\s*f?([^]*?)([^)]*)\), # print(...) ]匹配到消息内容后调用 get_log_level_from_message 依据消息中的关键词推断日志级别判定关键词映射级别❌、错误、ERROR、Error、失败、Failed、Exceptionerror⚠️、警告、WARNING、Warning、注意warning、DEBUG、Debug、[DEBUG]debug✅、成功、完成、Success、Completeinfo其余info默认随后按原缩进改写为logger.level(fmessage)若原 print 带额外参数如sep则保留在调用括号内# 转换前 print(f✅ 分析完成 - {symbol}) # 转换后 logger.info(f✅ 分析完成 - {symbol})得益于仓库源码里大量使用 emoji 前缀作为状态标识这与logging_manager.py内置的log_analysis_complete等语义化日志风格一脉相承这套关键词推断在真实代码上命中率很高。三、统一日志体系的底层支撑print 转 logger 之所以能落地是因为项目已具备一套完整的统一日志基础设施转换后的get_logger()调用最终都汇入这里。3.1 统一日志管理器TradingAgentsLoggertradingagents/utils/logging_manager.py 定义了TradingAgentsLogger类与两个关键入口get_logger(name)获取/创建命名日志器脚本 L439-L441所有模块统一通过它取 loggersetup_logging(config)可传入自定义配置重建日志系统脚本 L444-L448。类内部实现了四类处理器处理器输出目标默认级别说明console标准输出INFO支持 ANSI 彩色ColoredFormatterDEBUG 青、INFO 绿、WARNING 黄、ERROR 红、CRITICAL 紫仅 TTY 下着色file./logs/tradingagents.logDEBUGRotatingFileHandler轮转默认 10MB×5error./logs/error.logWARNING只收 WARNING/ERROR/CRITICAL便于单独盯异常structured./logs/tradingagents_structured.logINFO默认关闭产出 JSON 结构化日志其中StructuredFormatter脚本 L43-L69会把session_id、analysis_type、stock_symbol、cost、tokens等业务字段一并序列化为 JSON为后续检索分析提供机器可读数据。3.2 TOML 配置文件驱动的运行期行为日志行为全部由 config/logging.toml 控制加载逻辑位于_load_config_file脚本 L139-L160加载顺序为config/logging_docker.toml当环境变量DOCKER_CONTAINERtrue时config/logging.toml./logging.toml兜底环境变量配置TRADINGAGENTS_LOG_LEVEL、TRADINGAGENTS_LOG_DIR关键配置项config/logging.toml[logging] level INFO # 全局级别DEBUG/INFO/WARNING/ERROR/CRITICAL [logging.format] console %(asctime)s | %(name)-20s | %(levelname)-8s | %(message)s file %(asctime)s | %(name)-20s | %(levelname)-8s | %(module)s:%(funcName)s:%(lineno)d | %(message)s file_json true # 启用文件日志 JSON 输出webapi.log 与 worker.log [logging.handlers.file] enabled true level DEBUG max_size 10MB # 单个日志文件上限支持 KB/MB/GB 后缀 backup_count 5 # 轮转保留份数 directory ./logs [logging.handlers.error] enabled true level WARNING # 错误日志专用文件 filename error.log此外还包含三级环境预设Docker 环境logging.docker可切换为只输出 stdout、禁用文件日志开发环境logging.development可对tradingagents.graph、tradingagents.llm_adapters等模块开 DEBUG 并保存调试文件生产环境logging.production可启用纯结构化日志与错误通知并放大单文件上限至 100MB。另有一份专为容器准备的 config/logging_docker.toml将日志目录固定为/app/logs并细分出webapi.log、worker.log等独立文件配合file_json true让后端与 Worker 的日志分别以 JSON 落盘便于在 Docker 部署场景下做集中采集。四、从报告到工程实践本次改造的经验沉淀报告本身是一份「迁移留痕」文档但从其结构与配套脚本可以提炼出可复用的工程方法论先立规范再动代码get_logger()命名空间与logging.toml中 logger 段一一对应保证迁移后日志归属清晰自动化 人工复核转换器承担全部机械改写报告自动生成成功转换文件/错误数量统计方便审计报告中「错误数量: 0」说明规则转换在目标代码上无失败案例保留语义级别通过消息关键词自动分级使历史 print 文本在转换后依然能按级别过滤而不是全部落入 info配套修复闭环本次 print 迁移并非孤立动作仓库中还有scripts/fix_duplicate_loggers.py移除重复 logger 定义对应 duplicate_logger_fix_report.md累计修复 98 个文件、移除 108 处重复定义与 scripts/migrate_to_unified_logging.py把logging.getLogger(__name__)、traceback.print_exc()等旧式调用统一收编三者共同构成「print 转日志 → 去重 → 统一 API」的完整治理链路。4.1 迁移后的日志查看方式完成转换后运行任意模块如python cli/main.py或 Web 服务即可看到分级彩色输出常规运行日志落在./logs/tradingagents.log错误与警告单独沉淀在./logs/error.log。在 Docker 部署下则统一写入/app/logs/下各命名文件。开发者可用grep、日志采集器或直接解析 JSON 行完成排障与监控。五、小结本次「print 转日志」改造以零错误的成绩覆盖 100 个 Python 文件将分散的print()统一收敛到 logging_manager.py 提供的分级日志体系之下转换器 convert_prints_to_logs.py 负责规则化改写config/logging.toml 与 config/logging_docker.toml 负责运行期行为get_logger()命名空间规范负责模块归属。对于任何正在演进的多模块 Python 项目这套「脚本批量转换 命名空间规范 TOML 驱动 报告留痕」的组合都是一份可直接借鉴的日志基建治理样板。【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 TradingAgents-CN 统一日志改造：print 转 logger 的规模化迁移实践与实现解析
TradingAgents-CN 统一日志改造print 转 logger 的规模化迁移实践与实现解析【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN导读TradingAgents-CN 是基于多智能体 LLM 的中文金融交易框架其代码库横跨核心交易代理tradingagents/、Web 界面web/、CLIcli/、脚本工具scripts/与示例examples/等大量模块。随着模块数量膨胀散落各处的print()调试输出不仅污染终端、无法分级过滤也无法被统一采集与分析。本文基于仓库中的 print_to_log_conversion_report.md 与配套的 convert_prints_to_logs.py 转换器实现完整讲解本次「print 转日志」批量迁移的统计结果、转换规则、日志器命名规范以及底层 logging_manager.py 与 logging.toml 构成的统一日志体系。读完本文你将掌握如何在一个多模块 Python 仓库中安全、自动化地把 print 替换为分级日志输出并理解其背后的配置机制。一、迁移概览一次覆盖 100 个文件的自动化改造本次 print 转日志改造以「批量扫描 规则化转换 报告留痕」的方式执行转换器由PrintToLogConverter类实现见 scripts/convert_prints_to_logs.py。官方报告记录的最终结果为成功转换文件100错误数量0报告全文以「转换统计 转换的文件清单」两部分构成文件清单覆盖了项目内从入口到工具脚本的全部 Python 代码按目录归类主要包括目录代表性文件职责根目录main.py、quick_syntax_check.py、syntax_checker.py主入口与语法检查工具cli/cli/main.py、cli/utils.py命令行接口examples/examples/batch_analysis.py、examples/cli_demo.py演示与集成示例scripts/scripts/log_analyzer.py、scripts/setup-docker.py运维与构建脚本tradingagents/tradingagents/dataflows/akshare_utils.py、tradingagents/graph/trading_graph.py核心数据流与交易图web/web/app.py、web/components/analysis_form.pyWeb 界面utils/utils/check_version_consistency.py工具函数可以看到这次改造不是局部修补而是对全仓库日志基建的一次系统性收口目的是让所有模块统一走 logging_manager.py 提供的get_logger()通道。二、转换器的核心实现规则驱动的 print 检测与改写转换器以PrintToLogConverter为核心类scripts/convert_prints_to_logs.py#L13-L45工作流程分为三步跳过规则判定 → 注入日志导入 → 改写 print 语句。2.1 安全的文件过滤规则迁移必须避免误伤测试与虚拟环境因此转换器维护了两套排除清单should_skip_file排除目录tests、env、.env、__pycache__、.git、.github排除文件模式test_*.py、*_test.py、conftest.py、setup.py以及转换器自身convert_prints_to_logs.py这一设计保证了测试代码中的print辅助输出不受影响同时避免转换器处理自身导致无限递归式改写。2.2 自动注入统一日志导入对每个待转换文件转换器会在所有 import 语句结束后插入日志导入与 logger 初始化add_logging_import# 导入日志模块 from tradingagents.utils.logging_manager import get_logger logger get_logger(default)其中 logger 名称并非写死而是根据文件相对路径自动推导脚本 L109-L129规则如下路径特征logger 名称含webweb含tradingagents且含agentsagents含tradingagents且含dataflowsdataflows含tradingagents且含llm_adaptersllm_adapters含tradingagents且含utilsutils含tradingagents其他tradingagents含clicli含scriptsscripts其他default该命名规范与 config/logging.toml 中[logging.loggers]各命名空间tradingagents、web、dataflows、llm_adapters等一一对应从而保证每个模块的日志可以被按命名空间独立调节级别。2.3 print 语句的匹配与级别判定转换器通过正则匹配四种 print 形态convert_print_statementsprint_patterns [ rprint\s*\(\s*f?([^]*?)([^)]*)\), # print(...) rprint\s*\(\s*f?([^]*?)([^)]*)\), # print(...) rprint\s*\(\s*f?([^]*?)([^)]*)\), # print(...) rprint\s*\(\s*f?([^]*?)([^)]*)\), # print(...) ]匹配到消息内容后调用 get_log_level_from_message 依据消息中的关键词推断日志级别判定关键词映射级别❌、错误、ERROR、Error、失败、Failed、Exceptionerror⚠️、警告、WARNING、Warning、注意warning、DEBUG、Debug、[DEBUG]debug✅、成功、完成、Success、Completeinfo其余info默认随后按原缩进改写为logger.level(fmessage)若原 print 带额外参数如sep则保留在调用括号内# 转换前 print(f✅ 分析完成 - {symbol}) # 转换后 logger.info(f✅ 分析完成 - {symbol})得益于仓库源码里大量使用 emoji 前缀作为状态标识这与logging_manager.py内置的log_analysis_complete等语义化日志风格一脉相承这套关键词推断在真实代码上命中率很高。三、统一日志体系的底层支撑print 转 logger 之所以能落地是因为项目已具备一套完整的统一日志基础设施转换后的get_logger()调用最终都汇入这里。3.1 统一日志管理器TradingAgentsLoggertradingagents/utils/logging_manager.py 定义了TradingAgentsLogger类与两个关键入口get_logger(name)获取/创建命名日志器脚本 L439-L441所有模块统一通过它取 loggersetup_logging(config)可传入自定义配置重建日志系统脚本 L444-L448。类内部实现了四类处理器处理器输出目标默认级别说明console标准输出INFO支持 ANSI 彩色ColoredFormatterDEBUG 青、INFO 绿、WARNING 黄、ERROR 红、CRITICAL 紫仅 TTY 下着色file./logs/tradingagents.logDEBUGRotatingFileHandler轮转默认 10MB×5error./logs/error.logWARNING只收 WARNING/ERROR/CRITICAL便于单独盯异常structured./logs/tradingagents_structured.logINFO默认关闭产出 JSON 结构化日志其中StructuredFormatter脚本 L43-L69会把session_id、analysis_type、stock_symbol、cost、tokens等业务字段一并序列化为 JSON为后续检索分析提供机器可读数据。3.2 TOML 配置文件驱动的运行期行为日志行为全部由 config/logging.toml 控制加载逻辑位于_load_config_file脚本 L139-L160加载顺序为config/logging_docker.toml当环境变量DOCKER_CONTAINERtrue时config/logging.toml./logging.toml兜底环境变量配置TRADINGAGENTS_LOG_LEVEL、TRADINGAGENTS_LOG_DIR关键配置项config/logging.toml[logging] level INFO # 全局级别DEBUG/INFO/WARNING/ERROR/CRITICAL [logging.format] console %(asctime)s | %(name)-20s | %(levelname)-8s | %(message)s file %(asctime)s | %(name)-20s | %(levelname)-8s | %(module)s:%(funcName)s:%(lineno)d | %(message)s file_json true # 启用文件日志 JSON 输出webapi.log 与 worker.log [logging.handlers.file] enabled true level DEBUG max_size 10MB # 单个日志文件上限支持 KB/MB/GB 后缀 backup_count 5 # 轮转保留份数 directory ./logs [logging.handlers.error] enabled true level WARNING # 错误日志专用文件 filename error.log此外还包含三级环境预设Docker 环境logging.docker可切换为只输出 stdout、禁用文件日志开发环境logging.development可对tradingagents.graph、tradingagents.llm_adapters等模块开 DEBUG 并保存调试文件生产环境logging.production可启用纯结构化日志与错误通知并放大单文件上限至 100MB。另有一份专为容器准备的 config/logging_docker.toml将日志目录固定为/app/logs并细分出webapi.log、worker.log等独立文件配合file_json true让后端与 Worker 的日志分别以 JSON 落盘便于在 Docker 部署场景下做集中采集。四、从报告到工程实践本次改造的经验沉淀报告本身是一份「迁移留痕」文档但从其结构与配套脚本可以提炼出可复用的工程方法论先立规范再动代码get_logger()命名空间与logging.toml中 logger 段一一对应保证迁移后日志归属清晰自动化 人工复核转换器承担全部机械改写报告自动生成成功转换文件/错误数量统计方便审计报告中「错误数量: 0」说明规则转换在目标代码上无失败案例保留语义级别通过消息关键词自动分级使历史 print 文本在转换后依然能按级别过滤而不是全部落入 info配套修复闭环本次 print 迁移并非孤立动作仓库中还有scripts/fix_duplicate_loggers.py移除重复 logger 定义对应 duplicate_logger_fix_report.md累计修复 98 个文件、移除 108 处重复定义与 scripts/migrate_to_unified_logging.py把logging.getLogger(__name__)、traceback.print_exc()等旧式调用统一收编三者共同构成「print 转日志 → 去重 → 统一 API」的完整治理链路。4.1 迁移后的日志查看方式完成转换后运行任意模块如python cli/main.py或 Web 服务即可看到分级彩色输出常规运行日志落在./logs/tradingagents.log错误与警告单独沉淀在./logs/error.log。在 Docker 部署下则统一写入/app/logs/下各命名文件。开发者可用grep、日志采集器或直接解析 JSON 行完成排障与监控。五、小结本次「print 转日志」改造以零错误的成绩覆盖 100 个 Python 文件将分散的print()统一收敛到 logging_manager.py 提供的分级日志体系之下转换器 convert_prints_to_logs.py 负责规则化改写config/logging.toml 与 config/logging_docker.toml 负责运行期行为get_logger()命名空间规范负责模块归属。对于任何正在演进的多模块 Python 项目这套「脚本批量转换 命名空间规范 TOML 驱动 报告留痕」的组合都是一份可直接借鉴的日志基建治理样板。【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考