TradingAgents多智能体交易系统：从决策流水线到风控回测的完整工程实践

最近交易技术社区里冒出一个高频词：TradingAgents。如果你把英文拆开看，就是“交易智能体”。它既不是某个荐股软件，也不是传统量化策略，而是一整套把大型语言模型包装成“多角色交易团队”的开源框架思路。简单说，就是把一个真实交易公司里分析师、研究员、交易员、风控经理的工作流程，全部塞进多个LLM智能体里，让它们通过对话、辩论、证据核查、互相否决，最终产出交易决策。

这篇文章我会按技术拆解的方式聊清楚：TradingAgents这类系统到底改变了什么，它的核心机制为什么有价值，以及如果你自己动手搭一个最小可用的多智能体交易工作流，会踩到哪些我用真金白银换来的坑。全程只讲工程和技术原理，不构成任何投资建议。

1. TradingAgents不是什么“自动炒股机器人”，而是一套多人格决策流水线

很多人在第一次看到“多智能体交易”这个概念时，理解成“让AI自己开户、自己下单、自己赚钱”。这个理解不能说全错，但至少偏了十万八千里。TradingAgents的设计目标从来不是替代交易员去敲单，而是把原本只存在于一个大脑里的决策过程，拆成多个角色、多轮辩论、互相制衡的流水线。

1.1 从“单模型给答案”到“多角色给结论”：范式差异在哪

过去我们用LLM做投资分析，最常见的做法是：把新闻、财报、行情数据一股脑塞给ChatGPT，问一句“你觉得这只股票下周怎么走”，然后拿回答当参考。这种做法最大的问题是：模型一旦给出结论，你根本不知道它依据了哪条数据、忽略了多少反向信息、有没有做过风险校验。它像一个人关起门拍脑袋，整个过程完全不可审计。

TradingAgents改变的是这个“拍脑袋”过程。它把决策拆成了多个独立的思考节点：有人负责收集和解读信息，有人负责质疑和查证，有人负责把观点变成可执行计划，还有人专门负责泼冷水。这个流程本质上是把“一个可能产生幻觉的LLM”变成“一组相互制约、需要对自己的论点负责的LLM”。虽然每个Agent本身仍然是同一个基座模型，但它们拿着不同的提示词、不同的上下文、不同的工具权限，产出的内容就有了角色边界。

这一点非常关键：多智能体不等于更强的智能，而是等于更可控的流程。你不再关心某一次回答对还是错，而是关心整个团队有没有充分交换信息、有没有人做最终风险把关。

1.2 交易公司里的五类角色，如何映射成Agent

TradingAgents这类项目最吸引我的地方，是它把真实金融机构里的人员分工搬进了代码里。以目前社区里流传较广的角色设计为例，大致可以拆成五个岗位：

实际实现时不一定叫这些名字，但核心逻辑一致。分析师先输出偏向性观点，研究员必须用工具去查原始数据来验证，交易员不能直接看到行情就下单，风控经理拥有“一票否决权”。这种分工最大的好处是：没有任何单一智能体可以在没有交叉验证的情况下直接输出交易指令。

1.3 它真正解决的是决策透明度和过程可审计，而不是预测准确率

我见过不少人把多智能体框架的性能指标等同于“预测涨跌胜率”，这是一个误区。TradingAgents这类系统的真正价值在于：你可以把每一次决策过程中的所有中间产物拿出来复盘。分析师当时引用了哪条新闻？研究员验证时发现了什么矛盾？风控经理为什么否决？这些记录天然构成了“决策日志”。

对于做量化研究的人来说，这套日志的含金量远高于一个孤立的价格预测。因为你可以把“模型在某一天因某条新闻上调了预期”这件事本身当作一个可回放的信号，而不是追求一个模糊的“涨跌判断”。换句话说，TradingAgents提供的不只是结论，而是“结论的生成路径”。这也是为什么它适合被放在研究辅助、策略灵感和投教场景，而不是让人直接挂到实盘网关后面。

2. 多智能体协作不是噱头：对抗辩论、工具调用、独立风控三个机制拆解

理解了角色分工，接下来要回答一个更核心的问题：为什么多智能体协作比单个Agent更值得搭？这一节我会拆三个机制，它们分别解决LLM在交易场景里最致命的三个毛病：幻觉、没有实时数据、缺乏风险约束。

2.1 对抗式辩论：让模型在互相抬杠中暴露证据漏洞

LLM单独做分析时，经常出现一种“自信的通顺”。它能把一个错误的前提完整地、毫不含糊地推演出一套逻辑自洽的观点，而且语气越笃定，越容易让人放松警惕。对抗式辩论做的事情，是强制模型从两个对立立场去解读同一组数据。

具体实现时，系统会让看多Agent和看空Agent分别生成报告，要求每个论点都带上数据或新闻来源，然后把两份报告同时交给裁判Agent。裁判必须找出双方论据的矛盾点，再给出裁决。这个过程很像庭审：控辩双方各自举证，陪审团判断证据链是否完整。

实际跑下来你会发现，很多看多报告在“被反驳”的时候才暴露出问题。比如分析师说“公司营收增长强劲”，研究员一查原始财报发现，增长主要来自一次性资产处置，主营业务的贡献其实是下滑的。这种错误在单个Agent模式里很难被发现，但在多智能体辩论模式下，只要有人被分配了“找茬”立场，错误被抓住的概率就会显著提高。当然，对抗辩论不是无意义的抬杠，后面我会讲如何避免它变成两个立场各说各话。

2.2 工具调用：实时行情、新闻、财务数据都通过API注入，而不是靠模型“回忆”

LLM的训练数据有截止日期，它本身不掌握实时行情，更不知道今天早上发生了什么。如果直接问“现价是多少”，模型只会一本正经地编一个数字。TradingAgents类系统解决这个问题的标准方式，是把数据服务封装成工具函数，让Agent通过function calling主动调用。

拿我本地做的演示版来说，数据层封装了四类工具：

• get_history：取历史K线，用于技术面分析。
• get_realtime_quote：取实时报价，用于当前价格、涨跌幅。
• get_news：取相关新闻标题和正文，用于信息面解读。
• get_fundamentals：取财务指标，用于基本面验证。

每个工具都定义好参数和返回结构。比如get_news需要传入股票代码、时间范围、关键词，返回的每条新闻都会带一个news_id。为什么强调news_id？因为辩论节点要求论点必须引用证据ID，研究员可以拿着这个ID去查原文，避免Agent凭空捏造“某媒体报道了XX”。

我把这个思路叫“给模型装上可以查证的眼睛”。模型可以表达观点，但观点必须建立在实际返回的数据之上，而不是训练参数里的模糊记忆。这一步是降低幻觉最有效的手段，没有之一。

2.3 独立风控智能体：LLM系统里也必须有一个“合规安全员”

交易系统和人不一样，人亏钱会心疼、会犹豫、会停下来；代码不会。当多智能体已经给出一个看起来逻辑完整的交易计划时，如果没有独立的风控节点，系统很容易在一些“尾部风险”上翻车。

风控Agent在流程中的位置必须是“门禁”而不是“顾问”。它要对交易计划里的仓位、杠杆、止损距离做检查，还要模拟一些极端场景。比如：如果开盘直接跳空3%，这个仓位能不能承受；如果持仓集中在一只票上，单票黑天鹅会不会把整个账户打穿。硬性约束可以直接用代码写死，比如“单票仓位不得超过总资产的5%”，这个数字是代码逻辑，不是让LLM商量的。LLM负责做的是“结合上下文判断情景”，比如当市场情绪极度恐慌时，是否该把仓位上限从5%临时降到3%，这种软性调整才交给风控Agent去推理。

我在搭建时最深的体会是：不要把风控规则全都写进提示词，让模型“自觉遵守”。模型在长上下文里很容易忘记前文约束。正确的做法是硬规则写在代码里，软判断留在Agent里。一个没有风控门禁的多智能体系统，比单Agent更危险，因为它会用集体决策的外表，掩盖掉所有人的共同盲区。

3. 从零搭建一个最小可用的TradingAgents工作流：选型、工具、人和指令流转

如果你看完前面觉得这套思路值得动手试一试，这一节就是你需要的。我不打算直接让你去复刻一个庞大的生产系统，而是教你搭一个最小闭环：能读数据、能生成多角色报告、能产出交易计划、能做基础回测。整个工作流大概几百行代码能跑通。

3.1 选型：框架底座、模型和数据源怎么配

先说框架。目前适合做多智能体编排的工具有LangGraph、AutoGen、CrewAI，我自己最常用的是LangGraph，原因是它把智能体之间的流转建模成一张有向图，支持条件分支、循环、提前终止，非常适合实现“辩论不超过N轮”“风控否决后重新回传给交易员”这类逻辑。

模型层面，建议按照角色做分层，而不是所有Agent都用同一个最强模型。我常用的搭配是：

数据源我特别说一句：很多人在模型选型上花大量精力，却忽略了数据质量。模型再强，喂进去的数据时间戳是错的，产出的决策就是废的。建议一开始先用本地数据集，比如导出一只股票一年的日K线加上对应的新闻时间流，把流程跑通，再去接实时API。

3.2 数据层：把行情和新闻封装成模型可调用的工具

工具封装的核心是“给模型一个清晰的函数签名”。下面是一个简化的Python示例，演示如何用LangChain的Tool接口包装一个新闻查询函数：

from langchain_core.tools import tool @tool def get_news(symbol: str, start_date: str, end_date: str, max_results: int = 5) -> list[dict]: """获取指定股票在日期范围内的相关新闻列表，返回包含news_id, title, summary, publish_time的字典。""" # 这里接入你的新闻数据源，比如AkShare新闻接口或本地CSV rows = load_news_from_local(symbol, start_date, end_date) return rows[:max_results]

你可能会问：为什么这里不直接把新闻全文返回？因为上下文窗口有限，新闻全文太长会污染Agent注意力。比较好的做法是在工具内部先做截断、去重、关键句抽取，只返回几百字以内的摘要，同时保留news_id让研究员能溯源。我习惯在工具返回里加一个source字段，格式类似“data_source=akshare, news_id=12345”，这样后续辩论时，证据引用可以直接指向这条ID。

3.3 角色提示词：给每个Agent立人设、定输出格式、限制发挥边界

提示词是决定多智能体质量的最重要环节。我的经验是：角色提示词必须包含三个部分：身份立场、任务目标、输出约束。身份立场决定它看问题的角度，任务目标告诉它每一步要交付什么，输出约束防止它写成一篇没有结构的散文。

举一个交易员角色的提示词片段：

trader_prompt = """ 你是一名拥有10年经验的交易台策略师。你负责综合分析师和研究员的报告，制定一份可执行的交易计划。 规则： 1. 你必须明确交易标的、方向（做多/做空/观望）、入场条件、止损价、目标价、建议仓位（占总资金比例）。 2. 你只能基于研究报告中的数据和证据做决策，不得自己编造数据。 3. 如果两份报告冲突严重，你需要在计划中明确说明你采信了哪一方的逻辑，为什么。 4. 输出必须是JSON格式，字段包括：symbol, side, entry_condition, stop_loss, take_profit, position_ratio, reasoning。 """

关键不是让提示词写得多文艺，而是把输出格式钉死。LLM自由发挥的文本解析成本很高，还容易出错。用JSON约束后，后续风控节点可以直接消费字段。我见过很多人在这一步偷懒，让Agent输出自然语言，结果整个流程像个无底洞一样到处需要正则匹配。结构化输出是这类系统的地基。

3.4 决策回路：从研究报告到最终交易指令的数据流转

一张完整的决策流程可以理解为五步，我用文字描述：

流程启动：系统读取一个股票代码，触发分析师Agent，分析师调用工具获取行情和新闻，输出初步研究报告。

交叉验证：研究员Agent拿到研究报告后，逐个检查报告中的关键论断。它会对每个论断调用对应工具去取原始数据，生成验证注解，标注“支持”或“证伪”或“无法验证”。

对抗辩论：系统再启动一个持相反立场的Agent，生成一份对立报告。裁判Agent依据研究员的数据验证结果，形成一份辩论总结，列出双方论据和裁决倾向。

交易计划和风控：交易员Agent基于辩论总结生成交易计划。风控Agent读取计划中的仓位、止损等字段，和硬编码约束对比，输出“通过”或“否决”及修改建议。

最终裁决：如果没有风控否决，计划进入最终输出队列；如果被否决，把风控意见传回交易员，要求修改，最多迭代两轮，两轮仍不通过则当天放弃该标的。

这套流转的价值在于，每个节点都消费上一个节点的结构化产物，而不是重新让模型自由发挥。我用Pydantic定义了中间数据结构，比如：

class TradePlan(BaseModel): symbol: str side: Literal["long", "short", "hold"] entry_condition: str stop_loss: float take_profit: float position_ratio: float # 0~1之间 reasoning: str

这样下游的风控Agent只需要读取对象字段，不需要再解析大段文本。

3.5 回测与评测：别一上来就看收益率，先看过程指标

很多第一次搭完这套系统的人，第一反应是赶紧跑一个月的回测，看赚不赚钱。我的建议是反过来：先做过程指标的评测。你可以统计这几项：

• 数据覆盖率：多少个Agent的输出里引用了带news_id的证据？没有引用ID的比例是多少？
• 事实一致性：研究员“证伪”了多少个分析师论点？如果证伪率接近0，说明辩论环节没有真正起作用。
• 风控拦截率：交易计划被风控否决的比例是多少？否决理由集中在哪一类？这能帮你完善硬约束。
• 最终指标的参考意义：夏普比率、最大回撤、胜率。但注意，回测收益不等于实盘收益，这里的收益只作为系统逻辑是否自洽的参考。

我建议在回测时采用“t+1对齐”：假设决策生成于第t天盘中，实际订单最早只能在第t+1天开盘执行。这样才能避免未来函数带来的虚假高收益。很多新手第一次跑出惊人超额收益，一查全是数据对齐出了问题。

4. 跑通这套流程后，我踩过的坑和有针对性的优化

这一节全是实操教训。我在本地搭建和测试TradingAgents同类工作流时，遇到过不少看起来很合理、实际却很坑的情况，挑五个印象最深的讲。

4.1 模型对具体数字不敏感：让模型先写推理，再做数值计算

第一次测试时，我让分析师直接输出“目标价”，结果模型给出的目标价和当前价格之间经常出现明显矛盾。比如当前价100元，模型根据一条“营收增长15%”的新闻，目标价写成120元，看起来合理，但它的推理过程里又说“预测营收增长5%”。问题在于，模型擅长文本推理，不擅长精确算术，尤其是处理多步乘除法时，很容易“大致对”。

我的解法是：把数值计算从模型推理里剥离。具体做法是让模型在输出交易计划前，先以文本形式写出推理逻辑，再由一个专门的计算Agent或者代码函数去执行数值计算。比如，如果逻辑里说“按行业平均PE和预期EPS估算目标价”，那么EPS预测由模型给，目标价则由函数计算。不要让模型直接输出最终目标价，而是让输出“目标价 = 函数(eps预测, 行业PE)”。这个改动之后，计划里的数字一致性明显提升。

4.2 辩论变成各说各话：证据必须和论点点对点绑定

多智能体系统最大的隐藏风险，不是模型不聪明，而是系统把“辩论”做成了“吵架”。看多Agent用三条新闻证明上涨，看空Agent用另外三条新闻证明下跌，裁判Agent听完觉得“两边都有道理”，最后给一个模棱两可的观望结论。这样的辩论等于没辩。

根因是缺少“证据对质”环节。我后来做了强制要求：每个论点必须包含证据ID，研究员Agent必须将两份报告中互相矛盾的证据ID拿出来单独比较。比如，看多方引用了一篇财报摘要里的“净利润同比增长”，看空方引用的是同一份财报里的“经营性现金流为负”。研究员需要明确指出，两个论点其实不矛盾，只是角度不同；如果真的有矛盾，则必须进一步调用原始数据确认哪一方的事实描述是准确的。这个“在事实层面先达成一致”的步骤，让辩论质量高了一个台阶。

4.3 未来函数是最隐蔽的坑：数据时间戳必须统一对齐

我回测时发现一个诡异现象：某只股票在下跌当天，系统在盘中就给出了“卖出”信号，完美躲过了连续大跌。听起来很厉害，但我仔细检查后发现，新闻工具返回的是一条收盘后才发布的公告，而我设定的“决策时间”是当天上午。系统等于“提前知道”了下午才发生的消息。这就是典型的未来函数。

解决过程分三步：第一，所有数据接入时统一转为UTC时间戳，保留时区信息；第二，每个工具返回的数据都带上available_at字段，代表这个消息在什么时间点之后才可用；第三，决策节点在读取数据时，只允许读取available_at早于当前决策时间戳的数据。做完这三步，回测收益立刻掉了一大截，但也终于变得可信。

4.4 模型调用成本失控：多角色意味着多倍Token消耗

多智能体系统不是免费的。一个单次决策如果跑满5个节点、每节点调用一次模型，一次下来通常要消耗几万Token。如果还要做辩论轮次迭代，成本会翻倍。我第一次做全市场扫描时，一个下午烧掉了一笔不小的API费用，结果产出的有效决策没几个。

我的对策是分级和缓存。分级的意思是，简单任务用轻量模型，只有复杂推理才用强模型。比如新闻初筛、字段抽取、情感粗分类，用mini/Flash就能干得很好；研究报告、裁判、交易计划这些需要综合推理的节点，才上最强模型。缓存的意思是，对同一只股票同一天的数据，先算一个哈希值，如果今天已经跑过相同数据，就直接复用之前的中间结果，不再重复调用模型。对数据更新不频繁的标的，缓存能省掉一半以上的调用。

4.5 回测结果虚高：幸存者偏差和交易约束一个都不能少

最后一个坑，也是最容易让新手产生幻觉的。如果回测标的池只包含“当前仍然上市交易的股票”，那么那些已经退市的、因为暴跌被摘牌的股票就全被排除在外了，回测结果天然会偏乐观。这个问题叫幸存者偏差。我一开始用某一行业“当前龙头股”做测试，收益曲线很好看，但加入一批已经退市的老样本后，整体表现立刻被打回原形。

另一个被忽略的问题是流动性约束。系统给出的交易计划可能是“在100元买入5%仓位”，但如果这只股票当天成交额很低，你的订单根本成交不了，或者一成交就把价格打上去。我在回测引擎里加入了最小成交额过滤、涨跌停过滤，以及一个简单的滑点假设。这些约束虽然让结果变难看，但更接近现实。做研究可以乐观，做工程必须悲观。

5. TradingAgents的边界与正确打开方式：什么场景该用它，什么场景千万别用

聊完技术细节，回到一个更实际的问题：这套东西到底该怎么用？什么情况下它有价值，什么情况下它只会给你制造麻烦？这部分我尽量讲得直接一点。

5.1 不要把它当成全自动交易机器人

这句话我说得再强调一次也不算多：多智能体系统有延迟、有调用成本、有不可控的推理波动，它不适合直接接实盘。LLM的决策时间通常在几秒到几十秒，遇到行情剧烈波动时，这个速度根本跟不上。更关键的是，它的推理过程虽然比单模型更透明，但依然不是数学上可证明的确定性算法，极端行情下所有Agent共享同一个语义空间，也完全可能集体陷入同一个思维误区。

我建议的用法是：它输出研究结论和交易计划草稿，你作为人来审查，决定是否采纳。把它当成一个“AI研究助理”，而不是“AI基金经理”。实盘交易涉及真金白银，还有监管合规问题，任何自动化系统接入前都必须经过券商和风控部门的批准，这个底线不要碰。

5.2 它真正适合三类人

我觉得最舒服的使用场景，是把它当成“思维脚手架”。比如你在研究一个新的行业，过去可能要花两小时读新闻、翻财报、整理信息，现在可以让分析师Agent先给出初始框架，研究员Agent去验证数据，你来决定最终的判断。它能帮你减少信息收集和初步整理的时间，但不能替你做决策责任。

5.3 后续可以往哪些方向扩展

如果你已经跑通了最小闭环，可以考虑这几个扩展方向。第一，多市场覆盖：把数据源扩展到美股、港股、外汇、期货，让一套智能体框架适配不同市场的交易规则。第二，引入长期记忆：把历史研究报告存入向量数据库，让新决策能引用过去三周的分析结论，而不是每次都从零开始。第三，集成强化学习：把回测结果作为奖励信号，对交易员Agent的提示词做自动调优，让“总结经验”这件事也变成自动化。第四，接入模拟交易：先接券商仿真接口，跑足够的模拟盘，再决定是否有必要做更高阶的实盘适配。无论往哪个方向走，都要记住一条：多智能体系统的价值，不在于它能给你一个收益更高的信号，而在于它把决策过程变得可拆解、可检查、可复盘。这才是它能长期复用的真正原因。

最后再分享一个我个人的经验：搭建这类系统时，不要一上来就追求“角色多、辩论深、模型强”。先用一个最小的两角色版本跑通数据流，比如只有一个分析师和一个风控经理，加上硬编码止损规则。等这条链路稳定后，再逐步加入研究员、交易员、裁判。每增加一个角色，都要问自己一句：它带来了多少信息增益，还是只增加了Token成本和延迟？在我做过的项目里，那些看起来“很热闹但没什么用”的多智能体系统，基本都是因为角色间没有真正形成信息互补，只是在重复制造风格不同的同一句话。避开这个陷阱，你的TradingAgents才算真正落地。