TradingAgents-CN 基本面实时调用 TTM 计算修复实战从单期数据高估到 TTM 估值一致性【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN导读本文围绕 TradingAgents-CN 在基本面分析中数据库无数据时实时调用 AKShare / Tushare API场景下的估值失真问题展开完整剖析 PE/PS 因使用单期财务数据被高估 1.334 倍的三个根因并给出推荐修复方案——复用_calculate_ttm_metric在实时调用链路中计算 TTM 指标。读完本文你将掌握该项目实时财务数据解析的两级降级链路、TTM 计算的完整策略与源码实现、以及对应的测试验证方法。问题背景实时调用是基本面分析的兜底路径在 TradingAgents-CN 中基本面数据获取遵循严格的优先级顺序见 optimized_china_data.pyMongoDB 缓存优先从stock_financial_data集合读取已标准化的财务数据_parse_mongodb_financial_data此时 PE/PB/ROE 等指标已经过清洗校验AKShare API 兜底缓存未命中或数据库缓存未启用时实时调用 AKShare 财务接口并解析_parse_akshare_financial_dataTushare API 再次兜底AKShare 不可用或未连接时降级到 Tushare_parse_financial_data。问题正出在第 2、3 条实时调用路径上用户首次查询某只股票且数据库尚无该股财务数据时系统直接消费 API 返回的单期财务数据来计算 PE/PS导致估值严重失真。问题剖析三个导致 PE/PS 高估的根因问题发现于 2025-10-26见 bugfix 文档核心症结可归纳为三类。问题 1AKShare 实时调用用单期 EPS 计算 PE原实现中PE 直接使用 AKShare基本每股收益字段计算# 获取每股收益 - 用于计算PE eps_value indicators_dict.get(基本每股收益) if eps_value is not None and str(eps_value) ! nan and eps_value ! --: try: eps_val float(eps_value) if eps_val 0: # 计算PE 股价 / 每股收益 pe_val price_value / eps_val # ❌ 使用单期EPS metrics[pe] f{pe_val:.1f}倍问题在于 AKShare 的基本每股收益是单期数据可能为 Q1/Q2/Q3 累计值或年报直接用单期 EPS 充当年度 EPS会造成系统性高估最新报告期单期累计含义PE 被高估幅度Q1一季报仅 1 个季度累计约 4 倍Q2半年报上半年累计约 2 倍Q3三季报前三季度累计约 1.33 倍年报全年无偏差问题 2AKShare 实时调用缺少 PS 计算原实现中 PS市销率完全没有参与计算仅被写为占位符# 补充其他指标的默认值 metrics.update({ ps: 待计算, # ❌ 没有实际计算 dividend_yield: 待查询, cash_ratio: 待分析 })用户在该场景下无法获得 PS 指标估值维度不完整。问题 3Tushare 实时调用用单期累计数据计算 PE/PSTushare 利润表接口返回的total_revenue营业总收入与n_income净利润是自年初至报告期的累计值原实现直接将其当作全年数据使用# PE比率使用单期净利润可能不准确 if net_income 0: pe_ratio market_cap / (net_income * 10000) # ❌ 使用单期净利润 metrics[pe] f{pe_ratio:.1f}倍 logger.warning(f⚠️ Tushare PE 使用单期净利润可能不准确) else: metrics[pe] N/A亏损 # PS比率使用单期营业收入可能不准确 if total_revenue 0: ps_ratio market_cap / (total_revenue * 10000) # ❌ 使用单期营业收入 metrics[ps] f{ps_ratio:.1f}倍 logger.warning(f⚠️ Tushare PS 使用单期营业收入可能被高估2-4倍) else: metrics[ps] N/A原代码注释中也留下了明确的整改提示# ⚠️ 警告Tushare income_statement 的 total_revenue 是单期数据可能是季报/半年报 # 理想情况下应该使用 TTM 数据但 Tushare 数据结构中没有预先计算的 TTM 字段 # TODO: 需要从多期数据中计算 TTM影响范围与严重程度触发条件三者同时满足用户首次查询某只股票的基本面数据数据库中尚未存在该股票的财务数据系统降级调用 AKShare 或 Tushare API 实时获取数据。影响程度数据失真PE/PS 被高估 1.334 倍直接进入后续的估值评分_calculate_valuation_score等与投资决策链路体验割裂首次查询得到错误数据待数据同步进数据库后再次查询又得到正确数据前后不一致易造成混淆决策风险估值指标被高估可能误导用户对股票贵贱的判断。该问题被标记为P0 紧急理由是影响基本面分析这一核心功能且数据错误幅度大、可能引发错误投资决策。修复方案对比三条可选路径方案 1实时调用时计算 TTM推荐优点数据准确用户首次查询即得正确结果与数据库侧数据保持一致。缺点需要获取最近 4 期数据API 调用次数增加实现复杂度较高。方案 2实时调用时返回 None强制同步到数据库优点实现简单避免返回不准确数据强制用户使用准确的数据库数据。缺点用户首次查询会失败需要手动触发数据同步用户体验较差。方案 3实时调用时标注数据类型临时方案优点实现简单用户能感知数据可能不准确。缺点仍然返回不准确的数据治标不治本。metrics[pe] f{pe_val:.1f}倍单期可能高估 metrics[ps] f{ps_val:.2f}倍单期可能高估最终决策采用方案 1。理由数据准确性最重要仓库中已有_calculate_ttm_metric函数可直接复用能与数据库数据保持一致用户体验最佳。修复核心_calculate_ttm_metric的 TTM 计算策略TTMTrailing Twelve Months最近 12 个月计算是本次修复的关键基础设施实现在 scripts/sync_financial_data.py。其输入为包含报告期与目标指标列的 DataFrame输出为 TTM 值万元失败返回None。完整策略分三层def _calculate_ttm_metric(df, metric_name: str) - Optional[float]: 计算 TTM最近12个月指标值营业收入、净利润等 策略 1. 如果最新期是年报12月31日直接使用年报数据 2. 如果最新期是中报/季报计算 TTM 最新年报 (本期累计 - 去年同期累计) 3. 如果数据不足返回 None不使用简单年化因为对季节性行业不准确 # 按报告期排序升序 df_sorted df.sort_values(报告期, ascendingTrue).reset_index(dropTrue) latest df_sorted.iloc[-1] latest_period str(latest[报告期]) latest_value _safe_float(latest[metric_name]) # 判断最新期是否是年报报告期以1231结尾 if latest_period.endswith(1231): # 年报直接使用 return latest_value # 非年报需要计算 TTM year int(latest_period[:4]) month_day latest_period[4:] last_year year - 1 last_annual_period f{last_year}1231 # 上一年的年报 last_same_period f{last_year}{month_day} # 去年同期 last_annual_row df_sorted[df_sorted[报告期] last_annual_period] last_same_row df_sorted[df_sorted[报告期] last_same_period] if not last_annual_row.empty and not last_same_row.empty: # TTM 最近年报 (本期累计 - 去年同期累计) ttm_value last_annual_value (latest_value - last_same_value) return ttm_value if ttm_value 0 else None # 数据不足时返回 None绝不使用简单年化对季节性行业不准确 return None三个关键设计点年报直接采用最新报告期以1231结尾时年报本身就是完整 12 个月数据无需加工累计值差分非年报期采用TTM 最近年报 (本期累计 − 去年同期累计)其中本期累计与去年同期累计均取自同一报告期口径如 0930保证差值严格对应最新一个季度的增量拒绝简单年化数据不足缺少基准年报或去年同期时返回None而不是把单期数据 ×4 粗算成年化值——因为对季节性行业而言简单年化同样会引入严重误差。函数同时保留旧接口_calculate_ttm_revenue做向后兼容sync_financial_data.py。修复落地当前仓库中的实时调用实现AKShare 实时解析PE 两级降级 TTM 化修复后的_parse_akshare_financial_dataoptimized_china_data.py将 PE 计算重构为两级降级第 1 层实时 PE/PB 优先L1393-L1449。通过get_pe_pb_with_fallback从 realtime_metrics.py 获取动态 PE实时股价 Tushare 官方 TTM 净利润反推失败时降级到 Tushare 静态pe_ttm/pb_mrqstock_basic_info集合并额外标记数据来源与(实时)标签。第 2 层TTM EPS 计算 PEL1476-L1532。当实时 PE 不可用时从main_indicatorsDataFrame 中抽取全部报告期的基本每股收益构造多期 DataFrame调用_calculate_ttm_metric得到 TTM EPSif 基本每股收益 in main_indicators[指标].values: eps_row main_indicators[main_indicators[指标] 基本每股收益] value_cols [col for col in eps_row.columns if col ! 指标] eps_data [] for col in value_cols: eps_val eps_row[col].iloc[0] if eps_val is not None and str(eps_val) ! nan and eps_val ! --: eps_data.append({报告期: col, 基本每股收益: eps_val}) if len(eps_data) 2: eps_df pd.DataFrame(eps_data) from scripts.sync_financial_data import _calculate_ttm_metric ttm_eps _calculate_ttm_metric(eps_df, 基本每股收益) # 使用 TTM EPS 或单期 EPS 计算 PE eps_for_pe ttm_eps if ttm_eps else None pe_type TTM if ttm_eps else 单期 if eps_for_pe and eps_for_pe 0: pe_val price_value / eps_for_pe metrics[pe] f{pe_val:.1f}倍即有 TTM 用 TTM无 TTM 才降级单期并且日志会明确标注本次 PE 的类型是TTM还是单期便于排查。PS 补齐同样从多期营业收入数据计算 TTM 营业收入L1625-L1676再用市值 股价 × 总股本计算if revenue_for_ps and revenue_for_ps 0: total_share stock_info.get(total_share) if stock_info else None if total_share and total_share 0: # 市值万元 股价元× 总股本万股 market_cap price_value * total_share ps_val market_cap / revenue_for_ps metrics[ps] f{ps_val:.2f}倍至此原文档中问题 2 的ps: 待计算占位符已被真实计算替代AKShare 路径的 PE/PS 均完成 TTM 化。Tushare 实时解析利润表累计值差分修复后的_parse_financial_dataoptimized_china_data.py在计算指标前先把利润表各期total_revenue与n_income分别构造成多期 DataFrame再统一走_calculate_ttm_metric# Tushare income_statement 的数据是累计值从年初到报告期 # 需要使用 TTM 公式计算 for stmt in income_statement: end_date stmt.get(end_date) revenue stmt.get(total_revenue) if end_date and revenue is not None: revenue_data.append({报告期: str(end_date), 营业收入: float(revenue)}) if len(revenue_data) 2: revenue_df pd.DataFrame(revenue_data) from scripts.sync_financial_data import _calculate_ttm_metric ttm_revenue _calculate_ttm_metric(revenue_df, 营业收入) # 净利润同理profit_data.append({报告期: ..., 净利润: float(n_income)})随后在指标计算处以 TTM 值为优先、单期累计值为兜底并显式记录数据口径total_revenue ttm_revenue if ttm_revenue else (latest_income.get(total_revenue, 0) or 0) net_income ttm_net_income if ttm_net_income else (latest_income.get(n_income, 0) or 0) revenue_type TTM if ttm_revenue else 单期 profit_type TTM if ttm_net_income else 单期 # PE比率优先使用 TTM 净利润 if net_income 0: pe_ratio market_cap / (net_income * 10000) metrics[pe] f{pe_ratio:.1f}倍 # PS比率优先使用 TTM 营业收入 if total_revenue 0: ps_ratio market_cap / (total_revenue * 10000) metrics[ps] f{ps_ratio:.1f}倍市值统一由股价 × 总股本 × 10000元推算后换算为亿元L1782-L1791当无法取得总股本时PE/PB/PS 均输出N/A无总股本数据避免使用错误市值产生误导。配套的实时 PE 校验realtime_metrics.py 中的validate_pe_pb为实时估值提供了合理性护栏PE 合理范围-100 ~ 1000允许亏损负值PB 合理范围0.1 ~ 100超出范围即判定异常并触发下一级降级进一步避免脏数据进入用户视图。测试验证TTM 计算的四种场景仓库提供了专门的验证脚本 scripts/test_akshare_ttm_calculation.py用一组含 8 期2023 年报至 2025Q3的真实风格数据覆盖四种场景TTM 营业收入计算正确性以 2025Q3 为最新期手动验证TTM 2024年报(1466.95) (2025Q3累计1006.68 − 2024Q3累计1115.82) 1357.81断言误差小于 0.01TTM 净利润计算正确性同理验证TTM 733.20 (383.39 − 557.91) 558.68并覆盖最新期净利润环比下滑的敏感场景数据不足返回 None仅含 2024Q3 与 2025Q3 两期、缺少年报时必须返回None严禁退化为简单年化对季节性行业不准确年报直接采用最新期为 20241231 时直接返回年报值1466.95 / 733.20不做差分。对应文档中的测试计划还包括端到端验证清空数据库中某只股票的财务数据 → 触发基本面分析 → 校验 PE/PS 是否使用 TTM 口径 → 与数据库侧数据对比确保一致。总结本次修复围绕实时调用链路估值失真这一 P0 问题完成了三项核心改造AKShare 路径的 PE 由单期 EPS 改为多期 TTM EPS并补齐 PS 计算、Tushare 路径的 PE/PS 由单期累计值改为 TTM 差分值、以及统一复用_calculate_ttm_metric作为 TTM 计算的事实标准。修复后用户首次查询实时链路与后续查询数据库链路的估值口径保持一致PE/PS 不再被系统性高估 1.334 倍。后续工作仍包括为两条实时解析路径补充正式单元测试、持续更新文档并在_calculate_ttm_metric数据不足时保持宁缺毋假的降级策略返回None而非简单年化以守住估值数据的准确性底线。【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 TradingAgents-CN 基本面实时调用 TTM 计算修复实战：从单期数据高估到 TTM 估值一致性
TradingAgents-CN 基本面实时调用 TTM 计算修复实战从单期数据高估到 TTM 估值一致性【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN导读本文围绕 TradingAgents-CN 在基本面分析中数据库无数据时实时调用 AKShare / Tushare API场景下的估值失真问题展开完整剖析 PE/PS 因使用单期财务数据被高估 1.334 倍的三个根因并给出推荐修复方案——复用_calculate_ttm_metric在实时调用链路中计算 TTM 指标。读完本文你将掌握该项目实时财务数据解析的两级降级链路、TTM 计算的完整策略与源码实现、以及对应的测试验证方法。问题背景实时调用是基本面分析的兜底路径在 TradingAgents-CN 中基本面数据获取遵循严格的优先级顺序见 optimized_china_data.pyMongoDB 缓存优先从stock_financial_data集合读取已标准化的财务数据_parse_mongodb_financial_data此时 PE/PB/ROE 等指标已经过清洗校验AKShare API 兜底缓存未命中或数据库缓存未启用时实时调用 AKShare 财务接口并解析_parse_akshare_financial_dataTushare API 再次兜底AKShare 不可用或未连接时降级到 Tushare_parse_financial_data。问题正出在第 2、3 条实时调用路径上用户首次查询某只股票且数据库尚无该股财务数据时系统直接消费 API 返回的单期财务数据来计算 PE/PS导致估值严重失真。问题剖析三个导致 PE/PS 高估的根因问题发现于 2025-10-26见 bugfix 文档核心症结可归纳为三类。问题 1AKShare 实时调用用单期 EPS 计算 PE原实现中PE 直接使用 AKShare基本每股收益字段计算# 获取每股收益 - 用于计算PE eps_value indicators_dict.get(基本每股收益) if eps_value is not None and str(eps_value) ! nan and eps_value ! --: try: eps_val float(eps_value) if eps_val 0: # 计算PE 股价 / 每股收益 pe_val price_value / eps_val # ❌ 使用单期EPS metrics[pe] f{pe_val:.1f}倍问题在于 AKShare 的基本每股收益是单期数据可能为 Q1/Q2/Q3 累计值或年报直接用单期 EPS 充当年度 EPS会造成系统性高估最新报告期单期累计含义PE 被高估幅度Q1一季报仅 1 个季度累计约 4 倍Q2半年报上半年累计约 2 倍Q3三季报前三季度累计约 1.33 倍年报全年无偏差问题 2AKShare 实时调用缺少 PS 计算原实现中 PS市销率完全没有参与计算仅被写为占位符# 补充其他指标的默认值 metrics.update({ ps: 待计算, # ❌ 没有实际计算 dividend_yield: 待查询, cash_ratio: 待分析 })用户在该场景下无法获得 PS 指标估值维度不完整。问题 3Tushare 实时调用用单期累计数据计算 PE/PSTushare 利润表接口返回的total_revenue营业总收入与n_income净利润是自年初至报告期的累计值原实现直接将其当作全年数据使用# PE比率使用单期净利润可能不准确 if net_income 0: pe_ratio market_cap / (net_income * 10000) # ❌ 使用单期净利润 metrics[pe] f{pe_ratio:.1f}倍 logger.warning(f⚠️ Tushare PE 使用单期净利润可能不准确) else: metrics[pe] N/A亏损 # PS比率使用单期营业收入可能不准确 if total_revenue 0: ps_ratio market_cap / (total_revenue * 10000) # ❌ 使用单期营业收入 metrics[ps] f{ps_ratio:.1f}倍 logger.warning(f⚠️ Tushare PS 使用单期营业收入可能被高估2-4倍) else: metrics[ps] N/A原代码注释中也留下了明确的整改提示# ⚠️ 警告Tushare income_statement 的 total_revenue 是单期数据可能是季报/半年报 # 理想情况下应该使用 TTM 数据但 Tushare 数据结构中没有预先计算的 TTM 字段 # TODO: 需要从多期数据中计算 TTM影响范围与严重程度触发条件三者同时满足用户首次查询某只股票的基本面数据数据库中尚未存在该股票的财务数据系统降级调用 AKShare 或 Tushare API 实时获取数据。影响程度数据失真PE/PS 被高估 1.334 倍直接进入后续的估值评分_calculate_valuation_score等与投资决策链路体验割裂首次查询得到错误数据待数据同步进数据库后再次查询又得到正确数据前后不一致易造成混淆决策风险估值指标被高估可能误导用户对股票贵贱的判断。该问题被标记为P0 紧急理由是影响基本面分析这一核心功能且数据错误幅度大、可能引发错误投资决策。修复方案对比三条可选路径方案 1实时调用时计算 TTM推荐优点数据准确用户首次查询即得正确结果与数据库侧数据保持一致。缺点需要获取最近 4 期数据API 调用次数增加实现复杂度较高。方案 2实时调用时返回 None强制同步到数据库优点实现简单避免返回不准确数据强制用户使用准确的数据库数据。缺点用户首次查询会失败需要手动触发数据同步用户体验较差。方案 3实时调用时标注数据类型临时方案优点实现简单用户能感知数据可能不准确。缺点仍然返回不准确的数据治标不治本。metrics[pe] f{pe_val:.1f}倍单期可能高估 metrics[ps] f{ps_val:.2f}倍单期可能高估最终决策采用方案 1。理由数据准确性最重要仓库中已有_calculate_ttm_metric函数可直接复用能与数据库数据保持一致用户体验最佳。修复核心_calculate_ttm_metric的 TTM 计算策略TTMTrailing Twelve Months最近 12 个月计算是本次修复的关键基础设施实现在 scripts/sync_financial_data.py。其输入为包含报告期与目标指标列的 DataFrame输出为 TTM 值万元失败返回None。完整策略分三层def _calculate_ttm_metric(df, metric_name: str) - Optional[float]: 计算 TTM最近12个月指标值营业收入、净利润等 策略 1. 如果最新期是年报12月31日直接使用年报数据 2. 如果最新期是中报/季报计算 TTM 最新年报 (本期累计 - 去年同期累计) 3. 如果数据不足返回 None不使用简单年化因为对季节性行业不准确 # 按报告期排序升序 df_sorted df.sort_values(报告期, ascendingTrue).reset_index(dropTrue) latest df_sorted.iloc[-1] latest_period str(latest[报告期]) latest_value _safe_float(latest[metric_name]) # 判断最新期是否是年报报告期以1231结尾 if latest_period.endswith(1231): # 年报直接使用 return latest_value # 非年报需要计算 TTM year int(latest_period[:4]) month_day latest_period[4:] last_year year - 1 last_annual_period f{last_year}1231 # 上一年的年报 last_same_period f{last_year}{month_day} # 去年同期 last_annual_row df_sorted[df_sorted[报告期] last_annual_period] last_same_row df_sorted[df_sorted[报告期] last_same_period] if not last_annual_row.empty and not last_same_row.empty: # TTM 最近年报 (本期累计 - 去年同期累计) ttm_value last_annual_value (latest_value - last_same_value) return ttm_value if ttm_value 0 else None # 数据不足时返回 None绝不使用简单年化对季节性行业不准确 return None三个关键设计点年报直接采用最新报告期以1231结尾时年报本身就是完整 12 个月数据无需加工累计值差分非年报期采用TTM 最近年报 (本期累计 − 去年同期累计)其中本期累计与去年同期累计均取自同一报告期口径如 0930保证差值严格对应最新一个季度的增量拒绝简单年化数据不足缺少基准年报或去年同期时返回None而不是把单期数据 ×4 粗算成年化值——因为对季节性行业而言简单年化同样会引入严重误差。函数同时保留旧接口_calculate_ttm_revenue做向后兼容sync_financial_data.py。修复落地当前仓库中的实时调用实现AKShare 实时解析PE 两级降级 TTM 化修复后的_parse_akshare_financial_dataoptimized_china_data.py将 PE 计算重构为两级降级第 1 层实时 PE/PB 优先L1393-L1449。通过get_pe_pb_with_fallback从 realtime_metrics.py 获取动态 PE实时股价 Tushare 官方 TTM 净利润反推失败时降级到 Tushare 静态pe_ttm/pb_mrqstock_basic_info集合并额外标记数据来源与(实时)标签。第 2 层TTM EPS 计算 PEL1476-L1532。当实时 PE 不可用时从main_indicatorsDataFrame 中抽取全部报告期的基本每股收益构造多期 DataFrame调用_calculate_ttm_metric得到 TTM EPSif 基本每股收益 in main_indicators[指标].values: eps_row main_indicators[main_indicators[指标] 基本每股收益] value_cols [col for col in eps_row.columns if col ! 指标] eps_data [] for col in value_cols: eps_val eps_row[col].iloc[0] if eps_val is not None and str(eps_val) ! nan and eps_val ! --: eps_data.append({报告期: col, 基本每股收益: eps_val}) if len(eps_data) 2: eps_df pd.DataFrame(eps_data) from scripts.sync_financial_data import _calculate_ttm_metric ttm_eps _calculate_ttm_metric(eps_df, 基本每股收益) # 使用 TTM EPS 或单期 EPS 计算 PE eps_for_pe ttm_eps if ttm_eps else None pe_type TTM if ttm_eps else 单期 if eps_for_pe and eps_for_pe 0: pe_val price_value / eps_for_pe metrics[pe] f{pe_val:.1f}倍即有 TTM 用 TTM无 TTM 才降级单期并且日志会明确标注本次 PE 的类型是TTM还是单期便于排查。PS 补齐同样从多期营业收入数据计算 TTM 营业收入L1625-L1676再用市值 股价 × 总股本计算if revenue_for_ps and revenue_for_ps 0: total_share stock_info.get(total_share) if stock_info else None if total_share and total_share 0: # 市值万元 股价元× 总股本万股 market_cap price_value * total_share ps_val market_cap / revenue_for_ps metrics[ps] f{ps_val:.2f}倍至此原文档中问题 2 的ps: 待计算占位符已被真实计算替代AKShare 路径的 PE/PS 均完成 TTM 化。Tushare 实时解析利润表累计值差分修复后的_parse_financial_dataoptimized_china_data.py在计算指标前先把利润表各期total_revenue与n_income分别构造成多期 DataFrame再统一走_calculate_ttm_metric# Tushare income_statement 的数据是累计值从年初到报告期 # 需要使用 TTM 公式计算 for stmt in income_statement: end_date stmt.get(end_date) revenue stmt.get(total_revenue) if end_date and revenue is not None: revenue_data.append({报告期: str(end_date), 营业收入: float(revenue)}) if len(revenue_data) 2: revenue_df pd.DataFrame(revenue_data) from scripts.sync_financial_data import _calculate_ttm_metric ttm_revenue _calculate_ttm_metric(revenue_df, 营业收入) # 净利润同理profit_data.append({报告期: ..., 净利润: float(n_income)})随后在指标计算处以 TTM 值为优先、单期累计值为兜底并显式记录数据口径total_revenue ttm_revenue if ttm_revenue else (latest_income.get(total_revenue, 0) or 0) net_income ttm_net_income if ttm_net_income else (latest_income.get(n_income, 0) or 0) revenue_type TTM if ttm_revenue else 单期 profit_type TTM if ttm_net_income else 单期 # PE比率优先使用 TTM 净利润 if net_income 0: pe_ratio market_cap / (net_income * 10000) metrics[pe] f{pe_ratio:.1f}倍 # PS比率优先使用 TTM 营业收入 if total_revenue 0: ps_ratio market_cap / (total_revenue * 10000) metrics[ps] f{ps_ratio:.1f}倍市值统一由股价 × 总股本 × 10000元推算后换算为亿元L1782-L1791当无法取得总股本时PE/PB/PS 均输出N/A无总股本数据避免使用错误市值产生误导。配套的实时 PE 校验realtime_metrics.py 中的validate_pe_pb为实时估值提供了合理性护栏PE 合理范围-100 ~ 1000允许亏损负值PB 合理范围0.1 ~ 100超出范围即判定异常并触发下一级降级进一步避免脏数据进入用户视图。测试验证TTM 计算的四种场景仓库提供了专门的验证脚本 scripts/test_akshare_ttm_calculation.py用一组含 8 期2023 年报至 2025Q3的真实风格数据覆盖四种场景TTM 营业收入计算正确性以 2025Q3 为最新期手动验证TTM 2024年报(1466.95) (2025Q3累计1006.68 − 2024Q3累计1115.82) 1357.81断言误差小于 0.01TTM 净利润计算正确性同理验证TTM 733.20 (383.39 − 557.91) 558.68并覆盖最新期净利润环比下滑的敏感场景数据不足返回 None仅含 2024Q3 与 2025Q3 两期、缺少年报时必须返回None严禁退化为简单年化对季节性行业不准确年报直接采用最新期为 20241231 时直接返回年报值1466.95 / 733.20不做差分。对应文档中的测试计划还包括端到端验证清空数据库中某只股票的财务数据 → 触发基本面分析 → 校验 PE/PS 是否使用 TTM 口径 → 与数据库侧数据对比确保一致。总结本次修复围绕实时调用链路估值失真这一 P0 问题完成了三项核心改造AKShare 路径的 PE 由单期 EPS 改为多期 TTM EPS并补齐 PS 计算、Tushare 路径的 PE/PS 由单期累计值改为 TTM 差分值、以及统一复用_calculate_ttm_metric作为 TTM 计算的事实标准。修复后用户首次查询实时链路与后续查询数据库链路的估值口径保持一致PE/PS 不再被系统性高估 1.334 倍。后续工作仍包括为两条实时解析路径补充正式单元测试、持续更新文档并在_calculate_ttm_metric数据不足时保持宁缺毋假的降级策略返回None而非简单年化以守住估值数据的准确性底线。【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考