先讲一段个人观察前几年做交易决策常见路径是打开行情软件、翻几篇研报、再看一眼新闻标题最后凭感觉下单。这个过程最大的问题不是信息太少而是信息太散且缺少一个持续、可对抗的决策结构。TauricResearch 开源的 TradingAgents 提供了一个很有意思的解决思路把大模型组织成一支“虚拟交易团队”用多智能体协作替代单人拍板让研究、交易、风控、合规各司其职再通过辩论机制收敛出一份相对理性的交易决策。这篇文章会从多智能体设计、环境搭建、配置说明、本地运行到核心代码解读逐步展开适合想用 LLM Agent 做金融实验的开发者也适合正在设计多智能体协作系统的后端工程师。1. TradingAgents 是什么1.1 它解决什么问题传统交易决策链路中人的认知负荷是很大的。既要看基本面数据又要跟踪新闻情绪还要考虑仓位风险甚至要面对自身情绪的干扰。单个模型 Agent 虽然能完成一部分信息处理但很难对同一份信息形成多角度判断。TradingAgents 的定位是一个基于大型语言模型的多智能体金融交易框架。它把一次投资决策拆解为多个角色研究分析师负责解读行情与新闻交易员负责构建多空论点风控经理负责评估风险投资组合经理负责最终决策合规顾问负责规则审查。每个角色由一个或多个 LLM Agent 承担Agent 之间通过结构化对话完成信息交换。用比较通俗的话来说如果过去是一个人面对一堆数据那么 TradingAgents 就是搭建了一个“线上投研会议室”有人整理材料有人提多空观点有人挑毛病最后由一个人拍板。这种结构天然具备对抗性与冗余性能减少单一模型输出不稳定带来的决策偏差。1.2 适用场景这个框架适合以下几类场景个人量化研究者用 LLM 快速获取多空分析报告辅助人工决策。Agent 开发者学习多智能体协作、辩论机制、工具调用与记忆管理的工程实现。金融科技产品原型验证在 Demo 中演示“ AI 投研助手”的效果。教学场景展示大模型在垂直领域的 Multi-Agent 编排方式。需要说明的是TradingAgents 并不是一个自动交易机器人。它生产分析报告、交易信号和辩论纪要最终是否执行交易、如何执行仍然需要用户自己判断与操作。官方文档也明确强调项目仅供教育与研究使用不构成投资建议。1.3 为什么值得关注从技术角度看TradingAgents 的价值在于它是“通用 Agent 框架 金融垂直场景”的完整范本。它没有重新发明 Agent 基础设施而是基于 LangChain、LangGraph 等生态把 Agent 的规划、工具调用、记忆和协作串了起来。对于想理解 Multi-Agent 系统如何落地的人来说这套代码比抽象的理论文章直观得多。2. 核心机制多智能体协作与对抗2.1 角色成员构成TradingAgents 的典型成员包括角色职责核心能力Research Analyst收集新闻、行情、基本面信息工具调用、摘要生成TradersBull/Bear分别构建看多与看空论点多空辩论、逻辑推理Risk Management评估仓位风险、最大回撤、波动率风险量化、上下文审查Portfolio Manager结合多空论点与风控意见做出最终决策综合判断、行动输出Compliance审查合规风险与偏见规则校验、安全提示这里比较核心的设计是 Bull 与 Bear 的对抗。框架会要求两个交易员分别站在多方和空方用各自的论据完成辩论然后再由其他角色参与评价。这样一个信息源会被从两个方向审视降低“模型只输出一边倒结论”的概率。2.2 辩论机制的工作流程整个决策流程可以简化如下触发研究任务输入股票代码/加密货币代码。Research Analyst 拉取新闻、行情数据输出研究报告。Bull Trader 依据报告构建看多论点。Bear Trader 依据报告构建看空论点。双方向对方提问进行多轮辩论。Risk Management 基于辩论上下文评估潜在风险。Portfolio Manager 综合研究报告、辩论纪要与风控意见输出 BUY/SELL/HOLD 决策及其理由。Compliance 对决策做合规审查完成最终报告。这个流程的可取之处在于它不是一次性 Prompt 输出了事而是把“思考”过程拆成了多个阶段并让每个阶段产出结构化的中间结果。即使最终结论不准确用户也能从辩论纪要中看到模型的推理依据而不是面对一个莫名的输出。2.3 工具与外部知识接入Agent 本身不具备实时数据能力必须依赖外部工具。TradingAgents 中常用的工具包括新闻搜索工具例如 Tavily检索公司最新新闻与市场情绪。行情数据工具例如 AlphaVantage、FinnHub获取价格、成交量等指标。数据库例如 DuckDB本地缓存历史数据与运行结果。项目通过 LangChain 的 Tool 机制把这些 API 封装成 Agent 可调用的能力。用户需要自行申请对应 API Key并在配置文件中完成设置。3. 环境准备与项目结构3.1 运行环境说明TradingAgents 本质是一个 Python 项目本地运行需要准备Python 3.10不同版本对依赖兼容性有影响建议使用虚拟环境pip 或 poetry 包管理工具一个 LLM API 提供商OpenAI、DeepSeek、Claude、Gemini 等可选Tavily API Key、AlphaVantage API Key、FinnHub API Key可选DuckDB项目会在本地创建数据库文件版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。建议在 Python 3.10 或 3.11 的虚拟环境中运行避免系统 Python 环境被项目依赖污染。3.2 克隆项目并安装依赖将项目克隆到本地git clone https://github.com/TauricResearch/TradingAgents.git cd TradingAgents创建虚拟环境python3 -m venv venv source venv/bin/activate安装项目依赖pip install -r requirements.txt如果你的机器支持 CUDA 且需要使用本地模型可以额外关注项目文档中的安装说明。大多数情况下直接使用云端 LLM API 的场景不需要本地 GPU。3.3 项目结构概览克隆下来后目录中几个关键文件的作用如下TradingAgents/ ├── tradingagents/ │ ├── agents/ │ │ ├── research_analyst.py │ │ ├── traders.py │ │ ├── risk_management.py │ │ ├── portfolio_manager.py │ │ └── compliance.py │ ├── graph/ │ │ └── ... │ ├── tools/ │ │ └── ... │ ├── utils/ │ └── ... ├── config.yaml ├── research.py ├── trade.py ├── backtest.py ├── recorder.py └── requirements.txt主流程中research.py执行研究流程只产出研究报告。trade.py执行完整交易决策流程输出交易信号。backtest.py在历史数据上运行策略生成回测结果。recorder.py将运行结果记录到本地数据库。config.yaml集中管理模型提供商、API Key、Agent 参数等。4. 配置详解4.1 主要配置项项目根目录下的config.yaml是核心配置文件。需要根据你自己的 API 服务商调整。以使用 OpenAI 兼容接口为例配置文件中的核心部分如下llm: provider: openai model: gpt-4o temperature: 0.5 max_tokens: 2048配置说明provider模型提供商支持 openai、deepseek、anthropic、gemini 等。model使用的具体模型名称需要和 API 服务商提供的能力对应。temperature采样温度值越低输出越稳定值越高越有创造性。金融分析场景建议不要过高。max_tokens单次生成的最大 token 数研究报告和辩论纪要内容较长建议不要设置过小。如果你的 API 服务商提供 OpenAI 兼容接口可以使用base_url配置自定义接口地址。很多国内模型服务都兼容 OpenAI 协议这种配置方式比较通用。4.2 API Key 管理金融数据工具和 LLM API 的密钥不要硬编码在config.yaml中提交到 Git推荐使用环境变量export OPENAI_API_KEYyour-key export TAVILY_API_KEYyour-tavily-key export ALPHAVANTAGE_API_KEYyour-alpha-vantage-key export FINNHUB_API_KEYyour-finnhub-key项目在读取配置时也会优先查找环境变量这样的好处是不同环境本地、测试、服务器可以复用同一份config.yaml密钥只在运行环境中注入。4.3 多模型组合一个值得关注的设计是TradingAgents 允许不同 Agent 使用不同模型。可以在配置中为研究分析师、交易员、投资组合经理分别指定模型agents: research_analyst: model: deepseek-chat trader: model: openai/gpt-4o portfolio_manager: model: anthropic/claude-3-5-sonnet这样做的好处是研究分析任务需要较强的长文本理解能力辩论任务需要较好的推理能力而最终决策需要稳定、低温度的输出。不同角色使用不同模型可以在成本与效果之间取得平衡。当然这也会让配置和排错更复杂建议先在单一模型下跑通流程再逐步替换角色模型。5. 本地运行研究、交易与回测5.1 运行研究流程研究流程是理解整个系统的最短路径。运行命令python research.py --ticker AAPL这里的--ticker参数可以是美股代码也可以根据项目文档传入加密货币代码。运行后系统会依次执行研究分析、生成报告并打印出研究结果。第一次运行会消耗一定时间因为多个 Agent 是串行协作的每一步都有 LLM 调用耗时。预期输出包括研究分析师的观点摘要。相关新闻与数据信息。技术面与基本面的判断。最终投资论点摘要。5.2 运行完整交易决策流程python trade.py --ticker AAPL --budget 10000--budget表示投资金额这个参数主要用于让投资组合经理在做仓位建议时有一个金额上下文。完整流程运行结束后会输出类似下面的决策信号Investment Action: BUY Confidence: 0.7 Reason: 多头辩论胜出风险可控技术面出现向上突破信号值得强调的是这里的 BUY/SELL/HOLD 只是一个结构化的模型输出不是真实交易指令。你还需要检查辩论纪要、风控意见和生产环境中的实际市场情况再做人工判断。5.3 回测模式python backtest.py回测模式会比较复杂需要先准备好历史数据与策略参数。不同版本的回测实现差异较大建议先阅读项目 README 中的回测章节再根据自己需求调整。回测的意义在于在投入真实资金之前先用历史数据验证策略在特定市场环境下的表现。5.4 配置 Streamlit UI可选项目文档中提到了一个可视化界面 AgentEar用于以聊天形式展示 Agent 决策过程。如果你希望更直观地观察多智能体协作可以按文档启动 UIstreamlit run agentear/app.pyUI 界面通常需要在本地浏览器中访问适合演示与调试。6. 核心代码解读6.1 研究分析师 Agent研究分析师的职责是收集信息并生成研究报告。它的核心思路是给 Agent 一组工具新闻搜索、行情查询让它先“调研”再输出结构化报告。下面是一个简化思路示例实际代码路径在tradingagents/agents/research_analyst.pyclass ResearchAnalyst: def __init__(self, llm, tools): self.llm llm self.tools tools def analyze(self, ticker: str) - str: # 1. 收集新闻与行情 news self.tools.search_news(ticker) price self.tools.get_price(ticker) # 2. 构建研究提示 prompt f 你是一名专业研究分析师。 请基于以下信息分析 {ticker} 的投资价值。 最新新闻 {news} 最新价格数据 {price} 请输出研究报告包括基本面摘要、新闻情绪、技术面观察。 # 3. 调用大模型生成报告 report self.llm.invoke(prompt) return report这里的重点是Agent 本身不产生数据它只是把数据组织成 Prompt再让 LLM 完成推理。工具层的数据质量直接决定研究报告质量。6.2 交易员与辩论循环多智能体系统的核心在于 Agent 之间的信息交换。TradingAgents 的辩论环节并不是简单的“你一句我一句”而是让 Bull 和 Bear 分别输出论点、相互提问、再回应。这个过程可以用 LangGraph 的 StateGraph 来编排也可以用循环调用实现。简化思路如下def run_debate(bull_agent, bear_agent, report, rounds3): bull_arguments [] bear_arguments [] for i in range(rounds): bull_arg bull_agent.respond( reportreport, bear_argumentbear_arguments[-1] if bear_arguments else None ) bear_arg bear_agent.respond( reportreport, bull_argumentbull_arguments[-1] if bull_arguments else None ) bull_arguments.append(bull_arg) bear_arguments.append(bear_arg) return bull_arguments, bear_arguments这种设计让每一方都能看到对方的论据从而对自己的论点进行修正。如果没有这种对抗闭环模型非常容易“自说自话”只输出与第一条信息一致的观点。6.3 投资组合经理决策最终决策由 Portfolio Manager 负责。它会接收研究报告、多空辩论纪要、风控意见然后输出一个结构化的 JSON。输出格式类似{ action: BUY, confidence: 0.72, quantity: 10, reason: 多方论点在新闻催化与技术形态上占优风控提示仓位不超过总预算的20%, risk_flags: [高波动性, 行业政策不确定性] }为了让输出稳定Prompt 中通常会要求模型严格遵循 JSON 格式并对字段含义做明确说明。这也是生产级 Agent 工程中很常见的做法结构化输出比自由文本更容易被下游系统消费。6.4 记忆与持久化TradingAgents 使用 DuckDB 记录历史运行结果。运行完一次交易决策后结果会被写入本地数据库。这样做的价值在于可以对比不同时间点的决策变化。可以复盘模型在某次市场事件中的表现。可以为后续回测与策略调优积累数据。实际工程中数据库表结构需要根据项目文档或代码中的建表语句来确认不建议直接手工创建表。7. 常见问题与排查思路7.1 模型 API 调用失败问题现象常见原因解决思路401 UnauthorizedAPI Key 未设置或设置错误检查环境变量是否注入确认 Key 有足够额度404 Model Not Found模型名称与 API 服务商不匹配修改config.yaml中的模型名称Rate Limit 报错请求频率超过 API 限制降低并发次数或增大每次请求间隔超时无响应网络不通或模型服务响应慢检查网络代理调大timeout参数7.2 循环运行很久没有输出这种情况很常见。多智能体系统每次决策都会调用多次 LLM如果某个环节 Prompt 较长或者 API 响应慢整个流程可能需要数分钟。建议先用小模型跑通全流程再切换效果更好的模型。在代码中增加日志输出观察卡在哪个 Agent。控制辩论轮数不要一开始就设置很大。7.3 输出格式不稳定LLM 输出的 JSON 偶尔会有残缺或多余字符导致下游解析失败。解决方案使用 LangChain 的with_structured_output或 Pydantic 输出解析器。在 Prompt 中明确说明输出字段与类型。增加重试机制解析失败时重新调用模型。7.4 数据库文件不一致如果你改了代码或配置但查询结果仍是旧数据需要检查 DuckDB 数据文件是否被重复使用。建议按日期或 ticker 建立独立表定期清理缓存数据。7.5 不同版本差异导致 API 变更TradingAgents 迭代速度较快GitHub 主分支可能与文档中的示例不完全一致。遇到奇怪报错时优先查看项目 README、GitHub Issues 和最近提交记录确认是否因为版本升级引入了接口变化。8. 工程化最佳实践与风险提示8.1 不要在真实账户直接使用TradingAgents 是一个研究框架不是生产级交易系统。它的输出依赖于 LLM 的推理而大模型存在幻觉、延迟、上下文丢失等问题。任何基于该框架做出的交易决策都必须经过人工复核。建议用法把模型输出当作“第二意见”而非唯一依据。先在模拟盘或历史回测中验证策略。使用小仓位验证信号质量。对关键字段做人工二次确认。8.2 API Key 与数据安全金融数据往往涉及敏感信息。不要把 API Key、账户信息、交易密钥写入代码或配置文件后提交到公开仓库。推荐做法使用.env文件并在.gitignore中忽略。将密钥托管在环境变量或密钥管理服务中。团队协作时遵循最小权限原则只给必要成员开放数据源权限。8.3 日志、可观测性与迭代多智能体系统是典型的状态密集型系统决策链路长可观测性非常重要。建议在代码中增加结构化日志import logging logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) logger.info(ticker%s, agentresearch_analyst, statusstart, ticker) logger.info(ticker%s, agentportfolio_manager, action%s, ticker, action)这样能快速定位问题发生在哪个环节。也可以把每次运行的研究报告、辩论纪要、决策信号都落库便于对比不同模型参数下的输出质量。8.4 配置管理的演进当项目进入团队协作阶段建议将配置拆分为config.base.yaml公共配置如模型默认参数、日志级别。config.local.yaml本地开发配置。config.prod.yaml生产环境配置启用更强的风控校验。通过环境变量指定使用哪份配置而不是直接修改公共配置。这样可以避免“本地能跑服务器上不能跑”的问题。8.5 从学习到扩展的路径如果你想在 TradingAgents 基础上做二次开发推荐从三个方向入手增加新数据源接入更多财经新闻源、另类数据 API。增加新 Agent比如情绪分析师、宏观经济分析师。优化决策逻辑在 Portfolio Manager 中加入更严格的风控规则和仓位计算公式。开发时建议先写单元测试把每个 Agent 的输入输出固定下来再集成到主流程中。多智能体系统的维护成本主要来自状态流转与异常恢复提前做好接口设计能省去大量后期排查时间。9. 下一步学习建议如果读完本文后想深入掌握这套多智能体交易框架建议按下面的顺序继续学习先阅读trade.py主流程理清一个 ticker 从输入到输出的完整调用链。再阅读graph/目录下的状态图定义理解 LangGraph 如何管理多智能体状态。然后修改一个 Agent 的 Prompt观察输出变化建立对“提示词影响决策”的直觉。最后尝试接入自己的数据源或模型跑通一次全流程。金融场景下的 AI 应用并不只是“把 Prompt 写长一点”它需要严谨的结构、充分的可观测性和克制的风险意识。TradingAgents 提供了一个相当完整的参考实现值得花时间拆解。一个小技巧在本地试验时可以先让所有 Agent 使用同一个模型并把temperature调低到 0.2 左右先把流程跑通等稳定之后再逐步引入多模型组合、辩论轮数与工具调用。这种“先固定变量再逐步放开”的思路能帮你更快判断瓶颈出在数据、Prompt 还是模型能力上。