最近交易技术社区里冒出一个高频词TradingAgents。如果你把英文拆开看就是“交易智能体”。它既不是某个荐股软件也不是传统量化策略而是一整套把大型语言模型包装成“多角色交易团队”的开源框架思路。简单说就是把一个真实交易公司里分析师、研究员、交易员、风控经理的工作流程全部塞进多个LLM智能体里让它们通过对话、辩论、证据核查、互相否决最终产出交易决策。这篇文章我会按技术拆解的方式聊清楚TradingAgents这类系统到底改变了什么它的核心机制为什么有价值以及如果你自己动手搭一个最小可用的多智能体交易工作流会踩到哪些我用真金白银换来的坑。全程只讲工程和技术原理不构成任何投资建议。1. TradingAgents不是什么“自动炒股机器人”而是一套多人格决策流水线很多人在第一次看到“多智能体交易”这个概念时理解成“让AI自己开户、自己下单、自己赚钱”。这个理解不能说全错但至少偏了十万八千里。TradingAgents的设计目标从来不是替代交易员去敲单而是把原本只存在于一个大脑里的决策过程拆成多个角色、多轮辩论、互相制衡的流水线。1.1 从“单模型给答案”到“多角色给结论”范式差异在哪过去我们用LLM做投资分析最常见的做法是把新闻、财报、行情数据一股脑塞给ChatGPT问一句“你觉得这只股票下周怎么走”然后拿回答当参考。这种做法最大的问题是模型一旦给出结论你根本不知道它依据了哪条数据、忽略了多少反向信息、有没有做过风险校验。它像一个人关起门拍脑袋整个过程完全不可审计。TradingAgents改变的是这个“拍脑袋”过程。它把决策拆成了多个独立的思考节点有人负责收集和解读信息有人负责质疑和查证有人负责把观点变成可执行计划还有人专门负责泼冷水。这个流程本质上是把“一个可能产生幻觉的LLM”变成“一组相互制约、需要对自己的论点负责的LLM”。虽然每个Agent本身仍然是同一个基座模型但它们拿着不同的提示词、不同的上下文、不同的工具权限产出的内容就有了角色边界。这一点非常关键多智能体不等于更强的智能而是等于更可控的流程。你不再关心某一次回答对还是错而是关心整个团队有没有充分交换信息、有没有人做最终风险把关。1.2 交易公司里的五类角色如何映射成AgentTradingAgents这类项目最吸引我的地方是它把真实金融机构里的人员分工搬进了代码里。以目前社区里流传较广的角色设计为例大致可以拆成五个岗位角色对应职责核心产出类比真实岗位分析师读取新闻、行情、财务数据形成初始观点研究报告卖方分析师研究员对分析师的论点做证据查证补充数据验证报告/反驳意见买方研究员交易员综合多份报告设计具体交易计划交易计划书交易台策略师风控经理检查仓位、止损、集中度、极端场景风控意见/否决权风险管理部基金经理听取各方意见做最终决策最终交易指令投资委员会实际实现时不一定叫这些名字但核心逻辑一致。分析师先输出偏向性观点研究员必须用工具去查原始数据来验证交易员不能直接看到行情就下单风控经理拥有“一票否决权”。这种分工最大的好处是没有任何单一智能体可以在没有交叉验证的情况下直接输出交易指令。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都用同一个最强模型。我常用的搭配是组件推荐方案理由编排框架LangGraph天然支持循环、条件判断和状态持久化强推理模型GPT-4o/Claude/DeepSeek系列用于研究报告、裁判、交易计划轻量模型各家mini/Flash版本用于新闻初步筛选、格式化提取数据源AkShare/Tushare/Finnhub等公开接口覆盖行情、新闻、财务数据方便本地验证结构化输出Pydantic JSON Mode确保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_sourceakshare, news_id12345”这样后续辩论时证据引用可以直接指向这条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说明辩论环节没有真正起作用。风控拦截率交易计划被风控否决的比例是多少否决理由集中在哪一类这能帮你完善硬约束。最终指标的参考意义夏普比率、最大回撤、胜率。但注意回测收益不等于实盘收益这里的收益只作为系统逻辑是否自洽的参考。我建议在回测时采用“t1对齐”假设决策生成于第t天盘中实际订单最早只能在第t1天开盘执行。这样才能避免未来函数带来的虚假高收益。很多新手第一次跑出惊人超额收益一查全是数据对齐出了问题。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 它真正适合三类人使用者用法建议注意事项量化研究者用多智能体生成可解释的因子和事件研究样本把中间报告当作特征分析材料需要关注数据时间对齐避免未来函数LLM应用开发者借鉴其智能体编排、工具调用、角色辩论、结构化输出等工程经验先做小规模验证别一上来搞全市场投资教育/投研辅助用Agent输出流程展示“一个专业决策需要考虑哪些维度、如何做风险控制”明确标注用途为教学演示不能替代正式投资建议我觉得最舒服的使用场景是把它当成“思维脚手架”。比如你在研究一个新的行业过去可能要花两小时读新闻、翻财报、整理信息现在可以让分析师Agent先给出初始框架研究员Agent去验证数据你来决定最终的判断。它能帮你减少信息收集和初步整理的时间但不能替你做决策责任。5.3 后续可以往哪些方向扩展如果你已经跑通了最小闭环可以考虑这几个扩展方向。第一多市场覆盖把数据源扩展到美股、港股、外汇、期货让一套智能体框架适配不同市场的交易规则。第二引入长期记忆把历史研究报告存入向量数据库让新决策能引用过去三周的分析结论而不是每次都从零开始。第三集成强化学习把回测结果作为奖励信号对交易员Agent的提示词做自动调优让“总结经验”这件事也变成自动化。第四接入模拟交易先接券商仿真接口跑足够的模拟盘再决定是否有必要做更高阶的实盘适配。无论往哪个方向走都要记住一条多智能体系统的价值不在于它能给你一个收益更高的信号而在于它把决策过程变得可拆解、可检查、可复盘。这才是它能长期复用的真正原因。最后再分享一个我个人的经验搭建这类系统时不要一上来就追求“角色多、辩论深、模型强”。先用一个最小的两角色版本跑通数据流比如只有一个分析师和一个风控经理加上硬编码止损规则。等这条链路稳定后再逐步加入研究员、交易员、裁判。每增加一个角色都要问自己一句它带来了多少信息增益还是只增加了Token成本和延迟在我做过的项目里那些看起来“很热闹但没什么用”的多智能体系统基本都是因为角色间没有真正形成信息互补只是在重复制造风格不同的同一句话。避开这个陷阱你的TradingAgents才算真正落地。