简介这份资源是 tradingagents-cn 中文增强版的二次开发成果面向关注 A 股量化交易与 AI 多智能体分析的开发者、量化爱好者及个人投资者。它在原版基础上新增多股批量分析能力可对多只 A 股标的进行多维度智能体协同研判适合希望搭建本地化选股与行情分析流程的中高级用户。压缩包共 744 个文件约 47.16MB以 457 个 py 脚本为核心实现分析逻辑与数据接口辅以 173 个 md 说明文档、19 个 txt 配置、18 个 ps1 与 14 个 bat 启动脚本以及少量 png、toml、yml、sh 等资源覆盖环境安装、服务启动与调试运行等环节。目前已有 160 人学习下载。借助该包读者可获得一套可二次开发的 A 股量化分析框架理解多智能体协作的批量分析思路并参考脚本与文档快速完成本地部署与功能扩展。1. 从单股到多股批量tradingagents-cn 中文增强版到底解决了什么如果你跑过 tradingagents-cn 原版大概率经历过这种场景晚上想复盘三只自选股结果得一只一只手动改配置、一只一只等结果跑完一轮半小时过去了天都亮了。原版的多智能体框架本身没问题——分析师、研究员、交易员、风控各司其职辩论式推理出来的结论比单模型拍脑袋靠谱得多。但它的交互设计是「一次一只票」对 A 股这种动辄几十只自选股的场景来说效率就是硬伤。这份二次开发版的核心改动就一个方向把单股分析流程改造成可批量调度的多股流水线同时针对 A 股做了中文语料和交易规则层面的增强。它适合两类人一是手里有自选股池、需要定期批量出分析报告的散户或小团队二是想拿它当多智能体编排的学习样本、研究怎么把 LLM 工作流工程化的开发者。不适合指望它直接给买卖信号的人——它输出的是多维度分析结论不是荐股。2. 多智能体批量分析的架构拆解从单股串行到多股并发2.1 原版单股流程的瓶颈在哪tradingagents-cn 原版的执行链路大致是数据采集 → 技术面/基本面/情绪面分析师并行 → 研究员多空辩论 → 交易员出方案 → 风控审核。这条链路本身设计得不错问题出在调度层——它把「股票代码」当成一次运行的全局参数整个流程跑完才释放。你想分析第二只票要么重启进程要么手动改配置再跑一遍。更麻烦的是中间状态的隔离。原版把辩论记录、分析结论存在共享的 state 字典里单股跑没问题一旦你想并发多股state 就会互相污染。常见做法是给每只股票分配独立的 state 副本用股票代码做 key 做命名空间隔离。这份二次开发版在调度层加了一个批量入口内部对每只票创建独立的 agent 实例和 state 容器跑完再汇总。2.2 批量调度的实现思路与关键参数批量分析的核心不是「循环调用」而是「受控并发」。A 股数据源尤其是行情和公告接口对请求频率敏感无脑并发会触发限流甚至封 IP。我一般会把并发度控制在 35 之间配合每只票之间的随机延迟。下面是一个批量调度的骨架代码展示怎么把单股流程包装成可并发、可限流的任务import asyncio import random from tradingagents.graph import TradingAgentsGraph async def analyze_single(ticker: str, sem: asyncio.Semaphore, config: dict): 单只股票的分析任务用信号量控制并发 async with sem: # 并发闸门超过上限就排队 graph TradingAgentsGraph(configconfig) # 每只票独立 state避免多股之间数据串台 result await graph.arun( tickerticker, trade_dateconfig[trade_date], asset_typestock ) # 随机延迟降低被数据源限流的概率 await asyncio.sleep(random.uniform(1.5, 4.0)) return ticker, result async def batch_analyze(tickers: list, config: dict, max_concurrent: int 3): 批量入口tickers 是股票代码列表 sem asyncio.Semaphore(max_concurrent) tasks [analyze_single(t, sem, config) for t in tickers] # gather 保持返回顺序与输入一致方便对号入座 results await asyncio.gather(*tasks, return_exceptionsTrue) summary {} for item in results: if isinstance(item, Exception): print(f[失败] {item}) continue ticker, res item summary[ticker] res return summary这段代码有三个关键点。第一asyncio.Semaphore(max_concurrent)是并发闸门max_concurrent建议设 3数据源稳定的话可以试 5超过 5 基本会触发限流。第二每只票在analyze_single内部重新实例化TradingAgentsGraph保证 state 隔离——如果你图省事复用同一个 graph 实例多股结果会互相覆盖这是血泪经验。第三asyncio.sleep的随机延迟不是可有可无的装饰A 股行情接口对固定间隔的请求很敏感加随机抖动能显著降低被限流的概率。2.3 A 股中文增强体现在哪些地方原版 tradingagents-cn 虽然叫「中文版」但对 A 股特有的东西覆盖不全。这份二次开发版在几个地方做了补强增强点原版表现增强版处理涨跌停规则按通用逻辑处理识别 10%/20% 涨跌停分析时排除无效信号财报字段英文财报字段映射适配 A 股财报中文科目名情绪面数据通用新闻源增加股吧、互动易等中文语料权重交易日历通用日历内置 A 股交易日历跳过非交易日这些增强不是锦上添花是能不能用的分界线。比如涨跌停识别如果不做技术面分析师会把一字板当成正常放量信号结论直接跑偏。3. 跑通批量分析的完整步骤配置、执行、看结果3.1 环境准备与依赖确认先把运行环境理清楚。这份二次开发版基于 Python核心依赖包括 langchain、langgraph 以及若干数据源 SDK。建议用独立虚拟环境避免和系统里的其他包打架。# 创建独立环境Python 版本建议 3.10 以上 python -m venv venv_trading source venv_trading/bin/activate # Windows 用 venv_trading\Scripts\activate # 安装核心依赖以项目实际 requirements 为准 pip install -r requirements.txt # 确认关键包版本langgraph 版本不匹配会导致图编排报错 pip show langgraph langchainlanggraph的版本要特别注意0.1.x 和 0.2.x 的 API 有 breaking change图节点的注册方式不一样。如果你装完跑起来报AttributeError之类的错先查版本。常见做法是锁定项目 requirements 里写的版本不要盲目升级。3.2 配置文件怎么写批量模式的关键字段批量模式的配置和单股模式差别不大核心是加一个股票列表字段和并发控制字段。下面是一份配置示例# config_batch.py BATCH_CONFIG { tickers: [600519, 000858, 300750, 601318], # 股票代码列表 trade_date: 2026-01-15, # 分析基准日 max_concurrent: 3, # 并发上限建议 3 request_delay: (1.5, 4.0), # 请求间隔随机范围秒 llm_config: { model: gpt-4o, # 或项目支持的国产模型 temperature: 0.3, # 分析类任务温度调低减少发散 max_tokens: 4096 }, analysts: [technical, fundamental, sentiment], # 启用的分析师 debate_rounds: 2, # 多空辩论轮数 output_dir: ./reports/batch # 批量报告输出目录 }几个参数值得展开说。temperature设 0.3 而不是默认的 0.7是因为分析任务要的是稳定复现不是创意发散温度高了同一只票跑两次结论可能差很多。debate_rounds设 2 是性价比平衡点设 1 辩论不充分设 3 以上 token 消耗陡增但结论提升有限。max_concurrent和request_delay要配合调并发高就把延迟拉长总吞吐差不多但更安全。3.3 执行批量分析并解读输出配置就绪后用批量入口跑起来import asyncio from config_batch import BATCH_CONFIG from batch_runner import batch_analyze async def main(): results await batch_analyze( tickersBATCH_CONFIG[tickers], configBATCH_CONFIG, max_concurrentBATCH_CONFIG[max_concurrent] ) # 按股票代码逐只打印结论摘要 for ticker, res in results.items(): print(f {ticker} ) print(f技术面: {res.get(technical_summary, N/A)}) print(f基本面: {res.get(fundamental_summary, N/A)}) print(f情绪面: {res.get(sentiment_summary, N/A)}) print(f最终建议: {res.get(final_decision, N/A)}) if __name__ __main__: asyncio.run(main())输出结构里每只票会带技术面、基本面、情绪面三段摘要以及多空辩论后的最终结论。看结果时重点看辩论环节的推理链而不是只看最终那句结论——多智能体的价值在推理过程结论只是副产品。如果某只票的辩论记录里多空双方论据高度雷同说明数据源可能没取到有效信息这只票的结论要打问号。4. 避坑与排查批量分析最容易翻车的五个地方4.1 多股结果串台A 的结论跑到 B 头上现象批量跑完发现两只票的分析结论一模一样或者某只票的辩论记录里出现了另一只票的代码。原因复用了同一个 graph 实例或共享 state 字典多股并发时 state 被覆盖。原版单股流程没有做 state 隔离直接循环调用必然出这个问题。解决每只票在任务内部独立实例化 graphstate 用股票代码做命名空间。参考 2.2 节的analyze_single写法确保TradingAgentsGraph在async with sem内部创建。4.2 数据源限流跑到一半集体报错现象前两只票正常第三只开始报连接超时或 403后面全挂。原因并发度设太高或者请求间隔太短触发了数据源的频率限制。A 股行情接口对短时间内的高频请求很敏感。解决把max_concurrent降到 23request_delay下限拉到 2 秒以上。如果还是被限在数据采集层加一层本地缓存同一交易日的数据只取一次。4.3 LLM 调用超时导致整批中断现象某只票的分析卡在研究员辩论环节长时间无响应最终整批任务超时退出。原因单次 LLM 请求的 token 量太大尤其是辩论轮数多、上下文长的时候或者网络抖动。批量模式下一只票卡住会拖垮整批。解决给每个单股任务加独立的超时控制用asyncio.wait_for包一层超时就跳过该票并记录不要让异常向上传播。同时把debate_rounds控制在 2 轮以内减少单次上下文长度。4.4 交易日历没对齐非交易日跑出空结果现象周末或节假日跑批量所有票的分析结论都是「数据不足」或直接报错。原因数据源在非交易日返回空数据但流程没有做交易日判断硬跑下去就是一堆空结果。解决在批量入口加一层交易日校验非交易日直接跳过并提示。增强版内置了 A 股交易日历调用前先查一下is_trading_day(trade_date)。4.5 报告输出覆盖前一只票的结果被后一只冲掉现象批量跑完去看报告目录只有最后一只票的文件前面的都不见了。原因输出文件名没带股票代码所有票写同一个文件后写的覆盖先写的。解决输出路径按output_dir/{ticker}_{trade_date}.json命名每只票独立文件。如果要多股汇总单独生成一个summary_{trade_date}.json不要和单股报告混在一起。5. 进阶技巧把批量分析接进定时任务与结果校验跑通单次批量只是起点真正省事的是把它变成定时任务。我一般用schedule或系统 cron 在收盘后自动触发跑完把报告推到本地目录或邮件。但定时任务有个前提结果必须可校验否则跑了一堆垃圾报告你也不知道。校验分两层。第一层是结构校验检查每只票的输出是否包含技术面、基本面、情绪面、最终结论四个字段缺字段的直接标记为异常。第二层是内容校验看辩论记录里多空双方的论据是否有实质差异——如果两边说的是一回事说明数据源没喂进有效信息这份报告不可信。def validate_report(report: dict) - tuple: 校验单份报告是否完整可信 required [technical_summary, fundamental_summary, sentiment_summary, final_decision] missing [f for f in required if not report.get(f)] if missing: return False, f缺失字段: {missing} # 检查辩论记录是否有实质分歧 debate report.get(debate_log, ) if len(debate) 200: # 辩论记录过短大概率没跑起来 return False, 辩论记录过短可能数据源异常 return True, ok这个校验函数不复杂但能挡住大部分「跑完了但结果是废的」情况。定时任务里对每只票跑一遍校验失败的单独记日志第二天手动补跑。还有一个习惯每次改完配置或升级依赖后先拿两只票做小批量验证确认输出正常再放开全量。批量分析最怕的就是配置改错一个字段几十只票跑完才发现全废了token 和时间都打水漂。从那以后我每次动配置都强制先跑两只票的冒烟测试确认无误再上全量。希望帮到你。本文还有配套的精品资源点击获取