TradingAgents-CN 实时 PE/PB 计算实施方案基于 30 秒行情快照的动态估值体系改造【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN导读本文档完整讲解 TradingAgents-CN 中实时 PE/PB 计算专项的实施规划与落地细节。该方案针对分析报告、股票详情、筛选与自选股等场景中估值指标滞后依赖stock_basic_info前一日收盘数据的问题利用现有market_quotes集合每 30 秒更新的实时价格结合最新财报与 Tushare TTM 数据反推动态 PE/PB无需引入任何额外数据源或基础设施。读完本文你将掌握动态市盈率/市净率的计算原理、realtime_metrics.py核心工具模块的函数设计、后端四类接口与前端三处页面的集成方式以及配套的单元测试、集成测试与性能验收标准。背景PE/PB 为什么需要实时化用户反馈指出当前系统展示的 PE 和 PB 并非实时更新可能影响分析结果的准确性。方案文档确认了以下三个事实性问题数据源滞后PE/PB 数据来自stock_basic_info集合需要手动触发同步任务后才会刷新时间粒度粗数据使用的是前一个交易日的收盘价属于日频快照波动放大偏差当股价日内大幅波动时基于旧收盘价计算的 PE/PB 与真实估值会出现明显偏差进而误导分析报告与投资决策。解决思路复用现有基础设施零新增依赖方案的核心思路非常克制直接利用项目中已经存在、每 30 秒刷新一次的market_quotes集合以实时价格为分子、以最新财报或 Tushare TTM 净利润为分母在应用层实时计算 PE/PB。这样数据实时性从每日一次提升到30 秒级不引入新的数据供应商、新集合或新服务实现简单、风险可控、性能影响小。影响范围全景图后端接口接口文件影响优先级分析数据流tradingagents/dataflows/optimized_china_data.py分析报告中的 PE/PB高股票详情-基本面app/routers/stocks.py的get_fundamentals()详情页基本面快照高股票筛选app/routers/screening.py筛选结果中的 PE/PB高自选股列表app/routers/favorites.py自选股的 PE/PB中前端页面页面文件使用场景优先级股票详情页frontend/src/views/Stocks/Detail.vue基本面快照显示 PE高股票筛选页frontend/src/views/Screening/index.vue筛选条件和结果列表高自选股页面frontend/src/views/Favorites/index.vue自选股列表如果显示 PE/PB中分析报告各分析相关页面报告中的估值指标高第一步核心工具模块realtime_metrics.py方案文档规划新建tradingagents/dataflows/realtime_metrics.py该文件已在当前仓库中实际落地且实现比初版规划更加精细。模块共暴露三个函数calculate_realtime_pe_pb、validate_pe_pb、get_pe_pb_with_fallback。计算原理从直接相除升级为TTM 反推 实时市值规划文档中的初版算法是实时市值 实时价格 × 总股本PE 实时市值 / 净利润PB 实时市值 / 净资产。落地版本在此基础上做了关键升级见 realtime_metrics.py优先使用 Tushare 数据源从stock_basic_info中按{code: code6, source: tushare}精确查询因为只有 Tushare 数据源包含pe_ttm、total_mv、total_share等关键字段若找不到 Tushare 数据会诊断性地列出该股票在 MongoDB 中存在的全部数据源并给出运行 Tushare 数据同步任务的明确建议反推 TTM 净利润TTM 净利润 昨日市值 / Tushare PE_TTM其中昨日市值优先用总股本 × 昨日收盘价pre_close计算避免单季度财务数据带来的抖动计算动态 PE_TTM动态 PE_TTM 实时市值 / TTM 净利润其中实时市值 总股本万股× 实时股价元/ 10000亿元动态 PB从stock_financial_data取最新报告期按report_period降序的total_equity净资产元换算为亿元后计算PB 实时市值 / 净资产若无财务数据则降级使用 Tushare 的静态 PB。多方案总股本推导实时市值的计算依赖总股本落地实现针对stock_basic_info与market_quotes的数据完整度提供了四种推导方案方案 1直接使用stock_basic_info.total_share万股并用pre_close计算昨日市值方案 2无total_share但有pre_close与total_mv时先判断stock_basic_info是昨日数据还是今日收盘后数据再用pre_close或realtime_price反推总股本方案 3仅有total_mv时假设其为昨日市值并用realtime_price反推股本同时输出警告日志方案 4以上均缺失时判定计算失败并返回None。时区与收盘后免计算优化实现中加入了北京时间Asia/Shanghai时区判断若stock_basic_info的更新时间是今天 15:00 收盘之后说明数据已是当日最新直接返回其中数据sourcestock_basic_info_latestis_realtimeFalse避免无意义的重复计算。异步客户端兼容由于该模块既会被异步 FastAPI 路由调用也会被数据流同步调用函数内部会检查客户端类型名AsyncIOMotorClient/Motor检测到异步客户端时自动通过MongoClient(settings.MONGO_URI)创建同步客户端保证在两种调用环境下都能正常工作realtime_metrics.py。返回结果结构{ pe: 22.5, # 动态市盈率基于 TTM pb: 3.2, # 动态市净率 pe_ttm: 23.1, # 动态市盈率TTM price: 11.0, # 当前价格 market_cap: 110.5, # 实时市值亿元 ttm_net_profit: 4.8, # TTM 净利润亿元从 Tushare 反推 updated_at: 2025-10-14T10:30:00, source: realtime_calculated_from_market_quotes, is_realtime: True }实际实现还额外返回total_shares总股本万股、yesterday_close昨日收盘价参考、tushare_pe_ttm、tushare_pe等参考字段方便排查数据来源。计算失败时返回None。数据合理性校验validate_pe_pb为防止脏数据污染下游模块提供校验函数realtime_metrics.pyPE 合理范围-100 到 1000允许负值因为亏损企业 PE 为负PB 合理范围0.1 到 100None值视为合法跳过对应项校验超出范围时记录warning日志并返回False。智能降级策略get_pe_pb_with_fallback该函数是各接口统一调用的入口realtime_metrics.py实现两层策略方案 1动态计算调用calculate_realtime_pe_pb结果通过validate_pe_pb校验后直接返回方案 2Tushare 静态降级动态计算失败或数据异常时回退到stock_basic_info中 Tushare 源的静态pe/pe_ttm/pb/pb_mrq基于最近交易日收盘价返回sourcedaily_basic、is_realtimeFalse并附带数据更新时间保证接口在任何情况下都有值可用。整个过程带有详细的分层日志[PE智能策略]前缀便于在生产环境追踪每一步的决策路径。第二步后端接口集成股票详情接口get_fundamentals()在 app/routers/stocks.py 中get_fundamentals()在组装基本面快照时接入实时计算。由于get_pe_pb_with_fallback是同步函数FastAPI 异步路由通过asyncio.to_thread将其放入线程池执行避免阻塞事件循环# 3. 获取实时PE/PB优先使用实时计算 from tradingagents.dataflows.realtime_metrics import get_pe_pb_with_fallback import asyncio # 在线程池中执行同步的实时计算 realtime_metrics await asyncio.to_thread( get_pe_pb_with_fallback, code6, db.client ) # 估值指标优先使用实时计算降级到 stock_basic_info pe: realtime_metrics.get(pe) or b.get(pe), pb: realtime_metrics.get(pb) or b.get(pb), pe_ttm: realtime_metrics.get(pe_ttm) or b.get(pe_ttm), pb_mrq: realtime_metrics.get(pb_mrq) or b.get(pb_mrq), # PE/PB 数据来源标识 pe_source: realtime_metrics.get(source, unknown), pe_is_realtime: realtime_metrics.get(is_realtime, False), pe_updated_at: realtime_metrics.get(updated_at),接口同时新增了pe_source数据来源标识、pe_is_realtime是否实时、pe_updated_at数据更新时间三个元信息字段并在此基础上对市值做同样的实时化有实时市值时total_mv取实时值且mv_is_realtimeTrue否则回退到静态市值。这些字段随后被前端用于展示实时标签。分析数据流optimized_china_data.py在 tradingagents/dataflows/optimized_china_data.py 中PE/PB 获取逻辑被重构为多层策略第 1 层实时计算调用get_pe_pb_with_fallback成功且校验通过后写入metrics[pe]/metrics[pe_ttm]/metrics[pb]并附加realtime_tag实时标识亏损股pe_ttm为None、 0、nan或--会被单独识别并跳过降级避免对亏损企业显示误导性负 PE第 2 层静态降级实时层失败时回退到stock_basic_info.pe_ttm等静态字段同样对负值/零值/格式异常做兜底处理对 AKShare 数据源路径第 1395-1442 行附近也建立了同构的实时计算优先逻辑保证不同数据源链路行为一致。最终报告中的 PE/PB 会体现为类似23.1倍 (实时)的文案让分析报告的估值指标可追溯、可信任。股票筛选服务app/services/enhanced_screening_service.py 在返回筛选结果前调用_enrich_results_with_realtime_metrics(items)。需要注意的是落地实现基于工程权衡做了取舍筛选场景默认使用stock_basic_info中的静态 PE/PB见 enhanced_screening_service.py 中的注释说明原因是批量计算动态 PE 需要逐只股票查询多个集合会带来严重的性能问题而静态 PE 基于最近一个交易日的收盘价对批量筛选这种相对粗粒度的场景已经足够准确。实时计算能力保留在单只股票的详情页等场景中使用。这与方案文档中批量计算以提高性能的设想一致也印证了性能优先的设计原则。第三步前端显示优化股票详情页Detail.vue在 frontend/src/views/Stocks/Detail.vue 中接口返回的pe_is_realtime被映射到前端状态basics.peIsRealtime。显示层在 PE 数值旁渲染一个成功色小标签实时让用户一眼识别数据的时效性div classfact spanPE(TTM)/span b {{ Number.isFinite(basics.pe) ? basics.pe.toFixed(2) : - }} el-tag v-ifbasics.pe_is_realtime typesuccess sizesmall stylemargin-left: 4px实时/el-tag /b /div股票筛选页Screening/index.vue在 frontend/src/views/Screening/index.vue 中市盈率与市净率两列表格单元均增加了实时标签渲染逻辑无值或非数字时优雅降级为占位符el-table-column proppe label市盈率 width120 alignright template #default{ row } span v-ifrow.pe {{ row.pe?.toFixed(2) }} el-tag v-ifrow.pe_is_realtime typesuccess sizesmall实时/el-tag /span span v-else classtext-gray-400-/span /template /el-table-column类型声明frontend/src/api/stocks.ts 中为接口响应类型补充了pe_is_realtime?: boolean字段注释保证前端类型安全。第四步测试计划单元测试已落地方案规划的新建测试文件 tests/dataflows/test_realtime_metrics.py 已在仓库中实现覆盖以下场景test_validate_pe_pb验证正常范围如(20.5, 3.2)、PE 过大1500、PE 过小-150、PB 过大150、PB 过小0.05以及None值(None, 3.2)、(20.5, None)、(None, None)等全部边界test_calculate_realtime_pe_pb_with_mock_data通过 Mock MongoDB 集合验证完整计算链路——close10.5、total_share100000万股、net_profit50000万元、total_hldr_eqy_exc_min_int200000万元时断言pe 21.01050000 万 / 50000 万、pb 5.251050000 万 / 200000 万、price 10.5、is_realtime Truetest_calculate_realtime_pe_pb_missing_data数据缺失时返回Nonetest_get_pe_pb_with_fallback_success实时计算成功时直接返回实时结果test_get_pe_pb_with_fallback_to_static实时计算失败时通过 monkeypatch 降级到静态daily_basic数据is_realtime False、source daily_basic。集成测试方案文档给出了三条集成验收路径股票详情接口验证响应中包含pe_is_realtime: true与pe_source: realtime_calculated实际源码中 source 值为realtime_calculated_from_market_quotescurl -H Authorization: Bearer token \ http://localhost:8000/api/stocks/000001/fundamentals股票筛选接口验证返回列表中 PE/PB 字段与实时计算一致curl -X POST -H Authorization: Bearer token \ -H Content-Type: application/json \ -d {conditions: {logic: AND, children: []}} \ http://localhost:8000/api/screening/screen分析功能触发单股分析检查分析报告中的 PE/PB 是否使用实时数据。性能验收标准方案文档明确了三档性能目标可作为上线前的量化验收依据场景目标单只股票实时计算 50ms批量计算100 只股票 2s筛选接口整体耗时与现有性能相当增幅 20%上线计划与当前进度方案文档给出三阶段推进节奏其中第一阶段首项创建realtime_metrics.py工具模块在仓库中已完成标记[x]后端详情接口与分析数据流集成、单元测试均已落地第一阶段核心功能1 天创建realtime_metrics.py工具模块修改股票详情接口修改分析数据流基本测试验证第二阶段完善功能2 天修改股票筛选服务前端显示优化添加数据时效性标识完整测试第三阶段优化和监控1 周添加缓存机制性能优化监控和告警文档完善风险与缓解措施风险 1性能影响实时计算可能增加接口响应时间尤其在批量场景。缓解措施包括为计算结果添加 30 秒缓存、批量计算优化筛选场景已实践为静态数据兜底、将同步计算放入线程池避免阻塞异步事件循环asyncio.to_thread模式。风险 2数据准确性计算结果可能与官方数据存在偏差。缓解措施通过validate_pe_pb做范围校验、在返回值与前端 UI 中明确标注数据来源pe_source/ 实时标签 /pe_updated_at、提供完整的静态数据降级链路。风险 3兼容性可能影响现有功能。缓解措施保持向后兼容实时值缺失时or b.get(pe)回退旧字段、渐进式上线核心链路先行、筛选等批量场景保守处理、充分测试单元测试 集成测试 性能验收。总结本方案在零新增基础设施的前提下借助market_quotes集合 30 秒级实时行情与 Tushare TTM 净利润反推把 PE/PB 的时效性从每日提升到30 秒级别同时通过多方案股本推导、范围校验、智能降级与前端实时标签兼顾了准确性、健壮性与可追溯性。从当前仓库的实际代码看realtime_metrics.py核心模块、股票详情接口、分析数据流与单元测试已经落地为分析报告准确性、投资决策可靠性以及用户界面体验带来了实质性改善。【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 TradingAgents-CN 实时 PE/PB 计算实施方案：基于 30 秒行情快照的动态估值体系改造
TradingAgents-CN 实时 PE/PB 计算实施方案基于 30 秒行情快照的动态估值体系改造【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN导读本文档完整讲解 TradingAgents-CN 中实时 PE/PB 计算专项的实施规划与落地细节。该方案针对分析报告、股票详情、筛选与自选股等场景中估值指标滞后依赖stock_basic_info前一日收盘数据的问题利用现有market_quotes集合每 30 秒更新的实时价格结合最新财报与 Tushare TTM 数据反推动态 PE/PB无需引入任何额外数据源或基础设施。读完本文你将掌握动态市盈率/市净率的计算原理、realtime_metrics.py核心工具模块的函数设计、后端四类接口与前端三处页面的集成方式以及配套的单元测试、集成测试与性能验收标准。背景PE/PB 为什么需要实时化用户反馈指出当前系统展示的 PE 和 PB 并非实时更新可能影响分析结果的准确性。方案文档确认了以下三个事实性问题数据源滞后PE/PB 数据来自stock_basic_info集合需要手动触发同步任务后才会刷新时间粒度粗数据使用的是前一个交易日的收盘价属于日频快照波动放大偏差当股价日内大幅波动时基于旧收盘价计算的 PE/PB 与真实估值会出现明显偏差进而误导分析报告与投资决策。解决思路复用现有基础设施零新增依赖方案的核心思路非常克制直接利用项目中已经存在、每 30 秒刷新一次的market_quotes集合以实时价格为分子、以最新财报或 Tushare TTM 净利润为分母在应用层实时计算 PE/PB。这样数据实时性从每日一次提升到30 秒级不引入新的数据供应商、新集合或新服务实现简单、风险可控、性能影响小。影响范围全景图后端接口接口文件影响优先级分析数据流tradingagents/dataflows/optimized_china_data.py分析报告中的 PE/PB高股票详情-基本面app/routers/stocks.py的get_fundamentals()详情页基本面快照高股票筛选app/routers/screening.py筛选结果中的 PE/PB高自选股列表app/routers/favorites.py自选股的 PE/PB中前端页面页面文件使用场景优先级股票详情页frontend/src/views/Stocks/Detail.vue基本面快照显示 PE高股票筛选页frontend/src/views/Screening/index.vue筛选条件和结果列表高自选股页面frontend/src/views/Favorites/index.vue自选股列表如果显示 PE/PB中分析报告各分析相关页面报告中的估值指标高第一步核心工具模块realtime_metrics.py方案文档规划新建tradingagents/dataflows/realtime_metrics.py该文件已在当前仓库中实际落地且实现比初版规划更加精细。模块共暴露三个函数calculate_realtime_pe_pb、validate_pe_pb、get_pe_pb_with_fallback。计算原理从直接相除升级为TTM 反推 实时市值规划文档中的初版算法是实时市值 实时价格 × 总股本PE 实时市值 / 净利润PB 实时市值 / 净资产。落地版本在此基础上做了关键升级见 realtime_metrics.py优先使用 Tushare 数据源从stock_basic_info中按{code: code6, source: tushare}精确查询因为只有 Tushare 数据源包含pe_ttm、total_mv、total_share等关键字段若找不到 Tushare 数据会诊断性地列出该股票在 MongoDB 中存在的全部数据源并给出运行 Tushare 数据同步任务的明确建议反推 TTM 净利润TTM 净利润 昨日市值 / Tushare PE_TTM其中昨日市值优先用总股本 × 昨日收盘价pre_close计算避免单季度财务数据带来的抖动计算动态 PE_TTM动态 PE_TTM 实时市值 / TTM 净利润其中实时市值 总股本万股× 实时股价元/ 10000亿元动态 PB从stock_financial_data取最新报告期按report_period降序的total_equity净资产元换算为亿元后计算PB 实时市值 / 净资产若无财务数据则降级使用 Tushare 的静态 PB。多方案总股本推导实时市值的计算依赖总股本落地实现针对stock_basic_info与market_quotes的数据完整度提供了四种推导方案方案 1直接使用stock_basic_info.total_share万股并用pre_close计算昨日市值方案 2无total_share但有pre_close与total_mv时先判断stock_basic_info是昨日数据还是今日收盘后数据再用pre_close或realtime_price反推总股本方案 3仅有total_mv时假设其为昨日市值并用realtime_price反推股本同时输出警告日志方案 4以上均缺失时判定计算失败并返回None。时区与收盘后免计算优化实现中加入了北京时间Asia/Shanghai时区判断若stock_basic_info的更新时间是今天 15:00 收盘之后说明数据已是当日最新直接返回其中数据sourcestock_basic_info_latestis_realtimeFalse避免无意义的重复计算。异步客户端兼容由于该模块既会被异步 FastAPI 路由调用也会被数据流同步调用函数内部会检查客户端类型名AsyncIOMotorClient/Motor检测到异步客户端时自动通过MongoClient(settings.MONGO_URI)创建同步客户端保证在两种调用环境下都能正常工作realtime_metrics.py。返回结果结构{ pe: 22.5, # 动态市盈率基于 TTM pb: 3.2, # 动态市净率 pe_ttm: 23.1, # 动态市盈率TTM price: 11.0, # 当前价格 market_cap: 110.5, # 实时市值亿元 ttm_net_profit: 4.8, # TTM 净利润亿元从 Tushare 反推 updated_at: 2025-10-14T10:30:00, source: realtime_calculated_from_market_quotes, is_realtime: True }实际实现还额外返回total_shares总股本万股、yesterday_close昨日收盘价参考、tushare_pe_ttm、tushare_pe等参考字段方便排查数据来源。计算失败时返回None。数据合理性校验validate_pe_pb为防止脏数据污染下游模块提供校验函数realtime_metrics.pyPE 合理范围-100 到 1000允许负值因为亏损企业 PE 为负PB 合理范围0.1 到 100None值视为合法跳过对应项校验超出范围时记录warning日志并返回False。智能降级策略get_pe_pb_with_fallback该函数是各接口统一调用的入口realtime_metrics.py实现两层策略方案 1动态计算调用calculate_realtime_pe_pb结果通过validate_pe_pb校验后直接返回方案 2Tushare 静态降级动态计算失败或数据异常时回退到stock_basic_info中 Tushare 源的静态pe/pe_ttm/pb/pb_mrq基于最近交易日收盘价返回sourcedaily_basic、is_realtimeFalse并附带数据更新时间保证接口在任何情况下都有值可用。整个过程带有详细的分层日志[PE智能策略]前缀便于在生产环境追踪每一步的决策路径。第二步后端接口集成股票详情接口get_fundamentals()在 app/routers/stocks.py 中get_fundamentals()在组装基本面快照时接入实时计算。由于get_pe_pb_with_fallback是同步函数FastAPI 异步路由通过asyncio.to_thread将其放入线程池执行避免阻塞事件循环# 3. 获取实时PE/PB优先使用实时计算 from tradingagents.dataflows.realtime_metrics import get_pe_pb_with_fallback import asyncio # 在线程池中执行同步的实时计算 realtime_metrics await asyncio.to_thread( get_pe_pb_with_fallback, code6, db.client ) # 估值指标优先使用实时计算降级到 stock_basic_info pe: realtime_metrics.get(pe) or b.get(pe), pb: realtime_metrics.get(pb) or b.get(pb), pe_ttm: realtime_metrics.get(pe_ttm) or b.get(pe_ttm), pb_mrq: realtime_metrics.get(pb_mrq) or b.get(pb_mrq), # PE/PB 数据来源标识 pe_source: realtime_metrics.get(source, unknown), pe_is_realtime: realtime_metrics.get(is_realtime, False), pe_updated_at: realtime_metrics.get(updated_at),接口同时新增了pe_source数据来源标识、pe_is_realtime是否实时、pe_updated_at数据更新时间三个元信息字段并在此基础上对市值做同样的实时化有实时市值时total_mv取实时值且mv_is_realtimeTrue否则回退到静态市值。这些字段随后被前端用于展示实时标签。分析数据流optimized_china_data.py在 tradingagents/dataflows/optimized_china_data.py 中PE/PB 获取逻辑被重构为多层策略第 1 层实时计算调用get_pe_pb_with_fallback成功且校验通过后写入metrics[pe]/metrics[pe_ttm]/metrics[pb]并附加realtime_tag实时标识亏损股pe_ttm为None、 0、nan或--会被单独识别并跳过降级避免对亏损企业显示误导性负 PE第 2 层静态降级实时层失败时回退到stock_basic_info.pe_ttm等静态字段同样对负值/零值/格式异常做兜底处理对 AKShare 数据源路径第 1395-1442 行附近也建立了同构的实时计算优先逻辑保证不同数据源链路行为一致。最终报告中的 PE/PB 会体现为类似23.1倍 (实时)的文案让分析报告的估值指标可追溯、可信任。股票筛选服务app/services/enhanced_screening_service.py 在返回筛选结果前调用_enrich_results_with_realtime_metrics(items)。需要注意的是落地实现基于工程权衡做了取舍筛选场景默认使用stock_basic_info中的静态 PE/PB见 enhanced_screening_service.py 中的注释说明原因是批量计算动态 PE 需要逐只股票查询多个集合会带来严重的性能问题而静态 PE 基于最近一个交易日的收盘价对批量筛选这种相对粗粒度的场景已经足够准确。实时计算能力保留在单只股票的详情页等场景中使用。这与方案文档中批量计算以提高性能的设想一致也印证了性能优先的设计原则。第三步前端显示优化股票详情页Detail.vue在 frontend/src/views/Stocks/Detail.vue 中接口返回的pe_is_realtime被映射到前端状态basics.peIsRealtime。显示层在 PE 数值旁渲染一个成功色小标签实时让用户一眼识别数据的时效性div classfact spanPE(TTM)/span b {{ Number.isFinite(basics.pe) ? basics.pe.toFixed(2) : - }} el-tag v-ifbasics.pe_is_realtime typesuccess sizesmall stylemargin-left: 4px实时/el-tag /b /div股票筛选页Screening/index.vue在 frontend/src/views/Screening/index.vue 中市盈率与市净率两列表格单元均增加了实时标签渲染逻辑无值或非数字时优雅降级为占位符el-table-column proppe label市盈率 width120 alignright template #default{ row } span v-ifrow.pe {{ row.pe?.toFixed(2) }} el-tag v-ifrow.pe_is_realtime typesuccess sizesmall实时/el-tag /span span v-else classtext-gray-400-/span /template /el-table-column类型声明frontend/src/api/stocks.ts 中为接口响应类型补充了pe_is_realtime?: boolean字段注释保证前端类型安全。第四步测试计划单元测试已落地方案规划的新建测试文件 tests/dataflows/test_realtime_metrics.py 已在仓库中实现覆盖以下场景test_validate_pe_pb验证正常范围如(20.5, 3.2)、PE 过大1500、PE 过小-150、PB 过大150、PB 过小0.05以及None值(None, 3.2)、(20.5, None)、(None, None)等全部边界test_calculate_realtime_pe_pb_with_mock_data通过 Mock MongoDB 集合验证完整计算链路——close10.5、total_share100000万股、net_profit50000万元、total_hldr_eqy_exc_min_int200000万元时断言pe 21.01050000 万 / 50000 万、pb 5.251050000 万 / 200000 万、price 10.5、is_realtime Truetest_calculate_realtime_pe_pb_missing_data数据缺失时返回Nonetest_get_pe_pb_with_fallback_success实时计算成功时直接返回实时结果test_get_pe_pb_with_fallback_to_static实时计算失败时通过 monkeypatch 降级到静态daily_basic数据is_realtime False、source daily_basic。集成测试方案文档给出了三条集成验收路径股票详情接口验证响应中包含pe_is_realtime: true与pe_source: realtime_calculated实际源码中 source 值为realtime_calculated_from_market_quotescurl -H Authorization: Bearer token \ http://localhost:8000/api/stocks/000001/fundamentals股票筛选接口验证返回列表中 PE/PB 字段与实时计算一致curl -X POST -H Authorization: Bearer token \ -H Content-Type: application/json \ -d {conditions: {logic: AND, children: []}} \ http://localhost:8000/api/screening/screen分析功能触发单股分析检查分析报告中的 PE/PB 是否使用实时数据。性能验收标准方案文档明确了三档性能目标可作为上线前的量化验收依据场景目标单只股票实时计算 50ms批量计算100 只股票 2s筛选接口整体耗时与现有性能相当增幅 20%上线计划与当前进度方案文档给出三阶段推进节奏其中第一阶段首项创建realtime_metrics.py工具模块在仓库中已完成标记[x]后端详情接口与分析数据流集成、单元测试均已落地第一阶段核心功能1 天创建realtime_metrics.py工具模块修改股票详情接口修改分析数据流基本测试验证第二阶段完善功能2 天修改股票筛选服务前端显示优化添加数据时效性标识完整测试第三阶段优化和监控1 周添加缓存机制性能优化监控和告警文档完善风险与缓解措施风险 1性能影响实时计算可能增加接口响应时间尤其在批量场景。缓解措施包括为计算结果添加 30 秒缓存、批量计算优化筛选场景已实践为静态数据兜底、将同步计算放入线程池避免阻塞异步事件循环asyncio.to_thread模式。风险 2数据准确性计算结果可能与官方数据存在偏差。缓解措施通过validate_pe_pb做范围校验、在返回值与前端 UI 中明确标注数据来源pe_source/ 实时标签 /pe_updated_at、提供完整的静态数据降级链路。风险 3兼容性可能影响现有功能。缓解措施保持向后兼容实时值缺失时or b.get(pe)回退旧字段、渐进式上线核心链路先行、筛选等批量场景保守处理、充分测试单元测试 集成测试 性能验收。总结本方案在零新增基础设施的前提下借助market_quotes集合 30 秒级实时行情与 Tushare TTM 净利润反推把 PE/PB 的时效性从每日提升到30 秒级别同时通过多方案股本推导、范围校验、智能降级与前端实时标签兼顾了准确性、健壮性与可追溯性。从当前仓库的实际代码看realtime_metrics.py核心模块、股票详情接口、分析数据流与单元测试已经落地为分析报告准确性、投资决策可靠性以及用户界面体验带来了实质性改善。【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考