案例基于 LangGraph + TradingAgents-CN 框架的 A 股多智能体分析系统，每日筛选 Top100 潜力股并优化输出 Top10 推荐。
基于 LangGraph + TradingAgents-CN 框架的 A 股多智能体分析系统，每日从沪深两市近 5000 只标的中筛选 Top100 潜力股，经多个分析模块交叉验证后优化输出 Top10 推荐。5 人核心团队 6 周交付首版，包含 Web 管理后台、多源行情接入和完整的用户权限体系。
这个项目的核心难点不是"调用大模型分析股票"——GPT-4o 读财报、Claude 看 K 线都不难。真正的工程挑战是多智能体协作时的意见冲突：当基本面分析看多、技术面分析看空、情绪面分析中性时，汇总器怎么决策？
LangGraph 的图编排模型让我们可以精确控制每个分析单元的输入输出和流转条件——基本面分析和情绪面分析并行执行汇聚后，与技术面结果做第二轮交叉验证，再送入汇总模块。CrewAI 的线性编排方式在这种需要条件分支 + 并行 + 汇聚的拓扑里就显得不够灵活。选择 LangGraph 不是因为它"更强"，而是因为金融推荐场景天然需要可审计的决策链路——每一只股票的推荐理由必须能追溯到是哪个分析模块、基于什么数据做出的判断。
| 维度 | LangGraph | CrewAI |
|---|---|---|
| 编排范式 | 有向图（状态图），节点 + 条件边，支持并行/分支/汇聚 | 线性链式编排，Agent 按顺序执行 |
| 多模块并行 | 原生支持 Send API 并行调度 | 需手动实现，非框架原生能力 |
| 审计链路 | 每个状态转换有明确边和条件，天然可追溯 | 链式日志，复杂分支下回溯困难 |
| 学习曲线 | 高（需理解状态图 + Python 异步） | 中（Role/Goal 声明式定义） |
| 适合场景 | 条件分支多、需并行 + 汇聚、强审计要求 | 线性任务流、快速原型、简单多角色对话 |
项目接入了三个行情数据源：Tushare Pro、AKShare 和通达信本地数据。起初以为就是调 API、落库、对齐字段——结果三个数据源的字段命名、数据粒度、更新频率完全不同：Tushare 的"市盈率"字段叫 pe_ttm，AKShare 叫 PE_TTM，通达信导出的是中文列名"市盈率（TTM）"。而且三个数据源对停牌股票的处理逻辑也不一致——一个返回 null，一个返回 0，一个返回上一交易日数据。
我们花了近两周写了一个数据标准化中间层：统一字段映射、停牌/退市标记、复权因子对齐、交易日历校准。这个模块从外部看是"隐形的"，但它是整个推荐系统数据准确性的基础——如果 ETL 层把停牌股当正常股喂给分析模块，后面所有分析都是垃圾。一个教训：金融数据类项目，ETL 的投入永远比你预估的多一倍。
早期版本的做法是三个分析单元各自打分、加权平均——结果推荐列表里经常出现"基本面极好但技术面破位"的股票。后来改成先独立分析、再交叉质询：技术面分析单元看到基本面推荐的标的后，必须针对该标的输出自己的技术面判断；汇总模块在两者分歧明显时，会触发第三轮"验证查询"——调取最近 30 个交易日的量价关系和公告事件，再让情绪面分析做最终裁定。
这个三层冲突解决机制上线后，推荐列表的一致性显著提升——冲突标的从日均约 15% 降到了 5% 以内，剩下的分歧标的会在前端标注"多空分歧"并附上双方论据，供人工判断。
初版架构中，汇总模块被允许直接输出股票代码——我们认为模型足够聪明，不会编造。第二周，运营团队发现推荐列表里出现了两只不存在的股票代码。排查后发现：当某只股票的简称和另一只已退市股票的名称相似时，模型会"融合"两者信息，生成一个既不存在于沪深两市、但在训练数据中出现过的代码。
修复方案是加了一层硬约束：汇总模块不再直接输出代码，而是输出股票简称 + 行业分类 + 推荐理由；后端在已维护的 A 股全量代码表中做精确匹配，匹配不到的标记为"无法确认"并触发人工审核。这个改动看起来是"退步"——让模型少做了一个动作——但金融场景下，宁可少推荐一只、不能推荐一只不存在。这也是金融 AI 应用和通用 chatbot 最本质的区别：容错率是零。
传统量化选股依赖因子模型和统计回测——规则是预先写死的，对市场风格切换反应滞后。多智能体方案的核心差异在于每个分析模块（基本面/技术面/情绪面）由大模型驱动推理而非固定规则：模型能理解财报附注中的非结构化风险提示、能从 K 线形态中提取"市场情绪正在转向"这类量化因子难以编码的定性信号。代价是延迟——单次推荐链路约 8–15 秒，不适合高频交易场景，但用于日频选股完全够用。
会。这正是为什么不能只用一个模型、一个分析视角的原因。本项目通过三个独立分析模块 + 交叉质询机制来对冲单一模型的偏见——基本面看多时技术面必须给独立判断，分歧明显时触发第三轮验证。根据该项目的实测数据，交叉质询可将单一模型的系统性偏见影响降低约 60%。
根据该项目的实际投入：ETL 层（多源接入+字段映射+停牌/复权/交易日历校准）占开发总工时的 40%。这不是个例——金融数据天然多源异构，且对准确性要求极高（一个停牌标记的错误会污染整个推荐管线）。建议在金融 AI 项目预算中为 ETL 预留至少 35% 的开发资源，不要按常规软件项目的 15-20% 估算。
该项目的教训是：金融场景不要让 LLM 直接输出后续系统依赖的结构化字段（股票代码、金额、日期等）。用"LLM 输出自然语言描述 + 后端精确匹配/校验"的双层架构——LLM 负责理解和推理，后端负责事实校验。这一原则同样适用于合同条款提取、合规审查、财务报表解析等场景。
前端：Next.js · Arco Design Pro · antd · Redux Toolkit · TanStack Query · axios
后端：FastAPI · SQLAlchemy · Alembic · MySQL · LangChain（OpenAI / Anthropic / Google-GenAI） · LangGraph · TradingAgents-CN · JWT
数据层：Tushare Pro · AKShare · 通达信本地数据 · Redis 缓存（行情快照）
]]>