TradingAgents-CN 批量分析并发安全修复实战从串行执行到线程安全的线程池与实例隔离改造【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN本文是 TradingAgents-CN基于多智能体 LLM 的中文金融交易框架在批量股票分析场景下的一次典型并发安全修复实战总结。文章围绕用户提交 3 只股票批量分析时任务意外串行执行、以及多任务共享实例导致数据混淆这两个核心问题完整还原了根因定位、修复方案、源码级验证与性能权衡读者将掌握 Python asyncio 线程池的正确用法、多线程共享可变状态的风险识别以及并发场景下正确性优先于性能的工程决策方法。问题回顾批量分析为何变成串行执行在 TradingAgents-CN 中用户可以通过 批量分析路由 一次性提交多只股票的深度分析任务。实际使用中当用户提交 3 只股票的批量分析如 000001、000002、000003时发现任务并没有如预期般并发执行而是顺序排队执行整体耗时被线性拉长。深入排查后发现问题的表象是串行执行但根因其实是两个相互独立的 bug叠加在一起Bug影响严重性Bug 1线程池配置问题每次调用都新建线程池实际串行执行性能问题Bug 2实例共享问题多个任务共享同一TradingAgentsGraph实例可变状态互相覆盖⚠️ 数据正确性问题其中 Bug 2 的后果远比 Bug 1 严重——它可能直接导致A 股票的分析拿到 B 股票的数据属于必须优先解决的业务安全级缺陷。Bug 1每次调用创建新线程池导致的串行执行问题代码问题定位在 simple_analysis_service.py 的_execute_analysis_sync方法中。修复前的代码如下# ❌ 每次调用都创建新的线程池 with concurrent.futures.ThreadPoolExecutor() as executor: result await loop.run_in_executor(executor, ...)问题本质每个任务进入该方法时都会新建一个独立的线程池任务执行完就销毁虽然表面上有多个线程池但线程池的创建、销毁本身存在开销且各任务之间并没有共享执行资源实际效果退化为串行执行这也是 Python 并发编程中常见的一个误用模式把ThreadPoolExecutor当作局部变量使用而非作为服务级别的共享资源。修复方案修复的核心思路是将线程池提升为服务实例的共享资源在__init__中创建一次、全局复用# ✅ 在 __init__ 中创建共享线程池 import concurrent.futures self._thread_pool concurrent.futures.ThreadPoolExecutor(max_workers3) # ✅ 在方法中使用共享线程池 result await loop.run_in_executor(self._thread_pool, ...)在 simple_analysis_service.py 源码 中可以确认SimpleAnalysisService.__init__现在持有self._thread_poolThreadPoolExecutor(max_workers3)默认最多同时执行 3 个分析任务日志中明确记录了线程池最大并发数: 3日志输出 [服务初始化] SimpleAnalysisService 实例ID: {id(self)}为后续排查多实例问题留下了关键线索。而_execute_analysis_sync方法源码位置则统一通过loop.run_in_executor(self._thread_pool, self._run_analysis_sync, ...)将同步的分析逻辑提交到共享线程池执行并输出 [线程池] 提交分析任务到共享线程池: {task_id} - {stock_code}日志。补充说明max_workers3与批量分析路由中限制的单批次最多 10 只股票见 analysis.py 源码 的MAX_BATCH_SIZE 10相配合超出并发上限的任务会在线程池中排队但不会退回串行。Bug 2实例共享导致的数据混淆严重缺陷问题代码问题定位在 simple_analysis_service.py 的_get_trading_graph方法中。修复前的代码如下# ❌ 使用缓存多个任务共享同一个实例 def _get_trading_graph(self, config: Dict[str, Any]) - TradingAgentsGraph: config_key str(sorted(config.items())) if config_key not in self._trading_graph_cache: self._trading_graph_cache[config_key] TradingAgentsGraph(...) return self._trading_graph_cache[config_key] # ❌ 共享实例问题本质TradingAgentsGraph多智能体交易图谱负责编排市场分析师、基本面分析师等角色的多轮协作与状态推进包含可变的实例变量。从 trading_graph.py 源码 可以看到其状态跟踪部分# State tracking self.curr_state None self.ticker None self.log_states_dict {} # date to full state dict同时在分析流程推进过程中会持续写入这些可变状态如设置self.ticker company_name、更新self._current_task_id、把最终结果写入self.curr_state参见 trading_graph.py 与 trading_graph.py 附近的状态更新逻辑。当多个线程共享同一个TradingAgentsGraph实例时这些可变变量会被并发覆盖线程 A 刚写入self.ticker 000001线程 B 随即把它改成000002线程 A 后续读取时拿到的可能是 B 的数据严重后果A 股票的分析结果中混入 B 股票的数据且这种错误是随机出现的取决于线程调度极难复现与定位。修复方案修复思路是彻底放弃缓存每次调用都创建全新的实例# ✅ 每次都创建新实例避免共享状态 def _get_trading_graph(self, config: Dict[str, Any]) - TradingAgentsGraph: trading_graph TradingAgentsGraph( selected_analystsconfig.get(selected_analysts, [market, fundamentals]), debugconfig.get(debug, False), configconfig ) return trading_graph # ✅ 每次返回新实例在 simple_analysis_service.py 当前源码 中_get_trading_graph的文档字符串明确记录了这次设计决策⚠️ 注意为了避免并发执行时的数据混淆每次都创建新实例。虽然这会增加一些初始化开销但可以确保线程安全。TradingAgentsGraph实例包含可变状态self.ticker、self.curr_state等如果多个线程共享同一个实例会导致数据混淆。每个新实例都会输出✅ TradingAgents实例创建成功实例ID: {id(trading_graph)}日志实例 ID 各不相同为验证实例隔离提供了直接证据。修复效果性能约 2 倍提升 数据完全隔离性能提升根据修复记录对比数据如下该数据来自本次修复的实测记录具体耗时受服务器资源与模型调用速度影响修复前12-15 分钟串行执行修复后6-8 分钟并发执行已考虑每次创建实例的初始化开销整体提升约 2 倍安全性提升✅ 完全避免数据混淆每个任务持有独立的TradingAgentsGraph实例✅ 每个任务有独立的实例和状态ticker、curr_state、_current_task_id等变量互不干扰✅ 线程安全共享线程池 独立实例的组合不再产生共享可变状态竞争。修改的文件清单本次修复集中在 app/services/simple_analysis_service.py 一个文件内涉及三个关键位置__init__约 568-582 行创建共享线程池ThreadPoolExecutor(max_workers3)_get_trading_graph约 681-702 行每次调用创建新TradingAgentsGraph实例不再使用缓存_execute_analysis_sync约 1037-1058 行通过loop.run_in_executor(self._thread_pool, ...)使用共享线程池执行分析。需要说明的是同一仓库中的 analysis_service.py 仍保留了基于config_key的实例缓存实现其文档字符串注明带缓存 - 与单股分析保持一致这提示读者并发安全改造需要结合具体服务的并发特征逐一评估并非所有服务都已统一到每次新建实例的策略引入新并发场景时需重点核查这类仍在使用缓存的路径。验证方法三层检查确保修复有效修复完成后通过以下三步在真实运行环境中验证。1. 检查并发执行提交批量分析后观察服务日志。修复后应看到所有任务同时开始执行而不是等上一个完成再开始下一个 [线程池] 提交分析任务到共享线程池: task-1 - 000001 [线程池] 提交分析任务到共享线程池: task-2 - 000002 [线程池] 提交分析任务到共享线程池: task-3 - 000003 [线程池] 开始执行分析: task-1 - 000001 ← 3个任务同时开始 [线程池] 开始执行分析: task-2 - 000002 [线程池] 开始执行分析: task-3 - 000003其中 [线程池] 提交分析任务...与 [线程池] 开始执行分析...两条日志分别来自_execute_analysis_sync与_run_analysis_sync源码 与 源码。2. 检查实例隔离查看日志中的实例 ID3 个任务的实例 ID 必须互不相同✅ TradingAgents实例创建成功实例ID: 140234567890123 ← 任务1 ✅ TradingAgents实例创建成功实例ID: 140234567890456 ← 任务2 ✅ TradingAgents实例创建成功实例ID: 140234567890789 ← 任务33. 检查数据正确性确认每个任务的分析结果对应正确的股票代码可编写如下断言脚本连接 MongoDB 的analysis_reports集合# 检查任务1的结果 task1_result db.analysis_reports.find_one({task_id: task-1}) assert task1_result[stock_code] 000001 assert 000002 not in str(task1_result) # 不应该包含其他股票的数据此外批量分析路由在 analysis.py 中使用asyncio.create_taskasyncio.gather调度并发任务而非BackgroundTasks其文档字符串明确注明它是串行执行的配合共享线程池构成异步协程调度 同步任务线程池执行的完整并发链路。性能权衡为什么放弃缓存修复中一个关键决策是用每次都新建实例替换掉实例缓存这并非性能最优解而是一次有意识的安全取舍。缓存的优点避免重复创建实例可节省 1-2 秒初始化时间减少内存占用尤其是多智能体框架中每个TradingAgentsGraph都会加载多个 Agent 与 LLM 配置。缓存的缺点数据混淆风险多线程共享可变状态是并发安全的大忌难以调试数据混淆随机出现依赖线程调度时序极难复现和定位安全隐患可能把股票 A 的数据写入股票 B 的报告直接导致业务错误。结论安全性 性能1-2 秒的初始化开销相对于一次完整分析分钟级可以接受数据正确性是第一优先级。如果未来需要优化性能修复记录同时给出了三个面向未来的优化方向均可作为后续演进方案使用对象池预创建一组独立实例每次从池中取出一个未占用的实例使用兼顾复用与隔离# 创建一个对象池每个线程从池中获取独立的实例 self._graph_pool [TradingAgentsGraph(...) for _ in range(3)]重构TradingAgentsGraph将可变状态从实例变量改为方法参数使propagate等方法完全无状态从而可以安全地共享实例——这是治本之策但改造面较大需要同步调整图中各 Agent 节点的调用方式使用进程池代替线程池进程间内存天然隔离从根上消除共享状态竞争但代价是更高的内存开销与跨进程序列化成本# 使用进程池每个进程有独立的内存空间 self._process_pool concurrent.futures.ProcessPoolExecutor(max_workers3)相关问题 FAQ单股分析是否也有这个问题不会。单股分析每次只执行一个任务不涉及并发因此不会遇到实例共享问题。但需要注意一个边界场景如果用户快速连续提交多个单股分析请求这些请求也可能同时进入共享线程池执行从而遇到与批量分析相同的实例共享风险。本次修复后多个单股分析请求同样可以安全地并发执行——这正是共享线程池 独立实例方案对两种场景同时生效的体现。为什么之前没有发现这个问题批量分析功能较新此前主路径是单股分析批量分析上线时间短、使用频率低问题难以复现数据混淆是随机行为取决于线程调度时序常规功能测试很难稳定触发测试覆盖不足缺少针对并发场景多任务同时执行的测试用例这也是本次修复记录中明确承认的测试缺口。如何避免类似问题修复记录给出了四条可落地的预防措施代码审查重点关注共享状态缓存、类级变量、全局单例与并发安全的组合单元测试补充并发场景的测试用例模拟多任务同时提交、同时执行压力测试模拟高并发批量提交观察是否存在数据串扰与状态竞争日志监控在关键对象创建时记录实例 ID如✅ TradingAgents实例创建成功实例ID: xxx便于事后排查数据归属。总结与关键教训本次修复一次性解决了批量分析场景的两个关键问题性能问题通过将线程池从每次调用新建改为服务级共享实现了真正的并发执行实测耗时缩短约 2 倍安全问题通过每次新建TradingAgentsGraph实例彻底消除了多线程共享可变状态导致的数据混淆杜绝了跨股票数据串扰。修复后的系统具备以下特征✅ 性能提升约 2 倍✅ 数据完全隔离✅ 线程安全✅ 可靠性大幅提升。关键教训在设计并发系统时必须仔细考虑共享状态和线程安全问题。性能优化不能以牺牲数据正确性为代价——尤其在金融交易分析这类数据准确性直接决定业务决策的场景中宁可慢 1-2 秒不可错一个数据点应当成为并发改造的基本原则。【免费下载链接】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基于多智能体 LLM 的中文金融交易框架在批量股票分析场景下的一次典型并发安全修复实战总结。文章围绕用户提交 3 只股票批量分析时任务意外串行执行、以及多任务共享实例导致数据混淆这两个核心问题完整还原了根因定位、修复方案、源码级验证与性能权衡读者将掌握 Python asyncio 线程池的正确用法、多线程共享可变状态的风险识别以及并发场景下正确性优先于性能的工程决策方法。问题回顾批量分析为何变成串行执行在 TradingAgents-CN 中用户可以通过 批量分析路由 一次性提交多只股票的深度分析任务。实际使用中当用户提交 3 只股票的批量分析如 000001、000002、000003时发现任务并没有如预期般并发执行而是顺序排队执行整体耗时被线性拉长。深入排查后发现问题的表象是串行执行但根因其实是两个相互独立的 bug叠加在一起Bug影响严重性Bug 1线程池配置问题每次调用都新建线程池实际串行执行性能问题Bug 2实例共享问题多个任务共享同一TradingAgentsGraph实例可变状态互相覆盖⚠️ 数据正确性问题其中 Bug 2 的后果远比 Bug 1 严重——它可能直接导致A 股票的分析拿到 B 股票的数据属于必须优先解决的业务安全级缺陷。Bug 1每次调用创建新线程池导致的串行执行问题代码问题定位在 simple_analysis_service.py 的_execute_analysis_sync方法中。修复前的代码如下# ❌ 每次调用都创建新的线程池 with concurrent.futures.ThreadPoolExecutor() as executor: result await loop.run_in_executor(executor, ...)问题本质每个任务进入该方法时都会新建一个独立的线程池任务执行完就销毁虽然表面上有多个线程池但线程池的创建、销毁本身存在开销且各任务之间并没有共享执行资源实际效果退化为串行执行这也是 Python 并发编程中常见的一个误用模式把ThreadPoolExecutor当作局部变量使用而非作为服务级别的共享资源。修复方案修复的核心思路是将线程池提升为服务实例的共享资源在__init__中创建一次、全局复用# ✅ 在 __init__ 中创建共享线程池 import concurrent.futures self._thread_pool concurrent.futures.ThreadPoolExecutor(max_workers3) # ✅ 在方法中使用共享线程池 result await loop.run_in_executor(self._thread_pool, ...)在 simple_analysis_service.py 源码 中可以确认SimpleAnalysisService.__init__现在持有self._thread_poolThreadPoolExecutor(max_workers3)默认最多同时执行 3 个分析任务日志中明确记录了线程池最大并发数: 3日志输出 [服务初始化] SimpleAnalysisService 实例ID: {id(self)}为后续排查多实例问题留下了关键线索。而_execute_analysis_sync方法源码位置则统一通过loop.run_in_executor(self._thread_pool, self._run_analysis_sync, ...)将同步的分析逻辑提交到共享线程池执行并输出 [线程池] 提交分析任务到共享线程池: {task_id} - {stock_code}日志。补充说明max_workers3与批量分析路由中限制的单批次最多 10 只股票见 analysis.py 源码 的MAX_BATCH_SIZE 10相配合超出并发上限的任务会在线程池中排队但不会退回串行。Bug 2实例共享导致的数据混淆严重缺陷问题代码问题定位在 simple_analysis_service.py 的_get_trading_graph方法中。修复前的代码如下# ❌ 使用缓存多个任务共享同一个实例 def _get_trading_graph(self, config: Dict[str, Any]) - TradingAgentsGraph: config_key str(sorted(config.items())) if config_key not in self._trading_graph_cache: self._trading_graph_cache[config_key] TradingAgentsGraph(...) return self._trading_graph_cache[config_key] # ❌ 共享实例问题本质TradingAgentsGraph多智能体交易图谱负责编排市场分析师、基本面分析师等角色的多轮协作与状态推进包含可变的实例变量。从 trading_graph.py 源码 可以看到其状态跟踪部分# State tracking self.curr_state None self.ticker None self.log_states_dict {} # date to full state dict同时在分析流程推进过程中会持续写入这些可变状态如设置self.ticker company_name、更新self._current_task_id、把最终结果写入self.curr_state参见 trading_graph.py 与 trading_graph.py 附近的状态更新逻辑。当多个线程共享同一个TradingAgentsGraph实例时这些可变变量会被并发覆盖线程 A 刚写入self.ticker 000001线程 B 随即把它改成000002线程 A 后续读取时拿到的可能是 B 的数据严重后果A 股票的分析结果中混入 B 股票的数据且这种错误是随机出现的取决于线程调度极难复现与定位。修复方案修复思路是彻底放弃缓存每次调用都创建全新的实例# ✅ 每次都创建新实例避免共享状态 def _get_trading_graph(self, config: Dict[str, Any]) - TradingAgentsGraph: trading_graph TradingAgentsGraph( selected_analystsconfig.get(selected_analysts, [market, fundamentals]), debugconfig.get(debug, False), configconfig ) return trading_graph # ✅ 每次返回新实例在 simple_analysis_service.py 当前源码 中_get_trading_graph的文档字符串明确记录了这次设计决策⚠️ 注意为了避免并发执行时的数据混淆每次都创建新实例。虽然这会增加一些初始化开销但可以确保线程安全。TradingAgentsGraph实例包含可变状态self.ticker、self.curr_state等如果多个线程共享同一个实例会导致数据混淆。每个新实例都会输出✅ TradingAgents实例创建成功实例ID: {id(trading_graph)}日志实例 ID 各不相同为验证实例隔离提供了直接证据。修复效果性能约 2 倍提升 数据完全隔离性能提升根据修复记录对比数据如下该数据来自本次修复的实测记录具体耗时受服务器资源与模型调用速度影响修复前12-15 分钟串行执行修复后6-8 分钟并发执行已考虑每次创建实例的初始化开销整体提升约 2 倍安全性提升✅ 完全避免数据混淆每个任务持有独立的TradingAgentsGraph实例✅ 每个任务有独立的实例和状态ticker、curr_state、_current_task_id等变量互不干扰✅ 线程安全共享线程池 独立实例的组合不再产生共享可变状态竞争。修改的文件清单本次修复集中在 app/services/simple_analysis_service.py 一个文件内涉及三个关键位置__init__约 568-582 行创建共享线程池ThreadPoolExecutor(max_workers3)_get_trading_graph约 681-702 行每次调用创建新TradingAgentsGraph实例不再使用缓存_execute_analysis_sync约 1037-1058 行通过loop.run_in_executor(self._thread_pool, ...)使用共享线程池执行分析。需要说明的是同一仓库中的 analysis_service.py 仍保留了基于config_key的实例缓存实现其文档字符串注明带缓存 - 与单股分析保持一致这提示读者并发安全改造需要结合具体服务的并发特征逐一评估并非所有服务都已统一到每次新建实例的策略引入新并发场景时需重点核查这类仍在使用缓存的路径。验证方法三层检查确保修复有效修复完成后通过以下三步在真实运行环境中验证。1. 检查并发执行提交批量分析后观察服务日志。修复后应看到所有任务同时开始执行而不是等上一个完成再开始下一个 [线程池] 提交分析任务到共享线程池: task-1 - 000001 [线程池] 提交分析任务到共享线程池: task-2 - 000002 [线程池] 提交分析任务到共享线程池: task-3 - 000003 [线程池] 开始执行分析: task-1 - 000001 ← 3个任务同时开始 [线程池] 开始执行分析: task-2 - 000002 [线程池] 开始执行分析: task-3 - 000003其中 [线程池] 提交分析任务...与 [线程池] 开始执行分析...两条日志分别来自_execute_analysis_sync与_run_analysis_sync源码 与 源码。2. 检查实例隔离查看日志中的实例 ID3 个任务的实例 ID 必须互不相同✅ TradingAgents实例创建成功实例ID: 140234567890123 ← 任务1 ✅ TradingAgents实例创建成功实例ID: 140234567890456 ← 任务2 ✅ TradingAgents实例创建成功实例ID: 140234567890789 ← 任务33. 检查数据正确性确认每个任务的分析结果对应正确的股票代码可编写如下断言脚本连接 MongoDB 的analysis_reports集合# 检查任务1的结果 task1_result db.analysis_reports.find_one({task_id: task-1}) assert task1_result[stock_code] 000001 assert 000002 not in str(task1_result) # 不应该包含其他股票的数据此外批量分析路由在 analysis.py 中使用asyncio.create_taskasyncio.gather调度并发任务而非BackgroundTasks其文档字符串明确注明它是串行执行的配合共享线程池构成异步协程调度 同步任务线程池执行的完整并发链路。性能权衡为什么放弃缓存修复中一个关键决策是用每次都新建实例替换掉实例缓存这并非性能最优解而是一次有意识的安全取舍。缓存的优点避免重复创建实例可节省 1-2 秒初始化时间减少内存占用尤其是多智能体框架中每个TradingAgentsGraph都会加载多个 Agent 与 LLM 配置。缓存的缺点数据混淆风险多线程共享可变状态是并发安全的大忌难以调试数据混淆随机出现依赖线程调度时序极难复现和定位安全隐患可能把股票 A 的数据写入股票 B 的报告直接导致业务错误。结论安全性 性能1-2 秒的初始化开销相对于一次完整分析分钟级可以接受数据正确性是第一优先级。如果未来需要优化性能修复记录同时给出了三个面向未来的优化方向均可作为后续演进方案使用对象池预创建一组独立实例每次从池中取出一个未占用的实例使用兼顾复用与隔离# 创建一个对象池每个线程从池中获取独立的实例 self._graph_pool [TradingAgentsGraph(...) for _ in range(3)]重构TradingAgentsGraph将可变状态从实例变量改为方法参数使propagate等方法完全无状态从而可以安全地共享实例——这是治本之策但改造面较大需要同步调整图中各 Agent 节点的调用方式使用进程池代替线程池进程间内存天然隔离从根上消除共享状态竞争但代价是更高的内存开销与跨进程序列化成本# 使用进程池每个进程有独立的内存空间 self._process_pool concurrent.futures.ProcessPoolExecutor(max_workers3)相关问题 FAQ单股分析是否也有这个问题不会。单股分析每次只执行一个任务不涉及并发因此不会遇到实例共享问题。但需要注意一个边界场景如果用户快速连续提交多个单股分析请求这些请求也可能同时进入共享线程池执行从而遇到与批量分析相同的实例共享风险。本次修复后多个单股分析请求同样可以安全地并发执行——这正是共享线程池 独立实例方案对两种场景同时生效的体现。为什么之前没有发现这个问题批量分析功能较新此前主路径是单股分析批量分析上线时间短、使用频率低问题难以复现数据混淆是随机行为取决于线程调度时序常规功能测试很难稳定触发测试覆盖不足缺少针对并发场景多任务同时执行的测试用例这也是本次修复记录中明确承认的测试缺口。如何避免类似问题修复记录给出了四条可落地的预防措施代码审查重点关注共享状态缓存、类级变量、全局单例与并发安全的组合单元测试补充并发场景的测试用例模拟多任务同时提交、同时执行压力测试模拟高并发批量提交观察是否存在数据串扰与状态竞争日志监控在关键对象创建时记录实例 ID如✅ TradingAgents实例创建成功实例ID: xxx便于事后排查数据归属。总结与关键教训本次修复一次性解决了批量分析场景的两个关键问题性能问题通过将线程池从每次调用新建改为服务级共享实现了真正的并发执行实测耗时缩短约 2 倍安全问题通过每次新建TradingAgentsGraph实例彻底消除了多线程共享可变状态导致的数据混淆杜绝了跨股票数据串扰。修复后的系统具备以下特征✅ 性能提升约 2 倍✅ 数据完全隔离✅ 线程安全✅ 可靠性大幅提升。关键教训在设计并发系统时必须仔细考虑共享状态和线程安全问题。性能优化不能以牺牲数据正确性为代价——尤其在金融交易分析这类数据准确性直接决定业务决策的场景中宁可慢 1-2 秒不可错一个数据点应当成为并发改造的基本原则。【免费下载链接】TradingAgents-CN基于多智能体LLM的中文金融交易框架 - TradingAgents中文增强版项目地址: https://gitcode.com/GitHub_Trending/tr/TradingAgents-CN创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
