多代理LLM交易系统实战拆解：从角色分工到落地避坑指南

说起TradingAgents，最近在量化圈和AI圈的讨论热度一直没下去过。很多人看到Demo里几个Agent有模有样地开会、讨论、争论该买哪只股票，第一反应是"挺炫酷"，但真问到这东西能落地吗、怎么落地、回测曲线可信吗，大多数人都答不上来。我当时也是带着一堆疑问去研究的，前后折腾了将近两个月才把思路理顺，踩了不少坑。这篇文章就把我对TradingAgents这类多代理交易系统的完整拆解和实战心得写出来。

如果你第一次接触这个方向，看完能建立起整体的架构认知，知道每个角色在做什么、代理之间怎么协作、数据怎么流转；如果你已经在研究多代理框架，那后面关于协作协议、上下文管理、回测陷阱和落地成本的内容，应该能帮你少走几个月的弯路。

1. TradingAgents是什么：一个让AI角色各司其职的交易决策框架

1.1 "多代理"不是花架子：交易决策天然需要团队协作

先聊个本质问题：交易决策到底难在哪？很多人以为难在"预测涨跌"，但真正做过交易就知道，难的是把完全相反的信息综合成一组可执行动作——基本面说公司质地很好，技术面说趋势已经走坏，资金面显示主力正在撤退，宏观上流动性又在收紧。单一模型一次性消化这么多互相矛盾的信号，往往会给出一个和稀泥式的结论。

TradingAgents的思路很直接：模仿一个真实投资团队的运作方式，把决策拆给多个各司其职的代理。这让每个代理都能专注于自己擅长的分析维度，再通过他们之间的讨论、辩论和验证，把单点模型的偏见摊薄。这种方法之所以有效，是因为它把"一个人既要看财报又要盯K线还要管仓位风控"的认知负荷，拆成了流水线上互相监督的工序。

1.2 传统单一Prompt方案为什么会撞墙

我用传统"一个大Prompt塞进去"的方法做过一段时间实验，核心痛点非常明确。首先，上下文有限，把所有数据都塞进一次调用，模型根本记不住前面的细节，分析到后面就只顾着"顺着话头说"。其次，没有对抗机制，模型天然倾向迎合你给的已有观点，即使两个信号明显冲突，它也会试图给你编一个自洽但不可验证的故事。

更麻烦的是，单一Prompt方案出问题以后你基本没法排查——到底是数据问题、指令问题还是模型臆测？你只知道最后的结论不对，但整个过程是个黑盒。TradingAgents这类框架把决策拆成了多步、多方参与的流程，哪一步出了问题，回头看中间某个代理的输出就能定位，这对工程落地的意义非常大。

1.3 核心工作流概览

从整体上看，一个典型的TradingAgents工作流分为四个阶段。研究阶段由数个研究员代理从不同数据源收集信息；分析阶段由分析师们对研究结果进行解读并形成观点；决策阶段由交易员代理基于分析师观点给出具体的交易方向和仓位建议；最后是风控阶段，由专门的风控代理对交易建议进行一致性检查、风险参数校验和极端情况压力测试，通过后才会输出最终动作。

这整个流程跟我们平时在投资团队里看到的分工协作几乎没有差别。人做交易决策需要什么，这个框架就模拟什么。它不是预测神器，而是把决策过程变得结构化、可审计、可反复优化。

2. 角色分工拆解：研究员、分析师、交易员与风控官的职责边界

2.1 研究员代理：从公开数据中挖掘有效信息

研究员代理是整个流程的输入端。它的核心职责是把外界信息转化为结构化的"研究笔记",包括财务指标变化、行业新闻情绪、技术指标状态等等。实操中我倾向于把研究员再按数据来源拆成几个子代理，例如基本面面负责人、技术面负责人、新闻情绪负责人，各看各的，互不干扰。任何一个研究员代理的分析范围是窄但深的，这种"窄"恰恰是质量保证。

我发现一个比较有效的设计是：给每个研究员代理定义好输出模板，让它们必须回答固定的问题集——"相比上次观察，关键指标怎么变化""目前的信号偏向多方还是空方""支持这个判断的证据有哪些""可能的反方观点是什么"。第四点尤其重要，它迫使研究员不只找顺手的证据，还得正视反面信息，为后面的分析讨论提供靶子。

2.2 分析师代理：观点的形成与对抗

分析师的输入是研究员们的研究笔记，输出是结构化的投资观点。这个环节适合让多个分析师同时独立工作，可以在同一个数据基础上给出不同方向的观点——一个相对乐观、一个相对保守。我尝试过让两个分析师各持一方观点做辩论，效果很有意思：当多方分析师必须反驳空方数据时，它的分析深度明显提升，不再只是"我觉得业绩好所以看多"这种单薄结论。

分析师之间观点的差异非常重要，如果所有人的观点高度一致，说明信息多样性不够，要么是研究员阶段已经遗漏了关键视角，要么是分析师的System Prompt写得过于雷同。我后来特意让两个分析师的prompt风格差异化——一个偏Graham式价值派，一个偏Livermore式趋势派，两者的分歧明显变大，最终汇总出的决策质量也更稳定。

2.3 交易员代理：把观点翻译成订单

交易员代理负责"开会做决定"。它接收所有分析师观点，结合账户资产情况和当前仓位，输出最终的交易操作——是买入、卖出还是持有，方向多大，止损位放在哪，目标价位又在哪里。

这里有个容易踩的坑：交易员输出结果如果不做字段约束，它会给你写一大段散文式总结，可能包含几个持仓方案，却不说最终选哪个。为了规避这点，我让它必须用JSON格式输出，明确给出action、ticker、position_size、stop_loss、take_profit、rationale这几个字段。有了结构化输出，后续风控、回测甚至实盘推送就能直接把这串JSON接上，不用再做一层语义解析，减少出错。

同时，交易员代理必须能看到当前持仓和账户风险限额。否则他会给出一个完全脱离实际可能性的建议——比如满仓单票，这在真实场景里第一关就会被风控打回。

2.4 风控官代理：决策前的最后一道闸门

交易员给出建议之后，风控官代理负责验证。这一步极其重要，但由于它不像分析师那样负责"产出观点"，经常被人忽视。风控代理要检查的点包括：与当前已有持仓是否冲突、仓位是否超过单票限制、止损设置是否合理、整个组合的名义风险是否在可承受范围。

我通常给风控代理设置几条硬性规则，以近似"否决权"的方式来运作。例如单票仓位不得超过组合总资产的20%，单笔交易的预期风险敞口不得超过账户净值的3%。规则可以同时用prompt描述，也可以在代码里做一步硬性校验——我建议两者都做，prompt让模型理解规则，代码校验兜底。风控反馈意见会送回交易员代理，交易员根据反馈修正建议再交回风控，形成一个小的交互循环。这个"否定-修正"的回路是整个多代理系统里最像人类团队协作的地方。

3. 代理之间怎么说话：协作协议、记忆共享与冲突消解

3.1 结构化对话协议：让代理间的交互可解析

代理之间的通信方式，直接决定了整个框架是"能跑"还是"能稳定跑"。我最早尝试过让代理之间用自然语言自由对话，结果是灾难：有的代理东拉西扯，有的代理把别人的观点想办法复述一遍当自己的输出，信息熵越聊越低。后来把交互改成了结构化消息，效果立刻不一样。

我的做法是定义几种固定的消息类型：ResearchNote,AnalysisOpinion,TradeProposal,RiskCheckResult。消息体里除了文本内容，还有发送者角色、时间戳、关联目标标的、数据引用来源这些元信息。代理之间不直接"聊天"，而是通过共享消息池读取与自己相关的消息、在池中发布新消息。这样，每条信息都有了明确的来源和去向，系统运行过程可以完整回溯，出了问题直接翻日志就行。

3.2 状态机驱动的流程编排

多代理框架最怕的就是代理之间的调用逻辑混乱，彼此等待、输出覆盖。我用了一个很朴素的状态机来编排流程：每个代理对应一个状态节点，当前置条件满足后激活对应代理，代理输出写入消息池，再判断是否进入下一个节点。

这个状态机的设计可以做到相当灵活。在"研究-分析-交易-风控"的主链路之外，我还加了"风控否决后回到交易员修正"的循环边，以及"研究员信息不足时启动二次研究"的回退边。状态机的好处是让整个系统的运行路径变得可预期：某一天程序出现意外输出，你只需要看状态转移日志就知道是哪一步跳错了。

3.3 上下文与记忆管理：避免长对话把模型"聊晕"

多代理系统一个很容易被低估的问题是上下文窗口消耗。每个代理如果都要把历史所有轮次的消息读完，再聪明的模型也会被不相关信息干扰，表现得像"记忆力很好但判断力很差"的人。好的做法是只把与本轮任务直接相关的消息子集注入当前代理的上下文。

我结合任务类型设计了不同粒度的记忆机制分析类任务读最近一轮研究笔记；决策类任务读当前持仓和本次流程的所有观点摘要，而非原始长文；风控类任务则读取交易提案和固定风控规则。为了控制上下文，分析师的原始长文会经过摘要后再传给下一层。系统每次运行结束，我会把整个流程的决策摘要存进长期记忆库，下次运行时可以引用历史决策作为参考，用于"关注连续几次决策的一致性"。这个设计思路跟LangChain和AutoGen的Memory模块很像，但自己做的好处是可以精确控制每层读什么、不读什么。

3.4 多头意见冲突时如何收敛

多个分析意见冲突怎么办？这是多代理系统绕不开的问题。实践中发现，如果只是简单投票，多数情况下会得到"第二个分析师的观点和第一个相反，因此建议观望"这种无意义结论。要解决冲突，关键是让冲突发生在同一个维度上。

我的做法是让不同分析师的输出落到统一的字段结构里，然后由交易员代理负责"综合"——它必须解释为什么在多方和空方分歧明显时选择了某一方向，并给出明确的置信度。如果两个分析师的分歧极大，交易员又给不出有说服力的理由，我就让系统自动把置信度调低、仓位建议缩减到正常水平的50%以下。用规则兜底，比完全依赖模型的临场判断更可靠。

4. 把框架跑起来：数据接入、信号生成与回测验证的完整链路

4.1 数据源接入与清洗

TradingAgents这种框架的数据需求，和传统量化策略相比有一个显著差异：它不只是吃K线或因子数据，更依赖语义信息——财报文本、新闻摘要、分析师评论、宏观数据解读。我搭建数据层时，把所有来源统一清洗成两类供后续代理消费：数值型指标（价格、成交量、财务比率、宏观数据）和文本型事件（新闻标题、公告要旨、点评）。

文本型数据建议做去重和去噪。直接用原始新闻标题喂给模型，模型很容易被同一事件的重复报道带偏，比如某个大新闻被十几家媒体同一天报道，代理就会认为这是持续利好，实际上只是一次事件被放大。我用了一道简单的"事件指纹"去重，按"公司名+事件关键词+报道时间窗"归并，把同一条新闻收敛成一条带权重的消息，效果非常明显。

4.2 信号生成的输入输出结构

数据清洗加工好后，会打包成标准的SignalBundle，包含目标标的、时间范围、关键数值指标、新闻事件摘要和历史决策摘要。研究员代理拿到这个Bundle后进行分析，分析结果逐级传递，最后交易员输出结构化信号。

信号里最关键的是置信度字段。早期我让代理自己对判断给置信度，结果模型普遍过度自信，动不动就给出90%的胜率预测，后来改成"基于历史类似交易结果的统计胜率"作为客观置信度参考，模型的自我评估只作为微调。这样既保留了模型的主观判断，又用统计基数给它踩了刹车。

4.3 回测不是跑个backtrader那么简单

多代理系统回测的特殊困难在于，历史行情上的"当时可得信息"和"历史之后才知道的信息"必须严格区分开。用未来函数会让回测曲线漂亮得离谱，但实盘立刻露馅。这里的关键是逐点重放：回测的每一天，代理只能看到截至当日的数据和新闻，不能让它提前看到未来走势。

我在数据管线上加了严格的时间戳隔离：所有新闻、价格数据、财务报告都按发布时间的真实时间戳来注入，而不是按数据在文件里的排列顺序。此外，LLM本身有训练数据里带有的"事后知识"，这是完全无法根除的——让GPT面对"2020年3月的市场"时，它知道后来发生了什么。这个问题没有完美解法，但至少可以做到：回测时对标的、时间进行脱敏实验，观察模型输出是否明显依赖"后见之明"，从而评估回测结果的可信度。这一点我认为做TradingAgents的人必须清楚，否则拿回测结果忽悠自己没有意义。

4.4 评价指标：不要只盯着收益率

收益率是最容易被短期运气左右、最难比较的指标。我给自己的回测体系定了一套多维评价指标，重点包括：年化收益率（当然还是看）、最大回撤、夏普比率、胜率、盈亏比以及交易频率。其中盈亏比比胜率重要得多，多代理系统天然更擅长做深度的定性判断，所以盈亏比是评估信号质量更合适的窗口。

多说一句，交易成本对这类LLM驱动策略的影响比想象中大得多。LLM信号本身有延迟，策略不容易做高频，我按单边千分之二的手续费加滑点做压力测试时，很多看起来"能赚"的策略直接变成亏损。任何回测都应该把成本模型往高了设，宁可估高也别估低。

5. 落地过程中的几个大坑与我的应对建议

5.1 上下文膨胀与API成本失控

多代理系统的调用次数比单一Prompt方案高出一个数量级。一次完整决策流程里，五六个代理各跑一到三轮调用，就是十几次LLM API调用。如果每个调用还携带长上下文，成本相当可观。

我的应对经验是：给每一步调用都设定最大输出长度限制和上下文精简策略。能用摘要就绝不用全文，能用局部数据就别把所有历史都带上。还有一个小技巧是缓存——研究员对不同标的前缀分析结果经常完全一样，尤其是一些大盘宏观数据，我做了RAG式缓存，相同数据查询直接复用上次结果，能省下30%左右调用量。

5.2 代理"一本正经地胡说八道"

LLM在金融场景下的幻觉问题不能指望靠提示词完全解决。我发现最实用的防线是把关键数值都用代码从数据源获取，而不是让模型从文本中"理解后生成"。例如财务比率直接由程序计算好塞进上下文，分析师只负责解读，不负责算数，这样就在源头上掐断了算错数的可能。

另一个防线是给代理叠加"引用来源"要求：分析观点必须标注引用了哪个研究笔记或数据字段，风控阶段可以做一致性检查。如果一个代理的结论在数据层面找不到依据，就自动标记为低置信度并请求重新分析。

5.3 历史回测的优秀结果与实盘现实的巨大落差

实盘遇到的问题，回测里基本都看不到。最典型的是模型信号与盘口流动性的脱节：回测里假定想买就能买，但实际上小市值标的的深度根本不够，滑点极大。这个问题我在小市值标的上吃了大亏。

现在我的策略限定了标的池，只有日均成交额高于某个门槛的标的才允许进入候选池。同时，回测系统里加入了一个简单的冲击成本模型：根据标的近期平均成交量和信号大小估算单笔交易对价格的冲击，超过阈值就拒绝执行。这样做之后，回测曲线没那么好看了，但实盘的信任度明显提升了。

5.4 延时、失败重试与运行时监控

多代理系统每一步都可能失败：API超时、返回格式坏掉、模型拒绝回答问题，这些都很常见。最关键的是让框架具备"局部失败自我修复"的能力。超时自动重试是基本操作，但更复杂的场景是风控代理返回了非法JSON，直接卡死整个流程。

我给每一步调用外面都包了重试和降级逻辑：重试两次还失败，就跳过该代理并标记为"缺失意见"，流程继续走，交易员在看到"缺失意见"时会自动降低综合置信度。宁可拿着不完整的信息做一个偏保守的决策，也不能让整个流程因为某一个代理宕机而白白空转。

实盘运行时，我还会监控每次决策的耗时和token消耗，一旦均值异常升高，说明可能在读太多上下文或者模型行为有变化，立刻人工介入检查。Agent这种东西偶尔看起来像一个正常系统，但遇到反弹数据时行为的不确定性，把人逼成敬业的运维，是这个方向特有的体验。

5.5 一些从实操中沉淀的具体建议

最后分享几条我觉得比较实用的经验，不是什么高深理论，就是一次次调试中磨出来的教训。

第一，先用模拟盘完整跑两个星期再碰真实资金。流程能跑通和流程能稳定跑出符合预期的信号，中间隔着巨大的鸿沟。模拟盘期间重点观察决策一致性，而不是收益。

第二，把所有Agent的输出全部落盘。每轮决策完成后，把研究员笔记、分析师观点、交易员原始输出、风控反馈都存下来。你不会知道自己多快就会需要一个"当时它为什么这么判断"的答案。

第三，给模型的选择增加"不交易"这个选项。框架默认倾向是输出一个动作，这让它频繁给出不必要的小仓位交易，不断消耗手续费。在交易员和风控代理的Prompt中明确写"只有当预期概率显著高于阈值时才能给出买入或卖出信号，否则就持有"，这个微小改动就省下了一大笔成本。

第四，建立足够的先验认知。别指望系统帮你发现"不为人知的秘密"，它更适合做"给定信息下最合理的综合判断"。把它当作一个24小时不休息、各有专长的投研团队，而不是用来预测下一个涨停板的黑箱。想清楚这个定位，对TradingAgents这类框架的期望值管理会健康很多，使用的效果也好很多。