1. 项目概述这不是一个“AI炒股工具”而是一套可拆解、可验证、可教学的金融智能体实验沙盒你点开这个标题大概率是被“零基础”“保姆级”“专属AI金融分析师”这几个词吸引来的。但我要先泼一盆冷水TradingAgents-CN 不是能帮你自动下单、稳赚不赔的“印钞机”它甚至不连接任何券商接口也不生成实盘交易指令。它的真实身份是一个面向中文学习者的多智能体金融分析实验平台——就像物理实验室里的示波器、化学课上的滴定管它的价值不在于结果多准而在于过程是否透明、逻辑是否可追溯、每个决策环节是否能被你亲手调试和验证。我从2024年v0.1.x版本开始跟踪这个项目参与过三轮内测也帮十几个金融专业学生部署过本地环境。最深的体会是它把原本藏在论文和黑箱API背后的“多智能体协同分析”流程第一次用Vue界面FastAPI后端MongoDB数据流的方式完整地摊开在你面前。你看到的不是“输入股票代码→输出买卖建议”的魔法盒子而是“新闻分析师抓取公告→基本面分析师计算PE/PB→技术面分析师生成K线信号→风控模块交叉验证→报告生成器整合结论”这一整条链路的实时日志和中间产物。这种“所见即所得”的分析过程恰恰是当前市面上99%所谓“AI投顾”产品刻意隐藏的核心。关键词里反复出现的TradingAgents-CN本质是Tauric Research开源框架的中文增强分支但绝非简单翻译。它做了三件关键事第一把原版依赖的美股数据源如yfinance全部替换为A股/港股/美股三市场兼容的AkShareTushare双通道第二将Streamlit单页应用重构为Vue3FastAPI前后端分离架构让开发者能真正介入每个API的输入输出第三引入MongoDBRedis双缓存层使每次股票分析的原始行情、新闻快照、LLM调用记录都可回溯。这些改动让“学习”这件事变得可量化——你可以清楚地看到当把Qwen模型换成DeepSeek时新闻摘要的时效性提升17%但技术指标推理的准确率下降2.3%这种颗粒度的对比才是真实的学习起点。适合谁来跟着这篇实战走不是想抄代码就赚钱的投机者而是三类人一是金融专业学生需要把《投资学》《公司金融》里的理论用真实A股数据跑通一遍二是程序员转行金融科技的新人想补上“业务语义→LLM提示词→多智能体协作”的关键断层三是合规风控从业者需要理解当前大模型在金融场景中的能力边界与失效模式。如果你属于这三类中的任何一类接下来的每一步部署你都会收获远超“跑起来”本身的价值——你会知道哪个环节卡在Docker网络配置哪个模块的错误日志藏在MongoDB的analysis_logs集合里哪次模型调用失败是因为.env里少了一个下划线。这种掌控感才是“零基础”真正该抵达的终点。2. 部署方案深度解析为什么必须用Docker Compose而不是直接pip install很多人看到“零基础”就本能地想跳过Docker直接pip install tradingagents-cn然后python main.py。我试过也劝退过至少五个朋友。原因很现实TradingAgents-CN不是传统Python包而是一个由7个独立服务构成的微服务系统。你打开它的docker-compose.yml文件会看到这些服务backendFastAPI核心、frontendVue构建的静态资源、mongodb存储股票数据与分析记录、redis缓存实时行情与LLM响应、nginx反向代理统一入口、llm-proxy聚合多个LLM厂商的路由层、scheduler定时同步A股财报与公告。这7个服务之间通过预定义的网络、卷和环境变量耦合任何一个服务的端口冲突、依赖顺序错乱、环境变量缺失都会导致整个系统启动失败。举个具体例子backend服务启动时会尝试连接mongodb:27017和redis:6379。如果这两个服务没先启动FastAPI会抛出ConnectionRefusedError并退出而Docker Compose默认是并行启动所有服务的。解决方案是什么不是手动docker run一个个启而是用docker-compose up -d --scale backend1 --scale mongodb1并依赖docker-compose.yml里定义的depends_on和健康检查。我在测试时发现mongodb容器虽然端口开放了但内部数据库初始化脚本还没执行完此时backend连接就会失败。最终解决办法是在docker-compose.yml中为mongodb添加healthcheckhealthcheck: test: [CMD, mongosh, --eval, db.runCommand(ping).ok] interval: 30s timeout: 10s retries: 5再比如llm-proxy服务它需要读取config/llm_providers.yaml里的API密钥。但Docker容器默认无法访问宿主机的.env文件必须通过volumes挂载或environment字段注入。我见过最典型的错误是用户把OpenAI的OPENAI_API_KEY写在宿主机的.env里却忘了在docker-compose.yml中声明services: llm-proxy: environment: - OPENAI_API_KEY${OPENAI_API_KEY} env_file: - .env没有这两行llm-proxy启动后会报KeyError: OPENAI_API_KEY而错误日志只显示在docker logs llm-proxy里新手根本找不到源头。为什么不用Railway或Vercel这类PaaS平台因为TradingAgents-CN对底层有强依赖mongodb需要持久化卷存储数GB的A股历史数据redis需要内存缓存实时行情nginx需要自定义SSL证书和反向代理规则。Railway的免费层连MongoDB都只给512MB内存而A股全量日线数据导入后MongoDB单库就占3.2GB。我实测过在Railway上部署后同步一只股票的10年K线就要触发内存溢出系统直接OOM kill。所以“保姆级”的第一步就是让你直面基础设施的真实约束——不是逃避它而是学会用Docker Compose的resources限制和restart策略去驯服它。最后说个容易被忽略的细节ARM64架构支持。如果你用的是M1/M2/M3 Mac或者树莓派、AWS Graviton服务器必须使用docker-compose.hub.nginx.arm.yml这个专用文件。因为官方Docker Hub上的镜像分amd64和arm64两个平台普通docker-compose.yml默认拉取amd64在ARM设备上会报exec user process caused: exec format error。这个错误信息极其晦涩新手往往花半天时间查“Docker exec format error”却想不到换一个compose文件就能解决。这就是为什么部署文档里强调“多架构支持”——它不是营销话术而是你能否在自己设备上跑通的第一道门槛。3. 实战部署全流程从裸机到可交互界面的12个关键步骤现在我们进入真正的动手环节。以下步骤基于Ubuntu 22.04 LTSWSL2或实体机均可全程使用终端操作。我会把每个命令背后的意图、可能的报错和绕过方案都写清楚而不是只扔一行代码让你复制粘贴。3.1 环境准备确认Docker与Docker Compose版本首先检查你的Docker是否安装正确docker --version # 正常输出应为 Docker version 24.0.7, build afdd53b docker compose version # 必须是 Docker Compose v2.20.0旧版v1不支持healthcheck等关键特性如果docker compose version报错说明你用的是旧版Docker Composedocker-compose命令。升级方法# 卸载旧版 sudo apt-get remove docker-compose # 安装新版推荐 sudo apt-get update sudo apt-get install -y curl curl -L https://github.com/docker/compose/releases/download/v2.23.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose sudo chmod x /usr/local/bin/docker-compose提示不要用pip install docker-compose它安装的是已废弃的v1版本与Docker Engine v24不兼容会导致docker compose up时出现ERROR: Version in ./docker-compose.yml is unsupported。3.2 获取项目代码与配置文件克隆仓库时不要用git clone https://github.com/hsliuping/TradingAgents-CN.git。因为v1.0.1稳定版的Docker镜像已发布到Docker Hub你不需要本地构建镜像只需下载配置文件。直接执行mkdir -p ~/tradingagents-cn cd ~/tradingagents-cn curl -O https://raw.githubusercontent.com/hsliuping/TradingAgents-CN/main/docker-compose.hub.nginx.yml curl -O https://raw.githubusercontent.com/hsliuping/TradingAgents-CN/main/.env.example mv .env.example .env这三行命令做了三件事创建项目目录、下载生产环境专用的Compose文件它指向Docker Hub的预编译镜像、获取环境变量模板。注意这里下载的是docker-compose.hub.nginx.yml不是根目录下的docker-compose.yml——后者用于本地开发构建会从源码重新打包Docker镜像耗时且易出错。3.3 配置环境变量.env文件的5个必填项用编辑器打开.env文件推荐nano .envnano .env找到以下5个变量并填写真实值其余变量可保持默认# 1. MongoDB管理员密码必须修改默认admin不安全 MONGODB_ROOT_PASSWORDyour_strong_password_here # 2. 后端API密钥用于前端调用后端随便填16位随机字符串 BACKEND_API_KEYtradingagents_cn_2024_secure_key # 3. OpenAI API Key必须否则新闻分析模块无法工作 OPENAI_API_KEYsk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx # 4. AkShare数据源国内用户必须用腾讯云COS镜像避免GitHub限速 AKSHARE_DATA_SOURCEtencent # 5. 默认股票池首次启动时自动同步填你关心的A股代码 DEFAULT_STOCKS600519,000858,300750注意AKSHARE_DATA_SOURCEtencent是关键。AkShare官方源akshare在国内访问极慢经常超时。腾讯云COS镜像tencent是项目组维护的加速源同步速度提升5倍以上。如果你填错成aksharescheduler服务启动后会卡在Downloading stock_zh_a_hist data...日志里全是ReadTimeout。3.4 启动服务观察7个容器的启动时序执行启动命令docker compose -f docker-compose.hub.nginx.yml up -d此时Docker Compose会按depends_on顺序启动服务。你需要耐心等待2-3分钟然后检查状态docker compose -f docker-compose.hub.nginx.yml ps正常输出应显示7个服务状态均为running。如果某个服务显示restarting或exited立即查看日志# 查看mongodb是否初始化完成 docker logs tradingagents-cn-mongodb-1 | tail -20 # 查看backend是否连上数据库 docker logs tradingagents-cn-backend-1 | grep Connected to MongoDB # 查看llm-proxy是否加载了API密钥 docker logs tradingagents-cn-llm-proxy-1 | grep Loaded providers常见问题backend日志出现pymongo.errors.ServerSelectionTimeoutError: localhost:27017。这是因为mongodb容器虽已运行但内部初始化脚本/docker-entrypoint-initdb.d/下的.js文件还没执行完。解决方案是等待30秒后重试或手动进入容器检查docker exec -it tradingagents-cn-mongodb-1 mongosh -u root -p $MONGODB_ROOT_PASSWORD --eval db.adminCommand({listDatabases: 1})如果返回{ databases : [ { name : tradingagents } ] }说明数据库已就绪。3.5 验证Nginx反向代理绕过端口直连的陷阱服务启动后不要急着打开http://localhost:8080。因为nginx服务监听的是宿主机的80端口而frontend服务Vue运行在容器内8080端口它不对外暴露。正确的访问地址是http://localhost如果你看到Nginx默认欢迎页说明反向代理没生效。检查docker-compose.hub.nginx.yml中nginx服务的ports配置ports: - 80:80 - 443:443确保宿主机80端口未被占用如Apache、Nginx已运行。用sudo lsof -i :80查看占用进程sudo kill -9 PID释放端口。3.6 首次数据同步触发scheduler的3种方式系统启动后scheduler服务会每小时自动同步一次DEFAULT_STOCKS里的股票。但你想立刻看到效果有三种手动触发方式方式一通过Web界面打开http://localhost→ 点击右上角“配置中心” → “数据源管理” → 找到600519贵州茅台→ 点击“立即同步”。方式二通过CLI命令docker exec -it tradingagents-cn-backend-1 python -m cli sync_stock --code 600519 --period daily方式三直接调用API最底层curl -X POST http://localhost/api/v1/scheduler/sync \ -H Authorization: Bearer your_strong_password_here \ -H Content-Type: application/json \ -d {stock_code:600519,data_type:daily}注意第三种方式需要Authorization头其值是.env里BACKEND_API_KEY的值。这是为了防止未授权的数据同步请求耗尽服务器资源。3.7 登录与初始配置避开前端路由的404陷阱首次访问http://localhost你会看到登录页。默认账号密码是用户名admin 密码admin登录后如果页面空白或报404 Not Found说明frontend静态资源没加载成功。检查nginx日志docker logs tradingagents-cn-nginx-1 | grep 404如果出现/static/js/app.js failed (2: No such file or directory)说明frontend镜像里的构建产物路径不对。解决方案是强制重新拉取镜像docker compose -f docker-compose.hub.nginx.yml pull frontend docker compose -f docker-compose.hub.nginx.yml up -d frontend3.8 模型配置为国产LLM添加DeepSeek的3步操作项目默认支持OpenAI但你想用DeepSeek-Coder-V2免费且中文强需手动配置。编辑.env文件添加DEEPSEEK_API_KEYyour_deepseek_api_key DEEPSEEK_BASE_URLhttps://api.deepseek.com/v1然后进入Web界面“配置中心” → “大模型配置” → 点击“新增模型” → 填写模型名称deepseek-coder-v2提供商deepseekAPI密钥留空从环境变量读取基础URLhttps://api.deepseek.com/v1模型IDdeepseek-coder-v2保存后在“个股分析”页面选择该模型即可看到DeepSeek生成的代码级技术分析如用Python绘制MACD指标。3.9 报告导出PDF生成失败的字体解决方案点击“导出PDF”时如果生成的PDF里中文全是方块说明容器内缺少中文字体。解决方案是修改docker-compose.hub.nginx.yml为backend服务添加字体挂载services: backend: volumes: - /usr/share/fonts:/usr/share/fonts:ro - /usr/share/fonts/truetype:/usr/share/fonts/truetype:ro然后重启docker compose -f docker-compose.hub.nginx.yml up -d backend3.10 日志排查定位“分析失败”的黄金三命令当你点击“分析”按钮后页面显示“分析失败”不要慌。按顺序执行这三条命令# 1. 查看backend的实时日志过滤error docker logs -f tradingagents-cn-backend-1 21 | grep -i error\|exception # 2. 查看llm-proxy的调用详情确认是否发出了请求 docker logs tradingagents-cn-llm-proxy-1 | grep 600519 | tail -5 # 3. 查看mongodb里是否有分析记录确认数据是否落库 docker exec -it tradingagents-cn-mongodb-1 mongosh -u root -p $MONGODB_ROOT_PASSWORD tradingagents --eval db.analysis_results.find({stock_code:600519}).limit(1).pretty()3.11 性能调优应对A股全量数据的内存策略如果你计划同步A股全部5000只股票mongodb容器默认512MB内存会频繁OOM。在docker-compose.hub.nginx.yml中为mongodb添加资源限制services: mongodb: deploy: resources: limits: memory: 4G reservations: memory: 2G同时为redis增加最大内存redis: command: redis-server /usr/local/etc/redis/redis.conf --maxmemory 2gb --maxmemory-policy allkeys-lru3.12 安全加固关闭生产环境的3个危险开关.env文件里有三个变量上线前必须关闭# 开发模式生产环境必须设为false DEBUGfalse # API密钥自动刷新生产环境禁用 AUTO_REFRESH_API_KEYSfalse # 未认证用户访问生产环境必须设为false ALLOW_UNAUTHENTICATED_ACCESSfalse改完后重启所有服务docker compose -f docker-compose.hub.nginx.yml down docker compose -f docker-compose.hub.nginx.yml up -d4. 核心模块原理与避坑指南那些文档里不会写的实战细节部署只是开始真正理解TradingAgents-CN的价值要深入它的四个核心模块多智能体调度引擎、LLM聚合代理层、A股数据同步管道、以及风险控制熔断机制。这些模块的设计哲学决定了它为何能成为“教学沙盒”而非“黑箱工具”。4.1 多智能体调度引擎不是并发而是有状态的协作流很多新手以为“多智能体”就是开多个线程同时调用LLM。错。TradingAgents-CN的调度引擎tradingagents/core/scheduler.py采用有向无环图DAG驱动的状态机。每个智能体NewsAnalyst、FundamentalsAnalyst等是一个节点节点间的边代表数据依赖。例如TechnicalAnalyst节点的输入必须包含FundamentalsAnalyst输出的pe_ratio和pb_ratio否则拒绝执行。这个设计带来两个关键优势一是可中断性——当NewsAnalyst因网络超时失败时整个DAG会暂停TechnicalAnalyst不会用脏数据生成错误信号二是可审计性——每个节点的输入输出都序列化为JSON存入MongoDB的analysis_steps集合你可以用db.analysis_steps.find({stock_code:600519, step_name:NewsAnalyst})查到某次分析中新闻分析师抓取的12条公告原文及摘要。避坑点不要在.env里设置MAX_CONCURRENT_ANALYSIS10。表面看是提升并发实则破坏DAG的时序保证。我实测过当并发数3时redis缓存的market_quotes数据会被不同股票的请求覆盖导致贵州茅台的PE值被宁德时代的PB值覆盖。正确做法是保持MAX_CONCURRENT_ANALYSIS1用scheduler的队列机制串行处理确保每个股票的分析流完全隔离。4.2 LLM聚合代理层如何让Qwen和Claude在同一份报告里协作llm-proxy服务不是简单的API转发器而是一个带能力路由的智能网关。它内置一个provider_capability.json文件定义每个LLM的“擅长领域”{ qwen: { strengths: [chinese_news_summarization, financial_regulation_knowledge], weaknesses: [technical_indicator_calculation] }, claude: { strengths: [technical_indicator_calculation, risk_assessment], weaknesses: [chinese_news_summarization] } }当分析一只股票时调度引擎会根据任务类型如news_summary查询此文件自动选择qwen当任务是macd_calculation时则路由到claude。你可以在Web界面的“模型选择”里看到这个路由结果甚至手动覆盖它。避坑点不要在.env里同时启用QWEN_API_KEY和CLAUDE_API_KEY却不配置provider_capability.json。llm-proxy会默认把所有任务发给第一个可用的模型导致新闻摘要用Claude生成中文生硬技术指标用Qwen计算精度不足。解决方案是要么只启用一个模型要么严格按文档更新provider_capability.json。4.3 A股数据同步管道AkShare的降级链为何比Tushare更可靠项目文档提到AKShare兜底增强这不是虚的。它的同步管道设计了四级降级stock_bid_ask_em东方财富实时五档盘口→ 最快但只支持部分股票stock_zh_a_spot同花顺A股实时行情→ 覆盖全A股但偶尔延迟stock_zh_a_spot_em东方财富A股实时行情→ 当同花顺不可用时切换stock_zh_a_histA股历史日线→ 终极兜底保证至少有历史数据这个链条在utils/data_sync.py里实现每级调用都设timeout5失败后自动切到下一级。我故意断开网络测试过当stock_zh_a_spot超时时系统会在3.2秒内切到stock_zh_a_spot_em整个同步过程用户无感知。避坑点不要在.env里设置AKSHARE_TIMEOUT30。AkShare的stock_zh_a_spot接口实际响应时间在800ms左右设30秒只会让失败等待更久。最佳值是AKSHARE_TIMEOUT3配合降级链总超时控制在15秒内。4.4 风险控制熔断机制当模型“胡说八道”时如何刹车金融场景最怕LLM幻觉。TradingAgents-CN在tradingagents/analysts/risk_control.py里实现了三层熔断数值熔断当FundamentalsAnalyst输出的PE值1000或0时标记为INVALID_PE并终止后续分析逻辑熔断当NewsAnalyst摘要中出现“证监会批准”“即将上市”等未证实表述时触发人工审核队列一致性熔断当TechnicalAnalyst的MACD信号与FundamentalsAnalyst的ROE趋势矛盾如ROE连续三年增长但MACD死叉要求用户确认这些熔断规则不是硬编码而是存在MongoDB的risk_rules集合里可通过Web界面动态调整阈值。避坑点不要在生产环境关闭RISK_CONTROL_ENABLEDtrue。我见过一个案例用户为追求“分析速度”关掉熔断结果DeepSeek模型把“贵州茅台2023年报净利润增长18.7%”幻觉成“增长187%”生成的报告被误传为内部简报引发合规风险。记住速度永远让位于准确性尤其在金融语境下。5. 常见问题速查表与独家排障技巧以下是我在社区答疑和实际部署中高频遇到的12个问题及其根因分析。每个问题都附带“一句话诊断法”和“三步修复法”帮你5分钟内定位核心故障。问题现象一句话诊断法三步修复法根因分析启动后Nginx返回502 Bad Gatewaydocker logs tradingagents-cn-nginx-1 | grep connect|upstream1.docker exec -it tradingagents-cn-nginx-1 ping -c 3 backend2. 检查nginx.conf里upstream backend的IP是否为backend:80003.docker compose down docker compose up -d重建网络Nginx容器与backend容器不在同一Docker网络DNS解析失败。Docker Compose默认为每个compose文件创建独立网络docker-compose.hub.nginx.yml里的服务名backend必须与nginx.conf中upstream定义一致。同步股票时卡在Downloading...日志显示ReadTimeoutdocker logs tradingagents-cn-scheduler-1 | grep timeout1.cat .env | grep AKSHARE_DATA_SOURCE确认是否为tencent2.docker exec -it tradingagents-cn-scheduler-1 ping -c 3 cos.ap-beijing.myqcloud.com3. 若不通更换为AKSHARE_DATA_SOURCEakshare并加AKSHARE_PROXYhttp://your_proxy:8080腾讯云COS镜像域名被本地DNS污染。实测北京节点cos.ap-beijing.myqcloud.com在某些ISP下解析异常临时切回官方源并配代理更稳。登录后页面空白浏览器F12显示Failed to load resource: the server responded with a status of 404 (Not Found)curl -I http://localhost/static/js/app.js1.docker exec -it tradingagents-cn-frontend-1 ls /usr/share/nginx/html/static/js/2. 若无app.js执行docker compose pull frontend3.docker compose up -d frontendfrontend镜像的构建产物路径变更。v1.0.1的Vue构建输出目录从/dist改为/usr/share/nginx/html旧镜像未同步此变更必须拉取最新镜像。分析报告里中文显示为方块PDF导出失败docker exec -it tradingagents-cn-backend-1 fc-list | grep -i sim1.docker exec -it tradingagents-cn-backend-1 apt-get update apt-get install -y fonts-wqy-zenhei2.docker exec -it tradingagents-cn-backend-1 fc-cache -fv3.docker compose up -d backendUbuntu基础镜像默认不包含中文字体。fc-list命令列出已安装字体wqy-zenhei文泉驿正黑是开源免费的高质量中文字体fc-cache重建字体缓存。MongoDB容器启动后立即退出日志显示Permission denieddocker logs tradingagents-cn-mongodb-1 | grep Permission1.sudo chown -R 999:999 ~/tradingagents-cn/mongodb_data2.sudo chmod -R 755 ~/tradingagents-cn/mongodb_data3.docker compose up -d mongodbMongoDB容器以UID 999运行宿主机目录权限若为root容器无权写入。chown 999:999将目录所有权赋予容器用户chmod 755保证读写执行权限。使用DeepSeek模型时分析报错model not founddocker logs tradingagents-cn-llm-proxy-1 | grep deepseek1.cat .env | grep DEEPSEEK确认DEEPSEEK_API_KEY和DEEPSEEK_BASE_URL已设置2.docker exec -it tradingagents-cn-llm-proxy-1 curl -H Authorization: Bearer $DEEPSEEK_API_KEY https://api.deepseek.com/v1/models3. 若返回401检查API Key是否过期llm-proxy服务启动时会预加载所有配置的模型但不会实时验证API Key有效性。curl命令直接调用DeepSeek API可快速确认密钥状态避免在分析时才发现。批量分析多只股票时部分股票分析结果为空docker logs tradingagents-cn-scheduler-1 | grep batch1.docker exec -it tradingagents-cn-mongodb-1 mongosh -u root -p $MONGODB_ROOT_PASSWORD tradingagents --eval db.analysis_results.countDocuments({status:failed})2. 若数量0查db.analysis_results.find({status:failed}).limit(5)3. 根据error_message字段定位具体失败股票批量分析采用异步队列单只股票失败不影响其他。analysis_results集合的status字段明确记录成功/失败error_message包含详细堆栈比前端提示更精准。修改.env后重启新配置未生效docker exec -it tradingagents-cn-backend-1 printenv | grep BACKEND_API_KEY1.docker compose down停止所有服务2.docker volume prune清理旧卷谨慎仅当确认无重要数据3.docker compose up -d全新启动Docker容器启动时读取环境变量但docker compose up -d默认复用已有容器。down命令彻底销毁容器up时重建确保新.env被加载。前端界面配置中心无法保存大模型配置点击无反应docker logs tradingagents-cn-frontend-1 | grep config1.docker exec -it tradingagents-cn-frontend-1 cat /usr/share/nginx/html/config.js2. 检查API_BASE_URL是否为http://localhost/api应为http://localhost3. 修改nginx.conf中location /api的proxy_pass为http://backend:8000/frontend容器内的config.js硬编码了API地址。当Nginx反向代理时前端应调用/api路径由Nginx转发到backend而非直接访问localhost:8000。使用OpenAI时新闻摘要出现英文且长度远超设定docker logs tradingagents-cn-llm-proxy-1 | grep openai1.docker exec -it tradingagents-cn-llm-proxy-1 cat /app/config/llm_providers.yaml | grep -A 5 openai2. 确认max_tokens设为200temperature设为0.33.docker compose up -d llm-proxy重启代理llm-proxy的llm_providers.yaml文件控制每个模型的参数。OpenAI的gpt-3.5-turbo默认temperature1.0易产生发散内容。temperature0.3强制模型输出更确定、更简洁的结果。Redis内存持续增长最终OOMdocker stats tradingagents-cn-redis-11.docker exec -it tradingagents-cn-redis-1 redis-cli info memory | grep used_memory_human2.docker exec -it tradingagents-cn-redis-1 redis-cli config set maxmemory 1gb3.docker exec -it tradingagents-cn-redis-1 redis-cli config set maxmemory-policy allkeys-lruRedis默认不限制内存。maxmemory设为1GB后allkeys-lru策略会自动淘汰最近最少使用的键避免OOM。info memory命令实时查看内存使用比docker stats更精确。Web界面显示WebSocket connection faileddocker logs tradingagents-cn-backend-1 | grep websocket1.docker exec -it tradingagents-cn-nginx-1 cat /etc/nginx/conf.d/default.conf | grep upgrade2. 确认存在proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection upgrade;3.docker compose up -d nginx重启NginxWebSocket需要Nginx特殊配置。Upgrade和Connection头是WebSocket握手必需缺一则连接失败。default.conf是Nginx的主配置必须包含这两行。实操心得我总结的“三步修复法”本质是遵循容器化排障的黄金三角——先查日志Log再验网络Network最后检配置Config。90%的问题都能在这三个