TradingAgents-CN 分析任务预估总时长显示错误修复从根因定位到时间估算算法全解析【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN本篇技术指南聚焦 TradingAgents-CN 多智能体分析框架中预计总时长显示错误的完整修复过程。文章以修复文档为骨架结合仓库源码app/services/progress/tracker.py、测试脚本scripts/test_estimated_total_time.py与前端轮询实现从问题现象、根因定位、修复方案到时间估算算法的参数设计逐一展开。读完本文你将掌握 RedisProgressTracker 初始化时序、预估总时长算法研究深度 × 分析师系数 × 模型系数的底层原理以及如何通过测试脚本验证前后端时间数据的一致性。问题现象前端显示的预计总时长为何与预期不符用户在使用 TradingAgents-CN 提交股票分析任务时发现前端页面展示的预计总时长与后端算法计算出的结果不一致。以一组典型配置为例研究深度4级 - 深度分析分析师3个市场分析师、新闻分析师、基本面分析师LLM 提供商dashscope预期结果预计总时长 11 分钟。依据后端算法330 秒 × 2.0 × 1.0 660 秒 11 分钟。实际结果前端显示19 分钟与预期严重偏离。此外在1级快速 1个分析师、5级全面 4个分析师等场景下前端显示未知或错误的时长用户无法获得准确的任务耗时预期。根本原因初始化时未写入 estimated_total_time 字段通过代码定位问题源头在app/services/progress/tracker.py的RedisProgressTracker.__init__()方法中。有缺陷的初始化代码初始化progress_data字典时虽然包含elapsed_time已用时间和remaining_time剩余时间但遗漏了estimated_total_time预估总时长字段# 进度数据修复前 self.progress_data { task_id: task_id, status: running, progress_percentage: 0.0, current_step: 0, total_steps: 0, current_step_name: 初始化, current_step_description: 准备开始分析, last_message: 分析任务已启动, start_time: time.time(), last_update: time.time(), elapsed_time: 0.0, remaining_time: 0.0, steps: [] } # ❌ 缺少 estimated_total_time 字段缺陷传导链路缺失字段会沿数据流逐级放大为错误的展示结果to_dict()方法从progress_data中读取estimated_total_time见 tracker.py当字段不存在时通过self.progress_data.get(estimated_total_time, 0)返回默认值0该 0 值随进度数据一起被序列化保存到 Redis 或本地文件前端轮询进度接口拿到 0 后可能回退到自身的默认值或沿用旧任务残留值最终渲染出 19 分钟这类错误时长。值得说明的是_calculate_static_time_estimates()虽然提供了兜底逻辑当进度数据中没有estimated_total_time时使用默认值 300 秒见 tracker.py但这只作用于历史任务的读取恢复路径get_progress_by_id无法覆盖新任务创建瞬间的初始化路径因此任务启动后前端拿到的第一份进度数据依然是残缺的。修复方案初始化时即时计算并写入预估总时长修复的核心思路是在__init__()中生成分析步骤之后、首次保存进度之前立即调用_get_base_total_time()计算出预估总时长并同步写入estimated_total_time与remaining_time两个字段。修复后的初始化逻辑# 进度数据 self.progress_data { task_id: task_id, status: running, progress_percentage: 0.0, current_step: 0, total_steps: 0, current_step_name: 初始化, current_step_description: 准备开始分析, last_message: 分析任务已启动, start_time: time.time(), last_update: time.time(), elapsed_time: 0.0, remaining_time: 0.0, steps: [] } # 生成分析步骤 self.analysis_steps self._generate_dynamic_steps() self.progress_data[total_steps] len(self.analysis_steps) self.progress_data[steps] [asdict(step) for step in self.analysis_steps] # 计算并设置预估总时长 base_total_time self._get_base_total_time() self.progress_data[estimated_total_time] base_total_time self.progress_data[remaining_time] base_total_time # 初始时剩余时间 总时长 # 保存初始状态 self._save_progress()关键改动点调用_get_base_total_time()在任务初始化的第一时刻完成预估总时长的计算而不是等后续update_progress()时才被动补充设置estimated_total_time确保to_dict()序列化、Redis/文件持久化、前端轮询返回的每一步都能拿到该字段设置remaining_time初始时任务尚未执行剩余时间应等于预估总时长避免前端一开始就显示 0。修复后_save_progress()会在初始化阶段立即持久化包含estimated_total_time的完整进度快照Redis 存储键为progress:{task_id}过期时间 3600 秒文件存储路径为./data/progress/{task_id}.json详见 tracker.py。时间估算算法预估总时长从哪来修复之所以能给出 11 分钟、2 分钟、23 分钟等精确数值依赖于_get_base_total_time()中一套基于实际测试数据校准的估算算法。该方法的完整实现在 tracker.py。算法公式total_time base_time_per_depth × analyst_multiplier × model_mult三个因子分别对应研究深度、分析师规模与 LLM 模型速度彼此独立、相乘耦合。参数一base_time_per_depth研究深度基础耗时五个分析深度级别与单分析师基础耗时单位秒的映射关系级别深度名称基础耗时折算1级快速150 秒2.5 分钟2级基础180 秒3 分钟3级标准240 秒4 分钟4级深度330 秒5.5 分钟5级全面480 秒8 分钟深度名称通过depth_map字典映射为数字级别未知名称时默认按 3 级标准处理基础耗时兜底值为 240 秒depth_map { 快速: 1, # 1级 - 快速分析 基础: 2, # 2级 - 基础分析 标准: 3, # 3级 - 标准分析推荐 深度: 4, # 4级 - 深度分析 全面: 5 # 5级 - 全面分析 } d depth_map.get(self.research_depth, 3) # 默认标准分析参数二analyst_multiplier分析师数量系数考虑到分析师之间存在并行处理系数采用非线性增长设计而非简单的线性叠加分析师数量系数说明1 个1.0基准2 个1.5约 1.5 倍时间3 个2.0实测验证4级 3分析师 660 秒4 个2.4约 2.4 倍时间5 个及以上2.4 (n-4) × 0.3每增加 1 个分析师增加 30%代码中的实现为analyst_count len(self.analysts) if analyst_count 1: analyst_multiplier 1.0 elif analyst_count 2: analyst_multiplier 1.5 elif analyst_count 3: analyst_multiplier 2.0 elif analyst_count 4: analyst_multiplier 2.4 else: analyst_multiplier 2.4 (analyst_count - 4) * 0.3参数三model_mult模型速度系数不同 LLM 提供商的速度差异通过系数体现提供商系数语义qwen / dashscope1.0标准速度阿里百炼 / 通义千问deepseek0.8快约 20%google1.2慢约 20%其他未识别1.0默认按标准处理值得注意的是__init__中传入的llm_provider会先经过tradingagents/llm_clients/provider_keys.py的normalize_provider_key()归一化处理例如阿里百炼百炼会被归一化为qwen详见 provider_keys.py而model_mult字典同时包含qwen与dashscope两个键且均映射为 1.0因此无论提供商以哪种写法传入都能稳定命中正确的系数。数据流从用户提交到前端展示的完整链路修复后的预估总时长贯穿以下完整数据流1. 用户提交分析请求 ↓ 2. 创建 RedisProgressTracker 实例 ↓ 3. __init__() 方法初始化 ↓ 4. 调用 _get_base_total_time() 计算预估总时长 ↓ 5. 设置 progress_data[estimated_total_time] ↓ 6. 调用 _save_progress() 保存到 Redis/文件 ↓ 7. 前端轮询 /api/analysis/progress/{task_id} ↓ 8. 后端返回 progress_data包含 estimated_total_time ↓ 9. 前端显示预计总时长后端创建与推进在 analysis_service.py 中单股分析任务通过线程池异步执行任务启动时会以task_id、selected_analysts、research_depth为参数创建RedisProgressTracker实例并缓存到self._progress_trackers随后立即调用update_progress( 开始股票分析)触发首次进度更新。在update_progress()中见 tracker.py每次进度更新都会调用_calculate_time_estimates()重新计算三组时间elapsed_time当前时间减start_timeest_total进度未达 100% 时取_get_base_total_time()的固定预估值任务完成后则等于实际elapsedremaining_timemax(0, est_total - elapsed)即预估总时长减去已用时间保证不为负数。这保证了任务运行过程中预计剩余会随已用时间线性递减体验上更加真实。前端轮询与展示前端 SingleAnalysis.vue 以 5 秒为间隔轮询任务状态接口。updateProgressInfo()函数见 L1151-L1205直接消费后端返回值// 接收后端返回的时间数据 if (status.elapsed_time ! undefined) { progressInfo.value.elapsedTime status.elapsed_time } if (status.remaining_time ! undefined) { progressInfo.value.remainingTime status.remaining_time } if (status.estimated_total_time ! undefined) { progressInfo.value.totalTime status.estimated_total_time }前端不做任何二次估算源码注释明确前端不进行估算只展示后端返回的数据展示层通过formatTime()将秒数格式化为X分Y秒 / X分钟 / X小时X分钟见 L1811-L1827秒数非法或为 0 时显示计算中...。因此后端返回的estimated_total_time是否准确、是否在初始化阶段就存在直接决定了前端预计总时长栏目的显示质量。此外analysis.py 中的任务状态接口还包含 MongoDB 恢复路径当任务从analysis_tasks进行中或analysis_reports已完成集合恢复时会分别以 0 或实际耗时填充estimated_total_time与 Redis/文件路径返回的进度结构保持一致前端无需区分数据来源。测试验证三种典型场景全通过仓库提供了专项测试脚本 scripts/test_estimated_total_time.py直接构造RedisProgressTracker实例并断言to_dict()返回的estimated_total_time是否等于理论值。场景 14级深度 3个分析师 dashscope预期330 × 2.0 × 1.0 660 秒11 分钟结果✅ 任务ID: test_task_1 ✅ 分析师数量: 3 ✅ 研究深度: 深度 ✅ LLM提供商: dashscope ✅ 预估总时长: 660.0 秒 (11.0 分钟) ✅ 预计剩余时间: 660.0 秒 (11.0 分钟) ✅ 预估总时长正确: 660.0 秒 (预期: 660.0 秒)场景 21级快速 1个分析师 deepseek预期150 × 1.0 × 0.8 120 秒2 分钟结果✅ 任务ID: test_task_2 ✅ 分析师数量: 1 ✅ 研究深度: 快速 ✅ LLM提供商: deepseek ✅ 预估总时长: 120.0 秒 (2.0 分钟) ✅ 预计剩余时间: 120.0 秒 (2.0 分钟) ✅ 预估总时长正确: 120.0 秒 (预期: 120.0 秒)场景 35级全面 4个分析师 google预期480 × 2.4 × 1.2 1382.4 秒23 分钟结果✅ 任务ID: test_task_3 ✅ 分析师数量: 4 ✅ 研究深度: 全面 ✅ LLM提供商: google ✅ 预估总时长: 1382.4 秒 (23.0 分钟) ✅ 预计剩余时间: 1382.4 秒 (23.0 分钟) ✅ 预估总时长正确: 1382.4 秒 (预期: 1382.4 秒)测试结论 ✅ 所有测试通过 测试脚本的三个场景覆盖了深度/系数/模型三个维度的交叉组合从侧面对_get_base_total_time()的参数表做了端到端验证。修复效果对比修复前场景预期时长前端显示匹配度4级 3个分析师11分钟19分钟❌ 错误1级 1个分析师2分钟未知❌ 错误5级 4个分析师23分钟未知❌ 错误修复后场景预期时长后端返回匹配度4级 3个分析师11分钟11分钟✅ 完美1级 1个分析师2分钟2分钟✅ 完美5级 4个分析师23分钟23分钟✅ 完美相关修复与演进脉络本次修复是继时间估算算法优化之后的补充修复两者共同构成了预估总时长能力的完整闭环算法层修复docs/time_estimation_optimization.md重写_get_base_total_time()算法将支持的深度级别从 3 级扩展到 5 级基于实际测试数据4级深度 3分析师实测 11.02 分钟等校准基础时间与系数将预估误差从265% 降低到 ±10%并同步更新前端depthOptions中 1-5 级的时间范围说明见 SingleAnalysis.vue。初始化层修复本次docs/fixes/performance/estimated_total_time_fix.md修复__init__()未设置estimated_total_time的字段缺失问题确保任务创建瞬间即有准确的预估总时长可供前端读取完善了从创建、推进、持久化到恢复的完整时间数据流。总结与后续优化方向问题根源初始化progress_data时未设置estimated_total_time字段导致to_dict()回退默认值 0前端拿到 0 后渲染出错误或未知的时长。修复方案在__init__()方法中调用_get_base_total_time()计算预估总时长并同步设置estimated_total_time与remaining_time随后立即_save_progress()持久化。修复效果✅ 后端正确计算预估总时长✅ 前端正确显示预估总时长✅ 所有测试场景通过✅ 用户体验提升后续建议继续收集实际分析耗时数据定期校准base_time_per_depth、analyst_multiplier与model_mult参数考虑引入更多影响因素如网络延迟、数据源响应时间、股票市场类型A股 / 美股 / 港股与交易时段状态探索运行过程中的动态调整机制结合历史任务数据与实时进度使用移动平均等平滑算法让预估时间随分析推进持续收敛。相关文档与脚本docs/time_estimation_optimization.md - 时间估算算法优化前置修复docs/fixes/performance/estimated_total_time_fix.md - 本次初始化字段修复scripts/test_estimated_total_time.py - 预估总时长测试脚本app/services/progress/tracker.py - RedisProgressTracker 核心实现frontend/src/views/Analysis/SingleAnalysis.vue - 前端进度展示与轮询【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
TradingAgents-CN 分析任务预估总时长显示错误修复：从根因定位到时间估算算法全解析
TradingAgents-CN 分析任务预估总时长显示错误修复从根因定位到时间估算算法全解析【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN本篇技术指南聚焦 TradingAgents-CN 多智能体分析框架中预计总时长显示错误的完整修复过程。文章以修复文档为骨架结合仓库源码app/services/progress/tracker.py、测试脚本scripts/test_estimated_total_time.py与前端轮询实现从问题现象、根因定位、修复方案到时间估算算法的参数设计逐一展开。读完本文你将掌握 RedisProgressTracker 初始化时序、预估总时长算法研究深度 × 分析师系数 × 模型系数的底层原理以及如何通过测试脚本验证前后端时间数据的一致性。问题现象前端显示的预计总时长为何与预期不符用户在使用 TradingAgents-CN 提交股票分析任务时发现前端页面展示的预计总时长与后端算法计算出的结果不一致。以一组典型配置为例研究深度4级 - 深度分析分析师3个市场分析师、新闻分析师、基本面分析师LLM 提供商dashscope预期结果预计总时长 11 分钟。依据后端算法330 秒 × 2.0 × 1.0 660 秒 11 分钟。实际结果前端显示19 分钟与预期严重偏离。此外在1级快速 1个分析师、5级全面 4个分析师等场景下前端显示未知或错误的时长用户无法获得准确的任务耗时预期。根本原因初始化时未写入 estimated_total_time 字段通过代码定位问题源头在app/services/progress/tracker.py的RedisProgressTracker.__init__()方法中。有缺陷的初始化代码初始化progress_data字典时虽然包含elapsed_time已用时间和remaining_time剩余时间但遗漏了estimated_total_time预估总时长字段# 进度数据修复前 self.progress_data { task_id: task_id, status: running, progress_percentage: 0.0, current_step: 0, total_steps: 0, current_step_name: 初始化, current_step_description: 准备开始分析, last_message: 分析任务已启动, start_time: time.time(), last_update: time.time(), elapsed_time: 0.0, remaining_time: 0.0, steps: [] } # ❌ 缺少 estimated_total_time 字段缺陷传导链路缺失字段会沿数据流逐级放大为错误的展示结果to_dict()方法从progress_data中读取estimated_total_time见 tracker.py当字段不存在时通过self.progress_data.get(estimated_total_time, 0)返回默认值0该 0 值随进度数据一起被序列化保存到 Redis 或本地文件前端轮询进度接口拿到 0 后可能回退到自身的默认值或沿用旧任务残留值最终渲染出 19 分钟这类错误时长。值得说明的是_calculate_static_time_estimates()虽然提供了兜底逻辑当进度数据中没有estimated_total_time时使用默认值 300 秒见 tracker.py但这只作用于历史任务的读取恢复路径get_progress_by_id无法覆盖新任务创建瞬间的初始化路径因此任务启动后前端拿到的第一份进度数据依然是残缺的。修复方案初始化时即时计算并写入预估总时长修复的核心思路是在__init__()中生成分析步骤之后、首次保存进度之前立即调用_get_base_total_time()计算出预估总时长并同步写入estimated_total_time与remaining_time两个字段。修复后的初始化逻辑# 进度数据 self.progress_data { task_id: task_id, status: running, progress_percentage: 0.0, current_step: 0, total_steps: 0, current_step_name: 初始化, current_step_description: 准备开始分析, last_message: 分析任务已启动, start_time: time.time(), last_update: time.time(), elapsed_time: 0.0, remaining_time: 0.0, steps: [] } # 生成分析步骤 self.analysis_steps self._generate_dynamic_steps() self.progress_data[total_steps] len(self.analysis_steps) self.progress_data[steps] [asdict(step) for step in self.analysis_steps] # 计算并设置预估总时长 base_total_time self._get_base_total_time() self.progress_data[estimated_total_time] base_total_time self.progress_data[remaining_time] base_total_time # 初始时剩余时间 总时长 # 保存初始状态 self._save_progress()关键改动点调用_get_base_total_time()在任务初始化的第一时刻完成预估总时长的计算而不是等后续update_progress()时才被动补充设置estimated_total_time确保to_dict()序列化、Redis/文件持久化、前端轮询返回的每一步都能拿到该字段设置remaining_time初始时任务尚未执行剩余时间应等于预估总时长避免前端一开始就显示 0。修复后_save_progress()会在初始化阶段立即持久化包含estimated_total_time的完整进度快照Redis 存储键为progress:{task_id}过期时间 3600 秒文件存储路径为./data/progress/{task_id}.json详见 tracker.py。时间估算算法预估总时长从哪来修复之所以能给出 11 分钟、2 分钟、23 分钟等精确数值依赖于_get_base_total_time()中一套基于实际测试数据校准的估算算法。该方法的完整实现在 tracker.py。算法公式total_time base_time_per_depth × analyst_multiplier × model_mult三个因子分别对应研究深度、分析师规模与 LLM 模型速度彼此独立、相乘耦合。参数一base_time_per_depth研究深度基础耗时五个分析深度级别与单分析师基础耗时单位秒的映射关系级别深度名称基础耗时折算1级快速150 秒2.5 分钟2级基础180 秒3 分钟3级标准240 秒4 分钟4级深度330 秒5.5 分钟5级全面480 秒8 分钟深度名称通过depth_map字典映射为数字级别未知名称时默认按 3 级标准处理基础耗时兜底值为 240 秒depth_map { 快速: 1, # 1级 - 快速分析 基础: 2, # 2级 - 基础分析 标准: 3, # 3级 - 标准分析推荐 深度: 4, # 4级 - 深度分析 全面: 5 # 5级 - 全面分析 } d depth_map.get(self.research_depth, 3) # 默认标准分析参数二analyst_multiplier分析师数量系数考虑到分析师之间存在并行处理系数采用非线性增长设计而非简单的线性叠加分析师数量系数说明1 个1.0基准2 个1.5约 1.5 倍时间3 个2.0实测验证4级 3分析师 660 秒4 个2.4约 2.4 倍时间5 个及以上2.4 (n-4) × 0.3每增加 1 个分析师增加 30%代码中的实现为analyst_count len(self.analysts) if analyst_count 1: analyst_multiplier 1.0 elif analyst_count 2: analyst_multiplier 1.5 elif analyst_count 3: analyst_multiplier 2.0 elif analyst_count 4: analyst_multiplier 2.4 else: analyst_multiplier 2.4 (analyst_count - 4) * 0.3参数三model_mult模型速度系数不同 LLM 提供商的速度差异通过系数体现提供商系数语义qwen / dashscope1.0标准速度阿里百炼 / 通义千问deepseek0.8快约 20%google1.2慢约 20%其他未识别1.0默认按标准处理值得注意的是__init__中传入的llm_provider会先经过tradingagents/llm_clients/provider_keys.py的normalize_provider_key()归一化处理例如阿里百炼百炼会被归一化为qwen详见 provider_keys.py而model_mult字典同时包含qwen与dashscope两个键且均映射为 1.0因此无论提供商以哪种写法传入都能稳定命中正确的系数。数据流从用户提交到前端展示的完整链路修复后的预估总时长贯穿以下完整数据流1. 用户提交分析请求 ↓ 2. 创建 RedisProgressTracker 实例 ↓ 3. __init__() 方法初始化 ↓ 4. 调用 _get_base_total_time() 计算预估总时长 ↓ 5. 设置 progress_data[estimated_total_time] ↓ 6. 调用 _save_progress() 保存到 Redis/文件 ↓ 7. 前端轮询 /api/analysis/progress/{task_id} ↓ 8. 后端返回 progress_data包含 estimated_total_time ↓ 9. 前端显示预计总时长后端创建与推进在 analysis_service.py 中单股分析任务通过线程池异步执行任务启动时会以task_id、selected_analysts、research_depth为参数创建RedisProgressTracker实例并缓存到self._progress_trackers随后立即调用update_progress( 开始股票分析)触发首次进度更新。在update_progress()中见 tracker.py每次进度更新都会调用_calculate_time_estimates()重新计算三组时间elapsed_time当前时间减start_timeest_total进度未达 100% 时取_get_base_total_time()的固定预估值任务完成后则等于实际elapsedremaining_timemax(0, est_total - elapsed)即预估总时长减去已用时间保证不为负数。这保证了任务运行过程中预计剩余会随已用时间线性递减体验上更加真实。前端轮询与展示前端 SingleAnalysis.vue 以 5 秒为间隔轮询任务状态接口。updateProgressInfo()函数见 L1151-L1205直接消费后端返回值// 接收后端返回的时间数据 if (status.elapsed_time ! undefined) { progressInfo.value.elapsedTime status.elapsed_time } if (status.remaining_time ! undefined) { progressInfo.value.remainingTime status.remaining_time } if (status.estimated_total_time ! undefined) { progressInfo.value.totalTime status.estimated_total_time }前端不做任何二次估算源码注释明确前端不进行估算只展示后端返回的数据展示层通过formatTime()将秒数格式化为X分Y秒 / X分钟 / X小时X分钟见 L1811-L1827秒数非法或为 0 时显示计算中...。因此后端返回的estimated_total_time是否准确、是否在初始化阶段就存在直接决定了前端预计总时长栏目的显示质量。此外analysis.py 中的任务状态接口还包含 MongoDB 恢复路径当任务从analysis_tasks进行中或analysis_reports已完成集合恢复时会分别以 0 或实际耗时填充estimated_total_time与 Redis/文件路径返回的进度结构保持一致前端无需区分数据来源。测试验证三种典型场景全通过仓库提供了专项测试脚本 scripts/test_estimated_total_time.py直接构造RedisProgressTracker实例并断言to_dict()返回的estimated_total_time是否等于理论值。场景 14级深度 3个分析师 dashscope预期330 × 2.0 × 1.0 660 秒11 分钟结果✅ 任务ID: test_task_1 ✅ 分析师数量: 3 ✅ 研究深度: 深度 ✅ LLM提供商: dashscope ✅ 预估总时长: 660.0 秒 (11.0 分钟) ✅ 预计剩余时间: 660.0 秒 (11.0 分钟) ✅ 预估总时长正确: 660.0 秒 (预期: 660.0 秒)场景 21级快速 1个分析师 deepseek预期150 × 1.0 × 0.8 120 秒2 分钟结果✅ 任务ID: test_task_2 ✅ 分析师数量: 1 ✅ 研究深度: 快速 ✅ LLM提供商: deepseek ✅ 预估总时长: 120.0 秒 (2.0 分钟) ✅ 预计剩余时间: 120.0 秒 (2.0 分钟) ✅ 预估总时长正确: 120.0 秒 (预期: 120.0 秒)场景 35级全面 4个分析师 google预期480 × 2.4 × 1.2 1382.4 秒23 分钟结果✅ 任务ID: test_task_3 ✅ 分析师数量: 4 ✅ 研究深度: 全面 ✅ LLM提供商: google ✅ 预估总时长: 1382.4 秒 (23.0 分钟) ✅ 预计剩余时间: 1382.4 秒 (23.0 分钟) ✅ 预估总时长正确: 1382.4 秒 (预期: 1382.4 秒)测试结论 ✅ 所有测试通过 测试脚本的三个场景覆盖了深度/系数/模型三个维度的交叉组合从侧面对_get_base_total_time()的参数表做了端到端验证。修复效果对比修复前场景预期时长前端显示匹配度4级 3个分析师11分钟19分钟❌ 错误1级 1个分析师2分钟未知❌ 错误5级 4个分析师23分钟未知❌ 错误修复后场景预期时长后端返回匹配度4级 3个分析师11分钟11分钟✅ 完美1级 1个分析师2分钟2分钟✅ 完美5级 4个分析师23分钟23分钟✅ 完美相关修复与演进脉络本次修复是继时间估算算法优化之后的补充修复两者共同构成了预估总时长能力的完整闭环算法层修复docs/time_estimation_optimization.md重写_get_base_total_time()算法将支持的深度级别从 3 级扩展到 5 级基于实际测试数据4级深度 3分析师实测 11.02 分钟等校准基础时间与系数将预估误差从265% 降低到 ±10%并同步更新前端depthOptions中 1-5 级的时间范围说明见 SingleAnalysis.vue。初始化层修复本次docs/fixes/performance/estimated_total_time_fix.md修复__init__()未设置estimated_total_time的字段缺失问题确保任务创建瞬间即有准确的预估总时长可供前端读取完善了从创建、推进、持久化到恢复的完整时间数据流。总结与后续优化方向问题根源初始化progress_data时未设置estimated_total_time字段导致to_dict()回退默认值 0前端拿到 0 后渲染出错误或未知的时长。修复方案在__init__()方法中调用_get_base_total_time()计算预估总时长并同步设置estimated_total_time与remaining_time随后立即_save_progress()持久化。修复效果✅ 后端正确计算预估总时长✅ 前端正确显示预估总时长✅ 所有测试场景通过✅ 用户体验提升后续建议继续收集实际分析耗时数据定期校准base_time_per_depth、analyst_multiplier与model_mult参数考虑引入更多影响因素如网络延迟、数据源响应时间、股票市场类型A股 / 美股 / 港股与交易时段状态探索运行过程中的动态调整机制结合历史任务数据与实时进度使用移动平均等平滑算法让预估时间随分析推进持续收敛。相关文档与脚本docs/time_estimation_optimization.md - 时间估算算法优化前置修复docs/fixes/performance/estimated_total_time_fix.md - 本次初始化字段修复scripts/test_estimated_total_time.py - 预估总时长测试脚本app/services/progress/tracker.py - RedisProgressTracker 核心实现frontend/src/views/Analysis/SingleAnalysis.vue - 前端进度展示与轮询【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
原理及MATLAB实现)
